Aus dem Leben eines Szlauszafs

Seit diesem Wochenende steht jetzt - wie geplant und angekündigt - die aktuelle und brandneue Debian-Version 6.0 “Squeeze” zur Verfügung. Der Release-Prozess war in diesem Jahr nicht nur von einer Vielzahl von Release-Parties, sondern auch von einer fortlaufenden Berichterstattung via Twitter bzw. identi.ca begleitet.

Mein neuer Rechner läuft bekanntlich bereits unter Debian Squeeze; mit den Updates der bestehenden Server werde ich hingegen noch ein wenig warten, bis möglicherweise bestehende Probleme erkannt und behoben sind, Erfahrungen von anderen Updatern vorliegen, ich wieder über ein größeres Budget an freier Zeit verfüge und mal ein Wochenende für eventuell notwendig werdende Reparaturen zur Verfügung habe.

Doch Debian hat nicht nur released - man hat die Gelegenheit genutzt und auch direkt den Webseiten ein neues Gesicht gegeben, also den lange geplanten und vorbereiteten Relaunch pünktlich zum Release-Wochenende umgesetzt.

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.

Gestern schrieb ich schon, daß ich mal wieder wahrlich zu nichts komme (jedenfalls nicht zu den Sachen, die ich mir vorgenommen hatte) - daher mußte bislang auch die Einrichtung des neuen Rechners (die ich eigentlich in der ersten Woche des neuen Jahres abzuschließen hoffte) zurückstehen. Heute habe ich damit aber dann einmal - mit Unterstützung aus dem IRC - angefangen und ein Debian Squeeze (dessen Release ja unmittelbar bevorsteht) installiert. Da die Maschine per KVM-Switch an Monitor, Tastatur und Maus hängt, habe ich mich mittlerweile entschlossen, sie nicht nur als Server, sondern auch als Desktop zu nutzen, auch um einmal ein Gefühl dafür zu bekommen, wie sich ein Linux auf dem Desktop so anfühlt - denn obschon ich seit gut 10 Jahren mit Linux als Server-OS umgehen, arbeite ich auf dem Desktop immer noch unter Windows (zunehmend ergänzt um Tools aus der unixoiden Welt).

Aufgrund meiner bisher mangelnden Erfahrung mit der Installation eines Systems (ich kenne den Arbeitsgang in der Regel erst beginnend mit der Anpassung eines vom Provider aufgespielten Images und habe Erfahrung im wesentlichen mit dem Zugang via SSH, nicht mit der Arbeit an der Konsole ...) und der Tatsache, daß Debian für das bevorstehende Release alle nicht-freie Firmware aus dem main-Archiv entfernt hat, befürchtete ich erhebliche Probleme, schließlich sind mir aus den vorgenannten Gründen im weitesten Sinne hardwarenahe Arbeiten (Treiber, Kernel, Partitionierung von Platten, Auswahl des Filesystems und Einrichtung von RAID, LVM und Co.) nicht wirklich vertraut. Der Ablauf erwies sich aber als angenehm einfach.

Nach dem Herunterladen eines Netinstall-Images aus den täglichen Snapshots und dessen Brennen auf CD wurde mir nach dem Boot angeboten, den graphischen oder den konsolenorientierten Installer zu starten, wobei ich mich für letzteres entschied; danach wurde ich durch die Ersteinrichtung geführt, bis ... tatsächlich eine fehlende Firmware (rtl8168d-1.fw) gefunden wurde, sinnigerweise ausgerechnet für die (Realtek-)Netzwerkkarte (ohne die sich ein Netinstall dann vermutlich nicht so richtig erfolgreich gestalten dürfte). Glücklicherweise hatte ich mich bereits vorher informiert, wo Debian die nicht-freie Firmware jetzt versteckt hat, so daß ich den entsprechen Tarball herunterladen und via USB-Stick bereitstellen konnte. Das half aber nicht; weder der Tarball noch die ausgepackten Debs konnten den Installer glücklich machen. Weitere Suche mit dem Namen der vermißten Firmware führte dann zu einem Bugreport und dem entsprechenden Firmware-Paket mit Realtek-Firmware; ich habe dann entsprechend das dort verlinkte Tar-Archiv heruntergeladen, ausgepackt und - nach mehreren erfolglosen Versuchen - die Realtek-Firmware in das Root-Verzeichnis des USB-Sticks gepackt. Jetzt war der Installer glücklich.

Im weiteren Verlauf gelang es mir allerdings dennoch nicht, eine Netzwerkverbindung aufzubauen, was die weitere Installation etwas hinderte, insbesondere soweit Repositories eingebunden und Sicherheitsupdates geladen werden sollte; nach deren Abschluss und einem Reboot war jedoch eine Netzwerkverbindung vorhanden. Hilfreich für den absoluten Anfänger *hüstel* ist es übrigens in solchen Fällen zu wissen, daß man mit Alt-4 ein Terminal mit den Logs und Fehlermeldungen angezeigt bekommt, mit Alt-1 wieder zurückkomt und ggf. auf einem der anderen TTYs eine Shell starten kann. Dokumentiert ist das im Install-Manual.

