<div dir="ltr"><div dir="ltr">On Tue, Aug 11, 2020 at 12:46 AM Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Mon, 10 Aug 2020, Todd Benivegna wrote:<br>
<br>
> synoups: <a href="https://hastebin.com/xexafofiha.bash" rel="noreferrer" target="_blank">https://hastebin.com/xexafofiha.bash</a><br>
<br>
Wow! What a mess.  It looks as if Synology wanted to write their own "NUT", but <br>
decided it would be easier to put their ideas in a script when they saw they <br>
could use upssched.conf to call it.  NUT intends such a script for timer <br>
management.  Synology use it for general system management.<br></blockquote></div><div><br></div><div>Roger's comment confirms my suspicion of NUT as provided by Synology. They make a great NAS product, but then they bolt on all manner of other things. In my opinion, best to leave the NAS as an appliance configured and managed by their GUI tools, and let it just be a NUT client rather than trying to configure it to be the NUT server. I use and find the RaspberryPi's to be very capable NUT servers with the rest of my systems (including my Synology NAS) as NUT clients. Much simpler to manage that way as you have complete control over a fairly current NUT as provided by Raspbian (a Debian derivative). The only kink I've run into is that the Synology NAS as a NUT client provides no means of changing the NUT credentials, so you have to use default credentials for NUT (another reason to make sure NUT is on a protected network).</div><div><br></div><div>--Larry</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div>Larry Fahnoe, Fahnoe Technology Consulting, fahnoe@FahnoeTech.com</div><div>           Minneapolis, Minnesota       <a href="http://www.FahnoeTech.com" target="_blank">www.FahnoeTech.com</a></div></div></div>