Kernel Traffic #239 For 1 Nov 2003

Nous sommes fiers d'annoncer la disponibilité d'un système de fichiers _modèle de démonstration_, appelé srfs. ( http://www.cs.bgu.ac.il/~srfs/ ). une brève présentation: [page d'accueil]

srfs est une système de fichiers global destiné a être distribué géographiquement sur des locations diverses. Il fournit une infrastructure, durable et de haute disponibilité pour les données.

Commencé comme un projet de recherche en systèmes de fichiers et auto-stabilisation dans le département Negev d'informatique de l'université Ben Gourion, le projet vise a intégrer des méthodes et des algorithmes d'auto-stabilisation dans le système de fichiers et ses opérations afin d'offrir un système ayant le comportement souhaité alors que surviennent des erreurs transitoires.

Basé sur des couches d'algorithmes auto-stabilisants, il fournit un structure de réplication d'arbres basé sur la découverte automatisée de serveurs en utilisant un multicast IP local et global. La structure d'arbre fournit l'infrastructure de commande et de temps, requis pour un nouveau système de fichiers.

Le projet est divisé en deux composants:

1. Un module noyau, qui fournit les fonctionnalités de bas niveau et de gestion du disque.
2. Un daemon espace utilisateur de cache, qui fourni les propriétés de stabilisation et de réplication du système de fichiers.

Ces deux composants communiquent via un périphérique caractère.

Plus d'information sur l'architecture du système est disponible sur la page web et ici:http://www.cs.bgu.ac.il/~tzachar/srfs.pdf

Nous espérons que certains trouveront cela suffisamment intéressant pour se lancer dans un essai et qu'ils ne trouveront pas les temps de latence trop rédhibitoires (actuellement, le daemon de cache est un peu lent. Nous espérons l'améliorer dans le futur) De tout façon, soyez conscients que c'est une version extrêmement jeune qui ne fait que marcher et garder les propriétés de stabilisation, pas de compatibilité posix ou quoi que ce soit...

Supposez que j'installe srfs sur mon portable et mon serveur. Je déplace alors le repositoire CVS de mon projet favori sur le nouveau système de fichiers srfs. et je m'en vais pour la fin de semaine avec mon portable. Pendant la fin de semaine, je committe divers changements sur le fichier X. Pendant la fin de semaine, mon ami committe lui aussi des changements sur le fichier X.

Lorsque je reviens à la maison et que je branche mon portable, le daemon de cache va probablement tenter de stabiliser les système de fichiers en décidant quelle version du fichier X a été changée en dernier et va dupliquer cette version.

Quel est le travail que le daemon de cache va écraser? Mon travail ou celui de mon ami?

Bien sur, il n'y a pas besoin d'avoir des temps aussi longs que des journées de déconnections et d'opérations indépendantes. Un router qui reboote entre deux hôtes srfs préalablement synchronisés semble suffisant pour déclencher ce genre de perte de données, à moins que vous ne fassiez échouer toutes les écritures lorsque vous êtes déconnecté.

je veux m'excuser si mon explication n'était pas assez claire: l'auto-stabilisation (originellement une idée de Dijkstra) - Un système auto-stabilisant est un système qui peut réparer automatiquement la survenue d'erreurs (transitoires). L'idée est de concevoir un système qui peut être démarré dans un état arbitraire et converger vers le comportement désiré.

Notre système de fichiers se comporte de la façon suivante : disons que vous avez divers systèmes avec divers systèmes de fichiers dessus. Si (et quand...) vous connectez ces systèmes de fichiers dans un cadre srfs, tous les serveurs vont afficher le même système de fichiers, ce qui est une sorte d'union entre tous. si vous voulez parler en termes coda, vous pouvez imaginer que tous les serveurs opéraient de manière indépendante et qu'ils ont été connectés en même temps. le mécanisme de résolution de conflit que nous utilisons est la majorité.

Nous différons dans coda dans le sens où nous n'avons pas de serveur principal, ce qui pousse les Volumes sur les sous-serveurs (je ne connais pas la terminologie exacte), et le données sont servies en load-balancing. Dans Srfs, toutes les données résident sur les serveurs (hôtes) et est répliquée entre eux. la réplication a lieu à deux niveaux : la vue de l'arbre (plus les meta données) et les données elles-mêmes.