[Update vom 23.01.2011: Offenbar handelt es sich bei dem Problem mit der Firmware für die Realtek-Netzwerkkarte noch um einen Bug, der mit dem ersten Point-Release behoben werden soll - sowohl hinsichtlich der Probleme des Installers, die Firmware auf dem USB-Stick zu finden, als auch hinsichtlich der fehlenden Netzwerkkonnektivität nach dem Finden der Firmware.]

Der Rest der Installation bis zum ersten Reboot verlief ereignislos, gut unterstützt und dokumentiert - es gelang mir auch auf Anhieb (naja, mit einigen Versuchen), aus meinen beiden Festplatten ein RAID 1 (mit gesonderter Bootpartition) zu erstellen, darüber LVM zu legen, die einzelnen Logical Volumes anzulegen und zu formatieren, ohne daß ich (abgesehen von Hinweisen zu der grundsätzlichen Auswahl des Filesystems und der Partitionierung) irgendeine Unterstützung via IRC gebraucht hätte.

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.

Als Hobby-Admin *räusper* lernt man ständig dazu. Bekannt und bewußt war mir schon, daß nach (Sicherheits-)Updates von Bibliotheken, die von verschiedenen Programmen genutzt werden (man denken an OpenSSL), die entsprechenden laufenden Prozesse neu gestartet werden müssen, weil sie nur dann die dynamisch geladenen Bibliotheken neu laden und zuvor mit der alten Version arbeiten, was insbesondere bei sicherheitsrelevanten Updates nicht besonders hilfreich ist. Bisher ging ich allerdings (blauäugig) davon aus, daß die Paketverwaltung das schon richten wird. Durch einen Beitrag von Paul Wise in der Debian-Developer-Mailingliste wurde mir nun bewußt, daß das - jedenfalls / auch unter Debian - nicht der Fall ist, die betreffenden Dienste also manuell neu gestartet werden müssen.

Hilfreich ist in diesem Zusammenhang das im Paket debian-goodies enthaltene Tool checkrestart, das überprüft, welche laufenden Prozesse noch auf Dateien zugreifen, die mittlerweile gelöscht wurden, und diese auflistet (zusammen mit ggf. vorhandenen init-Scripts, um die Dienste neu zu starten).

Mantis (aktuell in der Version 1.2.1) ist ein ganz netter Bugtracker, also ein Ticketsystem (Fallbearbeitungssystem) für die Softwareentwicklung, dessen auffallendstes Manko allerdings die unterirdische Qualität der Dokumentation (weitgehend schlicht nicht vorhanden, ansonsten grob unvollständig oder weit veraltet) ist. *seufz*

“Mantis Graphs 1.0” ist ein Plugin für Mantis, das graphische Darstellungen ermöglicht, und ich habe heute längere Zeit damit verbracht, es in Betrieb zu setzen, nachdem es immer nur “unable to read/find font” von sich geben wollte. Einer der ersten Schritte war die Installation der msttcorefonts (aptitude install ttf-mscorefonts-installer), aber das genügte nicht. Längeres Debugging mit eingestreuten Statements im Quellcode ergab schließlich, daß Mantis weder das passende Font-Verzeichnis erkennen noch - bei expliziter Angabe des Verzeichnisses in der Konfiguration mit $g_system_font_folder - die Fontdatei laden wollte. Die Lösung dafür fand sich in der Dokumentation der PHP-Funktion file_exists(): diese liefert auch dann false zurück, wenn auf die entsprechende Datei aufgrund von safe_mode-Restriktionen nicht zugegriffen werden kann ...

Und natürlich ist das der Fall: das Font-Verzeichnis - bpw. /usr/share/fonts/truetype/msttcorefonts/ - gehört root, und die Font-Dateien auch. Jedenfalls ist Owner dieser Dateien niemals der Webserver oder der Benutzer, unter dessen Kennung die PHP-Scripts dank su_php o.ä. ausgeführt werden. *brummel*

Es bleibt demnach nur der Verzicht auf die Grafiken oder die Deaktivierung von safe_mode (für Mantis).

gitweb ist, wie vorgestern beschrieben, eine schöne Sache - aber nicht immer will man seine Repositories jedermann zugänglich machen. Schön wäre es doch, wenn man die Möglichkeit hätte, auch den Zugriff auf gitweb an eine Anmeldung zu koppeln und so nur für befugte Benutzer zu erlauben. Eine Möglichkeit dazu will ich nachstehend schildern, orientiert an einem Beitrag im Blog von Leho Kraav.

