Avant de mettre en place le serveur d'installation je tenais à faire un rappel sur quelques points particuliers de la procédure d'installation de Solaris.

Tout d'abord il existe différentes installations de Solaris. Le première est une installation initiale,c'est à dire que l'on va recharger l'ensemble du système d'exploitation en écrasant le système déjà existant. La seconde est le rechargement par upgrade (mise à jour) qui permet de modifier le système par rapport à un système déjà chargé. Ce type d'installation est utile dans le cas d'un système défectueux ou tout simplement pour mettre à jour Solaris vers une version supérieure.
Pour les installations intiales, le programme d'install va demander de choisir le metacluster d'install voulu. Ces metacluster sont au nombre de cinq. Ils permettent de définir le rôle d'une station et d'installer les packages nécessaires à ce rôle.

Cinq metaclusters:

• core (SUNWCreq): installation minimum, il n’y a pas chargement de l’interface graphique.
• End user (SUNWCuser): Station de travail standard (avec interface graphique), pas de documentation (man).
• Developper (SUNWCprog) : End user + pages de manuelles et librairies.
• Entire (SUNWCall) :Developper + certains logiciels nécessaires aux serveurs.
• Entire plus OEM Supports (SUNWCXall) :Entire + Drivers supplémentaires.

Les noms en gras correspondent au nom logiciel des metaclusters (utilisés dans création du serveur jumpstart…)

En fonction du metacluster choisi à l'installation il faudra réserver un espace disque différent pour la partition racine:

• End user : 1,6 Go
• Developer : 1,9 Go
• Entire: 2,3 Go
• Entire plus OEM: 2,4 Go

Etudions maintenant le contenu des différents CD fournis pas Sun...

• Le CD nommé installation permet de booter une machine sur cdrom, de charger un mini système d'exploitation qui contient l'installation webstart de Solaris. Cette installation est effectuée à travers un navigateur nestcape où l'utilisateur va devoir répondre à différentes questions afin de choisir et de paramétrer son installation. Ce CD ne sera pas utiliser durant toute la procédure de création du serveur d'installation.

• Le CD nommé 1/2 permet lui aussi de booter sur cdrom et de charger un mini OS. Il permet de lancer l'installation de Solaris à l'aide d'un programme soit en ligne de commande, soit en mode fenêtré (openwindows). Ce CD contient les packages nécessaires aux installations core et end user.

• Le CD nommé 2/2 contient les packages nécessaires aux installations Developper, Entire et Entire OEM.
  Son chargement sera effectué au premier boot suivant l'installation du CD 1/2.

• Le CD nommé language contient les packages des différentes localisation. Le choix de la langue se fait pendant la phase de paramétrage  (CD installation ou CD 1/2).

Tous les autres CD fournis avec une distributions ne font pas partie intégrante du pack de CD d'installation. Ils peuvent être installer à n'importe quel moment.

Maintenant commençons …

 

Pour booter il nous faut trois démons:

• Le démon rarpd (reverse adresse résolution protocole). Il gère le protocole rarp qui permet de faire de la translation d'adresse mac et d'adresse ip inverse. Inverse car c'est à partir de l'adresse mac du client que le serveur affecte une ip au client. Ce démon utilise le fichier /etc/ethers qui contient l'adresse mac (Ethernet) du client et l'alias réseau défini dans le fichier /etc/hosts (ou /etc/inet/hosts pour Solaris). Il utilise aussi le fichier hosts qui permet de faire la relation entre une adresse ip et un alias réseau.

• Le démon bootparamd permet de positionner les options de boot du client. Ce démon utilise le fichier /etc/bootparams qui contient les options de boot du client ainsi que le serveur à contacter. Pour que le client puisse utiliser les fichiers de boot du serveur, celui ci doit exporter le répertoire de boot en nfs. Pour ce faire il faut remplir le fichier /etc/dfs/dfstab puis exécuter la commande shareall (Solaris). Pour Linux, il faut remplir le fichier /etc/export et exécuter la commande exportfs.

• Le démon tftpd permet la copie du fichier de boot du serveur vers le client. Ce démon utilise comme méthode de lancement inetd.conf (ou xinetd selon le cas). On stocke les fichiers nécessaires au boot du client dans le répertoire /tftpboot.

Mise en place du serveur de boot:

On récupère l'adresse mac de la machine cliente avec la commande banner de l'obp ou tout simplement avec la commande arp -a

Notre machine cliente s'appelle tac (c'est la petite sœur d'une autre bécane non présente dans l'exemple qui s'appelle tic).

