Une réunion a eu lieu le mercredi 8 février après-midi

Contact: Philippe.d-Anfray@cea.fr

Les points sur lesquels il y aurait matière à échanger ou à travailler

• politiques et techniques d'installation et de mise à jour (même si les contraintes “locales” sont prédominantes dans les choix à effectuer…); outils associés Anaconda/Kickstart, Puppet,…
• intégration dans le SI
  • problèmes d'authentification et d'annuaire
  • gestion de parc
  • accès aux ressources partagées (Kerberox, NFS4, …)
  • sécurité (VPN, Cryptage, …)

INRIA

• Laurent Mirtain
• .. ..

CNES

• Laurent Becquey
• Gerald Grucker
• Francois Jocteur-Monrozier

EDF

• Josselin Mouette

CEA Saclay

• Philippe d'Anfray
• Stephane Despret

CEA Grenoble

• Christine Leroy
• Benoit Benda
• Renaud Haxaire

CEA Cararache

• Pierre Berrier
• Eric Caroff

David Denis de ONERA n'ayant pu être présent avait envoyé un document.

Les distributions utilisées sont liés à des raisons historiques… le plus souvent en liaison avec des projets internes ou externes. Les collaborations expliquent la grande diversité des distributions utilisées “Linux est rentré avec les projets”. Le maintien d'une distribution maison est une entreprise de longue haleine qui demande quand même des ressources (projet Calibre à EDF autour de Debian), ce type d'action a été abandonné à l'INRIA (Sophia). Pour les organismes pluridisciplinaires (comme le CEA), il est difficile d'envisager de soutenir une distribution unique. Au moins Debian, CentOS, Ubuntu, Suse, Mandriva sont utilisés à une échelle assez large chez les différents participants.

L'intérêt pour CentOS vient bien sûr de sa proximité avec RedHat/Fedora ce qui permet une certaine continuité avec les OS installés sur les serveurs et facilite le passage du développement à l'exploitation.

Notons ici le problèmes des logiciels certifiés, souvent RedHat rarement les autres? Mais visiblement, avec une politique volontariste (DEBIAN/EDF) ce n'est pas un problème.

Dernière remarque, le monde Unix inclut aussi Mac OS X.

Généralement les utilisateurs ont accès à l'environnement de bureau de leur choix (Gnome, KDE, XFCE (, … ?)), même si une version par défaut leur est le plus souvent proposée. Dans certains cas le gestionnaire de bureau est imposé. Le chargement d'un nouvel environnement de bureau peut aussi se faire via un gestionnaire d'application si l'utilisateur n'a pas la maîtrise des mises à jour.

L'évolution vers des environnements “tablette”, peu adaptés aux stations de travail avec un grand écran, comme Unity pour Ubuntu ne semble pas (encore) causer de souci. Il semble que la politique -par exemple d'Ubuntu- ne soit plus de les imposer pour le moment. Un autre exemple du coté de Mac OS X Lion.

Il semble aussi que les gestionnaires de bureau “évolués” soient gourmands en ressources notamment vis à vis des cartes graphiques ce qui peut faire baisser les performances en visualisation des stations de travail.

La tendance semble d'offrir toute la distribution à l'utilisateur. Un “Master” peut contenir un choix cohérent d'outils pour un poste de travail “standard”. Si l'utilisateur n'est pas gestionnaire de son poste et notamment n'a pas accès aux dépôts (ou autres techniques de mises à jour ..) un choix plus étendu d'outils peut néanmoins lui être proposé via un gestionnaire d'applications (type Ubuntu Software Center).

Un des gros problème sur lequel il serait bon de travailler plus concerne l'intégration des postes de travail Linux dans le SI de l'entreprise: authentification, annuaires (LDAP, synchronisation avec un AD,…), environnement réseau, ressources partagées serveurs, fichiers, imprimantes.. (Kerberos, NFS4, …) sauvegardes et outils de mobilité (WiFi, VPN, cryptage, …). Bien sûr tout cela se pose dans une autre perspective dans le cas d'une distribution “maison”.

Il est possible aussi de proposer des machines virtuelles l'utilisateur peut alors posséder sur son poste un OS “standard” pour ses tâches “fonctionnelles” et un autre pour développer… Une autre façon consiste à installer une interopérabilité “à la Citrix”.

Il y a d'autres pistes coté remote desktop ou encore cloudification d'applications