• la vue de l'arbre - la vue de l'arbre est la même sur tous les hôtes. un `ls` sur un répertoires produira le même résultat sur tous les hôtes.
• données - les données seront dupliquées sur tous les hôtes lors de chaque écriture réussie et lors de chaque accès à un fichier sale sur chaque hôte.

toute la réplication est paresseuse, et n'arrive que lors de l'accès aux répertoires / fichiers (lors d'écritures réussies - quand le fichier est fermé).

Ainsi, le comportement suivant peut être atteint: disons que vous avez 2N+1 hôtes, tous avec des systèmes de fichiers cohérents. maintenant, débranchons N hôtes, changeons l'arbre et mettons ces hôtes de nouveau sur le réseau, leur arbre sera le même que les N+1 autres hôtes.

Le but principal du système de fichiers est l'auto-stabilisation, sur de longues périodes de temps et sur de grandes distances. vous pouvez l'utiliser comme un SAN ou comme une ferme de données, en utilisant un système comme LinuxVirtualServer pour répartir la charge entre les différents noeuds.

J'ai écrit un simple wrapper setuid-root qui donne certaines capacités, abandonne tous les autres privilèges, puis exec un shell. J'espérais utiliser ce wrapper comme un shell de login, j'aurais pu ainsi permettre à un utilisateur de se logger avec un petit sous-ensemble de privilèges élevés.

Malheureusement, après avoir vu le code de capacités dans le kernel 2.4, on dirait que ce n'est pas possible actuellement, et que mon wrapper ne fonctionnerait pas sans le support des capacités par le système de fichiers. Et quand bien même, je devrais mettre le drapeau d'héritage sur tous les fichiers que je voudrais lancer, y compris le shell. Est-ce que j'ai raté quelque chose ou ma description correspond à ce qui se passe?

Je pense comprendre le raisonnement derrière ce comportement; le draft de la spécification posix 1003.1e dit:

Assigner des états de capacité à des fichiers à pour but de fournir à la fonction exec() des informations concernant les capacités que chaque image de processus crée avec le programme dans le fichier est autorisée à manipuler et fournies par une autorité.

Donc, l'absence de drapeau d'héritage sur un fichier peut empêcher ce fichier de s'exécuter avec la capacité correspondante active.

Bien, mais que dire de mon shell semi-super-utilisateur? Comment forcer la persistance d'un groupe de capacités a travers un exec() pour tous les exécutables? Il semblerait que ni la spec ni implémentation actuelle dans le kernel 2.4 ne permettent ceci, bien que ça m'apparaisse comme une chose raisonnable et utile pour certains cas.

Comme solution temporaire, pourquoi ne pas faire comme si toutes les capacités étaient héritables dans fs/exec.x:prepare_binprm, c'est à dire, à la place de cap_clear(bprm->cap_inheritable), appeler cap_set_full() ??? Je ne pense pas que cela affecterait quoi que ce soit mais cela rendrait les capacités plus utiles jusqu'à ce que nous ayons le support dans le système de fichiers.

Les gens qui ont écrit le code ont travaillé sur deux différentes versions de la spec. Je crois que certaines personnes on utilisé le draft 16, tandis que d'autres utilisaient le draft 17. (ou 15 et 16, ou 17 et 18 -- une différence de 1) Pendant ces deux drafts, il y a eu de GROS changements. Enfin, un équation critique changea.

Les gens de SGI, clônant le code IRIX sans réfléchir, nous fourni la moitié implémentation des bits de capacité que nous avons aujourd'hui. Ils ont ignoré implémentation DG-UX qui utilise 256 bits et des équations quelque peu différentes. Ils ont ignoré le fait que le modèle de sécurité sera bien peu consistant si vous avez toujours des applications prenant des décisions basées sur l'UID -- cela veut dire que vous devez allouer des bits pour la glibc, XFree86, les distributions Linux, outils d'admin, diverses bases de données et l'usage local. Oui c'est bizarre, mais c'est obligatoire. Se boucher les oreilles et s'enterrer la tête ne fera pas disparaître le problème.

Personne ne pensait avec la moitié des bits à "on" par défaut pour les choses actuellement autorisées à l'utilisateur normal. Par exemple le droit d'attendre des connections réseau pourrait être limité si on avait alloué un bit mis par défaut.

IL y aussi le bidouillage d'urgence fait pour boucher un trou de sécurité qui les bits de capacité avaient introduit. Je crois que c'était dans les premiers jours du 2.4.x.

Les gens préfèrent ignorer le fait que les applications ont tendance à répondre "Ais-je besoin de précautions du style setuid" en examinant l'UID.

Les gens préfèrent ignorer que le code privilégié, écrit avec setuid en-tête, peut conduire à toutes sortes de problèmes si 42% des opérations privilégiées sont interdites. Ouais, vous espéreriez que toute application setuid a une bonne gestion d'erreurs et pourrait s'en sortir ... mais l'espoir ne devrait pas vous satisfaire. Nous avons réellement besoin d'un moyen, pour les développeurs d'applications, de marquer un binaire comme "bloque les droits P, Q et R" et "bloque tous les droits sauf si on reçoit V, W, X", en supposant qu'une application non marquée a une situation tout ou rien.

Il devrait probablement y avoir deux mondes dans le système. Les applications avec des droits "étranges" devraient être écartées de l'UID 0 et des applications setuid, tandis que les applications avec UID 0 et setuid devraient être mises à l'écart des droits "étranges". Donnons au processus init le droit de passer d'un monde à l'autre.

Les auteurs de notre code semblent avoir abandonné et volé vers d'autres cieux. Personne n'a rangé le fatras. Est-ce un miracle si le draft POSIX n'a jamais dépassé l'état de draft?

(Et merde, est-ce que !capable(...) peut vous dire que vous avez le droit d'effectuer cette action?)

Et l'horreur finale : imaginez que vous essayez d'écrire une documentation correcte pour l'admin moyen. Les mécanismes de sécurité mal compris sont un danger. D'ailleurs, n'oubliez pas de documenter toutes les interactions avec les UID, systèmes de fichiers, etc...

Regardons les choses en face: les admins vont penser en termes de fournir des droits aux utilisateurs, sans jamais penser qu'il y a des équations bizarres, des interactions avec les UID et peut-être même des bits par exécutable.

De manière générale, nous évoluons vers une version de BK où les clés (révisions internes, un peu comme les id de mails) sont utilisables là où une rev est utilisable.

Un cas où nous utiliserons cela est dans BK/Web comme ça vous pourrez avoir des URLs qui ne changent pas dans votre dos.

Nous corrigerons cela en même temps que nous mettrons en marche le serveur de patches GNU : vous pourrez avoir n'importe quel changeset comme un patch. Les double T1 devraient être disponibles à la fin du mois.

Il pourrait y avoir un peu de retard, j'ai des affaires familiales qui ont une plus grande priorité que cela, mais je vais essayer d'avoir quelqu'un d'autre pour le faire si ça prend plus longtemps que la fin du mois avant que je ne revienne.

Ce patch met à jour UML pour 2.6.0-test8.

Le patch pour UML 2.6.0-test5 est disponible sur
http://jdike.stearns.org/mirror/uml-patch-2.6.0-test8.bz2

Les utilisateurs de BK peuvent utiliser mon repositoire 2.5 sur :
http://jdike.stearns.org:5000/uml-2.5

Pour d'autres miroirs et d'autres téléchargements, voir:
http://user-mode-linux.sourceforge.net/dl-sf.html

D'autres liens:

La page d'accueil du projet UML : http://user-mode-linux.sourceforge.net
Le site de la communauté UML : http://usermodelinux.org

Cette version sort avant une discussion là dessus dans la rencontre CGL demain à OSDL

J'ai sorti la version 005 d'udev, Elle est disponible sur:
kernel.org/pub/linux/utils/kernel/hotplug/udev-005.tar.gz

Les rpms sont disponibles sur:
kernel.org/pub/linux/utils/kernel/hotplug/udev-005-1.i386.rpm
avec le rpm source sur:
kernel.org/pub/linux/utils/kernel/hotplug/udev-005-1.src.rpm

udev est une implémentation de devfs en système utilisateur, utilisant sysfs et /sbin/hotplug. Il nécessite un kernel 2.6 pour tourner correctement.

Les changements les plus importants depuis la version 004 sont:

• la klibc est désormais inclue dans le tarball udev. Si vous voulez compiler udev avec klibc, lisez le README pour les instructions.
• LABEL pour le lien symbolique vers le périphérique marche de nouveau.
• Si le fichier 'dev' n'est pas présent (comme quand le périphérique est retiré avant que udev n'y jette un coup d'oeil), udev fera un timeout normalement.
• Les fichiers namedev.permission et namedev.config sont renommés en udev.permission et udev.config. Soyez sur d'avoir pris cela en compte si vous avez fait des modifications dans le passé.
• Mises à jour du fichier man.

Le plus gros truc, c'est l'intégration de la klibc. Si vous compilez avec klibc, le binaire de 453K se réduit à 45K. Rien n'est mieux qu'une diminution de la puissance de dix :)

Les rpms sont compilés avec le deboguage activé, utilisant glibc, il n'ont pas de diminution de taille pour l'instant...

Encore, merci beaucoup à Dan Stekloff, Kay Sievers et Robert Love pour leur aide sous forme de patches pour cette version, j'apprécie vraiment

Le ChangeLog complet est disponible ci-dessous.

La FAQ udev est disponible sur:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

Le développement d'udev est fait sur un arbre BitKeeper disponible sur:
bk://kernel.bkbits.net/gregkh/udev/

Il y a le travail initial de quelques tests de régression dans l'arbre bk, mais il y a un bogue dans libsysfs qui empêche ces tests de marcher correctement à l'heure actuelle. Les gens de la libsysfs travaillent à corriger cela.

Si quelqu'un voulait un extrait de l'arbre actuel, pour ne pas utiliser BitKeeper, ou d'autres raisons, c'est toujours disponible de tout temps en demandant.

Voici un patch pour le kernel 2.4.23-pre8 pour le driver MPT Fusion venant de LSI Logic.

Ce patch est grand, je l'ai donc placé sur le site ftp de LSI sur: ftp://ftp.lsil.com/HostAdapterDrivers/linux/Fusion-MPT/2.05.10/mptlinux-2.05.10.patch

Une nouvelle adresse mail est mise en place pour toutes les questions MPT Fusion: mpt_linux_developer@lsil.com

Je connais la politique des mises à jour, cependant le driver MPT 2.05.00.03 du kernel 2.6 n'est *PAS* compatible avec ce qui est dans le kernel 2.4 qui est le driver 2.05.05+. Nous avons abandonné la compatibilité descendante comme la vieille Gestion d'Erreurs et beaucoup d'autres changements qui le rendent incompatible avec le kernel 2.4.

Nous nous sommes concentrés sur la version 2.4 du driver puisque c'est ce qui est fourni avec toutes les distributions Linux et nos clients ont demandé à obtenir des mises à jour RPM avec les dernières mises à jour et améliorations correspondant à leur système. Un des majeurs acteurs OEM a demandé que nous mettions à jour Kernel.org afin de ne pas dépendre de LSI pour les mises à jour de drivers en RPM. J'espère que ces mises à jour feront leur chemin vers le kernel 2.4. Je commencerai à porter ces changements dans le driver 2.6 immédiatement. Une autre chose c'est que la maintenance du driver est passée de Pam Delaney à moi-même et Larry Stephens, les choses vont dont revenir à la normale.

Je suis heureux de pouvoir annoncer la première version test de l'actuelle 2.0 pre-release de Software Suspend pour 2.6. C'est aujourd'hui disponible sur: www.sourceforge.net/projects/swsusp and bk://swsusp25.bkbits.net/main.

Notes:

• Le patch a été fait avec le bk actuel. Il devrait s'appliquer à la test8 avec peu voire pas de problème.
• Est incompatible avec les actuelles implémentation de Software Suspend dans le kernel. Pardon à Patrick et Pavel. Je ne le laisserai pas longtemps dans cet état, promis!.
• Les E/S sont lentes et saccadées. Je dois enquêter encore sur la cause quelque chose dans le nouveau code n'est pas bon.

Mis a part ce que l'on voit ci-dessus, les problèmes avec le support incomplet du driver continue. En plus, vous pourrez trouver des erreurs qui gèlent la machine. Si le processus se plante lors de 'Freezing processes: Waiting for activity to finish' ou 'Syncing remainnig I/O', essayez d'appuyer sur 'Echap' une fois. Si le processus n'abandonne pas, essayez une seconde fois (qui réessaye avec plus d'insistance de redémarrer les choses). Si tout va bien, vous devriez être capable d'arrêter le suspend. Un log de ce qui n'a pas marché se trouvera dans /var/log/messages. Passez-le dans ksymoops si nécessaire et envoyez-le moi, je devrais être capable de résoudre ce problème.

