Archive:Fr FR/StatelessLinux

From FedoraProject

Revision as of 21:01, 16 February 2010 by Mrtom (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Important.png
Old page
This page has been marked as "old", and likely contains content that is irrelevant or incorrect. If you can, please update this page. This page will be deleted if action is not taken.
= Stateless Linux =

Traduite de la page originale StatelessLinux

Le projet Linux Stateless est une technologie au coeur de l'OS permettant aux ordinateurs sous Fedora d'être configurés comme des appareils remplaçables à souhait sans que leur configuration n'importe.

Par exemple, un administrateur système peut configurer un réseau de centaines de machines de bureau, clientes, comme clônes du système maître, et peut s'assurer de leur synchronisation, quelque soit l'état du système maître. Nous proposons plusieurs technologies autour des ces fonctions.


Contents

Mailing Lists

Vous pouvez discuter de Linux Stateless sur stateless-list . On en discute aussi sur fedora-devel-list .

Utilisation

Pour FC6, nous nous concentrons sur les utilisations de StatelessLinux pour:

1. Serveurs virtuels: démarrés et exécutés entièrement à partir du réseau ou d'un SAN, sans aucun stockage local nécessaire.

1. Bureaux d'entreprise avec stockage local: les images Stateless sont synchronisées avec le disque local et exécutées de là. Cela inclue les stations de travail (partition swap locale, répertoire racine en lecture-seule synchronisé avec le disque local, et dossiers personnels sur le réseau), et les portables (partition swap locale, répertoire racine en lecture-seule synchronisé avec le disque local, dossiers personnels locaux qui doivent être synchronisés avec un stockage réseau pour les sauvegardes).

Travaux en cours

1. Système de fichier racine en lecture-seule.

Les versions précédentes du logiciel Stateless utilisaient plusieurs patchs pour que le système fonctionne avec un répertoire racine en lecture seule, et plusieurs utilisateurs modifiaient ces patchs selon leurs besoins.

Cette fonctionnalité doit être intégrée à la base du système d'exploitation, pour qu'il y ait une façon simple de démarrer en lecture-seule, et que les utilisateurs de cette technologie n'aient pas besoin de s'inquiêter à propos de ces détails.

Le support du système de fichier racine en lecture seule est dans initscripts, à partir de la verion 8.33-1.

Il faut donc que soient accomplies les tâches suivantes:

  • Intégrer la reconnaissance d'un système de fichier racine en lecture-seule à la base du système d'exploitation [FAIT]
  • Rechercher les options concernant le stockage temporaire (/tmp, /var)
  • via tmpfs, dont le contenu copié au démarrage - la solution de contournement [FAIT]
  • Déterminer quelles applications ont besoin de corrections pour fonctionner avec un répertoire racine en lecture seule, et les corriger

Pour parvenir à cela, un script d'audit/enregistrement a été écrit, qui peut être exécuté à n'importe quel démarrage normal, pour observer les applications qui essaient d'écrire sur le système de fichier racine. [FAIT] Ce code est actuellement disponible à http://people.redhat.com/notting/rolo/

  • S'assurer que tout le matériel est configuré correctement dès le démarrage, sans configuration pré-existante.

1. Le support pour exécuter un système racine synchronisé par le réseau se fait via un analyseur de périphériques (device-mapper). Cf. StatelessLinuxCachedClient (en) 1. rsync (ou un rsync-like) du stockage local (/home) sur un serveur centralisé, pour les sauvegardes. Pour le cas des ordinateurs portables (et éventuellement des ordinateurs de bureau), les utilisateurs auront un stockage local pour leur répertoire personnel et les données similaires.

Il faudra sauvegarder ces données sur un stockage réseau (soit NFS, iCSI, ou autre). De plus, il faudra aussi intégrer la possibilité de récupérer ces données sur la machine lors d'une installation initiale (lors du remplacement d'une machine défaillante).

1. Démarrage par le réseau, fichiers sur le réseau

Pour le cas de serveurs virtuels, il faut intégrer la possibilité de démarrer depuis le réseau, et d'utiliser un système de fichier par le réseau en tant que répertoire racine.

Les premiers objectifs sont:

  • NFS [FAIT]
  • iSCSI
  • NBD (éventuellement)
  • NFS loopback (éventuellement)

Les autres systèmes de fichiers réseau pourront être étudiés s'ils peuvent être ajoutés proprement au démarrage.

