-
@kaeny123 I wasn't being mean dude. You should understand that the approach you took is considered to be inappropriate and does not incline people to help you.
-
@dennypage said in NUT package:
@kaeny123 I wasn't being mean dude. You should understand that the approach you took is considered to be inappropriate and does not incline people to help you.
How so? I am fairly new to this, maybe I don't understand the etiquette. I apologize for any rude behavior on my part, I would like to know so I dont repeat the same mistake
-
@kaeny123 Given that you are trying to hook up a UPS to a Linux system, and are trying to using SNMPv3 (!), I would have expected you to have some computer awareness. If not, there should be hundreds if not thousands of folk at Georgia Tech that would be able to help you.
That said, I'll try a simple analogy. Coming into a support forum for a firewall distribution based on FreeBSD and asking a question about the NUT package on CentOS is akin to going into a BMW forum and asking a question about tire recommendations for a Honda. It doesn't matter that both cars use tires, the question is completely out of scope for the audience.
Also, you had already asked your question upstream in the NUT users list. If the terms upstream and downstream don't make sense, ask some of the people around you.
-
@dennypage said in NUT package:
@kaeny123 Given that you are trying to hook up a UPS to a Linux system, and are trying to using SNMPv3 (!), I would have expected you to have some computer awareness. If not, there should be hundreds if not thousands of folk at Georgia Tech that would be able to help you.
That said, I'll try a simple analogy. Coming into a support forum for a firewall distribution based on FreeBSD and asking a question about the NUT package on CentOS is akin to going into a BMW forum and asking a question about tire recommendations for a Honda. It doesn't matter that both cars use tires, the question is completely out of scope for the audience.
Also, you had already asked your question upstream in the NUT users list. If the terms upstream and downstream don't make sense, ask some of the people around you.
Well, other than the blatant condescending tone, I understand what you mean. I was being modest when I said I was new to this. And it turns out my issue wasn't computer knowledge related. I should've checked the forum topic first, this just came as a result of googling.
Thank you for your replies, they were very helpful :)
-
@kaeny123 said in NUT package:
Well, other than the blatant condescending tone, I understand what you mean. I was being modest when I said I was new to this. And it turns out my issue wasn't computer knowledge related. I should've checked the forum topic first, this just came as a result of googling.
Thank you for your replies, they were very helpful :)
Dial it back son. You asked me to explain so you could avoide the same mistake in the future, and I did. Computer awareness meant understanding the difference between CentOS and a firewall distribution based on FreeBSD. This was not indented to be condescending.
-
Hello all,
Trying to get NUT working with a local-usb apc back-ups pro (on pfsense
).ugen0.2: <American Power Conversion Back-UPS RS 900G FW879.L4 .I USB FWL4> at usbus0I've configured the pfsense package gui with a random name, driver usbhid-ups and "Local USB" as type. Nothing else.
cat /usr/local/etc/nut/ups.conf [APC_Back-UPS_PRO_900] driver=usbhid-ups port=autoNothing works and I see:
Oct 19 16:33:25 upsd 15243 User local-monitor@::1 logged into UPS [APC_Back-UPS_PRO_900] Oct 19 16:33:25 upsmon 14608 Poll UPS [APC_Back-UPS_PRO_900] failed - Driver not connected Oct 19 16:33:25 upsmon 14608 Communications with UPS APC_Back-UPS_PRO_900 lost Oct 19 16:33:30 upsmon 14608 Poll UPS [APC_Back-UPS_PRO_900] failed - Driver not connected Oct 19 16:33:30 upsmon 14608 UPS APC_Back-UPS_PRO_900 is unavailable Oct 19 16:33:35 upsmon 14608 Poll UPS [APC_Back-UPS_PRO_900] failed - Driver not connectedCould someone please point me in the right direction?
(the same worked out of the box with apcupsd)Thanks
-
The messages you are looking for are those from process "usbhid-ups". You can find them by going into the system logs (Status / System Logs / System / General), selecting the funnel icon, and then inputing "usbhid-ups" in the Process field.
Perhaps to short circuit the process, have you rebooted or unplugged / replugged the UPS since you installed it? If not, it's likely a permissions problem.
-
@dennypage you are right; rebooting the device did the trick. Thanks.
-
Is there anyway to silence the NUT error reporting I'm seeing? I've tested my setup and it appears to work correctly so appears to be info rather than a warning.
<snip> Dec 31 15:15:10 snmp-ups 91308 dstate_setflags: base variable (battery.charge.low) is immutable Dec 31 15:14:38 snmp-ups 91308 dstate_setflags: base variable (battery.charge.low) is immutable Dec 31 15:14:06 snmp-ups 91308 dstate_setflags: base variable (battery.charge.low) is immutable Dec 31 15:13:34 snmp-ups 91308 dstate_setflags: base variable (battery.charge.low) is immutable and repeat.....my additional driver appear correct to me are
ignorelb override.battery.charge.low = 50thanks for any info
-
@q54e3w said in NUT package:
Is there anyway to silence the NUT error reporting I'm seeing?
To my knowledge, you cannot silence the error. You are attempting to set a variable in the UPS snmp module that you do not have permission to change (battery.charge.low).
Remove
ignorelb
override.battery.charge.low = 50from the advanced parameters.
For snmp, you generally have to set variables in the ups using either upsrw (with snmp write access) or a proprietary application. Occasionally you can also use http/https.
You can learn more in the archive of the nut users mailing list.
-
That fixed that error, thank you, I can configure those values through my Eaton web configuration page as you suggested.
I'm seeing different behavior with this Eaton 9px than my previous APC. Once the battery level falls below my predetermined level (87% for testing) the ups.status turns to OB OFF OB, ESXi shuts down VMs then itself, but pfSense doesn't ever initiate its own shut down. I have 'FINALDELAY 600' in my upsmon.conf additional parameters to give ESXi time to shutdown, however there no progress from pfSense reportingUPS UPS on battery.upsrw ups [battery.charge.low] Remaining battery level when UPS switches to LB (percent) Type: STRING Maximum length: 2 Value: 87 [outlet.desc] Outlet description Type: STRING Maximum length: 20 Value: Main Outlet [ups.delay.shutdown] Interval to wait after shutdown with delay command (seconds) Type: STRING Maximum length: 6 Value: 20 [ups.delay.start] Interval to wait before (re)starting the load (seconds) Type: STRING Maximum length: 6 Value: 30 [ups.start.auto] UPS starts when mains is (re)applied Type: ENUM Option: "yes" SELECTED Option: "no" upsc ups ambient.humidity: 47.40 ambient.temperature: 11.7 battery.charge: 70.00 battery.charge.low: 87 battery.runtime: 12652.00 battery.runtime.low: 13000.00 battery.voltage: 49.00 device.mfr: Eaton device.model: Eaton 9PX device.serial: GA18H32185 device.type: ups driver.name: snmp-ups driver.parameter.pollinterval: 2 driver.parameter.port: 192.168.10.52 driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.data: mge MIB 0.5 driver.version.internal: 0.97 input.phases: 1.00 input.transfer.reason: input voltage out of range outlet.desc: Main Outlet outlet.id: 0 output.current: 2.00 output.frequency: 60.00 output.phases: 1.00 output.voltage: 119.00 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.firmware: 01.14.4257 ups.firmware.aux: LB ups.load: 21.00 ups.mfr: Eaton ups.model: Eaton 9PX ups.serial: 111122223333 ups.start.auto: yes ups.status: OB OFF OB ups.test.result: done and passed ups.timer.reboot: -1.00 ups.timer.shutdown: -1.00 ups.timer.start: -1.00 -
@q54e3w Unless you are running NUT on pfSense as a NUT master with slaves on other systems, you should not be setting FINDELAY on pfSense. Also, 10 minutes is an incredibly long time...
I'm not very knowledgable about Eaton, but you may also need to set some variables for the snmp driver. See the snmp-ups man page for detail on what is available. Perhaps the polling frequency is too short to constantly catch a shutdown pending situation.
-
Thanks for the pointers @dennypage, my problem appears to be resolved although I still need to tweak some final timings. Sharing here for any one else who runs across this issue.
The solution was that the snmp drivers 'auto' detection mode resulted in a less than optimal mibs parameter causing improper device reporting. The Eaton manual states that the Network-MS card is compatible with following MIBs:- MIB II (RFC 1213)
- Internet Engineering Task Force (IETF) Standard UPS MIB (RFC 1628)
- EATON Pulsar MIB (ex MGE) V1.7
- EATON Powerware MIB (PowerMib)
Selecting the 'pw' mib allowed me to access the correct parameter and using a SNMP v1 write enabled passphrase allowed adjusting the shutdown parameters (although I've reverted to setting these in the UPS web UI). Adding 'overidelb' was needed to prod the correct OB/LB needed to initiative the shutdown procedure.
mibs = pw pollfreq = 15 community = private ignorelbThe 10 minute FINALDELAY I had used was because pfSense in my master node and I want pfSense to stay up whilst my ESXi hosts shutdown the various VMs to ensure routing across VLANs for storage requirements is available.
thanks again for your support and maintenance of this package.
-
@q54e3w I'm glad you got everything straightened out. And I'd like to give a big thank you for posting details on the resolution--I'm sure this will help someone in the future.
-
Hello, I'm trying to do a couple different things. But I am not sure where I can set these options in. The first thing I want to do is modify the ups.delay.shutdown from 20 to 120. The second thing, is it possible to completely disable shutting down the UPS itself? Thanks.
-
@doxymoron The power off delay, ups.delay.shutdown, is a variable stored in the ups. If it is settable in your ups, you would set this via upsrw.
As to disabling shutdown completely, it is possible, however I would strongly recommend against doing that. If you are looking to maximize your runtime, look at adjusting the battery low settings instead. But be careful of going to far... an extra minute of runtime isn't really worth the corruption risk of an ungraceful shutdown.
-
@dennypage Ok thanks, I will check if those options are available. I have 2 ESXi servers that I have with the Nut client installed and talking to the pfsense package. But when I did a test letting the battery run down I don't think the ESXi servers had enough time to shut down gracefully. Once my UPS hit the low battery threshold I set to 30%, it shut the UPS completely off 20 seconds later. I've been trying to figure out the best way to set this up, and I think I have to increase the shutdown delay. The ESXi servers only get triggered once the low battery threshold is hit I believe, then will probably take at least a minute to shutdown.
-
Ok I was able to run this command successfully: upsrw -s ups.delay.shutdown=120 -u admin -p **** CyberPower-01@localhost
OK
So am I correct that this means once my battery.charge.low is hit, it will wait 120 seconds and then issue a shutdown command? This shuts down pfsense and then the UPS itself? -
@doxymoron Unfortunately the term "shutdown" is a little overloaded. Is used to refer to initiating a shutdown of the operating system, and also to refer to sending a command to the ups to kill the mains.
When a low battery condition is determined to exist, nut initiates a shutdown of the operating system. The os shutdown can take seconds or minutes depending upon the operating system and what is running on it. As one of the final steps of the shutdown, the os calls back into nut which issues the kill command to the ups. This is where the delay described by ups.delay.shutdown comes into effect--the ups waits this amount of time before killing the mains. Usually the 20 seconds is sufficient because the os isn't doing much other than syncing disk buffers for a few seconds followed by a halt.
Compared to pfSense, ESXi can take a very long time to shut down. To get a better handle on this, you might want to consider running a nut slave on the ESXi server. Yes, surprisingly there is one available. A quick write up using FreeNAS can be found here. Using a remote client may give you a little more time and flexibility in how the ESXi shutdown works. Note that I do not have direct experience with the ESXi client and cannot answer questions about it, but there may be others here who have experience with it...
The pfSense information needed for enabling remote clients can be found in the second post of this thread.
-
Thanks so much for helping me, I understand a bit more. I do actually have the ESXi client installed that should properly shut down the host and all VMs. I think the problem I ran into was that from the time the low battery condition hit, to when the Pfsense box shutdown, and then the UPS itself shutdown, was just too fast. The ESXi server did not have time to do any of the proper shutting down before it lost power. I will test tomorrow to see if increasing the ups.delay.shutdown will help. If it delays the shutting down of the UPS, I think it should.
