NUT package (2.8.0 and below)

newberger

Thanks for clarifying the remote/local definitions.

Very disappointing, but not horribly surprising. Synology does something equally stupid by hardcoding "monuser" and "secret".

I found some additional information that states you can change the username/password by editing /etc/config/ups/upsmon.conf on the QNAP (it was on my system volume).

In that file I found:


RUN_AS_USER admin
MONITOR qnapups@192.168.34.5 1 admin 123456 slave
...

For now I haven't changed the configuration. Would I need to change "admin" in both lines? Since the RUN_AS_USER parameter is <userid>and the MONITOR parameter is <username>, it's unclear. Further, it appears that changing <userid>in RUN_AS_USER might cause some permission issues?</userid></username></userid>

dennypage

@newberger:

I found some additional information that states you can change the username/password by editing /etc/config/ups/upsmon.conf on the QNAP (it was on my system volume).

Yes, you can do the same thing with the Synology. The problem is that it the Synology (and presumably QNAP) will reset every time you touch the service or perform an OS update.

@newberger:

In that file I found:
RUN_AS_USER admin
MONITOR qnapups@192.168.34.5 1 admin 123456 slave
...
For now I haven't changed the configuration. Would I need to change "admin" in both lines? Since the RUN_AS_USER parameter is <userid>and the MONITOR parameter is <username>, it's unclear. Further, it appears that changing <userid>in RUN_AS_USER might cause some permission issues?</userid></username></userid>

It is only the MONITOR line that you would change. The RUN_AS_USER is a directive saying under what username the nut services should run on the local (QNAP) machine.

Given that changes will end up being sporadically reset by the NAS, I would leave the username/password alone and live with it. If you are feeling adventuresome, you could file a security bug report with QNAP.

newberger

@dennypage:

Given that changes will end up being sporadically reset by the NAS, I would leave the username/password alone and live with it.

Good to know and I'll leave as is. Thanks for all of your help!

Maxburn

Is this the right package to monitor a UPS and shut down pfsense if I get a low battery?

I'm poking around and tried to add a remote snmp UPS but there doesn't seem to be a field to specify a community string. I don't run public for obvious reasons.

Edit; it's a Liebert GXT. My synology had no issue monitoring it and doing shutdown. Looked through the MAN pages linked under advanced config and didn't see anything mentioning community strings.

Edit2; added public in the UPS and it worked, where can I specify that in this package?

Also where do I specify shutdown settings?

dennypage

@Maxburn:

Is this the right package to monitor a UPS and shut down pfsense if I get a low battery?

I'm poking around and tried to add a remote snmp UPS but there doesn't seem to be a field to specify a community string. I don't run public for obvious reasons.

Yes, this is the right package.

As to the community string, if you are using the default ("public"), then you don't need to specify a community string. If you are using something other than the default, you would specify the community in the Extra Arguments to driver section. See the snmp-ups man page for more information on snmp driver arguments.

As an aside, a unique community name can be marginally effective at preventing accidents, but it offers nothing in the way of actual security because the name is sent across the network in clear text. While it used to be considered an important best practice to change the community name with v1/v2, many people don't bother any more. For actual security you need to use v3, at which point it doesn't matter if the community name is public. Even when using a unique community name for read/write with v1/v2/v3, it is common to leave public in place as an read only v1 community for monitoring things such as UPSs.

pablo_deskObar

Hello,

I have connected my apc ups to netgate pfsense and setup nut.

I have it as server, and connected my synology NAS to it.

These devices shutdown after the limit imposed.

Here,

i have battery low warning - 90
low battery - 80

(i like to preserve battery XD)

The ISSUE is my APC is not shutting down after pfsense and synology shuts off. It keeps running till battery becomes 0.

Tried changing offdelay (ups.shutdown.delay from 20 to 30) no success.

Can i use shutdown timer to make the ups shut down after say like 5 mins? (all my devices shutdown before that), and when power returns will ups turn back on automatically?

Any help appreciated. :)

dennypage

@pablo_deskObar:

The ISSUE is my APC is not shutting down after pfsense and synology shuts off. It keeps running till battery becomes 0.

See post #1, version 2.7.4_6 which addresses this issue.

pablo_deskObar

@dennypage:

@pablo_deskObar:

The ISSUE is my APC is not shutting down after pfsense and synology shuts off. It keeps running till battery becomes 0.

See post #1, version 2.7.4_6 which addresses this issue.

Didnt see that :) Also, will the ups power back on automatically after mains is restored after a power kill?

dennypage

@pablo_deskObar:

Also, will the ups power back on automatically after mains is restored after a power kill?

