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@192.168.0.7 1 sdrups autocadba2 master
On the Slave:
     nut.conf        MODE=netserver
     upsmon.conf        MONITOR root@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: clep...@gmail.com
Date: Sat, 8 Nov 2014 09:00:12 -0500
CC: nut-upsuser@lists.alioth.debian.org
To: sd_r...@hotmail.com

[Please use reply-all to keep the discussion on the list, thanks]

On Nov 6, 2014, at 10:19 PM, Charles Lepple <clep...@gmail.com> wrote:

On Nov 6, 2014, at 12:48 PM, Steve Read <sd_r...@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@backup2:~# sudo upsc sdrups@localhost ups.status
    OL

Which is the response I expect, but if I type (also from the master):
  root@backup2:~# sudo upsc sdrups@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@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@gmail



                                          
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Reply via email to