Package: torrus-common Version: 2.03-2 Severity: normal Dear Maintainers,
please backport Commit 5985de2ace378ff8179ab9229470bd321728d061 (Bugfix in walkSnmpTable(): maxrepetitions is only applicable in SNMPv2 or v3) and Commit 2f468f3e0aef02657b066baa98504dc98e841888 (Bugfix in collector: maxrepetitions is unsupported in SNMPv1) as found in git://torrus.git.sourceforge.net/gitroot/torrus/torrus to stable. Rationale: These patches are essential for proper operation of Torrus (as supplied in Wheezy) against SNMPv1-only targets. Without these patches, the following symptoms may be observed: 1) cbQoS will never start to fill graphs with data. It *is* discovering the QoS trees correctly, but will never collect them from targets through SNMP (note that this isn't limited to v1 targets), and graphs will show NaN values forever. 2) SNMPv1 targets will neither discover nor collect the ifTable tree. This also stops interface mapping from ever completing, which in turn causes (1) as the cbQoS collector in this version will not start up for a target when the number of open mapping sessions isn't zero. As soon as one SNMPv1 target was encountered, no more targets will have their cbQoS collection started, the exact impact of which depends a lot on the actual trees and targets and their sequence of initialization. In my case, two out of several hundred targets still had live cbQoS data... Please note that (1) is probably also fixed by Commit 13ce4e222408ca89c786a903ffed39d737f81bf1 (Bugfix in cbQoS collector initialization) which generally changes collection to start for an individual target as soon as that target has completed interface mapping. In this case, that is a fix for cbQoS startup being hampered by unreachable devices which prevent interface mapping from ever terminating in much the same way as the SNMPv1 issues do. I had, however, some difficulties in backporting that commit to 2.03 as found in Wheezy, given it is based on a way newer codebase. The patches from 5985de2ace378ff8179ab9229470bd321728d061 and 2f468f3e0aef02657b066baa98504dc98e841888, on the other hand, apply cleanly and are "obviously right", so there should not be any problem with backporting them. I'm now running an on-hold locally modified version of torrus-common, but would like to get back on the original distribution package path for the upcoming live of Wheezy, and others may run into these problems as well (specifically when upgrading from earlier versions). So after debugging these issues, I thought I share them here and see if there is a chance of getting the fixes into a point release. TIA, Andre. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages torrus-common depends on: ii adduser 3.113+nmu3 ii db-util 5.1.6 ii dpkg 1.16.10 ii libapache-session-perl 1.89-1 ii libberkeleydb-perl 0.51-1 ii libcgi-fast-perl 5.14.2-21 ii libjson-perl 2.53-1 ii libnet-snmp-perl 6.0.1-2 ii libproc-daemon-perl 0.14-1 ii librrds-perl 1.4.7-2 ii libtemplate-perl 2.24-1 ii libtimedate-perl 1.2000-1 ii liburi-perl 1.60-1 ii libxml-libxml-perl 2.0001+dfsg-1 ii lsb-base 4.1+Debian8 ii netbase 5.0 ii perl 5.14.2-21 ii rrdtool 1.4.7-2 torrus-common recommends no packages. Versions of packages torrus-common suggests: ii libapache2-mod-fcgid 1:2.3.6-1.2 pn libcrypt-des-perl <none> ii libdigest-hmac-perl 1.03+dfsg-1 ii libio-socket-inet6-perl 2.69-2 -- Configuration Files: /etc/torrus/conf/devdiscover-siteconfig.pl changed [not included] /etc/torrus/conf/torrus-siteconfig.pl changed [not included] -- no debconf information -- debsums errors found: debsums: changed file /usr/share/perl5/Torrus/Collector/SNMP.pm (from torrus-common package) debsums: changed file /usr/share/perl5/Torrus/DevDiscover.pm (from torrus-common package) debsums: changed file /usr/share/perl5/Torrus/DevDiscover/RFC2863_IF_MIB.pm (from torrus-common package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
