LV-Namen, UUIDs, Filesystemlabels etc
Hi,
auf meinen Servern lege ich eigentlich recht großen Wert darauf, dass
sie weitgehend identisch sind, damit ich auch mal einen Nichtlinuxer
aus der Ferne durch das System führen kann, ohne mir vorher Gedanken
darüber machen zu müssen, wie diese Büchse denn nun konfiguriert ist.
Besondere Betrachtung hatte ich damals für:
(h1) die Lage des root-fs (/etc/fstab, grub/menu.lst)
(h2) die Namen der LVM-Volumes (/etc/fstab)
So kam es dazu, dass das root-Filesystem immer auf /dev/hda1 liegt,
und dass /dev/hda2 eine PV ist, die die einzige PV einer VG vg0 ist,
in der wiederum LVs namens home, var und usr liegen.
Dieses Setup hat die folgenden Nachteile:
* Man muss von dem Standardsetup abweichen, wenn RAID oder
Kryptografie im Spiel ist. Dann muss nämlich das root FS auch im
LVM liegen, und hda1 ist /boot
* Das LVM-Setup macht *rumms*, wenn man in Recovery- oder
Migrations-Szenarien die Platten aus einem Server in einen anderen
hängt. Das ist aber per lvrename über UUID lösbar.
* Die Migration auf libata tut weh, weil man dort dann hda in sda
ändern muss.
Für diese Problematik gibt es einen Haufen denkbarer Lösungen:
(l1) Einhängen des Root-Filesystems nach UUID
- Man muss bei Neupartitionierung des Systems aufpassen, dass man die
UUID in /etc/fstab und grub/menu.lst anpasst
+ konfliktfrei, wenn die Platten mehrerer Server zusammen in einer
Hardware hängen
(l2) Einhängen des Root-Filesystems nach Label (gleiches Label überall)
- Konflikte beim Einhängen mehrerer Platten in eine einzige Hardware,
wobei unter Umständen das falsche System bootet
(l3) Einhängen des Root-Filesystems nach Label (hostspezifisch)
- Man muss beim Umbenennen des Systems aufpassen, dass man das
Label in /etc/fstab und grub/menu.lst anpasst
+ konfliktfrei, wenn die Platten mehrerer Server zusammen in einer
Hardware hängen
(l4) VG hat auf allen Systemen denselben Namen
- Manuelles Eingreifen (siehe oben) notwendig, wenn die Platten mehrerer
Server zusammen in einer Hardware hängen
+ Backup- und andere plattennahe Scripts können auf allen Systemen
identisch konfiguriert sein: Draufwerfen, läuft.
(l5) VG ist genannt wie der Server
- Man muss beim Umbenennen des Systems aufpassen, dass man /etc/fstab
anpasst
- Backup- und andere plattennahe Scripts müssen zum Server passend
konfiguriert sein, keine Standardkonfig möglich.
+ konfliktfrei, wenn die Platten mehrerer Server zusammen in einer
Hardware hängen
Ich brüte jetzt über eine Lösung, habe aber Bedenken, dass sie
overengineered ist:
(l1)
Das root-FS wird über Label eingehängt, so dass die
/boot/grub/menu.lst nur einmal bearbeitet werden muss. Wenn grub 2
irgendwann mal benutzbar wird, kann über ein Hookscript (grub 2
scheint ein grub.d zu haben) das Label des root-FS automatisch
generiert werden. molly-guard ist so konfiguriert, dass es das System
nicht freiwillig bootet, wenn das in der Bootmanagerkonfiguration
eingetragene Label des root-FS nicht mit dem des aktuell eingehängten
root fs identisch ist. Sprich: Es wird erzwungen, dass der Kernel beim
reboot dasselbe root-fs vorgesetzt bekommt wie das, was aktuell
eingehängt ist.
Unter welchen Umständen muss ich dann (und wann?) blkid -g aufrufen?
(l2)
Die /etc/fstab ist auf allen systemen gleich und hat Einträge wie:
/dev/disk/localhost/usr /usr ext3 defaults
Die Symlinks in /dev/disk/localhost erzeugt ein früh (27) in
Runlevel S gestartetes Initscript (oder kriegt man das per udev hin?).
Hab ich da noch was übersehen, und ist die Lösung machbar? Habt Ihr
Euch über diese Dinge auch schon Gedanken gemacht?
Grüße
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
Reply to: