Re: [Nut-upsuser] Master Works, Slave Does Not
On Nov 9, 2014, at 7:56 PM, Steve Read sd_r...@hotmail.com wrote: Boy, I guess I got that one wrong. When I run nmap on the master it does say that port 3493 is open which is expected. So then what you are telling me means the ports are open. In other words I don't have a firewall issue. I know this sounds incredibly pedantic, but if you run nmap on the slave and scan the master, and it says the ports are open, then you don't have a firewall issue. The netstat output is independent of the firewall. Now I am stumped as to why the slave does not shut down? You should see something like this in /var/log/daemon.log on the slave (and on the master, but you said that was shutting down already): upsmon[1234]: Communications with UPS sdrups@192.168.0.7 established Once that connection is up, you can run sudo upsmon -c fsd on the master to simulate a power failure (to avoid running down the batteries too much). Note that this will shut down the master system, too. Details are in the upsmon man page. -- 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
Re: [Nut-upsuser] Master Works, Slave Does Not
On the slave which is 192.168.0.6 in /var/log/daemon.log I see entries of: Nov 10 17:43:03 server2 upsmon[2120]: Poll UPS [root@192.168.0.7] failed - [root] does not exist on server 192.168.0.7 In upsmon.conf I have one entry: MONITOR root@192.168.0.7 1 sdrups autocadba2 slave (Yes, I realize I displayed my password some time ago) So I think it is saying that root does not exist on server which is confusing as on the server 192.168.0.7 I have. In upsd.users I have [root] password = autocadba2 upsmon master instcmds = ALL So why is it saying root does not exist on server? Subject: Re: [Nut-upsuser] Master Works, Slave Does Not From: clep...@gmail.com Date: Mon, 10 Nov 2014 07:34:44 -0500 CC: nut-upsuser@lists.alioth.debian.org To: sd_r...@hotmail.com On Nov 9, 2014, at 7:56 PM, Steve Read sd_r...@hotmail.com wrote: Boy, I guess I got that one wrong. When I run nmap on the master it does say that port 3493 is open which is expected. So then what you are telling me means the ports are open. In other words I don't have a firewall issue. I know this sounds incredibly pedantic, but if you run nmap on the slave and scan the master, and it says the ports are open, then you don't have a firewall issue. The netstat output is independent of the firewall. Now I am stumped as to why the slave does not shut down? You should see something like this in /var/log/daemon.log on the slave (and on the master, but you said that was shutting down already): upsmon[1234]: Communications with UPS sdrups@192.168.0.7 established Once that connection is up, you can run sudo upsmon -c fsd on the master to simulate a power failure (to avoid running down the batteries too much). Note that this will shut down the master system, too. Details are in the upsmon man page. -- Charles Leppleclepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
On 11/10/14 16:54, Steve Read wrote: On the slave which is 192.168.0.6 in /var/log/daemon.log I see entries of: Nov 10 17:43:03 server2 upsmon[2120]: Poll UPS [root@192.168.0.7] failed - [root] does not exist on server 192.168.0.7 In upsmon.conf I have one entry: MONITOR root@192.168.0.7 1 sdrups autocadba2 slave (Yes, I realize I displayed my password some time ago) So I think it is saying that root does not exist on server which is confusing as on the server 192.168.0.7 I have. In upsd.users I have [root] password = autocadba2 upsmon master instcmds = ALL So why is it saying root does not exist on server? The root in the MONITOR root@192.168.0.7 srdups autocadba2 slave line is the name of the UPS define in ups.conf. What does your ups.conf look like? Stan ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
On 11/10/14 17:52, Steve Read wrote: Hi Stan, thank you for your help. My ups.conf file is: [sdrups] driver = genericups port = /dev/ttyS1 desc = For Server Backup upstype=9 Assuming upsmon is the user and autocadba2 is the password in upsd.users, the monitor line should be MONITOR sdrups@192.168.0.7 upsmon autocadba2 slave Stan Date: Mon, 10 Nov 2014 17:03:46 -0600 From: sg063...@gmail.com To: nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] Master Works, Slave Does Not On 11/10/14 16:54, Steve Read wrote: On the slave which is 192.168.0.6 in /var/log/daemon.log I see entries of: Nov 10 17:43:03 server2 upsmon[2120]: Poll UPS [root@192.168.0.7 mailto:root@192.168.0.7] failed - [root] does not exist on server 192.168.0.7 In upsmon.conf I have one entry: MONITOR root@192.168.0.7 mailto:root@192.168.0.7 1 sdrups autocadba2 slave (Yes, I realize I displayed my password some time ago) So I think it is saying that root does not exist on server which is confusing as on the server 192.168.0.7 I have. In upsd.users I have [root] password = autocadba2 upsmon master instcmds = ALL So why is it saying root does not exist on server? The root in the MONITOR root@192.168.0.7 mailto:root@192.168.0.7 srdups autocadba2 slave line is the name of the UPS define in ups.conf. What does your ups.conf look like? Stan ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
I would like to verify my understanding keeping in mind I have a one master and one slave computer. When the master gets the low batt/noAC signal it initiates a broadcast packet(s) on port 3493. 1) Is this correct? Then the slave computer must have this port open and it listens on this port for the shut-down command. 2) Is this correct? On the slave if I run the following: steve@MyDesktop:~$ nmap -p 3493 192.168.0.6 Starting Nmap 6.40 ( http://nmap.org ) at 2014-11-09 15:42 ESTNmap scan report for 192.168.0.6Host is up (0.00013s latency).PORT STATE SERVICE3493/tcp closed nut Nmap done: 1 IP address (1 host up) scanned in 11.06 seconds Which tells me this port is configured for nut but it is closed? I have rebooting and starting and stopping the service using: sudo service ups-monitor stop sudo service ups-monitor startBut it remains closed. 3) Assuming this should be open how do I fix this? Thank you for any help - Steve ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
On Nov 9, 2014, at 3:48 PM, Steve Read sd_r...@hotmail.com wrote: I would like to verify my understanding keeping in mind I have a one master and one slave computer. When the master gets the low batt/noAC signal it initiates a broadcast packet(s) on port 3493. 1) Is this correct? No, the slave computer's upsmon process connects to the master (via TCP, so point-to-point, not broadcast), and listens for the OB (on battery) and then OB LB (on battery; low battery) status. (Not to say that some other UPS shutdown software couldn't broadcast, but port 3493 is reserved for NUT.) Then the slave computer must have this port open and it listens on this port for the shut-down command. 2) Is this correct? It's the other way around: the master (via upsd) listens on port 3493, and the slave connects to that port. On the slave if I run the following: steve@MyDesktop:~$ nmap -p 3493 192.168.0.6 Starting Nmap 6.40 ( http://nmap.org ) at 2014-11-09 15:42 EST Nmap scan report for 192.168.0.6 Host is up (0.00013s latency). PORT STATE SERVICE 3493/tcp closed nut Nmap done: 1 IP address (1 host up) scanned in 11.06 seconds Which tells me this port is configured for nut but it is closed? As mentioned above, that is expected. But if you run it against the master (192.168.0.7, if I understand correctly) from the slave, you should see that it is open. I have rebooting and starting and stopping the service using: sudo service ups-monitor stop sudo service ups-monitor start But it remains closed. 3) Assuming this should be open how do I fix this? You mentioned that you have a LISTEN 0.0.0.0 line in upsd.conf on the master - has upsd been restarted since that change was made? Other than that, you should be set. Do things match the netstat output I mentioned in a previous email? -- 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
Re: [Nut-upsuser] Master Works, Slave Does Not
Boy, I guess I got that one wrong. When I run nmap on the master it does say that port 3493 is open which is expected. So then what you are telling me means the ports are open. In other words I don't have a firewall issue. Now I am stumped as to why the slave does not shut down? Subject: Re: [Nut-upsuser] Master Works, Slave Does Not From: clep...@gmail.com Date: Sun, 9 Nov 2014 16:31:22 -0500 CC: nut-upsuser@lists.alioth.debian.org To: sd_r...@hotmail.com On Nov 9, 2014, at 3:48 PM, Steve Read sd_r...@hotmail.com wrote: I would like to verify my understanding keeping in mind I have a one master and one slave computer. When the master gets the low batt/noAC signal it initiates a broadcast packet(s) on port 3493. 1) Is this correct? No, the slave computer's upsmon process connects to the master (via TCP, so point-to-point, not broadcast), and listens for the OB (on battery) and then OB LB (on battery; low battery) status. (Not to say that some other UPS shutdown software couldn't broadcast, but port 3493 is reserved for NUT.) Then the slave computer must have this port open and it listens on this port for the shut-down command. 2) Is this correct? It's the other way around: the master (via upsd) listens on port 3493, and the slave connects to that port. On the slave if I run the following: steve@MyDesktop:~$ nmap -p 3493 192.168.0.6 Starting Nmap 6.40 ( http://nmap.org ) at 2014-11-09 15:42 ESTNmap scan report for 192.168.0.6Host is up (0.00013s latency).PORT STATE SERVICE3493/tcp closed nut Nmap done: 1 IP address (1 host up) scanned in 11.06 seconds Which tells me this port is configured for nut but it is closed? As mentioned above, that is expected. But if you run it against the master (192.168.0.7, if I understand correctly) from the slave, you should see that it is open. I have rebooting and starting and stopping the service using: sudo service ups-monitor stop sudo service ups-monitor startBut it remains closed. 3) Assuming this should be open how do I fix this? You mentioned that you have a LISTEN 0.0.0.0 line in upsd.conf on the master - has upsd been restarted since that change was made? Other than that, you should be set. Do things match the netstat output I mentioned in a previous email? -- Charles Leppleclepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
[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 ... tcp0 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 ... tcp0 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
Re: [Nut-upsuser] Master Works, Slave Does Not
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: 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 ... tcp0 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 ... tcp0 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
Re: [Nut-upsuser] Master Works, Slave Does Not
On Nov 8, 2014, at 10:34 AM, Steve Read sd_r...@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@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
Thank you for that clarification. What makes it more confusing for me is that I chose the backup server to monitor the ups which means my backup is the master and my server is the client. And then IP wise my master is .7 and the client is .6 which sometimes messes me up. Not sure if you are interested but I believe you helped me out the first time as your name is familiar. It would have been around 2007 which is when I transitioned from NT 4.0 to the Linux world. Were you involved back then? As I recall, I had troubles then and you helped me get it running but to be honest I never fully understood it and once it was running didn't need to even think about it as it has been running flawlessly since then. Hence why I simply copied those parameters over to the new servers. Also, I am using a home-made UPS which has been running since my first server which was Win95 then NT. My UPS provides a simple low bat and AC present signalling and uses a standard adapter to charge an old car battery and a DC-AC inverter. This along with Nut has provided me all these years with no data loss. And at a cheap cost as I use old batteries from the car which still have enough life to provide many hours of run time. Anyway, I plan to look into this later on. Thank you - Steve Subject: Re: [Nut-upsuser] Master Works, Slave Does Not From: clep...@gmail.com Date: Sat, 8 Nov 2014 11:00:39 -0500 CC: nut-upsuser@lists.alioth.debian.org To: sd_r...@hotmail.com On Nov 8, 2014, at 10:34 AM, Steve Read sd_r...@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 Leppleclepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Master Works, Slave Does Not
I don't see a upsmon.conf in the original post. Shouldn't the clients have upsmon running on them rather than upsd? Stan On Thu, Nov 6, 2014 at 9: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. -- 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 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
