[Nut-upsuser] Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)
todd at benivegna.com
Wed Aug 12 22:32:53 BST 2020
> 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...
Do you think it may that line upsd.conf like Charles mentioned?
Thanks everyone for all the help!!!
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),
> 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
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser