Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
developpement:productions:sidus [2013/11/04 12:13] ltaulell [Deboostrap] |
developpement:productions:sidus [2022/03/16 14:45] (Version actuelle) equemene [Démonstrateur SIDUS sous VirtualBox] |
||
---|---|---|---|
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 !" ====== |
- | <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> | + | ===== 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. | ||
- | <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> | + | 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 : |
- | <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> | + | * [[https://www.debian.org/releases/bullseye/|Debian Bullseye]] : la dernière distribution Debian, la 11.2 |
+ | * [[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 23: | Ligne 80: | ||
* **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 40: | Ligne 98: | ||
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 59: | Ligne 117: | ||
Le laboratoire de Chimie utilise "COMOD" pour quelques postes de travail "à la demande". | Le laboratoire de Chimie utilise "COMOD" pour quelques postes de travail "à la demande". | ||
- | Des membres des laboratoires de l'IGFL, du LBMC et du LJC se sont montrés intéressés par "COMOD" : il reste à définir les modalités d'accès lesquelles ne sont pas entre les mains du CBP. | + | 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. | 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. | ||
Ligne 67: | Ligne 125: | ||
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 près 100 noeuds. Le futur équipement informatique Equip@Meso de près de 150 noeuds supplémentaires, utilisera SIDUS comme socle dans quelques semaines. | + | 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 73: | Ligne 131: | ||
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> | ||
- | time 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> | ||
- | time 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 partage 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}/vmlinuz /srv/tftp/vmlinuz-Sidus | ||
- | cp ${SIDUS}/initrd.img /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'' | ||
- | * Liste à puceExé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// |