[Please use reply-all to keep the discussion on the list, thanks] On Nov 6, 2014, at 10:19 PM, Charles Lepple <clepple at gmail.com> wrote:> On Nov 6, 2014, at 12:48 PM, Steve Read <sd_read at hotmail.com> wrote: > >> I am presently upgrading my servers. The old ones are running Suse 10.1 and I am upgrading to the most recent Debian. > > What version of NUT on the new systems? > > There are a few changes to the configuration files, mostly related to the ACL lines.You mentioned you got "driver.version: 2.6.4" from upsc. So it seems like you have Debian wheezy. Is that the case for both servers? (What I was really interested in was the output of "dpkg -l nut", since it shows the Debian-specific version number as well, but wheezy hasn't changed much. There are a few things still being sorted out in Debian jessie.)> Now this may be a problem but I don't think it is the only one. I really feel this is a permissions issue. > > For example from the master, if I type: > root at backup2:~# sudo upsc sdrups at localhost ups.status > OL > > Which is the response I expect, but if I type (also from the master): > root at backup2:~# sudo upsc sdrups at 192.168.0.7 ups.status > Error: Connection failure: Connection refusedOne thing that has changed since NUT 2.4.x is that the ACL options were removed, and the defaults for the LISTEN directive were changed to only bind to localhost. So a "netstat -ta" (trimmed to just show NUT) would look like this: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 localhost:nut *:* LISTEN Instead, you want to listen on the wildcard address, so you will want to add "LISTEN 0.0.0.0" to /etc/nut/upsd.conf. After restarting NUT, netstat should look like this: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 *:nut *:* LISTEN And at that point, you can use the firewall rules to restrict access to just localhost and your local network. If you were able to get output from upsc, then it sounds like you got the driver working. Just in case, here is the UPGRADING document: https://github.com/networkupstools/nut/blob/master/UPGRADING Some drivers (apcsmart) have had under-the-hood changes that should be more beneficial than problematic. Also, Stan mentioned the following off-list, and it holds true:> upsmon.conf should have a line like this > > MONITOR apcusb at 192.168.1.235 1 upsmon pass slave > > upsd.users should have a matching statement like this > > [upsmon] > password = pass > # upsmon master > # or > upsmon slaveThe only configuration files that a slave needs are upsmon.conf, nut.conf to tell the init.system that it is a slave, and possibly an upssched.conf if you haven enabled that. The others are master-only. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141108/7bdc8b5e/attachment.html>
Thank you Charles, I am hoping fiddle with that sometime today or tomorrow.
But I have another question, when you ask me to modify various files I am
confused as to weather you mean on the server, client or both?
So in your statement:
"Instead, you want to listen on the wildcard address, so you will want to
add "LISTEN 0.0.0.0" to /etc/nut/upsd.conf. After restarting NUT,
netstat should look like this:"
I think you mean the client?
Steve
Subject: Re: [Nut-upsuser] Master Works, Slave Does Not
From: clepple at gmail.com
Date: Sat, 8 Nov 2014 09:00:12 -0500
CC: nut-upsuser at lists.alioth.debian.org
To: sd_read at hotmail.com
[Please use reply-all to keep the discussion on the list, thanks]
On Nov 6, 2014, at 10:19 PM, Charles Lepple <clepple at gmail.com> wrote:
On Nov 6, 2014, at 12:48 PM, Steve Read <sd_read at hotmail.com> wrote:
I am presently upgrading my servers. The old ones are running Suse 10.1 and I am
upgrading to the most recent Debian.
What version of NUT on the new systems?
There are a few changes to the configuration files, mostly related to the ACL
lines.
You mentioned you got "driver.version: 2.6.4" from upsc. So it seems
like you have Debian wheezy. Is that the case for both servers?
(What I was really interested in was the output of "dpkg -l nut",
since it shows the Debian-specific version number as well, but wheezy hasn't
changed much. There are a few things still being sorted out in Debian jessie.)
Now this may be a problem but I don't think it is the only one. I really
feel this is a permissions issue.
For example from the master, if I type:
root at backup2:~# sudo upsc sdrups at localhost ups.status
OL
Which is the response I expect, but if I type (also from the master):
root at backup2:~# sudo upsc sdrups at 192.168.0.7 ups.status
Error: Connection failure: Connection refused
One thing that has changed since NUT 2.4.x is that the ACL options were removed,
and the defaults for the LISTEN directive were changed to only bind to
localhost. So a "netstat -ta" (trimmed to just show NUT) would look
like this:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp 0 0 localhost:nut *:* LISTEN
Instead, you want to listen on the wildcard address, so you will want to add
"LISTEN 0.0.0.0" to /etc/nut/upsd.conf. After restarting NUT, netstat
should look like this:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp 0 0 *:nut *:* LISTEN
And at that point, you can use the firewall rules to restrict access to just
localhost and your local network.
If you were able to get output from upsc, then it sounds like you got the driver
working. Just in case, here is the UPGRADING document:
https://github.com/networkupstools/nut/blob/master/UPGRADING
Some drivers (apcsmart) have had under-the-hood changes that should be more
beneficial than problematic.
Also, Stan mentioned the following off-list, and it holds true:
upsmon.conf should have a line like this
MONITOR apcusb at 192.168.1.235 1 upsmon pass slave
upsd.users should have a matching statement like this
[upsmon]
password = pass
# upsmon master
# or
upsmon slave
The only configuration files that a slave needs are upsmon.conf, nut.conf to
tell the init.system that it is a slave, and possibly an upssched.conf if you
haven enabled that. The others are master-only.
--
Charles Lepple
clepple at gmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141108/26f0ac61/attachment.html>
On Nov 8, 2014, at 10:34 AM, Steve Read <sd_read at hotmail.com> wrote:> Thank you Charles, I am hoping fiddle with that sometime today or tomorrow. > > But I have another question, when you ask me to modify various files I am confused as to weather you mean on the server, client or both? > > So in your statement: > > "Instead, you want to listen on the wildcard address, so you will want to add "LISTEN 0.0.0.0" to /etc/nut/upsd.conf. After restarting NUT, netstat should look like this:" > > I think you mean the client?Sorry if I didn't use consistent terminology, but starting from the standard TCP client/server definitions, NUT's upsd is the server process, running on the NUT master machine, and it listens on TCP port 3493. It is configured via upsd.conf. The NUT upsmon process runs on the master as well as the slave, and it is a TCP client to upsd. Your previous upsmon.conf files should work (assuming the passwords match that of upsd.users on the master). Put another way, with one UPS, one master, and one or more slaves, there is only one driver and one upsd on the master host. The slaves, therefore, do not need upsd.conf or the driver configuration file ups.conf, since they connect to the upsd process running on the master, and upsd distributes that information over the network. I think part of the confusion is that the master/slave and server/client terms are not exactly synonymous, due to the usual need for the NUT master machine to shut down itself as well as the slave. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141108/5bde9d99/attachment-0001.html>
I have made changes but it is still the same. That is when the server gets the
lowbat/noAC signal it does shut down as expected but the slave does not.
Perhaps it makes sense for me to list the present settings:
On the Master:
nut.conf MODE=netserver
ups.conf [sdrups] driver = genericups port =
/dev/ttyS1 desc = "For Server & Backup"
upstype=9
upsd.conf LISTEN 0.0.0.0
upsd.users [root] password = mypassword upsmon
master instcmds = ALL
upsmon.conf MONITOR root at 192.168.0.7 1 sdrups autocadba2 master
On the Slave:
nut.conf MODE=netserver
upsmon.conf MONITOR root at 192.168.0.7 1 sdrups autocadba2 slave
Master: 192.168.0.7Slave: 192.168.0.6
Dealing with the firewall I applied the following to both the master and slave:
sudo iptables -A INPUT -p tcp --dport 3493 -j ACCEPT
I have looked in the log files but have not seen anything to suggest a problem.
Steve
Subject: Re: [Nut-upsuser] Master Works, Slave Does Not
From: clepple at gmail.com
Date: Sat, 8 Nov 2014 09:00:12 -0500
CC: nut-upsuser at lists.alioth.debian.org
To: sd_read at hotmail.com
[Please use reply-all to keep the discussion on the list, thanks]
On Nov 6, 2014, at 10:19 PM, Charles Lepple <clepple at gmail.com> wrote:
On Nov 6, 2014, at 12:48 PM, Steve Read <sd_read at hotmail.com> wrote:
I am presently upgrading my servers. The old ones are running Suse 10.1 and I am
upgrading to the most recent Debian.
What version of NUT on the new systems?
There are a few changes to the configuration files, mostly related to the ACL
lines.
You mentioned you got "driver.version: 2.6.4" from upsc. So it seems
like you have Debian wheezy. Is that the case for both servers?
(What I was really interested in was the output of "dpkg -l nut",
since it shows the Debian-specific version number as well, but wheezy hasn't
changed much. There are a few things still being sorted out in Debian jessie.)
Now this may be a problem but I don't think it is the only one. I really
feel this is a permissions issue.
For example from the master, if I type:
root at backup2:~# sudo upsc sdrups at localhost ups.status
OL
Which is the response I expect, but if I type (also from the master):
root at backup2:~# sudo upsc sdrups at 192.168.0.7 ups.status
Error: Connection failure: Connection refused
One thing that has changed since NUT 2.4.x is that the ACL options were removed,
and the defaults for the LISTEN directive were changed to only bind to
localhost. So a "netstat -ta" (trimmed to just show NUT) would look
like this:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp 0 0 localhost:nut *:* LISTEN
Instead, you want to listen on the wildcard address, so you will want to add
"LISTEN 0.0.0.0" to /etc/nut/upsd.conf. After restarting NUT, netstat
should look like this:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
tcp 0 0 *:nut *:* LISTEN
And at that point, you can use the firewall rules to restrict access to just
localhost and your local network.
If you were able to get output from upsc, then it sounds like you got the driver
working. Just in case, here is the UPGRADING document:
https://github.com/networkupstools/nut/blob/master/UPGRADING
Some drivers (apcsmart) have had under-the-hood changes that should be more
beneficial than problematic.
Also, Stan mentioned the following off-list, and it holds true:
upsmon.conf should have a line like this
MONITOR apcusb at 192.168.1.235 1 upsmon pass slave
upsd.users should have a matching statement like this
[upsmon]
password = pass
# upsmon master
# or
upsmon slave
The only configuration files that a slave needs are upsmon.conf, nut.conf to
tell the init.system that it is a slave, and possibly an upssched.conf if you
haven enabled that. The others are master-only.
--
Charles Lepple
clepple at gmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141108/d4cd3a97/attachment.html>
On Nov 8, 2014, at 1:52 PM, Steve Read <sd_read at hotmail.com> wrote:> I have made changes but it is still the same. That is when the server gets the lowbat/noAC signal it does shut down as expected but the slave does not. > > Perhaps it makes sense for me to list the present settings: > > On the Master: > > nut.conf > MODE=netserver > > ups.conf > [sdrups] > driver = genericups > port = /dev/ttyS1 > desc = "For Server & Backup" > upstype=9 > > upsd.conf > LISTEN 0.0.0.0 > > upsd.users > [root] > password = mypassword > upsmon master > instcmds = ALL > > upsmon.conf > MONITOR root at 192.168.0.7 1 sdrups autocadba2 masterThis looks good, except for the MONITOR line. Given the above settings, I think you need this: MONITOR sdrups at 192.168.0.7 1 root mypassword master> > On the Slave: > > nut.conf > MODE=netserverMODE=netclient for the slave.> upsmon.conf > MONITOR root at 192.168.0.7 1 sdrups autocadba2 slaveSame username/password change as above: MONITOR sdrups at 192.168.0.7 1 root mypassword slave> Master: 192.168.0.7 > Slave: 192.168.0.6 > > Dealing with the firewall I applied the following to both the master and slave: > > sudo iptables -A INPUT -p tcp --dport 3493 -j ACCEPT > > > I have looked in the log files but have not seen anything to suggest a problem.You should see something like this in /var/log/daemon.log: upsmon[1234]: Communications with UPS sdrups at 192.168.0.7 established And something like this from netstat on the slave: $ netstat -t |grep -w nut tcp 0 0 192.168.0.6:40925 192.168.0.7:nut ESTABLISHED -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141108/5a3b1024/attachment-0001.html>