A faire pour cela:

  • Ajouter le support du démarrage par le réseau au mkinitrd, ou écrire de nouveaux scripts pour créer une image ramfs personnalisée qui contient les outils actuels (et libc, etc.)
  • Ajouter le support pour utiliser le stockage local en tant que périphérique cachefs
  • Ajouter le support pour swapper sur le stockage local. La swap à partir du réseau ne devrait pas être intégré.
Note.png
Dépendances
Cela requiert que le travail soit fait pour l'installeur et ce qui concerne le stockage; iSCSI a surtout besoin d'un travail qui n'est pas encore fait.

Des exemples simples vont être faits pour configurer un serveur PXE pour distribuer ces images stateless; la façon la plus simple est de la distribuer en fonction de l'adresse MAC du serveur qui demande l'image.

Stop (medium size).png
Complications avec Xen
Il faut trouver un moyen pour démarrer des images via le réseau avec Xen. Une solution simple est d'avoir les mêmes images qui sont utilisées pour PXE (pour le cas sans Xen), les images PXE-type monté sur le dom0, et de les distribuer aux domU de cette façon. La combinaison iSCSI/Xen doit aussi être étudiée.
Stop (medium size).png
Complications liées à la gestion
Il faut trouver des moyens de modifier les images réseau sans affecter les clients existants.

1. Support du LiveCD

L'utilisation de LiveCD est une bonne façon de tester le modèle Stateless. Nous voulons que le code du LiveCD intègre le support du répertoire racine en lecture-seule dès que possible, et utiliser cela comme une base pour les tests.

D'autres améliorations peuvent être l'utilisation de clés USB et de périphériques similaires pour le stockage des documents quand ils sont utilisés avec les LiveCDs et lors de déploiements similaires.

La sauvegarde via des systèmes rsync-like, le démarrage et racine par le réseau, et les LiveCDs sont prévus une fois que le code initial du répertoire racine lecture-seule aura été terminé.

Ce qui n'est pas prévu

Choses que nous ne visons pas:

  • Création d'outils de configuration et de gestion des images
  • Changements pour les applications de configuration des mécanismes pour obtenir les données de configuration (comme changer l'application de configuration d'images locales pour un système avec LDAP)
  • Des outils spécifiques à Stateless.

Si nous voulions faire cela, le code serait:

  • sûrement fait trop rapidement et ne serait pas complet, dans le temps imparti par la sortie de FC6
  • ne fonctionnerait pas avec les systèmes de gestion actuels ou futurs sans modifications
  • ne s'intègrerait pas bien avec les systèmes de gestion des utilisateurs

Ainsi, cet espace est laissé au développement dans le contexte de futurs systèmes de gestion. Ce sur quoi nous concentrons nos efforts pour FC6 est l'infrastruture de base.

FAQs

1. Comment puis-je faire pour que mon application fonctionne avec stateless ?


Généralement, si elle n'écrit pas sur le système de fichier racine, elle devrait passer sans aucun problème. Pour la configuration, nous nous basons sur les images sources brutes elles-mêmes (soit via chroot, soit en démarrant l'image par Xen, soit par d'autres méthodes); cela implique que les fichiers de configuration soient bons, tant que vous n'exigez pas que le système client écrive sur lui-même.

1. Quelles architectures sont visées par stateless ?

  • Déjà: x86, x86_64
  • Autre architecture, si le temps le permet: ppc

Problèmes qui compliquent le support de l'architecture PPC:

  • Xen - Xen ne supporte pas PPC
  • Démarrage par le réseau - PPC ne peut pas être démarré par le réseau différemment

Le support pour le démarrage réseau avec EFI pour x86/x86_64 sera peut-être aussi retardé.

L'architecture du serveur peut poser problème seulement si vous modifiez les images stateless i386, par exemple, soit par chroot, soit par Xen. Il faudra que vous le fassiez depuis une architecture qui peut exécuter des binaires i386.

1. Comment stateless interagit avec SELinux ?

SELinux devrait fonctionner sans modifications importantes, une fois que le système de fichier sous-jacent le supporte. (Actuellement, ce n'est pas le cas pour NFS ou pour les différents systèmes de fichiers utilisés par les LiveCDs.)

1. Y aura-t-il une documentation ?

Alors que ça n'est pas actuellement spécifiquement demandé, une sorte de livre blanc ou un document au contenu similaire, qui explique les bases du fonctionnement, et comment stateless pourrait être déployé serait utile.


Autres informations

  • Notre vision

Document de présentation (en) au format PDF.

  • Installer Linux Stateless

Les instructions d'installation du serveur Linux Stateless avec les différents types de clients sont disponibles ici (en). Vous trouverez également un guide à l'adresse http://people.redhat.com/dmalcolm/stateless/stateless-linux-HOWTO-en/ (en).