date:20090727

Re: [Nut-upsuser] Any word on when the ietf mib will be fixed for liebert?

2009-07-27 Thread Maurice Volaski


At 9:11 AM +0200 7/27/09, Arnaud Quette wrote:
2009/7/27 Maurice Volaski 
<mvola...@aecom.yu.edu>


This mib used to work, so is there a way to go back to the version 
prior to this one without downgrading the whole package?



yes, only take the snmp-ups driver from the previous working release.


2.2.2 and 2.0.5 also complain but with fewer errors. 1.5.15 does not 
complain, so it's the one I added. Oddly, this old version doesn't 
seem to like that /var/state/ups directory is owned by user nut. I 
had to manually pass "-u nut" to upsdrvctl to get it to work.


Anyway, now that the script is starting, I'm seeing "failed - got 
[ERR ACCESS-DENIED]" errors  from upsmon, and I don't know why. I 
noted that the configuration has changed. It seems ACLs and ACCEPT 
are no longer used and have been replaced with LISTEN, but I have set 
that.


provide us back with an SNMP walk so that we can check the exact 
issue and find a suitable solution.

this might have something to do with the ".0" suffix...
starting with the RFC1628 MIB entry point (ie 1.3.6.1.2.1.33) is sufficient.


mib-2.33.1.1.1.0 = STRING: "Liebert Corporation"
mib-2.33.1.1.2.0 = STRING: "GXT2-2000RT120"
mib-2.33.1.1.3.0 = STRING: "GXT2MR15E-2K3K"
mib-2.33.1.1.4.0 = STRING: "2.200.1"
mib-2.33.1.1.5.0 = STRING: "upswallleft"
mib-2.33.1.2.1.0 = INTEGER: 2
mib-2.33.1.2.2.0 = INTEGER: 0
mib-2.33.1.2.3.0 = INTEGER: 6
mib-2.33.1.2.4.0 = INTEGER: 100
mib-2.33.1.2.5.0 = INTEGER: 553
mib-2.33.1.3.1.0 = Counter32: 0
mib-2.33.1.3.2.0 = INTEGER: 1
mib-2.33.1.3.3.1.2.1 = INTEGER: 600
mib-2.33.1.3.3.1.3.1 = INTEGER: 114
mib-2.33.1.4.1.0 = INTEGER: 3
mib-2.33.1.4.2.0 = INTEGER: 600
mib-2.33.1.4.3.0 = INTEGER: 1
mib-2.33.1.4.4.1.2.1 = INTEGER: 120
mib-2.33.1.4.4.1.3.1 = INTEGER: 112
mib-2.33.1.5.1.0 = INTEGER: 600
mib-2.33.1.5.2.0 = INTEGER: 1
mib-2.33.1.5.3.1.2.1 = INTEGER: 114
mib-2.33.1.6.1.0 = Gauge32: 0
mib-2.33.1.7.1.0 = OID: mib-2.33.1.7.7.1
mib-2.33.1.7.2.0 = INTEGER: 1
mib-2.33.1.7.3.0 = INTEGER: 6
mib-2.33.1.7.4.0 = ""
mib-2.33.1.7.5.0 = Timeticks: (0) 0:00:00.00
mib-2.33.1.7.6.0 = INTEGER: 0
mib-2.33.1.8.1.0 = INTEGER: 1
mib-2.33.1.8.2.0 = INTEGER: 0
mib-2.33.1.8.3.0 = INTEGER: 0
mib-2.33.1.8.4.0 = INTEGER: 0
mib-2.33.1.8.5.0 = INTEGER: 1
mib-2.33.1.9.1.0 = INTEGER: 120
mib-2.33.1.9.2.0 = INTEGER: 600
mib-2.33.1.9.3.0 = INTEGER: 120
mib-2.33.1.9.4.0 = INTEGER: 600
mib-2.33.1.9.5.0 = INTEGER: 2000
mib-2.33.1.9.7.0 = INTEGER: 2
mib-2.33.1.9.8.0 = INTEGER: 2
--

Maurice Volaski, mvola...@aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

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

[Nut-upsuser] Powercom Black Knight BNT-1000CS

2009-07-27 Thread Evan Micheal Goers

Hello. I would like to know the correct configuration for my Powercom 
Black Knight BNT-1000CS UPS. Here is my current configuration:


[blackknight]
   driver = powercom
   type = BNT-other
   port = /dev/ttyS0

BNT does not seem to work so I have to use BNT-other.
Does anyone else have this model? Google was of no help...

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

Re: [Nut-upsuser] Problems connecting via USB to APC Back-UPS ES 700 (Model BE700-GR)

2009-07-27 Thread Christoph Loesch


Hi Arnaud,

Arnaud Quette schrieb:

