Compte-rendu du FOSDEM 2009

1. Premier jour

Un peu d'humour, pour commencer, avec ce panneau affiché dans les toilettes des hommes (voir Fig. 1).

1.1 Ouverture

Durant la keynote d'ouverture, une annonce rappelle que Google a sponsorisé les bières gratuites du beer event. Il y a des fans qui expriment leur enthousiasme.

La classique danse d'ouverture (synchronisée) est aussi l'occasion d'inviter les visiteurs, mais aucun visiteur n'a osé monter brûler les planches avec les organisateurs.

Les différents parrains sont passés en revue, dont CISCO qui a assuré l'infrastructure réseau, mais il y avait clairement des soucis de connexion la première journée qui ont été résolus assez tard.

Il y a eu une discussion sur le code des RPC qui était initialement la propriété de Sun, avec une alerte du projet Debian qui ne voyait pas d'un bon œil du code non libre, et l'intervention de Fedora. Au final, tout est bien qui finit bien.

1.2 Free. Open. Future? – Mark Surman

Cette keynote aborde le parcours de Mozilla, en s'arrêtant à quelques périodes troubles, comme en 2003, où la situation des navigateurs était préoccupante, quand le monopole de Microsoft Internet Explorer sur le web engendrait des sites « faits pour » Microsoft Internet Explorer, et surtout qui ne fonctionnaient pas avec d'autres navigateurs web.

C'était aussi le moment où l'émergence d'une technologie comme Macromedia Flash a jeté un peu d'huile sur le feu en bloquant l'interopérabilité, et où on avait des contenus « protégés » qu'il n'était pas possible de consulter ou d'indexer sans la technologie propriétaire.

Depuis quelques années, la situation de monopole est bien atténuée, et à nouveau les utilisateurs peuvent partager des connaissances.

Pour aller plus loin, Mark Surman aimerait que les utilisateurs aient plus de poids dans le développement, qu'ils puissent orienter et améliorer le logiciel.

Ça parlait beaucoup de valeurs.

1.3 Debian - Bdale Garbee

Cette keynote a aussi parlé de valeurs. On peut retenir cette citation :

Never underestimate the value of values!

1.4 OLAP/windowing functions – David Fetter

Simon Riggs devait parler de réplication, mais il est arrivé en retard. La présentation a été échangée avec celle de David Fetter sur les fonctions de fenêtrage (windowing functions) dans PostgreSQL. En fait, ces fonctionnalités existent déjà depuis un bon moment dans certains autres moteurs de SGBD, comme DB2 ou SQL Server.

C'est pas pour dire, mais David, qui vient de Californie, était là avant Simon, qui vient pourtant du Royaume-Uni.

Les fenêtres de données sont davantage orientées listes que multi-lots (enregistrement). Un exemple est donné sur le décompte des lignes dans un resultset. En général, pour les comptages, il faut utiliser des astuces tordues à base d'opérations de groupement. La nouvelle mode, en utilisant les fonctions de fenêtrage, c'est plutôt :

Toujours avec des exemples bien sentis, David continue sur les partitions, les agrégats et les fenêtres.

Il a aussi parlé des fonctions lead() et lag() pour calculer des valeurs à partir des groupes d'enregistrements précédents et suivants.

Dans PostgreSQL 8.4, on trouve les Common Table Expressions. Pour le moment, on peut écrire ses propres fonctions de fenêtrage en C, et, à partir de 8.5, il devrait être possible de les écrire aussi dans d'autres langages.

1.5 UTF-8 support for syscons, new TTY layer - Ed Schouten

La présentation débute sur l'utilité des TTY, et ce qu'ils permettent de faire, du login au pseudo-terminal.

Toute l'intelligence, et en particulier la gestion des travaux, n'est pas implémentable uniquement dans un processus. Il est nécessaire d'intégrer des choses dans le noyau.

La réécriture devenait nécessaire parce que certaines limitations devenaient pesantes. Le code n'était pas MP-safe. Il n'y avait pas de support correct du hotplugging, la gestion des buffers n'était pas très efficace et il y avait des morceaux pas très beaux dans l'implémentation.

En fait, pour la gestion du multiprocesseur, le verrou géant (Giant lock) était utilisé. Désormais, il y a des mutex par TTY, et le Giant est utilisé uniquement en cas de besoin.

