[Nut-upsdev] Issue with apcupsd-ups?
Charles Lepple
clepple at gmail.com
Sun Aug 24 12:58:46 UTC 2014
On Aug 24, 2014, at 12:10 AM, Horia Georgescu <hgeorgescu at hotmail.com> wrote:
> Hello;
> I just came across NUT, testing FreeNAS/FreeBSD.
> I’m running at home a APC UPS connected to another computer, running apcupsd.
>
> I found out that NUT didn't talk by default to apcupsd, and there was a driver created relatively recently (apcupsd-ups), which filled in that gap.
>
> The version I found on my FreeBSD/FreeNAS system seems to imply that there is more to come to that driver (0.04)
We haven't really pushed for any specific versioning scheme (like semver.org) on the drivers. For reasons lost in history, skel.c starts at 0.02, and we simply increment that number in the actual driver when changes are introduced.
The apcupsd-ups driver worked for the original author, and I was using it for a while until I had to swap machines around. We only have one issue logged so far, and it is a corner case when the apcupsd host is down: https://github.com/networkupstools/nut/issues/81
> [root at freenas] ~# /usr/local/libexec/nut/apcupsd-ups
> Network UPS Tools - apcupsd network client UPS driver 0.04 (2.7.1)
>
> On the other hand, the man page, suggests the driver is fully functional:
> http://www.networkupstools.org/docs/man/apcupsd-ups.html
>
> I tried to configure it on FreeNAS to talk to the UPS master (running apcupsd) and I cannot make it work. (I have other machines running apcupsd in slave mode, and those work just fine).
>
> On FreeNAS I keep getting this error, no matter what I did with the configuration files. Here is an example:
> [root at freenas] ~# upsc apcupsd
> Error: Connection failure: Connection refused
This symptom usually indicates that upsd is not running, which is somewhat decoupled from whether or not the driver is configured properly. In the case of the apcupsd-ups driver, if the driver-to-apcupsd connection is refused, that error shows up as a "data stale" error when it gets sent through NUT upsd.
> Can someone actually clarify how NUT is supposed to be configured in the very specific case of a slave (apcupsd netclient), what configuration files (which directories – /etc , /usr/local/… are used, and what should be the content of each configuration file.
The FreeNAS build system (well, technically, the ports tree) is somewhat confusing to me, so I don't know the exact directories it ends up using. The NUT configuration files might well be in a jail or chroot. But on a stock FreeBSD box, this is what I have:
/usr/local/etc/nut/ups.conf:
[apcupsd]
driver = apcupsd-ups
port = hostname-of-apcupsd.example.org
/usr/local/etc/nut/upsd.conf:
LISTEN 0.0.0.0 # Otherwise this listens on the localhost interface only. Tune as needed.
/usr/local/etc/nut/upsd.users:
# Contents don't matter for upsc to get access, but you will eventually need an entry for upsmon if you want the FreeNAS box to shut down (unless FreeNAS provides another method).
[upsmon-master]
password = 12345
upsmon master
/etc/rc.conf:
nut_enable="YES"
nut_upsmon_enable="YES"
The FreeBSD /usr/local/etc/rc.d/nut file starts the drivers in its 'start_precmd', so if running '/usr/local/etc/rc.d/nut start' fails, it may be due to either the driver or upsd. All of the NUT components log basic status to syslog, so you should have entries there whether each step fails or succeeds.
Note: the consensus on the list seems to be that reply-to munging is bad, so please use your mailer's reply-to-list or reply-all feature.
--
Charles Lepple
clepple at gmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20140824/79743212/attachment.html>
More information about the Nut-upsdev
mailing list