Donnez-moi du retour via la mailing list Software Suspend sur Sourceforge. Voyez http://swsusp.sf.net pour les FAQ, détails de mailing list etc... Parce que le code est essentiellement le même que dans la version 2.4, beaucoup des solutions aux problèmes seront les mêmes.

Le package User-Space System Device Enumeration (uSDE) est disponible dans sa version 0.74 pour la première fois sur: http://sourceforge.net/projects/usde

uSDE propose un framework ouvert pour l'énumération (spécification) des périphériques système dans un environnement dynamique. La gestion des périphériques est implémentée via des plug-ins : les lignes de conduite (policy methods). Les règles de conduite sont libres de gérer les périphériques à leur manière, du simple au compliqué - tout, de la fourniture de noeuds périphériques LSB à la gestion persistante de noms de périphériques avec des stratégies de réallocation et de replacement.

uSDE se base sur /sbin/hotplug (pour les insertions dynamiques et les suppressions), sysfs (pour les informations sur le périphériques), et /proc (diverses informations). Il ne se base pas sur initrd - il parcourt explicitement sysfs lors du démarrage du système pour déterminer l'ensemble de périphériques initial.

Une part d'uSDE consiste en un groupe exemple de lignes de conduite.

disk-ide-policy - gère les disques IDE, EIDE, SATA et USB-EIDE. Implémente le nommage persistent de périphériques, le remplacement automatique des périphériques et la réallocations.

