Christoph's last Weblog entries

LVM ist eine großartige Sache. Dynamische Volumes lassen sich jederzeit nach Bedarf vergrößern. Nie mehr raten, wie viel Platz für was nötig ist, einfach die Partitionen mitwachsen lassen.

Klingt alles nach einer netten Angelegenheit, warum also nicht für die neue USB-Festplatte verwenden? An sich eine Gute Idee. Falsch gemacht steht man allerdings schnell ratlos da.

z.B. wenn man die Volume Group nicht offline nimmt bevor die Festplatte vom USB-Port verschwindet. Nach eingehenden Experimenten kann ich bestätigen, dass das mitunter unerwartete Ergebnisse liefert.

$lvs
  /dev/dm-3: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-4: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-5: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  LV     VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert                                 
  backup extern -wi-a-  50,00G                                      
  oggs   extern -wi-a-  50,00G                                      
  photos extern -wi-a- 100,00G 
$ mount /dev/extern/backup /media/extern/backup/
mount: /dev/mapper/extern-backup: can't read superblock

Was ist passiert? Ich bin kein LVM Experte. Die Erklärung sollte allerdings sein, dass durch das Entfernen und wieder Anstecken der Festplatte die Mappers nicht angepasst werden. LVM versucht jetzt von der bereits entfernten Festplatte zu lesen und nicht von der neuen.

Und jetzt? Das Problem selbst behebt sich relativ einfach:

$ vgchange -a n extern
  /dev/dm-3: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-4: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  /dev/dm-5: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler
  0 logical volume(s) in volume group "extern" now active
$ vgchange -a y extern
  3 logical volume(s) in volume group "extern" now active

Was macht dise Befehlsfolge? Ersteinmal wied die nicht mehr funktionierende Volume Group offline genommen, danach wieder angeschaltet. Dadurch wreden auch die Verweise im Mapper angepasst. Danach sollte die Wechselfestplatte wieder normal ansprechbar sein. Und in Zukunft wird die Volume Group auf der Festplatte erst deaktiviert (vgchange -a n extern) und danach abgesteckt

Server konfigurieren ist keine einfache Angelegenheit. Soweit klar. Allerdings kann es doch immer wieder überraschend sein wie schwer es manchmal sein kann.

Dieser Server lief lange Zeit mit SuSE 10.2 -- verhältnismäßig alt, es ist schwer irgendetwas neues zu installieren und die alte Administrationssoftware für unsere Webkunden war auch nicht das wahre. Ein Update kam nicht in Frage, niemand im Team hat die Erfahrung mit SuSE im generellen und die Konfiguration war vom Anbieter voreingestellt.

Da bald Debian Lenny released wird und immerhin ich einige Erfahrung mit Debian gesammelt habe stand dann fest, dass dieser Server mit eben jenem System betrieben werden wird.

Am 22.12. war es dann soweit. Ich mobil mit meinem Notebook beim zweiten Admin eingetroffen, die letzten Backups abgeschlossen, reset beantragt. Um 10 Uhr der Server dann mit etch einsatzbereit (Lenny gibt's nicht im Angebot aber ein update eines frischen Etch ist ja kein Problem).

Natürlich läuft nincht alles so, wie es soll. In diesem Fall der MTA, exim4. Wärend die Grundlegende Konfiguration auf den Einstellungen von SysCP eigentlich ganz gut funktionieren, ist beim MTA nacharbeit angesagt.

Für einen neuen Anlauf ein rm -rf /etc/exim4 + neuinstallation des Paketes war dann irgendwie keine gute Idee, sodass nach 14 Stunden Arbeit der Mailserver immer noch nicht lief.

Immerhin läuft jetzt alles, wie es soll, und das neue System war die Arbeit sicherlich wert!

Wie man meinem privaten Launchpad PPA ansieht verwende ich selbiges doch recht ausgiebig. Der Nutzen liegt, in meinen Augen, unter anderem darin, bereits vor dem offiziellen Release mit den aktiven Benutzern der Software auf Fehlerzuche gehen zu können.

Solchige Software könnte sonst lediglich in Debians «experimental» landen, würde das ganze aber für mich ausbremsen da mit einfach die Upload-Rechte (noch) fehlen und gerade für kleinere Projekte kann man in einem solchigen experimental-Updload auch Resourcenverschwendung sehen.

Außerdem geben die PPAs eine gute Möglichkeit backports zu veröffentlichen. Aufgefallen ist mir das, als ich festgestellt habe, dass, obwohl ich primär ein Debian-Mensch bin, meine neuen SFML-Pakete zuerst für Ubuntu verfügbar sind und in Debian wohl erst irgendwann nach dem Release erhältlich sein werden und auch dann nur für sid und squeeze.

Schade eigentlich, dass es so etwas für Debian nicht gibt.