Nos amis les Filesystems… Part II (suite et fin)

Tout d’abord, BONNE ANNEE à tous les courageux qui ont réussi à se convaincre de reprendre le boulot sur leur site de travail -car maintenant, avec tous les moyens qu’il existe, il est largement possible de skipper l’implication physique, avec tout ce qu’elle entraîne, tout gardant la charge et la pleine responsabilité de l’infrastructure-.

Donc nous voila de retour sur les filesystems pour continuer -et éventuellement finir, tout dépend de ce qui vous reste en motivation le sujet.

Pour rappeler le contexte, ceci n’est qu’un épluchage de filesystems échantillonnés au hasard des rencontres, le tout rangé comme il faut dans les catégories qui vont bien. Si vous êtes curieux des épisodes précédents mais que le scroll down est trop pénible (je comprends, je comprends), vous pouvez juste placer votre souris sur le lien <- ici et vous laisser transporter dans la première partie de cet article !

Rapidement, nous nous sommes pluché les généralités, l’architecture logique, les classiques et les extensibles / haute disponibilités… Non, je n’ai pas prévu les apéritifs… Mais si vous avez faim, on attaque !

Les réseaux.

A l’heure de la communication et des flux de données, il aurait été inconcevable de ne pas mentionner les systèmes de fichier distants. En effet, il est possible d’exporter un système de fichier et de le rendre accessible par plusieurs machines. L’avantage concerne notamment le fameux « Zero Conf », et donc la possibilité d’être complètement -ou presque- indépendant de la machine que l’on utilise. Cela permet aussi de beaucoup mieux contrôler, sécuriser les accès et les droits sur ce système de fichiers, de centraliser les traitements et d’apporter une certaine robustesse et une certaine portabilité.

Le plus connu est NFS (Network File System). Il existe à l’heure où j’écris ces lignes, 2 versions qui sont exclusives l’une de l’autre, la version 3 et la version 4. La version 4 est celle désormais supportée par défaut.

NFS fonctionne comme un export de répertoire, qui peut être fait de manière lâche ou en contraignant les accès. Les machines autorisées peuvent alors, de manière manuelle ou automatique, monter ces répertoires, en lecture, en écriture et/ou exécution et les utiliser comme s’ils faisaient partie intégrantes de leur filesystem local. Si l’on veut savoir de quoi il en retourne, il suffit alors de lancer un netstat, un rpcinfo -p, un nmap ou un nfsstat sur les machines impliquées.

Globalement, les différences entre NFSv3 et NFSv4 tiennent à une réécriture du code pour optimisation et améliorations. Elles concernent notamment :

• une gestion plus poussée de la sécurité,
  - support de techniques comme Kerberos,
  - réduction des ports à ouvrir sur un firewall (plus d’UDP, on passe de 4 ports à 1, 2049:tcp)
• une gestion de cache plus poussée,
• une compatibilité pour les clients non Unix-like (donc Windows, via SFU, Services For Unix) ,
• une administration facilité (en terme de réplication, de migration,…),
• la gestion du crash recovery (client comme serveur)…

NFSv4 est statefull (il gère les états, ce qui n’était pas le cas de NFSv3), utilise la notion de répertoires virtuels, et supporte IPv6 côté client. L’unique port auquel il s’adresse est le 2049:tcp.

Il est bien sûr tout à fait possible de migrer de NFSv3 à NFSv4. Et pour ceux que cela intéresse, un petit lien sur les benchmarks réalisés sur les 2 versions et des infos sur la bête en question !

Effectivement, NFS est bien visible, beaucoup utilisé, mais il existe d’autres filesystems dans cette catégorie, comme SAMBA, qui présente l’avantage d’être accessible nativement par Windows et par Mac OS X. En effet, à l’heure actuelle, aucun support n’a été intégré au nouveau noyau de Mac concernant la prise en charge d’NFSv4. Bien entendu, un courageux développeur a bien tenté de créer un module pour pallier au manque -d’autant plus éprouvant qu’NFSv4 est maintenant devenu standard sous Linux- mais le résultat est aléatoire et peut sans problème et à répétition, faire planter outrageusement Mac OS X. Le module est accessible ici.

