Bonjour.
 
Je cherche à installer un parc de Suse avec autoyast. Je sais que c'est possible avec cette outil, (fonctionnant sur le meme principe que Kickstart pour RH), mais impossible de le configurer correctement.
 
2 gros problèmes se posent :
 
- La création de mon fichier de conf : il est indiqué dans le manuel (non mis à jour) d'utiliser Yast et le module "autoinstallation", mais celui n'apparait jamais sous ma Suse 9.2 avec YaST. (le manuel était pour la 9.1).
Donc, pour l'instant je travaille avec un fichier (logiquement correcte) trouvé sur Internet... et très légèrement modifié à ma sauce.
 
- Les pécés n'arrivent pas à lire ce fichier. (XML) lors du début de l'installation.  
Je me retrouve toujours avec l'erreur "Error while merging control files" dans les logs de Yast (/var/log/YaST/y2log )
Je ne comprend pas, car j'ai essayé en passant par FTP, NFS, HTTP... idem à chaque fois.
 
Bref, si vous avez une idée pour me sortir de cette embuscade ....  
merci

 
C'est bon, j'ai trouvé mes problèmes... j'y répond, si jamais ca intéresse quelqu'un...
 
La doc est tellement peu claire qu'il faut impérativement utiliser SLES ou la Suse 9.1 pour générer les fichiers de conf avec l'utilitaire.
 
Après l'installation passe sans trop de soucis...  
je suis sur le point de déployer des Suse 9.3 sans interventions.. préconfiguré.
 

Les mises a jour de sécu sont assurées pendant combien de temps sur la Suse 9.3 ? Je trouve le release cycle de suse un peu trop rapide perso Ca fait pas vraiment distri pro, enfin faut bien qu'ils vendent Novell linux desktop

J'ai parlé un peu, vite, je déploie des 9.2 pour l'instant... la 9.3 n'étant pas disponible pour l'instant.
 
Sinon, pour les MAJ, je n'en ai aucune idée pour l'instant. Je vais étudier ce point cette semaine.
C'est comme RH, il propose une release tout les 6 mois... on est pas obligé de suivre non plus, car les améliorations sont probablement pas très très importantes....  
PS : je dis ca, mais je connais encore mal Suse.

si tu vas la ftp://ftp.suse.com/pub/suse/i386/9.2/suse/noarch/, tu trouveras  
 
autoyast2-2.10.13-2.1.noarch.rpm
autoyast2-installation-2.10.13-2.1.noarch.rpm
autoyast2-utils-2.10.13-2.1.noarch.rpm
 
et tu pourras fabriquer tes fichiers xml avec l'interface graphique

j'ai deja installé les 3 packages dont tu parles mais comment je m'en sers après !!
 
Merci