Même si le sous-système TTY n'est pas vraiment problématique pour les performances, il y a finalement des améliorations dont bénéficient les autres sous-systèmes.

Quelques limitations persistent (il reste du pain sur la planche) :

- Tous les pilotes n'ont pas été portés (surtout pour les matériels ISA).

- PPP/SLIP n'ont pas encore été portés.

- syscons utilise toujours le Giant lock.

Un autre chantier concerne le support d'Unicode. Unicode en soi n'est pas parfait. À ce moment-là, Ed fait un aparté sur la question qui a été posée lors de la keynote de Mark Surman sur le support de caractères qui n'existent pas dans Unicode. Un des encodages les plus couramment utilisés d'Unicode est UTF-8, mais ça ne reste qu'un encodage pour lequel il y a une compatibilité avec ASCII, les caractères non-ASCII apparaissant dans une plage au-delà de celle utilisée pour ASCII.

Ed soulève un problème de sécurité potentiel avec les conversions d'Unicode, par exemple dans un script shell, avec un codage du caractère « ` » sur plus d'un octet.

Comme pour toute présentation *BSD qui se respecte, il y a des comparatifs classiques entre Linux et FreeBSD. Ici, forcément, c'est sur la gestion de l'Unicode sur les consoles.

Cette nouvelle couche devrait être implémentée dans FreeBSD 8.

1.6 Replication replication replication – Simon Riggs

Simon débute sa présentation sur un avertissement. Certains détails très techniques pourraient rebuter les auditeurs. En fait, l'auditoire est toute ouïe.

La réplication qui faisait partie de la feuille de route de PostgreSQL 8.4 n'a pas été intégrée finalement. Il y avait d'autres choses en route, comme les PITR (Point In Time Recovery), et la Log-based Replication en a fait les frais.

La notion de hot-standby est utilisée pour désigner une architecture dans laquelle un serveur est capable de reprendre, sans interruption, le traitement des requêtes d'un autre serveur auquel il est associé.

Les archives sont stockées sur un serveur à part, par exemple un simple serveur de fichiers.

Dans les différents modes de réplication, il y a le stream-mode. C'est une réplication synchronisée, les écritures sont doublées (ou plus), et tout ce qui doit être écrit l'est sur tous les espaces de stockage avant de retourner du commit à l'utilisateur.

Il sera possible de choisir la robustesse transaction par transaction. Cette fonctionnalité n'est disponible dans aucune autre base de données, y compris les bases de données commerciales.

Il y a des problèmes sur les identifiants de transaction, surtout quand il y a eu beaucoup de transactions. Que faire quand on ne peut plus en créer ? Une solution partielle est de ne pas créer d'identifiant pour les transactions en lecture uniquement. Le problème a été détecté assez tôt, et par conséquent la solution a été implémentée.

Un autre problème concerne les conflits en cas de suppression des données par un HOT-STANDBY ou un VACUUM. En fait, on traite ces cas de la même manière que pour un accès classique. On ne supprime pas les données qu'un utilisateur peut voir.

Aucune solution de réplication ou de haute-disponibilité n'est parfaite et il y a toujours des compromis à faire.

Simon adresse ses remerciements à Florian et à Google qui a sponsorisé ce travail.

Pour la résolution des conflits, le mode opératoire est wait-then-cancel.

Pour ceux qui ont déjà vu le message « snapshot too old » dans une célèbre base de données propriétaire, il indique une réponse tardive. Un message similaire sera implémenté pour avertir en cas d'accès à une donnée en conflit dans Pg.

Il y a un autre petit souci avec les identifiants de transaction absents. Par exemple, si un identifiant 32 arrive, ça doit vouloir dire que le 31 existe même si on ne l'a pas vu. Le problème est courant, il faut alors consigner ces Xids dans une liste.

Beaucoup de problèmes sont posés par les sous-transactions. Simon les déteste (les sous-transactions), mais il faut bien faire avec.

Les optimisations pour éviter les mises à jour de cachelog sont profitables même en l'absence de réplication.

Le patch pour la réplication concerne 80 fichiers et plus de 10 000 lignes de code. Il a été implémenté à partir de ce qui avait été demandé l'année précédente.

