Solaris-OMA-Management-Konsole booten
Grundlage der Solaris-OMA-Management-Konsole ist die Installations-DVD von Solaris. Darauf befindet sich in Form einer Miniroot-Datei eine Minimalfassung von Solaris. Diese Datei lässt sich vom Netz oder von CD booten. Die originalen Skripte in der Miniroot-Datei haben die Aufgabe, Sie per Menü durch die Installation zu führen beziehungsweise ein Shell-Skript abzuarbeiten, das versucht, die Antworten auf die Installationsabfragen auf einer Freigabe zu finden. Der Client holt sich per NFS-Protokoll die Installationsdaten von der auf die Freigabe kopierten DVD. Sun Microsystems bietet dieses als "JumpStart" bekannte Verfahren als unbeaufsichtigtes Setup für Solaris an.
Für die Features von OMA reicht dies jedoch nicht aus. Der Client soll in eine per SSH-Protokoll ansprechbare, sichere und vollwertige Solaris-OMA-Management-Konsole booten. Aus diesem Grund müssen Sie in OMA eine Bootinstanz anlegen. Die Bootinstanz übernimmt die Miniroot-Datei von der Solaris Installations-DVD und bietet per Menü eine Modifizierung an. Als Ergebnis dieser Modifizierung entsteht ein Miniroot, das Sie automatisch bis zu einem gestarteten SSH-Serverdienst führt. In die modifizierte Datei müssen noch die SSH-Schlüssel hinein und eventuell weitere Verwaltungsinformationen. Sofern die Installation auch mit einer sicheren OMA-Boot-CD und einer angesteckten USB-Festplatte komplett lokal ablaufen soll, ist etwa noch die Datei bootdisk.db nötig. Über diese Datei kann sich ein Client selbst adressieren, wenn er keinen Netzkontakt zu einem OMA-Server herstellen kann.
Zum Anlegen einer OMA-Bootinstanz für Solaris 10 x86 muss ein OMA-Server existieren, der unter Solaris 10 x86 läuft, da die Programme zum abändern der Miniroot-Datei nur unter dieser Version funktionieren. Ist die Bootinstanz erstellt, lässt sie sich aber auch auf OMA-Servern verwenden, die unter Linux oder MacOS X laufen. Beim Brennen einer Solaris-Bootinstanz als OMA-Boot-CD zeigt sich, wie wenig auf die CD muss: Das Verzeichnis "boot/grub" und die beiden Dateien boot/x86.miniroot und boot/multiboot reichen schon. Das Programm "grub" aus dem gleichnamigen Verzeichnis übernimmt nach Anweisung aus der Datei boot/grub/menu.lst das Booten des 64-Bit-Kernels, der zusammen mit dem SSH-Serverdienst in der angepassten Datei boot/x86.miniroot steckt. Die von OMA erstellt Datei menu.lst hat nur einen einzigen Booteintrag:
default=0 timeout=5 title OMA Boot CD - solaris10_x86_64bit.2009_10_u8 kernel /boot/multiboot kernel/amd64/unix module /boot/x86.minirootObwohl sich hinter der Datei /boot/x86.miniroot bei der 64-Bit-Version ein 400 MByte großes UFS-Dateisystem versteckt hält, kann die Datei mit Hilfe des Programms gzip noch auf 150 MByte reduziert werden, was die Übertragung in den Hauptspeicher des Clients per TFTP-Protokoll beschleunigt. 1 oder besser 2 MByte Hauptspeicher sind die Grundanforderung, um die Ramdisk im Speicher auszupacken und dem Client noch ein bisschen Platz zum arbeiten zu lassen. Relevant ist die Entscheidung, ob ein 32-Bit- oder ein 64-Bit-Kernel zu booten ist. Da bestimmte Treiber, die nicht von Sun Microsystems stammen, nur in einer 64-Bit-Version vorliegen, müssen Sie diese Entscheidung mit Bedacht treffen. Ein Miniroot mit 64-Bit-Support finden Sie erst ab Solaris 10 x86 2009/10 u8 auf der DVD. Film IV-1 zeigt den Bootvorgang in eine 64-Bit-Solaris-OMA-Client-Console vom Netz.
So muss die Partitionierung aussehen
Solaris akzeptiert nur eine primäre Partition pro Festplatte. Innerhalb dieser lassen sich dann sogenannte Slices anlegen. Minimal muss es das Slice "s0" geben. Bei Verwendung des UFS-Dateisystems ist das Dateisystem immer so groß wie das angelegte Slice. Beim ZFS-Dateisystem werden sämtliche s0-Slices aller Festplatten zu einem ZFS-Pool zusammengelegt. Innerhalb dieses Pools ist dann das Anlegen sogenannter Data-Sets möglich. In bester Volume Manager-Tradition lassen sich die Data-Sets frei verschieben und wachsen so, wie die Inhalte es erfordern. Lediglich die Gesamtsumme des verfügbaren Plattenplatzes in einem ZFS-Pool lässt sich nicht modifizieren. In unserer Testumgebung hatte ein Unix-OS immer ein Stück Platte (Slice beziehungsweise Dataset) für das root-Dateisystem und ein Stück Platte für ein leeres home-Dateisystem. Eine weitere Sektion für den swap ist in Solaris ebenfalls angebracht. Schließlich ist auch ein separates VAR-Dateisystem nicht verkehrt, wenn Sie bei der Verwendung von UFS-Dateisystemen das Volllaufen des root-Dateisystems über Datenablagen in "/var/tmp" verhindern wollen.
Da bei OMA-Archiv-Images die Daten und die Partitionierungen getrennt voneinander verwaltet werden, ist die Platteneinteilung der Musterinstallation eigentlich unerheblich. Am Ende der manuellen Musterinstallation müssen Sie diese noch neutralisieren. Rufen Sie dazu die Prozedur oma2solaris.sh direkt auf dem eingesteckten USB-Stick auf, was zur Deaktivierung aller Netzwerkkarten führt. Nach einem erneuten Bootvorgang existiert als Netzkarte nur noch der Loopback und der Rechner – in unserem Workshop mit dem Namen "paradiesvogel". Wenn Sie wollen, können Sie nun noch Meldungen des Programms sendmail abschalten und die Verwendung von "/home" für den Automounter deaktivieren (je nach Bedarf lassen sich die folgenden Befehle auch in ein Softwarepaket verpacken):
svcadm disable sendmail svcadm disable autofs
Seite 1 von 2 Nächste Seite>>
