Journal Live CD vitaminé

Posté par (page perso) .
Tags : aucun
0
13
mai
2006
Âmes sensibles, attention, ce journal est quasi-intégralement recopié de mon blog.

Dans le LUG dont je fais partie (Toulibre [1]), nous organisons régulièrement des rencontres autour du Logiciel Libre dans des lieux qui ne sont pas équipés de postes sous GNU/Linux. Nous dégainons alors évidemment la technologie LiveCD, qui a fait ses preuves depuis longtemps, et nous permet de transformer (devrais-je dire libérer ?) en un clin d'oeil 5 ou 6 postes. Et donc de pouvoir animer nos petites rencontres, et de montrer au public l'environnement GNU/Linux ainsi que les divers Logiciels Libres disponibles.

Pourtant, ce mode de fonctionnement n'était pas tout à fait satisfaisant:
- d'une part, le LiveCD de la Ubuntu, que nous utilisons, n'est pas totalement francisé. Évidemment, nous pouvons le personnaliser, mais il faudra alors faire une copie du CD pour chaque poste, et ce, à chaque modification du LiveCD
- et surtout, les performances du système lancé depuis un LiveCD laissent clairement à désirer. Le lecteur de CD de beaucoup de machines n'est pas très véloce, et le lancement du système ou d'applications comme Firefox ou OpenOffice.org est vraiment très très long.