Les outils et fichiers importants :

• nfs-common et nfs-kernel-server : les packages respectivement pour le client et le serveur et pour le serveur,
• /etc/exports : le fichier de paramétrage d’export et de contrôle d’accès des fichiers accessibles via NFS,
• /etc/default/nfs-kernel-server et /etc/default/nfs-common : fichiers de configuration globaux
• /etc/fstab : notre fichier de montage automatique au démarrage,
• mount -t nfs : notre outil de montage manuel.

Les systèmes répartis.

Gros gibier. Eh oui, les clusters ont, eux-aussi, droit à leur catégorie puisqu’il existe des systèmes de fichiers conçus exprès pour eux.

PVFS (Parallel Virtual FileSystem) est l’un d’eux.

PVFS, comme son nom l’indique, s’adresse aux clusters destinés à faire tourner des traitements en parallèle. Il a été conçu pour optimiser les flux d’information transitant entre les nœuds du cluster. Ses principaux objectifs sont :

• d’offrir une large capacité concernant les accès concurrents de multiples processes sur un même espace,
• supporter plusieurs API (UNIX/POSIX IO, MPI I/O, PVFS I/O,…) et d’être Unix command-compliant (ls, cp, rm,…)
• offrir robustesse et scalabilité tout en restant accessible à l’utilisateur.

PVS est en réalité composé d’un set de daemons et de librairies, liés aux nodes suivant des rôles qui leur sont attribué par l’administrateur (donc vous). Il en existe 3 : compute, IO et management, certains peuvent même se cumuler. Grâce à l’attribution de ces rôles, il devient possible de découper les responsabilités attribuées à un filesystem orienté parallel computing sur plusieurs nodes et donc mieux gérer les accès aux ressources et par là même d’optimiser les performance du système.

Pour schématiser, c’est au rôle de Manager que reviennent les charges de contrôle des permissions d’accès et la maintenance des métadonnées et de l’organisation logique des éléments du filesystem. Les IO nodes, quant à eux, ont pour tâche de fournir l’accès aux données et de se corréler pour gérer les accès concurrents.

Les Compute nodes sont à la base des requêtes d’accès, de création et de modification des données, communiquent directement avec les IO nodes et sont donc encadrés en amont par les Management nodes au moment de la vérification des permissions d’accès, de lecture, d’écriture, d’exécution, et toute autre modification comme une copie ou un effacement de fichier. Ce sont eux qui font tourner les processes à proprement parler.

On notera que PVFS est très user-friendly, compatible, scalable à souhait et permet d’atteindre de haute performances concernant les applications IO intensives (parallèles comme distribuées) mais qu’en revanche, il ne fournit aucun mécanisme de recovery en cas de crash de node, et la redondance de donnée n’est pas présente. Il est également soumis aux limitations de TCP (nombre de socket ouvertes simultanément, surchage du trafic,…) et celles des filesystems Linux en général (taille de fichier <= 2Gb). Son module de compatibilité d’API UNIX/POSIX pose un problème de support des différentes versions de glibc. Enfin, le modèle de sécurité fourni par PVFS est plutôt basique (aucune restriction sur les connexions client, pas d’encryption des données, aucune vérification d’authenticité sur l’identité des clients, comme pour NFS, les clients et les informations qu’ils transmettent (UID) sont considérés comme fiables), ce qui le destine à des clusters confinés dans un réseau sécurisé.

Il faut tout de même dire que PVFS est encore en évolution, et quelques améliorations sont d’ores et déjà annoncées. Pour les liens, ça se passe par ici et par là !

Sachez que les principaux rivaux à PVFS se nomment GFS (Global FileSystem), MFS (Mosix FileSystem), Coda, Intermezzo, et Lustre.

La discussion sur les différences inhérentes à ces filesystems représente un vaste débat dans lequel je n’entrerais pas, pour la simple et bonne raison que d’une part je ne les ai pas mis en pratique, et d’autre part, comme on dit, c’est le contexte qui choisit sa solution. Je vous laisse donc potasser joyeusement, du moins si le cœur vous en dit…

