Aus dem Leben eines Szlauszafs (Entries tagged as debian)

Debian 6.0 Squeeze ist released

thh@inter.net (Thomas Hochstein) — Sun, 06 Feb 2011 18:36:00 +0100

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.

DHCP-Server und automatische DNS-Zone-Updates

thh@inter.net (Thomas Hochstein) — Fri, 21 Jan 2011 19:46:00 +0100

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.

1. Installation und Einrichtung des DNS-Servers

aptitude -r install bind9

Die DNS-Zonen für das lokale Netz sollen später dynamische Updates zulassen; aufgrund der dann notwendigen Schreibrechte für den Benutzer bind auf diese Dateien darf man sie unter Debian nicht in /etc/bind/ anlegen, sondern im dafür vorgesehenen Verzeichnis /var/lib/bind. Also legen wir eine Zone-Datei /var/lib/bind/example.org für die Vorwärtsauflösung an, in der auch schon die Maschinen stehen, die feste IP-Adressen vergeben bekommen sollen:

$ORIGIN .
$TTL 604800     ; 1 week
example.org            IN SOA server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN example.org.
server                  A       10.0.0.1
desktop                 A       10.0.0.11
laptop1                 A       10.0.0.21
laptop2                 A       10.0.0.22

Und dasselbe dann für die Rückwärtsauflösung:

$ORIGIN .
$TTL 604800     ; 1 week
0.0.10.in-addr.arpa            IN SOA server.example.org. hostmaster.server.example.org. (
                                2011012101 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                39600      ; minimum (11 hours)
                                )
                        NS      server.example.org.
$ORIGIN 0.0.10.in-addr.arpa.
1            PTR    server.example.org.
11            PTR    desktop.example.org.
21            PTR    laptop1.example.org.
22            PTR    laptop2.example.org.

Jetzt werden die Zonen in die Nameserver-Konfiguration eingebunden, und zwar durch Anpassen der Datei /etc/bind/named.conf.local:

zone “example.org” {
type master;
file “/var/lib/bind/zone.example.org”;
};

zone “0.0.10.in-addr.arpa” {
type master;
file “/var/lib/bind/zone.10.0.0”;
};

Nach einem Reload der Zonen (rndc reload) sollte die Auflösung vor- und rückwärts funktionieren, was man mit host laptop1.example.org und dann mit host 10.0.0.21 testen kann.

2. Installation und Einrichtung des DHCP-Servers

aptitude -r install isc-dhcp-server

Nun ist /etc/dhcp/dhcpd.conf (ggf. nach Sicherung der Originaldatei) anzupassen:

server-name Server;

option domain-name “example.org”;
option subnet-mask 255.255.255.0;
option domain-name-servers 10.0.0.1; # der oder die DNS-Server

default-lease-time 86400; # 24 h
max-lease-time 172800; # 48 h

authoritative;

ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.101 10.0.0.199; # DHCP-Adressen werden zwischen .101 und .199 vergeben
option broadcast-address 10.0.0.255;
option routers 10.0.0.200; # das Gateway ins Internet, bspw. der DSL-Router
}

Das genügt zunächst einmal; nach einem /etc/init.d/isc-dhcp-server restart sollte der DHCP-Dienst funktionieren und IP-Adressen zwischen 10.0.0.101 und 10.0.0.199 vergeben. Die vergebenen Adressen lassen sich unter /var/lib/dhcp/dhcpd.leases ersehen.

Im Logfile (standardmäßig /var/log/daemon.log) kann man die Vergabe der Leases verfolgen; dort ersieht man auch die MAC-Adressen der Hosts, die sich per DHCP Adressen holen. Mit Hilfe dieser MAC-Adressen kann man dann den Hosts, die feste Adressen per DHCP vergeben erhalten sollen (im Beispiel sind das desktop, laptop1 und laptop2), ebensolche zuweisen. Nehmen wir an, desktop hat die MAC-Adresse 00:30:05:5a:db:a0, dann müßte der entsprechende Eintrag in der /etc/dhcp/dhcpd.conf folgendermaßen lauten:

host desktop {
hardware ethernet 00:30:05:5a:db:a0;
fixed-address 10.0.0.11;
}

Nach einem erneuten Restart des DHCP-Servers wird desktop jetzt immer fest diese DHCP-Adresse zugewiesen bekommen.

3. Dynamische Aktualisierung der DNS-Zonen

Der letzte Schritt sorgt jetzt dafür, daß durch den DHCP-Server dynamisch vergebene Adressen (10.0.0.101-199) in den Zonen-Dateien des Nameservers mit dem entsprechenden Namen erfasst werden. Diese Updates kann man entweder durch jedes Programm, das auf dem Server läuft, erlauben, oder kryptographisch absichern. Ich stelle hier ersteres dar.

Die Konfiguration des DNS-Servers in /etc/bind/named.conf.local ist folgendermaßen zu ergänzen (fettgedruckt):

zone “example.org” {
type master;
file “/var/lib/bind/zone.example.org”;
allow-update { localhost; };
};

zone “0.0.10.in-addr.arpa” {
type master;
file “/var/lib/bind/zone.10.0.0”;
allow-update { localhost; };
};

Reloaden der Konfiguration nicht vergessen!

Die Konfiguration des DHCP-Servers in /etc/dhcp/dhcpd.conf ist folgendermaßen zu ergänzen (fettgedruckt):

[...]

ddns-update-style interim;
ignore client-updates;

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.101 10.0.0.199; # DHCP-Adressen werden zwischen .101 und .199 vergeben
option broadcast-address 10.0.0.255;
option routers 10.0.0.200; # das Gateway ins Internet, bspw. der DSL-Router
ddns-domainname “gast.example.org”;

zone example.org. {
primary 127.0.0.1;
}

zone 0.0.10.in-addr.arpa. {
primary 127.0.0.1;
}
}

Restart des DHCP-Servers nicht vergessen!