It should. Most all UPSs are designed to.

q54e3w

My pfsense server is running NUT package and I also have a separate ESXi host with NUT installed. I want to shut down the VMs and the ESXI host before pfsense shutdowns to ensure network services remain up to prevent problems closing down the VMs cleanly. How can I delay pfsense powering down until esxi has completed shutting down?
I have a APC SMX UPS attached via AP9631 network card.

dennypage

@q54e3w:

How can I delay pfsense powering down until esxi has completed shutting down?

The HOSTSYNC variable controls how long the master will wait for slaves to initiate their shutdown. You can find information on this in the ups.conf man page.

q54e3w

Thank you - I'll give it a try.

I've noticed the following errors appearing in my logs, any idea why this would be?


...
Feb 18 11:01:52	snmp-ups	44002	dstate_setflags: base variable (battery.runtime.low) is immutable
Feb 18 11:01:20	snmp-ups	44002	dstate_setflags: base variable (battery.runtime.low) is immutable
Feb 18 11:00:48	snmp-ups	44002	dstate_setflags: base variable (battery.runtime.low) is immutable
...

I have the following code

extra arguments


ignorelb
override.battery.charge.warning = 50
override.battery.charge.low = 30
override.battery.runtime.low = 1200

upsmon.conf


HOSTSYNC 600

upsd.conf


LISTEN 192.168.10.1

upsd.users


[remoteuser]
password = mypassword
upsmon slave

the settings appear to be being applied correctly….


upsc ups@localhost
ambient.1.humidity.alarm.high: 60.00
ambient.1.humidity.alarm.low: 30.00
ambient.1.temperature.alarm.high: 40.00
ambient.1.temperature.alarm.low: 10.00
ambient.humidity: 39.00
ambient.temperature: 15.0
battery.charge: 100.00
battery.charge.low: 30
battery.charge.warning: 50
battery.date: 11/15/2017
battery.packs: 1.00
battery.runtime: 4428.00
battery.runtime.low: 1200
battery.voltage: 54.20
device.mfr: APC
device.model: Smart-UPS X 1500
device.type: ups
driver.flag.ignorelb: enabled
driver.name: snmp-ups
driver.parameter.pollinterval: 2
driver.parameter.port: 192.168.10.50
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: apcc MIB 1.2
driver.version.internal: 0.97
input.frequency: 60.00
input.sensitivity: high
input.transfer.high: 127
input.transfer.low: 106
input.transfer.reason: selfTest
input.voltage: 122.20
input.voltage.maximum: 123.20
input.voltage.minimum: 121.30
output.current: 4.80
output.frequency: 60.00
output.voltage: 122.20
output.voltage.nominal: 120
ups.delay.shutdown: 20
ups.delay.start: 10
ups.firmware: UPS 09.1 (ID20)
ups.id: UPS
ups.load: 48.30
ups.mfr: APC
ups.mfr.date: 06/30/2012
ups.model: Smart-UPS X 1500
ups.status: OL
ups.temperature: 18.60
ups.test.date: 02/14/2018
ups.test.result: Ok

dennypage

@q54e3w:

Thank you - I'll give it a try.

I've noticed the following errors appearing in my logs, any idea why this would be?


...
Feb 18 11:01:52	snmp-ups	44002	dstate_setflags: base variable (battery.runtime.low) is immutable
Feb 18 11:01:20	snmp-ups	44002	dstate_setflags: base variable (battery.runtime.low) is immutable
Feb 18 11:00:48	snmp-ups	44002	dstate_setflags: base variable (battery.runtime.low) is immutable
...

I believe it means that the variable is marked read-only in the SNMP MIB. For more information on this, I would suggest checking the nut users list.

FWIW, if it were me I would just remove the setting of runtime and use charge %. You don’t need both.

spambait

pfsense 2.4.2-RELEASE-p1 (amd64)
nut 2.7.4_5

Polling an APC AP9631 on the LAN via SNMP.

When I reboot the appliance, UPS status shows as down. Log has a bunch of these:

Feb 19 21:40:27 upsmon 66529 Poll UPS [office-UPS] failed - Driver not connected
Feb 19 21:42:22 upsmon 67668 Startup successful
Feb 19 21:42:23 upsd 68233 listening on ::1 port 3493
Feb 19 21:42:23 upsd 68233 listening on 127.0.0.1 port 3493
Feb 19 21:42:23 upsd 68233 Can't connect to UPS [office-UPS] (snmp-ups-office-UPS): No such file or directory
Feb 19 21:42:23 upsd 68498 Startup successful
Feb 19 21:42:24 snmp-ups 68710 Startup successful