Hi Christoph,

2009/7/27 Christoph Loesch 

hi list,

im running debian/testing(act. squeeze) with 2.6.26-2-amd64 kernel.
first
tried apcupsd what flawlessly worked but because i run nagios (needs nut
running for 'check_ups'), im trying to run nut.

dmesg and syslog show the device:
Jul 27 00:08:06 kate kernel: [16001.477941] hiddev96hidraw0: USB HID
v1.10
Device [APC Back-UPS ES 700 FW:829.D3 .I USB FW:D3 ] on
usb-:00:1d.1-1
Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: New USB device
found,
idVendor=051d, idProduct=0002
Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: New USB device
strings: Mfr=3, Product=1, SerialNumber=2
Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: Product:
Back-UPS ES
700 FW:829.D3 .I USB FW:D3
Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: Manufacturer: APC
Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: SerialNumber:
3B0908X39177

lsusb doesnt show it. (maybe because usb is statically compiled in?)
kate:/# grep -w CONFIG_USB /boot/config-`uname -r`
CONFIG_USB=y
but the hiddevice is there
kate:/# ls -la /dev/hid*
crw-rw-r-- 1 root root 180, 96 27. Jul 00:08 /dev/hiddev0
crw-rw 1 root root 250,  0 27. Jul 00:08 /dev/hidraw0

tried using usbhid-ups driver and even with setting the option variable
"cable" to "940-0127E" i had no luck.
genericups with all possible upstypes doesnt work either.

any ideas?
chris


NUT' USB drivers use the libusb, so the usbfs on Linux (ie 
/dev/bus/usb/XXX/YYY)


depending on your exact distro version, the udev rule is located in 
/etc/udev/rules.d (old path) or /lib/udev/rules.d (new path). Generally, 
putting "auto" as the port value is sufficient.


to make a quick test, launch the driver as root, ie:
/path/to/usbhid-ups -u root -a upsname

it should acquire the connexion and talk to the device.
if it's ok, also try lsusb as root, you should see your device. then 
check the devices permissions, with the info from lsusb (Bus XXX, Device 
YYY) on /dev/bus/usb/XXX/YYY
it should be sufficient for the "nut" user (the exact user name depends 
on the distro...)


cheers,
Arnaud


i have no /dev/bus but /dev/usb/:
usb1usb4usbdev1.1_ep00  usbdev2.1_ep00
usbdev3.1_ep00  usbdev3.4_ep00  usbdev4.1_ep00  usbdev5.1_ep00  usbmon1
usbmon4
usb2usb5usbdev1.1_ep81  usbdev2.1_ep81
usbdev3.1_ep81  usbdev3.4_ep81  usbdev4.1_ep81  usbdev5.1_ep81  usbmon2
usbmon5
usb3usbdev1.1   usbdev2.1   usbdev3.1
usbdev3.4   usbdev4.1   usbdev5.1   usbmon0 usbmon3

i didnt touch udev but nut is there..
kate:/etc/nut# find /etc/udev/rules.d/ -name ??-nut*
/etc/udev/rules.d/52-nut-usbups.rules
kate:/etc/nut# find /lib/udev/rules.d/ -name ??-nut*
kate:/etc/nut#

libusb seems to be installed according to dpkg.
kate:/etc/nut# dpkg -l libusb* | grep ii
ii  libusb-0.1-42:0.1.12-13
userspace USB programming library
ii  libusb-1.0-02:1.0.0-1
userspace USB programming library

putting "auto" as the port value doesnt work either.
kate:/etc/nut# tail -n 10 ups.conf
# To find out if your driver supports any extra settings, start it with
# the -h option and/or read the driver's documentation.
[UPS]
driver = usbhid-ups
#   driver = genericups
#   upstype=12
#   port = /dev/hiddev0
port = auto
desc = "APC Back-UPS ES 700"
#   cable = 940-0127E

kate:/etc/nut# upsdrvctl -u root start
Network UPS Tools - UPS driver controller 2.4.1
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
USB communication driver 0.31
No matching HID UPS found
Driver failed to start (exit status=1)

kate:/etc/nut# /lib/nut/usbhid-ups -u root -a UPS
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
USB communication driver 0.31
No matching HID UPS found

(no nut-entries in syslog after running upsdrvctl or the driver itself)

further recommendations?

regards,
chris

--
Christoph Loesch - http://Loesch.me
OpenSource IT-Concepts & Services


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

Re: [Nut-upsuser] Any word on when the ietf mib will be fixed for liebert?

2009-07-27 Thread Arjen de Korte


Citeren Maurice Volaski :

This mib used to work, so is there a way to go back to the version  
prior to this one without downgrading the whole package?


