Posts Tagged ‘snmpd’

Sonntag, 19. Februar 2017

ELK: snmpd: Cannot statfs

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Heute geht es um snmpd und Mounts, deren Attribute der Daemon nicht auslesen kann. Dies äussert sich auf ELK mit folgenden Log-Meldungen:

... snmpd[1234] Cannot statfs /var/lib/docker/containers/: Permission denied ...
... snmpd[1234] Cannot statfs /var/lib/docker/aufs/mnt/: Permission denied ...
... snmpd[1234] Cannot statfs /run/docker/netns/: Permission denied ...
... snmpd[1234] Cannot statfs /run/user/1000/gvfs: Permission denied ...
... snmpd[1234] Cannot statfs /sys/kernel/debug/tracing: Permission denied ...

Ich versuchte mit verschiedenen Einträgen in /etc/snmp/snmpd.conf das auslesen dieser Mounts zu verhindern. Zuerst mittels der Direktive ignoredisk:

...
ignoredisk /run/user/*
ignoredisk /var/lib/docker/containers/*
ignoredisk /var/lib/docker/aufs/mnt/*
ignoredisk /run/docker/netns/*
ignoredisk /sys/kernel/debug/tracing
...

Das Blacklisting hatte leider keine Wirkung.

Auch der umgekehrte Weg, das Whitelisting, funktionierte nicht:

...
#includeAllDisks 10%
disk / 10%
...

Nach längeren Recherchen im Netz musste ich zum Schluss kommen, dass man solche Meldungen nicht mit Anpassungen an der SNMP-Konfiguration unterdrücken kann. Der Grund:

Because as I wrote in comment #2, snmpd reads /proc/mounts and runs statfs on each entry there. If any statfs call fails it logs an error. So, either stafs must not fail (i.e. no „net:[4026532288]“ entries in /proc/mounts) or snmpd must be fixed to log something more useful and only once.

Quelle: Bug 1314610 – snmpd complaining twice „Cannot statfs net:[********]#***: No such file or directory“ every 10 minutes

snmpd iteriert über die Einträge in /proc/mounts und führt ein statfs auf jeden Mountpoint durch. Das ist der Moment, in dem die Fehlermeldung geloggt wird.

Eine potentielle Lösung:

There needs to be an option to just make snmpd not try to look at these sort of mount points. The problem is that ignoreDisk only works for the devices, not mount points and a tmpfs has no „device“ name to match it by.

Quelle: snmpd storage reports all tmpfs and floods logfile

Dem Problem begegne ich nun, indem ich mit rsyslog solche snmpd-Fehlermeldungen ausfiltere und nicht zu Logstash übermittle. Der Filter dazu lautet:

...
if $programname == 'snmpd' and $msg contains 'statfs' then {
    stop
}
...

Tags: , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. Januar 2017

snmpd-Konfiguration unter OpenWrt (Turris Omnia) anpassen

Auf Grund des in meinem Forum-Artikels geschilderten Problems der nicht zugänglichen Web-Interfaces meines Turris Omnias (das Problem trat kürzlich wieder auf), entschied ich mich, den von /tmp verwendeten Speicherplatz zu überwachen und mich beim Unterschreiten eines bestimmten Wertes zu alarmieren.

Was gibt es besseres, als den bereits laufenden SNMP-Daemon für diese Information anzuzapfen? Doch leider realisierte ich erst nach ein, zwei Stunden pröbeln, dass snmpd Dateisysteme vom Typ tmpfs nicht in den SNMP-Baum aufnimmt (weitere Diskussion hier sowie hier).

Doch vorerst setzte ich mich mit der snmpd-Konfiguration unter /etc/snmp/snmpd.conf auseinander. Beim Turris Omnia handelt es sich hierbei um einen Symlink auf die Datei /var/run/snmpd.conf. Doch bearbeitet man diese Datei und startet SNMP über die LuCI-Web-Oberfläche neu, werden die Anpassungen wie von Geisterhand mit den ursprünglichen Standardwerten überschrieben.

Nach ca. einer halben Stunde pröbeln und Googlen dann die Erkenntnis: Die Konfigurationsdatei ist — wie für OpenWrt typisch — unter /etc/config/snmpd abgelegt. Und zwar in einem OpenWrt-Format.

Darauf gestossen bin ich, als ich folgenden Befehl ausgeführt habe, welcher mir den Standort aller Dateien dieses Pakets zeigt:

# opkg files snmpd
Package snmpd (5.4.4-3) is installed on root and has the following files:
/etc/init.d/snmpd
/etc/config/snmpd
/usr/sbin/snmpd
/etc/snmp/snmpd.conf

Nimmt man die Anpassungen an sysLocation und sysContact hier vor, bleiben sie beim Neustarten des Daemons wie auch des Routers erhalten. Doch leider kann man in der unnötig komplexen Syntax nicht einfach neue Direktiven einbauen — diese müssen dem Start-Script unter /etc/init.d/snmpd explizit bekannt sein. So ist es zwar möglich, Einträge in der Form

disk /tmp 10%

einzubauen, indem man die Datei unter /etc/config/snmpd mit folgenden Zeilen ergänzt:

...
config disk
	option partition /tmp
	option size '10%'

Doch den Parameter includeAllDisks kennt das Script nicht. Halleluja für die aus meiner Sicht unnötige Komplexität, die dieser zusätzliche Konfigurationslayer dem Benutzer aufzwingt …

Im Internet habe ich nach etwas Googlen einen Patch gefunden, mit welchem der includeAllDisks-Parameter nachgerüstet werden kann. Mein Code von /etc/init.d/snmpd schaut deshalb nun so aus:

...
snmpd_disk_add() {
        local cfg="$1"
        local disk='disk'

        config_get partition "$cfg" partition
        [ -n "$partition" ] || return 0
        config_get size "$cfg" size
        [ -n "$size" ] || return 0

        if [ "$partition" == "includeAllDisks" ]; then
            echo "includeAllDisks $size" >> $CONFIGFILE
        else
            echo "disk $partition $size" >> $CONFIGFILE
        fi
        #echo "$disk $partition $size" >> $CONFIGFILE
}
...

Nun ist es mir möglich, includeAllDisks in der Konfiguration zu verwenden:

...
config disk
	option partition includeAllDisks
	option size '90%'
...

Den Daemon startet man über LuCI-Oberfläche neu, indem man zu System > Startup navigiert und beim Paket snmp den Restart-Button drückt.

Auf Grund des oben genannten Problems mit tmpfs-Partitionen erschien die gesuchten Informationen aber nie im SNMP-Baum.

Schlussendlich entschied ich mich für den Quick-und-Dirty-Ansatz. Ich ergänzte die crontab mittels

# crontab -e

mit folgendem Befehl:

...
0 4 * * *   rm -rf /tmp/beaker
...

Der Ordner wird nun pro-aktiv jede Nacht um 4 Uhr morgens zwangsweise gelöscht.

Dennoch hätte ich gerne die Möglichkeit, mittels Cacti den Zuwachs der Partition zu überwachen, um zu sehen, ob die Grösse stetig zunimmt, oder ob es einzelne Episoden mit plötzlichem Grosswachstum gibt.

Nachtrag

Allenfalls könnte man mit folgendem Script etwas basteln:

snmpd-tmpfs.sh

Tags: , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 27. August 2016

SNMPd schreibt standardmässig kein PID-Datei mehr

Ein kürzlich erfolgtes Update des SNMPd-Pakets auf meinem Debian-Server hatte zur Folge, dass meine monit-Installation den Service fälschlicherweise als offline meldete.

Dies, weil monit nach der PID-Datei des SNMP-Daemons Ausschau hält, um dessen Prozess-ID auszulesen und auf Existenz zu prüfen. Bei Debian liegt diese Datei unter /var/run/snmpd.pid.

Folgendermassen re-aktivierte ich die PID-Datei:

/etc/systemd/system/multi-user.target.wants/snmpd.service

Vor der Anpassung …

...
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f
...

… und nach der Anpassung:

...
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f -p /var/run/snmpd.pid
...

Anschliessend folgte noch ein Neustart des Daemons:

# systemctl stop snmpd
Warning: snmpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
# systemctl daemon-reload
# systemctl stop snmpd
# systemctl start snmpd

Und prompt meldete mir monit, dass der Service wieder online sei.

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Installing SNMP-Daemon (snmpd) on IPCop for remote monitoring

The Task

After some days of testing I finally found out a relative simple solution to run a SNMP-Daemon on my IPCop-Router.

Package management under Mac OS X

First of all, I had to deal with Debian-packages. This posed some problems to me, because I don’t have any linux box here except the one running IPCop, which hasn’t package-managers installed. After I dived into manuals for dpkg i was able to extract the files on my PowerMac running Mac OS X. Before you can execute the shell command below, you need to download and install Fink. After that, continue:

dpkg-deb -x <package>.deb <destination-dir>

Installation

You now do have the required files on your workstation, but yet they need to be put on the IPCop-box. Make use of an SFTP-Client, which requires the SSH-Service enabled on the router. With a SSH-connection to the box, I checked the error messages which occured upon start of the snmpd and then went out to look for the additional files required. The ’search file within packages‘-Function of some package-sites helped me a lot!

Packages needed

These 3 Debian-Packages are essential for your success. Download the .debs and extract them to a single folder with the command mentioned above:

  • snmpd (4.2.3-2)
  • libsnmp4.2 (= 4.2.3-2)
  • libwrap0

File locations

I had to copy all files over to IPCop manually, therefore I made this list to monitor all the files necessary.

/lib/libwrap.so.0
/usr/lib/libucdagent-0.4.2.so
/usr/lib/libucdmibs-0.4.2.so
/usr/lib/libsnmp-0.4.2.so

/usr/sbin/snmpd

Caveats

Don’t try to copy snmpd.conf over to the box. In my case, it prevented snmpd to act the way it should. I have no idea where the problem lied, but after deleting snmpd.conf, everything worked fine. I hope this saves you a lot of headaches.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen