SIDUS

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

Son 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

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'auteur et faites en la promotion !

Si vous voulez déployer SIDUS sur vos installations et vous faire aider, vous pouvez contacter l'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 :

Dans 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.

Pour le serveur DHCP, dans le fichier de configuration /etc/dhcp/dhcpd.conf :

next-server 10.13.20.13;
filename "pxelinux.0";
allow booting;

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.

./pxelinux.0 
./vmlinuz-Sidus
./initrd.img-Sidus
./pxelinux.cfg

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
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 

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 :

/srv/nfsroot/sidus 10.13.20.128/255.255.255.0(ro,no_subtree_check,async,no_root_squash)

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, 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 :

export SIDUS=/srv/nfsroot/sidus
alias sidus="DEBIAN_FRONTEND=noninteractive chroot ${SIDUS} $@"

Nous avons définis les $MyInclude et $MyExclude suivants pour une architecture 64 bits AMD64 :

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"

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 :

debootstrap --arch amd64 --components='main,contrib,non-free' --include=$MyInclude --exclude=$MyExclude wheezy $SIDUS http://ftp.debian.org/debian

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) :
#!/bin/sh
exit 101

Ou sous forme de commande :

printf '#!/bin/sh\nexit 101\n' > ${SIDUS}/usr/sbin/policy-rc.d
chmod +x ${SIDUS}/usr/sbin/policy-rc.d
  • 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 :
    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

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) :

sidus apt-get install --install-suggests -f -m -y --force-yes science-*

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 !

sidus apt-get purge -y -f --force-yes matlab-*

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:

wget -O  ${SIDUS}/etc/nsswitch.conf http://MyServeur.MySIte/sidus/nsswitch.conf

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 :

  1. création de dossiers temporaires /ro, /rw et /aufs
  2. déplacement de la racine NFSroot du point de montage originel vers dans /ro,
  3. montage d'un partage distant, d'une partition locale ou distante, ou d'un volume TMPFS dans un autre point de montage /rw
  4. superposition des deux dossiers /ro et /rw dans le dossier /aufs
  5. déplacement de /aufs vers le point de montage originel

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

Dans le numéro de novembre 2013 de Linux Journal, rootaufs manque dans la définition du fichier destination.

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 :

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

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
sidus update-initramfs -k all -u
Dans 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.

Il suffit ensuite de copier les noyau et boot loader dans la définition :

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

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.

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

Configuration du démarrage de services

cp /sbin/start-stop-daemon ${SIDUS}/sbin/start-stop-daemon

Si vous souhaitez que votre SIDUS chrooté démarre ses services (mauvaise idée), vous devez supprimer le hook correspondant.

rm -f ${SIDUS}/usr/bin/policy-rc.d

Effacement des dossiers temporaires

rm -r ${SIDUS}/run/* ${SIDUS}/tmp/* 

Purge des processus liés à Sidus

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

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

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 Sidus4Scipy2013 et 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 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 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
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

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.

Communications autour de SIDUS

Emmanuel Quemener 2015/03/20 09:27

developpement/productions/sidus.txt · Dernière modification: 2015/03/20 09:30 par equemene