Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
developpement:productions:sidus [2015/03/20 09:30]
equemene [Communications autour de SIDUS]
developpement:productions:sidus [2020/09/18 10:29] (Version actuelle)
equemene
Ligne 1: Ligne 1:
-====== SIDUS  ======+{{ :​developpement:​productions:​sidus-800.png?​600 |}}
  
-{{ :developpement:productions:sidus.png?​200 ​|}}+====== SIDUS "avec SIDUS, n'​installe plus, démarre seulement tes machines !" ====== 
 + 
 +===== Démonstrateur SIDUS sous VirtualBox ===== 
 + 
 +Pendant 7 ans, le Centre Blaise Pascal mettait à disposition toute la documentation permettant à un administrateur système de déployer son propre SIDUS. Trop compliqué pour beaucoup, il leur était impossible d'​avoir rapidement quelque chose de fonctionnel. 
 + 
 +Pour simplifier la compréhension et la prise en main de SIDUS, le démonstrateur **Sidus4Labs** est mis à disposition sous forme d'une machine virtuelle sous [[https://​www.virtualbox.org/​wiki/​Downloads|VirtualBox]]. Il permet de démarrer les trois versions de distributions les plus courantes en quelques secondes ​: 
 + 
 +  * [[https://​www.debian.org/​releases/​buster/​|Debian Buster]] : la dernière distribution Debian, la 10.5 
 +  * [[https://​releases.ubuntu.com/​20.04/​|Ubuntu Local Fossa]] ; la dernière distribution Ubuntu, la 20.04 
 +  * [[https://​www.centos.org/​centos-linux/​|CentosOS]] : la dernière distribution CentOS, la 8 
 + 
 +Ces 3 distributions proposent pour chaque client SIDUS au moins un bureau graphique complet, dont le "​léger"​ XFCE.  
 + 
 +===== Récupération des archives VirtualBox ===== 
 + 
 +Pour déployer ce SIDUS, il est donc indispensable d'​installer préalablement l'​application [[https://​www.virtualbox.org/​wiki/​Downloads|VirtualBox]] sur son équipement. VirtualBox existant sur la majorité des systèmes d'​exploitation,​ rien ne s'​oppose au déploiement de ce démonstrateur SIDUS sous la majorité des distributions GNU/Linux, Windows ou MacOSX.  
 + 
 +  * **[[https://​www.cbp.ens-lyon.fr/​sidus/sidus4labs.ova|serveur Sidus4Labs]]** : le système **"​maître"​** portant les 3 arbres SIDUS 
 +  * **[[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_bios.ova|client Sidus4Labs BIOS]]** : le système "​client"​ exploitant un BIOS au démarrage 
 +  * **[[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_uefi.ova|client Sidus4Labs ​ UEFI]]** : le système "​client"​ exploitant un boot UEFI au démarrage 
 + 
 +  * Le serveur **Sidus4Labs** propose un environnement complet comprenant tout ce qui est nécessaire pour déployer plusieurs centaines de clients SIDUS. Il intègre les services suivants : TFTP, DHCP, DNS, NFS. Il fonctionne sous une distribution Debian Buster. Son occupation maximale de disque est fixée à 48GB. L'​archive n'​occupe que 10GB d'​espace disque. 
 +  * Le client **Sidus4Labs BIOS** intègre simplement une machine virtuelle "​vide"​ de disque et une interface réseau démarrant avec un BIOS standard. 
 +  * Le client **Sidus4Labs UEFI** intègre simplement une machine virtuelle avec une mini-partition UEFI et une interface réseau. Cette machine illustre le fonctionnement de SIDUS sur des machines récentes disposant d'un environnement de démarrage UEFI. 
 + 
 +===== Installation du serveur et des clients ===== 
 + 
 +Avant d'​installer les images, vérifiez que vous disposez d'au moins 48GB d'​espace de stockage (en plus de l'​archive **Sidus4Labs** de 10GB). 
 + 
 +Une fois téléchargées,​ il suffit généralement de double-cliquer sur l'​icône de ces archives pour les intégrer dans votre application VirtualBox : cela va dépendre des systèmes d'​exploitation. Il est raisonnable de directement les intégrer "telle que" sans changer les adresses MAC comme demandé à l'​installation. 
 + 
 +L'​espace total (maximal) occupé par **Sidus4Labs** est de 48GB d'​espace disque. Le serveur **Sidus4Labs** et les clients **BIOS** et **UEFI** sont paramétrés pour occuper 2GB de RAM. 
 + 
 +===== Démarrage du serveur et des clients ===== 
 + 
 +Le démarrage du serveur **Sidus4Labs** s'​effectue en quelques secondes. Une fois l'​invite du terminal disponible, le serveur **Sidus4Labs** est prêt à démarrer un client **Sidus4Labs**. 
 + 
 +Le démarrage d'un client **Sidus4Labs** est alors possible, issu des 3 distributions disponibles : Debian, Ubuntu et CentOS. 
 + 
 +  * Démarrage d'une machine **[[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs-boot.webm|sidus4labs]]**,​ le maître 
 +  * Démarrage d'une SIDUS **Debian Buster** en [[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_bios_Debian.webm|BIOS]] et [[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_uefi_Debian.webm|UEFI]] 
 +  * Démarrage d'une SIDUS **Ubuntu 20.04** en [[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_bios_Ubuntu.webm|BIOS]] et [[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_uefi_Ubuntu.webm|UEFI]] 
 +  * Démarrage d'une SIDUS **CentOS 8** en [[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_bios_CentOS.webm|BIOS]] et [[https://​www.cbp.ens-lyon.fr/​sidus/​sidus4labs_client_uefi_CentOS.webm|UEFI]] 
 + 
 +===== Quelques remarques fondamentales ===== 
 + 
 +Par défaut, le mot de passe **root** du serveur **sidus4labs** est **Sidus4LABS** (pas très original donc à changer par vos soins). 
 + 
 +Il y a 24 comptes accessibles,​ les 24 lettres grecques de **alpha** à **omega**. Le mot de passe de chacun est son login avec la première lettre en majuscule et immédiatement suivi de cette funeste année, 2020 : donc de **Alpha2020** à **Omega2020**. 
 + 
 +Le compte **alpha** est un compte **sudo**. Il est donc possible de passer **root** en exploitant ce compte. Il est donc préférable de changer le mot de passe du compte **alpha** si vous //sortez// cet environnement Sidus4LABS de votre poste de travail. 
 + 
 +Le compte **root** dispose de deux clés d'​accès **ssh** :  
 +  * celle sans mot de passe : pour se connecter à **root** de **root** sur le serveur et sur n'​importe quel client SIDUS.  
 +  * celle du créateur de Sidus4LABS : pour de la maintenance initiale mais aussi pour lui permettre d'​accéder au serveur en cas de demande d'​intervention 
 +  * si vous craignez quoi que ce soit, ''​rm /​root/​.ssh/​authorized_keys''​ 
 + 
 +Les deux interfaces réseau du serveurs **sidus4labs** sont NATés. Pour accéder au serveur de l'​extérieur,​ il existe une redirection du port 22022 sur le port 22. Pour accéder au serveur **sidus4labs** de sa machine hôte, il suffit d'un ''​ssh -p 22022 <​login>​@localhost''​. 
 + 
 +Chacun des systèmes proposés au démarrage dispose d'un environnement graphique comparable, XFCE, plutôt léger. D'​autres environnements sont proposés, mais ils requièrent un matériel graphique conséquent. Il se peut donc que GNOME3, choisi comme environnement par défaut par certaines distributions,​ ne fonctionne pas correctement. XFCE fonctionne dans tous les cas. 
 + 
 +<note warning>​Pour en savoir plus sur SIDUS, c'est là-dessous</​note>​ 
 +====== SIDUS en quelques phrases ======
  
 **SIDUS** est l'​acronyme de //Single Instance Distributing Universal System// et se propose de simplifier à l'​extrême l'​administration de machines. ​ **SIDUS** est l'​acronyme de //Single Instance Distributing Universal System// et se propose de simplifier à l'​extrême l'​administration de machines. ​
Ligne 16: Ligne 79:
   * **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. ​   * **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 ​: les 7 questions sur SIDUS ======
  
 [[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. [[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 ? ===== ===== Pourquoi ? =====
  
Ligne 33: Ligne 97:
 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. 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//).+Mi 2015, SIDUS sert 76 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 ? ===== ===== Pour Qui ? =====
Ligne 60: Ligne 124:
 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 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.+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 480 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. 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.
Ligne 66: Ligne 130:
 Lors des école thématiques des Houches sur le calcul scientifique,​ SIDUS était servi à près d'une cinquantaine de machines simultanément. 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.+Quant au prix du logiciel (question ​posée ​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 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]]. Si vous voulez déployer SIDUS sur vos installations et vous faire aider, vous pouvez contacter l'​[[emmanuel.quemener@ens-lyon.fr|auteur]].
 +
 ===== Comment ? ===== ===== Comment ? =====
  
 SIDUS se base sur une majorité de composants simples et éprouvés, disponible sur la majorité des distributions GNU/Linux. 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 !+Dans les pages des années précédentes sous SIDUS, une documentation d'​installation pour Debian était détaillée... Malheureusement, ​le prérequis d'​installation rendait son appropriation inaccessible aux débutants. 
 + 
 +Il a donc été choisi de proposer une machine virtuelle complète sous VirtualBox permettant de démarrer les 3 distributions les plus courantes avec SIDUS : 
 +  * la [[https://​www.debian.org/​releases/​buster/​|Debian 10 "​Buster"​]] 
 +  * la [[https://​releases.ubuntu.com/​20.04/​|Ubuntu 20.04 "Focal Fossa"​]] 
 +  * la [[https://​www.centos.org/​|CentOS version 8]]
  
 ====== Installation ====== ====== 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''​. 
- 
-====== Communications autour de SIDUS ====== 
- 
-  * **Année 2014** 
-    * Présentation à l'ISA : SIDUS outil de reproductibilité 
-    * Présentation à [[http://​lyoncalcul.univ-lyon1.fr/​spip.php?​article3|Lyon Calcul]] : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​LyonCalcul2014.pdf|SIDUS outil de reproductibilité]],​ [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​PiMPI.avi|exemple vidéo]] 
-    * Poster à Compas 2014 sur [[developpement:​productions:​sidus|SIDUS]] : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​Compas2014_SIDUS.pdf|article Compas]], [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​Realis2014_SIDUS.pdf|article Realis]], [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​Compas2014_Poster.pdf|poster]] 
-    * Présentation au LIP sur [[developpement:​productions:​sidus|SIDUS]] : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​LIP-20140127-EQ.pdf|presentation]],​ janvier 2014 
- 
-  * **Année 2013** 
-    * Poster JRES 2013 sur [[developpement:​productions:​sidus|SIDUS]] : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​JRes2013-SIDUS-1121.pdf|article]],​ [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​JRes-Poster-SIDUS.pdf|poster]],​ décembre 2013 
-    * Présentation [[http://​succes2013.sciencesconf.org/​|Succes 2013]] sur [[developpement:​productions:​sidus|SIDUS]] avec [[http://​succes2013.sciencesconf.org/​24312/​document|article]],​ [[http://​succes2013.sciencesconf.org/​conference/​succes2013/​Succes_20131114_EQ.pdf|présentation]] et [[http://​webcast.in2p3.fr/​videos-JSFG2013_sidius|video]] : novembre 2013 
-    * Article [[http://​www.linuxjournal.com/​content/​november-2013-issue-linux-journal-system-administration|Linux Journal]] sur [[developpement:​productions:​sidus|SIDUS]] : novembre 2013 
-    * Présentation [[http://​conference.scipy.org/​scipy2013/​presentation_detail.php?​id=199|SciPy 2013]] sur [[http://​www.youtube.com/​watch?​v=J5myH0y_bks|SIDUS]] 
- 
-  * **Année 2012** 
-    * Présentation [[http://​aramis.resinfo.org/​wiki/​doku.php?​id=pleniaires:​pleniaire14juin2012|Aramis]] : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​ARAMIS-20120614_EQ.pdf|Virtualisation de ressources dans un contexte Open Source]] 
-    * Présentation Séminaire Chimie Théorique ENS-Lyon : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​ChimieTheo2012.pdf|SIDUS & Loi d'​Amdahl]] 
-    * Présentation [[http://​www.esrf.eu/​events/​conferences/​debian-for-scientific-facilities-days-1/​debian-for-scientific-facilities-days|Debian Facilitaties Days ]] : [[http://​www.cbp.ens-lyon.fr/​emmanuel.quemener/​documents/​DSFD2012_4.pdf|From Workstations to HPC with Debian]]. 
  
- --- //​[[emmanuel.quemener@ens-lyon.fr|Emmanuel Quemener]] 2015/03/20 09:27// 
developpement/productions/sidus.1426840239.txt.gz · Dernière modification: 2015/03/20 09:30 par equemene