When did this stop working (from which version to nut-2.4.1 did you  
upgrade)? The last changes to the IETF are made almost two years ago.  
Also, a dump of 'upsc' would be helpful, since I doubt that the errors  
you're seeing are fatal (they look more like warnings to me).


Best regards,
Arjen
--
Please keep list traffic on the list


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

Re: [Nut-upsuser] Problems connecting via USB to APC Back-UPS ES 700 (Model BE700-GR)

2009-07-27 Thread Arnaud Quette

Hi Christoph,

2009/7/27 Christoph Loesch 

> hi list,
>
> im running debian/testing(act. squeeze) with 2.6.26-2-amd64 kernel. first
> tried apcupsd what flawlessly worked but because i run nagios (needs nut
> running for 'check_ups'), im trying to run nut.
>
> dmesg and syslog show the device:
> Jul 27 00:08:06 kate kernel: [16001.477941] hiddev96hidraw0: USB HID v1.10
> Device [APC Back-UPS ES 700 FW:829.D3 .I USB FW:D3 ] on usb-:00:1d.1-1
> Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: New USB device found,
> idVendor=051d, idProduct=0002
> Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: New USB device
> strings: Mfr=3, Product=1, SerialNumber=2
> Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: Product: Back-UPS ES
> 700 FW:829.D3 .I USB FW:D3
> Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: Manufacturer: APC
> Jul 27 00:08:06 kate kernel: [16001.477941] usb 3-1: SerialNumber:
> 3B0908X39177
>
> lsusb doesnt show it. (maybe because usb is statically compiled in?)
> kate:/# grep -w CONFIG_USB /boot/config-`uname -r`
> CONFIG_USB=y
> but the hiddevice is there
> kate:/# ls -la /dev/hid*
> crw-rw-r-- 1 root root 180, 96 27. Jul 00:08 /dev/hiddev0
> crw-rw 1 root root 250,  0 27. Jul 00:08 /dev/hidraw0
>
> tried using usbhid-ups driver and even with setting the option variable
> "cable" to "940-0127E" i had no luck.
> genericups with all possible upstypes doesnt work either.
>
> any ideas?
> chris
>

NUT' USB drivers use the libusb, so the usbfs on Linux (ie
/dev/bus/usb/XXX/YYY)

depending on your exact distro version, the udev rule is located in
/etc/udev/rules.d (old path) or /lib/udev/rules.d (new path). Generally,
putting "auto" as the port value is sufficient.

to make a quick test, launch the driver as root, ie:
/path/to/usbhid-ups -u root -a upsname

it should acquire the connexion and talk to the device.
if it's ok, also try lsusb as root, you should see your device. then check
the devices permissions, with the info from lsusb (Bus XXX, Device YYY) on
/dev/bus/usb/XXX/YYY
it should be sufficient for the "nut" user (the exact user name depends on
the distro...)

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Any word on when the ietf mib will be fixed for liebert?

2009-07-27 Thread Arnaud Quette

2009/7/27 Maurice Volaski 

> This mib used to work, so is there a way to go back to the version prior to
> this one without downgrading the whole package?
>

yes, only take the snmp-ups driver from the previous working release.

Note that Liebert is not registered with SNMP support in our compat list! so
we even don't know about that.


> * Starting UPS drivers...
> Network UPS Tools - UPS driver controller 2.4.1
> Network UPS Tools - Generic SNMP UPS driver 0.44 (2.4.1)
> Detected GXT2-2000RT120 on host upswallleft (mib: ietf 1.3)
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.4.4.1.4.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.7.4: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.2.6.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.2.7.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.4.4.1.2.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.4.4.1.3.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.4.4.1.4.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.3.3.1.2.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.3.3.1.3.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.3.3.1.4.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] nut_snmp_get: 1.3.6.1.2.1.33.1.4.4.1.5.0: Error in packet:
> (noSuchName) There is no such variable name in this MIB.
> [upswallleft] snmp_ups_walk: data stale for ups.load
>

provide us back with an SNMP walk so that we can check the exact issue and
find a suitable solution.
this might have something to do with the ".0" suffix...
starting with the RFC1628 MIB entry point (ie 1.3.6.1.2.1.33) is sufficient.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Any word on when the ietf mib will be fixed for liebert?

[Nut-upsuser] Powercom Black Knight BNT-1000CS

Re: [Nut-upsuser] Problems connecting via USB to APC Back-UPS ES 700 (Model BE700-GR)

Re: [Nut-upsuser] Any word on when the ietf mib will be fixed for liebert?

Re: [Nut-upsuser] Problems connecting via USB to APC Back-UPS ES 700 (Model BE700-GR)

Re: [Nut-upsuser] Any word on when the ietf mib will be fixed for liebert?

6 matches

Site Navigation

Mail list logo

Footer information