Nunmehr wird die Maschine, die sich - bspw. - als gastnetbook meldet und eine IP möchtet, bspw. die IP 10.0.0.105 zugewiesen bekommen; in die Nameserver-Zonen werden jetzt entsprechende Einträge für 10.0.0.105 und gastnetbook.gast.example.org vorgenommen. Das erfolgt zunächst in Dateien, die den Namen der jeweiligen Zone plus die Endung “.jnl” (für “Journal”) tragen; regelmäßig werden aber auch die Zonendateien aktualisiert.

Manuelle Änderungen der DNS-Zonen dürfen dann nicht mehr ohne weiteres vorgenommen werden! Zunächst müssen die dynamischen Updates unterbrochen werden, danach kann man Änderungen vornehmen und die dynamischen Updates wieder starten:

rndc freeze example.org
vim /var/lib/bind/zone.example.org
rndc thaw example.org

oder

rndc freeze 0.0.10.in-addr.arpa
vim /var/lib/bind/zone.10.0.0
rndc thaw 0.0.10.in-addr.arpa

Installation von Debian Squeeze

thh@inter.net (Thomas Hochstein) — Thu, 20 Jan 2011 22:47:00 +0100

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.

Nach dem Reboot saß ich dann zum ersten Mal vor einer graphischen Konsole mit Gnome - und ich muß sagen, das gefällt mir bisher gut. Momentan muß ich mich dort noch zurechtfinden, aber immerhin kann die Maschine schonmal MP3s abspielen (nächster Eintrag auf der ToDo-Liste: Musikbibliothek mit korrekten MP3-Tags versehen ... *seufz*).

Auch der Weg dorthin war allerdings nicht ganz ohne Probleme, denn ich mußte dem System noch beibringen, die On-Board-Soundkarte richtig anzusteuern. Insoweit hilfreich war nach längerem Googeln - wie gesagt, bei solchen Dingen war ich bislang völlig ahnungslos - ein Eintrag im Ubuntuusers-Wiki, dem ich die Lösung für mein Problem entnehmen konnte: die Datei /etc/modprobe.d/alsa-base.conf möchte um den Eintrag options snd-hda-intel model=auto ergänzt werden. Statt dem dort empfohlenen Reboot (das erschien mir so ... Windows-artig) habe ich mich dann auf ein modprobe snd-hda-intel beschränkt - und auch das hat genügt.

Jetzt muß “nur noch” alles eingerichtet werden - insbesondere deshalb bestimmt ein großer Spaß, weil ich nach dem Einrichten des Basis-Systems den Fehler gemacht hatte, die zu installierenden weiteren Pakete mittels tasksel auszuwählen. Für den Desktop, von dem ich bekanntlich keine Ahnung habe, mag das noch eine gute Idee gewesen sein, aber der Rest - Mailserver, Webserver, Datenbankserver, ... - entspricht nun wirklich gar nicht meinen (teilweise sicherlich speziellen) Vorstellungen. Also werde ich das in den nächsten Tagen einfach neu machen.

Insgesamt muß ich sagen, daß meine erste Debian-Installation (auf aktueller Hardware) mich sehr positiv überrascht hat.

Der einzige Punkt, bei dem ich mir mehr Dokumentation gewünscht hätte, war die richtige Vorgehensweise, um dem Installer die fehlende Firmware unterzuschieben. Schön zu wissen, daß man sich .debs herunterladen (die dem Installer aber AFAIS nicht helfen, also nur für Updates hilfreich sein dürften) oder die notwendige Firmware “bspw. via USB-Stick” bereitgestellt werden kann; noch schöner wäre aber zu erläutern, wo und wie man ggf. die einzelnen Firmware-Dateien findet und wo genau auf dem Stick sie dann bereitgestellt werden sollen. (Vielleicht habe ich die entsprechende Doku einfach nicht gefunden, das glaube ich in diesem Fall aber noch nicht einmal.) Der Kampf mit der Soundkarte dürfte hingegen für jemanden, der so ungefähr weiß, was er tut, nicht problematisch sein; die Anleitung im Ubuntuusers-Wiki ist auch völlig hinreichend. (Ob man sie aus der Installationsanleitung verlinken sollte, sei dahingestellt; ich habe, ehrlich gesagt, nicht einmal nachgeschaut, ob das nicht vielleicht sogar der Fall ist.)

[Update vom 23.01.2011: Vermutlich ist die Doku über das Bereitstellen zusätzlicher Firmware völlig korrekt und das Problem besteht im Installer bzw. dem konkreten Firmware-Paket. Siehe dazu auch die Errata-Seite des Debian-Installers.]

Backup mit duply und duplicity

thh@inter.net (Thomas Hochstein) — Thu, 13 Jan 2011 18:18:15 +0100

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.

Eine mögliche Umsetzung für einen Mietserver sieht - unter Debian Lenny - so aus:

duplicity und ncftp installieren: aptitude -r install duplicity ncftp

duply (in /usr/local/bin) installieren:

cd /tmp
wget -O duply_1.5.4.2.tgz http://sourceforge.net/projects/ftplicity/files/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.4.2.tgz/download
tar -xzf duply_1.5.4.2.tgz
cp duply_1.5.4.2/duply /usr/local/bin/
rm duply_1.5.4.2.tgz
rm -r duply_1.5.4.2

Alternativ (Debian Squeeze): aptitude -r install duply

Da der gesamte Server gesichert werden soll, läuft der Backupprozess am besten mit Root-Rechten. Wir brauchen jetzt also einen GPG-Key für root und richten dann das Backup ein:

cd /root
gpg --gen-key

Wenn nicht genug Entropie vorhanden ist, um den Key zu erzeugen, empfiehlt es sich, bspw. durch mehrere größere Downloads für Netzwerkverkehr und Belastung der Festplatten zu sorgen, um den Pool aufzufüllen. Key-ID und Paßwort des erzeugten Schlüssels benötigt man im nächsten Schritt zur Einrichtung des Backups; der Name des Backups kann frei gewählt werden:

duply NAME create
vim .duply/NAME/conf

