Trucs et astuces d'organisation pour les administrateurs système et réseau 1. Présentation de Joël Marchand Le support de la présentation est disponible ici : http://www.math.cnrs.fr/mathrice/mars.2003/organisation/joel.txt Tout ce qui a été dit à lors de la présentation y est. Les lignes qui suivent reprennent la majorité des points du support en les développant un peu. Le point clé pour survivre est de faire preuve de grande rigueur et de discipline pour respecter les principes que l'on s'est fixé, en particulier de conserver une trace écrite de *toute* activité. Pour limiter le "zapping", faire peu de chose mais bien (ce qui a un effet de bord positif sur le moral). Un autre leitmotiv : faire du "low tech". En d'autres termes, privilégier ce qui est simple, rustique et bien connu et se méfier des modes et du "bleeding edge" tout chaud sorti de la forge. Communiquer abondamment --sans avoir peur de râbacher-- tant en mode "push" (mél) que "pull" (web). La rédaction de documentation sur le web prend du temps, mais elle permet ensuite d'y renvoyer les utilisateurs et de gagner du temps par factorisation. Pour les services sur les serveurs, ne pas hésiter à appliquer la politique du "format + install" (sur une machine qui n'est pas en production) pour faire des tests. Dans le cas où l'on prend un nouveau poste, négocier soigneusement et par écrit le cadre de travail avec la direction, afin que les choses soient bien claires. Si la situation "dérape", ce document permettra de bien recadrer les choses. Demander aux utilisateurs de consulter le web avant de faire une requête, et de faire leur requête par mél à une adresse banalisée (et pas votre adresse personnelle). Tout ceci devra être rabâché sans relâche. Mettre en place des correspondants informatiques dans les équipes, qui seront les interlocuteurs de niveau 1 des utilisateurs. Pour éviter que le service informatique (SI) soit le centre de débats entre utilisateurs passionnés, mettre en place des listes de diffusion thématiques avec archive : les passions se déchaîneront sur ces liste. Deux exemples : - la liste macosx@math.jussieu.fr, créée à l'arrivée de Mac OS X : les utilisateurs enthousiastes ont pu échanger leurs expériences sur ce nouveau système, se sont enrichi mutuellement et on appris des choses au SI ; - la liste beta@math.jussieu.fr, conçue pour les férus de nouveautés parues la veille. Les abonnés à cette liste sont des beta-testeurs consentants avec lesquels le SI peut dialoguer. Ces listes gagnent à être ouvertes vers d'autres laboratoires pour augmenter les échanges. Tous les fichiers de configuration importants sont dupliqués à un endroit (dépôt) unique. Des scripts simples (toujours faire simple...) existent pour recopier les fichiers de conf du dépôt vers une machine en cas de réinstallation, où de donner les différences entre le dépôt (référence) et la machine que l'on est en train de bricoler. Cette discipline a pour effet de bord positif d'identifier les fichiers de conf qui sont vraiment importants. On met également dans ce dépôt : - dmesg.log : le résultat de la commande 'dmesg' qui donnent les messages de boot ; - pkginfo.log : le résultat de la commande 'pkginfo' (ou équivalent) qui listent les paquets qui sont installés sur le système ; - lsof.log : le résultat de la commande 'lsof -i | grep -i listen', qui liste les services qui écoutent le réseau ; - la config des noyaux et leurs éventuelles modifications. Un outil pour la gestion des fichiers de conf a été évoqué : cfengine (http://www.cfengine.org/). Mais pas de retour d'expérience à ce sujet. Est-ce suffisamment "low tech" ? Toujours garder les fichiers de conf d'origine, i. e. faire 'cp -p toto.conf toto.conf.orig' avant de faire quoique ce soit. Si le fichier de conf a une histoire compliquée, archiver ses différentes versions en suffixant la date au nom de fichier. Mettre la date au format ISO YYYY-MM-DD pour que le tri du ls (je crois qu'on dit lexicographique) corresponde au tri chronologique. Exemple : toto.conf.2002-12-27 toto.conf.2003-01-13 toto.conf.2003-02-05 Pour les imprimantes, un seul gros fichier 'printcap' (ou équivalent) pour tout le monde. Il contient toutes les imprimantes du labo. À partir d'une machine centrale, on est root sur les autres via ssh, sans passphrase (passphrase vide). Cela permet de faire des choses qui nécessitent d'être root via cron la nuit. Un fil sur la liste mathrice a eu lieu à propos de ces passphrases vides : sujet 'potins divers', initié le 28/03/2003 17:12 par Jacques Foury : http://www.math.cnrs.fr/archives/mathrice/msg02442.html La sauvegarde est centralisée : rsync des serveurs (/ et /usr/local) vers un gros espace disque, qui est sauvegardé par tar (logiciel de sauvegarde "low tech" !) sur SDLT. NDLA : tar est utilisable si on a la chance de tout pouvoir faire tenir sur une seule bande. Les journaux (logs) sont centralisés vers une seule machine : loghost. Le nom 'loghost' est un alias DNS, cf. plus loin. Le 'syslog.conf' de chaque serveur (client syslog) est réduit à : *.* @loghost Sur le serveur syslog loghost : - tous les logs (*.*) vont dans all.log - les logs sont filtrés thématiquement vers des fichiers dédiés (par ex. 'auth.*' vers 'auth.log', 'mail.*' vers 'mail.log', etc.) Un 'tail -f all.log' permet de voir la vie du réseau, alors qu'un 'tail -f mail.log' permet la supervision d'un service en particulier. Les logs ont une rotation de période une semaine. Des scripts de comptage spécialisés permettent de remonter des statistiques. Les logs sont sauvegardés sur bande. Dans le DNS, on met un nom par service. Par exemple, la machine 'riemann' (nom canonique) fournit les services SMTP, POP, IMAP et webmail. Les noms 'smtp', 'pop', 'imap' et 'webmail' sont alors des alias de 'riemann'. Si 'riemann' tombe et qu'en urgence on met le service SMTP sur 'gauss', on change dans le DNS : le nom 'smtp' devient un alias de 'gauss'. À l'aide de Big Brother (http://bb4.com/) et de MRTG (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/), on peut se faire un tableau de bord visible sur le web depuis n'importe où. On peut par exemple superviser la charge CPU, l'espace disque consommé, les jetons de licence consommés, etc. Le tableau de bord de math.jussieu est visible ici : http://www.math.jussieu.fr/bb/ Pour les installation de postes individuels genre PC Windows ou Mac, faire un dépôt dans lequel on met tous les logiciels à installer (Acrobat Reader, Anti-virus, Mozilla, client NTP, etc.). Lorsqu'on a une machine à installer, on la met sur le réseau, on va dans le dépôt correspondant et on clique sans (trop) réfléchir. La communauté Mathrice pourrait aider à maintenir ces dépôts au goût du jour. Pour gérer la masse de mél, filtrer (.procmailrc ou autre) au maximum dans des dossiers, garder le plus petit Inbox (/var/mail/toto) possible : au maximum une page d'écran. Tenir à jour un fichier 'a.faire', dans lequel on insère toutes les nouvelles tâches. Relire et réorganiser (gestion des priorités) ce fichier plusieurs fois par mois. Effet de bord positif : bien au moral quand on enlève une tâche. Tenir à jour un fichier 'attente', dans lequel on met toutes les tâches pour lesquelles la balle n'est pas dans notre camp (en attente, en cours, au point mort) : permet de se décharger l'esprit, et de se les remémorer rapidement. Pour chaque tâche, rédiger un "mémo" où l'on met la documentation rédigée au vol ainsi que l'historique des modifications, les options de ligne de commande qui vont bien, etc. Plus tard, on pourra retrouver des points précis en faisant 'grep' dans le répertoire des mémos. Quand les mémos ne sont pas finis, ils sont dans $HOME. On peut ainsi, après une période de "zapping", se rappeler les tâches précédemment abandonnées par un 'ls -lrt' (tri par dernière date de modif). Discipline quotidienne : - essayer de bien faire, notamment bien nommer les fichiers ; - ne pas laisser traîner de fichiers ; - rédiger les mémos ; Quelques éléments bons pour le moral : - ne pas toujours faire de l'urgence ; - quoiqu'il arrive, résister à la pression et faire des tâches de fond ; - relire, élaguer et "reprioritiser" plusieurs fois par mois le fichier 'a.faire' ; Quelques éléments bons pour la popularité : - essayer de répondre rapidement au gentil utilisateur ; - rendre compte (liste beta, commission informatique) ; - documenter le plus rapidement possible sur le web ; 2. Commentaires d'Emmanuel Halbwachs Pas grand-chose à dire puisque tout a été dit dans la présentation de Joël Marchand. Sans se concerter, on arrive sur les mêmes grands principes, ce qui est rassurant. Quelques commentaires sur l'exposé de Joël Marchand. Il s'agit de difficultés rencontrées dans la "vraie vie" lors de la mise en oeuvre des bonnes pratiques énoncées. - Faire preuve de grande rigueur et de discipline n'est pas chose facile si son propre tempérament n'y incite pas naturellement. Si le service informatique est une équipe, ces notions de rigueur et de discipline peuvent être conçues différemment selon les individus. Il est donc important de beaucoup discuter pour converger vers un compromis qui sera accepté -et donc adopté- par tout le monde. - Il n'est pas toujours facile de résister aux nouveautés. Par exemple, si on veut se cantonner à Netscape 4, on se heurtera au problème des sites web de plus en plus nombreux qui ne s'affichent pas correctement avec ce navigateur. Et l'utilisateur risque de dire "C'est nul, je passe à Internet Explorer". Quel tiraillement... - Se dégager de l'urgence et du "zapping" semble être le plus important. Il apparaît indispensable de se ménager des plages de temps pendant lesquelles on ne fait pas d'assistance utilisateur (mode "non interruptible", sauf en cas de gros pépin, bien sûr). Il est aussi important de canaliser la façon de faire des requêtes : par mél à une adresse dédiée, par téléphone (mais le moins possible) à un numéro dédié, pas de requêtes dans les couloirs, pas d'irruption dans le bureau pour des requêtes (acquérir un "groom" pour que la porte reste fermée et ainsi obliger les gens à frapper avant d'entrer), etc. Ces pratiques sont à faire approuver par la direction et/ou le conseil de labo puis indiquées et rabâchées aux utilisateurs. - Autre chose à faire valider par la direction et/ou le conseil de labo : le périmètre d'intervention du service informatique (SI). Autrement dit, "ce qu'on fait" vs "ce qu'on fait pas". Il est bien de se recentrer sur les activités qui demandent une vraie compétence et que seul le SI peut faire. Il faut l'afficher sur le web. Rien n'empêche de faire des extras si on en a le temps, mais il faut alors gentiment faire comprendre à l'utilisateur que c'est une faveur. En cas de surcharge, on pourra alors se référer à ce contrat. - Les correspondants informatiques dans les équipes : il n'est pas toujours facile de trouver des volontaires ("Ouh là là, mais je ne vais faire que ça", "Ça n'est pas mon boulot", etc.). Dans notre labo, certains correspondants informatiques ont été "désignés volontaires" par leur chefs d'équipe. Il est alors parfois délicat de s'appuyer sur eux. il faut alors faire preuve de persuasion/psychologie pour expliquer que leur action va dans le sens de l'intérêt commun. 3. Présentation de Philippe Depouilly et de Jacques Foury 3.1 Guichet unique de permanence À Bordeaux, les informaticiens de plusieurs laboratoires se sont fédérés pour faire une permanence d'assistance. Il forment un groupe de 5 personnes, donc chacun fait la permanence un jour de la semaine. La permanence a un numéro de téléphone unique, que chacun renvoie a tour de rôle sur son poste. Il y a un effort de la personne de permanence pour être présente dans son bureau le plus possible. Si une tâche nécessite un déplacement, c'est une autre personne que celle de permanence, le binôme, qui se déplace. Chacun est donc binôme à son tour. 3.2 Outils de gestion de requêtes La gestion des requêtes se fait avec un logiciel "maison", baptisé provisoirement SOS, qui s'accède via le web et qui est basé sur PHP + PostgreSQL. Le logiciel SOS devrait pouvoir fonctionner avec MySQL (attention toutefois au type 'timestamp', utilisé par SOS, qui est différent entre ces deux SGBD). Nous avons eu droit à une démonstration de SOS qui permet entre autres choses : - à un utilisateur de faire une requête ; - à un admin de prendre en charge la requête ; - aux admins entre-eux de se passer la prise en charge ; - d'attacher un champ texte à la requête, qui est à la discrétion de l'admin et peut contenir l'historique, une description, des remarques, etc. Pour les personnes qui seraient intéressées par SOS, une distribution prête à installer existe et est disponible en http://www.math.cnrs.fr/mathrice/mars.2003/organisation/sos.tar.gz Un autre logiciel, Gédéon, est envisagé. Gédéon est en fait un projet très similaire, qui a été développé par deux collègues de Bordeaux exactement en même temps que SOS. Les bordelais sont en train de monter un petit groupe d'admin à Bordeaux (environ une dizaine) pour poursuivre le développement de gédéon qui est maintenant aussi utilisé par le CRI de Bordeaux. Pour les utilisateurs potentiels de SOS, on peut dire que Gédéon est un grand frère de SOS (même philosophie mais avec quelques fonctionnalités supplémentaires et un peu plus abouti). Dès que gédéon sera dans un état "simple à installer", les bordelais pourrons faire un retour d'infos à son sujet. 3.3 (Re)installation de machine via réseau Les installations de machines (serveurs et clients) se font par réseau avec l'outil de RedHat : kickstart http://www.tldp.org/HOWTO/KickStart-HOWTO.html 99 % des postes Linux sont sous RH et environ 95 % sous RH-7.2. Ceci est possible en passant exclusivement par des installations via kickstart et aussi PXE (boot via le réseau qui évite tout support nécessaire pour booter, Kickstart via PXE est proposé de base sur les CD de la RH). Cette technique permet de stocker toutes les confs des machines clientes et serveurs (on utilise ce mécanisme pour rapidement réinstaller à l'identique une machine en panne). C'est un peu le pendant high-tech de ce qui a été présenté par Joël.