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
[Nut-upsuser] APC Smart-UPS C1500 connected by usb
Hi, I have setup NUT in netserver mode on debian wheezy with two APC UPS units connected to it by usb. lsusb identifies the units as Smart-UPS 1000 and Smart-UPS C1500. It appears these do not use the smart protocol and usbhid-ups is the correct driver to use. System: Debian wheezy with stock version of nut (Version: 2.6.4-2.3+deb7u1) Everything works rather well, except that the cgi-interface does not report input/output voltages and load for the C 1500 unit. upsc also reports these values only for model 1000, not for 1500. Battery charge is and runtime are reported. Is this a limitation of the driver, or is there way to get these data? Thanks Selva ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Emerson/Liebert GXT3
On Nov 7, 2014, at 7:30 AM, Marcelo Fernandez marcelo.fidel.fernan...@gmail.com wrote: 2014-11-07 0:16 GMT-03:00 Charles Lepple clep...@gmail.com: On Nov 6, 2014, at 5:56 PM, Marcelo Fernandez marcelo.fidel.fernan...@gmail.com wrote: battery.voltage: 1000. battery.voltage.nominal: 0.0 Well, these are certainly interesting values ;-) I suspect the correction for earlier units has failed. Can you please start the driver with -DDD, let it run for a minute, then gzip and attach the resulting log? Yes, sure. Here it is. Let me know if it's enough to diagnose that weird value. Here is the problem: Starting at 0.062904 (reformatted): Report[buf]: (5 bytes) = 05 51 00 48 00 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x05, Offset: 0, Size: 16, Value: 1 Report[buf]: (5 bytes) = 05 51 00 48 00 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0 ConfigVoltage = 0 - assuming correction factor = 1e+08 The Voltage of 0x51 (81 V) and ConfigVoltage of 0x48 (72 V) seem reasonable, but somewhere else in the HID Report Descriptor, the voltages are getting scaled to a Logical range of 0-1. Can you temporarily comment out line 383 in drivers/libhid.c and rebuild? It currently looks like this: *Value = logical_to_physical(hiddata, hValue); If that works, we can add a flag to ignore logical-to-physical mappings. -- 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] nutdrv_atcl_usb
If you still can't get it to work with nutdrv_atcl_usb, another approach could be worth considering. Since this UPS seems to be supported by UPSmart2000I, it could use a serial-over-usb implementation of the megatec protocol. A very first early version of the nutdrv_qx driver that should support it can be found here: https://github.com/zykh/nut/tree/nutdrv_qx-fuji (USB subdriver 'fuji'; but it shouldn't be necessary to set it, as the driver is expected to automatically select it according to the iManufacturer/iProduct strings) Note that the user I first developed it for abruptly stopped replying to my mails (maybe his UPS went boom.. who knows?), so I don't really know if it works or not: quite a lot of testing may be needed. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
