-
Nope, no IPv6. I made sure to disable it wherever I can.
-
@kevindd992002 I think rc.newwanip* can be invoked in several circumstances. Look in the system log for messages immediately preceding the Restarting/Starting all packages message.
-
@dennypage said in NUT package:
@kevindd992002 I think rc.newwanip* can be invoked in several circumstances. Look in the system log for messages immediately preceding the Restarting/Starting all packages message.
May 10 13:08:43 php-fpm 14757 /rc.newwanip: Resyncing OpenVPN instances for interface CCTV. May 10 13:08:43 php-fpm 14757 /rc.newwanip: Creating rrd update script May 10 13:08:43 upsd 45275 User local-monitor@::1 logged into UPS [ups] May 10 13:08:43 php-fpm 378 /rc.start_packages: Restarting/Starting all packages. May 10 13:08:43 radiusd 48725 Signalled to terminate May 10 13:08:43 radiusd 48725 Exiting normally May 10 13:08:43 php-fpm 378 /rc.start_packages: Stopping service nut May 10 13:08:43 upsmon 72305 Signal 15: exiting May 10 13:08:43 upsd 45275 User local-monitor@::1 logged out from UPS [ups] May 10 13:08:43 upsd 45275 mainloop: Interrupted system call May 10 13:08:43 upsd 45275 Signal 15: exiting May 10 13:08:43 usbhid-ups 24821 Signal 15: exiting May 10 13:08:43 php-fpm 378 /rc.start_packages: Starting service nut May 10 13:08:43 upsmon 29518 Startup successful May 10 13:08:43 php-fpm 40655 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 0.0.0.0 -> 192.168.40.1 - Restarting packages. May 10 13:08:43 check_reload_status Starting packagesYou're right. What's the best approach to solve this though? It looks like even my OPT interfaces are interpreted as WANs. All my intefaces (WAN and LAN) have static IP's, so I'm not sure why there is an IP change event there.
-
@kevindd992002 I don't believe you can prevent this from occurring. Problem is, pfSense doesn't know what each package is doing with the various interfaces or if they support dynamic discovery of interface changes (most don't). The only way for pfSense to ensure everything is functioning correctly is to restart the packages.
-
I'm seeing this in my logs
php-fpm 40655 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 82.127.34.254 -> 82.127.34.254 - Restarting packages.I was asling yself : what changed ? Why was this line triggered ?
For me, "82.127.34.254" is identical to "82.127.34.254".My WAN is using an RFC 1918 IP (DHCP using an upstream router) - the real WAN IP - 82.127.34.254 - doesn't change, but still, packages get restarted.
For longtime I really thought this was completely unnecessary, nut now I knows that that processes like unbound or openvpn don't like the fact that an interface to which they are bound, go up and down, even when the IP on that interface stays the same. -
@dennypage said in NUT package:
@kevindd992002 I don't believe you can prevent this from occurring. Problem is, pfSense doesn't know what each package is doing with the various interfaces or if they support dynamic discovery of interface changes (most don't). The only way for pfSense to ensure everything is functioning correctly is to restart the packages.
I see. Do you happen to know why the interface IP changes for no reason, in the first place?
-
@kevindd992002 In your case it looks like a change of state for OpenVPN interfaces. I'm sorry I don't know much beyond this. If you want to explore more, I'd suggest asking in the General pfSense Questions or OpenVPN groups.
-
Can I use the 2 USB ports on my XG-7100 1U appliance to monitor my APC Smart-UPS 1500 with this package?
-
@bazzacad If the ups has a usb interface, I expect nut with the usbhid driver would work. You can always check the nut hardware compatibility matrix to confirm. Have you tried it and encountered a problem?
-
@dennypage said in NUT package:
@kevindd992002 In your case it looks like a change of state for OpenVPN interfaces. I'm sorry I don't know much beyond this. If you want to explore more, I'd suggest asking in the General pfSense Questions or OpenVPN groups.
Ok, thanks.
I also have an error with my slave client but I'm not sure if it's OT here or not. Basically, my slave monitor client is a Debian box and it works just fine connecting to this pfsense master. But during boot time I get the same exact error described here. So what does the nut-driver.service do? Since the nut package here only runs as monitor (not server), do I need that service active?
-
@kevindd992002 I'm an RC guy. I don't use systemd.
That said, the link you posted is about a problem with usbhid-ups not being able to find the local ups on the serial bus. This is unrelated to use of upsmon to remotely monitor a ups.
If you are seeing anything from upsdrvctl, it means that the system is misconfigured. In a remote monitor case, only upsmon would be started. The local services, upsdrvctl (usbhid-ups) and upsd are not used and should not be started.
Please don't ask me how to configure systemd. I simply don't know.
-
@dennypage said in NUT package:
@kevindd992002 I'm an RC guy. I don't use systemd.
That said, the link you posted is about a problem with usbhid-ups not being able to find the local ups on the serial bus. This is unrelated to use of upsmon to remotely monitor a ups.
If you are seeing anything from upsdrvctl, it means that the system is misconfigured. In a remote monitor case, only upsmon would be started. The local services, upsdrvctl (usbhid-ups) and upsd are not used and should not be started.
Please don't ask me how to configure systemd. I simply don't know.
Lol, ok. Yeah, that's what I figured. I'm only using the nut package their as a monitor so I don't think the other services should be started at all.
-
@dennypage Everything worked perfectly with my XG-7100 1U and APC Smart-UPS 1500 using the usbhid driver. Is the package able to monitor 2 UPSs? Both APC Smart-UPS 1500. I didn't try that yet?
-
@bazzacad You mean a pfSense system with redundant power supplies, each with a separate ups? NUT itself is capable of this, but the NUT package does not provide any configuration support for it.
-
Just wanted to say thanks for this package. I am now using pfSense to monitor my CyberPower 1500 over USB, while my two unraid servers are network slave clients. Worked great after adding the NAT rule in the OP :-)
-
@cybrnook you are most welcome.
It’s really nice when people say thank you.
-
@dennypage said in NUT package:
@cybrnook you are most welcome.
It’s really nice when people say thank you.
Absolutely! It's my pleasure. Now just to figure out how to add multiple source IP's to the NAT rule, since I have 3 x clients I want to be able to phone home. Maybe it's just as simple as creating one NAT rule per IP :-) And see if you baked in "monuser" for Synology by default :-) since that will be my third.
EDIT: Synology was no problem. Just had to add monuser to the upsd.users with secret, and rename the UPS to "ups" in pfsense. Redid my Unraid systems with the same info, and it's all back online
-
Hi @dennypage - a big thank you from me as well! I came across a blog post today that detailed installing the NUT package on pfSense. Looking at the NUT compatibility list I saw that the the CyberPower UPS that I am using is actually supported. So I went ahead and hooked up the USB connection from the UPS to the firewall, installed the NUT package, and got everything setup and working inside pfSense. After that I also configured my Proxmox box and Synology NAS as slaves (thanks to everyone for all the great tips and advice in this thread!). Everything is working great so far. I went over two years with this same hardware not realizing that I could actually setup and utilize NUT -- very happy I found about the project today and the pfSense package.
I do have one basic quick question for everyone: When setting up NUT (e.g. slaves and on the master) how is the UPS critical battery threshold or shutdown time to determined (i.e. when connected devices are given the signal to shut down)? If this parameter adjustable in the configuration files (e.g. on the master) or is there a default value that's used? In other words, with the default out of the box NUT setup and configuration, will connected devices be given plenty of time to shut down? Thanks in advance for your help, I really appreciate it.
-
@tman222 By default, the level at which shutdown will occur is under control of the ups. The ups sends a "low battery" signal, and nut initiates a shutdown.
Generally the low battery signal is sufficient for single host systems, however if you find the ups runs out of battery before shutdown completes you can override the behavior. See the nut variables "battery.charge.low"
and "battery.runtime.low".Important note... some slaves, particularly Synology, take a long time to shutdown. After changing the runtime values, you will want to increase the "HOSTSYNC" variable. The default of 15 is far too short to allow a Synology to complete a shutdown.
Here is what I use on my server:
[Extra Arguments to driver]
override.battery.charge.low = 20
override.battery.runtime.low = 300[Additional configuration lines for upsmon.conf]
HOSTSYNC 120 -
@dennypage - thanks a bunch for this additional information. I was able to find a reference to the variables you mentioned and read up a bit:
https://networkupstools.org/docs/user-manual.chunked/apcs01.html
I had a one quick follow up question: Regarding the two variables you overrode (battery.charge.low and battery.runtime.low): Is it whichever of the two occurs first that then triggers the LB state and causes NUT to issues the shutdown signal? That is to say, in your case, when the battery drops to 20% charge OR has 300 seconds of run time remaining, the LB state is triggered and NUT begins shutdown process begins?
Thanks again for the help and clarification, I really appreciate it.