Pour Simon, le but ultime est que PostgreSQL soit la meilleure base de données dans l'absolu, pas uniquement la meilleure des bases open source.

Dernier conseil : « Act with urgency and do Big Things! »

Absolument pas lié, mais tant qu'on parle de SQL, voici une blague : « An SQL query comes into a bar and sees two tables. It then comes to them and says : Can I join you? »

2. Deuxième jour

La deuxième journée commence avec des échanges de salles. Les conférences de sécurité et celles du système ont été inversées.

2.1 FreeIPA - Simo Sorce

FreeIPA signifie Free Identity Policy Audit. C'est un ensemble intégré d'outils existants qui a pour but de rendre transparente l'utilisation de sources d'authentifications diverses de manière unifiée tout en restant simple à administrer, même si l'architecture sous-jacente est complexe.

Jusqu'à présent, dans ce domaine, on trouve surtout des solutions propriétaires, ce qui fait qu'en gros les clefs d'une organisation ou d'une entreprise sont entre les mains d'un éditeur.

Le constat est donc qu'il n'est pas possible d'avoir un environnement libre si la partie gestion de l'identité n'est pas libre elle-même.

Avec des bases diverses pour l'authentification, il y a des risques de doublon et de confusion. Les besoins portent sur :

- SSO/single password.

- single datastore pour l'audit (s'assurer que la politique de sécurité est respectée) ;

- single point of management (vue unifiée).

Les problèmes d'implémentation les plus contraignants concernent la synchronisation des informations. La solution FreeIPA intègre des composants classiques dans ce type d'architecture, à commencer par un annuaire.

Ce dernier permet de stocker les informations sur l'identité et les authentifications (penser à passwd et shadow pour une analogie avec une implémentation locale), de manière sécurisée à l'aide de contrôle d'accès. Il doit pouvoir structurer des groupes et des relations, diffusion les informations sur des clients, et, si nécessaire, répliquer les données sur des serveurs multiples.

Avec LDAP, on dispose déjà d'un standard, même si certaines implémentations sont « plus ou moins » standards, et, globalement, ces annuaires arrivent à se parler. LDAP est extensible, dans le sens qu'il est possible d'étendre les schémas, et d'utiliser des schémas standards pour joindre des informations complémentaires sur les comptes d'utilisateurs. Il est tout autant extensible dans les opérations à réaliser, par exemple pour étendre les opérations de création.

FreeIPA est architecturé autour d'un royaume Kerberos et d'un annuaire.

Kerberos fournit :

- un SSO ;

- les informations d'authentification pendant l'utilisation du système pour les utilisateurs ou les administrateurs ;

- un standard éprouvé et solution sécurisée qui marche ;

- la possibilité d'utiliser des nouvelles technologies d'authentification, comme des smartcards ou de nouveaux algorithmes de cryptage s'ils sont disponibles.

L'exemple classique est celui de SSH avec propagation des tickets pour une seule authentification.

LDAP est une alternative possible pour l'authentification.

Les autres composants indispensables sont :

- le DNS pour le nommage et des associations entre certaines entités de Kerberos ;

- NTP, au moins pour avoir une référence commune de temps pour tous les systèmes et c'est un pré-requis pour Kerberos.

En plus de ces composants, il serait intéressant d'ajouter un système de définition des règles (policy), et éventuellement d'une autorité de certification. Pour disposer d'une interface web d'administration, il faudrait aussi ajouter un serveur web. Enfin, il faudrait ajouter un système d'audit pour s'assurer que les règles sont respectées.

Dans la version 1 de FreeIPA, même s'il n'y a pas d'autorité de certification, ni d'audit de règles, les composants utilisés sont les suivants :

- Fedora Directory Server

- MIT Kerberos;

- Apache mod_nss mod_auth_krb mod_proxy

- Python Turbogears

- pam_ldap pam_krb5

- ISC BIND, ISC NTPd

Les données d'identification et d'authentification sont stockées dans deux espaces séparés, ce qui s'avère plus facile pour définir des ACI (Access Control Information).

Il est possible d'utiliser un cn=compat pour les vieilles implémentations (en particulier Solaris ou des vieux Linux) qui ne respectent pas ou ne connaissent pas la RFC 2307.

