Alte Bekannte, neu ausgegraben: smokeping

Aus nicht wirklich geheimen Gründen gibt es bei meinem Brötchengeber ein paar marginale Änderungen, und um die Sichtbarkeit zu erhöhen, habe ich mich grade mal wieder mit Smokeping beschäftigt.

Neu ist das nicht, schon, als ich damals dort startete, fing ich an, einen Smokeping-Server laufen zu lassen, um damals leider häufige LAN-Probleme einkreisen und, vor allem, dem IT-Support gegenüber dokumentieren zu können. Die Zeiten von Koffeinschocks durch zwangsweise erweiterte Kaffeepausen sind zwar glücklicherweise vorbei — aber da alles auf links gezogen wird, kommt das bekannte Tool wieder raus aus der Mottenkiste zu einem praktischen Einsatz.

Nachdem ich das also beruflich gemacht habe, habe ich es am Freitag abend mal eben auch auf die heimische Wolke losgelassen. Mittlerweile ist das Geflecht von verschiedenen Inseln, die per dieser oder jener Tunneltechnik verbunden sind, doch recht komplex, und dem einen oder anderen Nutzer kann ich durchaus eine URL an die Hand geben zur Vor-Analyse.

Der Grund für diesen Blogbeitrag allerdings ist ein anderer — denn, wie eigentlich zu erwarten, gab es Probleme ;)

Zu allererst sei da das Debian-Lenny-basierte OpenVPN-Gateway in Gütersloh genannt: ein debianisierter Seagate Dockstar. Während der (seit Sommer temporäre) Raspberry Pi in Berlin – von fehlender VPN-Performance abgesehen – problemlos, dank Raspbian-Wheezy, mit dem ebenfalls Wheezy-basierten Smokeping-Master zusammenarbeitete, kamen vom Debian-Lenny-basierten System in Gütersloh keine Daten.

Zwar meckerte Smokeping beim Start …

### fping seems to report in 0.99999849104012 milliseconds (old version?)

… aber was soll man mit der Meldung anfangen? Erst eine komplexere Google-Recherche führte mich zum entsprechenden Bug-Report für »fping 2.4b2-to-ipv6-15«.
Quintessenz: »fping 2.4b2-to-ipv6-15« ist (mindestens auf Sheeva-CPUs) für die Tonne. Da ich grade anderes zu tun habe als mutig »apt-get update && apt-get dist-upgrade« auf meinem hiesigen Tor zur Welt zu tippen, habe ich das wheezy-Binary (aus »fping 3.2-1«) von einem anderen armel-Host rüberkopiert, es einem prinzipiellen Funktionstest (sprich: keine fehlenden Abhängigkeiten?) unterzogen und dann anstelle des orginalen fpings installiert. Jetzt klappt’s auch mit dem Nachbarn …

Smokeping

Zum zentralen Host klappt es, wie es soll …

Somit habe ich auch für mein Netz smokeping mit Master-Slave in Betrieb genommen: die DC-Instanz ist der Master, Linux-Kisten an den Standorten die Slaves. Dabei kam allerdings der Wunsch auf, einige Tests nur zwischen Standorten zu machen, d. h. der zentrale Master testet bestimmte Ziele nicht (weil er sie z. B. gar nicht erreichen kann, z. B. interne Tunnelendpunkte oder sowas). Lustigerweise hat smokeping sogar dafür eine Lösung: »nomasterpoll = yes« bei einem »Target« soll tun, was es sagt — nur tat es das bei mir nur sehr selektiv ;-)
Smokeping

Der eigentlich interessante Teil (Standorte untereinander) funktioniert nicht :(

Letzlich war das ein Layer-8-Problem: während der smokeping-Prozeß (unter Debian zumindest) mit UID und GID smokeping läuft, läuft die Interaktion mit den Slaves über HTTP und damit unter den Rechten des Webserver-Users — bei Debian also www-data. Der smokeping-Prozeß legt die rrd-Dateien an – als smokeping/smokeping –, der Slave liefert seine Daten an den Webserver und der dortige smokeping-Teil kontaktiert (leider) nicht den Server, sondern versucht – als www-data/www-data – die rrds zu aktualisieren. Bang, keine neuen Daten :-(

Letztlich habe ich also die Berechtigungen wie folgt vergeben:

# chown www-data -R /var/lib/smokeping
# chmod g+w -R /var/lib/smokeping

Führe ich dies auf den Server kurz nach jedem restart/reload aus, klappt’s auch endlich mit den Slaves, wie es soll. Im Nachhinein logisch, wenn man davor sitzt, nicht ganz so offensichtlich.

2 thoughts on “Alte Bekannte, neu ausgegraben: smokeping

  1. Tja – ich mache auch immer noch mit smokeping rum – auch im Master-Slave Setup (das mit den Rechten hätte ich Dir sagen können, das setup auch des Pakets ist an der Stelle einfach braindead). Ich brauche es primär um die Verfügbarkeit von Sites aus diversen Backbones zu testen und habe es dazu auf “zur Verfügung” gestellten DSL Anschlüßen gebaut.

    • Hmm, was bei mir schein’s nicht klappt, ist das Aktualisieren der Slave-Konfiguration, wenn der Master eine neue hat. Reload auf dem Master scheint die Slaves nicht zu tangieren (alles smokeping-2.6.x für Debian Lenny/Wheezy) :(

      Und EchoPingHttp von der Amazon-Instanz liefert auch nix; da mag das aber mit Lenny zusammenhängen, smokeping mußte ich da von Wheezy und dann mit apt-get -f install draufnageln. Muß nachher mal gucken, vielleicht fehlen Pakete.

Comments are closed.