NUT package (2.8.0 and below)

dennypage

Hey dtallon13,

Have you rebooted pfSense since you first installed NUT? If you have not, there is a USB permissions problem that may be tripping you up. Just leave the UPS connected via USB, and reboot the firewall.

If a reboot doesn't address the issue, then check the system log (Status / System Logs / System / General) for messages matching 'nut' or 'ups' and report back what you find please.

w0w

Where can I find example for power kill function?

dennypage

@w0w:

Where can I find example for power kill function?

There isn't anything you will have to set up or code. It will be automatic with the new version of the NUT package and the new version of pfSense.

digitalgimpus

Anyone know how to get NUT to accept incoming connections?

I tried adding:

LISTEN 192.168.1.5

in upsd.conf, however that seems to cause nut to freeze and any page in the webui with NUT goes nuts (pun intended). I had to restore from a backup config to get things working again.

dennypage

@digitalgimpus:

Anyone know how to get NUT to accept incoming connections?

Covered earlier in this thread. See reply 1.

digitalgimpus

@dennypage:

Covered earlier in this thread. See reply 1.

Thanks! I missed that.

dtallon13

@dennypage:

Hey dtallon13,

Have you rebooted pfSense since you first installed NUT? If you have not, there is a USB permissions problem that may be tripping you up. Just leave the UPS connected via USB, and reboot the firewall.

If a reboot doesn't address the issue, then check the system log (Status / System Logs / System / General) for messages matching 'nut' or 'ups' and report back what you find please.

Reboot worked like magic. Thanks!

DownloadDeviant

Hello,

My NUT package displays as 2.7.4_5.
This page says there is a version 2.7.4_6 but I am offered no option to update.
What am I doing wrong?

Recent changes I've made -
I was running pfSense 2.3.4x. I upgraded to 2.4.2, saved a config after checking everything was running properly.
I then did a fresh install of 2.4.2 (went with ZFS this time), then upgraded to p1 and restored from the backup config.xml.

Everything went as smooth as possible. Not a single hiccup. UPS service is accurate and working.

*IF it matters, my pfSense box is a slave to my Synology DS415+ for UPS.

Thanks for any advice.

dennypage

@DownloadDeviant:

My NUT package displays as 2.7.4_5. This page says there is a version 2.7.4_6 but I am offered no option to update.

NUT package version 2.7.4_6 isn't offered for pfSense 2.4.2 because the changes in 2.7.4_6 require pfSense 2.4.3 or later to function. Currently, you will only see 2.7.4_6 if you are running a pfSense development snapshot.

DownloadDeviant

Ahhh, OK. Whew! I was thinking I borked my fresh install or something didn't translate from the backup config.
Thanks for the reply. I'll sleep better tonight. ;D

dennypage

@DownloadDeviant:

Thanks for the reply. I'll sleep better tonight. ;D

LOL. You're welcome.

newberger

Hi New pfSense user. I appreciate your work on NUT, it's the first package I have installed.

I'm running pfSense on Netgate SG-3100, which I have as UPS Master. I have a QNAP T-882 as slave.

UPS is CyberPower OR700 and is connected to SG-3100 via USB.

I have configured the psSense as described in post #2, in the pfSense: Services/UPS and the UPS shows up in properly in pfSense.

Here's how I configured the NAT rule. I am still working up the learning curve on Firewall in pfSense, so please let me know if you see any issues.

I did not have to setup the remote access user as described in post 2. In post #64, there are instructions to place directives in the advanced section for ups.conf if you want to override the shutdown levels:

ignorelb
override.battery.charge.low = 50
override.battery.runtime.low = 600

However, later posts (e.g. #85) say that UPS specific arguments should be entered in the section above that says "Extra Arguments to driver".

So I added like this:

After setting the Port Forward, the QNAP can now see the UPS:

Any feedback is appreciated and, hopefully this will be helpful for other new users.

dennypage

@newberger:

I did not have to setup the remote access user as described in post 2.

You will want to set up a user for remote access as discussed in reply #2. The monuser in the config is intended for local use only. It is automatically generated based on a random number for security, and will change from time to time. If you set up your own user, the name and password will be under your control and will not change.

@newberger:

In post #64, there are instructions to place directives in the advanced section for ups.conf if you want to override the shutdown levels:
ignorelb
override.battery.charge.low = 50
override.battery.runtime.low = 600
However, later posts (e.g. #85) say that UPS specific arguments should be entered in the section above that says "Extra Arguments to driver".

Reply #64 discusses pollinterval which does belong in the global section for ups.conf. The battery parameters are UPS specific, and belong in the driver section as noted in #85 and elsewhere. Your post above shows it in the correct section.

newberger

Thanks for the reply!

@dennypage:

You will want to set up a user for remote access as discussed in reply #2. The monuser in the config is intended for local use only. It is automatically generated based on a random number for security, and will change from time to time.

For 'remote access', it sounds like you mean any device other than the pfSense Master? So the QNAP on the same LAN is considered remote? Sorry, it's not the context I'm used to for local/remote.

@dennypage:

If you set up your own user, the name and password will be under your control and will not change.

So, I in adding the QNAP as a slave/user, I have read here (and elsewhere) that it only will accept admin/123456:

dennypage

@newberger:

For 'remote access', it sounds like you mean any device other than the pfSense Master? So the QNAP on the same LAN is considered remote? Sorry, it's not the context I'm used to for local/remote.

Remote access in this context refers to anything not running locally on the box that the UPS is attached to.

@newberger:

So, I in adding the QNAP as a slave/user, I have read here (and elsewhere) that it only will accept admin/123456:

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

newberger

Thanks for clarifying the remote/local definitions.

@dennypage:

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.