Il n'y a pas de souci de synchronisation de données parce que l'annuaire contient tous les mots de passe, et le KDC (Key Distribution Center) va utiliser les informations de l'annuaire à l'aide d'un plugin LDAP.

ipa_kpasswdva mettre à jour le mot de passe dans la base LDAP également, et il n'y aura pas non plus de réplication.

En version 1, pour l'interface en ligne de commandes, on utilise XMLRPC, et pour l'interface web, le cheminement est :

S'ensuit une série de quelques captures d'écran de l'interface web ainsi qu'une énumération des 20 commandes. En plus de l'interface web et de la CLI, on peut aussi utiliser les commandes du client LDAP, et même éditer le LDIF à la main et tout casser si on veut.

Mais le but est de faire simple. À l'installation, il faut juste installer les paquets, puis lancer ipa-server-install, répondre aux questions sur le domaine DNS et le royaume Kerberos. Des valeurs par défaut sont suggérées. Il faut ensuite définir les mots de passe du manager et de l'administrateur LDAP, et c'est tout. C'est vraiment simple à mettre en œuvre.

Dans le schéma de base, il y a simplement besoin de pam_ldap pour les informations des utilisateurs et des groupes et pam_krb5 pour l'authentification. Pour l'interface web d'administration, le navigateur web suffit.

C'est un peu plus complexe quand on envisage d'utiliser plusieurs serveurs. Le serveur d'annuaire doit supporter la réplication multi-maître. Toutes les informations sont répliquées dans le KDC (pas besoin de kpropd). La réplication est faite au niveau attribut. La version 1 a été testée avec 4 serveurs répliqués sans problème.

En version 2, l'infrastructure est considérablement remaniée. Il y a en plus :

- un agent client qui prend en charge la mise en cache et les opérations hors-ligne ;

- l'infrastructure de règles (policy infrastructure), à savoir le traitement et l'interface de gestion ;

- les contrôles sur les machines (host-based controls).

En outre, l'interface web a été améliorée, et le DNS a été intégré, avec les signatures de transactions TSIG, et le plugin LDAP-BIND.

La plus grosse différence est l'utilisation d'un agent au lieu des modules PAM classiques en version 2.

Pour l'audit, il y a de nombreuses informations qui peuvent être collectées, dans l'audit log du noyau, ou dans syslog.

2.2 Upstart – Scott James Remnant

Difficile de naviguer entre les salles. Il arrive toujours le moment où l’on rate le début d'une présentation.

Upstart est un processus de démarrage qui vise à remplacer le vénérable init. La keynote présente des astuces d'Upstart pour démarrer plus vite.

Pour commencer, il faut bien être conscient que sleep() ne fait pas booter plus vite. Il faut aussi éviter les race conditions.

Upstart intervient dans toute la couche entre la session du bureau et le noyau.

La première version de 2006 permet de faire des choses très simples et exécuter des scripts, mais aussi définir un certain nombre d'attributs pour des évènements.

La version suivante (0.2.7) permet de définir plus simplement les évènement, et ajoute start on et stop on.

En 2.3, les scripts pre/post stop/start IPC ont encore changé.

Upstart 0.5 n'est pas encore déployé dans les distributions, mais utilise D-Bus pour l'IPC. Il y a aussi un nouveau comportement pour les instances.

Suivent ensuite une série d'exemples qui défilent à toute vitesse sur le suivi des forks, les opérateurs pour les évènements, une vraie gestion des jobs.

Pour les services, il y a une gestion du multi-user.

Les dépendances sont gérées :

De même que les dépendances multiples :

On peut aussi combiner des conditions avec des opérateurs logiques :

hal et devicekit dépendent de udev, mais ne tourneront pas de nuit. Il y a aussi des raccourcis d'écriture.

En conclusion, les runlevels, c'est du passé. Mais, Upstart va plus loin. C'est aussi un remplaçant pour cron. Les exemples suivants portent sur la gestion des évènements planifiés, soit à une fréquence particulière

soit par rapport à un autre évènement :

Dans le futur immédiat, le but est surtout d'améliorer le code, mais sans ajouter de nouvelles fonctionnalités.

La version 0.10, prévue pour juin, apporte (encore) une nouvelle syntaxe pour le traitement des jobs.

La prochaine version importante portera le numéro 0.50 si la version 1.0 n'est pas satisfaisante en termes de fonctionnalités.