Les encryptés.

Nous en arrivons à nous demander si, par rapport à toute cette histoire d’accès aux données, de confiance implicite accordée au client et de tout ce que l’on entend à la radio, vandalisme, blackmailing, trafic de données et espionnage industriel, si nos données à nous, locales, notre filesystem, si lui est sécurisé contre les intrusions… Ou pas…

Tout d’abord, vous devez absolument savoir que des lois s’étendent sur le sujet, notamment parce que l’absolue imperméabilité des échanges pourrait servir des desseins terroristes, des machinations, des pushs, bref l’autorité n’est pas tranquille. Cette anticipation amène donc à de drôles de restrictions au niveau de l’encodage des données.

Les solutions Linux.

Il y a plusieurs manières de faire le boulot sous Linux, surtout depuis le noyau 2.6. Dans un premier temps déjà, au niveau de l’installation, la plupart des distributions vous demande si vous désirez crypter vos données (Ubuntu 9.10 : « le mot de passe est requis pour ouvrir une session et déchiffrer mon dossier personnel », Fedora : « Encrypt System || Encrypt », …). L’avantage d’opérer la manip’ à ce niveau est surtout que vous n’aurez pas à passer par des sauvegardes pour migrer d’un espace non encrypté à un qui l’est. Par ce que, oui, il n’y a pas de recette miracle : lorsque vous devez faire en sorte que telle ou telle partition doit encryptées, les données existantes sont écrasées. L’inconvénient est qu’en fait, les opérations d’encryption réalisées à ce moment-là nous sont complètement cachées, impossible de savoir précisément ce qui se trame, et surtout ce qu’il y a dessous cette « encryption ».

S’il n’a pas jugé opportun de procéder à l’encryption du filesystem à l’installation, ou si les données ont changé (nouveau disque tout beau, PSSI renforcée, syndrome de paranoïa aigüe, …), alors Linux, depuis le noyau 2.6, met à disposition nativement une API de cryptographie (CryptoAPI) qui centralise les traitements et ce, quelque soit le choix de l’outil qui fera le sale boulot. Notons également que certaines distributions (les *BSD par exemple) proposent un panel d’outils supplémentaire.

Parmi les outils et les mécanismes disponibles, il est nécessaire de cerner le besoin : a-t-on besoin d’une granularité fine sur les répertoires et fichiers, ou nous arrêtons-nous aux partitions ?

En effet, il est possible de gérer l’encryption de manière totale, c’est-à-dire que tout le disque est encrypté, y compris les outils qui permettent justement d’encrypter et de décrypter, c’est ce que l’on appelle le Full Disk Encryption. Généralement, ce type de fonctionnement implique une déclaration statique de l’espace à encrypter, qui est fixe et ne peut être alloué dynamiquement, par exemple lors du rajout d’un disque, du moins sans avoir préalablement renouvelé la démarche de déclaration et d’encryption. Ce type d’encryption englobant la totalité du support, cela permet d’éviter tout leaking d’information, notamment au niveau swap, malheureusement, il est parfois impossible de paramétrer l’encryption plus finement au niveau des répertoires. Parmi les grands noms impliqués, dm-crypt et LUKS (Linux Unified Key Setup) figurent dans le top ten. Remarquez, c’est normal, on les trouve souvent ensembles, ces deux-là.

N’hésitez pas à mettre les mains dans le cambouillis ! Les dm-Crypt, par ici et ici ! Les LUKS, là et là (pour les RedHat) !

A contrario, l’encryption peut être gérée en elle-même par le filesystem, et donc nous ne trouvons plus face à la nécessité d’allouer et de crypter explicitement avant d’écrire sur l’espace. L’encryption est alors faite à la volée (on the fly). Ce mode apporte une certaine souplesse mais en revanche, il laisse des traces au niveau swap et les traitements intermédiaires ne sont pas adaptés à une large sollicitation des accès disques. C’est ce que l’on appelle communément un Filesystem-Level Encryption. On peut citer, par exemple, dm-Crypt avec ou sans LUKS (et oui, qui peut le plus peut souvent le moins), Truecrypt, CryptFS, Enc-FS, Loop-AES, … Il est intéressant que certains des outils fonctionnent en UserSpace grâce à notre bon vieux FUSE, et ne nécessitent souvent pas de root access pour être mis en place. Si vous décidez de ce type d’encryption, CryptoAPI est votre ami.

