Ceci est une ancienne révision du document !


Atelier Linux Poste de Travail

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

Contact: Philippe.d-Anfray@cea.fr

Points abordés

Choix du "socle" (distribution)

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 (CEA), il est difficile d'envisager de soutenir une distribution unique. Au moins Debian, CentOS, Ubuntu, Mandriva sont utilisés à une échelle assez large dans les différents départements.

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 ?

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

Choix de la déclinaison

  • ce “socle” inclut-il le gestionnaire de fenêtres, c'est à dire le bureau et en fait de nombreux outils associés (KDE, Gnome, etc…)
  • ce “socle” inclut-il plusieurs gestionnaires de fenêtres ?
  • est-ce que l'évolution vers des environnements “pour tablette” de certaine distribution est un problème ?

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

Choix du contenu

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

Choix d'intégration

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, environnement réseau, ressources partagées (serveurs, fichiers, imprimantes..) et outils de mobilité (VPN, …).

Choix de personnalisation

L'organisme peut proposer des logiciels métier “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”.

Politique et modèle économique

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.

Une autre façon de faire consiste à 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…

Choix du mode d'installation

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.

Choix des possibilités de mises à jour

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.

Choix du niveau de service 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.

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

Choix de l'orientation

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

Témoignage ONERA (David Denis)

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

Témoignage INRIA Sophia (Laurent Mirtain)

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

public/atelierlinux.1329749381.txt.gz · Dernière modification: 2012/11/21 12:51 (modification externe)
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0