2006/8/30, Davide Ferrari [EMAIL PROTECTED]:
El Miércoles, 30 de Agosto de 2006 15:35, escribió:
I don't see any reason to this failure, according to your info.
moreover, snmp-ups hasn't received much attention for long, so the
problem shouldn't come from the version diff between 2.0.2 and 2.0.3.
Ok.
since snmp-ups is based upon Net SNMP, the problem might sit here.
So, did you try some snmpwalk/snmpget from the same box to see if data
is reachable?
snmpwalk -c public -v 1 sai.atrapalo.com
SNMPv2-MIB::sysDescr.0 = STRING: Comet Extreme 6 kVA
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.705.1.2
SNMPv2-MIB::sysUpTime.0 = Timeticks: (68683888) 7 days, 22:47:18.88
SNMPv2-MIB::sysContact.0 = STRING: Davide Ferrari
SNMPv2-MIB::sysName.0 = STRING: SAI
SNMPv2-MIB::sysLocation.0 = STRING: Sala servidores
SNMPv2-MIB::sysServices.0 = INTEGER: 72
IF-MIB::ifNumber.0 = INTEGER: 1
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifDescr.1 = STRING: UM9008
IF-MIB::ifType.1 = INTEGER: iso88023Csmacd(7)
(etc. etc.)
so it seems to work. I've also tried to set in /etc/ups/ups.conf
mips = mge
according to snmp-ups manpage but it throws the same error (well, only
changing ietf for mge in the error output).
I really have no clues about what's happening here...
nor do I.
I vaguely remember a problem with name resolution (or alike)in
snmp-ups, due to a net snmp problem, but I can't find it back.
Possible tests:
- replace sai.atrapalo.com by its IP address
- starting snmp-ups in full debug mode (-D) will give us some more info.
A side solution is simply to set the faulty system as a nut slave of
one of the working system.
Arnaud
--
Linux / Unix Expert - MGE UPS SYSTEMS - RD Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource 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
