Aus dem Leben eines Szlauszafs

Für lokale Netze ist ein DHCP-Server eine nützliche Einrichtung, ermöglicht er doch die automatische Adreßvergabe. Die meisten Consumer-DSL-Router (und nicht nur diese) haben entsprechende Funktionalitäten eingebaut; noch schöner und flexibler ist es aber natürlich, selbst einen entsprechenden Dienst bereitzustellen, weil man ihn dann genau so konfigurieren kann, wie man ihn gerne hätte, um neben der automatischen Vergabe von IP-Adressen auch bestimmten Rechnern feste Adressen zuzuweisen und zugleich im internen Netz eine Namensauflösung zu organisieren.

Dafür bedarf es im Prinzip dreierlei:

• Zunächst benötigt man einen DHCP-Server (dhcpd), bspw. den des ISC, der dann so konfiguriert werden muß, daß er die erwünschten Adressen an die Clients zuweist.
• Dann benötigt man einen DNS-Server, bspw. den BIND des ISC, der dann so konfiguriert werden muß, daß er Namen im lokalen Netz zu IPs auflöst und umgekehrt lokale IPs zu den richtigen Namen.
• Und letztlich muß man in einem zweiten Schritt die beiden so miteinander verheiraten, daß der DHCP-Server dem DNS-Server erzählt, welche IPs er an welche Maschinen dynamisch vergeben hat.

All das ist vergleichsweise einfach unter Debian möglich.

Im folgenden Beispiel gehe ich davon aus, daß das lokale Netz den IP-Bereich von 10.0.0.1-10.0.0.254 (10.0.0.1/24) umfassen soll und die Domain example.org verwendet wird. Der Host, auf dem DHCP- und DNS-Server laufen, heißt server.example.org und hat die (fest konfigurierte) IP-Adresse 10.0.0.1.

Über die Einrichtung des Monitoring-Tools Munin habe ich bereits vor 2 Jahren geschrieben. Mittlerweile habe ich meine Installation aus den Debian-Backports auf die Version 1.4.5 geupdatet, die deutlich ressourcenhungriger zu sein scheint; überdies sind mittlerweile auch mehr Hosts durch Munin zu überwachen. Beides führte zu einer spürbaren Grundlast auf dem (älteren) System, das bislang den Munin-Server darstellte; daher habe ich Munin nunmehr auf eine andere Maschine umgezogen, was deutlich sichtbare Performance-Verbesserungen gebracht hat, die sich schon in einer Laufzeitverkürzung darstellen.

Bei dem Umzug sollten aber auf jeden Fall die bereits erstellten Statistiken aus den letzten beiden Jahren erhalten bleiben, um nicht komplett von vorne beginnen zu müssen. Eigentlich sollte ja nichts leichter als das sein: Munin auf dem neuen Rechner installieren, die Konfiguration des alten Systems übernehmen, das neue System auf allen Nodes für den Abruf freischalten, testen, dann die gesammelten Daten auf dem alten Rechner packen, auf den neuen transferieren und dort wieder auspacken, Munin auf dem alten Rechner anhalten, fertig. Ungefähr so geht das auch tatsächlich - wenn denn diebeiden Systeme dieselbe Architektur haben. Wenn aber der alte Rechner ein 32bit-System ist und der neue ein 64bit-System, dann sind die erzeugten RRD-Dateien nicht kompatibel. Autsch. Aber auch dafür gibt es glücklicherweise eine Lösung, die ich einem alten Eintrag aus dem Cacti-Forum abgeschaut habe.

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, ...) schützen. Backups sollten daher

• regelmäßig durchgeführt werden,
• versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
  
• off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. “Rootserver”, also Mietserver, zu denen bei üblichen Angeboten auch ein sog. “Backupspace”, also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, ... - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage “belauschen” können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, ...) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

... oder: How to unbrick your Linksys BEFSR41.

Wie bereits an anderer Stelle geschildert, kämpfe ich mit Verbindungsabbrüchen an einem DSL-Anschluß. In diesem Zusammenhang habe ich gestern auch den dort bislang eingesetzten Linksys BEFSR41 “EtherFast Cable/DSL Router with 4-Port Switch” durch ein Neugerät ersetzt und dann für das Altgerät ein Update auf die aktuellste Firmwareversion durchgeführt (und zwar über das Webinterface). Das ging aber offensichtlich schief - möglicherweise mag der Router nur den Internet Explorer und keinen Firefox auf seinem Webinterface dulden, oder es gab andere Probleme; jedenfalls mochte nach Abschluß des Firmware-Uploads der Router nicht mehr mitspielen. Nach jedem Reboot grüßte er mit einer blinkenden Power-LED, was eine defekte Firmware kennzeichnet; die Weboberfläche steht dementsprechend gar nicht erst zur Verfügung.

