Retrouvez cet article dans : Linux Magazine 95

Le FOSDEM avait lieu pour la 7ème année consécutive à Bruxelles, les 24 et 25 février 2007. J’y ai retrouvé un autre Mongueur de Perl, Olivier Mengué, qui a assisté à quelques conférences.

Présentations

Il y avait 11 conférences en parallèle le premier jour et 18 le second. En outre, LPI (Linux Professional Institute) a organisé des examens de certification.
" http://lpi.org/
Les présentations abordaient des thèmes variés sur de nombreux langages, des technologies multiples, et il était parfois frustrant de ne pas pouvoir développer ponctuellement des compétences en ubiquité.

Xorg Security framework

Les connexions externes sont prises en charge à l’aide des mécanismes de restriction sur l’origine des connexions (xhost) et les cookies de session xauth (pour les restrictions xhost, ça vaut ce que ça vaut, mais ça a le mérite d’exister). Pour améliorer le transport sur des réseaux non fiables, il existe une possibilité d’utiliser un tunnel SSH et une redirection de messages X11. OpenSSH fait cela très bien.
En fait, les problèmes les plus importants concernent la gestion des clients qui sont effectivement affichés dans un serveur X et des interactions entre eux.
En particulier, et concernant des applications graphiques, il est généralement préférable que les entrées d’une application ne soient pas partagées ou capturées par une autre application qui n’a pas notre confiance. On doit souvent éviter qu’une application n’en recouvre pas une autre, par exemple avec un fond transparent pour en capturer le contenu.
L’exception la plus notable est le gestionnaire de fenêtre à qui ce type de tâche incombe. Un mécanisme simple, mais déjà implanté est celui des applications de confiance et celles qui ne sont pas de confiance. En fait, c’est ce que l’on utilise déjà avec les options -X ou -Y du client ssh. Les applications de confiance peuvent globalement tout faire. Celles qui ne sont pas de confiance ont des accès limités ou inexistants aux autres ressources X.
En plus de ce mécanisme très simple, une implantation de XSELinux sera intégrée à l’arbre X. Elle vise à introduire des profils d’utilisation des ressources similaires à ceux de SELinux, où un processus d’un certain contexte, lancé par un utilisateur d’un certain contexte peut accéder à des ressources d’un certain contexte.
Le problème réside toujours en espace utilisateur de la manière d’avertir d’une violation de règle. Actuellement, il y a des avertissements de "bad access" dans des traces textuelles de quelques lignes, pas forcément très lisibles pour un humain.
Le problème reste entier pour OpenGL et GLX, puisque les accès au matériel sont plus directs.
Pour les composition managers comme Compiz, c’est aussi compliqué. L’orateur a une illustration excellente que ni Olivier, ni moi-même n’avons perçue au premier coup d’œil. Il s’agit d’une barrière de péage sur une route, mais comme les alentours immédiats du péage ne sont pas bloqués, on voit clairement les traces de toutes les voitures qui l’ont contourné sur une photo aérienne.

Metasploit framework

Historique : initialement développé en Perl, actuellement écrit en Ruby, C/C++ et un peu d’assembleur. Explication du fonctionnement de Metasploit. Démonstration avec un Microsoft Windows dans une machine virtuelle VMware. Il existe au moins trois interfaces à MSF. La console, l’interface en ligne de commandes, l’interface web et, à venir, une ou plusieurs interfaces graphiques.
L’orateur insiste sur les raisons qui l’ont poussé à choisir Ruby en remplacement de Perl. Pour le départ de Perl, c’est en raison de la propension des développeurs à être constamment insatisfaits et prétendre à tort ou à raison qu’il existe une meilleure manière d’écrire. Pour l’arrivée à Ruby, c’est parce que c’est "clean, easy and fun".
Après avoir choisi ses exploits, et une charge (payload), sur l’OS de la machine virtuelle, en quelques secondes, on obtient un shell et l’exécution de la charge. Idem pour l’obtention d’une connexion à un serveur VNC et un shell.
La démonstration de l’interface web est aussi intéressante, parce que l’on peut avoir des sessions sauvegardées et reprises, un peu comme avec un screen.
Tonnerre d’applaudissements à l’obtention du shell et de la fenêtre VNC.
" http://framework.metasploit.com/

Second Life