disk-scsi-policy - gère les disques SCSI, IEEE-1394, FibreChannel et USB-SCSI , y compris les périphériques multiport. Implémente le nommage persistent de périphériques, le remplacement automatique des périphériques et la réallocations.

multipath-policy - gère le provisionnement automatique du multipathing pour les périphériques de stockage multiport.

ethernet-policy - gère les interfaces ethernet. Implémente le nommage d'interface persistent, l'ancrage d'interface, le remplacement automatique de périphériques et la réallocation automatique des périphériques.

floppy-policy - gère les lecteurs de disquettes internes.

simple-device-policy - une ligne de conduite "prend tout" pour les périphériques de block et caractère.

devfs-policy - fournit des noms de périphériques à la devfs.

lsb-policy - fournit des noms de périphériques LSB.

Se trouve sur: http://sourceforge.net/projects/usde
Mailing list: usde-general@lists.sourceforge.net

Quelle est la relation d'uSDE avec udev? Vous ne le mentionnez pas, dans votre mail bien que celui-ci prétende implémenter des fonctionnalités similaires voire identiques. Y a-t-il une relation? Est-ce basé dessus?

Si non, prévoyez vous de joindre vos efforts avec udev dans le futur?

Utilisez vous la librairie libsysfs pour accéder aux données sysfs? Si non, je vous le recommande vivement.