Wie ich dann längerer Suche bei Google entnommen habe, kann aber auch in diesem Fall ein erneuter, korrekter Upload der Firmware via TFTP erfolgen. Dazu muß der Router durch Powercycle rebootet werden und dann binnen der nächsten ~ 5 Sekunden ein Firmware-Image mittels TFTP aufgespielt werden. TFTP ist u.a. bei Windows bereits dabei; es gibt natürlich auch diverse Shell- und GUI-Clients für alle Betriebssysteme.

Allerdings genügt das nicht; der BEFSR41 möchte nämlich für den TFTP-Upload das Routerpaßwort mitgesendet bekommen, ansonsten verweigert er die Annahme einer neuen Firmware. Allerdings unterstützen gebräuchliche TFTP-Clients keine Paßwortübertragung (wohl deshalb, weil eine Authentifizierung via Paßwort gar kein Bestandteil des Protokolls ist, sondern eine firmenspezifische Ergänzung). Der im Netz häufig zu lesende Ratschlag, das Paßwort des Routers auf “” zu setzen, also zu leeren, hilft natürlich nicht weiter, wenn der Router gar nicht mehr ansprechbar ist ...

Die einzige Lösung ist daher die Verwendung eines TFTP-Clients, der sich mit Paßwort anmelden kann. Früher fand sich ein solcher (mit GUI, für Windows) wohl auf dem FTP-Server von Linksys, jetzt bedarf es einiger Suche, um dieses Programm oder ein vergleichbares zu finden. Erfolgreich war ich u.a. mit diesem Link zur Linksys-Webseite.

Damit war die Sache dann einfach: Eingaben im Client (IP des Routers, Paßwort “admin”, Firmware-Datei) vorbereiten, Powercycle, abwarten, bis der Router auf “ping” reagiert, und dann den TFTP-Upload vornehmen. Voilà! Ein Reboot später spielt der Router dann auch wieder mit.

Sehr praktisch ist es bei einem Bugtracker, wenn er mit dem verwendeten Versions-/Sourcecode-Verwaltungssystem (SCM-System, source code management) interagieren kann, Änderungen im Code, die - laut Kommentar (Commit-Message) - einen bestimmten Fehler beheben, also direkt auch dazu führen, daß der entsprechende Fehlerbericht (Bugreport) als erledigt gekennzeichnet wird. Man kennt dieses Verhalten - bspw. - vom Debian-Bugtracker.

Grundsätzlich ist das auch schon immer mit Mantis möglich; allerdings war die bisher vorhandene Unterstützung rudimentär und primär auf SVN abgestellt; sie wurde auch in der aktuellen Entwicklungsversion 1.3 entfernt. Seit Anfang 2009 gibt es nämlich von einem der Mantis-Entwickler, John Reese, ein Plugin namens Source Control Integration, das sich beim Bugtracker für Mantis selbst bereits seit Monaten im Echtbetrieb bewährt hat. Es liefert ein Framework für die Anbindung beliebiger Versionsverwaltungssysteme, und fertige Plugins für die Anbindung an git via GitHub oder GitWeb und an SVN via SourceForge oder WebSVN sind direkt dabei.

Leider ist auch hier die Dokumentation der schwache Punkt. Eine solche fehlt nämlich bisher völlig; einen Einstieg liefert einzig ein Blogbeitrag vom 07.01.2009, der die Vorgehensweise beschreibt. Weitere Blogbeiträge (von März und Oktober 2009) umreißen die technischen Grundlagen und beschreiben den Einsatz für Subversion, helfen aber ansonsten auch nicht wirklich weiter.

Was mich bei meiner Nutzung von git unter Windows noch etwas störte war vor allem, daß ich für den Zugriff auf externe Repositories bisher auf TortoiseGit angewiesen war, weil Git on Windows (msysgit) nicht recht zur Kommunikation über SSH bereit war; angeblich wurde nie der passende Schlüssel gefunden, obwohl eigentlich PLink und Pageant aus dem Putty-Paket installiert waren und mit TortoiseGit ihre Arbeit auch prima taten. Die Google-Recherche führte mich dann allerdings zu einem passenden Beitrag, und nach einigem ausprobieren kann ich bestätigen, daß die dort genannte Lösung funktioniert:

• Git on Windows (msysgit) installieren
• Putty installieren (soweit erforderlich)
• Pageant konfigurieren (soweit war ich schon)
• Umgebungsvariable GIT_SSH auf PLink setzen
• GitBash und/oder GitGui neu starten (!)

