NUT package (2.8.0 and below)
-
Well me too. Installed the new package and its gone. Maybe you should pull this update till this problem is fixed…
-
Maybe you should pull this update till this problem is fixed…
I don't have access to pull the package from the servers.
It's correct in the development branch of the repo, which is why beta works. There appears to have been a merge problem in moving between the development branch and the 2_3_2 branch which resulted in a duplicate line in the xml file. I don't have access to modify the 2_3_2 branch, or update the package servers. If I did, I would fix the issue.
I have an email in, but don't know if anyone will be available over the weekend to update the package servers.
-
Maybe you should pull this update till this problem is fixed…
I don't have access to pull the package from the servers.
It's correct in the development branch of the repo, which is why beta works. There appears to have been a merge problem in moving between the development branch and the 2_3_2 branch which resulted in a duplicate line in the xml file. I don't have access to modify the 2_3_2 branch, or update the package servers. If I did, I would fix the issue.
I have an email in, but don't know if anyone will be available over the weekend to update the package servers.
Gotcha, hopefully it will get fixed shortly..
-
It sure is flooding my logs now though:
Aug 6 14:39:40 kernel uhid0: <cps 0="" 1="" or1500lcdrm1u,="" class="" 0,="" rev="" 1.10="" 2.00,="" addr=""> on usbus0 Aug 6 14:39:39 kernel ugen0.2: <cps> at usbus0 Aug 6 14:39:37 kernel uhid0: at uhub1, port 5, addr 1 (disconnected) Aug 6 14:39:37 kernel ugen0.2: <cps> at usbus0 (disconnected) Aug 6 14:39:31 kernel uhid0: <cps 0="" 1="" or1500lcdrm1u,="" class="" 0,="" rev="" 1.10="" 2.00,="" addr=""> on usbus0 Aug 6 14:39:30 kernel ugen0.2: <cps> at usbus0 Aug 6 14:39:28 kernel uhid0: at uhub1, port 5, addr 1 (disconnected) Aug 6 14:39:28 kernel ugen0.2: <cps> at usbus0 (disconnected) Aug 6 14:39:21 kernel uhid0: <cps 0="" 1="" or1500lcdrm1u,="" class="" 0,="" rev="" 1.10="" 2.00,="" addr=""> on usbus0 Aug 6 14:39:21 kernel ugen0.2: <cps> at usbus0 Aug 6 14:39:18 kernel uhid0: at uhub1, port 5, addr 1 (disconnected) Aug 6 14:39:18 kernel ugen0.2: <cps> at usbus0 (disconnected) Aug 6 14:39:12 kernel uhid0: <cps 0="" 1="" or1500lcdrm1u,="" class="" 0,="" rev="" 1.10="" 2.00,="" addr=""> on usbus0</cps></cps></cps></cps></cps></cps></cps></cps></cps></cps>
on and on…
-
If you are comfortable with the command line, you can fully delete the package with the following command:
pkg delete pfSense-pkg-nut
If you need a functioning package right away, you can update the package using the beta switch switch as w0w describes in the beta thread, or you can PM me with an email address and I will send you a package which is functionally the same as the release version.
-
Well got this result, but it has disappeared off the Installed Packages list. However my logs are still being flooded…
[2.3.2-RELEASE][xxxx@xxxxx.lan]/root: pkg delete pfSense-pkg-nut Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: pfSense-pkg-nut-2.7.4_1 Number of packages to be removed: 1 Proceed with deinstalling packages? [y/N]: y [1/1] Deinstalling pfSense-pkg-nut-2.7.4_1... The nut package is not installed. [1/1] Deleting files for pfSense-pkg-nut-2.7.4_1: 100%nut-2.7.4_1: 0% The nut package is not installed.
-
OK I did the install from the development branch and it still didn't show up afterwards. So I uninstalled and switched back to Stable.
I'll be waiting for the update/fix to show in the Stable…
-
Are you sure that you are looked for "UPS" in Services menu instead of "NUT"?
Just because "development trick" still working for me on VM and production.
-
@w0w:
Are you sure that you are looked for "UPS" in Services menu instead of "NUT"?
Just because "development trick" still working for me on VM and production.
Ah, there it is. See it now, thanks…
-
The repo issue has been fixed. The package version has been updated to 2.7.4_2.
-
I can confirm it's working with apcupsd as a remote host. Thanks Dennypage !
-
Confirmed here as well. Thanks!
-
Confirmed working, thanks.
-
The repo issue has been fixed. The package version has been updated to 2.7.4_2.
Thank you for the fix! Looks good!
-th3r3isnospoon
-
I have a new APC UPS (BN1080G) which only has a serial data port on the back but it came with a serial-to-USB cable. I already tried to use the default USB driver via the UPS service settings but it couldn't connect to the UPS. From what I read (http://www.freebsddiary.org/apcupsd.php) in order for the serial-to-USB connection to typically work you'll need to also be running the apcupsd daemon. "apcupsd" is listed as a remote connection option in the UPS services settings, but I would like to run it local to the firewall if possible.
There isn't a PFSense plugin for this yet but there is a BSD port for it (https://www.freshports.org/sysutils/apcupsd/).
Unfortunately it doesn't appear to be listed as an available package in the latest stable PFSense release's core package repository.
2.3.2-RELEASE (amd64)
built on Tue Jul 19 12:44:43 CDT 2016
FreeBSD 10.3-RELEASE-p5I have another FreeBSD machine internally that I can probably run apcupsd on and then have its port available for PFSense to use in the meantime.
Any advice?
Thanks
-
First, I want to thank the developers for their work in this open source project :)
I can confirm that the new package works with EATON Protection Station 800. But the E-mails notification option does not work, I have this error in the system log:php-cgi: nut_email.php: Could not send the message to email@example.com -- Error: could not start TLS connection encryption protocol
.
The E-mail notifications works well if I Test SMTP Settings under System -> Advanced -> Notifications.
Thanks (and sorry for my bad English). -
I have a new APC UPS (BN1080G) which only has a serial data port on the back but it came with a serial-to-USB cable.
According to APC documentation it's a USB port. A new model UPS with a real serial port is pretty rare these days.
According to the NUT HCL, the default values should support this UPS. Use "Local USB" for UPS Type and "usbhid" for the driver.
-
@afa:
But the E-mails notification option does not work, I have this error in the system log:
php-cgi: nut_email.php: Could not send the message to email@example.com -- Error: could not start TLS connection encryption protocol
.
The E-mail notifications works well if I Test SMTP Settings under System -> Advanced -> Notifications.NUT invokes a script to send the email. Unfortunately, SSL is not available when PHP is invoked from a script. This is a known issue with pfSense. It's considered a bug, but no one has tracked it down yet.
It's on my list when time permits.
-
@afa:
But the E-mails notification option does not work, I have this error in the system log:
php-cgi: nut_email.php: Could not send the message to email@example.com -- Error: could not start TLS connection encryption protocol
.
The E-mail notifications works well if I Test SMTP Settings under System -> Advanced -> Notifications.NUT invokes a script to send the email. Unfortunately, SSL is not available when PHP is invoked from a script. This is a known issue with pfSense. It's considered a bug, but no one has tracked it down yet.
I had a brief moment to take a look at this. I've narrowed it to an issue with PHP scripts invoked by users other than root. By default, upsmon runs as uucp, so it isn't able to initialize the secure connection. It's not clear what the long term solution will be, but you can work around the issue by adding the following line to upsmon.conf in the Advanced section:
RUN_AS_USER root
This will keep upsmon as root and allow secure connections from PHP.
As a security best practice it is generally recommended to run upsmon as a user other than root. However, given the closed environment nature of the firewall, I don't see an obvious security issue running upsmon as root.
-
I had a brief moment to take a look at this. I've narrowed it to an issue with PHP scripts invoked by users other than root. By default, upsmon runs as uucp, so it isn't able to initialize the secure connection. It's not clear what the long term solution will be, but you can work around the issue by adding the following line to upsmon.conf in the Advanced section:
RUN_AS_USER root
The solution works correctly, thanks dennypage!