Now when I go to restart the service via the GUI In Services -> UPS, it starts up perfectly right away.

apcupsd was installed but I removed it when switching to NUT.

I tried using snmp v1 instead of v3 thinking I screwed up my v3 credentials but that doesn't seem to be the issue. Even with snmpv1 it wont come up after a reboot until I manually intervene.

I tried some of the retry and delay parameters in the additional parameters for ups.conf but they also didn't help with this


maxretry=3
retrydelay=10
pollinterval=5
snmp_retries=10
snmp_timeout=2
pollfreq=10

dennypage

Please give the following a try:

Get rid of pollfreq and pollinterval.

Set these variables in the Extra Arguments to driver section:


snmp_timeout=2
snmp_retries=10

Set these variables in the Advanced section for ups.conf:


retrydelay=30
maxretry=20

Now reboot the box. When the box comes up, go to the UPS status page. [Do not attempt to start the service manually] If the UPS shows as needing attention, wait for the page to refresh automatically. If it doesn't auto refresh, after a couple minutes refresh the page manually. Does the UPS show as running? Or is it still down?

spambait

@dennypage:

Please give the following a try:

Get rid of pollfreq and pollinterval.

Set these variables in the Extra Arguments to driver section:
snmp_timeout=2
snmp_retries=10
Set these variables in the Advanced section for ups.conf:
retrydelay=30
maxretry=20
Now reboot the box. When the box comes up, go to the UPS status page. [Do not attempt to start the service manually] If the UPS shows as needing attention, wait for the page to refresh automatically. If it doesn't auto refresh, after a couple minutes refresh the page manually. Does the UPS show as running? Or is it still down?

These settings work perfectly!

I am now back on SNMPv3 and NUT is performing as expected, across reboots and all. Thank you!

dennypage

That's good news. Now that it's working, you can probably tune the variables down quite a bit. In particular, the settings in Extra Arguments can likely be returned to their default values of 1 & 5. Or simply deleted.

spambait

@dennypage:

That's good news. Now that it's working, you can probably tune the variables down quite a bit. In particular, the settings in Extra Arguments can likely be returned to their default values of 1 & 5. Or simply deleted.

I think actually found a bug (with the AP9631, fw 6.5.0).

I just deployed a second AP9631 out of the box. Factory reset, flashed 6.5.0, factory reset again, set up SNMPv3 and had the same issues I described before where NUT cannot communicate.

I have now noticed that if I have SNMPv1 DISABLED, NUT will fail to connect via SNMPv3 no matter what extra settings I provide. Simply turning on SNMPv1 in the AP9631 (fw 6.5.0) immediately lets them communicate. Very strange. Further testing is needed.

I have replicated this on the previous installation where I can break the SNMPv3 communication between NUT and the AP9631 by disabling SNMPv1, don't even need to reboot.

this_fixes_it.JPG_thumb

this_breaks_it.JPG_thumb

dennypage

@spambait:

I just deployed a second AP9631 out of the box. Factory reset, flashed 6.5.0, factory reset again, set up SNMPv3 and had the same issues I described before where NUT cannot communicate.

I have now noticed that if I have SNMPv1 DISABLED, NUT will fail to connect via SNMPv3 no matter what extra settings I provide. Simply turning on SNMPv1 in the AP9631 (fw 6.5.0) immediately lets them communicate. Very strange. Further testing is needed.

I have replicated this on the previous installation where I can break the SNMPv3 communication between NUT and the AP9631 by disabling SNMPv1, don't even need to reboot.

It sounds like SNMPv3 may not be properly configured/functioning in NUT. Can you post the contents of /usr/local/etc/nut/ups.conf please?

spambait

@dennypage:

It sounds like SNMPv3 may not be properly configured/functioning in NUT. Can you post the contents of /usr/local/etc/nut/ups.conf please?

I am going to find an SNMPv3 client and try replicate this in a moment. If a different v3 client fails in the same way the issue is with AP9631.

If it doesn't then there may indeed be a NUT issue. Maybe it has some routine to check SNMPv1 availability before anything else, even if only SNMPv3 is needed.

I realize the credentials are in there but it's a sandbox setup so this is not really a concern. My full, unedited /usr/local/etc/nut/ups.conf:

retrydelay=30
maxretry=20
snmp_version=v3
privProtocol=AES
authProtocol=SHA
secName=pfSense
authPassword=VtwHzSj6XQlmp9OFFa28NJcUL93qq5zZ4
privPassword=TpWsICXWm4CeKtwUehtvcBpDnBW0KZCC

[S10-AP9631]
driver=snmp-ups
port=172.16.10.5
snmp_timeout=2
snmp_retries=10