L'organisme peut proposer des logiciels métier et scientifiques “empaquetés” -maison ou externes- par exemple dans des dépots spécifiques destinées à tous les utilisateurs ou seulement à une équipe (ou direction, ou service…). Bien sûr plusieurs distributions, plusieurs empaquetages (rmp, dpkg, …). L'idéal en cas de forte hétérogénéité est que le “Master” soit configurable, dans une certaine mesure, “localement”.

Là nous avons une grande diversité parmi des intervenants, présence ou non d'un infogérant, etc… Néanmoins nous remarquons souvent que trois niveaux de service sont proposés à l'utilisateur, en schématisant:

1. gestion [par le service informatique] qui applique ses propres normes.
2. co gestion [par l'utilisateur et le service informatique] ou l'utilisateur bénéficie de services plus étendus et d'une certaine autonomie dans la mesure ou sa configuration reste “standard” au regard des normes en vigueur (typiquement une distribution “supportée”).
3. autogestion [par l'utilisateur] qui ne dispose “que d'une adresse ip”

Le cas 1) est difficile à imposer dans un environnement de R&D. Le cas 2) est idéal, le cas 3) pose des problèmes (intégration au SI, sécurité, …). Tendre vers le 2) suppose une “politique” qui convainque une majorité d'utilisateurs… ils peuvent y être poussés si les ressources partagées et autres outils de l'entreprise ne sont pas accessible (sécurité, …) à la catégorie 3). Selon le fonctionnement de l'organisme, il faut être capable de mettre des coûts pour l'organisme ou à facturer aux utilisateurs pour chaque catégorie. Pour cela, la conception et le support du socle Linux doit probablement être inclus dans l'éventuel contrat d'infogérance.

L'installation de la distribution passe par la définition d'un “master” c'est à dire la liste des paquetages à installer pour la distribution standard. De façon opérationnelle, idéalement, l'utilisateur démarre avec un CD ou une clef “bootable” puis l'installation se fait par le réseau (ainsi Anaconda/Kickstart pour par exemple CentOS). Les mises à jour “lourdes” (changement de version) peuvent aussi se faire par le réseau.

L'organisme peut conserver un miroir des dépots logiciels correspondant à une distribution la façon de les utiliser ensuite cela dépend du “niveau de service” proposé ou imposé aux utilisateurs.

La politique peut être de laisser l'utilisateur indépendant avec le risque d'avoir un parc “obsolète” ou d'imposer les mises à jour (au moins dans le cadre d'une distribution donnée) dans ce dernier cas les mises à jour peuvent être “poussés” sur les postes en co-gestion.

Un autre problème est de basculer périodiquement sur des versions maintenues par l'éditeur (si possibles des Long Time.. LTS comme chez Ubuntu…).

Bref question: jusqu'à quelle point la politique standard doit imposer les évolutions aux utilisateurs. Le choix des releases pouvant être imposé par les applications extérieures.

D'autres outils plus généraux comme Puppet peuvent être utilisés pour gérer la cohérence des postes installés

l'idéal est d'avoir bien sûr une souche unique pour les postes de travail (fussent-ils bureautique), les clusters et les serveurs voire les super-calculateurs, d'où l'intérêt de, par exemple, de Debian ou de (la convergence) CentOS/Fedora/RedHat.

Une distribution “maison” permet bien sûr d'aller beaucoup plus loin en travaillant, par exemple, sur les drivers pour intégrer tous les types de matériels utilisés dans l'organisme (notamment les portables) et de pousser beaucoup plus loin l'intégration au SI.

- Choix du socle : Nous nous sommes tournés vers CentOS, un clone de Red Hat, pour les postes de travail. Les serveurs d'applications des départements de recherche étaient déjà sous Red Hat, et CentOS nous permettait d'avoir un socle d'applications commun pour tous les moyens informatiques. De plus, pour les problèmes d'utilisation de certains logiciels métier comme Tecplot, Matlab ou autre, Red Hat est certifié par les éditeurs. Nous pouvons ainsi reproduire les problèmes rencontrés par les utilisateurs sur les postes CentOS sur les serveurs départementaux en RHEL.

- Choix de la déclinaison : Nous avons choisi Gnome par défaut, que nous entretenons (menu d'applications, fond d'écrans…).