Second Life est un projet intéressant à plus d’un titre. C’est un monde virtuel qu’il est possible d’explorer à l’aide de clients disponibles sur plusieurs systèmes d’exploitation.
La particularité de ce monde virtuel est qu’il est possible de transférer des fonds depuis le monde réel pour acheter des objets, des créations dans l’univers virtuel, et, d’autre part, de récupérer de l’argent du monde réel à partir du monde virtuel. En fait, il y a des personnes qui sont devenues millionnaires en dollars à partir de créations artistiques ou autres vendues.
Par rapport à des jeux où l’on commence à voir des ventes d’objets virtuels sur des sites d’enchères, Second Life se distingue parce qu’il existe une banque pour les transactions directement dans l’univers virtuel. Ce mode de fonctionnement fait d’ailleurs partie de ce qu’il est possible de faire.
L’orateur a exposé le mode de fonctionnement des clients, avec des region agent, des user agent et les manières de se connecter entre eux.
Il a insisté sur l’ouverture progressive de portions des clients et du protocole. Pour la partie serveur, l’ouverture est aussi envisagée, mais après avoir bouclé des parties fonctionnelles pour l’instant inachevées.
La licence d’utilisation choisie est la GNU GPL. L’un des visiteurs a insisté pour des échéances et s’est interrogé sur la fermeture de certaines parties du code.
" http://secondlife.com/

Packaging RPM

Jeff Johnson nous a présenté posément les changements dans RPM réalisés et à venir. La conférence a lieu dans la salle Fedora/CentOS.
Actuellement, même si une version étendue de tar est en cours de développement par Red Hat (star), il n’en reste pas moins que les versions historiques de tar et de cpio ne permettent pas de sauvegarder les attributs étendus. Les attributs en question qui peuvent exister sont les ACL, les contextes SELinux ou, pourquoi pas, tout autre attribut qui peut être stocké dans une i-node.
Les tests d’intégrité qui sont réalisés dans les RPM concernent les archives elles-mêmes et pas les fichiers contenus dans l’archive. En fait, c’est hérité là encore directement de ce qu’il est possible de faire avec tar ou cpio.
Ce que Jeff Johnson propose, c’est d’utiliser XML et XQuery pour obtenir et stocker les informations qui décrivent un paquet RPM (les métadonnées). Ce type de solution remet considérablement en cause l’API actuelle qui se base sur des couples variable=valeur et non sur des données structurées, quelle que soit la méthode d’accès.
En fait, pour Jeff Johnson, le format doit changer pour prendre en compte des nouveaux besoins.
Il a aussi parlé des signature headers et de la nécessité de séparer les métadonnées des données elles-mêmes.
Il évoque Mac OS X et le fait que cet OS ne dispose pas d’un système de gestion de paquetages satisfaisant. En gros, on peut saisir qu’il s’intéresse beaucoup à cet OS.
La présentation ressemblait à un avertissement courtois mais ferme d’une rupture d’API, sur un fond de justification technique.
Il y a un point qui n’a pas été abordé de manière approfondie (à mon goût) qui est qu’il existe actuellement deux projets en parallèle qui remplissent les mêmes fonctions et qui héritent de la même base de code et qui sont désormais incompatibles, mais qui continuent à porter le même nom.

Running Debian on Inexpensive Network Storage Devices

Présentation d’une installation de Debian dans des NAS bon marché. En partant du constat que les petits serveurs de fichiers NAS disponibles sur le marché embarquent suffisamment de ressources matérielles (CPU, mémoire) pour faire tourner un OS comme Linux, un projet est né pour permettre l’exécution d’un noyau Debian.
Dans certains cas, il y a un remplacement du firmware par l’installeur Debian après l’avoir alimenté avec les données conservées dans le firmware par défaut. Ensuite, l’installation se déroule et, à la fin de l’installation, l’image est écrite sur la mémoire flash ou le disque en fonction du type d’installation.
Il y a de nombreuses optimisations. Le remplacement de la glibc par une version ultra allégée, la klibc, permettrait de gagner énormément en taille de l’image à charger.
Une discussion sur le poids des communautés d’utilisateurs sur les fabricants de matériel s’ensuit. Pour illustrer le propos, l’orateur raconte qu’un appareil du même type, mais avec une communauté moins importante et des perspectives d’évolution moindres ont entraîné des ventes plus faibles.
Quelques machines sont présentées. Le NSLU2 est impressionnant par sa petitesse. Il permet d’utiliser des disques connectés en USB.
Globalement, si les installations fonctionnent, il faudra attendre la RC2 de l’installeur Debian pour la stabilisation pour plus de fiabilité.
Les configurations matérielles sont très légères. Les utilisateurs se satisfont généralement de ces appareils, parce qu’ils sont très peu chers, silencieux et que pour des petites applications, comme un serveur web, on peut se satisfaire du résultat. Pour des besoins plus complexes, ces appareils sont trop lents.

