Nut upsuser - Jul 2009 - Any word on when the ietf mib will be fixed for liebert?

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?

* 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

-- 

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

2009/7/27 Maurice Volaski <mvolaski at 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.

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090727/7086e15c/attachment.htm>

Citeren Maurice Volaski <mvolaski op 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?
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

>Please don't mistake warning messages with (fatal) errors. Starting 
>with nut-2.4.0, these messages should only be displayed in debug mode,
>so I'm surprised you're seeing them in nut-2.4.1.
It doesn't seem this way from my reading of the source code:

upslogx(LOG_ERR, "[%s] %s: Error in packet: %s",

 From what I can tell, that's a regular log message of an error, not a 
debug mode message, which would use either "upsdebugx" or
"debug", or
a warning, which would use upslogx with "LOG_WARNING".

>Upon startup, the snmp-ups driver will query the UPS for all the OID's 
>the driver supports. The ones which are not supported by the UPS, will
In addition, the errors are continually output to syslog; they don't 
just appear once and stop.
>generally result in an error message from the NetSNMP library that is
>used. There is nothing we can do about that and it is *not* an error.
Perhaps you could change LOG_ERR to  LOG_WARNING and perhaps you can 
ignore it after the first time it appears.
>  > Anyway, now that the script is starting, I'm seeing "failed
- got
>  > [ERR ACCESS-DENIED]" errors  from upsmon, and I don't know
why.
>
>See 'man 8 upsd', 'man 5 upsd.conf' and 'man 5
upsd.users'. This is a
>configuration error.
My nut configuration is fine. To troubleshoot this, I had to label 
each one of ACCESS-DENIED errors in the code, and with that, I 
determined that the one involving tcp-wrappers was complaining. It 
appears that local network communication is hard coded with 
127.0.0.1. In my /etc/hosts.allow, I just have "ALL:localhost", with 
no 127.0.0.1. TCP wrappers doesn't know or check that they're the 
same, so I once I added it, it started working. :-) Presumably, 
previous versions used localhost.
-- 

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

>  >> Please don't mistake warning messages with (fatal) errors.
Starting
>>>  with nut-2.4.0, these messages should only be displayed in debug 
>>>  mode, so I'm surprised you're seeing them in nut-2.4.1.
>>
>>  It doesn't seem this way from my reading of the source code:
>>
>>  upslogx(LOG_ERR, "[%s] %s: Error in packet: %s",
>
>This is a different message from what you reported before. These where 
>logged with 'nut_snmp_get' in them and these lines should now be
gone
>(unless running in debug mode 2 or higher).
What message do you think I posted?

It was this one and it has the "Error in packet":

[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.

>  > From what I can tell, that's a regular log message of an error,
not
>>  a debug mode message, which would use either "upsdebugx" or
"debug",
>>  or a warning, which would use upslogx with "LOG_WARNING".
>
>Indeed, but this is in the lines you posted.
Where exactly do see any mention of "debug" or "warning"?
>  >> Upon startup, the snmp-ups driver will query the UPS for all the 
>>>  OID's the driver supports. The ones which are not supported by
the
>>>  UPS, will
>>
>>  In addition, the errors are continually output to syslog; they
don't
>>  just appear once and stop.
>
>It looks like this is a different problem than what you mentioned 
>before. Please be specific.
No, there was only one set of messages that prompted me to post and 
they were reported as errors and they are indeed being continuously 
output to the system log.
>No, previous versions didn't use tcp-wrappers. That's why I pointed 
>you to 'man 8 upsd.conf' which has a paragraph ACCESS CONTROL that 
>tells you that we use tcp-wrappers. It's true that we only do a lookup 
>for the IP, not the hostname. Although it is common to include both 
>hostname and IP in hosts.allow, we probably should make a note to that
>effect.
I saw that it was using tcp-wrappers, but I wouldn't have guessed 
localhost and 127.0.0.1 would be interpreted differently. For one 
thing, I have them as equivalent in /etc/hosts and they ordinarily 
are equivalent, so tcp-wrappers documentation could also be clarified 
:-)
-- 

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