Weitere, vielleicht hilfreiche Anregungen dazu kann man ergoogeln, bspw.

• Using apache authentication with gitweb, gitosis – repository access control
• madduck's gitweb.conf
• Securing gitweb

u.a.

Wie ich bereits schrieb, habe ich mich in den letzten Tagen etwas näher mit dem Versionskontrollsystem (VCS, oder auch SCM für “Source-Code-Management”) git beschäftigt. Das macht natürlich nur bedingt Spaß - und Sinn -, wenn die Repositories nur auf dem heimischen Rechner liegen; um wirklich universal auf sie zugreifen zu können und auch die Zusammenarbeit mit anderen zu ermöglichen, sollten die Repositories irgendwo im Netz stehen, und eine nette Weboberfläche, die auch einen Zugriff über den Browser - ohne weitere Software - ermöglicht, um den aktuellen Stand der Bearbeitung zu sehen, Commits zu prüfen und ggf. einen Snapshot zu ziehen, wäre auch nicht schlecht.

Um mir die Anlage von Repositories und das Zusammenspiel mit den anderen Komponenten zu erleichtern und auch für erweiterte Anforderungen wie verschiedene Zugriffsrechte für die jeweiligen Repositories gerüstet zu sein, habe ich mich für die Verwaltung der Repositories für gitosis entschieden; als Weboberfläche will ich gitweb nutzen, und für den Zugriff via git dann git-daemon. Installiert habe ich dazu die jeweiligen Pakete aus Debian Lenny bzw. den Debian-Backports.

Dieser Tage war mal wieder ein Kernelupdate einzuspielen. Normalerweise mache ich das Maschine für Maschine, um bei möglicherweise auftretenden Problemen nur ein System bis zur Lösung lahmzulegen, und eigentlich nie abend, wenn ich eigentlich nur noch ins Bett gehen sollte. Dieses Mal dachte ich mir, das könne ich “noch eben schnell” erledigen - famous last words. Und weil es schnell gehen sollte, habe ich den Update-Prozess mehr oder weniger gleichzeitig gestartet und die ersten beiden Maschinen dann auch parallel rebootet. Während ich dann darauf wartete, daß sie ordnungsgemäß wieder hochkommen, hatte ich die übrigen Updates durchlaufen lassen.

Nur ... kamen die beiden rebooteten Maschinen nicht wieder hoch. Nada. Und natürlich handelte es sich dabei um gehostete Server, und natürlich um ältere solche, die über keine remote console verfügen. Nicht, daß mir das zwingend geholfen hätte.

Also hilft nur fluchen und ein Reboot in das sog. Rettungssystem, ein Minimal-Linux, das eine Untersuchung des Systems erlaubt. Und während ich noch grübelte und in den Logs nach möglichen Ursachen suchte, kam mir auch schon ein Gedanke - beides waren Altsysteme, die als Bootloader noch mit LILO, nicht grub, ausgestattet sind. Und ich konnte mich jedenfalls nicht bewußt erinnern, beim Upgrade irgendwelchen Output von LILO gesehen zu haben ... Also die Partitionen ins Rettungssystem mounten, in das Echtsystem chrooten, lilo ausführen, unmounten, das Echtsystem rebooten und das beste hoffen.

Und, siehe da: das war die Lösung.

Jetzt frage ich mich nur: War das immer schon so, daß man bei einem Debian nach dem Kernelupdate von Hand lilo ausführen mußte? Oder wurde das früher - unter Sarge oder Lenny - nicht automatisch von einem postinstall-Script gemacht? kopfkratz Und wenn letzteres: wie stelle ich dieses Verhalten wieder her?

Nach dem - inzwischen auf allen Rechnern abgeschlossenen - Upgrade auf Debian Lenny beklagte ich unter anderem ein Volllaufen des Root-Filesystems auf einer Maschine, das ich damals bei der Einrichtung etwas arg knapp bemessen hatte. Mittlerweile stellte sich heraus, dass der verbliebene Platz noch nicht einmal mehr für das Einspielen von Kernel-Updates ausreichte; so geht das natrülich auf Dauer nicht.

 

Auf der Suche nach einer Lösung stellte ich dann - glücklicherweise - fest, dass der große Platzverbrauch seine Ursache vor allem darin hatte, dass von allen jemals aktiv gewesen Kernel noch die zugehörigen Module auf der Platte lagen, insgesamt vier Verzeichnisse voll. Nach Beseitigung eines dieser Modul-Verzeichnisse (zugehörig zu einem schon weggeputzten Kernel - sah es mit dem Platz dann schon viel, viel besser aus, und auch das Kernel-Update ließ sich brav installieren.

So soll es sein.