In der Konfigurationsdatei sind nun zumindest einzutragen
- die ID des erzeugten GPG-Schlüssels (GPG_KEY),
- das Paßwort desselben (GPG_PW),
- das Backup-Ziel (FTP-Server und ggf. Verzeichnis, Benutzername, Kennwort: TARGET, TARGET_USER, TARGET_PASS) und
- den Pfad, der gesichert werden soll (im Zweifel “/”: SOURCE).
Für die Einzelheiten und fortgeschrittene Konfigurationsmöglichkeiten sei auf die Kommentare innerhalb der Datei und die Dokumentation von duplicity und duply verwiesen.

Als nächstes erstellt man eine Liste der Dateien, die nicht gesichert werden sollen, die mindestens spezielle Verzeichnisse wie /dev und /proc enthalten sollte: vim .duply/NAME/exclude

/dev/*
/proc/*
/sys/*
/tmp/*
/var/tmp/*
/var/run/*

Danach kann man noch Scripts hinterlegen, die vor oder nach dem Backuplauf ausgeführt werden; bspw. kann es sich vor dem Backup empfehlen, Datenbanken zu dumpen. Diese Scripts heißen dementspechend pre und post, können zum Beispiel Shellscripts sein und müssen
- ausführbar sein (chmod 700 .duply/NAME/pre) und
- einen entsprechenden shebang (#!/bin/bash) enthalten.

Wenn das alles paßt, kann man nunmehr sein erstes Backup starten: duply NAME backup

Danach sollte man das komplette Verzeichnis .duply (das dann auch eine Kopie des GPG-Schlüssels enthält) sichern (nicht auf den Backupspace, sondern an einen sicheren Ort!).

Schließlich kann man noch in die Crontab von root einen entsprechenden Eintrag einfügen:

00 5 * * * /usr/local/bin/duply NAME backup
00 6 1 * * /usr/local/bin/duply NAME full && /usr/local/bin/duply NAME purge --force

Fertig. Viel Erfolg!

In gleicher Weise ist es möglich, weitere Backups zu definieren, die bspw. nur /home oder /etc (oder /var/mail ...) sichern, das dann aber häufiger.

Neustart von Diensten nach Updates - checkrestart

thh@inter.net (Thomas Hochstein) — Mon, 10 Jan 2011 21:06:00 +0100

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 Bug Tracker und Mantis Graphs 1.0

thh@inter.net (Thomas Hochstein) — Fri, 14 May 2010 18:14:00 +0200

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 mit Passwortschutz

thh@inter.net (Thomas Hochstein) — Sat, 16 Jan 2010 20:04:00 +0100

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.

u.a.

Voraussetzung dafür ist eine ausreichend neue Version von gitweb; die in Debian Lenny verfügbare Version 1.5.6.5 genügt nicht. Sie kann allerdings gepatcht werden (die Änderung ist minimal):

--- /usr/lib/cgi-bin/gitweb.cgi.OLD 2010-01-14 16:49:44.000000000 +0100
+++ /usr/lib/cgi-bin/gitweb.cgi     2010-01-15 15:30:40.975350737 +0100
@@ -86,6 +86,11 @@
 # (only effective if this variable evaluates to true)
 our $export_ok = "";
 
+# show repository only if this subroutine returns true
+# when given the path to the project, for example:
+#    sub { return -e "$_[0]/git-daemon-export-ok"; }
+our $export_auth_hook = undef;
+
 # only allow viewing of repositories also shown on the overview page
 our $strict_export = "";
 
@@ -353,7 +358,8 @@
 sub check_export_ok {
        my ($dir) = @_;
        return (check_head_link($dir) &&
-               (!$export_ok || -e "$dir/$export_ok"));
+               (!$export_ok || -e "$dir/$export_ok") &&
+                (!$export_auth_hook || $export_auth_hook->($dir)));
 }
 
 # process alternate names for backward compatibility

Das vorausgesetzt, genügt es, die gitweb.conf folgendermaßen zu erweitern:

# HTTP Basic Auth
$gitosis_conf = '/home/gitosis/.gitosis.conf';
$username = $cgi->remote_user;
$export_auth_hook = sub {
  my $projectdir = shift;
  if($projectdir =~ (/(.*?)\.git/)) {
    #my $projectname = basename($1);
    my $projectname = $1;
    $projectname =~ s/$projectroot\/?//;
    open FILE, $gitosis_conf or die 'Could not open gitosis config file. Please make sure that $gitosis_conf is set properly';
    my $project_match = 0;
    my $user_match = 0;
    while(<FILE>) {
      if($_ =~ /^\s*members\s*\=\s*(?:.*?\s)*$username(?:\s+|$)/) {$user_match = 1;}
      if($_ =~ /^\s*(read|writ)able\s*\=\s*(?:.*?\s)*$projectname(?:\s+|$)/) {$project_match = 1;}
      if($project_match && $user_match) {
         return 1;
      }
      if($_ =~ /\[group/) {
          $project_match = $user_match = 0;
      }
    }
  }
  return 0;
};

Dann muß noch die Apache-Konfiguration passend erweitert werden, um HTTP-Basic-Authentication für das entsprechende Verzeichnis zu machen:

<Location />
 AuthType Basic
 AuthName "git.host.example"
 AuthUserFile /home/gitosis/gitosis/ht.passwd
 Require valid-user
</Location>

Pfade müssen, wie üblich, entsprechend angepaßt werden.

Und schließlich müssen für die in der gitosis.conf definierten Benutzer - jedenfalls diejenigen, die auch Webzugriff haben sollen - Paßworte in der /home/gitosis/gitosis/ht.passwd angelegt werden. Dazu wird wie gewohnt htpasswd bzw. htpasswd2 aufgerufen.

Voilá!

Git-Repositories mit gitosis und gitweb (Debian Lenny)

thh@inter.net (Thomas Hochstein) — Thu, 14 Jan 2010 18:41:00 +0100

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.

Die Installation und Konfiguration habe ich folgendermaßen durchgeführt:

1. gitosis

a) Vorüberlegungen

gitosis bietet die Möglichkeit, Benutzer und Repositories zu konfigurieren. Die entsprechenden Repositories werden dann angelegt; für jedes kann gesondert festgelegt werden, welcher Benutzer - lesen oder schreibend - darauf zugreifen kann. Die Zugriffe erfolgen über (git-über-)SSH; jeder Benutzer muß dazu seinen öffentlichen SSH-Schlüssel hinterlegen. Er verbindet sich dann unter dem Benutzernamen (Useraccount) “gitosis” per SSH mit dem Server, auf dem das Repository liegt; gitosis prüft dann, welcher SSH-Schlüssel für die Verbindung übergeben wird und identifiziert auf diese Weise den Benutzer.

Die Konfiguration von gitosis erfolgt gleichfalls über ein git-Repository, das zunächst ausgecheckt wird; danach kann man die Konfiguration ändern und bspw. neue Repositories und Benutzer anlegen (und im Falle eines neuen Benutzers auch dessen öffentlichen SSH-Schlüssel speichern) und die Änderungen committen. Beim Commit paßt gitosis über entsprechende Hooks die Konfiguration an. Das Konfigurations-Repository kann entweder auf denselben Rechner ausgecheckt werden oder auf einen beliebigen anderen Client; auch diese Verbindungen erfolgen über (git-über-)SSH, und auch dafür muß man (s)einen öffentlichen SSH-Key bei gitosis hinterlegen. Ich habe mich entschlossen, dafür einen eigenen Key anzulegen; man kann aber natürlich auch einfach (s)einen bestehenden SSH-Schlüssel verwenden.

Standardmäßig sieht das Debian-Paket von gitosis die Anlage der Repositories in /srv/gitosis an; das paßt allerdings nicht zur Partitionierung meines Mietservers, der - historisch und aus dem Image des Anbieters bedingt - platzmäßig eher knapp kalkulierte Partitionen bietet und den gesamten restlichen Plattenplatz in /home eingehängt hat. Daher möchte ich die Repositories auch in /home/gitosis liegen haben.

b) Installation (der Debian-Pakete) und Inbetriebnahme

Zunächst sind git selbst und gitosis zu installieren:

aptitude install git-core git-doc gitosis

Danach lege ich ein Home-Verzeichnis für gitosis in /home an, lösche /srv/gitosis und setze einen Symlink auf das Home-Verzeichnis:

mkdir /home/gitosis
chown gitosis:gitosis /home/gitosis
rmdir /srv/gitosis/
ln -s /home/gitosis /srv/gitosis

Dann ist entweder mit ssh-keygen ein neues Schlüsselpaar zu erzeugen oder der öffentliche Schlüssel eines bestehenden Schlüsselpaares in einer Datei bereitzulegen, bspw. in git-admin_rsa.pub. Den verfüttert man dann an gitosis:

sudo -H -u gitosis gitosis-init < git-admin_rsa.pub

Dann habe ich der Bequemlichkeit halber noch die Konfiguration des SSH-Clients angepaßt, um bei SSH-Verbindungen zu localhost - was in meinem Fall nur für git-über-SSH bei der Konfiguration von gitosis vorkommt - direkt den richtigen Schlüssel zu benutzen, und dazu in ~/.ssh/config folgendes eingefügt:

Host localhost
IdentityFile ~/.ssh/git-admin_rsa

Zur Konfiguration und Einrichtung der Benutzer muß das Konfigurations-Repository von gitosis jetzt erst einmal ausgecheckt werden (in meinem Falle geschieht das auf demselben Host, man kann aber natürlich auch von jedem anderen Host aus mit dem oben an gitosis übergebenen SSH-Schlüssel auf das Repository zugreifen):

git clone gitosis@localhost:gitosis-admin.git gitosis-admin

Damit wird das Repositoy in das Verzeichnis gitosis-admin ausgecheckt. Dort befindet sich dann die Datei gitosis.conf und das Verzeichnis keydir; in ersterer werden Benutzer und Repositories angelegt, in letzterem finden sich die öffentlichen SSH-Schlüssel der Benutzer.

c) Konfiguration und Einrichtung der ersten Benutzer und Repositories

Als erstes nehme ich mir die gitosis.conf vor und prüfe bzw. setze dort die globalen Einstellungen:

[gitosis]
## To override the default ~/repositories path
# repositories = repositories

## Allow gitweb to show all known repositories. If you want gitweb,
## you need either this or a [repo foo] section for each repository
## you want visible in gitweb.
gitweb = no

## Allow git-daemon to publish all known repositories. As with gitweb,
## this can be done globally or per-repository.
daemon = no

## Logging level, one of DEBUG, INFO, WARNING, ERROR, CRITICAL
loglevel = INFO

Die Optionen sind im Prinzip selbsterklärend. Ich habe mich entschieden, den Webzugriff und den Zugriff via git-daemon nicht generell freizugeben, sondern das per Repository zu steuern.

Als nächstes werden Benutzergruppen und deren Rechte festgelegt:

### groups #####---------------
[group gitosis-admin]
writable = gitosis-admin
members = admin@admin.host.example

[group friends]
writable = repo-eins projekt/projektrepo-eins
members = me@my.host.example he@his.host.example another@another.host.example

[group myself]
writable = private projekt/projektrepo-private
members = me@my.host.example

Zur Gruppe “gitosis-admin” gehört also der Benutzer, der über den SSH-Key “admin@admin.host.example” identifiziert wird; dieser hat Zugriff auf das Konfigurations-Repository “gitosis-admin”. Zur Gruppe “friends” gehören neben mir (“me@my.host.example”) auch noch zwei andere, und diese Gruppe hat Zugriff auf zwei verschiedene Repositories; zur Gruppe “myself” gehöre nur ich mit Zugriff auf zwei weitere Repositories. Statt Lese- und Schreibzugriff (“writable”) kann auch ein bloßer Lesezugriff vergeben werden.

Diese Repositories werden dann im Anschluss konfiguriert:

### repos #####----------------
[repo repo-eins]
## Oneline description of the project, mostly for gitweb.
description = Repository Number One
## Owner of this repository. Used in gitweb list of projects.
owner = John Doe
## Allow git-daemon to publish this repository.
daemon = yes
## Allow gitweb to show this repository.
gitweb = yes

[repo projekt/projektrepo-eins]
description = Repository for our project
owner = John Doe
daemon = yes
gitweb = yes

[repo private]
description = Private repository
owner = John Doe
daemon = no
gitweb = no

[repo projekt/projektrepo-private]
description = Another repository for our project
owner = John Doe
daemon = no
gitweb = no

Auch das sollte eigentlich selbsterklärend sein. Zu beachten ist, daß die Angaben unter “daemon” und “gitweb” nur steuern, ob gitosis eine entsprechende “magische” Datei git-daemon-export-ok für git-daemon anlegt bzw. das Repository in eine Projektdatei für gitweb aufnimmt. Ob die entsprechenden mit “yes” gekennzeichneten Repositories dann via gitweb oder git-daemon auch wirklich verfügbar sind (und vor allem die mit “no” gekennzeichneten nicht!), ist eine Frage der Konfiguration dieser beiden Programme.

Nunmehr müssen für die in der gitosis.conf definierten Benutzer noch jeweils deren öffentliche SSH-Key hinterlegt werden, und zwar in keydir, wobei für jeden Nutzer eine Datei mit dem Namen $nutzername.pub angelegt werden muß, die mindestens einen Schlüssel enthalten muß, aber auch mehrere Schlüssel enthalten darf. Der oder die Schlüssel des Nutzers “me@my.host.example” gehören also in die Datei me@my.host.example.pub.

Schließlich müssen die Dateien mit dem Schlüsseln mittels git add hinzugefügt und alle Änderungen mittes git commit -a committed werden; danach wird das Repository mittels git push an gitosis verfüttert. Voilà!

2. git-daemon

git-daemon ist recht einfach zu installieren:

aptitude install git-daemon-run

git-daemon-run verwendet allerdings nicht die gewohnten Scripts in /etc/init.d, sondern runit/runsv, so dass sich ein Symlink lohnt:

ln -s /usr/bin/sv /etc/init.d/git-daemon

Außerdem sollte /etc/sv/git-daemon/run noch entsprechend konfiguriert werden:

#!/bin/sh
exec 2>&1
echo ‘git-daemon starting.’
exec chpst -ugitdaemon /usr/lib/git-core/git-daemon --verbose --enable=upload-pack --enable=upload-archive --base-path=/home/gitosis/repositories /home/gitosis/repositories

Statt “-ugitdaemon” wäre ggf. bei neueren Versionen des gitosis-Pakets in Debian “-ugitosis” zu verwenden; der Pfad /home/gitosis/repositories ist (zweimal) ggf. durch den Pfad zu den in gitosis angelegten Repositories zu ersetzen, im Falle des Debian-Paketes standardmäßig /srv/gitosis (den Grund für meine diesbezügliche Änderung habe ich weiter oben beschrieben).

Schließlich muß man sich noch entscheiden, welche Services der git-daemon bieten soll. “upload-pack” erlaubt den Zugriff via git fetch, git pull und git clone, “upload-archive” die Verwendung von git archive.

Das sollte es dann gewesen sein.

3. gitweb

Das gitweb-Paket aus Debian Lenny kann gleichfalls in wenigen Schritten installiert und konfiguriert werden; danach ist nur noch der Webserver - in meinem Fall Apache 2.2 - entsprechend anzupassen, wobei ich für gitweb einen eigenen vhost aufgesetzt habe.

a) gitweb

aptitude install gitweb

Dann kommt die /etc/gitweb.conf an die Reihe:

# path to git projects (<project>.git)
#$projectroot = “/var/cache/git”;
$projectroot = “/home/gitosis/repositories/”;

# directory to use for temp files
$git_temp = “/tmp”;

# target of the home link on top of all pages
#$home_link = $my_uri || “/”;

# html text to include at home page
$home_text = “indextext.html”;

# file with project list; by default, simply scan the projectroot dir.
# $projects_list = $projectroot;

# Point to projects.list file generated by gitosis.
$projects_list = “/home/gitosis/gitosis/projects.list”;

# stylesheet to use
$stylesheet = “/gitweb.css”;

# logo to use
$logo = “/git-logo.png”;

# the ‘favicon’
$favicon = “/git-favicon.png”;

# A list of base urls where all the repositories can be cloned from.
# Easier than having per-repository cloneurl files.
@git_base_url_list = (’git://git.host.example’);

“$projectroot” ist hier der Pfad zu den von gitosis angelegten Repositories, standardmäßig /srv/gitosis/repositories; “$projects_list” umfasst die Repositories, die gitweb anzeigen soll, und ist entweder ein Verzeichnis (bspw. $projectroot), in dem die Repositories liegen, oder eine Datei mit einer Liste der Repositories. Wenn man hier die Funktionalität von gitosis nutzen will, in der gitosis.conf zu steuern, welche Repositories gitweb anzeigen soll, dann ist es wichtig, hier auf die von gitosis erzeugte Projektliste zu verweisen, wie im obigen Beispiel geschehen! Wenn man sicherstellen will, daß gitweb nicht nur die Anzeige der Repositories auf die in der Liste gezeigten beschränkt, sondern auch nur diese Repositories überhaupt zum Abruf über das Webinterface anbietet, muß die Konfiguration hier noch um

$strict_export = “true”;

ergänzt werden. Schließlich können noch allgemeine Parameter wie “@git_base_url_list” gesetzt werden.

b) apache2

Für den Webserver konfiguriere ich, wie einleitend beschrieben, einen eigenen vhost in /etc/apache2/sites-available/gitweb:

<VirtualHost *:80>
 ServerName git.host.example
 ServerAdmin webmaster@host.example

 HeaderName HEADER

 # bogus but safe DocumentRoot
 DocumentRoot /var/cache/git

 #Alias /robots.txt /var/www/cvs.robots.txt
 Alias /gitweb.css /usr/share/gitweb/gitweb.css
 Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
 Alias /git-logo.png /usr/share/gitweb/git-logo.png
 ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
</VirtualHost>

Ich füge außerdem den Benutzer www-data, unter dem der Apache-Webserver läuft, noch in /etc/group zur Gruppe gitosis hinzu, damit er die Repositories lesen kann.

Danach aktiviere ich den zuvor angelegten vhost:

a2ensite gitweb
/etc/init.d/apache2 reload

Jetzt sollte unter http://git.host.example/ das Webinterface von gitweb mit den freigegebenen - und befüllten! - Repositories auftauchen.

Fertig!

LILO makes the difference

thh@inter.net (Thomas Hochstein) — Wed, 10 Jun 2009 07:30:00 +0200

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?

Aufräumen schafft Platz

thh@inter.net (Thomas Hochstein) — Mon, 08 Jun 2009 07:25:00 +0200

/ lief voll.

Aufräumen hilft.

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.

Munin-Plugin und BIND 9.5.1 revisited

thh@inter.net (Thomas Hochstein) — Mon, 18 May 2009 07:40:00 +0200

Ich hatte bereits geschildert, daß das Munin-Plugin für BIND nicht mit dem Format der Statistikdatei von BIND 9.5.x umgehen kann, und auch eine Lösung vorgeschlagen, die bei mir dafür gesorgt hatte, daß die Lücke in den Munin-Daten für BIND sehr schmal blieb. Leider mußte ich jetzt - nachdem ich, bedingt durch Zeitmangel, erst nach längerer Zeit wieder einmal einen Blick auf diese spezielle Grafik werfen konnte - feststellen, daß sich ein neues, bald zwei Wochen messendes Loch aufgetan hat.

Der Grund ist einfach: BIND 9.5.1 schreibt die Statistikdatei nicht immer wieder neu, sondern hängt die neuen Informationen am Ende an. So wird die Datei immer länger; hier waren es jetzt > 33 MB. Und da das Munin-Plugin die Datei schlicht zeilenweise liest und dabei auf das (letzte) Auftreten bestimmter Schlüsselbegriffe achtet, um die entsprechende Zeile dann auszuwerten, dauert das ab einer gewissen Dateigröße einfach so lange, daß dabei ein Timeout des entsprechenden Plugins entsteht.

Weiß jemand zufällig, ob man BIND 9.5.1 beibringen kann, die Statistiken wie früher immer neu zu dumpen, statt sie an die alte Datei anzuhängen? Sonst wird sich wohl ein Cronjob der Sache annehmen müssen, der die Datei rotiert - oder regelmäßig löscht.

INN und SSL/TLS (Debian Lenny)

thh@inter.net (Thomas Hochstein) — Mon, 27 Apr 2009 20:55:00 +0200

Das Internet ist schon lange kein friedlicher Ort mehr, an dem jeder jedem trauen kann - und deshalb wurden die ursprünglichen, unverschlüsselten Kommunikationsprotokolle schon lange durch kryptograhpisch abgesicherte Variationen ersetzt. Telnet verwendet heute wohl niemand mehr offen im Netz, stattdessen gibt es SSH; auch im Mailverkehr pflegt man - hoffentlich - zumindest das Paßwort beim Abruf über POP3 via APOP und beim Versand via SMTP über eine SMTP-Aut-Variante mit Verschlüsselung zu sichern, wenn man nicht ohnehin die ganze Kommunikation SSL-verschlüsselt, und auch diejenigen, die FTP noch nicht durch SCP/SFTP ersetzt haben, nutzen hoffentlich wenigstens SSL, um die Paßwortübertragung zu verschlüsseln.

So weit, so gut, aber schon vor einer ganzen Weile fiel mir auf, daß diese Regel für Netnews (NNTP) offenbar nicht gilt (und für UUCP oft auch nicht ...); denn zu seinem oder seinen Newsserver(n) verbindet man sich oft genug noch unverschlüsselt, obwohl auch dort ein Paßwort übertragen wird. So ging es zumindest mir, und ich habe mich am vergangenen Wochenende entschlossen, dagegen etwas zu unternehmen und auch die Verbindung zumindest zu meinem eigenen Newsserver zu verschlüsseln.

Das ist - mit dem INN 2.4.5-Paket aus Debian Lenny - eigentlich ganz einfach:

Ein SSL/TLS-fähiger nnrpd ist bereits vorhanden (nnrpd-ssl). Wer nicht das vorgenannte Paket verwendet, muß den INN (oder zumindest den nnrpd) ggf. mit “configure --with-openssl” noch einmal kompilieren.
Schlüssel muß man sich erzeugen, sofern noch nicht vorhanden. Vorhandene Zertifikate bzw. Schlüssel sollte man vielleicht am einfachsten kopieren; standardmäßig werden sie in /etc/news gesucht. Das ist verhandelbar respektive konfigurierbar, aber das Zertifikat und der Schlüssel müssen dem User news gehören und die Rechte 600 aufweisen.
Die Konfigurationsdatei /etc/news/sasl.conf muß editiert (oder ggf. angelegt) werden, um die korrekten Pfade zum Zertifikat und dem privaten Schlüssel des Servers aufzunehmen. “tls_cert_file” und “tls_key_file” sind die relevanten Parameter.
Danach muß der nnrpd-ssl nur noch veranlasst werden, auf Port 563 (NNTPS) zu lauschen. Das kann man u.a. über den (x)inetd erreichen, indem man bspw. folgende Konfigurationsdatei in /etc/xinet.d/ einwirft:

service nntps
{
   socket_type     = stream
   protocol        = tcp
   wait            = no
   user            = news
   group           = news
   server          = /usr/lib/news/bin/nnrpd-ssl
   server_args     = -S -p 563
}

Voraussetzung dafür ist, daß die /etc/services den Service “nntps” kennt.

Voila. Wer mag, kann auch noch eine CA daran anflanschen und bspw. Nutzer statt via Paßwort auch via Zertifikat authentifizieren, indem er die readers.conf entsprechend anpaßt, aber daran habe ich keinen Bedarf; mir genügt die Verschlüsselung der Verbindung zwischen Server und Client.

(Danke an Viktor Kafke für die entsprechenden Tips.)

Debian Lenny: erste Erfahrungen

thh@inter.net (Thomas Hochstein) — Fri, 17 Apr 2009 20:12:00 +0200

Platzverbrauch auf / gestiegen.

Speicherauslastung unter dem Strich unverändert.

Nachdem ich in den letzten Tagen einige Maschinen - heimische und Mietserver, letztere mit und ohne serielle Konsole - von Debian Etch auf Lenny hochgezogen haben, sind mir dabei einige Gemeinsamkeiten aufgefallen. Zunächst vielleicht das wichtigste: die in den Release Notes angesprochenen Probleme mit neu nummerierten Devices oder gar Problemen beim Auffinden des Root-Filesystems beim Reboot (Device enumeration reordering, System boot hangs on Waiting for root file system) sind bei mir glücklicherweise in keinem Fall aufgetreten; das verlief vielmehr alles durchaus problemlos, sei es mit LILO als Bootloader (ggf. an Verkleinerung der RAM-Disk denken, Prepare initramfs for LILO!) oder mit grub. Das hat mich besonders erleichtert, weil, wie gesagt, nicht alle entfernten Maschinen über eine serielle Konsole und damit über die Möglichkeit eines einfachen Zugriffs bei Bootproblemen verfügen.

Auch ansonsten verliefen die Upgrades an und für sich - bei der in den Release Notes empfohlenen Vorgehensweise - erfreulich unproblematisch. Das gehört auch zu den Dingen, die ich an Debian besonders schätze: der Upgrade-Prozeß ist in der Regel schmerzlos, gut dokumentiert und getestet. Hilfreich insbesondere, wenn man sich in den eher zentralen und maschinennahen Bereichen nicht so besonders auskennt und/oder keinen unmittelbaren Zugriff auf das System hat.

Mehr Entropie ...

... zumindest manchmal.

Schon allein ein Blick auf Munin zeigt aber einige Veränderungen, die sich aus den in den Beitrag eingestreuten Graphiken ergeben. Dass der Platzverbrauch im Rootverzeichnis - genauer wohl in /libs - gestiegen ist, hatte ich schon vorgestern nach dem Update der ersten Maschine berichtet. Das ist aber natürlich nicht die einzige Veränderung - es gibt auch positives zu berichten. So hatte ich zuerst den Eindruck gewonnen, daß die Speicherauslastung zurückgegangen ist, nicht nur, soweit sich die Buffer nach dem Reboot erst einmal wieder füllen müssen, sondern auch, soweit der von Applikationen in Anspruch genommene Speicher betroffen ist. Das scheint mir aber ein Irrtum gewesen zu sein; mit der Zeit steuert die Auslastung wieder dem bisherigen Wert zu. Was sich aber definitiv direkt um Größenordnungen erhöht und insoweit verbessert hat, ist die zur Verfügung stehende Entropie, wichtig für die Erzeugung von Zufallswerten, insbesondere auch im Zusammenhang mit der Verschlüsselung. Auf den meisten Maschinen ist die Erhöhung eine generelle, auf einer Maschine ist sie zumindest eine temporäre. Zumindest auf einer Maschine hat sich auch die Anzahl der MySQL-Queries spürbar verringert; das erscheint mir aber eher zufällig zu sein (oder steckt vielleicht irgendwo im neuen INN drin - denn der dürfte auf dieser Maschine für die SQL-Queries in erster Linie verantwortlich sein).

Deutlich weniger MySQL-Queries.

Ansonsten finden sich die meisten Veränderungen, wie in den Release Notes schon angekündigt, rund um den Apache herum: die Konfigurationsdatei wurde deutlich entschlackt und die Konfiguration von Modulen in die entsprechenden Module - in mods-available/ - verschoben, phpMyAdmin wird nicht mehr über einen Symlink, sondern direkt über einen Alias aus der Serverkonfiguration (in conf.d/phpmyadmin.conf, ein Symlin auf /etc/phpmyadmin/apache.conf) eingebunden, und mod_suphp muß auf einen anderen MIME-Type reagieren (application/x-httpd-php statt x-httpd-php) und wird per default für /usr/share, wo die in Debian gepackageten Webapplikationen liegen, deaktiviert (in mods-available/suphp.conf). Das erfordert ggf. einige Nacharbeit. Hat man zum Beispiel bisher den https-Zugriff auf phpMyAdmin dadurch erzwungen, daß das DocumentRoot für den normalen, unverschlüsselten Zugriff auf den Server nicht auf /var/www/ zeigt, sondern auf ein anderes Verzeichnis, so daß phpMyAdmin nur beim Aufruf per https gefunden werden konnte, hilft das jetzt nicht mehr, denn per Alias-Direktive wird es immer eingebunden. Hier kann man stattdessen an der passenden Stelle ein SSLRequireSSL in /etc/phpmyadmin/apache.conf einsetzen. Wenn man auch die Webapplikationen (weiterhin) nicht unter mod_php, sondern unter mod_suphp laufen lassen will (vielleicht schon deshalb, weil man mod_php gar nicht installiert hat), dann sollte man die entsprechenden Änderungen in mods-available/suphp.conf auskommentieren.

Schließlich beschwerte sich pam_env bei mir seit dem Upgrade, daß es /etc/default/locale nicht finden könne. Ein Anlegen der Datei beseitigt diese Fehlermeldungen aus dem Logfile.

Eine Sache ist mir allerdings noch etwas schleierhaft, und zwar hatte ich zumindest auf einer Maschine das Problem, das php-cgi ab und an segfaultet:

Apr 16 19:50:37 machine kernel: [113175.233973] php-cgi[2618]: segfault at b6d62eae ip b638e3cf sp b6b940b8 error 4 in libgcc_s.so.1[b6387000+c000]
Apr 17 01:25:27 machine kernel: [134723.984243] php-cgi[31344]: segfault at b6c94eae ip b62c03cf sp b6ac60b8 error 4 in libgcc_s.so.1[b62b9000+c000]
Apr 17 18:08:37 machine kernel: [199692.119127] php-cgi[21780]: segfault at b6d2be90 ip b6d2be90 sp b6b5d3ac error 4 in librt-2.7.so[b771f000+7000]
Apr 17 18:14:32 machine kernel: [200072.558515] php-cgi[22441]: segfault at b6cd9e90 ip b6cd9e90 sp b6b0b3ac error 4 in libtasn1.so.3.0.15[b759d000+f000]

Das tut es eben nicht immer, nur manchmal, vorher nicht und seitdem auch nicht mehr. Google hat mir eine entsprechende Anfrage eines Nutzers auf der Debian-User-Mailingliste aus dem Februar präsentiert, die allerdings bisher AFAIS ohne Antwort geblieben ist; dort scheinen mir dieselben Symptome dargestellt zu sein. Fällt jemand etwas dazu ein?

Apache 2.x, php-cgi, mod_suphp und "No input file specified!"

thh@inter.net (Thomas Hochstein) — Fri, 17 Apr 2009 17:03:00 +0200

Im Zusammenhang mit dem Update einer Maschine auf Debian Lenny bin ich auf das seltsame Phänomen einer - offensichtlich von PHP erzeugten - Fehlermedlung gestoßen: der Aufruf einer bestimmten Webseite (respektive des PHP-Scripts, das diese erzeugen sollte) ergibt nur die Meldung “No input file specified!”. Google führt einen zu diversen Threads, die sich vor allem um die Konfiguration des richtigen Handlers für die Interpretation von PHP-Scripts und um hilflose Fragen von Benutzern, die eigentlich nur ein fertiges Paket installieren wollten und nun nicht mehr weiter wissen, drehen. Erst ein alter Blogeintrag in ixs’ Vodkamelone (nein, das hat nichts mit einem Kamel Nr. Eins zu tun!) von 2005 half mir auf die Sprünge.

Der Grund dieser Fehlermeldung ist offenbar ein ganz seltsames Zusammenspiel der Ausführung von PHP als mod_suphp, d.h. der CGI-Version von PHP in der Weise, daß Scripts unter den Rechten des jeweiligen Benutzers ausgeführt werden, mit der Vergabe von Datei- und Verzeichnisrechten. Die oben genannten Fehlermeldung tritt demnach genau dann auf, wenn zwar der Webserver auf die Datei bzw. ihr Verzeichnis zugreifen, sie also “finden” kann, der Benutzer selbst aber nicht. Dann findet der Webserver - unter der UID www-data - das Script, erkennt es, ruft den Handler auf, der als suid root installiert ist, sich Root-Rechte verschafft, damit auf die UID des Benutzers wechselt und dann mit diesen Rechten den PHP-Interpreter aufruft, um ihn das Script ausführen zu lassen. Dieser PHP-Prozess, der jetzt aber im Kontext des Benutzers läuft, kann dann selbst auf das entsprechende Verzeichnis nicht mehr zugreifen, das Script also auch nicht ausführen, und reagiert dann mit der obigen Fehlermeldung, denn er findet ja keine Datei, die er ausführen könnte.

Vielleicht hilfts ja jemanden, wenn ich ixs’ Analyse her noch einmal wiedergebe und verlinke.

Debian Lenny und Munin

thh@inter.net (Thomas Hochstein) — Thu, 16 Apr 2009 20:33:00 +0200

Beim Upgrade eines Systems, auf dem ein Munin-Client läuft, von Debian Etch auf Debian Lenny sind ggf. einige Handgriffe nötig, damit Munin weiterhin ordnungsgemäß funktioniert.

Zum einen muß ggf. für die Apache-Statistiken der Konfigurationseintrag für mod_status (wieder) ergänzt werden, weil er von der apache2.conf in die Modulkonfiguration in mods-available/status.conf umgezogen ist. “Allow from localhost 127.0.0.1” sollte sich dort finden, und ggf. “ExtendedStatus On”.

Problematischer ist das Update von BIND auf Version 9.5.1; im Debian-Paket gibt es zwar ohnehin kein Plugin für den Nameserver, aber wer bisher das bind_-Plugin von MuninExchange verwendet hat, stößt auf das Problem, das dieses nicht mit BIND 9.5.x kompatibel ist. Der Grund dafür liegt in dem unterschiedlichen Format der von BIND erzeugten Statistikdatei. Die neue Version ist da viel ausführlicher, hat aber eben auch ein ganz anderes Format.

Daher habe ich das Plugin quick’n’dirty auf das neue Format umgeschrieben. Ob es überhaupt noch möglich ist, die Statistiken nur für bestimmte Domains zu sammeln, wie es das bind_-Plugin anbietet, weiß ich nicht; dieses Feature habe ich nicht benutzt. Jedenfalls kann man mit dem “neuen” Plugin nahtlos an die alten Munin-Graphiken anschließen; daher sammelt es auch nur (genau) die Daten, die auch das alte Plugin angeboten hat, auch wenn das neue Statistik-Format ggf. weitergehende Informationen bereit hält (mit einer Ausnahme: die Referrals scheinen nicht mehr geloggt zu werden). Meine Lösung ist nicht von der Perfektion weit entfernt, schon deshalb, weil sie teilweise Werte etwas willkürlich auf die alten Kategorien mappt (bspw. bei “failures”), aber es tut, und wie meine Graphen zeigen, sind die Werte von der Größenordnung her vergleichbar mit den früher erfassten. Dass BIND 9.5.x die Statistikdatei im übrigen nicht - wie offensichtlich früher der Fall - überschreibt, sondern die neuen Werte jeweils anhängt, stört gleichfalls nicht, weil das Plugin immer nur den letzten Match auswertet.

Wenn jemand Interesse daran hat - oder sich um eine Verbesserung kümmern möchte, für die mir momentan die Zeit fehlt, kann er sich das Plugin bind95 gerne herunterladen; Kommentare sind willkommen.

Wer seine bisherigen Munin-Graphen nahtlos weiterführen will, muß dafür sorgen, daß der symbolische Link - oder die Datei - in /etc/munin/plugins/ denselben Namen (“bind_”) wie bisher trägt, oder die Datensammlungen in /var/lib/munin/$DOMAIN/ entsprechend umbennen, d.h. von /var/lib/munin/$DOMAIN/$HOST-bind_-*.rrd nach /var/lib/munin/$DOMAIN/$HOST-bind95-*.rrd. Und, wie immer: ein Backup schadet nicht ...