Danach funktionierte die Sache bei mir wunderbar.

Die Umgebungsvariable GIT_SSH setzt man unter Windows XP in den “Systemeigenschaften” (Rechtsklick auf “Arbeitsplatz” oder “My Computer” und dann “Eigenschaften”) auf der Registerkarte “Erweitert” unter dem Button “Umgebungsvariablen” unter “Systemvariablen”. Ein beherzter Klick auf “Neu” fördert ein Eingabefeld zutage, in dem man nunmehr “GIT_SSH” und den kompletten Pfad zur Datei “PLink.exe” - bspw. “C:\Programme\PuTTY\plink.exe” - eingibt. Neustart von msysgit nicht vergessen!

Voilà! Bei mir funktionierte die SSH-Übertragung dann ohne jedes Problem.

Wie ich bereits im Februar beschrieben habe, benutze ich unter Windows msysgit bzw. “Git on Windows”. Die GUI-Variante ermöglicht die meisten denkbaren Aktionen in sehr bequemer Weise durchzuführen; sie krankt allerdings - aus meiner Sicht - arg an ihrer Übersetzung, die sämtliche Menüeinträge und damit natürlich auch Fachbegriffe umfaßt und manchmal zu Rätselraten führt, was genau gemeint sein mag. “Zweig” ist ja noch klar, “Zusammenführen” für “Merge” auch, aber das “Version” für “Commit” steht erschließt sich nicht sofort. Und Menüpunkte unterhalb von “Zweig” wie “Erstellen”, “Umstellen” oder “Zurücksetzen” sind auch alles andere als klar - “Erstellen” ist ohne Frage “Create”, aber “Umstellen”? Gut, man kann vielleicht noch darauf kommen, daß das für “Checkout / Switch” steht ... aber bedeutet “Zurücksetzen” jetzt “Reset” oder “Rebase”? Usw. usf. ... Da wäre doch eine englische Bedienungsoberfläche eine tolle Sache, da weiß man wenigstens, welche Funktion jeweils gemeint ist, und kann die dann ggf. nachschlagen.

Es scheint leider derzeit noch keine Möglichkeit zur manuellen Auswahl einer Sprache zu geben, auch nicht durch Setzen von Environment-Variablen (zumindest hat Google sich insoweit ausgeschwiegen); es wird automatisch auf die Systemsprache abgehoben. Eine Lösung gibt es dennoch - wenn man dafür sorgt, daß die Programme ihre deutschen Sprachdateien nicht mehr finden, fallen sie auf den englischen Default zurück, und das ist ja genau das, was wir wollen.

Die Sprachdateien liegen in %ProgramFiles%\Git\share\git-gui\lib\msgs bzw. %ProgramFiles%\Git\share\gitk\lib\msgs; dort muß jeweils nur die Datei “de.msg” entfernt - oder umbenannt - werden, und alles wird gut (bzw. in diesem Fall englischsprachig). Nach Updates ist dieser Schritt natürlich erneut erforderlich.

Ein weiteres nettes Feature von git sind die Möglichkeiten, die git archive bietet. So läßt sich der Inhalt eines git-Repositories leicht in ein tar-File packen, bspw. für ein Release.

Voraussetzung dafür ist beim Zugriff über git-daemon, daß der entsprechende Service aktiviert ist; für das Debian-Paket bedeutet das die Erweiterung des Aufrufs in /etc/sv/git-daemon/run um den Parameter “--enable=upload-archive”.

Dann aber kann mit einem Aufruf wie

git archive --format=tar --remote=git://git.domain.example/$REPO.git --prefix=$PREFIX/ $TAG | gzip > $REPO.tar.gz

aus dem Repository $REPO.git dessen Inhalt bei Commit (oder an der Spitze des Branches, oder an dem Tag) $TAG in eine .tar.gz-Datei gepackt werden, wobei die Dateien ein $PREFIX vorangestellt bekommen.

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-2.17/ 2.17 | gzip > myprog-2.17.tar.gz

erzeugt also aus dem Repository myprog.git in der mit “2.17” getaggten Version eine Datei myprog-2.17.tar.gz, die alle im Repository enthaltenen Dateien mit dem Verzeichnis-Präfix “myprog-2.17/” enthält.

Das ganze läßt sich noch etwas aufpeppen, wenn man bspw. bestimmte Dateien (.gitignore, ...) aus dem Repository nicht im Tarball haben möchte und/oder noch andere Änderungen vornehmen will, wie bspw. die Erzeugung eines README aus der eingebetteten POD-Dokumentation:

#! /bin/bash
# do a release of myprog
# $1: version number