Un auditeur demande si les changements de syntaxe seront facilement intégrables dans les distributions. Réponse : « oui, peut-être ... »

Une question est posée sur le remplacement de cron, et notamment le partitionnement pour les utilisateurs différents. Il est réalisé avec PolicyKit.

2.3 Securing CentOS with SELinux – Ralph Angenendt

Ralph commence par rappeler que toutes les nouvelles fonctionnalités ne sont pas implémentées dans CentOS, par opposition à Fedora.

Dans le vieux et vénérable modèle de sécurité de Linux, les restrictions sont limitées. En revanche, le modèle est simple, compréhensible et facile à mettre en œuvre.

Les groupes sont une manière de raffiner les accès, mais avec les noyaux 2.6, on atteint encore une limite pour plus de 65535 groupes, et c'est encore pire pour NFS avec une limite de 16 groupes.

Il est toutefois possible d'ajouter des ACL, avec la possibilité d'utiliser les attributs étendus pour stocker des métadonnées supplémentaires.

Avec SELinux, tous les objets ont un contexte qui leur est associé.

Avec RBAC (Role-Based Access Control), on ajoute la possibilité de définir des vrais rôles pour restreindre l'accès à des ressources à des utilisateurs qui n'auraient pas le rôle approprié. Dans la pratique, ça ne fonctionne pas vraiment bien ou, plutôt, c'est assez complexe à mettre en œuvre, ce qui revient un peu au même.

Avec MLS (Multi-Level Security), SELinux peut aussi permettre de classifier les documents (comme dans les films d'espions, avec Top Secret).

SELinux est transparent, ce qui fait que l'application ne sait pas pour quelle raison l'accès a été refusé. Certaines applications savent pourquoi elles ont été refusées, mais la plupart des applications normales ne sont pas au courant.

Les trois modes de SELinux (ou plutôt les deux modes + un) sont :

- Désactivé : les applications qui dépendent de SELinux ne fonctionnent plus, par exemple chcon ou setenforce.

- Permissive : le filtrage n'a pas vraiment lieu, mais toutes les infractions à la politique de sécurité sont consignées dans le journal du système.

- Enforcing : La politique de sécurité s'applique pleinement, et ce qui doit être refusé l'est effectivement.

À ce moment, Ralph présente un certain nombre d'outils pour gérer SELinux.

Suivent alors des exemples classiques autour des ressources d'un serveur web Apache. L'exemple porte sur des fichiers qui n'ont pas le contexte SELinux approprié. À ce moment-là, le serveur web ne peut pas servir le contenu.

Pour corriger ce problème, la commande chcon permet de rectifier le tir en appliquant un contexte correct à partir d'un fichier ou répertoire qui possède le bon contexte, par exemple :

Il est possible d'utiliser semanage pour un ajout persistant de contexte à la base de référence.

Un autre exemple porte sur l'utilisation des booléens de SELinux pour autoriser le serveur web à servir du contenu des répertoires personnels des utilisateurs :

Quelques exemples de booléens sont fournis sans beaucoup d'explication. On notera tout de même le booléen allow_execstack.

La présentation aborde ensuite un sujet intéressant qui est l'écriture d'un module. En version 4, la recompilation de toute la politique était indispensable. En version 5, il est possible d'utiliser des modules et de ne recompiler et recharger qu'un module, quitte à le développer sur une machine tierce et à le déposer sur le serveur pour le charger.

La commande audit2allowfacilite l'écriture des policies. On peut tourner avec SELinux en mode Permissive, collecter les avc:denied dans les journaux et alimenter audit2allow avec les messages avc pour produire un module et le charger.

Ralph enchaîne sur une petite démonstration avec les outils d'exploration. Enfin, il joue avec un autre exemple classique d'assignation d'un port TCP d'écoute pour le serveur web. Le démarrage plante, et avec un semodule bien senti, il charge son module. Le serveur web peut alors démarrer, et dès qu'il décharge le module à l'aide de semodule -r, le serveur web ne peut à nouveau plus démarrer.

2.4 SYSLINUX – Peter Anvin

Un peu d'humour pour commencer avec le rappel de la licence d'utilisation de la présentation sur le premier slide. On se demande d'ailleurs si c'est vraiment de l'humour, mais, en tout cas, ça amuse beaucoup l'auditoire.

Les différentes émanations de bootloader dérivées de SYSLINUX sont :

- SYSLINUX – FAT

- PXELINUX

- ISOLINUX - CDROM

- EXTLINUX – ext2/ext3

Actuellement, SYSLINUX fonctionne uniquement pour x86/BIOS. Le cœur est en assembleur. Il y a du travail en cours pour remplacer ça, en supprimant tout le code spécifique en assembleur, même si certaines portions doivent rester en l'état.

Parmi les fonctionnalités intéressantes, il y a le système de menus sophistiqués. Peter cite d'autres projets liés.

- MEMDISK est un émulateur de disque en mémoire. Il permet de démarrer les vieux systèmes comme DOS qui utilisent l'interruption 13h.

- gPXELinux vient d'une collaboration avec le projet Etherboot. Il intègre le support réseau, iSCSI, Ethernet, HTTP, FTP, NFS.

- ISOHYBRID permet de démarrer ISOLINUX depuis des clefs USB.

L'architecture x86 est vieille. Ça nous ramène en 1981. C'est une plateforme ouverte, et il y a beaucoup de clones. La plupart des interfaces BIOS datent de cette époque. Le boot depuis un disque ou une disquette tient sur 510 octets.

Pour les CD, El-Torito date de 1993. Il était peu supporté jusqu'à la fin des années 90.

PXE date de 1997 et a été révisé en 1999. Les premières versions étaient bien pourries.

Enfin, il y a beaucoup de bugs pour le support de l'amorçage à partir des clefs USB.

Peter continue sur un historique des implémentations.

- 1994 – La première implémentation de SYSLINUX, est la conséquence d'une installation problématique de Linux. Il était fait pour démarrer sur disquette, et, compte tenu des contraintes, devait être tout petit, et a été écrit en assembleur.

- 1999 PXELINUX – La spécification PXE autorise seulement 32 k pour le programme de boot réseau. SYSLINUX est assez petit, et les utilisateurs le comprennent.

- 2001 – ISOLINUX El-Torito (CDROM)

- 2004 – EXTLINUX est un chargeur générique pour ext2/ext3. Il a une API modulaire, est extensible, et possède un système de menus.

- 2006 – gPXELINUX, ISOLINUX avec le support Hybrid.

Les grandes forces des systèmes dynamiques est la découverte du matériel au démarrage, pas à l'installation. Ils fonctionnent bien avec les autres (s'intègrent bien).

