Der Rechner pcsec6 wird zum Server umfunktioniert. Dazu muss zuerst SuSE9.1 installiert werden. Leider funktioniert die von SuSE bereitgestellte Funktion SuSE Update nicht: Es wird als Quellmedium die CD angegeben, doch leider wird die CD nicht erkannt. Es wird ``Unable to mount filesystem'' gemeldet. Auch das Kopieren der CDs auf Festplatte half ebenso wenig wie ein mounten über NFS. Deshalb musste die Installation manuell über eine Neuinstallation gemacht werden. Dazu wird eine bestehende Partition verwendet.
Auf dem neu aufgesetzten System wird ein DHCP-Server eingerichtet. Er dient dazu, den Clients zuerst eine IP, und dann den Bootloader Bpbatch zur Verfügung zu stellen. Der Bootloader wird über das TFTP-Protokoll, ein minimales FTP, zum Client übertragen. Dazu muss das Verzeichnis /tftpboot existieren. Darin liegen der Bootloader mit seiner Konfigurationsdatei bpbatch.bpb, der zu bootende Kernel und die Initial Ramdisk. Die initrd ein kleines filebasiertes Loopback-Filesystem, das in eine Ramdisk geladen wird. Dies geschieht unmittelbar nach Laden des Kernels, aber noch vor dem Starten des eigentlichen Betriebssystems.
Bpbatch wird auf dem Client ausgeführt. Ein Restore des Clients, und damit ein Update des Betriebssystem, erfolgt über den Punkt ``ITSEC Restore'' im Bootmenü. Dabei wird vom Bootloader ein Kernel, der auf dem Server bereitsteht, auf den Client kopiert und geladen. Als Root-Filesystem dient das über NFS exportierte Verzeichnis /backup/restore, in dem ein entpacktes tar-Image des laufenden Systems liegt. Das Image wird mit
tar -czf /backup/restore/backup.tgz -exclude /tmp -exclude /home -exclude /proc -exclude /tftpboot -exclude /backup -exclude /usr/src /
erstellt. Es muss entpackt und angepasst werden. Z.B. müssen alle Client-spezifischen Konfigurationsdateien in etc angepasst werden. Dazu gehört der Hostname, die Netzkonfiguration (Namensauflösung, Routen, IP-Adressen) und das Entfernen überflüssiger Dienste aus den Runlevel-Verzeichnissen etc/rc*.d. Das System soll nur minimal starten, also sind Dienste wie z.B. Squid und DNS aus den einzelnen Runlevels zu entfernen. Als Defaultrunlevel wird in der /etc/inittab Runlevel 3 eingestellt. Ausserdem müssen die Verzeichnisse /proc, /install und /install2 angelegt werden, da diese später vom Systerm und den Restore-Skripten benötigt werden.
Die IP des Testservers wird auf die des Secservers gesetzt, am Secserver selbst wird das Netzwerk über /etc/init.d/network stop angehalten, um IP-Konflikte zu vermeiden. Damit wird gewährleistet, dass die am Testserver eingerichtete Konfiguration auch auf dem Secserver funktioniert.
Der Kernel und die Initial Ramdisk müssen in das /tftpboot-Verzeichnis kopiert werden. In der Konfigurationsdatei bpbatch.bpb muss der Dateiname des Kernels angepasst werden. Während des Fortgeschrittenenpraktikums kam es zu dem Problem, dass der Bootvorgang auf den Clients mit folgender Fehlermeldung abgebrochen hat:
Uncompressing Linux...
Invalid Compressed Format (err=1)Es stellte sich heraus, dass der Netzbootloader ausschliesslich einen Kernel laden kann, der kleiner als 960kB ist, ansonsten bricht der Bootvorgang wie beschrieben ab. Da der neue SuSE9.1-Kernel ca.1,3MB gross ist, musste er neu kompiliert werden. Nur die wichtigsten Treiber, wie die für das Filesystem, Netzwerk und Crypto-Optionen werden fest in den Kernel einkompiliert, alles andere wird als Modul ausgelagert, um die Grösse von 960kB nicht zu überschreiten.
Zum erfolgreichen Booten der Clients nach dem Restore, muss die Initial Ramdisk angepasst werden. Dazu wird die Datei cinitrd.gz entpackt und daraufhin loop-gemountet:
#gunzip cinitrd.gz
#mount cinitrd /mnt/initrd -o loop
Die Module im Verzeichnis /mnt/floppy/lib/modules müssen aktualisiert werden. Dazu ersetzt man die Moduldateien durch die aktuellen Versionen aus dem /lib/modules-Verzeichnis. Nach den Änderungen wird die Initial Ramdisk ausgehängt und wieder gepackt.
#umount /mnt/initrd
#gzip cinitrd
Das Backup-/Restore-Skript, das bereits in einem anderen Fortgeschrittenenpraktikum entwickelt wurde, benötigt die User secpback und secpuser auf dem Server. Also müssen sie angelegt und angepasst werden: Statt wie im Normalfall eine Shell, wird nach dem Login eines der Benutzer das Backup-/Restore-Skript ausgeführt. Diese Skripte wurden im Rahmen des Fortgeschrittenenpraktikums ``Konzeption und Realisierung einer sicheren Multiboot- und Backup-Infrastruktur'' [9] entwickelt. Damit sie auch sofort nach dem Login abgearbeitet werden, muss /etc/passwd angepasst werden:
secpback:x:501:100:secpbackup:/backup:/backup/master.pl
secpuser:x:502:101:userbackup:/backup:/backup/user.pl
Ebenfalls muss im Restore-System der User install existieren und angelegt werden. Zum Abschliessen der Serverkonfiguration wird in /backup die von den Skripten benötigte Verzeichnisstruktur angelegt. Dazu gehören u.a. die Verzeichnisse myfiles und pool, die von den Backup-Skripten des Multiboot-Fopras verwendet werden. Am besten werden diese Dateien und Verzeichnisse vom Secserver kopiert.
Nachdem ein Client das Restore-System gebootet hat, wird er zum Login aufgefordert. Als User install loggt man sich ein, was die Ausführung eines kleinen Shell-Skripts bewirkt, das den User secpback über SSH am Server anmeldet. Nach dem Login von secpback wird das Skript master.pl im /backup-Verzeichnis interaktiv abgearbeitet. Um während der Backup-/Restore-Prozedur nicht ständig das root-Passwort eingeben zu müssen, ergänzt man die Datei authorized-keys im .ssh-Verzeichnis des Users root im Restore-System um den Public-Key des Users root vom Secserver.
Wählt man den Restore des Defaultimages, so werden auf dem Client die Partitionen mit einem Cryptofilesystem angelegt und das Defaultimage des SuSE9.1-Systems installiert. Das Restore-System nutzt eine Kombination aus Dump und Restore. Dazu wird mittels
#dump -0anf /backup/myfiles/itsec1_default.dump -e 17386,21547,165 /
ein Dump erzeugt und anschliessend mit
#gzip /backup/myfiles/itsec1_default.dump > /backup/myfiles/itsec1_default.gz
komprimiert. Die Optionen des Dump-Aufrufs sind im Folgenden erklärt: