Nut upsuser - Aug 2020 - Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)

For directory permissions, the "x" priv determines if you can access
the directory, so going from 555 (r-x,r-x,r-x) to 640 (rw-,r--,---) pretty much
locks out access to the dir. Myself, I'd go back to 555. 640 essentially
locks the group "nut" out . . .

- Tim

On August 11, 2020 11:11:22 PM CDT, Todd Benivegna <todd at benivegna.com>
wrote:
>Ok, so just a follow-up to my last email; still following that guide, which
is great…. Just stuck on getting the nut-server service starting
automatically.  Got everything else working.  I’ve been able to get the
nut-client starting up automatically at boot up (I had a missing “1” in
upsmon.conf.  Oooops!)  However, I cannot get nut-server service to start-up
automatically still.
>
>proton at proton:~$ service nut-server status
>nut-server.service - Network UPS Tools - power devices information server
>     Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor
preset: enabled)
>     Active: failed (Result: exit-code) since Tue 2020-08-11 23:43:55 EDT;
2min 0s ago
>    Process: 1559 ExecStart=/sbin/upsd (code=exited, status=1/FAILURE)
>
>
>proton at proton:~$ service nut-client status
>nut-monitor.service - Network UPS Tools - power device monitor and shutdown
controller
>     Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled;
vendor preset: enabled)
>     Active: active (running) since Tue 2020-08-11 23:43:55 EDT; 2min 7s ago
>    Process: 1567 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS)
>   Main PID: 1570 (upsmon)
>      Tasks: 2 (limit: 9019)
>     CGroup: /system.slice/nut-monitor.service
>1569 /lib/nut/upsmon
>1570 /lib/nut/upsmon
>Warning: some journal files were not opened due to insufficient permissions.
>
>
>I can get it to start manually by doing "sudo service nut-server
restart".  Then it starts up…. Just starts up and all is good.
>
>
>proton at proton:~$ sudo service nut-server status
>nut-server.service - Network UPS Tools - power devices information server
>     Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor
preset: enabled)
>     Active: active (running) since Tue 2020-08-11 23:49:50 EDT; 12s ago
>    Process: 2949 ExecStart=/sbin/upsd (code=exited, status=0/SUCCESS)
>   Main PID: 2950 (upsd)
>      Tasks: 1 (limit: 9019)
>     CGroup: /system.slice/nut-server.service
>2950 /lib/nut/upsd
>Aug 11 23:49:50 proton upsd[2949]: listening on 127.0.0.1 port 3493
>Aug 11 23:49:50 proton upsd[2949]: listening on 127.0.0.1 port 3493
>Aug 11 23:49:50 proton upsd[2949]: Connected to UPS [ups]: usbhid-ups-ups
>Aug 11 23:49:50 proton upsd[2949]: Connected to UPS [ups]: usbhid-ups-ups
>Aug 11 23:49:50 proton upsd[2950]: Startup successful
>Aug 11 23:49:50 proton systemd[1]: Started Network UPS Tools - power devices
information server.
>Aug 11 23:49:50 proton upsd[2950]: User upsmon_local at 127.0.0.1 logged
into UPS [ups]
>Aug 11 23:49:51 proton upsd[2950]: User monuser at 192.168.1.70 logged into
UPS [ups]
>Aug 11 23:49:53 proton upsd[2950]: User upsmon_remote at 192.168.1.30 logged
into UPS [ups]
>Aug 11 23:49:53 proton upsd[2950]: User upsmon_remote at 192.168.1.20 logged
into UPS [ups]
>
>
>
>Here is my upsd.conf:
>
>LISTEN 127.0.0.1 3493
>LISTEN 192.168.1.31 3493
>
>
>
>Could it be a permissions issue?  Weird that all it takes is me manually
doing "sudo service nut-server restart” is all it takes.  Clients connect
and everything.
>
>Thanks,
>
>Todd
>
>--
>Todd Benivegna // todd at benivegna.com
>On Aug 11, 2020, 10:29 PM -0400, Todd Benivegna <todd at
benivegna.com>, wrote:
>> Thanks Manuel.  I’m following that guide but am now stuck when checking
to make sure the nut-sever and nut-client are up and working.  I got this:
>>
>> proton at proton:~$ service nut-server status
>> nut-server.service - Network UPS Tools - power devices information
server
>>      Loaded: loaded (/lib/systemd/system/nut-server.service; enabled;
vendor preset: enabled)
>>      Active: failed (Result: exit-code) since Tue 2020-08-11 22:13:42
EDT; 1min 18s ago
>>     Process: 1537 ExecStart=/sbin/upsd (code=exited, status=1/FAILURE)
>>
>> Warning: some journal files were not opened due to insufficient
permissions.
>>
>>
>>
>> proton at proton:~$ service nut-client status
>> nut-monitor.service - Network UPS Tools - power device monitor and
shutdown controller
>>      Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled;
vendor preset: enabled)
>>      Active: failed (Result: exit-code) since Tue 2020-08-11 22:13:42
EDT; 1min 50s ago
>>     Process: 1543 ExecStart=/sbin/upsmon (code=exited,
status=1/FAILURE)
>>
>> Warning: some journal files were not opened due to insufficient
permissions.
>>
>>
>>
>> Do I have incorrect permission on the conf files?  I did change this a
while back.  Why should the default permissions be on the nut folder and the
files in the nut folder?  I changed from 555 to 640 I believe.
>>
>> proton at proton:~$ sudo ls -la /etc/nut
>> total 60
>> drw-r-----   2 root nut   4096 Aug 11 22:13 .
>> drwxr-xr-x 147 root root 12288 Aug 11 22:02 ..
>> -rw-r-----   1 root nut   1543 Aug 11 22:13 nut.conf
>> -rw-r-----   1 root nut   5615 Aug 11 21:59 ups.conf
>> -rw-r-----   1 root nut   4601 Aug 11 22:04 upsd.conf
>> -rw-r-----   1 root nut   2466 Aug 11 22:09 upsd.users
>> -rw-r-----   1 root nut  15479 Aug 11 22:12 upsmon.conf
>> -rw-r-----   1 root nut   3879 Feb  8  2020 upssched.conf
>>
>> --
>> Todd Benivegna // todd at benivegna.com
>> On Aug 11, 2020, 9:09 PM -0400, Manuel Wolfshant <wolfy at
nobugconsulting.ro>, wrote:
>> > On 8/12/20 3:55 AM, Todd Benivegna wrote:
>> > > Manuel,
>> > >
>> > > You are absolutely right.  I think this is all the Synology
just being
>> > > very dumb.  I guess those are my only two options at this
point.
>> > >
>> > > I have no idea on how to set up the NUT server though on one
of my
>> > > NUCs or my Pi.  Do you know any good guides out there?
>> >
>> > there are literally tons of guides. for instance:
>> >
>> >
https://www.reddit.com/r/homelab/comments/5ssb5h/ups_server_on_raspberry_pi/
>> > and scroll down to configuring, past the apt install step (which
you
>> > already did )
>> >
>> > basically all you need is to edit a few files below /etc/nut/ .
takes 5
>> > min top
>> >
>> >
>> > >   I’m guessing it’s easy enough to edit upsmon.conf on the
Synology in
>> > > order to get that to become a slave; I think would be all
that’s
>> > > required for the Synology NAS.
>> >
>> >
>> > > Yeah I saw that.  Makes no sense.  I can Wireshark it,
however even if
>> > > I find the cause, I’d still have to go to Synology for
resolution,
>> > > which I doubt will ever get fixed.  Even if they do, I doubt
it’d be
>> > > any time soon.  Maybe that’s me being pessimistic, I don’t
know, but I
>> > > just don’t if I have the time or energy for all that!
>> > >
>> > no need to wireshark any more, we already know that it sends bogus
FSD
>> >
>> >
>> >
>> > _______________________________________________
>> > Nut-upsuser mailing list
>> > Nut-upsuser at alioth-lists.debian.net
>> >
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200812/7c8d304f/attachment-0003.html>

