Journal Instalaltion remote/automatic d'un parc de machines

Posté par  (site web personnel) .
Étiquettes : aucune
0
18
juil.
2008
Je suis en train de regarder comment installer un parc de machines Linux de la manière la plus simple, rapide, et maintenable (patches, modification des fichiers de config). L'idée serait de faire booter une machine toute neuve sur un Live CD qui va chercher les informations sur le réseau pour configurer la machine.

Voici l'état de mes recherches. Y'a t'il des personnes qui ont déjà montés de tels infrastructures et qui pourraient nous faire partager leur retour d'expérience ?

Ah oui, le parc est hétérogène, il faut donc pouvoir gérer plusieurs configurations avec un minimum de redondance entre les configs. De plus, la distrib installé sera Ubuntu.

Jusqu'ici j'ai repéré plusieurs trucs:

FAI - Fully Automatic Installation : un live CD qui va chercher quelques scripts de configuration sur le réseau et les exécuter à la suite. Pas mal mais je voudrais pouvoir combiner ça avec un système plus souple au niveau de la gestion de la configuration qui pourrait être...

cfengine ! : un moteur pour gérer la configuration en distant de chaque machine et de vérifier certaines propriétés. Mais difficile à dire si c'est un bon outil, car il y a pléthore de produits équivalents.

