Ports du serveur Ignite-UX

Le client envoie une demande d’amorçage au serveur sur le port 67. Cette demande est traitée par le démon bootpd sur le serveur. Si le client est enregistré, le fichier /etc/bootptab est utilisé pour l’adresse IP d’amorçage ; si le client est anonyme, les services DHCP sont utilisés pour attribuer l’adresse IP d’amorçage. Le serveur envoie ensuite les informations réseau au client sur le port 68. Pour plus de détails sur l’amorçage des clients Itanium enregistrés, voir la section « Configuration du serveur Ignite-UX pour les clients Itanium ». Pour plus de détails sur l’amorçage des clients Itanium anonymes, voir la section « Considérations relatives à l’amorçage de clients Itanium anonymes ». Pour de plus amples informations sur la commande bootpd, consultez la page de manuel bootpd(1M).

Le client envoie une demande d’amorçage au serveur sur le port 1067. Cette demande est traitée par le démon instl_bootd sur le serveur. Le fichier /etc/opt/ignite/instl_boottab est utilisé, que le client soit enregistré ou anonyme. Le serveur envoie ensuite les informations réseau au client sur le port 1068. Pour plus de détails sur l’amorçage des clients PA-RISC enregistrés, voir la section « Configuration du serveur Ignite-UX pour les clients PA-RISC ». Pour plus de détails sur l’amorçage des clients PA-RISC anonymes, voir la section « Configuration d’un serveur pour l’amorçage de clients PA-RISC anonymes ». Pour de plus amples informations sur la commande instl_bootd, consultez la page de manuel instl_bootd(1M).

Le noyau, le système de fichiers et les fichiers requis sont téléchargés sur le client par le serveur, puis le client est amorcé.

Le fichier install.log est mis à jour sur le serveur dans le répertoire /var/opt/ignite/clients/client. Une archive tar compressée des commandes de configuration des volumes de disques et des systèmes de fichiers est téléchargée (INSTCMDS sur les systèmes PA-RISC et INSTCMDSIA sur les systèmes Itanium). L’interface en mode caractère est exécutée sur la console client. L’utilisateur choisit la configuration de l’installation via cette interface et sélectionne Go!. Une archive tar compressée des commandes requises pour effectuer l’installation est téléchargée (SYSCMDS sur les systèmes PA-RISC et SYSCMDSIA sur les systèmes Itanium). Les ports utilisés par NFS pour effectuer les appels RPC (Remote Procedure Call) ne sont pas décrits ici.

Si l’installation est effectuée à partir d’une image, celle-ci est téléchargée. Les ports utilisés par NFS pour effectuer les appels RPC ne sont pas décrits ici.

Si la configuration de l’installation demande l’installation des logiciels à partir de dépôts sur le serveur, une demande swinstall est envoyée au démon Software Distributor (SD) du serveur, swagentd, sur le port 2121. Un agent SD, swagent, est ensuite généré sur le serveur afin d’obtenir l’affectation dynamique d’un port de communication pour le téléchargement. Ce port de communication est ensuite envoyé au client sur le port 2121. Le client génère un nouveau processus swagent qui communique avec le serveur sur le port de communication ainsi obtenu P, où est effectué le téléchargement du dépôt. Pour plus d’informations sur SD, reportez-vous au Guide d’administration Software Distributor figurant à l’adresse suivante : http://www.docs.hp.com.

	REMARQUE : Bien que swinstall soit illustrée ici, l’installation peut utiliser une ou plusieurs commandes swinstall, rexec (port 514), NFS (ports 49152–65535), ftp data (port 20) et ftp (port 21).

Le serveur envoie un « ping » au client avec une demande d’écho ICMP de type 8. Le client répond au « ping » par une réponse d’écho ICMP de type 0. Les fichiers requis par bootsys sont transférés du serveur vers le client. Par défaut, ces fichiers sont transférés par remsh, ou par ssh si l’option bootsys -S est utilisée.

Le noyau, le système de fichiers et les fichiers requis sont téléchargés sur le client par le serveur, puis le client est amorcé. Par défaut, ces fichiers sont transférés par rcp, ou par scp si l’option bootsys -S est utilisée.

Le serveur envoie un « ping » au client avec une demande d’écho ICMP de type 8. Le client répond au « ping » par une réponse d’écho ICMP de type 0. Si tftp est activée, la vérification de version est effectuée à l’aide du fichier /opt/ignite/Version.

Si tftp n’est pas activée, la vérification de version est effectuée à l’aide de swlist selon la séquence de dépôt swinstall décrite à la Figure 6-3.

Si le client utilise une version d’Ignite inférieure à celle du serveur, un dépôt des commandes de restauration est transféré sur le client à l’aide de la séquence de dépôt swinstall décrite à la Figure 6-3.

	REMARQUE : Bien que swinstall soit illustrée ici, l’installation peut utiliser une ou plusieurs commandes swinstall, rexec (port 514), NFS (ports 49152–65535), ftp data (port 20) et ftp (port 21).

Le serveur exécute make_net_recovery à distance sur le client. Par défaut, la commande est exécutée via remsh, ou par ssh si le client a été ajouté pour restauration sur le serveur avec l’option ssh.

	REMARQUE : Le client peut demander l’utilisation de ports privilégiés (1–1023) ou non, via la directive ssh_config. L’utilisation de ports non privilégiés est appliquée par défaut. Si vous souhaitez configurer ssh afin d’utiliser des ports privilégiés, vous devez appliquer un programme suid au client.

L’archive parfaite est envoyée au serveur de destination via remsh ou NFS. Il est à noter que make_sys_image n’impose pas de connexion réseau si l’archive est enregistrée en local sur le client.