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

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

> If you have problems with having the NAS as master, make it a slave, and
run the
> NUT configuration of your choice in your PC/workstation.
I have done just this.  I changed the Synology to a slave and made my Raspberry
Pi master and the rest of my servers are slaves as well.  Manuel recommnded and
he is definitely right, I think that is the best way forward, especially with
your discovery as to what they’re doing to NUT on Synology.  I am having one
issue getting the nut-server to start up automatically without failing.  You
have any idea what’s going on there?
> Those LISTEN lines were appropriate pre-systemd when NUT's startup
script was launched after networking was fully enabled. I would recommend
"LISTEN 0.0.0.0 3493" instead, and use firewall rules if you are
trying to exclude an interface (which is likely not the case on a Pi).
Ok, so replace both with that or just one of the lines?  I suspected one of the
lines may be the problem because when I took out the second line, nut-server
service wouldn’t fail, but then clients couldn’t
connect.
> That is odd, indeed. And yes, it is certainly a permission issue but on
> the journal files which reside below /var/log , not on the config files
>
> Start with journactl -x as it might say more about the error. And maybe
> verify if any log file is defined by the nut-server unit.
I tried journalctl -x and got a huge list, couldn’t even find where nut-service
was in there.  I tried...

sudo journalctl -x | grep "nut-server"
sudo journalctl -x | grep “error"

And got a few interesting things, but not very descriptive...
https://hastebin.com/ikupojorav.sql

Do you think it may that line upsd.conf like Charles mentioned?

Thanks everyone for all the help!!!

Regards,

Todd

--
Todd Benivegna // todd at benivegna.com
On Aug 12, 2020, 12:44 PM -0400, Tim Dawson <tadawson at tpcsvc.com>,
wrote:
> 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
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200812/43b78ab2/attachment.html>

On Aug 12, 2020, at 5:32 PM, Todd Benivegna <todd at benivegna.com>
wrote:
> 
>> Those LISTEN lines were appropriate pre-systemd when NUT's startup
script was launched after networking was fully enabled. I would recommend
"LISTEN 0.0.0.0 3493" instead, and use firewall rules if you are
trying to exclude an interface (which is likely not the case on a Pi).
> Ok, so replace both with that or just one of the lines?  I suspected one of
the lines may be the problem because when I took out the second line, nut-server
service wouldn’t fail, but then clients couldn’t connect.
Recommend replacing both. Binding to 0.0.0.0 will allow connections to/from
127.0.0.1. The error handling is not ideal, but upsd logs messages as it parses.
You can stop the service (if systemd is still trying to restart it), and then
try "sudo upsd -D" to see what it is doing. It should respond to
Ctrl-C.

On 8/13/20 12:32 AM, Todd Benivegna wrote:
>
> And got a few interesting things, but not very descriptive...
> https://hastebin.com/ikupojorav.sql
>
Look for more details between the last 2 lines quoted below:

|proton at proton:~$ sudo journalctl -x | grep "nut-server" --
Subject: A
start job for unit nut-server.service has begun execution -- A start job 
for unit nut-server.service has begun execution. Jul 22 21:51:13 proton 
systemd[1]: nut-server.service: Succeeded. -- The unit 
nut-server.service has successfully entered the 'dead' state. |
> Do you think it may that line upsd.conf like Charles mentioned?
No, but please do follow his pieces of advice. Probably no one over here 
knows nut better than he does.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200813/8995c33c/attachment.html>