# make tempdir
tempdir=`mktemp -td myprog-XXXXX`

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-$1/ $1 | (cd $tempdir && tar xf -)

cd $tempdir/myprog-$1/
pod2text -l myprog.pl README
rm .gitignore

cd $tempdir
tar -czf /var/www/myprog/download/myprog-$1.tar.gz myprog-$1/
rm -r $tempdir

Und schließlich kann man auf diese Weise auch nur eine einzelne Datei aus dem Repository extrahieren:

git archive --format=tar --remote=git://git.domain.example/repository.git master beispiel.txt | tar xf -

extrahiert die Datei beispiel.txt aus der Spitze des Branches master des Repositorys repository.git.

Ich finde das alles ausgesprochen praktisch.

INN bietet vielfältige Möglichkeiten der Benutzerauthentifizierung an. Wenn man einer größeren Anzahl von Benutzern einen Zugang einräumen will, bietet es sich an, die notwendigen Daten - Benutzerkennung, Paßwort, etc. - in einer Datenbank zu halten, bspw. in einer MySQL-Datenbank.

Eine denkbare Lösung dafür, die neben Benutzerkennung und Paßwort auch Namen und E-Mail-Adresse des Benutzers erfaßt sowie ein Flag für aktive/inaktive Benutzer und eine Trennung nach verschiedenen Zugriffsstufen kennt sowie den Zeitpunkt des letzten Logins festhält, möchte ich hier vorstellen. Dazu gehört über das hier vorgestellte Script für den INN hinaus natürlich noch ein passendes (Web-)Interface, mit dem Benutzer angelegt und gelöscht sowie Paßworte geändert werden können etc.

Die Datenbankstruktur sieht folgendermaßen aus:

CREATE TABLE IF NOT EXISTS `users` (
  `userid` int(11) NOT NULL auto_increment,
  `user` varchar(16) collate latin1_bin NOT NULL default ‘’,
  `password` varchar(16) collate latin1_bin NOT NULL default ‘’,
  `active` tinyint(1) NOT NULL default ‘1’,
  `username` varchar(60) collate latin1_bin default NULL,
  `usermail` varchar(60) collate latin1_bin default NULL,
  `domain` varchar(40) collate latin1_bin default ‘<EDITME>’,
  `llo` date default NULL,
  PRIMARY KEY  (`userid`),
  UNIQUE KEY `user` (`user`)
);

Die Felder sollten weitgehend selbsterklärend sein; “llo” steht für “last logged in”.

Eines muß ich von den Basteleien aus der letzten Woche bzw. vom Sonntag noch nachtragen: ich habe bei meinem vor ungefähr einem Jahr installierten Munin die Mailbenachrichtigungen aktiviert und die Limits für “warning” und “critical” entsprechend angepasst, soweit das erforderlich war. Jetzt werde ich über Probleme ggf. alle 5 Minuten - nach jedem Munin-Poll - per E-Mail informiert.

Die Konfiguration ist hinreichend einfach. Zunächst sind die Benachrichtigungen auf dem zentralen Munin-Host im globalen Bereich der /etc/munin/munin.conf zu konfigurieren, für Benachrichtigungen per E-Mail bspw. so:

contact.thomas.command mail -s “Munin notification ${var:host}” thomas@provider.example
contact.thomas.always_send warning critical

Es können verschiedene Benachrichtigungsziele (Kontakte) definiert werden, wenn bspw. je nach Host unterschiedliche Ansprechpartner zu benachrichtigen sind; hier habe ich das Ziel “thomas” konfiguriert durch Angabe eines Betreffs und einer Zieladresse und der Zustände, bei denen Benachrichtigungen versandt werden sollen.

Danach können pro Host(gruppe) die zu verständigenden Kontakte definiert werden:

[host.domain.example]
contacts thomas

Zu verwenden ist natürlich einer der zuvor definierten Kontakte, hier eben “thomas”. An diesen Kontakt werden dann die entsprechenden Benachrichtigungen versandt.

Sinnvollerweise sollten - ebenfalls pro Host - die nicht passend gesetzten oder gar aufgrund von Konfigurationsproblemen völlig unsinnig gesetzten Limits korrigiert werden durch Einfügen von Zeilen wie

sensors_temp.temp2.warning 55
sensors_temp.temp2.critical 65

oder ähnlich. Wo Handlungsbedarf besteht, erkennt man ganz einfach am Mailbombardement nach der Aktivierung der Benachrichtigungen.

Natürlich können Benachrichtigungen nicht nur per E-Mail versandt werden. Für die Einzelheiten verweise ich auf die Munin-Dokumentation.