Il ne reste que la gestion des mises-à-jour, par exemple UMC ou d'autres (il existe un produit chez canonical avec une licence un peu restrictive mais je n'arrive pas à retrouver le lien).
  • # Précision

    Posté par  (site web personnel) . Évalué à 1.

    J'ai oublié de préciser que le parc de machines est principalement desktop (les utilitaires prévus pour faire de l'installation distribuée sur des grilles ne sont pas intéressantes dans ce cas).
  • # Puppet

    Posté par  (site web personnel) . Évalué à 3.

    Puppet est parfait pour cela.

    http://la-rache.com

  • # Il y a peut-être une réponse par là

    Posté par  . Évalué à 10.

    <mode="comité contre les questions de forum déguisées en journaux">http://linuxfr.org/forums/ </mode>

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Il y a peut-être une réponse par là

      Posté par  (site web personnel) . Évalué à 0.

      Je ne lis pas les forums et je suis intéressé par les réponses à cette question ce qui fait que je vote pour son maintient en journal.

      Et na.
    • [^] # Re: Il y a peut-être une réponse par là

      Posté par  . Évalué à 0.

      Joli, quelle est cette syntaxe ?
    • [^] # Re: Il y a peut-être une réponse par là

      Posté par  . Évalué à 3.

      En même temps, si je jouais l'avocat du diable, j'aurais tendance à dire que j'ai vu plus pratique comme forum... ne serait-ce que pour faire des recherches...

      ... peut-être que c'est juste que je ne sais pas comment faire, mais autant j'apprécie la légèreté des pages du site, autant faire une recherche sur un sous-forum précis, ou juste sur les journaux, et bien, je n'y arrive jamais - tout se retrouve toujours pêle-mêle...

      Alors, ça ne justifie pas en soit l'utilisation des journaux comme d'un forum... mais ça participe à l'expliquer : le forum n'est pas agréable à utiliser, les dépêches sont modérées... donc les gens, aussi abusif que certains trouvent ça, vont au plus direct, au plus consulté (perso, je ne jette pour ainsi dire jamais un oeil au forum) - les journaux...

      Et ça ne me dérange pas du tout s'il s'agit de lancer un débat du genre "et vous, qu'est-ce que vous utilisez pour ..."...

      On va me reprocher de dire que c'était mieux à-vents, mais les journaux techniques (qui sont censés se retrouver dans les astuces) et les journaux invitant à la discussion sur des choix de technologies (qui sont censés être des questions sur le forum), ils me manquent en tant que journaux, où les retours d'expérience, plus nombreux, rendaient le panel de commentaires plus intéressant... et, du coup, je ne suis pas convaincu de la justesse d'exiger qu'ils soient cantonnés au forum, plus adapté à des questions rapides du genre "v'là mon xorg.conf, mon Xorg.0.log, ça marche pô, j'fais kôa ?/! (kôôôôa... kôôôôa)"...
  • # Automatisation d'installation

    Posté par  . Évalué à 4.

    Pour automatiser l'installation, le plus simple est d'avoir un mirroir local et d'utiliser le preseeding de debian-installer.
    Voici le lien vers la doc pour Ubuntu 8.04: https://help.ubuntu.com/8.04/installation-guide/i386/appendix-preseed.html

    Avec ça tu peux avoir un CD minimal (8Mo dans mon cas) qui va télécharger un fichier de config (.seed) depuis un serveur web lequel contient tous les paquets et les réponses à donner à l'installeur de sorte qu'il n'en pose plus aucune durant l'installation.
    Tu peux aussi utiliser l'option preseed/late_command pour démarrer un script en fin d'installation qui va modifier tes fichiers de configs ou faire tout changement que tu ne peux pas faire par preseeding.

    Pour ensuite gérer la config de tes machines sans devoir les réinstaller à chaque fois, tu peux regarder du côté de puppet qui te permettra de gérer les mises à jour automatiques des machines, la liste des paquets installés, de réstaurer des fichiers de configurations qui auraient été modifiés, ...
    • [^] # Re: Automatisation d'installation

      Posté par  . Évalué à 2.

      Sinon, je crois qu'il existe aussi pour cette distro, mais il y a simple-cdd, qui simplifie quand même bougrement la customisation d'un CD de Debian.

      On peut bien sûr y charger du fichier de preseed (ça permet d'ailleurs de squeezer toutes les questions de l'installation que l'on juge inutiles), mais aussi, grâce à l'udeb de simple-cdd, créer des profils équivalent à des tâches de tasksel, mais plus simples à créer (pas de meta-paquets : on fait une liste de ce que l'on veut, comme on le veut, dans les fichiers du profil, et simple-cdd s'occupe de faire venir les dépendances, et de tout installer comme il faut)...

      Les deux seuls trucs qui me limitent avec lui (faut dire qu'il est assez jeune), ce sont l'impossibilité d'ajouter des paquets venant d'un miroir où ils sont dans autre chose que main/contrib/non-free (j'imagine que ça a été adapté, pour les distros en utilisant plus, de base), et l'installation, si on le veut (et sur un desktop, en général, je le veux), des paquets recommandés, et pas simplement des dépendances.

      Ca ne résout pas le problème du déploiement automatique, mais pour des petites infrastructures (genre chez moi : deux serveurs physiques seulement, avec plein de conteneurs - si l'un des deux tombait en rade, il y aurait de toute façon une chance sur deux pour que le serveur FAI soit emporté avec lui : en ce cas, disposer d'un media de réinstallation déjà pas mal configuré, c'est très pratique), ou pour une réinstallation alors que le réseau est en panne, c'est une solution complémentaire à du backup et à du déploiement centralisé.
    • [^] # Re: Automatisation d'installation

      Posté par  . Évalué à 2.

      Ah oui, et je plusse puppet de tout mon coeur... c'est bougrement plus facile de rentrer dedans que dans cfengine.
  • # m23

    Posté par  (site web personnel) . Évalué à -3.

  • # Notre config

    Posté par  . Évalué à 4.

    - PXE :
    le boot PXE activé sur toutes les machines.

    - FAI :
    Serveur avec FAI et une config pour chaque type de machine
    Le plus long c'est la config de FAI pour un nouveau matos.

    - CFENGINE :
    cfengine permet d'affiner les configs ou les modifs plus fréquentes
    Cela permet aussi l'installation de nouveaux paquets.
    cfengine est lancé au boot des machines et chaque nuit.
    Si toutes les personnes veulent un nouveau paquet rapidement : reboot.
    Si elles peuvent attendre 24h, ça sera fait la nuit.
    • [^] # Re: Notre config

      Posté par  (site web personnel) . Évalué à 3.

      Pareil, avec en plus :

      - un /usr/local rsyncé depuis un "serveur" (celui qui héberge fai, le cfengine et l'image d'install)

      - cssh, pour le pilotage rapide d'un groupe de machines (cluster SSH).

      FAI, c'est long a préparer, mais c'est bon à déguster...

      Proverbe Alien : Sauvez la terre ? Mangez des humains !

  • # Boot

    Posté par  . Évalué à 3.

    Personne n'a pensé au boot sur PXE/LAN.

    En production sur des architectures distribuées, je pense principalement au salle de cours des universités et aux très gros systèmes du genre grappes ou clusters, c'est ce moyen qui est utilisé de façon courante.

    En gros, la machine boot sur LAN via PXE, charge une image réseau et opère son upgrade et/ou installation distante.

    Plus besoin de CD, DVD et autre support physique. Il faudra juste un serveur DHCP+TFTP+FTP/HTTP.

    Networkally yours.
    • [^] # Re: Boot

      Posté par  . Évalué à 1.

      Quelques remarques :

      * FAI utilise PXE pour booter et cfengine pour configurer (entre
      autres)

      * FAI est un "lourd" à mettre en oeuvre, c'est un investissement
      qui vaut le coup si on a beaucoup de machines derrière, sinon
      c'est plus rapide d'utiliser un CD ou une clef USB pour du
      temporaire ou pour une install

      * cfengine permet de relancer le client depuis le serveur pour
      modifer la config (pas besoin d'attendre ni un reboot ni le
      lendemain )

      Bon WE
  • # PXE + kickstart + yum + repo perso

    Posté par  . Évalué à 2.

    - PXE, pour que les machines sachent demarrer sur une image reseau
    - Un peu de config de to serveur TFTP pour dire "ah non, cette machine est deja installée, elle doit booter sur son disque local.
    - kickstart portant l'adresse MAC de la macine pour definir les parametres specifiques si besoin (ou par groupes)
    - yum pour automatiser l'installation des updates
    - un repo perso avec un meta-package "perso-admin" auquel tu ajoutes des dependances pour tes modifs perso. A coup de post-install, ca marche pas mal.

    Et pour garder la main, generer une clef ssh qui a access a un user lui meme dans le groupe wheel ou equivalent pour pouvoir lancer des commandes du style
    for mach in mach1 mach2 mach3
    do
    echo processing $mach
    ssh mach route add -net 10.2.3.0/24 192.168.1.5
    echo finished with $mach
    done

    sur toutes test machines
  • # en test chez nous

    Posté par  . Évalué à 2.

    Sur un parc de 90 machines :
    _ clonezilla pour l'installation initiale de l'image
    _ puppet pour la gestion ensuite
  • # Diskless Remote Boot in Linux

    Posté par  (site web personnel) . Évalué à 2.

    Jette un oeil à DRBL, Diskless Remote Boot in Linux
    http://drbl.sourceforge.net/

    DRBL is an open source solution to managing the deployment of the GNU/Linux operating system across many clients. Imagine the time required to install GNU/Linux on 40, 30, or even 10 client machines individually! DRBL allows for the configuration all of your client computers by installing just one server machine.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.