En plus, l'interface utilisateur est plutôt élaborée, avec un support du framebuffer avec de « beaux » menus.

En revanche, ils ne supportent pas bien les configurations exotiques (la dynamicité a un prix)

gPXELINUX est un ensemble logiciel contenant gPXE et PXELINUX qui permet de démarrer sur plein de choses.

À ce moment, Peter fait une démonstration assez bluffante d'un boot sur HTTP à partir d'un serveur en Californie. Bien entendu, le boot est graphique, avec des menus, c'est la grande classe. J'aurais bien aimé prendre une photo, mais les bras m'en sont tombés.

Peter aborde alors l'API des modules SYSLINUX COM32. Elle utilise klibc. L'avantage est que ça ressemble à du code C userspace. Il y a des limitations, comme la lecture séquentielle en lecture seule des fichiers (pas de seek()). Les modules classiques sont :

- Interface utilisateurs (menus). Il y a deux modules de menus. Le premier est le classique que tout le monde utilise. Mais, il y a un autre module beaucoup plus élaboré qui fait tout du sol au plafond. Ce module a été écrit par Murali Krishnan Ganapathy, alors à l'université de Chicago. La bibliothèque graphique permet d'utiliser le même code pour du texte du graphique ou des consoles séries.

- Modules de formats de fichiers (file format modules). Ce module permet d'ajouter le support de nouveaux fichiers binaires. Par exemple, Microsoft SDI (System Deployment Interface). Le support de ce nouveau format a été demandé par un utilisateur. Il n'y a que 199 lignes de code pour le supporter, avec 139 lignes de code utile et la plupart est de la gestion d'erreurs.

- Modules de règles (policy modules) qui permettent de décrire des choses comme « booter le kernel truc sur une machine x86 32 bits, booter le kernel... sur l'archi..., booter le kernel... sinon ». Il n'y a que 127 lignes de code pour ce module.