- Choix du contenu : L'installation de la distribution est quasiment par défaut pour le choix des paquets installés. Nous ajoutons également des logiciels depuis des dépôts tiers (rpmforge, atrpms) comme les codecs de lecture de vidéo/musique par exemple. Ces dépôts sont synchronisés en interne toutes les nuits.

- Choix de personnalisation : Nous “packageons” l'ensemble des logiciels utilisés à l'Onera sous Linux sous forme de rpm. Ces logiciels sont ensuite stockés dans des dépôts internes. Tous les postes y sont inscrits ainsi que les serveurs de départements sous RHEL (rpm communs pour tous les moyens informatiques). L'installation des logiciels est réalisée avec des notions de dépendances, c'est-à-dire que pour un département X, on installe le rpm soft-X qui fait un “require” de tous les logiciels du départements (payants). On installe également le rpm soft-commun qui lui nécessite l'ensemble des logiciels libres ou gratuits que nous entretenons sur le socle.

- Choix du mode d'installation : Nous utilisons les mécanismes de Red Hat (kickstart) pour réaliser toute la personnalisation des postes à l'installation. Une évolution future sera peut être de monter un serveur de configuration (pour l'instant, les fichiers de conf sont recopiés pendant l'installation).

- Choix des possibilités de mises à jour : Les logiciels sont mis à jour dans les dépôts internes. Un nouveau logiciel sera simplement inclus dans la liste des logiciels requis par les rpm soft-* décrits plus haut. Les PC sous Linux sont réveillés par “wake-on-lan” le matin à 5h30. De là ils réalisent leurs tâches d'exploitation : recopie du premier disque sur le second pour les données locales au PC (les fichiers les plus importants sont dans le home des utilisateurs, monté par NFS) et réalise une mise à jour du système (“yum update”). Ils récupèrent ainsi toutes les mises à jour système et logiciels internes.

- Choix du niveau de service : Nous avons choisi de ne pas partager l'administration des postes avec les utilisateurs : soit le poste est administré par la direction informatique de l'Onera, soit il est donné vierge à l'utilisateur qui pourra choisir sa distribution mais ne profitera pas du SI Onera (serveurs de fichiers NFS, personnalisation, mises à jour…).

Nous avons à ce jour 400 postes administrés par la direction informatique.

- Choix du “socle” (distribution) Nous avons fait le choix d'un socle de distribution proche pour les serveurs et les postes de travail (desktop et laptop) : Red Hat, CentOS pour les clusters/serveurs et Fedora pour les postes de travail. L'intérêt d'un socle commun est pour nous administrateur d'avoir un environnement d'administration système proche et de mutualiser nos outils d'atelier Linux et pour l'utilisateur d'avoir un environnement Linux relativement homogène entre son poste de travail et ses serveurs et les clusters. Nous avons par le passé (avant 2004) géré une distribution “customisée” basée sur Red Hat (ce qui explique que nous avons continué) complétement géré par les MI mais avant abandonnés car trop contraignant en terme de maintenance Le parc de Sophia en Linux est d'environ 100 serveurs / cluster et 450 postes de travail Linux. Le poste de travail est utilisé comme poste bureautique et/ou poste de calcul. Nous incitons nos utilisateurs à utiliser les ressouces de calcul mutualisées proposées (cluster) plutôt que des stations de travail lorsque c'est possible. Nous disposons à Sophia d'une infrastructure de virtualisation VMware et déployons désormais la totalité de nos serveurs sur cette infra. Ces serveurs sont soit des serveurs pour les services d'infra réseau et du SI mais aussi pour des serveurs des équipes de recherche pour leur besoins propres)

- Choix de la déclinaison Fedora fournit plusieurs environnements de bureau et les nombreux outils associés (KDE, Gnome, etc…) et nous laissons le choix à l'utilisateur en installant l'ensemble proposé. En conséquence, nous ne customisons pas les evironnements de bureau. Nos utilisateurs se débrouillent (existence d'un forum interne d'entraide Linux qui vient compléter les documents disponibles sur Internet)

- Choix du contenu Nous installons une grosse partie de la distribution (utilisation des profiles Fedora type “poste de travail”) pour bénéficier de sa richesse (notamment les logiciels scientifiques). Nous y ajoutons le dépôt RPMfusion qui fournit le complément à Fedora en terme de soft, driver (nvidia) et codec. Nous avons installé un serveur miroir interne des ces dépôts (centos, fedora, rpmfusion).