Dans Suse 9.3 (J'ai pas la 9.2, mais sa doit être pareil),
 
Tu lance Yast, tu vas dans Divers, et tu as installation automatique.
Et voilà.
 
Après, je ne l'ai jamais utiliser Autoyast.

 
Tous les 6 mois c'est comme Fedora, pas comme Redhat
Redhat enterprise linux, c'est 1 release tous les 18 mois, et le suivi de sécurité et le support pendant bien plus (moyennant finances bien sur)

Willits : tout à fait

 
Merci bien je va essayer

en effet c'est bien la !
 
Maintenant le probleme que je rencontre c'est une fois que j'ai fait mon fichier xml en utilisant l'autoyast quand je lance l'installe  
il me trouve bien le fichier et prend les parametres generaux et le partionnement mais il arrive pas à etablir la liste des packages et il me sort  
l'erreur suivante : "Impossible de définir la séléction de base : default"
Et j'ai esssayé avec d'autre liste de packages que default il veut rien savoir non plus  
 
si quelqu'un a reussi à passer cette étape je veux bien un coup de main parce que je suis bloqué

ouep , j'ai eu le meme problème.. car il faut réadapter le nom des sélections a celle de ta distribution.  
Tu peux pas prendre leur exemple...
 
Pour la Suse 9.2, regardes dans le rep /suse/setup/descr/
tu as la listes des "sélections" (les .sel)
 
donc mon xml me donne :

 
et la ça passe.

pourquoi vous n'utiliser pas yast et le module autoyast pour sélectionner les paquets pour vos profiles ? Depuis le temps que j'installes des SUSE, je n'ai jamais fabriquer de profiles en éditant le xml, mais plutot en utilisant leur outil qui est sympa

Oui biensur, ca doit être plus pratique
je maitrise pas bien encore Suse, et Yast, c'est pour cela.
Je vais revoir ca cette après midi avec la 9.2
 

en effet, c'est beaucoup plus simple comme cela.  
Par contre je ne comprend pas pourquoi, ces paquets (autoyast2-2 et autoyast2-utils ) ne sont pas présent sur le DVD.
 

ils le sont pour une 9.1 pro et une 9.3 pro en tout cas

ils le sont (en tout cas autoyast2-2).
 
sur une SLES9 (suse 9.2 enterprise) j'ai ca:

 
d'ailleurs, je sais faire generer le fichier xml par autoyast, mais apres j'en fait quoi?
En fait, j'ai un parc de serveurs a installer (petite ferme de calcul) est-ce que autoyast va gerer les differentes machines (mac@, ip, hostnames) sachant que tous les serveurs auront exactement la meme install?
J'aurais voulu faire les installs a partir d'un serveur d'install, faire en sorte que le xml soit accessible par le reseau et que tout le boot et l'install se passe par le reseau, j'ai trouve des docs ou ils parlent de disquette ou cd/dvd mais pas reseau.
Merci pour votre aide.
 
PS: la doc de la 9.1 pour ceux que ca interesserait : http://yast.suse.com/autoinstall/9.1/autoyast.pdf
 
EDIT: petite rectification, la SLES 9 est sur 6 CD, pas sur dvd, il n'y a peut-etre pas la meme chose...

pour faire ca il te faut une machine qui fasse dhcp/tftp/pxe/nfs (c'est la conf la plus facile) et quelques scripts à toi tu fabriques un template generique, tu remplaces les ip/netmask/hostname dedans par des expressions specifique du style #HOSTNAME#, #IP#, et apres tu fais une moulinettes qui parse ce template generique et te crée un fichier xml spécifique à chaque machine. J'ai fait un truc comme ça, et j'installe 50 machines en 30/45 minutes en comptant la conf du bios/raid, le recopiage des adresses mac (le plus chiant) dans le dhcpd.conf et le temps de l'install

Zoidberg : Tu n'as aucun soucis pour faire cela.
Il te faut juste un serveur DHCP qui alloue IP et hostname selon l'@MAC, ainsi que le dossier NFS à monter.
 
un serveur NFS qui partage ton arborescence des 6CDs (faire la manip comme dans la doc p56-57)
un serveur TFTP qui va donner l'adresse  du fichier de conf.
 
Je rédige aujourd'hui une doc la dessus. envoie moi un MP avec ton mail et je te la transfert.

En fait je voulais savoir ou trouver la doc qui explique tout ca.
Au jour d'aujourd'hui on utilise 'scali manage' qui se base sur autoyast, sauf qu'il gere les hostnames et le boot tout seul.
mais ca n'est pas genial et pas donne donc on pense l'abandonner au profit d'autoyast.
ah ben merci pedretti c'est cool... bon, les gens de scali arrivent a l'instant (nouvelle version qui doit parait-il tout corriger et ameliorer, j'en doute   ), je te contacte dans la journee.
Merci.

OK.
 
Je ne connais pas scali..  
Ca permet de faire quoi exactement ?
Comment cela fonctionne  ?
tu peux nous en dire un peu plus ?
 
Merci

Ben je ne connaissais pas non plus avant qu'ils pointent le bout de leur nez ici.
au niveau fonctionnement c'est base sur autoyast/kickstart, ca ajoute juste une surcouche qui permet de tout mettre en place plus "facilement" (enfin c'est ce qui est ecrit sur la doc ).
en gros: un serveur tftp pour deployer le fichier xml de conf, un serveur nfs pour les supports cd, un serveur dhcp pour choper les mac et enfin un boot pxe sur les clientes.
apparemment c'est souvent utilise pour le deploiment d'installs a grande echelle (en tout cas c'est ce qu'ils nous ont dit).
c'est (normalement) assez facile a configurer et a mettre a jour, et au niveau outil ca apporte:
- un outil de surveillance des machines (remontee d'alarmes, historisation cpu/disque/io/...)
- une gestion via des menus (texte) de toutes les reinstalls et autres confs.
- ca permet de gerer tout plein de machines facilement sans avoir a creer sois meme les entrees correspondantes a chaque machine, par exemple on va dire que la premiere machine va s'appeler toto001 et son ip sera 192.168.1.1 et on aura la possiblite de declarer les suivantes seulement en incrementant les noms et les ip), il fait aussi la decouverte des mac address tout seul.
ils ont aussi divers outils qui permettent d'integrer des softs pro facilement comme LSF (ca aussi c'est ecrit sur leurs docs mais en fait lsf n'a pas besoin d'etre deploye sur les serveurs et clients, il s'installe seulement sur un serveur NFS et tout le monde pointe vers lui)
Pour resumer sur le papier ca a l'air sympa et pro, mais en realite c'en est assez loin, beaucoup de bugs, de lacunes et des mises a jour trop frequentes (c'est pas tres pro)
Voili.

quand tu parles de lsf, tu parles du soft de Platform ? Pour l'instant, c'est vrai que ton outils à l'air sympa sur le papier, mais on peut arriver à la meme chose avec des produits open souce surement moins couteux

Oui c'est vrai qu'on y arrivent très bien en restant en opensource...
 
Actuellement je travaille justement sur ce genre de sujet... (Déploiement, mise à jour, et personnalisation du poste de travail)
et je but un peu sur le problème de la mise à jour des machines :
 
Admettons que j'ai un réseaux de 100 machines, avec des Debian, Suse, des Fedora...
-Pour les déployer, ça va.
-Pour mettre à jour les logiciels qui y sont installé.. je commence à chercher..comme ca je dirai
(pour les 3 OS) "apt-get update && apt-get upgrade" > sur le mirroir local que j'aurai mis à jour auparavant.
-Pour les mise à jour de sécurité, idem pour les mise à jour de sécurité.
 
Est ce que vous pensez que c'est une bonne idée ? que cela suffit  ?
Je pense que c'est suffisament simple et pratique à mettre en place.
 
Sinon pour les logiciels qui ne fond PAS partie des mirroir officiels (mirroir marrilat, lisnva, ...), comment faire pour les mettre à disposition des clients ?
J'aimerai consitituer un dossier sur le serveur, dans lequel figure les paquets que j'ai sélectionné à la main et que je souhaite déployer. Comment faire pour que cela soit pris en compte comme un mirroir ? (il n'y a pas de fichier base de donnée "Packages" )...
La je sèche.
 
Merci

 
Vi, c'est bien celui la meme, celui de platform et etant donne qu'il est deja utilise sur les gros serveurs de calculs (HP et Compag), et que la ferme y a ete integree, pour lui on ne peut pas y toucher (tant mieux, c'est un tres bon outil: stable, configurable a souhait et tres efficace) bon, il est peut-etre un peu cher mais bon, je pense qu'une entreprise s'y retrouve (ils ont un tres bon support aussi).
Pour en revenir a scali, il n'est pas trop cher (je n'ai pas les prix mais lorsque je discute avec les responsable il semblerait que ce soit de loin la moins chere des solutions payantes pour ce type de tache).
Lorsqu'on a une ferme standard sans specificite particuliere ca marche sans probleme (qu'ils nous disent) mais des qu'on a quelques trucs bizarre (et ca n'est pas ce qui manque ici ) et bien c'est la galere, ils sont obliges de faire du dev specialement pour nous .
Donc je pense qu'on va aller jeter un oeil du cote de Autoyast & Ganglia et voir si ca ne suffirait pas pour ce que l'on veut faire (installer des machines rapidement et facilement et les surveiller (pis aussi avoir un historique afin de voir ou ca coince ou encore ou il ne se passe rien de dans le but d'optimiser tout ca)).
 
pedretti75 >>
Concernant les mises a jour des logiciels, ce qui est fait ici et que je trouve pas mal, c'est un gros serveur NFS qui est accede par tout le monde (ou partie) a partir du meme point de montage (automontage via NIS) sur lequel on depose les softs et sur lequel on gere plusieurs versions de logiciels differentes (grace a des scripts en place pour chaque version de logiciel qui definissent les variables d'environnement qui vont bien), comme ca ca ne prends pas beaucoup de temps a installer, a deployer, a mettre a jour et pas beaucoup de place. Et si jamais un gars a besoin de garder une vieille version ou une version particuliere d'un logiciel ca ne bloque pas l'evolution du soft en question...

et oui on a tous les meme problemes en fait Ici il faut maintenir/administrer des redhat es3u4, Suse 9.1 Pro (x86 & x86-64), redhat 7.3, Suse 9.3 Pro... Et bien entendu, les machines ne sont pas toutes pareilles et ne font pas toutes les memes choses (sauf pour les serveurs de calculs qui representent 90% de mes machines). Mais globalement, je m'en sort bien pour les installer rapidement et sans solution particuliere à part kickstart, autoyast, kconsole et cluster ssh

 
Oki, merci du conseil.
Le truc c'est que j'aurai aimé qu'il installe les logiciels lors de phase d'installation. (au moins  cfengine, après je peux gérer les autres installations avec).
Ca voudrai donc dire qu'avec les outils d'installation (Autoyast, kickstart),je monte mon rep NFS, et execute un "rpm -i monPaquets.rpm" dans la partie script post installation. Mais s'il y a des dépendances... aie aie aie.    
 
Soyez pas trop méchant avec moi, je débute dans l'administration  

oui les dépendances avec rpm c'est chiant. C'est pour ça qu'il fait tester avant l'install des softs et mettre la bonne ligne rpm -ivh dans le post script du fichier kickstart/autoyast

 
Oki, ca confirme bien ce que je pensais. Merci beaucoup !
 
Pour l'instant je me suis pas penché sur les sections "post" de kickstart/autoyast..  maintenant je sais ce que je vais mettre dedans
 
D'ailleurs t'as pas un exemple ?  

Ici on evite au maximum les install via rpm, on recupere les sources et on compile dans la mesure du possible.
ca evite les problemes de dependances mais c'est parfois assez chiant.
En fait leur politique m'arrange bien, parceque c'est vrai que je ne suis pas trop 'rpm' (chez moi j'utilise une gentoo). on ne sait jamais trop avec quelles options ont ete compiles les rpms, alors qu'une compil/install via les sources c'est beaucoup plus clair (a mon gout).

 
dans autoyast il n'y a pas une section qui permet de resoudre les dependances tout seul?
 
a la fin de mon fichier de conf xml (scali, mais ca devrait etre ultra proche d'un fichier kickstart) j'ai ca:
 

 
on a pas a gerer les dependances, l'install se demerde toute seule.

 
Ca c'est strictement identique à un fichier autoyast. C'est simplement une sélection individuelle des paquets que tu souhaites. Je pense que ca résoud les dépendance automatiquement,puisque c'est rpm.. (je suis pas sur).

sous suse, c'est yast qui gere les dépendances. d'ailleurs pour installer un rpm de la distrib suse, un simple yast -i toto va installer toto et ses dépendances. C'est pour ça qu'il n'y a pas d'options pour les dépendances dans le fichier xml pour les rpm de base. Par contre, pour des rpm hors distrib, c'est la merde classique des rpm

Je change un peu de sujet, ...  a propos des boot PXE.
 
A chaque redémarage d'un machine il boot sur PXE et recommence l'install en boucle.
 
Est -ce qu'il ya une autre solution que de monter par NFS le rep /tftpboot du serveur et d'aller modifier le fichier C0A80032 correspondant à l'IP du client... pour qu'il boot sur le disque dur tel que :

Pour faire ca, en plus il faudrai que je connaisse l'addresse HEXA des clients lors de l'installation....  

me le donne bien, mais puisqu'il me faut se résultat, je vais devoir faire un script.

c'est plus facile de ne pas mettre le boot pxe par default Quand j'installe mes machines, j'appuie sur F12 pour faire un boot pxe et apres l'install, ca reboote sur le disque local comme ça

Oui en effet, seulement avec les machines que je dispose pour mes tests, j'ai pas le choix du F12,  elle boot direct.
 
Si bien que 1 fois sur 2.. je lance une install je vais prendre un café, et qd je revient, il en déjà recommancé une autre !!    
Avec des 3Ghz-1Go de RAM, ca carbure ces machines la !
 
Je vais me prendre la tête avec ça pour l'instant, ca  n'a pas vraiment d'importance

c'est bizarre  de ne pas avoir cette option pour des machines de ce type... tu devrais aller faire un tour dans le bios

Ah bah oui dis donc ! t'as raison.    
J'avais pas vu qu'on pouvait le faire comme ca avec mes Dell. C'est beaucoup plus pratique maintenant  

faut activer le serveur dhcp et le stopper des que la machine a boote, c'est le plus facile.
ou meme mieux, ajouter ou supprimer les machines que tu veux booter dans le fichier de conf a la volee...

 
Oui mais bon.. je pense pas qu'on installe des machines tous les jours non plus...    
 
C'est bien de connaitre les 2 solutions au moins.