" http://www.cyrius.com/debian/iop/n2100
" http://www.cyrius.com/debian/nslu2
" http://www.nslu2-linux.org

LVM2

Alasdair Kergon explique qu’il travaille sur LVM2, en mettant en avant Fedora et RHEL, et donc les distributions dérivées comme CentOS, mais également les autres distributions Linux, comme Debian ou Gentoo.
Le but ultime est l’acceptation upstream avant tout.
Alasdair parle de l’introduction du mirroring dans LVM2. Cette solution permet de s’affranchir de l’utilisation d’une autre solution logicielle pour créer des miroirs.
Il explique aussi pourquoi il est très compliqué de faire du RAID logiciel en cluster. À savoir que si plusieurs nœuds de cluster essaient d’écrire un bloc sur deux accès directs différents, on risque d’avoir des surprises au moment de la réplication.
Il explique la nécessité des rapports d’erreurs en espace utilisateur sur le miroir à l’aide de dm-event.
Il présente les tags (mot associé à un objet LVM) qu’il est possible d’utiliser dans les commandes. Il s’agit un peu d’étiquettes (labels sur les systèmes de fichiers), sauf que plusieurs objets peuvent être estampillés en même temps.
Par exemple, il est possible de taguer les PV ou des VG avec, comme étant utilisables pour des bases de données, et de déplacer éventuellement ces objets pour les utiliser sur une autre machine. Pour activer en une commande tous les VG marqués avec le tag database, il suffirait de taper une commande comme

vgchange -ay @tags database

pour activer tous les VG qui ont ce mot-clef.
Alasdair annonce que le cluster mirror LVM sera disponible dans RHEL4U5 et RHEL5 (utilisation du distributed lock manager).
Il parle aussi de la possibilité de spécifier des variables décimales pour les modifications de tailles ou d’utiliser un lvextend avec un pourcentage de l’espace libre ou un pourcentage de l’espace déjà occupé.
Il s’ensuit une discussion générale sur le démarrage avec des scripts de démarrage System V qui ont un déroulement linéaire, bien qu’il commence à exister une gestion des dépendances de services.
Certains envisagent une gestion du démarrage event-driven, donc basée sur des événements plutôt que sur un déroulement séquentiel. Le problème est que si la gestion des périphériques s’accommode bien d’une gestion par événements (cas d’udev et /dev), le reste du système pourrait en pâtir.
Il y a un problème général de la détection du matériel suivie de la création des kernel objects par udev.
Par exemple, si un pvscan est exécuté sur la détection d’un volume physique, on exécute ensuite un vgscan qui va explorer un volume physique. Si on en découvre un autre, on exécute à nouveau le vgscan avec 1+1 PV, etc. Si l’on a des grandes quantités de PV, on peut avoir des temps de détection complets considérables.
Bryn a proposé un patch pour dépasser la limite actuelle des périphériques de bouclage (loop devices) et illustre avec une démonstration au tableau du cas de Xen où l’on peut avoir besoin de beaucoup de boucles si l’on héberge plein de machines virtuelles avec LVM. On empile les couches de LVM et on explose ses limites de loop devices. On reconnaît bien le formateur à son aisance à exposer les concepts et les illustrer avec un schéma. ;-)

Conclusion

Cette édition était une réussite. Les organisateurs ont développé des trésors d’ingéniosité pour faciliter la vie des visiteurs. L’infrastructure technologique était impeccable, plusieurs salles étaient ouvertes avec des accès à internet, en plus des accès au réseau sans fil à travers une multitude de points d’accès.
La variété et la quantité des conférences auront peut-être pour conséquence de frustrer les visiteurs, obligés de choisir, mais leur qualité les amènera certainement à y revenir. À l’année prochaine !