Je me suis alors fait la remarque que tous ces postes étaient reliés par un réseau 100 Mbit/s, qui offre des performances (à la fois en terme de débit et en terme de temps d'accès) bien plus intéressant qu'un LiveCD. On a donc eu l'idée de transformer un LiveCD existant en un LiveCD démarrant par le réseau plutôt. (Note: si ça se trouve, quelqu'un avait déjà fait ça ailleurs, mais je n'ai pas trouvé).

Le week-end dernier, avec un collègue de Toulibre, nous nous sommes donc lancés dans la modification de la phase de démarrage du LiveCD d'Ubuntu. Désormais, il suffit d'une ISO de 7 Mo, ou bien de quelques fichiers sur une clé USB pour démarrer une machine. Dès le démarrage, elle va monter via NFS une copie du CD-ROM Live contenant l'ensemble du système (se trouvant sur une autre bécane, le serveur). Tous les accès se feront donc ensuite par NFS. Sur le serveur, la copie se trouve sur le disque dur (donc déjà beaucoup plus rapide que sur CD-ROM), et même une grande partie de ces données vont rapidement se retrouver cachées dans la mémoire du serveur, pour une vitesse encore accrue. La différence est vraiment nette: pour peu qu'on dispose d'un réseau rapide et d'un serveur pas trop pourri, on aurait presque l'impression, sur le poste client, d'utiliser un système réellement installé sur le disque.

En plus des performances, ce mécanisme fait que les données du LiveCD ne sont qu'à un seul endroit. Si l'on veut le personnaliser, pour par exemple, ajouter des logiciels ou un meilleur support du français, il suffit de le faire sur le disque du serveur.

Nous avons documenté toute notre démarche dans un petit HOWTO [2]. Il explique toutes les modifications que nous avons apporté, comment créer une clé USB ou une ISO qui va permettre de démarrer ce système. Ceux qui ont la flemme peuvent directement télécharger l'ISO [3]. Ceux qui veulent démarrer via une clé USB devront lire la section correspondante de la doc.

N'hésitez pas à faire part dans les commentaires de vos essais, suggestions et remarques par rapport à la documentation ou au bouzin lui-même.

[1] http://www.toulibre.org
[2] http://thomas.enix.org/pub/livecd/HOWTO-Ubuntu-Live-Speedup
[3] http://thomas.enix.org/pub/livecd/livecdboot.iso
  • # boot pxe

    Posté par . Évalué à 5.

    Si j'ai bien compris, ta version modifiée n'utilise qu'un noyau et initrd. Il est donc possible de pouvoir booter par pxe.

    Il suffit alors d'installer un serveur dhcp avec les options qui vont bien ainsi qu'un tftpd, et c'est possible de se passer de clé usb :)
    (enfin seulement sur les pc capables de booter par le réseau, mais ça devient une règle générale non ?)

    Je voudrais modifier de la même manière le livecd Gparted, mais je n'ai aucune idée du système surlequel il repose ..(et l'auteur ne répond pas aux mails). Si quelqu'un a une piste ..
    • [^] # Re: boot pxe

      Posté par (page perso) . Évalué à 5.

      Absolument, c'est tout à fait possible. De la même façon que pour l'instant, le chemin NFS doit être passé sur la ligne de paramètres du noyau, alors qu'on pourrait le passer par DHCP.

      Mais il y a une raison derrière tout cela: dans les lieux où nous (Toulibre) allons, nous ne maitrisons pas le serveur DHCP. C'est dans l'infrastructure réseau du lieu où nous sommes, et nous ne pouvons pas y toucher.

      De plus, PXE c'est sympathique, mais ça demande de connaître avec précision le modèle des cartes réseau (si je me souviens bien). Or, par nature, le but d'un LiveCD c'est d'être utilisable sur n'importe quelle bécane, peu importe sa carte réseau, graphique, son ou autre.
      • [^] # Re: boot pxe

        Posté par . Évalué à 4.

        De plus, PXE c'est sympathique, mais ça demande de connaître avec précision le modèle des cartes réseau (si je me souviens bien).

        Non, et heureusement :)

        Lorsqu'une carte réseau supporte pxe et qu'on demande au bios de booter sur le réseau, la carte réseau fera une requête bootp, le serveur lui filera l'adresse du serveur tftp, téléchargera le noyau et l'initrd, et bootera desus. Rien de spécifique à la carte réseau.

        En revanche, si une carte réseau n'est pas capable de booter par pxe (ce qui est rare sur les pc récents), là il faudra utiliser des outils type etherboot etc. qui nécessite l'utilisation d'une disquette / clé usb etc. spécifique à la carte réseau, qui contiendra un programme capable de booter par pxe.
        • [^] # Re: boot pxe

          Posté par (page perso) . Évalué à 3.

          Exact, j'ai confondu PXE et etherboot, autant pour moi. Effectivement, on peut faire comme tu le dis. Ça serait rigolo de tester.
    • [^] # Re: boot pxe

      Posté par . Évalué à 1.

      ClusterKnoppix fait ça. On boote sur une machine avec le livecd, puis avec un petit utilitaire inclu en quelques clics, ca fait DHCP, TFTP, NFS et tout ce qu'il faut.

      Il suffit de démarrer une machine du réseau par PXE et on se retrouve dans la knoppix.

      Peut-être à regarder pour s'inspirer de leurs scripts....
      • [^] # Re: boot pxe

        Posté par . Évalué à 2.

        ma difficulté avec Gparted, c'est plutôt de savoir quel est le noyau utilisé ainsi que les sources, histoire de pouvoir rajouter sans se casser la tête le support nfsroot et réseau dans l'initrd.
        La partie dhcp, tftp et nfs ne pose pas trop de pb en fait.
  • # Wouha !

    Posté par . Évalué à 7.

    C'est une super idee !
    Ca va revolutionner les install party...

    Surtout que si le gaillard est content de la demo il peut lancer espresso avec Dapper et installer son systeme du meme coup (a tester mais ca peut etre carrement genial)

    - Oh c'est pas mal linux
    - La rien n'est installe sur votre machine, hein c'est juste pour voir si votre materiel est bien reconnu...
    - et c'est quoi ce petit truc en haut a droite
    - votre carte wifi
    - elle est la ? reconnue
    - il me semble bien...
    - Dites on peut installer votre linux alors?
    - ok, (double clic, personnalisation, repartitionnement) voila on redemarre votre machine, (copie via le reseau... ~ 30 sec)
    Ayé...
    - deja ?
    - oui oui rebootons...

    C'est une tres tres bonne idee... Je sens que tu vas faire des heureux... http://doc.ubuntu-fr.org/edubuntu
    ;-)
  • # Question

    Posté par . Évalué à 6.

    Ca tient bien la montée en charge ? genre si t'as 15 marchines qui démarrent en même temps, le serveur souffre pas trop ?
    • [^] # Re: Question

      Posté par (page perso) . Évalué à 3.

      Aucune idée, on n'a pas encore pu faire de test en charge. Mercredi, on va tester avec 5 machines clientes, on verra bien ce que ça donne. C'est clair que NFS n'est pas très scalable, donc on pourra pas faire ça avec des dizaines de clients. Mais je pense que jusqu'à 10 clients ça devrait aller.

      Le top, c'est si le serveur a environ 1G de RAM. Alors le contenu du LiveCD va se retrouver quasi-intégralement dans le cache et il ne touchera même plus au disque.
    • [^] # Re: Question

      Posté par (page perso) . Évalué à 2.

      Actuellement, on ne peut pas faire du load balancing entre plusieurs serveurs NFS car l'adresse IP du serveur NFS est indiqué "presque" en dur dans les options de boot dans le fichier de config de grub menu.lst:

      http://thomas.enix.org/pub/livecd/menu.lst
      title UBUNTU Live over the Network
      root (hd0,0)
      kernel /vmlinuz root=/dev/ram0 nfs=192.168.2.1:/livecd/ quiet --
      initrd /initrd.gz
      savedefault
      boot


      On peut toujours le changer à la main lorsque la machine démarre pour répartir la charge sur plusieurs serveurs NFS. Mais ce n'est pas pratique car ce n'est pas automatique.

      En utilisant OpenSLP (voir mon commentaire plus bas), la machine pourrait trouver toute seule son serveur NFS, et aussi pourquoi pas faire automatiquement du load balancing.

      C'est ce qui est fait dans le projet MILLE-XTERM: les terminaux X trouvent leur serveur de boot par OpenSLP et choisissent le moins chargé par OpenSLP. Si vous voulez voir comment, vous pouvez jeter un coup d'oeil aux fichiers XTERM/trunk/mille-xterm-bootserver/OpenSLP_NFS_ROOT/ sur le repository subversion du projet. OpenSLP y est disponible en version statique (utile pour le initrd).
  • # La même avec PXE.

    Posté par . Évalué à 7.

    Je fait pareil :)

    Un DHCP, qui autorise du PXE, avec un serveur tftp, sur lequel on met les noyaux+initrd modifiés si besoin, qui seront lancés par un PXEgrub. Ca permet d'avoir pas mal d'outils à dispo simplement par le réseau (avec une carte qui supporte), par exemple Memtest86+, Knoppix DVD, Installations de distros (Debian) ...

    Si ça intéresse, je peux publier.
  • # Comment trouver le serveur NFS

    Posté par (page perso) . Évalué à 5.

    http://thomas.enix.org/pub/livecd/HOWTO-Ubuntu-Live-Speedup
    For example, if the copy of the LiveCD is available on 192.168.2.1:/livecd/, you'll have to add "nfs=192.168.2.1:/livecd/" to your kernel command-line.


    Mais si on n'a pas le contrôle sur le serveur DHCP, on ne sait pas quelle va être l'adresse IP du serveur NFS. On peut résoudre ce problème en utilisant OpenSLP.

    Qu'est-ce que SLP?

    http://openslp.org/
    Service Location Protocol is an IETF standards track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.


    Sur le serveur NFS, on enregistre le service avec la commande:

    slptool register service:nfs-ubuntu-livecd://192.168.2.3 "Mon serveur NFS"


    Ensuite, dans le initrd du terminal X, pour trouver l'adresse IP du serveur NFS, on utilise:

    slptool findsrvs service:nfs-ubuntu-livecd


    Cela impose de mettre les programmes d'OpenSLP dans l'archive initrd mais cela permet de ne pas avoir à configurer la ligne de commande de Grub sur chaque terminal pour indiquer l'adresse IP du serveur NFS.
    • [^] # Re: Comment trouver le serveur NFS

      Posté par (page perso) . Évalué à 3.

      Bonne idée, on va essayer d'ajouter ça!
    • [^] # Re: Comment trouver le serveur NFS

      Posté par (page perso) . Évalué à 2.

      En fait, il est sans doute plus simple d'ajouter dans le fichier de configuration /etc/slp.reg le paragraphe suivant:

      #Register the NFS LiveCD
      service:nfs-ubuntu-livecd://192.168.0.1,en,65535
      description=NFS Server for LiveCD Ubuntu
      authors=toulibre


      Cela évite de taper à chaque fois la commande «slptool register».

      Ensuite, un petit coup de sed pour trouver l'adress IP:

      $ slptool findsrvs service:nfs-ubuntu-livecd|sed 's/^.*\/\/\(.*\),.*$/\1/g'
      192.168.0.1
      $


      On peut imaginer mettre plusieurs entrée de boot sur le LiveCD pour chaque distribution qu'on veut démarrer, chacun avec une option de boot différente: nfs-ubuntu-livecd, nfs-kubuntu-livecd, ...

      Le initrd chercherait la ressource correspondante.

Suivre le flux des commentaires

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