On 8/12/20 8:10 AM, Tim Dawson wrote:
> For directory permissions, the "x" priv determines if you can
access
> the directory, so going from 555 (r-x,r-x,r-x) to 640 (rw-,r--,---) 
> pretty much locks out access to the dir. Myself, I'd go back to 555. 
> 640 essentially locks the group "nut" out . . .
>
> - Tim
At least if on Todd's system the access rights are identical to mine, 
no, nut is just fine with 640 because the whole directory is owned by 
group nut. And nut ( or anyone else but root, actually ) has no business 
in modifying the config files.  Actually I'd be quite concerned if user 
"nut" wanted to modify its own config.

Logs are written somewhere else.

The only reason NUT may whant to modify it's config is NUT-CGI and may be
Synology GUI.
Even then default install on my Synology makes no trubble.

555 gives no write access to the dir, and the files are covered by their 
own perms, so I fail to see any relevance to your comment - sorry . . .

640 is decent for files, not so much for directories - as noted, the 
fields mean different things on dirs . . .

 From the man pages:

        The  letters  rwxXst select file mode bits for the affected 
users: read
        (r), write (w), execute (or search for directories) (x), 
execute/search
        only  if  the file is a directory or already has execute 
permission for
        some user (X), set user or group ID on execution (s), 
restricted  dele-

So while direct access may well still work, there is *ZERO* liability in 
allowing search, and frankly, I don't know what tests NUT may be doing 
to find it's files pre-open, and some may block without that attribute . 
. .

For what it's worth . . .

- Tim


On 08/12/2020 03:08 AM, Manuel Wolfshant wrote:
> On 8/12/20 8:10 AM, Tim Dawson wrote:
>> For directory permissions, the "x" priv determines if you can
access
>> the directory, so going from 555 (r-x,r-x,r-x) to 640 (rw-,r--,---) 
>> pretty much locks out access to the dir. Myself, I'd go back to
555.
>> 640 essentially locks the group "nut" out . . .
>>
>> - Tim
>
> At least if on Todd's system the access rights are identical to mine, 
> no, nut is just fine with 640 because the whole directory is owned by 
> group nut. And nut ( or anyone else but root, actually ) has no 
> business in modifying the config files.  Actually I'd be quite 
> concerned if user "nut" wanted to modify its own config.
>
> Logs are written somewhere else.
>
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-- 
Tim Dawson

972-567-9360