✎ developpement:productions:sidus[CBP]

✎ developpement:productions:sidus
Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== SIDUS  ======

{{ :developpement:productions:sidus.png?200 |}}

<note tip>SIDUS à l'honneur au kiosque numérique de [[http://www.linuxjournal.com/content/november-2013-issue-linux-journal-system-administration|Linux Journal en Novembre 2013]]. Merci encore à Marianne Corvellec pour son aide précieuse dans la promotion de SIDUS (collaboration pour cet article & présentation de [[http://conference.scipy.org/scipy2013/presentation_detail.php?id=199|Scipy 2013]])</note>


<note warning>Tous les éléments présents dans cette documentation, les morceaux de code, etc entrent dans le cadre de la licence [[http://www.cecill.info/index.fr.html|CeCILL]]. Il est donc nécessaire de respecter les 4 libertés fondamentales des logiciels libres pour exploiter SIDUS dans sa propre infrastructure. Si vous comptez utiliser SIDUS dans votre infrastructure, faites le savoir à son [[emmanuel.quemener@ens-lyon.fr|auteur]], Centre Blaise Pascal ou citez le !</note>

<note tip>Première [[https://conference.scipy.org/scipy2013/presentation_detail.php?id=199|présentation]] avec [[http://www.youtube.com/watch?v=J5myH0y_bks|vidéo]] de **SIDUS** à [[http://conference.scipy.org/scipy2013|Scipy 2013]]</note>

**SIDUS** est l'acronyme de //Single Instance Distributing Universal System// et se propose de simplifier à l'extrême l'administration de machines. 

Son [[http://fr.wiktionary.org/wiki/sidus|origine latine]] //d'ensemble de corps stellaires// est une allégorie : nous vous laissons trouver celle qui vous convient le mieux =).

**SIDUS** a deux principales propriétés : 
  * **l'unicité de configuration** : deux machines démarrant sous Sidus ont exactement le même système d'exploitation
  * **l'usage des ressources locales** : les processeurs et mémoire vive sollicités sont ceux de la machine locale

**SIDUS** n'est donc :
  * **ni LTSP** pour //Linux Terminal Server Project// : LTSP propose une gestion simplifiée de terminaux légers en offrant un accès X11 ou RDP à un serveur : ce dernier supporte ainsi toute la charge de traitement. A contrario, SIDUS exploite entièrement (ou à discrétion de l'utilisateur) toute la machine qui s'y raccroche. Seul le stockage du système d'exploitation est déporté sur des machines tierces.
  * **ni FAI** pour //Fully Automatic Installation// : FAI ou Kickstart proposent une installation complète simplifiée permettant de limiter voire d'éliminer toute action de l'administrateur. A contrario, SIDUS propose un système unique dans un arbre intégrant à la fois le système de base et toutes les applications installées manuellement.
  * **ni un LiveCD** sur réseau : un LiveCD démarre un système minimaliste, nécessairement figé. Il est toujours possible de créer son propre LiveCD mais c'est une opération assez lourde. Avec SIDUS, il est possible d'installer à la volée sur tous ses clients un logiciel instantanément, de le reconfigurer. 

====== CQQCOQP ======

[[http://fr.wikipedia.org/wiki/QQOQCCP|CQQCOQP]] est une démarche analytique simple vous permettant, simplement en lisant les réponses aux questions élémentaires //Pourquoi ? Quoi ? Qui ? Où ? Quand ? Combien ? et Comment ?// les tenants et les aboutissants de SIDUS.
===== Pourquoi ? =====

Le temps d'administration système des équipements informatiques (noeud de calcul, poste personnel ou station de travail, machine virtuelle d'expérimentation) augmente avec leur nombre et leur diversité. Ainsi, tous ces matériels partagent essentiellement les mêmes fichiers, mais chacun sur son propre disque. Comment limiter le temps d'installation et d'administration des machines tout en conservant la flexibilité liée à leur destination ?

C'est le défi relevé par SIDUS (pour Single Instance Distributing Universal System), développée au Centre Blaise Pascal à l'origine essentiellement pour simplifier la tâche de l'unique administrateur système face à la gestion de centaines de machines de toutes natures pour toutes destinations (plateaux techniques multi-noeuds, multi-coeurs, GPU, etc).

===== Quoi ? =====

Une approche permettant le démarrage en réseau et l'offre d'un système parfaitement générique pour toutes les machines.

===== Quand ? =====

La première version de Sidus date de février 2010, elle était à l'origine sur Debian Etch. Elle a suivi toutes les évolutions de la distribution Debian, socle essentiel (voire exclusif) du Centre Blaise Pascal.

Début 2013, SIDUS sert près de 90 noeuds permanents de cluster au CBP (jusqu'à 120 simultanés en fonction des prêts), des serveurs de GPGPU, des stations de travail multi-coeurs et des postes //COMOD// (pour //Compute On My Own Device//).

===== Pour Qui ? =====

SIDUS s'adresse à tous ceux qui veulent se simplifier la tâche et qui :
  * disposent de groupes de machines ayant toute la même destination :
    * des noeuds de cluster de calcul
    * des machines de salle libre service
    * des machines virtuelles dans le cadre de formations
  * veulent analyser des équipements sans jamais toucher au système

===== Où ? =====

Le Centre Blaise Pascal, hôtel à projets de l'ENS-Lyon dans le domaine du calcul et de l'informatique scientifiques, utilise SIDUS pour tous ses équipements dont l'uniformité doit être conservée le plus possible : un simple redémarrage doit suffire à replacer le système dans son état d'origine.

Le Pôle Scientifique de Modélisation Numérique (PSMN), centre de calcul de l'ENS-Lyon, utilise maintenant SIDUS sur une centaine de noeuds et prépare sa généralisation pour la mise en place de Equip@Meso (près de 200 noeuds supplémentaires).

Le laboratoire de Chimie utilise "COMOD" pour quelques postes de travail "à la demande".

Les laboratoires de l'IGFL, du LBMC et du LJC utilisent "COMOD" : un cluster de 5 stations de travail gavées de GPU au LBMC, des stations graphiques à l'IGFL et au LJC.

L'université Joseph Fourier, dans le cadre de ses écoles thématiques sur le calcul scientifique, utilise depuis 2011 SIDUS pour l'infrastructure de travaux pratiques des auditeurs.

===== Combien ? ===== 

De 8 clients légers Neoware gonflés en CPU et mémoire et détournés début 2010 de leur vocation originelle, nous approchons les 120 machines au CBP utilisant ce système. 

De quelques machines déployées à des fins expérimentales, le Pôle Scientifique de Modélisation Numérique utilise également SIDUS en production pour 400 noeuds. L'équipement informatique Equip@Meso d'environ 200 noeuds à lui tout seul, utilise également SIDUS comme socle.

Quelques chercheurs du laboratoire de chimie utilisent SIDUS via COMOD : la disponibilité en offrant la possibilité de déployer une machine complète et opérationnelle sur son poste de travail en quelques secondes.

Lors des école thématiques des Houches sur le calcul scientifique, SIDUS était servi à près d'une cinquantaine de machines simultanément.

Quant au prix du logiciel (question posé au dernier Scipy 2013), tous les composants qu'il utilise étant Open Source, SIDUS l'est aussi, ainsi que toutes les documentations associées ! SIDUS est donc sous licence CeCILL.

Si vous utilisez SIDUS, informez l'[[emmanuel.quemener@ens-lyon.fr|auteur]] et faites en la promotion !

Si vous voulez déployer SIDUS sur vos installations et vous faire aider, vous pouvez contacter l'[[emmanuel.quemener@ens-lyon.fr|auteur]].
===== Comment ? =====

SIDUS se base sur une majorité de composants simples et éprouvés, disponible sur la majorité des distributions GNU/Linux.

Nous allons maintenant détailler comment installer le sien !

====== Installation ======

===== Préparation du système =====
Nous devons préparer un peu notre système pour accueillir SIDUS. Pour cela, nous avons la main sur plusieurs services pour déployer nos clients : serveurs DHCP, TFTP, NFS. Vous entretenez de très bonnes relations avec votre service IT ou vous êtes assez libres pour accéder sans contraintes aux serveurs Ldap et DNS bien définis :

  * le service DHCP fournit à notre client une adresse IP mais diffuse deux informations complémentaires : l'adresse du serveur TFTP via la variable ''next-server'' et le nom du binaire PXE, souvent nommé ''pxelinux.0''.
  * le service TFTP entre alors en scène. Il offre par TFTP tout le nécessaire permettant le démarrage du système : le binaire ''pxelinux.0'', le noyau et le démarrage du système du client. Si nous avons besoin d'offrir des paramètres à tel ou tel client, nous contruisons un document spécifique dont le nom sera contruit à partir de son adresse MAC (préfixé de 01 et dont les : sont remplacés par des -).
  * le serveur NFS s'invite alors dans la boucle : il va offrir la racine du système par son protocole (donc NFSroot). C'est donc dans cette racine, par exemple ''/srv/nfsroot/sidus'' que nous allons installer notre système client.

Sur nos configurations nous utilisons respectivement **isc-dhcp-server**, **tftpd-hpa** et **nfs-kernel-server** pour les serveurs DHCP, TFTP et NFS.

Regardons plus en détail la configuration des différents services que nous venons de citer :

<note important>Dans [[http://www.linuxjournal.com/content/november-2013-issue-linux-journal-system-administration|l'article Linux Journal]], le ''next-server'' est défini à l'IP ''172.16.20.13'', c'est préférable de l'avoir dans le même sous-réseau : 10.13.20.13 est un choix plus judicieux.</note>
Pour le serveur DHCP, dans le fichier de configuration ''/etc/dhcp/dhcpd.conf'' :<code>
next-server 10.13.20.13;
filename "pxelinux.0";
allow booting;</code>

Pour le serveur TFTP, dans le dossier ''/srv/tftp'', nous avons 3 fichiers et un dossier (pxelinux.cfg). Le fichier ''pxelinux.0'' vient le paquet **syslinux-common**.
<code>
./pxelinux.0 
./vmlinuz-Sidus
./initrd.img-Sidus
./pxelinux.cfg
</code>

Dans le dossier pxelinux.cfg, nous avons le fichier "default". Voici un exemple de fichier de démarrage précisant au client tout ce qu'il faut pour démarrer. Il comprend deux entrées, **tmpfs** et **iscsi**. Nous reviendrons plus loin sur cette seconde entrée **iscsi** :
  * le noyau ''vmlinuz-Sidus''
  * le système ''initrd.img-Sidus''
  * le serveur NFSroot ''10.13.20.13'' avec le point de montage ''/srv/nfsroot/sidus''

<code>
DEFAULT tmpfs

LABEL tmpfs
KERNEL vmlinuz-Sidus
APPEND console=tty1 root=/dev/nfs initrd=initrd.img-Sidus nfsroot=10.13.20.13:/srv/nfsroot/sidus,rsize=8192,wsize=8192,tcp ip=dhcp aufs=tmpfs

LABEL iscsi
KERNEL vmlinuz-Sidus
APPEND console=tty1 root=/dev/nfs initrd=initrd.img-Sidus nfsroot=10.13.20.13:/srv/nfsroot/sidus,rsize=8192,wsize=8192,tcp ip=dhcp aufs=iscsi ISCSI_TARGET_IP=10.13.20.13 ISCSI_INITIATOR=iqn.2013-04.zone.sidus.target:default root=LABEL=ISCSI 
</code>

Pour le serveur NFS, sa configuration prend un ligne dans le fichier /etc/exports. Ici, nous ouvrons un accès en lecture seule pour les machines dont l'IP est comprise entre 10.13.20.128 et 10.13.20.254 :<code>
/srv/nfsroot/sidus 10.13.20.128/255.255.255.0(ro,no_subtree_check,async,no_root_squash)
</code>

Une fois ces 3 services DHCP, TFTP et NFS configurés, nous pouvons installer un Sidus complet.

Attention cependant ! Il faudra également prévoir une racine contenant les comptes des utilisateurs (par NFS version 4) et un processus permettant leur identification/authentification (par Ldap ou Kerberos). Nous avons ainsi déployé Sidus dans des environnements où ces services étaient fournis par des serveurs tierces tout comme des environnements complètement autonomes. L'installation d'un serveur OpenLDAP avec SSL ou d'un serveur Kerberos sortant de ce sujet, nous nous contenterons de préciser les fichiers de configurations clients qu'il nous conviendra d'adapter à notre infrastructure de site : ici, du Ldap pour identification/authentification et du NFS version 4 pour les dossiers utilisateurs.

===== Deboostrap =====

Debootstrap permet l'installation d'un système dans une racine. Il exige plusieurs paramètres comme la racine d'installation, l'architecture matérielle, la distribution et l'archive FTP ou HTTP Debian à solliciter pour le téléchargement.

Warning : là commence la "spécialisation" de notre installation, à l'origine construite autour d'une distribution Debian. Cet outil est familier de toutes les distributions Debian-like : il sera donc disponible chez les dérivées du système à la spirale (à commencer par Ubuntu). Il sera cependant assez facile de réaliser cela sur les Redhat-like, Fedora intégrant par exemple un clone, [[http://people.redhat.com/~rjones/supermin/|Febootstrap]], mais que nous n'avons pas testé.

Debootstrap accepte aussi en entrée une liste d'archives (vous savez que Debian est très tatillon sur les licences en séparant les archives en main, contrib et non-free), une liste de paquets à inclure et une liste de paquets à exclure. Nous aurions été ravi de pouvoir, ici, préciser la liste complète des paquets à inclure ou exclure, mais, malheureusement, cette approche est une voie sans issue : nous installerons donc, dès cette commande ''debootstrap'', un ensemble d'outils qu'il nous semble indispensable d'inclure dès le début (par exemple le noyau, des firmwares pour un support étendu de tous les matériels et un ensemble d'outils d'audit).

Nous avons par commodité défini des variables d'environnement correspondant à la racine de notre système ''$SIDUS'' et une commande permettant l'exécution d'une commande par ''chroot'' avec une option particulière d'installation de paquet. La variable ''$MyInclude'' intègre la liste des paquets souhaités (séparés d'une virgule) et ''$MyExclude'' la liste des paquets rejetés dont :
<code>
export SIDUS=/srv/nfsroot/sidus
alias sidus="DEBIAN_FRONTEND=noninteractive chroot ${SIDUS} $@"
</code>

Nous avons définis les ''$MyInclude'' et ''$MyExclude'' suivants pour une architecture 64 bits AMD64 :
<code>
export MyInclude="adduser,apt,apt-utils,aptitude,aptitude-common,aspell,aspell-en,aufs-tools,bsdmainutils,btrfs-tools,busybox,ca-certificates,clusterssh,console-setup,cpio,cron,cups-pdf,debian-archive-keyring,dmidecode,dselect,emacs,environment-modules,ethtool,firmware-bnx2,firmware-linux,firmware-linux-nonfree,gnupg,gpgv,groff-base,htop,hwinfo,hwloc,iftop,ifupdown,info,initramfs-tools,install-info,iotop,iperf,ipmitool,iproute,iptables,iputils-ping,isc-dhcp-client,isc-dhcp-common,kmod,ldap-utils,less,libapt-inst1.5,libapt-pkg4.12,libboost-iostreams1.49.0,libcwidget3,libept1.4.12,libgcrypt11,libgdbm3,libgnutls26,libgpg-error0,libidn11,libkmod2,libncursesw5,libnet-ldap-perl,libnewt0.52,libnfnetlink0,libnss-ldap,libp11-kit0,libpam-ldap,libpipeline1,libpopt0,libprocps0,libreadline6,libsigc++-2.0-0c2a,libsqlite3-0,libssl1.0.0,libstdc++6,libtasn1-3,libudev0,libusb-0.1-4,libxapian22,linux-headers-3.2.0-4-amd64,linux-image-3.2.0-4-amd64,locales,logrotate,lsof,man-db,manpages,mbw,mtr,mutt,nano,net-tools,netbase,netcat-traditional,nfs-common,nscd,ntpdate,open-iscsi,openssh-server,pciutils,procps,python-ldap,readline-common,rsyslog,screen,scsitools,sdparm,ssh,ssmtp,sudo,tasksel,tasksel-data,tmux,traceroute,tshark,udev,usbutils,vim,wget,whiptail,xinit,python-html2text"

export MyExclude="nano,exim,mysql-server,mysql-server-5.5,mysql-server-core-5.5,network-manager,apache2,apache2-mpm-worker,apache2-utils,apache2.2-bin,apache2.2-common,libapache2-mod-dnssd,libapache2-mod-php5,r-cran-fecofin,libmpich1.0gf,gerris,gspiceui,qucs,ktimetrace,kseg,ghdl,earth3d,libopenigtlink1,qtdmm,scilab-overload,gmsh,klogic,g++-doc,openturns-wrapper,xorsa,r-cran-rpvm,labplot,zygrib,libteem1,magnus,libcomplearn-dev,libtorque2,torque-common,torque-server,gridengine-client,gridengine-exec,gridengine-master,gridengine-qmon,gnuplot,gnuplot-nox,rtai,rtai-doc,libhdf5-dev,libhdf5-1.8,libgd2-xpm"
</code>

Dans le ''$MyInclude'', nous avons tous nos outils "de base". Il est IMPERATIF de placer au moins le noyau ''linux-image-3.2.0-4-amd64'' dans cette liste !

Par défaut, la commande suivante installe une version **wheezy** dans **/srv/nfsroot/sidus** pour une architecture **amd64** à partir du miroir Debian **http://ftp.debian.org/debian** :
<code>
debootstrap --arch amd64 --components='main,contrib,non-free' --include=$MyInclude --exclude=$MyExclude wheezy $SIDUS http://ftp.debian.org/debian
</code>

A la suite de cette commande, nous devons prendre quelques précautions :
  * normalement, si le paquet Debian est un service, ce dernier démarre après son installation. Nous devons donc inhiber le lancement de ce service par la définition d'un hook (''/usr/sbin/policy-rc.d'') :
<code bash>
#!/bin/sh
exit 101
</code>
Ou sous forme de commande :
<code>
printf '#!/bin/sh\nexit 101\n' > ${SIDUS}/usr/sbin/policy-rc.d
chmod +x ${SIDUS}/usr/sbin/policy-rc.d
</code>


  * des paquets exigent l'accès à la liste des processus, du système, des périphériques, de la mémoire virtuelle, des pointeurs de périphériques. Nous devons donc "binder" le montage de ces dossiers du système hôte au système SIDUS :<code>
sidus mount -t proc none /proc
sidus mount -t sysfs sys /sys
mount --bind /run/shm ${SIDUS}/run/shm
mount --bind /dev/pts ${SIDUS}/dev/pts
</code>
===== Paquets spécifiques =====

De manière à simplifier l'installation de paquets appartenant à la même famille, Debian a créé de nombreux meta-paquets, préfixés de "science" : **science-chemistry** désigne par exemple tous les paquets de chimie. La commande d'installation de tous paquets scientifiques se fait par une seule commande. Comme nous sommes épris de complétude, nous allons "aussi" rajouter les paquets "suggérés" (attention, l'option ''--install-suggests'' n'est présente qu'à partir de la distribution Wheezy) :
<code>sidus apt-get install --install-suggests -f -m -y --force-yes science-*</code>

Durant l'installation, les phases les plus longues sont le téléchargement des paquets qui représente plusieurs Go (et dépend donc de la connectivité à Internet et aux miroirs officiels) et la configuration initiale de certains paquets (comme Perl et LaTeX).

Dans le meilleur des scénarii, cela prend 45 minutes pour un arbre complet de 32 Go.

===== Purge =====

Malheureusement, cette boulimie d'installation n'est pas sans effet. Des paquets s'installent encore un peu "mal" et une purge de quelques uns, notamment un installeur Matlab, nous hérisse le poil !
<code>sidus apt-get purge -y -f --force-yes matlab-*</code>

===== Environnement local =====

L'environnement local a une importance et, par défaut, rien n'est défini. Le défaut étant l'américain, nous paramétrons :
  * l'environnement local : ${SIDUS}/etc/locale.gen
  * la zone : ${SIDUS}/etc/timezone
  * le clavier : ${SIDUS}/etc/default/keyboard

===== Serveurs tiers NFS et Ldap =====

Les services NFS et Ldap exigent une petite configuration. L'importation des fichiers directement configurés est préférable.

Dans notre cas, nous avons choisi de les mettre tous sur un serveur Web **http://MyServeur.MySite/sidus**. Un ''wget'' permet directement de les récupérer et les placer au bon endroit avec l'option ''-O''. Par exemple, pour le fichier ''nsswitch.conf'':
<code>
wget -O  ${SIDUS}/etc/nsswitch.conf http://MyServeur.MySIte/sidus/nsswitch.conf
</code>

Ainsi, voici les fichiers à télécharger :

  * l'authentification Ldap : 
    * ''${SIDUS}/etc/nsswitch.conf'', 
    * ''${SIDUS}/etc/libpam_ldap.conf'', 
    * ''${SIDUS}/etc/libnss-ldap.conf'', 
    * ''${SIDUS}/etc/ldap/ldap.conf''
  * le montage des dossiers NFS utilisateurs :
    * pour NFSv4 : 
      * ''${SIDUS}/etc/default/nfs-common'', 
      * ''${SIDUS}/etc/default/idmapd.conf'', 
      * ''${SIDUS}/etc/fstab''
    * pour NFSv3 : 
      * ''${SIDUS}/etc/fstab''

===== Séquence de démarrage =====

Comment partager SIDUS sans le dupliquer ? Nous allons nous inspirer de mécanisme utilisé dans certains LiveCD : le montage de la racine du système consiste en la superposition de deux couches, l'une lecture seule (le système NFSroot) et l'autre en lecture/écriture (un TMPFS dans le cas le plus simple). Les deux couches sont liées par la glue AUFS, le projet successeur de UnionFS.

Tout réside dans un seul et unique "hook" au démarrage : rootaufs, placé très tôt dans le démarrage initrd. Son principe repose sur cinq étapes : 
  - création de dossiers temporaires ''/ro'', ''/rw'' et ''/aufs''
  - déplacement de la racine NFSroot du point de montage originel vers dans ''/ro'', 
  - montage d'un partage distant, d'une partition locale ou distante, ou d'un volume TMPFS dans un autre point de montage ''/rw''
  - superposition des deux dossiers ''/ro'' et ''/rw'' dans le dossier ''/aufs''
  - déplacement de ''/aufs'' vers le point de montage originel

Ce script, ''rootaufs'' se place dans ''${SIDUS}/etc/initramfs-tools/scripts/init-bottom''

<note important>Dans le  [[http://www.linuxjournal.com/content/november-2013-issue-linux-journal-system-administration|numéro de novembre 2013 de Linux Journal]], ''rootaufs'' manque dans la définition du fichier destination.</note>
Le script originel a été inspiré par le projet **rootaufs** de Nicholas A. Schembri (http://code.google.com/p/rootaufs/). Il a été profondément modifié pour l'adapter à notre infrastructure : une version est disponible sur http://www.cbp.ens-lyon.fr/sidus/rootaufs :<code>
wget -O ${SIDUS}/etc/initramfs-tools/scripts/init-bottom/rootaufs http://www.cbp.ens-lyon.fr/sidus/rootaufs
chmod 755 ${SIDUS}/etc/initramfs-tools/scripts/init-bottom/rootaufs
</code>

Nous n'en avons pas encore fini pour disposer d'un système fonctionnel : nous allons créer un ''initrd'' spécifique pour notre boot NFS:
  * ''aufs'' dans ''${SIDUS}/etc/initramfs-tools/modules''
  * ''eth0'' comme DEVICE dans ''${SIDUS}/etc/initramfs-tools/initramfs.conf''

<code>sidus update-initramfs -k all -u</code>

<note important>Dans [[http://www.linuxjournal.com/content/november-2013-issue-linux-journal-system-administration|numéro de novembre 2013 de Linux Journal]], ''vmlinux-Sidus'' est mentionné en lieu et place de ''vmlinuz-Sidus'' comme noyau servi par le serveur TFTP.</note>
Il suffit ensuite de copier les noyau et boot loader dans la définition :<code>
cp ${SIDUS}/boot/vmlinuz-3.2.0-4-amd64 /srv/tftp/vmlinuz-Sidus
cp ${SIDUS}/boot/initrd.img-3.2.0-4-amd64 /srv/tftp/initrd.img-Sidus
</code>

A l'origine, nous avons exploré la possibilité d'offrir un second partage NFS en lecture/écriture pour la persistance des modifications associées aux clients d'un redémarrage à l'autre. Cette version, bien que fonctionnelle, exigeait l'ouverture d'un partir NFS atomique pour chaque client avec ce qu'on imagine comme charge pour leur serveur ! 

Nous avons donc préféré une autre approche de persistance, sous la forme d'un disque réseau de technologie iSCSI, dont nous avons vu la définition dans notre fichier ''/srv/tftp/pxelinux.cfg/default'', avec la définition de ''LABEL=iscsi''. Avec cela, pour assurer la persistance, nous créons un partage iSCSI par client. Les paramètres de montage du disque iSCSI sont définis dans la commande en ligne.

Pour des raisons de simplicité, le volume offert porte l'IP du client et nous ne fournissons que le serveur de volume iSCSI. Des login et mot de passe d'accès par défaut sont dans le fichier ''rootaufs''.

===== Quelques ruses (à appliquer) =====

  * pour le paramétrage du nom par DHCP (hostname), effacer ''/etc/hostname''
  * paramétrer le ''/etc/resolv.conf'' avec une définition persistente
  * dans ''/etc/network/interfaces'' : définir un loopback
  * modifier le démarrage de GDM3 pour ne le démarrer qu'après le lancement du NSCD
  * paramétrer le ''/etc/security/limits.conf'' (indispensable dans un environnement HPC)
  * paramétrer du ''/etc/fstab'' avec l'entrée du serveur NFS des comptes utilisateurs
  * faire pour le montage NFS : ''echo ASYNCMOUNTNFS=no %%>>%% ${SIDUS}/etc/default/rcS''

==== Pour les systèmes virtuels à base de VirtualBox : ====

  * Installer VBoxLinuxAdditions.run dans le système Sidus

==== Pour les systèmes avec une carte InfiniBand : ====

  * Forcer le chargement des modules dans ''/etc/modules'' et regénérer le ''initrd''
  * Exécuter dans ''/etc/rc.local'' un script permettant de récupérer l'adresse IP Ethernet et construire une adresse IP pour la carte Infiniband.

==== Pour les systèmes avec une carte Nvidia : ====

Pour la majorité des cartes Nvidia, les paquets proposés dans la Debian Wheezy permettent une installation complète des pilotes propriétaires, des libraries OpenGL, Cuda et OpenCL. 

Attention cependant si vous désirez utiliser simultanément l'ICD (Installable Client Loader) OpenCL d'AMD pour exploiter vos processeurs ET votre carte graphique : nous avons dû installer toute l'infrastructure pilote, Cuda et OpenCL pour le permettre.

Pour les cartes Quadro 2000M de portable, il semble que la dernière bouture "qui fonctionne" soit la version 319.60.
Pour les cartes plus récentes, dont les GTX Titan, un pilote supérieur à la 319 est indispensable.

Dans tous les cas, le rétroportage des paquets Nvidia de Sid ou Experimental pour Wheezy fonctionne plutôt bien.

==== Pour les systèmes avec une carte AMD ATI ====

Pour la majorité de cartes ATI, les paquets proposés dans la Debian Wheezy permettent une installation complète des pilotes propriétaires, des libraries OpenGL, Cuda et OpenCL.


===== Démontage binding "système" =====

De manière à installer correctement SIDUS, nous avons été contraint de lier étroitement système hôte et chroot. Il est donc nécessaire de réaliser les opérations opposées du début d'installation de SIDUS.

<code>
umount ${SIDUS}/run/shm
umount ${SIDUS}/dev/pts
sidus umount /proc/sys/fs/binfmt_misc
sidus umount /proc
sidus umount /sys
</code>

===== Configuration du démarrage de services =====

<code>
cp /sbin/start-stop-daemon ${SIDUS}/sbin/start-stop-daemon
</code>

Si vous souhaitez que votre SIDUS chrooté démarre ses services (mauvaise idée), vous devez supprimer le hook correspondant.
<code>
rm -f ${SIDUS}/usr/bin/policy-rc.d
</code>

===== Effacement des dossiers temporaires =====

<code>
rm -r ${SIDUS}/run/* ${SIDUS}/tmp/* 
</code>

===== Purge des processus liés à Sidus =====

<code>
lsof | grep ${SIDUS}  | awk '{ print $2 }' | sort -u | xargs -I '{}' kill '{}'
</code>


====== Administration ======

L'administration d'une instance Sidus s'administre comme tout système chrooté : il y a cependant des précautions à prendre, toutes les fonctions d'administration n'exigeant pas les mêmes contraintes les unes des autres.

===== Mise à jour Debian =====

C'est certainement la fonction la plus courante. Le problème de la mise-à-jour est double :
  * des paquets peuvent remplacer des services démarrant par ''/etc/init.d'' : une séquence va donc tenter d'arrêter et redémarrer le service
  * des paquets exigent la présence d'un ''/proc'' monté

Pour réaliser une mise-à-jour d'une instance SIDUS installée dans ''${SIDUS}'' en toute tranquillité, il suffit d'enchaîner les commandes suivantes :

  * En amont des commandes de mise-à-jour :<code>
mount --bind /dev/shm ${SIDUS}/dev/shm 
mount --bind /dev/pts ${SIDUS}/dev/pts 
chroot ${SIDUS} mount -t proc none /proc
</code>
  * Commandes de mise-à-jour :<code>
chroot ${SIDUS} aptitude update
chroot ${SIDUS} aptitude -y full-upgrade
chroot ${SIDUS} aptitude clean</code>
  * En aval des commandes de mise-à-jour :<code>
umount -l /proc
umount -l ${SIDUS}/dev/shm
umount -l ${SIDUS}/dev/pts
lsof | grep ${SIDUS}  | awk '{ print $2 }' | sort -u | xargs -I '{}' kill '{}'  
</code>

La dernière ligne des commandes aval est une précaution pour éviter que des processus lancés dans l'instance tourne sur l'hôte.


====== Démonstration Scipy 2013 ======

Les images suivantes [[http://www.cbp.ens-lyon.fr/sidus/sidus4scipy2013.ova|Sidus4Scipy2013]] et [[http://www.cbp.ens-lyon.fr/sidus/sidus4client.ova|Sidus4Client]] permettent de juger de l'efficacité de Sidus à offrir un environnement complet sur un poste de travail unique.

Ces deux images nécessitent toutes les deux l'outil de virtualisation Open Source [[http://www.virtualbox.org|VirtualBox]] disponibles sur les plates-formes Linux, MacOS X, Windows et Solaris. 

L'instance SIDUS est intégrée dans la machine virtuelle **sidus4scipy** issue de l'importation de la machine [[http://www.cbp.ens-lyon.fr/sidus/sidus4scipy2013.ova|Sidus4Scipy]]. Elle offre un bureau Gnome complet avec des outils Python présentés lors de Scipy 2013

La machine virtuelle **sidus4client** intègre la machine virtuelle minimale permettant de démarrer un client utilisant l'instance SIDUS. Après quelques secondes, un bureau Gnome s'ouvre.

Quelques éléments :
  * l'espace nécessaire pour installer l'image complète est de 8 Go
  * à l'importation :
    * demander la réinitialisation de l'adresse Mac (dans le cas contraire, toutes les personnes sur le même réseau local auront la même adresse IP : des difficultés de communication sont à prévoir :)
  * avant le démarrage de la machine virtuelle :
    * ouvrir les paramétrages
    * aller dans le paramétrage réseau et vérifier l'interface réseau : c'est **eth0** sous Linux, **en0** sous MacOS
    * aller dans le paramétrage de partage et créer un dossier **MyHost**
  * il est préférable de disposer d'au moins 3 Go sur la machine créant ces deux machines virtuelles
  * lors du démarrage, les claviers sont en QWERTY américains
  * les identifiants et mots de passe du root et de 4 comptes génériques créés
    * **root** et **Sidus2013**
    * **alpha** et **Alpha13**
    * **beta** et **Beta13**
    * **gamma** et **Gamma13**
    * **delta** et **Delta13**
    * (voir pour toutes les autres lettres grecques dans un dico !)
    * **omega** et **Omega13**

<note warning>Attention ! Dans un souci d'internationalisation (Scipy 2013)
  * le clavier par défaut est un américain Qwerty, 
  * la langue par défaut est l'anglais
  * le fuseau horaire celui de Austin
Il est très facile de repasser dans un mode "français" pour le clavier et le fuseau via les commandes
  * Pour le serveur SIDUS
    * ''dpkg-reconfigure keyboard-configuration''
    * ''dpkg-reconfigure tzdata''
  * Pour le client SIDUS
    * ''sidus dpkg-reconfigure keyboard-configuration''
    * ''sidus dpkg-reconfigure tzdata''
</note>

===== Démarrage sur une machine tierce =====

Il est aussi possible de démarrer l'instance sur une autre machine en sélectionnant dans la configuration de la machine virtuelle l'interface réseau que vous comptez utiliser (généralement ''eth0''), 
  * soit en connectant directement la machine à une autre via le port Ethernet, une condition est nécessaire
    * un port RJ45 supportant l'autoconfiguration en port croisé
  * soit en connectant la machine hôte et la machine cliente sur un commutateur externe

Dans les deux cas, le //forwarding// doit être activé : ''/proc/sys/net/ipv4/ip_forward'' mis à ''1''.

 --- //[[emmanuel.quemener@ens-lyon.fr|Emmanuel Quemener]] 2013/11/03 15:38//