On définit une adresse ip pour cette machine (192.168.1.200 dans le cas présent). La machine cliente devra obligatoirement se trouver sur le même réseau que le serveur de boot (ici machine nommée serveur qui possède l'adresse 192.168.1.100).
On modifie le fichier /etc/inet/hosts afin de créer les alias réseaux et le fichier /etc/ethers afin de faire la relation entre l'adresse mac du client et son adresse réseau.

On démarre le démon rarpd (affectation d'un ip au boot du client) en exécutant la commande ci dessous (ou on crée le répertoire /tftpboot qui permettra de lancer le démon rarpd au prochain boot.) Pour Linux il suffit de lancer /etc/init.d/rarpd start.

Notre démon tourne bien !!!

A partir de cette étape nous pourrions lancer au niveau de l'obp de la station cliente la commande boot net. La cliente récupérerait bien une ip (c'est tout ce qu'elle peut faire d'ailleurs à ce niveau mais on peut vérifier que tout est ok avec un p'tit coup d'arp -a ).

Maintenant on récupère les fichiers de boot du CD 1/2 de Solaris (peu importe la version, elle devra juste correspondre à la version souhaitée sur le client). Pour faire cela, Sun nous a fournit un script qui crée tout seul le répertoire de boot. Il se trouve sur chaque CD d'installation de Solaris (1/2 et 2/2)dans les répertoires Solaris_8/Tools. Pour créer ce répertoire de boot il suffit de le lancer la commande setup_install_server avec l'option -b.

Dans notre exemple, le répertoire d'accueil des fichiers de boot sera /export/boot

On peut observer que la commande setup_install_server -b a crée dans le répertoire /export/boot une arborescence qui contient les fichiers nécessaires aux boot de la station cliente.

Le shell ci-dessus affiche le contenu du répertoire Boot qui se trouve sous /export/boot/Solaris_8/Tools.

 

Les autres scripts du répertoire (gentiment fournis par Sun) nous serviront plus tard.

En observant de plus prés le contenu de Boot, on s'aperçoit qu'il possède des fichiers qui seront inutiles.(poussé par une certaine habitude de l'optimisation je vais essayer de supprimer l'inutile).On va tout d'abord calculer la taille actuelle du répertoire afin de chercher où les bactéries attaquent…

Un p'tit du -sk va nous permettre d'effectuer cela. La commande du (disk used) permet de calculer la taille d'un répertoire ou d'un fichier. On passe donc la commande du dans le répertoire Boot…

Trois répertoire sortent du lot par leur taille importante. Kernel, platform et usr:

• kernel contient le noyau ditgénéral (c'est à dire commun à toutes les architectures) donc pas touche !!!

• platform contient la partie du noyau specifique à chaque type de platform, sachant que je ne vais utiliser qu'une sparc4 (sun4m,tac) et peut être mon u5 (sun4u, serveur) je vais supprimer tout le reste.

• usr contient les librairies ainsi que les binaires. On peut supprimer certain répertoire qui ne nous serviront pas. Je supprime le répertoire openwin et dt (interface CDE et OpenWindows), ensuite, j'effectue dans le répertoire /usr/platform la même manip que pour le répertoire platform.
  Et hop 85Mo c'est toujours ça …

Je tiens à préciser qu'il est possible de créer le répertoire boot manuellement sans utiliser le script setup_install_server. Pour ce faire, il suffit de copier le répertoire Boot qui se trouve sur le CD 1/2 dans le répertoire Solaris_8/Tools. Ensuite il suffit de supprimer les quelques répertoires inutiles bien que cela ne soit pas obligatoire.

Remarque: Le CD 1/2 possèdent plusieurs partitions.(De 0 à 5). La partition s0 contient le répertoire d'installation de Solaris (dont le repertoire Boot). La partition s1 contient le répertoire de Boot utilisé pour le boot cdrom. Les partitions suivantes contiennent les fichiers d'amorce de boot pour les différents types de platform ( 4c, 4d, 4m et 4u). J'ai essayé de récupérer la partition s1 (seulement 74 Mo) pour créer le repertoire de boot mais mon test n'a pas été concluant. Il manque trop de binaires dans les répertoire /usr/bin et /usr/sbin. Je pense qu'il y a moyen d'utiliser cette méthode afin d'alléger le serveur de Boot mais à l'instant où j'écris cette procédure je n'ai pas encore eu le temps de tester cela.

 

Maintenant passons au paramétrage du serveur…

Nous allons commencer par régler le problème du démon bootparamd. Pour cela Sun nous a encore fournit un script qui va travailler pour nous. Le script add_install_client (sous Solaris_8/Tools du répertoire de boot).

Le script à ajouter au fichier /etc/dfs/dfstab le repertoire de boot, ensuite il a paramétrer le fichier /etc/bootparams et a effectuer un ajout dans le répertoire /tftpboot. Etudions tout ça de plus près…

Le répertoire de boot est bien exporté en nfs. (commande share)…

C'est ok !!!

Le fichier /etc/bootparams, dans l'ordre, nom du client, chemin des fichiers de boot, chemin des fichiers d'install (inutile pour l'instant) et les options de boot.

Vérifions que le démon bootparamd tourne bien. (il s'appelle rpc.bootparamd)

Ok ça tourne aussi !!!

Dans le répertoire /tftpboot, on trouve le fichier d'amorce de boot (inetboot) et un lien symbolique portant le nom C0A801C8.SUN4M pointant vers le fichier inetboot. En fait le nom de ce fichier correspond à l'adresse ip du client codé en Hexadécimal suivi du type de plate-forme. Le dernier fichier (rm.192.168.1.200) est un script permettant du supprimer le client. Il est utiliser par le script rm_install_client du répertoire /export/boot/Solaris_8/Tools.

Le client va avoir besoin de récupérer l'amorce de boot (fichier inetboot du répertoire tftpboot). Il est propre au type de plate-forme sélectionner pour le client (dans notre cas sun4m). Lors de l'utilisation du script add_install_client celui a copié le fichier inetboot du répertoire /export/boot/Solaris_8/Tools/Boot/usr/platform/sun4m/lib/fs/nfs. Pour un client en sun4u, il suffit de changer sun4m par sun4u dans le chemin de recherche. Pour récupérer ce fichier d'amorce, le client se connecte en tftp.
Le Démon tftp du serveur est lancé via le fichier inetd.conf (vérifiez que la ligne ne soit pas commenter dans le fichier /etc/inetd.conf).

Dans notre cas la ligne n'est pas commentée. Si cela avait été le cas, il suffisait d'enlever le diese et de redémarrer inetd par un par la commande pkill -HUP inetd. On peut voir aussi que à niveau que l'on définit le répertoire d'accueil du tftp. Dans notre cas il s'agit bien de /tftpboot.

Pour vérifierle fonctionnement de tftpd on va effectué un tftp en local (localhost)

Pas de problèmes le démon s'active bien ….

…Là on est pas mal !!!

Pour une config sous Linux, la méthode diffère un peu au niveau de la gestion du démon inetd. En effet celui-ci a été remplacer par une nouvelle version qui se nomme xinetd. Les services ne sont plus directement intégrés dans le fichier de conf (pour cette version il s'appelle /etc/xinetd.conf). Ils possèdent chacun leur propre fichier de configuration et ils sont rassemblés dans le répertoire /etc/xinetd.d . Il suffit de créer un fichier de conf pour le tftp et de redémarrer xinetd par la même méthode qu'avec notre bon vieux inetd. Comme une explication complète du paramétrage de xinetd serait hors de propos je vous donne mon fichier de config. De plus il a fallu que j'installe les rpm (rarpd, bootparamd et tftp) car je ne les avais pas sélectionner lors de l’installation initiale de Linux (ah gain de place quand tu nous tiens …)

Maintenant on peut tester le boot à partir de notre client (tac) et on va utiliser la commande snoop pour vérifier ce qui ce passe…

Au niveau de notre machine tac (client), on exécute la commande boot net -s (on boot en single user car on veut juste tester le boot) . Sur le serveur on fait un snoop sur l'interface réseau hme1 (interface où se trouve branché notre client), l'option -d spécifie l'interface à écouter et l'option -o permet d'enregistrer le tout dans un fichier.
(On break avec control + C)

On récupère seulement les 5 premières lignes de notre fichier de snoop et on voit que le client récupère bien une  adresse ip que le serveur lui a attribué.

On vérifie la table d'arp…

Le client (tac) a bien une adresse ip, on laisse continuer le boot et là, miracle, le client a booté.

Voilà, notre serveur de boot est opérationnel. Bien sûr pour l'instant cela ne sert pas à grand chose à part, booter en single user sur une machine qui ne possède pas de lecteur de cd-rom (ce qui est mon cas).
Et puis, je trouve cela plus simple car je n'ai plus de besoin de mettre ma lampe de spéléologie pour retrouver les CD.

Attaquons nous maintenant au serveur d'install !!!

 

 La méthode de création d'un serveur d'install ne diffère pas beaucoup de celle du serveur de boot. Il va falloir juste récupérer les sources des CD d'installation de Solaris afin de créer un répertoire d'installation.
Pour ce faire Sun nous a encore fournit un script, setup_install_server, oui oui celui là même que nous avions utiliser pour créer notre serveur de boot, à la différence près, que cette fois ci nous n'allons pas utiliser l'option -b (réservé au boot).
Donc on insert le CD 1/2 dans le lecteur …

Pour les autres CD (2/2 et language) nous utiliserons le script add_to_install_server se trouvant dans le répertoire Solaris_8/Tools des différents CD respectifs.

Dans mon exemple je part sur une configuration bien distincte entre le serveur de boot et le serveur d'installation.Il est bien sûr possible(et sûrement plus fréquent) d'utiliser le même répertoire sur le même serveur. Nous obtiendrions un seul répertoire /export/install, qui contiendrait nous seulement les sources d'install mais aussi le répertoire de boot (/export/install/Solaris_8/Tools/Boot).

Pour continuer sur ma lancé je vais supprimer le nouveau répertoire Boot ( sous Tools )afin de gagner de la place.(Il fait quand même 230 Mo…)

Pour une config. sous Linux, il va y a avoir des problèmes d'exécution du script setup_install_server. Pour transformer une machine Linux en serveur (de boot et/ou d'install) il suffit de copier la partition s0 du CD 1/2 et d'effectuer la même procédure que sous Solaris. Ceci pour dire que l'on peut copier l'arborescence des CD sans utiliser le script fournit par sun.

Sur nos CD nous avons aussi un répertoire patch dans le répertoire Solaris_8. Celui ci permet de stocker certain patch à appliquer lors de l'installation de notre client. Ceci est pratique car cela évite de les installer manuellement par la suite ( je rappelle qu'on est en train de tester une installation automatisée alors automatisons que diable !!!).

Pour connaître les patchs à installer sur une machine je trouve la procédure de Sun un peu particulière.
On ne peux pas trouver sur le site sunsolve (http://fr.sunsolve.sun.com) la liste des patchs à appliquer à partir d'une version spécifique de Solaris. (Comme on trouve par exemple chez Microsoft , ou la, ou la qu'est-il dit ??? ).
La liste des patchs à appliquer est celle fournit dans un ensemble de patch que l'on appelle les Recommended.
Ce fichier ( les recommended sont fournis sous forme d'archive zip) contient tous les patchs de mise à jour de Solaris par rapport à la première version sortie de Solaris. Evidement beaucoup d'entre eux sont devenus obsolètes dans le sens, où ils sont déjà intégrés aux nouvelles versions de Solaris. (par exemple la 07/03 de Solaris 8) .

Ce que Sun nous propose pour connaître les patchs à intégrer au serveur d'install c'est un script qui permet de connaître le nombre de patchs qui vont être manquant par rapport à une installation déjà existante. Pour faire simple, vous avez un système qui tourne sous Solaris, vous avez un répertoire d 'installation, vous exécuter le script analyze_patches qui se trouvent dans le répertoire Solaris_8/Misc du CD ou du répertoire d 'install et celui-ci va vous donner la liste des patchs qui seront rendus obsolètes, incompatibles ou qui seront effacés après un réinstallation.

Je n'aime pas trop cette méthode car cela oblige à posséder un système de même architecture installé afin d' être certain que la liste soit fiable. Pour être sûr de la fiabilité de notre liste il faut vérifier chaque patch manuellement en se référant au READ_ME pour décider de sa nécessité. (Je vous cache pas que cela va être long …)

Pour effectuer la mise à jour des patchs, j'ai créer un petit script qui va  permettre de connaître le noms des patchs (par rapport à la liste Recommended) qui ne sont pas présents sur un système, ou qui ont une version plus récentes.
Ce script va remplacer le fichier patch_order du répertoire Recommanded qui sert au script d'install des Recommended pour connaître l'ordre d'installation des patchs.
Il faut savoir aussi que tous les patchs stockés dans le répertoire Patch du serveur d'install ne sont pas installer obligatoirement comme par exemple lorsque ces patchs concernent une application qui n'est pas installé. Pour éviter un problème à l'installation des patchs j'effectue leur installation à la fin de l'installation grâce au serveur jumpstart. ( Cf serveur jumpstart).
Pour cela j'ai créé un répertoire /export/patch qui contient les patchs à installer ainsi que le fichier patch_order crée à l'aide de mon script.
Bien sûr il ne faut pas oublier d'exporter en nfs le répertoire /export/patch.

Script maison utilisé pour la création d'une liste de patchs à installer. Il génère un fichier patch_order qui contient la liste des patchs classés par ordre d'installation. Pour que ce script fonctionne il faut l'exécuter ce script à partir du répertoire Recommended.

….Revenons un peu à nos montons car on a encore 2 CD à faire.

Le CD 2/2 d'installation …

Pour le CD language je vais modifier un peu la procédure car je n'aime pas tellement celle utiliser pour l'intégration des différentes langues avec le script add_to_install_server. En effet ce script installe toutes les langues disponibles sur le CD ce qui fait perdre énormément de place dans notre répertoire d'install alors qu'il est peu probable d'utiliser un jour le coréen, le chinois ou tout simplement l'allemand en utilisation de Solaris.
Comme il serait assez long de supprimer chaque package manuellement (ou à l'aide d'un p'tit script créé par nos soins), je propose plutôt de copier dans un premier temps le CD language dans un répertoire tampon, le script add_to_install_server. Je précise que les différents packages sont stockés dans le répertoire component du CD.

A ce niveau nous ne pouvons pas encore lancer le script add_to_install_server car il existe un fichier sur le CD qui contient la liste des langues à installer. Nous devons mettre en cohérence ce fichier avec les langages que nous avons décidés d'installer. Pour cela il faut ouvrir le fichier .cdtoc (dans la racine de notre répertoire tampon) et effectuer cette cohérence…

Fichier /export/tampon/.cdtoc après modification

Exemple d'intégration du CD lang au répertoire du serveur d'install. Il ne reste plus que deux langues lors de l'intégration.

 

Notre répertoire d'installation est prêt. On peut tester une installation réseau du client en utilisant la commande obp " boot net  ".

 

Jusqu'à maintenant nous avons créé un répertoire d'installation qui nous permet d'installer une machine par réseau dans un mode interactif. Maintenant nous allons automatiser tout ça !!!

Une automatisation d'installation se décompose en deux phases, la première que l'on appelle l'identification (sysidcfg)et la deuxième qui est le paramétrage de l'installation (jumpstart). Pour commencer nous allons créer un répertoire de stockage pour notre serveur jumpstart.

On retrouve bien nos répertoires install, Boot et le nouveau répertoire jumpstart.

Il ne faut pas oublier d'exporter en nfs le répertoire jumpstart à l'aide du fichier /etc/dfs/dfstab et de la commande shareall

Identification:

La première phase de l'installation concerne l'identification de la machine. C'est à cette étape que nous allons définir la langue utilisée pour l'installation, le hostname de la station, l'adresse ip, le netmask … Je vous invite à vous tourner vers les guides d'installation avancée de Solaris pour connaître tous les paramètres. (cf. liens)

Lors de l'installation les programmes d'installation de Solaris, suninstall (ligne de commande) et web_start ( installation en mode graphique) recherche un fichier nommé sysidcfg pour trouver les paramètres d'installation.
Par défaut le programme d'install va chercher ce fichier sur une disquette mais on peut lui indiquer où trouver ce fichier. C'est encore grâce au fichier/etc/bootparams que l'on va définir cela.

Comme pour définir les clients de notre serveur d'install,on peut utiliser le script add_intall_client avec une option ( -p ) mais on peut aussi insérer manuellement un nouveau champ dans le /etc/bootparams à l'aide d'un éditeur de texte.

Je ne vais par rentrer dans une explication trop complète du contenu du fichier sysidcfg car la documentation Sun est très complète (cf. liens), je vais plutôt vous donner un exemple. Je tiens à préciser que le fichier doit obligatoirement porter le nom sysidcfg.
Dans le cas d'un serveur possédant plusieurs clients, il faudra définir un répertoire de stockage du fichier sysidcfg différent par client car on ne peut bien sûr pas mettre plusieurs fichiers sysidcfg dans un même répertoire.

Fichier sysidcfg. (Le mot de passé crypté du mot clé root_password a été copier à partir du fichier /etc/shadow de notre serveur).

 

Installation automatisée (jumpstart):

Une installation automatisée jumpstart utilise plusieurs fichiers. Le premier fichier (et le plus important…) est le fichier rules (rôle en anglais). Ce fichier permet de référencer les clients jumpstart, les fichiers à exécuter et les actions à mener pendant l'installation.

Ce fichier contient plusieurs champs. Les deux premiers champs correspondent à la référence du client en fonction de différents mots clé (qui peuvent être le hostname du client, son architecture matériel, son réseau etc…) suivi de leurs arguments.
On peut cumuler les arguments à l'aide d 'un ET logique (&&). Par exemple on prend comme mot clé hostname (nom de machine) et comme argument tac (nom de notre client). On peut cumuler les arguments en précisant plusieurs machine : hostname tac && tic.

Le troisième champ sert à l'appel du fichier begin. Avant et après l'installation on peut exécuter des scripts appelle les fichiers begin (pré installation) et finish (post installation). Ces fichiers vont nous permettre d'effectuer des taches pré et post install. On peut choisir n'importe quel nom pour ces fichiers begin et finish, la seule condition c'est qu'ils soient présents dans le répertoire jumpstart et qu'ils possèdent les droits d'exécution.

Le quatrième champ correspond au fichier de profile. Ce qu'on appelle un profile lors d'une installation, c'est un fichier qui contient les paramètres d'installation et qui correspond à un type de machine référencé dans le fichier rules. Dans ce fichier, qui peut porter n'importe quel nom, on stocke les différentes réponses de l'installation comme le partionnement, le metacluster d'installation (core, end user …).

Comme il existe énormément de paramètres, je vous invite encore à lire le guide d'installation avancé pour remplir ce fichier. cf. liens) Ce fichier de profile permet d’ajouter ou de retirer des packages aux metaclusters d'installation.

Le dernier champ du fichier rules va correspondre au fichier finish grâce auquel on va effectuer des taches post install,comme l'ajout de patchs, de logiciels ou bien le paramétrage des fichiers d'environnement.

Voyons quelques exemples de fichiers:

Dans mon exemple je n'ai pas crée de fichier de begin, j'ai donc inséré un " - " dans le champ.

Dans ce fichier j'ai défini le type d'install (initiale) et le metacluster d'installation. SUNWCuser correspond à une installation end user. (cf. liste des metaclusters). J'ai effectué un partionnement spécifique pour mon disque système. (pour le partionnement par défaut on utilise l'argument default).
J'ai choisi aussi la langue (française) pour l'utilisation de Solaris et j'ai ajouté certains packages qui n'étaient pas inclus dans le metacluster end user. Ceux ci correspondent au manuel man (utile…) et au bash.

Pour que tout fonctionne il faut bien sûr que ces packages soient présents dans le répertoire Product de notre serveur d'install. 

J'utilise ce fichier pour ajouter certain patchs. J'ai créer un répertoire /export/patchs qui contient les patchs à ajouter (ne pas oublier de l'exporter …). J'utilise le fichier patch_order, crée avec mon script (script_patch) sens. (Cf serveur d'install ). Je supprime aussi grâce à ce fichier les services inutiles et je rajoute des entrées dans le fichier /etc/hosts.

Avant de pouvoir lancer notre installation il reste deux petites opérations à effectuer pour que tout fonctionne.

Le programme d'installation n'utilise pas directement le fichier rules dans son état brut. Le programme recherche un fichier rules.ok. Ce fichier est généré à l'aide du script check présent dans le répertoire Solaris_8/Misc/jumpstart _sample. Pour générer le fichier rules.ok, on copie le script check dans le répertoire jumpstart et on l'exécute. Celui va vérifier le fichier rules et généré le fichier rules.ok. Cela nous permet de vérifier la syntaxe de notre fichier rules.

La dernière opération à effectué est l'ajout d'une entrée dans le fichier /etc/bootparams afin que le programme d'install puisse trouver notre serveur jumpstart. On peut utiliser le script de Sun add_install_client avec l'option -c ou tout simplement ajouter un champ dans le fichier à l'aide d'un éditeur de texte.

Notre serveur est prêt. Il ne nous reste plus qu'a effectuer l'install en croisant les doigts que tout fonctionne…Il est possible qu'en fonction des machines utilisées (serveurs ou clientes) il soit nécessaire de modifier quelques paramètres.

Bien sûr je ne suis pas à l'abri d'une erreur et je reste donc à votre disposition pour toutes observations …
De plus, à tous ceux qui testeront cette procédure, ceux qui paramétrons des fichiers profiles ( de ouf !!!) ou ceux qui effectuerons des tests particuliers, je suis preneur de tous vos résultats…

Bonne installation ..