- Choix d'intégration, choix de personnalisation Nous customisons quelque peu la distribution pour l'intégrer dans notre réseau et notre SI : adéquation avec profils réseau et vpn, sauvegarde des fichiers, impression, utilisation des dépôts internes, sonde d'inventaire GLPI…. Nous y rajoutons quelques logiciels à “licence” que nous packageons et distribuons selon les cas : maple, matlab…. Nous avons également intégré à notre atelier Linux la notion de dépôts de packages par “équipes de recherche” intégrés à notre serveur miroir qui permet à un correspondant technique d'une équipe de recherche de gérer une liste de packages supplémentaires à mettre en place à l'installation soit fournis dans la distribution, soit fabriqués par lui.

- Politique et modèle économique, choix des possibilités de mises à jour, choix du niveau de service aux utilisateurs: L'achat des postes, l'installation, le support sont entièrement géré en interne par le service informatique Trois catégories de niveau de service :

1. Machine autonome : machine non installée et administrée par nous
2. Machine co-gérée : l'utilisateur a un compte “root” mais le service informatique garde la main sur la machine via un clé SSH “root” pour accès distant et un sonde d'inventaire GLPI
3. Machine gérée : l'utilisateur n'a pas de compte root (*)

(*) chaque équipe dispose d'un correspondant technique qui est un chercheur permanent, qui dispose d'un accès root sur les machines de son équipe Le service informatique ne pilote pas les mises à jour de sécurité ni les upgrades de version de Linux. C'est une action à l'initiative de l'utilisateur s'il est root ou du correspondant technique de l'équipe de recherche qui gère son parc d'équipe. L'idée est de laisser l'utilisateur et/ou le correspondant technique maître du choix de niveau de version et d'homogénéité de son parc Linux. Nous avons établi un contrat de support matériel et logiciel qui engage mutuellement utilisateur et service informatique. Il indique précisément quel service est fourni à utilisateur suivant la catégorie. Par exemple pour un poste cogéré, si l'utilisateur l'a “cassé”, on regarde pas trop longtemps si on peut réparer, sinon on réinstalle… Par exemple pour un poste autonome, si l'utilisateur n'a pas la possibilité d'accéder aux postes de travail en NFS (v3) Cette “libéralisation” du poste de travail est possible du fait de l'architecture de sécurité du site. Les postes de travail sont dans une Zone dédiée (Vlan), les serveurs hébergés sont dans des Zones (Vlan) dédiés à chaque équipe, voire chaque expérimentation ce qui garantie un cloisement entre les machines. Certains utilisateurs installent sur leur poste un soft de virtualisation (Virtualbox, VMware) qui leur permet d'installer un autre OS pour des besoins de portage ou d'outil logiciels (exemple MS Project) Nous avons également quelques installation en dual boot Linux Windows. C'est le cas des équipes qui ont des machines d'avances pour les stagiaires et autres personnels temporaires. Nous proposons pour ceux qui le demandent un service de sauvegarde des fichiers utilisateurs locaux au poste de travail (homedir local) basé sur un outil maison qui utilise rsync + ssh et un espace de stockage cible sur un serveur NAS NetApp (200 clients sauvegardés).

- Choix du mode d'installation: Nous utilisons la méthode de déploiement de Red Hat/CentOS/Fedora basée sur Anaconda/kickstart et le mécanisme de gestion de package YUM. Nous avons un “atelier” qui repose sur notre serveur de miroir et de repositoiries locaux, des profils d'installation (poste de travail, serveur etc….) et des scripts shell de pre et post installation. Nous avons également un script spécifique pour gérer les upgrades Fedora (adapté de la procédure proposée par Fedora) Nous installons les machines via le réseau :

• Dans le cas d'une installation “from scrach”, nous bootons sur un CD/USB de boot puis lançons l'installation réseau
• Dans le cas d'un upgrade, tout se passe via le réseau.

Nous utilisons Puppet uniquement pour gérer les configurations de nos serveurs Moyens info, pas pour les postes. Nous utilisons le produit GLPI pour l'inventaire de notre parc matériel.

- Choix de l'orientation: Nous cherchons à maintenir cette souche unique quelque soit le type de poste : bureautique, scientifique, cluster, serveur. Malgré la possibilité offerte désormais de gérer son propre OS, nos utilisateurs préfèrent une installation par nos soins et le mode cogéré (90% des postes dans ce mode !)