- Modules de diagnostics, par exemple pour avoir des informations du BIOS.

Bien entendu, il est aussi possible de combiner des modules, comme dans le cas d'utilisation suivant :

- probe bus PCI ;

- associer les périphériques à des modules ;

- construire un initramfs avec les modules nécessaires, à la volée.

C'est malheureusement plus compliqué avec les périphériques USB ou Firewire.

La feuille de route est tout aussi intéressante :

- Interpréteur Lua en module pour pouvoir ajouter des nouvelles fonctionnalités sous forme de script plutôt que des modules. C'est surtout utile pour les modules de règles.

- Support readdir().

- Suppression de tout le code assembleur (surtout pour le support de brtfs).

Les composants centraux qui ont besoin de rester en assembleur sont le first stage loader, les entrées/sorties disque ou réseau, le BIOS extender et le Shuffle system (qui fait le tri).

Les autres composants, comme l'interface en ligne de commandes, pourront être réécrits en C.

Peter termine sur un appel à contributions, parce que le chantier de réécriture du core est beaucoup trop important pour une seule personne.

La présentation est en ligne à l'adresse http://syslinux.zytor.com/fosdem2009.pdf.

2.5 EXT4 – Theodore Ts'o

Theodore démarre sa présentation en disant que ext3 est le système de fichiers le plus souvent utilisé, toutes distributions confondues. Le communauté est variée, ce qui se révèle être un avantage en cas de crise économique. Il y a aussi un support commercial, avec des entreprises comme SuSE ou Red Hat.

Il y a dans ext3 un certain nombre de limitations, comme celle de 16 To par exemple.

En fait, ext4 est un ensemble de nouvelles fonctionnalités (FS features) qui peuvent être activées ou désactivées option par option.

ext4 peut même ne pas avoir has_journal ;)

Le fork d'ext4 est survenu en 2.6.19. Et ext4dev est devenu ext4 en 2.6.28.

Parmi les nouvelles fonctionnalités, on trouve les extents, à la place des associations de blocs indirects. Pour les gros fichiers, les indirections (simple, doubles, triples) ont un impact énorme sur les performances.

Les extents permettent de gérer des allocations plus efficaces pour des systèmes de fichiers de plus en plus gros.

Les indirections sont pénalisantes sur les gros fichiers, parce que, justement, on doit lire les blocs indirects. On le sent bien quand on supprime des gros fichiers.

Il y a une nouvelle structure ext4_extent. Pour un total de 48 bits (physical block number>), la taille maximale d'un extent est de 128 Mo (16 bits) et d'un fichier 16 To (32 bits logical block number).

L'allocateur de blocs a été amélioré pour pouvoir allouer plus efficacement des fichiers contigus.

Quand on aborde la question des performances, il y a plusieurs questions inévitables :

- Est-ce que les benchmarks sont honnêtes ?

- Est-ce qu'ils sont répétables ?

- Est-ce qu'ils sont représentatifs d'un cas d'utilisation de la vraie vie ?

Pour présenter ses résultats, Théodore a utilisé les outils qui se trouvent sur http://btrfs.boxacle.net/. Dans les graphiques résultants, il y en a un qui présente des performances clairement avantageuses pour ext4, mais Theodore modère en expliquant que dans cette série de tests, sa machine a aussi planté violemment, donc qu'il n'y a pas que des avantages. ;)

Pour pouvoir utiliser ext4, il est recommandé d'avoir au moins un noyau Linux 2.6.28. Il est possible de convertir un ext3 avec tune2fs en ajoutant tout ou partie des options extents, huge_file, dir_nlink, dir_isize. On peut aussi ajouter des options complémentaires.

Enfin, pour créer un nouveau système de fichiers, on peut tout simplement utiliser mkfs -t ext4.

2.6 My system is slow – Kris Kennaway

Cette keynote aborde le problème des performances dans FreeBSD et va passer en revue un certain nombre d'indicateurs et d'outils pour identifier des baisses de performance et présenter quelques solutions.

Généralement, si on se pose la question des performances, c'est que l'on a en tête une charge particulière :

- nombre de hits sur un site web ;

- nombre de requêtes sur une base ;

- nombre de transactions sur un système bancaire.

