Posts Tagged ‘Perl’

Montag, 13. Juni 2011

cacti pingt nicht mehr

Heute habe ich mich endlich einem Problem angenommen, das mich mit meiner Cacti-Installation seit mehr als einem Jahr plagt: Die Ping-Werte für Google werden nicht mehr aufgezeichnet.

Nachdem ich unter

  1. Console
  2. System Utilities
  3. View Cacti Log File

nach „ping“ gesucht hatte und feststellen musste, dass das Script ~/cacti/scripts/ping.pl permanent „U“ als Wert zurücklieferte, begann das Debugging.

Auch die manuelle Ausführung von

~/cacti/scripts/ping.pl www.google.com

brachte ein „U“ als Resultat hervor. Was cheibs?

Im Grunde ruft das Perl-Script folgenden Kommandozeilenbefehl auf und filtert im Anschluss den Rückgabe wert:

ping -c 1 www.google.com | grep icmp_seq | grep time

Als ich dies auf der Kommandezeile ausführte, wurde ein leerer Wert zurückgegeben.

Nachdem ich ein Blick auf das Resultat von

$ ping -c 1 www.google.com
PING www.l.google.com (74.125.79.104) 56(84) bytes of data.
64 bytes from ey-in-f104.1e100.net (74.125.79.104): icmp_req=1 ttl=53 time=34.6 ms

--- www.l.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.695/34.695/34.695/0.000 ms

geworfen hatte, war mir sofort klar, was das Problem war: grep nach icmp_seq kann nicht von Erfolg gekrönt sein, weil hier offenbar icmp_req steht.

Das Problem ist im ping.pl does not account for ping using icmp_req rather than icmp_seq in some versions of ping festgehalten: Offenbar gab es bei ping irgendwann einmal eine Anpassung am Code, die nur noch diese Ausgabe zur Folge hatte.

Nach einem Blick auf den Patch nahm ich die Anpassung an ~/cacti/scripts/ping.pl selber vor — irgendwie einfach ein wenig anders als vorgeschlagen:

...
open(PROCESS, "ping -c 1 $host | grep -E 'icmp_(r|s)eq' | grep time |");
...

Damit klappte es wieder.

Nachtrag

Unter einer Synology DiskStation klappt es auch trotz dieser Anpassung nicht. Der Ping-Befehl gibt folgendes aus:

ping -c 1 192.168.8.8
PING 192.168.8.8 (192.168.8.8): 56 data bytes
64 bytes from 192.168.8.8: seq=0 ttl=64 time=0.223 ms

Keine Spur von icmp_seq, stattdessen steht dort nur seq. Somit passt man das Script finalerweise folgendermassen an:

...
open(PROCESS, "ping -c 1 $host | grep -E '(r|s)eq' | grep time |");
...

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 11. Dezember 2008

Perl 5 sucks!

Heute gerade erlebt:

For example, to install a module from the CPAN, you must first answer several questions to configure the CPAN client. Then, you download a package, which runs a small program, which generates a Makefile, which configures, builds, tests, and installs the module — if everything went correctly.

Quelle: Five Features Perl 5 Needs Now – O’Reilly Broadcast

Ich wollte mir App::Ack installieren. Zuerst versuchte ich es als normaler User, was aber (wohl wegen den Berechtigungen) nicht geklappt hat. Der Fragekatalog wurde durchgespult, viele Module heruntergeladen und irgendwo unter den vorbeiflimmernden Zeilen gab es dann irgendwann einmal eine Fehlermeldung, die ich natürlich übersehen habe.

Die Installation via sudo klappte leider auch nicht viel besser – vorerst jedenfalls. Auch hier lief irgendein Test schief und Ack wurde nicht installiert. Zwar war anhand der Fehlermeldung erkennbar, dass etwas schief gelaufen war – wie das Problem zu beheben sei, erfuhr ich aber nicht. Es ist dem Zufall zuzuschreiben, dass ich im Anschluss einige als „optional“ bezeichnete Test-Pakete installieren liess – und plötzlich war ack unter /usr/bin/ vorhanden. Heureka.

Was Perl braucht? Ein apt-get install ack – fertig. Obwohl ich Perl nicht gut genug kenne, denke ich, dass CPAN das Spiegelbild seiner Benutzer und seiner Programmierer ist: Umständlich, kompliziert, technikbesessen. Und somit für Endbenutzer wie mich nicht geeignet.

Tags: ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen