Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

Lien vers cette vue

public:atelierlinux [2012/02/08 13:03]
aristote
public:atelierlinux [2012/11/21 12:51] (Version actuelle)
Ligne 1: Ligne 1:
 +~~ODT~~
 ====== Atelier Linux Poste de Travail ====== ====== Atelier Linux Poste de Travail ======
  
-**Mercredi 8 février après-midi 14h-17h**+**Une réunion a eu lieu le mercredi 8 février après-midi**
  
 +/*
 CEA Saclay Salle visio 55c bt 474 RdC CEA Saclay Salle visio 55c bt 474 RdC
 +*/
  
-Contact: <Philippe.d-Anfray@cea.fr>+Contact: <Philippe.d-Anfray@cea.fr> 
  
-Pour venir au CEA:+/* 
 +06 86 38 49 86 
  
-  * si vous être déjà venu à Saclay, votre nom suffit +tel de la salle01 69 08 18 10
-  * si vous n'êtes jamais venu à Saclay, il faut les renseignements suivants pour établir un avis de Rendez-Vous: +
-    * Nom Prénom +
-    * Date et lieu de Naissance +
-    * Pays de Naissance et Nationalité +
-    * Adresse personnelle +
-    * Société et Fonction+
  
 Pour participer en visio, appeler notre pont public (selon votre matériel): Pour participer en visio, appeler notre pont public (selon votre matériel):
Ligne 24: Ligne 21:
  
 **Codes de la conférence 1111# pin 1111#** **Codes de la conférence 1111# pin 1111#**
 +*/
  
 +====== Pour continuer ======
  
-====== Parmi les points à aborder... ======+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, ...) 
 + 
 +====== Compte rendu de la visio du 8 février 2012 ====== 
 + 
 +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. 
  
 ===== Choix du "socle" (distribution) ===== ===== Choix du "socle" (distribution) =====
  
-  * quels arguments rationnels pour le choix du "socle ? +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). 
-  * pourquoi pas une création complètement gérée en interne ?+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 autresMais 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. 
 +   
 ===== Choix de la déclinaison ===== ===== 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, Gnomeetc...) +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.
-  * 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 ?+
  
-===== Choix du contenu =====+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. 
  
-Les paquetages de la distribution inclus "par défautdans la distribution de l'organisme+Il semble aussi que les gestionnaires de bureau "évoluéssoient gourmands en ressources notamment vis à vis des cartes graphiques  ce qui peut faire baisser les performances en visualisation des stations de travail. 
 + 
 +===== Choix du contenu =====
  
-  * **possibilités** +La tendance semble d'offrir toute la distribution à l'utilisateur. Un &quot;Master" peut contenir un choix cohérent d'outils pour un poste de travail &quot;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)
-    * toute la distribution =&gtrichesse, choix + 
-    * un sous-ensemble testé/validé/cohérent =&gtmaîtrise +
-    * ..          +
-  * ajout des outils de développement (boîte à outils de la R&D?+
  
 ===== Choix d'intégration ===== ===== Choix d'intégration =====
  
-Paquetages/logiciels "maison" à inclure dans la distribution de l'organisme (plutôt boîte à outils "fonctionnelle?)+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"
  
-  * pb: définition du périmètre, logiciels communs aux utilisateurs de l'organisme voire d'une direction,+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 
  
 ===== Choix de personnalisation ===== ===== Choix de personnalisation =====
  
-Paquetages/logiciels correspondant aux outils "métierspropres à une direction, un service... +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". 
- +
-  * pb: peut être une distribution complémentaire ???+
  
  
 ===== Politique et modèle économique ===== ===== Politique et modèle économique =====
  
-  * quelle politique vis à vis des utilisateurs (potentiels) +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:
-  * quelle intégration dans le SI +
-  * quel modèle économique (en interne/contrat extérieur/infogérant, ...)+
  
-===== Choix du mode d'installation =====+  - gestion     [par le service informatique] qui applique ses propres normes.  
 +  - 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").  
 +  - 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. 
  
-  * fabrication d'un master 
-  * installation par le réseau 
-  * dépôts logiciels "maison" 
-  * utilisation systématique de machines virtuelles 
-  * ... 
  
 +
 +===== 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 [[http://fedoraproject.org/wiki/Anaconda|Anaconda]]/[[http://fedoraproject.org/wiki/Anaconda/Kickstart|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 ===== ===== Choix des possibilités de mises à jour =====
  
-  * mise à jour du master +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 serviceproposé ou imposé aux utilisateurs. 
-  * intervention sur les postes + 
-  * dépôts logiciels "maison+
-  * ...+
  
 ===== Choix du niveau de service aux utilisateurs ===== ===== Choix du niveau de service aux utilisateurs =====
  
-  * utilisateur indépendant (mise à jour/installation sur son poste possible=&gtquel service peut être assure ? +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éedans ce dernier cas les mises à jour peuvent être &quot;poussés&quotsur les postes en co-gestion.  
-  * utilisateur dépendant =&gtcomment être réactif vis-à-vis des demandes d'évolution du poste ? + 
-  * choix mixte ? +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 [[http://projects.puppetlabs.com/projects/puppet|Puppet]] peuvent être utilisés pour gérer la cohérence des postes installés  
 +  
  
 ===== Choix de l'orientation ===== ===== Choix de l'orientation =====
  
-  * une souche "calcul" et une souche "poste de travail/ une souche commune +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. 
-  * utilisation de la même souche sur les serveurs ?+ 
 +Une distribution "maisonpermet 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. 
  
 ====== Témoignage ONERA (David Denis) ====== ====== Témoignage ONERA (David Denis) ======
Ligne 128: Ligne 168:
  
 Nous avons à ce jour 400 postes administrés par la direction informatique. 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 :
 +  - Machine autonome : machine non installée et administrée par nous
 +  - 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
 +  - 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.1328702581.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