Anschlüsse des Ignite-UX Servers

Der Client sendet über Anschluss 67 eine Startanforderung an den Server. Die Anforderung wird vom Daemon-Prozess bootpd auf dem Server verarbeitet. Bei registrierten Clients wird der Datei /etc/bootptab die Start-IP-Adresse entnommen. Bei anonymen Clients werden DHCP-Services zum Zuweisen der Start-IP-Adresse verwendet. Der Server sendet dann die Netzwerkinformationen über Anschluss 68 an den Client. Weitere Informationen zum Starten registrierter Itanium-basierender Clients finden Sie in „Konfigurieren des Ignite-UX Servers für Itanium-basierende Clients“. Weitere Informationen zum Starten anonymer Itanium-basierender Clients finden Sie in „Überlegungen zum Starten anonymer Itanium-basierender Clients“. Informationen zu bootpd finden Sie auf der HIlfeseite bootpd(1M).

Der Client sendet über Anschluss 1067 eine Startanforderung an den Server. Die Anforderung wird vom Daemon-Prozess instl_bootd auf dem Server verarbeitet. Die Datei /etc/opt/ignite/instl_boottab enthält Informationen darüber, ob der Client registriert oder anonym ist. Der Server sendet dann die Netzwerkinformationen über Anschluss 1068 an den Client. Weitere Informationen zum Starten registrierter PA-RISC basierender Clients finden Sie in „Konfigurieren des Ignite-UX Servers für PA-RISC Clients“. Weitere Informationen zum Starten anonymer PA-RISC Clients finden Sie in „Konfigurieren eines Servers für den Start anonymer PA-RISC Clients“. Weitere Informationen zu instl_bootd finden Sie auf der HIlfeseite instl_bootd(1M).

Der Systemkern, das Dateisystem und die erforderlichen Dateien werden vom Server auf den Client heruntergeladen, anschließend wird der Client gestartet.

Die Datei install.log wird auf dem Server im Verzeichnis /var/opt/ignite/clients/Client aktualisiert. Ein komprimiertes tar-Archiv mit den Befehlen zum Einrichten von Plattenvolumen und Dateisystemen wird heruntergeladen (INSTCMDS für PA-RISC und INSTCMDSIA für Itanium-basierende Systeme). Die TUI wird auf der Client-Konsole ausgeführt. Der Benutzer wählt die Installationskonfiguration über die TUI und wählt dann Go!. Ein komprimiertes tar-Archiv mit den für den Abschluss der Installation erforderlichen Befehlen wird heruntergeladen (SYSCMDS für PA-RISC und SYSCMDSIA für Itanium-basierende Systeme). Die von NFS zum Erstellen von RPC-Aufrufen (Remote Procedure Call) verwendeten Anschlüsse werden hier nicht beschrieben.

Wenn die Installation von einem Abbild durchgeführt wird, wird dieses heruntergeladen. Die von NFS zum Erstellen von RPC-Aufrufen verwendeten Anschlüsse werden hier nicht beschrieben.

Wenn für die Installationskonfiguration Software von Depots auf dem Server installiert werden muss, wird eine swinstall-Anforderung an den SD-Daemon-Prozess (Software Distributor) des Servers, swagentd, an den Anschluss 2121 gesendet. Dann wird ein SD-Agent, swagent, auf dem Server erstellt, der einen dynamisch zugeordneten Kommunikationsanschluss für den Download belegt. Dieser Kommunikationsanschluss wird dann an den Client an Anschluss 2121 ausgegeben. Der Client erstellt dann einen neuen swagent-Prozess, der mit dem Server auf dem verwendeten Kommunikationsanschluss A kommuniziert, über den der Download von den Depots stattfindet. Weitere Informationen zu SD finden Sie im Dokument Software Distributor Verwaltungshandbuch unter http://www.docs.hp.com.

	HINWEIS: Obwohl swinstall hier dargestellt wird, können bei der Installation ein oder mehrere der folgenden Befehle verwendet werden: swinstall, rexec (Anschluss 514), NFS (Anschlüsse 49152–65535), ftp data (Anschluss 20) und ftp (Anschluss 21).

Der Server sendet den Befehl „ping“ mit einer ICMP-Echo-Anforderung des Typs 8 an den Client. Der Client antwortet auf den Befehl „ping“ mit einer ICMP-Echo-Antwort des Typs 0. Die für bootsys erforderlichen Dateien werden vom Server an den Client übertragen. Diese Dateien werden standardmäßig mit remsh übertragen oder durch ssh, wenn die Option bootsys -S verwendet wird.

Der Systemkern, das Dateisystem und die erforderlichen Dateien werden vom Server auf den Client heruntergeladen, anschließend wird der Client gestartet. Diese Dateien werden standardmäßig mit rcp übertragen oder durch scp, wenn die Option bootsys -S verwendet wird.

Der Server sendet den Befehl „ping“ mit einer ICMP-Echo-Anforderung des Typs 8 an den Client. Der Client antwortet auf den Befehl „ping“ mit einer ICMP-Echo-Antwort des Typs 0. Wenn tftp aktiviert ist, erfolgt die Versionsprüfung mit der Datei /opt/ignite/Version.

Wenn tftp nicht aktiviert ist, erfolgt die Versionsprüfung mit dem Befehl swlist mit der in Abbildung 6-3 beschriebenen swinstall-Depotreihenfolge.

Wenn der Client eine niedrigere Version von Ignite als der Server verwendet, wird ein Depot mit Wiederherstellungsbefehlen mit der in Abbildung 6-3 beschriebenen swinstall-Depotreihenfolge an den Client übertragen.

	HINWEIS: Obwohl swinstall hier dargestellt wird, können bei der Installation ein oder mehrere der folgenden Befehle verwendet werden:swinstall, rexec (Anschluss 514), NFS (Anschlüsse 49152–65535), ftp data (Anschluss 20) und ftp (Anschluss 21).

Der Server führt den Befehl make_net_recovery fern vom Client aus. Der Befehl wird standardmäßig über remsh ausgeführt, oder durch ssh, wenn der Client zur Wiederherstellung auf dem Server mit der Option „ssh“ hinzugefügt wurde.

	HINWEIS: Der Client kann über die Anweisung ssh_config angeben, dass privilegierte Anschlüsse (1–1023) verwendet bzw. nicht verwendet werden sollen. Der Standardwert sind nicht-privilegierte Anschlüsse. Wenn Sie ssh so konfigurieren wollen, dass privilegierte Anschlüsse verwendet werden, müssen Sie den Client als suid-Programm verwenden.

Das Archiv mit einem idealen Modellbild wird über remsh oder NFS auf den Ziel-Server geschrieben. Für make_sys_image ist kein Netzwerkbetrieb erforderlich, wenn das Archiv lokal auf den Client geschrieben wird.