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” intégré au SI et un autre pour développer

Choix du mode d'installation

  • fabrication d'un master
  • installation par le réseau
  • dépôts logiciels “maison”
  • utilisation systématique de machines virtuelles

Choix des possibilités de mises à jour

  • mise à jour du master
  • intervention sur les postes
  • dépôts logiciels “maison”

Choix du niveau de service aux utilisateurs

  • utilisateur indépendant (mise à jour/installation sur son poste possible) ⇒ quel service peut être assure ?
  • utilisateur dépendant ⇒ comment être réactif vis-à-vis des demandes d'évolution du poste ?
  • choix mixte ?
  • ..

Choix de l'orientation

  • une souche “calcul” et une souche “poste de travail” / une souche commune
  • utilisation de la même souche sur les serveurs ?

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.

public/atelierlinux.1329747822.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