Je vous recommanderais également d'envoyer un mail à la liste linux-hotplug, puisque la plus part des applications ayant à voir avec hotplug sont discutées et développées via cette liste.

uSDE n'est pas construit au dessus d'udev.

uSDE et udev sont similaires dans bien des aspects. Les deux créent des noeuds de périphériques. Mail il y a plus dans la gestion de périphériques que de gérer des noeuds de périphériques.

Les quelques différences qui viennent à l'esprit entre uSDE et udev alors que je tape (une bonne partie de ceci se trouve dans INTRO dans le tarball uSDE):

Les périphériques sont classés une liste explicite et ordonnées de lignes de conduites sont invoquées de la part des périphériques en se basant sur cette classification.

Les lignes de conduites sont implémentées comme des plug-ins ouverts qui ont le contrôle complet (c'est à dire le nommage, la configuration, les besoins spécifiques) du périphérique.

De multiples lignes de conduites peuvent être exécutées de manière concurrente, elles peuvent être indépendantes ou coopératives.

Tous les types de périphériques sont traités - ethernet, disques, cdroms, disquettes, MD, LVM etc... Les lignes de conduite peuvent analyser les données et gérer des situations complexes comme l'ancrage d'une interface ethernet, la gestion de disques multiports, et la gestion de périphériques multipath.

Le concept d'agents de service qui fournit les informations critiques au framework d'énumération permettant aux lignes de conduite de gérer des situations matérielles très diverses comme des châssis multiples et l'adressage géographique.

Les lignes de conduite exemple d'uSDE implémentent des stratégies replacement et réallocation des périphériques, ce que la communauté demande depuis un certain temps.

Si vous voulez en savoir plus sur les différences, téléchargez le tarball et essayez le...

uSDE était construit en réponse à un ensemble de besoins de la communauté embarqué / télécom. Nous avons éprouvé des difficultés à exprimer nos idées. Tout le monde voulait voir le code et la documentation. Voici le code et la documentation initiale. C'est un point de départ...

Les deux packages prennent deux approches philosophiquement différentes et arrivent avec des fonctionnalités (pour la plupart) communes et d'autres non communes - après tout ils essayent tous deux de faire "la même chose". uSDE a des forces et des faiblesses tout comme udev ou tout autre programme. Il est bien sûr possible de proposer des changements (ou de faire des patches) pour udev afin d'incorporer les problèmes clé résolus dans uSDE.

uSDE encapsule des idées et des techniques. Il est suffisamment "complet" pour que ces idées soient discutées dans le cadre d'une communauté et nous pouvons envisager comment/quoi changer ensemble. Pensez-y comme "la pause du projet" à partir de laquelle nous pouvons discuter tranquillement techniques et implémentations.

Les besoins ont été réunis à partir de la spécification des besoins OSDL CGL version 1.0 et 1.1 ratifiée en septembre 2002. Ils viennent de discussions exhaustives avec les membres d'OSDL comme part de la définition de ces besoins, en les clarifiant:

• La gestion de tous les types de périphériques sans spécialisation ou limitation.
• L'habilité d'avoir le contrôle total sur la gestion du périphérique via des programmes de ligne de conduite externes. Les programmes de ligne de conduite sont invoqués avec une ligne de commande formelle et une description de l'évènement qui à causé l'invocation.
• Le concept de "service container". Un périphérique est classé (ou reconnu selon un modèle) et cela déclenche un évènement (mis en file d'attente) qui est traité par un "service container" configurable. Le container est une liste ordonnée de gestionnaires qui s'occupent du périphérique.
• Gestion de file d'attente des évènements et agrégation. Minimisant le nombre d'invocations de programme (fork/exec) est critique dans les environnements embarqués - petits processeurs.
• Énumération des périphériques agressive. Exécution multiple et concurrente des lignes de conduite.

• La persistance des informations de périphériques est une fonctionnalité des lignes de conduite, pas du framework d'énumération.

  Il y a beaucoup de situations où la persistance n'est pas un problème du tout ou juste dans des cas spécifiques (comme les disques) Pourquoi toujours payer pour la persistance à cause des disques alors que ça n'est pas (toujours) nécessaire?

• La protection transactionnelle de fichiers de configurations multiples est nécessaire. De multiples fichiers de configurations doivent souvent être modifiés à l'unisson et on doit être assuré qu'un groupe de données cohérent est utilisé lorsque l'on manipule les périphériques.