Enfin, on peut se pencher uniquement sur certains fichiers, et on bascule sur le cryptage manuel via des certificats numériques.

Si vous avez besoin de plus de détails concernant les généralités des 3 niveaux d’encryption, vous pouvez trouver une masse conséquente de savoir ici !

Les solutions *BSD.

En ce qui concerne les solutions *BSD, il vous arrivera d’entendre 2 noms : CDG pour FreeBSD et GELI pour NetBSD. Vous vous posez sûrement la question, vous qui ne faîtes pas partie des troupes *BSD, en quoi ces 2 OS sont-ils différents ? Pour répondre à cette question qui abrite beaucoup de trolls et qui sort complètement du scope de l’article, vous pouvez vous référer aux sites officiels, de les tester, tout simplement, ou si vous n’avez ni le temps ni la patience pour l’une ou l’autre solution proposée, vous pouvez toujours couper court en lisant l’article de Comment ça marche.

CDG se compose d’une couche d’abstraction supplémentaire qui se situe en dessous du buffer cache, cette position lui permettant de faire abstraction du système de fichier employé, de ce qu’il encrypte et décrypte (swap, disque, …) et d’une partie user utility, située dans le UserSpace. Il a été conçu et optimisé pour les machines destinées à une seule personne ou pour les supports de stockage amovibles et encrypte entièrement les partitions. Il est portable sur toute autre version dérivée de BSD et il est nécessaire d’activer son support à la création du kernel.

Techniquement parlant, CDG, via son outil de configuration en UserSpace, supporte et met à disposition différentes méthodes de cryptage, afin que l’utilisateur ne soit pas tenu à une technologie et qu’il puisse adapter CDG à son niveau de besoin. La partie située dans le kernel, sous le buffer cache, se contente, elle, d’encrypter les données, ce qui lui permet d’être plus réactive, mais de fait, l’encryption par utilisateur n’est pas possible. Pour les détails techniques, rendez-vous sur le chapitre dédié.

GELI (GEOM_ELI de son petit nom) demande également l’activation de son support avant recompilation du kernel car il n’est pas intégré nativement dans NetBSD. GELi est en fait la combinaison de 2 outils. Le premier outil, GEOM, s’occupe de gérer les disques (labels BSD, MBR, …) et qui sert souvent de base pour la mise en place de RAID. Dans le cas de l’encryption, GEOM sert également de base pour GBDE (Geom Based Disk Encryption). GELI, quant à lui, s’occupe de la partie encryption en elle-même.

Le reste est librement consultable ici ! Pour ceux qui voudraient même aller plus loin, vous pouvez lire l’excellente poussée Unix Garden.

On trouve de la même façon des solutions dites « cross plateform« , c’est-à-dire qui fonctionnent sous importe quel OS. Amis Windowsien, voici pour toi. Parce qu’il est vrai que jusqu’à présent, nous avons parlé de solutions exclusivement Linux, pour autant, il en existe pour Windows -EFS, FreeOTFE- et pour les deux -BestCrypt, TrueCrypt-. Si vous êtes intéressés, vous pouvez aller faire un petit tour sur les sites officiels. BestCrypt a aussi un article pour lui tout seul dans Linux Journal.

Notre « rapide » tour d’horizon s’achève sur ces mots. Oui, promis, plus jamais aussi basique. Plus court aussi. Je note dans mes bonnes résolutions.

Par contre, pour ceux qui ont décroché -et donc qui ne sont sûrement plus en train de lire ces lignes-, vous pouvez noter dans les vôtres plus d’endurance ! Après tout, c’est bien beau les tutos et autres, mais faut aussi savoir ce que l’on fait. Et pour cela, 4 lettres bénites : RTFM.

Sur ce ! Paix et longue vie à vos serveurs critiques (et aux autres aussi) !