NUT (Network UPS Tool) doesnt start up on reboot

[hansdampf]

I am using the apcupsd for the UPS which is connected via USB to OPNsense. I have configured the NUT service to offer the UPS to my NAS (Xigmanas), which is using NUT as UPS-tool.
So far, the service works as expected, both OPNsense and Xigmanas show the UPS as living and working. But when i restart OPNsense the NUT service is the only service which doesnt start up, even when i wait more time for the system to get settled.
Eventually i am missing something to get the NUT start up?

Logs show this:

entry after starting NUT manually:
2024-08-08T16:02:07   Warning   upsd   /usr/local/etc/nut/upsd.users is world readable   
2024-08-08T16:02:07   Warning   upsd   /usr/local/etc/nut/upsd.conf is world readable

Logs after reboot show many entries of this:   
2024-08-08T16:02:02   Error   upsmon   UPS [usv]: connect failed: Connection failure: Connection refused

[doktornotor]

I must be missing somethíng. Why would you install both apcupsd and nut to handle the same UPS? Obviously this is expected to cause issues...

The below setup is what we have been using for the same purpose for ages without any issues and conflicts...

[hansdampf]

Thanks a lot for your advise!
I tried your settings but was out of luck first, but finally got it: I had to enter the real IP of my opnsense in NUT -> general information and usbhid as the local device.
The port forwarding wasnt necessary (both devices are in the same lan-segment). Or am i missing again something?
So now i see the UPS-status on OPNsense and my NAS is showing the status of the remote UPS too.

The only caveat now is that we dont have a NUT-widget for the dashboard...

[doktornotor]

The port forwarding wasnt necessary (both devices are in the same lan-segment). Or am i missing again something?

We simply do not want it accessible from anything but the intended remote clients that need to use the UPS. Listening only on localhost and doing the port forwards, you can make sure only those specified IPs have access.

[franco]

Golden advice right there. Plus you can make your port forward as broad as you want. The added benefit of a loopback address is that it's always there, too, so you never lose connectivity to an address that was delivered via DHCP but then required to be hardcoded and then it fails when the DHCP address changes...


Cheers,
Franco

[hansdampf]

OK, again a very good point. So now i think i got the final idea. Again learned a lot!
Thanks again for your fast help and such a good lession about setting up things easy and secure to external changes (DHCP-changes in our case)