Web error: Error: can't open template file (upsstats.html) HTTPD error log says: [Fri Sep 25 11:27:23.117124 2020] [cgi:error] [pid 72959] [client 10.x.x.x:61405] AH01215: upsstats: Can't open /usr/local/etc/nut/upsstats.html: Permission denied: /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi, referer: http://10.x.x.y/nut/header.html Copy&Past upsstats.html from sample file doesn't help. Permissions on all folder /usr/local/etc/nut/* is uucp:uucp doesn't help.
What is ls -l /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi ?
I should have asked: ls -l /usr/local/etc/nut/upsstats.html But both will do.
Key to know: apache will be running as www www needs to read that file. Why HTML is in /usr/local/etc/ is another issue to resolve later. That should be in /usr/local/www
(In reply to Dan Langille from comment #3) ${LOCALBASE}/etc/nut/ is the proper place for it. It is not read by apache/nginx. It's is interpreted by upsstats.c (upsstats.cgi): slippy$ ag display_template upsstats.c 843:static void display_template(const char *tfn) 1037: display_template("upsstats-single.html"); 1062: display_template("upsstats.html"); slippy$ upsstats.html is a config file, not a raw html file.
(In reply to Dan Langille from comment #1) This isn't all the information we need. AH01215: upsstats: Can't open /usr/local/etc/nut/upsstats.html: Permission denied: /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi, referer: http://10.x.x.y/nut/header.html This is telling us that /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi (a binary produced by upsstats.c) cannot read its config file /usr/local/etc/nut/upsstats.html. Can you ls -l /usr/local/etc/nut/upsstats.html. What ID is your cgi running under? While we're at it, the following. I want to verify that upsstats.cgi isn't an invalid format ELF file. ls -l /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi file /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi. I suspect that /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi is running under an account that does not have read access to /usr/local/etc/nut/upsstats.html or the directory hierarchy it is in.
(In reply to Cy Schubert from comment #5) > Can you ls -l /usr/local/etc/nut/upsstats.html. -rw-r--r-- 1 uucp uucp 4003 23 авг. 18:32 /usr/local/etc/nut/upsstats.html > What ID is your cgi running under? What are you mean? nut process id or something else? > ls -l /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi -r-xr-xr-x 1 root wheel 48520 23 авг. 18:32 /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi > file /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi. /usr/local/www/apache24/cgi-bin/nut/upsstats.cgi: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.1, FreeBSD-style, stripped
Just FYI: I want to add... that with the same permissions in the nut-2.7.4_14 version everything works and every time I fixed permissions for whole folder: chown -R uucp:uucp /usr/local/etc/nut/* Right after update permissions for changed files (not edited config files) has permissions: root:wheel, that why I fixed permissions but this trick doesn't help at this time.
(In reply to AlexG from comment #6) No, we already know nut is running under the uucp id. What id is the upsstat.cgi running under? Probably apache or an account of your choosing if you configured apache that way. What specific id is upsstat.cgi running under?
Created attachment 218325 [details] Revert dvl patch Try this.
(In reply to Cy Schubert from comment #9) I hope it's not that. It affects only .sample files.
(In reply to Dan Langille from comment #10) That was the only other change, it couldn't be the syslog.d part of your patch. Why would the port magically change after two seemingly changes unrelated to this PR?
(In reply to Cy Schubert from comment #8) I thing apache used www id this is default account what running all cgi scripts
OP says: "Right after update permissions for changed files (not edited config files) has permissions: root:wheel, that why I fixed permissions but this trick doesn't help at this time." If a trick has always been needed, something was not right before.
(In reply to Dan Langille from comment #13) The difference between your patch and without it is: With dvl patch the permissions are 0640: -rw-r----- 1 root uucp 6.7K Sep 25 22:31 upsstats-single.html -rw-r----- 1 root uucp 6.7K Sep 25 22:31 upsstats-single.html.sample -rw-r----- 1 root uucp 4.0K Sep 25 22:31 upsstats.html -rw-r----- 1 root uucp 4.0K Sep 25 22:31 upsstats.html.sample Without dvl patch the permissions are 0644: -rw-r--r-- 1 root wheel 6.7K Sep 26 13:39 upsstats-single.html -rw-r--r-- 1 root wheel 6.7K Sep 26 13:39 upsstats-single.html.sample -rw-r--r-- 1 root wheel 4.0K Sep 26 13:39 upsstats.html -rw-r--r-- 1 root wheel 4.0K Sep 26 13:39 upsstats.html.sample This is why upsstats.cgi cannot read the file. It's running under the apache account under the control of apache. The permissions are too restrictive. And, the only way this can work is if the files are in the apache group, not uucp, OR if the apache account is also in the uucp group. I will revert the patch.
A commit references this bug: Author: cy Date: Sat Sep 26 20:46:03 UTC 2020 New revision: 550222 URL: https://svnweb.freebsd.org/changeset/ports/550222 Log: Revert r549867. The permissions were wrong. PR: 249893 Changes: head/sysutils/nut/Makefile head/sysutils/nut/pkg-plist head/sysutils/nut-devel/Makefile head/sysutils/nut-devel/pkg-plist
Sorry for the breakage. I should have tested the patch more thoroughly before committing it.
Now I understand. Sorry. I still assert that at least some sample files need different permissions to work out of the box. That's what I found when setting it up for the first time. I see now why that does not apply to the NUT_CGI but I'm sure it does apply to the ETCDIR files.
(In reply to Cy Schubert from comment #16) And I should have tested with NUT_CGI which I am not using. Sorry.
(In reply to Dan Langille from comment #18) I don't use it here either. It's simpler to log into my gateway and issue the command, especially with JuiceSSH from my phone, because I'd never expose anything like that out on the public side of my network.
BTW, this and cleaner log entries are the reasons I refactor patches to commit functional patches separately. It's so much easier reverting patches and helps people who want to browse the logs looking for errors like this. It's especially handy in src. Otherwise the commit logs look more like Linux commit logs, making it more difficult to separate out one part of a jumbo patch to resolve bugs.
(In reply to Cy Schubert from comment #20) Yes, I like that.
(In reply to commit-hook from comment #15) After update to version nut-2.7.4_17 all working as usually. Thank you very much!