Pour commencer, il faut identifier les interactions avec le système (CPU, disques, réseau, autres entrées/sorties). S'il y a des problèmes, ils peuvent provenir d'une mauvaise configuration d'une application, aussi bien que d'une limitation du matériel, des appels système et des interactions avec le noyau, une mauvaise gestion du multithreading et des verrous, ou que, tout simplement, quelqu'un a été fainéant.

En utilisant le vénérable top, on peut observer pratiquement en temps réel des indications. Les colonnes paging from:to swap permettront de voir le perf kiss of death. Beaucoup de temps passé dans le kernel signifie un grand nombre d'interruptions Pour les processus ou threads qui utilisent le kernel, on aura des grandes valeurs d'interruptions.

Pour les valeurs brutes sur les accès disques, il faut observer les colonnes biord/biowr/wdrain. sbwaitindique une attente de socket, ucond:umtx signalent un thread lock.

Et il y a plein d'autres choses documentées dans les sources.

Pour les disques, iostat et sysstat sont aussi d'un grand intérêt. top -m io n'est pas encore supporté par ZFS.

Pour limiter la contention, il est conseillé de répartir les accès sur plusieurs axes et utiliser gstripe. Il faudra aussi aligner les bandes sur les limites du système de fichiers pour éviter de répartir les accès sur plusieurs bandes. Ces considérations logicielles ne dispensent pas de choisir du bon matériel.

Pour les systèmes de fichiers, on peut utiliser l'option async au montage, mais, évidemment, on s'expose à des problèmes en cas de crash. Pour configurer un swap-backed memory-device, on peut utiliser une commande comme mdconfig -a -t swap 4g ; mount -o async.

De nombreux outils permettent de surveiller le réseau, netstat -i/-w/-s, ntop, tcpdump, wireshark.

À part les options sur les sockets (setsockopt()), on peut configurer des paramètres du noyau (kern.ipc.maxsockbuf, net.inet.udp.recvspace). Pour net.inet.tcp.inflight.enable, des problèmes peuvent survenir dans certaines configurations.

Il faut aussi surveiller l'état du matériel. Pour les périphériques d'entrées/sorties, avec la commande vmstat -i, on peut voir parfois un +, qui indique une IRQ partagée. La sortie de dmesg donne aussi ces informations. Le problème est qu'en cas de Giant locked device, les performances peuvent fortement baisser. La meilleure solution est de supprimer le piloteet/ou supprimer le matériel.

Si l’on observe beaucoup trop de context switch involontaires, il y a peut-être un problème de conception. L'application a trop peu de travail ou elle gère mal les threads.

ktrace et trusspermettent de montrer les appels système d'un processus. procstat donne des informations détaillées sur les processus, dont la stack trace.

On peut analyser les verrous à l'aide de  sysctl debug.lock.prof.state | sort -n -k 3

DTraceest supporté. 37 000 probes sont disponibles dans FreeBSD.

Pour collecter des compteurs sur le matériel, on peut utiliser les PMC hardware performance counters. Il faut avoir l'option HWPMC_HOOKS et le module noyau hwpmc. Ensuite, on choisit les instructions à compter à l'aide de pmcstat -S instructions.

sched_graph est un script écrit en Python pour visualiser l'activité à partir de la kernel trace.

Dans FreeBSD 8.0, il y aura la surveillance de la sleepqueue. Cette fonctionnalité s'active avec sysctl debug.sleepq.enable=1.

Globalement, FreeBSD est auto-tuning. L'ordonnanceur des tâches par défaut est ULE depuis 7.1. Il est plus réactif en utilisation interactive. Pour l'affinité aux CPU, il y a un peu plus d'overhead que dans 4BSD. Il est généralement préférable d'activer les superpages et debugging, et d'utiliser un timecounter rapide, comme TSC si la charge et le matériel le permettent (Ccf. java).

Kris termine par des conseils classiques. Il invite à avoir des mesures répétables, en utilisant une période d'observation et une charge de travail constante. Il ne faut bien sûr changer qu'une chose à la fois, répéter les mesures, et utiliser des grands intervalles de mesure pour valider les résultats.

En première approche, /usr/bin/ministat est aussi précieux.

Remerciements

Un très grand merci aux Mongueurs francophones pour la relecture !