K-Tux » filesystem

Auditd : monitoring de données en temps réel

KXan — Mon, 05 Sep 2011 16:45:14 +0000

Auditd

Auditd est un outil qui permet de monitorer les accès aux données et de pouvoir offrir un support stable pour l'exploitation des logs. Auditd fait partie d'un ensemble de composants qui ont pour fonctionnalités de gérer les règles de surveillance et d'afficher les rapports. Auditd est le daemon qui tourne en fond, en userspace, et qui est au coeur de la récupération des informations.

Prise en main

L'installation est très facile, et comme l'outil a fait ses preuves, on peut l'installer directement depuis les dépôts officiels.

$ apt-get install audit

Et oui, cela suffit...

Configuration

La configuration d'audit se trouve sous /etc/audit/. On y trouve auditd.conf, qui est la conf à proprement parler du daemon auditd et audit.rules qui est destiné à contenir vos règles en dur.

# ls -asl /etc/audit/
total 24
4 drwxr-x--- 2 root root 4096 2011-09-02 15:13 ./
12 drwxr-xr-x 140 root root 12288 2011-09-05 15:23 ../
4 -rw-r----- 1 root root 680 2009-07-27 21:07 auditd.conf
4 -rw-r----- 1 root root 373 2009-07-27 21:07 audit.rules

La conf ressemble à ça :

#
# This file controls the configuration of the audit daemon
#

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 4
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 5
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key

Cette conf nous apprend notamment l'emplacement du log généré par le daemon, ce qui nous permettra d'y jeter un œil plus tard, pour extraction. Quant à audit.rules, à la base, il est un peu vide, comme vous pouvez le constater : un -D pour tout flusher, une instruction d'augmentation de buffer, en dehors de cela, tout reste à faire.

$ cat /etc/audit/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

Il y a donc 2 manières différentes de faire des règles : en statique dans le fichier de conf /etc/audit/audit.rules, ou à la volée. Bien sûr, les seules différences entre statique et à la volée sont que :

la volée ne survit pas à un reboot, alors que statique se lancera avec le daemon auditd
la syntaxe des règles statiques est la même que celles à la volée, mis à part l'invocation de auditctl.

Création et gestions des règles

Comme c'est plus facile, et que c'est pratique, nous allons créer quelques règles à la volée. Pour information, voici les options que j'ai renseigné :

w : watch, activer la surveillance
p war : fixer le filtre concernant les permissions pour la surveillance d'un fichier. Ici, r pour read, w pour write, x pour execute, a pour append.
k passwd-file : clé unique permettant d'identifier l'objet de la requête

k-root # auditctl -w /etc/passwd -p war -k password-file
k-root # ausearch -f /etc/passwd

J'ai crée un watch sur le fichier /etc/passwd, qui relèvera toute tentative en read, write ou append sur le fichier. Comme on peut le voir, pour le moment, aucun évènement n'a eu lieu... Mais c'est sans compter sur k-user, qui va grepper root sur ledit fichier...

k-user $ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash

Immédiatement, la tentative -fructueuse- est journalisée et vue par auditd :

k-root # ausearch -f /etc/passwd
----
time->Fri Sep 2 15:16:50 2011
type=PATH msg=audit(1314969410.095:9): item=0 name="/etc/passwd" inode=1982554 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1314969410.095:9): cwd="/home/k-user/Documents"
type=SYSCALL msg=audit(1314969410.095:9): arch=40000003 syscall=5 success=yes exit=4 a0=b763b078 a1=80000 a2=1b6 a3=8295090 items=1 ppid=6893 pid=28672 auid=4294967295 uid=3100 gid=3000 euid=3100 suid=3100 fsuid=3100 egid=3000 sgid=3000 fsgid=3000 tty=(none) ses=4294967295 comm="ps" exe="/bin/ps" key="password-file"
----
time->Fri Sep 2 15:16:52 2011
type=PATH msg=audit(1314969412.095:10): item=0 name="/etc/passwd" inode=1982554 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1314969412.095:10): cwd="/home/k-user/Documents"
type=SYSCALL msg=audit(1314969412.095:10): arch=40000003 syscall=5 success=yes exit=4 a0=b7669078 a1=80000 a2=1b6 a3=86c6090 items=1 ppid=6893 pid=28673 auid=4294967295 uid=3100 gid=3000 euid=3100 suid=3100 fsuid=3100 egid=3000 sgid=3000 fsgid=3000 tty=(none) ses=4294967295 comm="ps" exe="/bin/ps" key="password-file"
---- [...]

On peut faire aussi un peu plus lisible, grâce à l'option -i qui interprètera les id (uid, guid, date, ...). Plus facile pour le coup d’œil, n'est-ce pas ?

k-root # ausearch -f /etc/passwd -i
----
type=PATH msg=audit(02/09/2011 15:16:50.095:9) : item=0 name=/etc/passwd inode=1982554 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(02/09/2011 15:16:50.095:9) : cwd=/home/k-user/Documents
type=SYSCALL msg=audit(02/09/2011 15:16:50.095:9) : arch=i386 syscall=open success=yes exit=4 a0=b763b078 a1=80000 a2=1b6 a3=8295090 items=1 ppid=6893 pid=28672 auid=unset uid=k-user gid=k-user euid=k-user suid=k-user fsuid=k-user egid=k-user sgid=k-user fsgid=k-user tty=(none) ses=4294967295 comm=ps exe=/bin/ps key=password-file
----
type=PATH msg=audit(02/09/2011 15:16:52.095:10) : item=0 name=/etc/passwd inode=1982554 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(02/09/2011 15:16:52.095:10) : cwd=/home/k-user/Documents
type=SYSCALL msg=audit(02/09/2011 15:16:52.095:10) : arch=i386 syscall=open success=yes exit=4 a0=b7669078 a1=80000 a2=1b6 a3=86c6090 items=1 ppid=6893 pid=28673 auid=unset uid=k-user gid=k-user euid=k-user suid=k-user fsuid=k-user egid=k-user sgid=k-user fsgid=k-user tty=(none) ses=4294967295 comm=ps exe=/bin/ps key=password-file
----

Les commandes de base sont intuitives, par exemple, le listing des règles en place :

k-root # auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=password-file
LIST_RULES: exit,always watch=/etc/shadow perm=rwax key=shadow-file

La suppression d'une règle (attention, une, et autant vous dire que les doublons ne sont pas conseillés). En parlant de doublon, étant donné que l'évaluation d'une règle est parfois coûteuse, comme par exemple l'évaluation de tous les syscall, la factorisation d'expression est préconisée.

k-root # auditctl -l
LIST_RULES: exit,always watch=/etc/shadow perm=rwxa key=shadow-file
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=passwd-file

k-root # auditctl -d exit,never -W /etc/shadow -k shadow-file

k-root # auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=passwd-file

A titre d'information, le delete all a déjà été vu dans le fichier de règles : l'option en question est -D. Bon à savoir quand on veut resetter notre daemon :)

Reporting

Pour ce qui est du reporting, pas de problème non plus, un tas d'options permettant en plus de mettre le focus sur ce que vous avez vraiment envie de consulter. Pour savoir un peu ce qui tourne, on appellera auditctl.

k-root # auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=28521 rate_limit=0 backlog_limit=64 lost=0 backlog=0

Alors que pour le reporting à proprement parler, on passera par aureport : ici pour les évènements...

k-root # aureport -e
1840. 02/09/2011 16:14:25 1846 USER_AUTH -1 yes
1841. 02/09/2011 16:14:25 1847 CRED_REFR -1 yes
1842. 02/09/2011 16:14:23 1840 SYSCALL -1 yes

Et là pour lister les authentifications, réussi ou pas d'ailleurs :)

k-root # aureport --auth

Authentication Report
============================================
# date time acct host term exe success event
============================================
1. 02/09/2011 15:16:46 root ? pts/26 /bin/su yes 4
2. 02/09/2011 16:14:25 k-user ? :0 /usr/lib/kde4/libexec/kcheckpass yes 1846

Et enfin, vue d'ensemble, à la logwatch :

# aureport --summary

Summary Report
======================
Range of time in logs: 02/09/2011 15:14:10.327 - 02/09/2011 16:17:06.165
Selected time for report: 02/09/2011 15:14:10 - 02/09/2011 16:17:06.165
Number of changes in configuration: 4
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 0
Number of authentications: 2
Number of failed authentications: 0
Number of users: 1
Number of terminals: 8
Number of host names: 1
Number of executables: 23
Number of files: 2
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 1
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 1847
Number of events: 1930

A titre d'indication, voila ce que renvoie le help de aureport.

k-root # aureport --help
usage: aureport [options]
-a,--avc Avc report
--auth Authentication report
-c,--config Config change report
-cr,--crypto Crypto report
-e,--event Event report
-f,--file File name report
--failed only failed events in report
-h,--host Remote Host name report
--help help
-i,--interpret Interpretive mode
-if,--input
 use this file as input
--input-logs Use the logs even if stdin is a pipe
-l,--login Login report
-k,--key Key report
-m,--mods Modification to accounts report
-ma,--mac Mandatory Access Control (MAC) report
--node Only events from a specific node
-n,--anomaly aNomaly report
-p,--pid Pid report
-r,--response Response to anomaly report
-s,--syscall Syscall report
--success only success events in report
--summary sorted totals for main object in report
-t,--log Log time range report
-te,--end [end date] [end time] ending date & time for reports
-tm,--terminal TerMinal name report
-ts,--start [start date] [start time] starting data & time for reports
-u,--user User name report
-v,--version Version
-x,--executable eXecutable name report
If no report is given, the summary report will be displayed

Auditd et Prelude

Ce qui est bien avec auditd, c'est qu'il ne fait pas sa soupe dans son coin, il peut aussi très bien échanger avec, mettons, des IDS... Malheureusement, comme je souhaite me garder encore quelques tips pour plus tard, je n'ai pas joué avec, mais sachez qu'il existe un plugin, audisp-prelude, qui, utilisant la librairie de Prelude, permet d'envoyer des IDMEF (Intrusion Detection Message Exchange Format). Ceci étant, il est nécessaire d'avoir un prelude-manager de disponible pour pouvoir agréger et corréler les données. D'ailleurs, si certains l'utilisent, je les encourage à donner de la voix sur leurs ressentis du produit :)

Conclusion

Auditd est un outil bien pratique, à porter de main, qui peut être appliqué dans un contexet de sécurisation et de monitoring comme de reporting sur des modifications effectuées sur les données du système. Il permet d'avoir un état des lieux concis et indiscutable et de pouvoir remonter le fil des évènements sans devoir dépendre totalement des informations fournies (ou pas) par les auteurs des modifs. Bien entendu, même s'il s'agit d'un outil très puissant et pouvant être redoutable d'efficacité, rien ne pourra remplacer une bonne com au sein de l'équipe :)

Linux : Mise en place de quota

KXan — Fri, 17 Jun 2011 11:24:52 +0000

Aujourd'hui, petit tip sur comment mettre en place des quotas sur un système Linux. Pour cela, il faut avoir quelques concepts de base que je vais définir vite fait, puis on passera à la pratique.

Les concepts en question

Limites

Hard limit

Une hard limit correspond à la limite maximale de blocs (disque ou d'inodes) étant autorisée et pouvant être utilisée même de manière temporaire par un utilisateur (ou par un groupe). Lorsqu'elle est atteinte, il est impossible d'allouer plus à l'utilisateur.

Soft Limit

Une soft limit correspond au nombre maximal de blocs de disque (ou d'inodes) pouvant être utilisé de manière temporaire par un utilisateur (ou par un groupe). Elle se situe logiquement au-dessous de la hard limit. Ainsi, ça permet aux utilisateurs d'y accéder temporairement (voir grace period) et de pouvoirêtre en mesure de finir toute tâche commencée ou de cleaner les données non utiles / non nécessaires afin de redescendre en-dessous de la soft limit.

Grace Period

Toute utilisation de disque au-dessus de la soft limit est par définition temporaire. C'est la grace period qui détermine la durée pendant laquelle un utilisateur (ou un groupe) peut pousser son utilisation au-delà de la soft tout en restant en dessous de la hard. Sous Linux, les quotas sont mis en place :

pour une parttion / un filesystem

pour un groupe ou pour un utilisateur.

Install et jeu

Pour l'installation, étant donné que les quotas sont intégrés sous Linux depuis belle lurette, il vous suffira d'utiliser votre package installer préféré et d'installer quota et quotatool. Je travaille sur une partition de sda, /dev/sda3 qui est montée sous /data. On commence par vérifier qu'il n'y a aucun quota de défini sur notre partition.

$ quotacheck -vgum /data/
quotacheck: Mountpoint (or device) /data not found or has no quota enabled.
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.

Il faut ensuite éditer le fichier /etc/fstab pour ajouter usrquota,grpquota après les options standard de montage (default pour moi) :

LABEL=DATA             /data                   ext3    defaults,usrquota,grpquota        1 2

Remonter la partition, bien entendu, afin que les options soient prises en compte :

$ mount -o remount /data
$ mount /data
/dev/sda3 on /data type ext3 (rw,acl,usrquota,grpquota)

Et maintenant démarrer les quotas :

$ quotaon -v /data

En sachant que pour les stopper, ce n'est pas plus difficile :

$ quotaoff -v /data

Petit check sur /data, histoire de voir si des quotas sont déjà en jeu...

$ quotacheck -vgum /data/
quotacheck: Parcours de /dev/sda3 [/data] terminé
quotacheck: Vérifié 20164 répertoires et 142505 fichiers

Gestion des quotas

La gestion des quotas est on ne peut plus intuitive :

$ edquota k-tux

Quotas disque pour user k-tux (uid 11039) :
Système de fichiers           blocs       souple     stricte   inodes    souple   stricte
/dev/sda3                        32       6000       8000          8        0        0

On peut également faire jouer la grace period. Pour cela un petit :

# edquota -u -f /data -t

Sursis avant l'application des limites souples pour users :
Unités de temps peuvent être : days (jours), hours (heures), minutes, ou seconds
Système de fichiers  période de sursis bloc  période de sursis inode
/dev/sda3                     7days                  7days

Et enfin, résultat de notre boulot, affichons nos quotas:

$ repquota /data/
*** Rapport pour les quotas user sur le périphérique /dev/sda3
Période de sursis bloc : 7days ; période de sursis inode : 7days
Limites bloc               Limites fichier
Utilisateur     utilisé souple stricte sursis utilisé souple stricte sursis
----------------------------------------------------------------------
root      -- 8782860       0       0          81579     0     0
k-tux       --      32    6000    8000              8     0     0

Pour ceux que les unités dérangent, il suffit de demander bien poliment à repquota :

$ repquota -si /data/
*** Rapport pour les quotas user sur le périphérique /dev/sda3
Période de sursis bloc : 7days ; période de sursis inode : 7days
Limites bloc               Limites fichier
Utilisateur     utilisé souple stricte sursis utilisé souple stricte sursis
----------------------------------------------------------------------
root      --   8578M       0       0          81579     0     0
k-tux       --      32    6000    8000              8     0     0

Conclusion

En moins de temps qu'il n'en faut pour printer "Hello world", vous voilà avec une partition sous quota ! Enjoy !

LUKS : quelques grammes de paranoïa pour des données bien protégées

K-TUX — Sun, 01 Aug 2010 14:27:12 +0000

LUKS signifie Linux Unified Key Setup. Il s'agit d'un format de cryptage de données standard et indépendant de la plateforme. Cet outil a justement été développé dans une optique de standardisation des processus d'encryptage et de décryptage des données, suite aux expériences malheureuses d'utilisateur. Afin de prétendre à la standardisation de l'outil, il a donc fallu prendre et justifier un ensemble de décisions. Ces décisions ont été regroupées sous une même modèle, TKS1, destiné au processing de clé issue de user password. Ce dispositif d'encryption est basé sur une version améliorée de cryptsetup et utilisant dm-crypt comme support pour la partie encryption de disque. Bien qu'initialement développé pour Linux, il existe aujourd'hui des versions dédiées Windows . LUKS est un processus à lancer sur une partition nouvelle, vierge de toute données dans la mesure où il opère une réorganisation de la structure logique de la partition. Néanmoins, il est possible, en passant par un backup et une restauration explicite à votre charge, de faire en sorte qu'une partition existante passe en cryptée sans perte de données.

Fonctionnement

Un disque encrypté via LUKS a une structure telle que :

LUKS phdr | KM1 | KM2 | ... | KM8 | bulk data

On peut y voir 3 types d'éléments : le Partition header (phdr), les key materials (KM) et les données encryptées (bulk data). Le partition header (phdr) débute au secteur 0 de la partition et contient :

les informations propres à l'encodage des données : le cipher utilisé, son mode, la md5sum de la master key ainsi que sa longueur, et un uuid,
les informations à propos des key slots, c'est-à-dire les entrées contenant les localisations des key materials.

Lorsqu'un key slot est activé, il y a recopie de la version cryptée de la master key dans la partie KM (Key Material) qui est associée au key slot. Cette version cryptée est verrouillée par le password utilisateur. La master key est construite grâce à PBKDF2 (PKCS #5’s password based key derive function 2). Elle est checksummée et plusieurs fois hashée via PBKDF2. Le résultat et le nombre d'itération sont tous les deux stockés dans le phdr. Normalement, une master key comprend seulement 16 ou 32 octets, ce qui peut poser des soucis de sécurité en cas de remapping en tant que zone réservée. En effet, il devient alors impossible d'accéder au secteur pour purger toute trace de la clé. C'est pour cela que LUKS a prévu une fonction qui splitte les information et gonfle la taille de la master key, ce qui permet de réduire les risques que l'ensemble de la master key soit remappée. Lorsqu'un utilisateur renseigne le mot de passe et après vérification de celui-ci, il y a décryptage du key material contenant la version cryptée de la master key. Il est alors possible de décrypter les données. Grâce à la multitude des key slot, il est possible d'avoir plusieurs mots de passe protégeant les données. Il suffit donc de fournir un de ces mots de passe pour déverrouiller la partition. Le phdr est de taille constante, en revanche, les tailles des KM dépendent de la longueur de la master key. Il existe plusieurs étapes par lesquelles on doit passer pour mettre en place et gérer LUKS. L'initialisation est la première. Elle consiste à construire une master key, et à modifier la structure de la partition à encrypter de telle sorte qu'elle dépende de cette master key. Il y a ensuite définition du password afin de déverrouiller la master key. Pour cela, l'utilisateur doit disposer d'une version non cryptée de la master key. Le password est ensuite crypté par PBKDF2 et crypte à son tour la master key.

Il est possible de changer de mot de passe puisque cela revient à déverrouiller la master key, à ajouter un nouveau password et à supprimer l'ancien.

Prise en main

Sur la plupart des distributions, il existe un package répondant au doux nom de cryptsetup, disponible sur les dépôts officiels. Pour jouer un peu, nous allons partir des sources, comme ça aucun paramétrage ne nous échappera et nous n'aurons plus de mauvaises excuses si cela ne fonctionne pas comme on veut. La dernière version en date est la 1.1.3, uploadée sur le serveur le 03 Juillet. Pour dire si la Communauté est active... C'est parti pour le rapatriement des sources !

$ wget http://cryptsetup.googlecode.com/files/cryptsetup-1.1.3.tar.bz2
$ tar jxf cryptsetup-1.1.3.tar.bz2
$ cd cryptsetup-1.1.3

Pour éviter que vous ne fassiez du stop-n'go comme moi, voici les principales requirements que j'ai rencontrées :

libdevmapper-devel
libgcrypt-devel, qui implique libgpg-error-devel

L'installation se fait à la régulière :

$ ./configure
$ make
$ make install
[...]
Libraries have been installed in:
/usr/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
[...]

Le make check est optionnel, mais conseillé. Beaucoup bavard, il permet de s'assurer que tout fonctionne au poil. L'installation est donc rapide et sans douleur. Voyons ce qu'il en retourne. Ne cherchez pas de luks quelque chose, vu que LUKS est une amélioration de cryptsetup, c'est cette commande qu'il faut invoquer.

$ cryptsetup --help
cryptsetup 1.1.3
Utilisation: cryptsetup [OPTION...]  ]
-v, --verbose                       Affiche des messages d'erreur plus détaillés
--debug                         Afficher les messages de débogage
-c, --cipher=CHAINE                 L'algorithme (« cipher ») utilisé pour chiffrer le disque (voir /proc/crypto)
-h, --hash=CHAINE                   L'algorithme de hachage utilisé pour créer la clé de chiffrement à partir de la phrase de passe
-y, --verify-passphrase             Vérifie la phrase de passe en la demandant deux fois
-d, --key-file=CHAINE               Lit la clé depuis un fichier (qui peut être /dev/random)
--master-key-file=CHAINE        Lit la clé (maîtresse) du volume depuis un fichier.
-s, --key-size=BITS                 La taille de la clé de chiffrement
-S, --key-slot=ENTIER               Numéro de l'emplacement pour la nouvelle clé (par défaut, le premier disponible)
-b, --size=SECTEURS                 La taille du périphérique
-o, --offset=SECTEURS               Le décalage à partir du début du périphérique sous-jacent
-p, --skip=SECTEURS                 Combien de secteurs de données chiffrées sauter au début
-r, --readonly                      Créer un « mapping » en lecture seule
-i, --iter-time=msecs               Temps d'itération de PBKDF2 pour LUKS (en ms)
-q, --batch-mode                    Ne pas demander confirmation
--version                       Afficher la version du paquet
-t, --timeout=secs                  Délai d'expiration de la demande interactive de phrase de passe (en secondes)
-T, --tries=ENTIER                  How often the input of the passphrase can be retried
--align-payload=SECTEURS        Utiliser une limite de  secteurs pour aligner les données - pour luksFormat
--non-exclusive                 (Obsolète, voir la page de man).
--header-backup-file=CHAINE     Fichier contenant une sauvegarde de l'en-tête LUKS et des emplacements de clés.

Options d'aide :
-?, --help                          Afficher ce message d'aide
--usage                         Afficher, en résumé, la syntaxe d'invocation

 est l'une de :
create   - créer un périphérique
remove  - retirer le périphérique
resize  - redimensionner le périphérique actif
status  - afficher le statut du périphérique
luksFormat  [] - formate un périphérique LUKS
luksOpen    - ouvrir un périphérique LUKS avec  comme « mapping »
luksAddKey  [] - ajouter une clé au périphérique LUKS
luksRemoveKey  [] - retire du périphérique LUKS la clé ou le fichier de clé fourni
luksKillSlot   - efface de façon sécurisée la clé avec le numéro  du périphérique LUKS
luksUUID  - afficher l'UUID du périphérique LUKS
isLuks  - teste si  a un en-tête de partition LUKS
luksClose  - retirer le « mapping » LUKS
luksDump  - afficher les informations LUKS de la partition
luksSuspend  - Mettre le périphérique LUKS en hibernation et effacer de façon sécurisée la clé (toutes les entrées/sorties sont suspendues).
luksResume  - Réveiller le périphérique LUKS de son hibernation.
luksHeaderBackup  - Sauvegarder l'en-tête et les emplacements de clés du périphérique LUKS
luksHeaderRestore  - Restaurer l'en-tête et les emplacements de clés du périphérique LUKS
luksDelKey   - identique à luksKillSlot - OBSOLÈTE - voir la page de man
reload   - modifier le périphérique actif - OBSOLÈTE - voir la page de man

 est le périphérique à créer dans /dev/mapper
 est le périphérique chiffré
 est le numéro de l'emplacement de clé LUKS à modifier
 est un fichier optionnel contenant la nouvelle clé pour l'action luksAddKey

Default compiled-in device cipher parameters:
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS1: aes-cbc-essiv:sha256, Key: 256 bits, LUKS header hashing: sha1

Tout d'abord, il faut initialiser une partition vierge (ou si elle ne l'est pas, la backupper, et la cleaner pour qu'elle le soit). Comme moi je n'en ai pas de dispo et que je souhaite quand même jouer un peu, je vais en créer une de toute part de 400M.

$ head -c 400M /dev/zero > luksdev
$ losetup /dev/loop0 luksdev
$ cryptsetup luksFormat /dev/loop0

WARNING!
========
Cette action écrasera définitivement les données sur /dev/loop0.

Are you sure? (Type uppercase yes): YES
Entrez la phrase de passe LUKS :
Verify passphrase:

Et la commande nous rend la main. Si vous êtes sceptique, et je le suis, vous pouvez toujours voir ce qui se passe sur votre partition :

$ cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 2056
MK bits:        256
MK digest:      0b 62 b6 db 1b 4d bf 99 1e 36 7a de 4b 07 00 49 56 a7 bc bd
MK salt:        b3 49 2e 88 5b 11 fc 02 d2 74 70 24 a7 54 2c b1
9a 9e dc f3 04 cd 83 52 20 db 88 d7 95 34 25 a3
MK iterations:  17250
UUID:           f19343f6-a783-498f-8304-c6bbf536ede5

Key Slot 0: ENABLED
Iterations:             69360
Salt:                   50 e3 ee 05 3d 19 f7 14 80 ee 24 db 66 69 7e 3e
cf 15 38 0d e9 77 47 43 85 bc ed bc 2a 46 37 02
Key material offset:    8
AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Nous avons crée la Master Key comme en témoigne le retour du luksDump avec champs MK (MK bits, MK digest, MK salt et MK iterations). Passons au password pour la verrouiller.

$ cryptsetup luksAddKey /dev/loop0
Entrez une phrase de passe :
Entrez une nouvelle phrase de passe pour l'emplacement de clé :
Verify passphrase:

Attention, ici, c'est la passphrase définie à l'initialisation qui est demandée en premier. Si vous vous trompez, il bronchera et finira la commande :

$ cryptsetup luksAddKey /dev/loop0
Entrez une phrase de passe :
Aucune clé n'est disponible avec cette phrase de passe.

Pour être certain, relançons un luksDump :

$ cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 2056
MK bits:        256
MK digest:      0b 62 b6 db 1b 4d bf 99 1e 36 7a de 4b 07 00 49 56 a7 bc bd
MK salt:        b3 49 2e 88 5b 11 fc 02 d2 74 70 24 a7 54 2c b1
9a 9e dc f3 04 cd 83 52 20 db 88 d7 95 34 25 a3
MK iterations:  17250
UUID:           f19343f6-a783-498f-8304-c6bbf536ede5

Key Slot 0: ENABLED
Iterations:             69360
Salt:                   50 e3 ee 05 3d 19 f7 14 80 ee 24 db 66 69 7e 3e
cf 15 38 0d e9 77 47 43 85 bc ed bc 2a 46 37 02
Key material offset:    8
AF stripes:             4000
Key Slot 1: ENABLED
Iterations:             65540
Salt:                   1f 23 24 2b 59 3a b6 12 ff 98 e5 b5 f4 bc d9 34
b5 af b4 64 a1 9a 3d 19 9e 07 7d 10 ba fb a2 0d
Key material offset:    264
AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

On voit que le Key Slot 1 a été activé et contient des infos. Comme je vous l'ai dit précédemment, on peut ajouter au plus 8 clés, et c'est un élément qu'on retrouve dans le nombre de key slots à disposition. Admettons qu'une des clés -on en a qu'une, ça facilite- a été compromise. Il suffit alors de la supprimer ! Ici, par exemple, je supprime la clé du key slot 1 :

$ cryptsetup luksDelKey /dev/loop0 1
luksDelKey is a deprecated action name.
Please use luksKillSlot.
Entrez une phrase de passe LUKS qui restera valide :

$ cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0
[...]
Key Slot 0: ENABLED
Iterations:             69360
Salt:                   50 e3 ee 05 3d 19 f7 14 80 ee 24 db 66 69 7e 3e
cf 15 38 0d e9 77 47 43 85 bc ed bc 2a 46 37 02
Key material offset:    8
AF stripes:             4000
Key Slot 1: DISABLED

Entre temps; j'ai défini une deuxième clé, qui occupe le Key Slot 2. Et par luksKillSlot :

$ cryptsetup luksKillSlot /dev/loop0 1
Entrez une phrase de passe LUKS qui restera valide :

$ cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0
[...]
Key Slot 0: ENABLED
Iterations:             69360
Salt:                   50 e3 ee 05 3d 19 f7 14 80 ee 24 db 66 69 7e 3e
cf 15 38 0d e9 77 47 43 85 bc ed bc 2a 46 37 02
Key material offset:    8
AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: ENABLED
Iterations:             74283
Salt:                   6e 45 60 fa 5e 93 f8 26 51 9f f6 9b 86 09 7d 32
77 9d 28 f9 a8 10 a1 21 8e 16 39 40 7b 43 93 09
Key material offset:    520
AF stripes:             4000
[...]

Bref, vous avez saisi, il existe plein d'autres options qui permettent de gérer finement la partition.

L'après-LUKS est encore du LUKS

C'est bien beau tout ça me direz-vous, mais comment on fait pour l'utiliser, ta partition ? Et bien comme pour toutes les nouvelles partitions, il faut formatter ! Et pour cela, il faut encore passer par LUKS avant d'utiliser vos outils dédiés au formatage (oui, souvenez-vous, la structure logique a été spécialisée). En réalité, on invoque luksOpen qui a pour rôle d'"ouvrir" le volume crypté. On lui fournit, en plus de votre partition, le nom souhaité du mapping. Le tout sera alors monté sur /dev/mapper/

$ cryptsetup luksOpen /dev/loop0 luksmnt
Entrez la phrase de passe pour /dev/loop0 :

$ ll /dev/mapper/luksmnt
brw-rw---- 1 root disk 252, 0 2010-07-28 14:52 /dev/mapper/luksmnt

Une fois cette ouverture faite, vous pouvez tout à fait invoquer mkfs.ext4 sur /dev/mapper/luksmnt.

$ /sbin/mkfs.ext4 /dev/mapper/luksmnt
mke2fs 1.41.9 (22-Aug-2009)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=1024 (log=0)
Taille de fragment=1024 (log=0)
102400 i-noeuds, 408572 blocs
20428 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=1
Nombre maximum de blocs du système de fichiers=67633152
50 groupes de blocs
8192 blocs par groupe, 8192 fragments par groupe
2048 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Écriture des tables d'i-noeuds : complété
Création du journal (8192 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

Le système de fichiers sera automatiquement vérifié tous les 25 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.

Si vous souhaitez l'utiliser tel quel, n'oubliez pas de le fermer après usage avec luksClose, mais le mieux tout de même, ce serait de l'intégrer au système et de la monter automatiquement. Pour la monter automatiquement, il vous faut créer le fichier /etc/crypttab tel que :

$ cat /etc/crypttab
#                 
luksmnt /dev/loop0  none    luks

Et retoucher la fstab en accord avec le crypttab, en sachant que c'est le crypttab qui sera évidemment examiné en premier :

$ cat /etc/fstab | grep luks
/dev/mapper/luksmnt /mnt/luks ext4 defaults 0 1

Le mount -a ne bronche pas et vous avez un joli :

$ mount | grep luks
/dev/mapper/luksmnt on /mnt/luks type ext4 (rw)

$ df -h /mnt/luks/
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/luksmnt   387M   11M  357M   3% /mnt/luks

$ ll /mnt/luks/
total 12
drwx------ 2 root root 12288 2010-07-28 15:01 lost+found/

Petit précis sur mon montage en loopback d'un fichier, pour le démonter, il suffit de lancer après le luksClose un :

$ losetup -d /dev/loop0

Mais bon, ça n'a rien à voir avec LUKS...

Conclusion

Quand on veut donner dans la parano (mais enfin, qui ne l'est pas ?), LUKS a tout ce qu'il faut là où il faut. Deux ou trois points méritent d'être soulignés au terme de ce tip :

LUKS se fait en amont de toute chose, il n'est pas orienté conversion de partition et encryptage à la volée. Si vous souhaitez le mettre en place, je vous conseille donc de le faire avant toute chose, et en évitant de préférence les partitions liées au boot.
Le niveau de sécurité de l'ensemble équivaut celui du maillon le plus faible, c'est-à-dire la passphrase. Si vous voulez jouer, mais que votre passphrase (ou celles de vos utilisateurs) est faible, le niveau de sécurité s'en ressentira.
LUKS utilise des ressources, donc négociez bien le tir avec les postes utilisateurs (mais bon, il est possible de le renicer).
LUKS n'est pas transparent, au boot, si vous avez paramétré l'automount via la fstab, un password sera demandé. Il est possible de faire en sorte que l'authentification de l'utilisateur suffise à LUKS, mais comme je vous l'ai dit, ça ne fait que rabaisser la sécurité. Si vous êtes tout de même intéréssé, visez libpam-mount.

Maintenant que tout est dit -ou presque-, je vous laisse tranquillement revoir vos plans de conquête du Monde à la hausse. ENJOY !

SystemImager : concepts d’une solution d’automatisation de déploiement

K-TUX — Sun, 04 Jul 2010 14:59:59 +0000

SystemImager est un projet très abouti qui permet de gérer l'installation et le déploiement de logiciel et de distribution Linux, tout en s'appuyant des outils standards comme SSH et rsync. Il se distingue très nettement des outils comme Fedora kickstart et Debian debootstrap dans la mesure où il est capable de gérer plusieurs architectures et distributions différentes. D'autre part, la finesse des petites customisations et tout ce qui pourrait sortir du standard des dépôts est directement prise en compte et appliquée, sans avoir à se confronter aux fameux scripts de post-installation. En ce sens, cela fait de lui l'outil incontournable pour une gestion de parc uniforme et automatisée. Son fonctionnement est simple : il aspire dans un premier temps tout ou partie d'un système de fichier (on peut spécifier des exclusions ou même en créer un viable, via les outils du package) qu'il stocke tel quel au sein d'un dépôt d'image. Il s'agit ensuite de rebalancer l'arborescence, soit pour une installation complète, soit pour un alignement des version. Du fait que le système de fichier soit stocké en l'état, il est alors très facile de modifier et contrôler le contenu de l'image avant déploiement. La seule contrainte concerne les clients et requiert une parfaite adéquation dans le nombre de disques durs des noeuds sous la juridiction de SystemImager. La capacité peut varier, mais attention aux disques plus petits que ceux du GoldenClient. En effet, si l'on venait à balancer une install qui ne tiendrait pas sur le disque, cela ferait désordre. Pour pouvoir entrer dans les détails, il est nécessaire de définir les notions sur lesquelles s'appuie SystemImager.

Les éléments

L'image server

SystemImager a besoin d'un maître d'orchestre, appelé le serveur d'image, afin de pouvoir centraliser toute la partie gestion des images et des noeuds. Notre serveur contiendra donc tous les packages et toute la configuration nécessaire à SystemImager. La racine de SystemImager se situe au niveau de /var/lib/systemimager, et est enrichie de plusieurs éléments :

# ll /var/lib/systemimager/
total 28
-rw-r--r--  1 root root 14361 2010-06-29 11:13 clients.xml
drwxr-xr-x  9 root root  4096 2010-06-23 10:21 images/
drwxr-xr-x 55 root root  4096 2010-06-23 10:21 overrides/
drwxr-xr-x  4 root root  4096 2010-06-23 10:21 scripts/

Les explications relatives aux différents éléments seront fournies un peu plus loin. Afin de pouvoir distribuer les images correctement -et surtout lors du boot PXE-, le server devra regrouper le duo TFTP server et DHCP server. A noter que SystemImager permet de rapidement mettre en place une configuration complète de serveur de boot grâce à l'outil si_mkbootserver, intégré au package systemimager-server. Il existe plusieurs façons d'installer via SystemImager. PXE, comme nous l'avons mentionné un peu plus haut, Bittorent, ou par multicast. Ces variations sont à l'origine de certains packages qui ont été spécialement crée sur ces spécificités. A titre d'information, les packages intéressants sont :

systemimager-server : le core du serveur SystemImager,
systemimager-common : les outils qui vont avec,
systemimager-*boot-standard : les outils relatifs à la partie boot server, * regroupe i386 et x86_64

systemimager-server-flamethrower* : pour utiliser le mode multicast
systemimager-server-bittorrent : pour utiliser le mode BitTorrent.

Il va sans dire que, si vous projetez d'installer plusieurs distributions, il faudra assurer au niveau stockage des images. Même réflexion concernant la partie réseau, surtout si l'intention de virtualiser vous taraude. Le paramétrage fin de SystemImager se fait comme d'habitude, via un fichier de configuration : /etc/systemimager.conf, ou /etc/systemimager/systemimager.conf.

Les nodes

Les nodes sont les postes clients qui vont faire l'objet d'une installation automatisée par SystemImager. Ils sont rattachés préalablement à une image bien précise, et optionnellement à un ou plusieurs overrides. Accessoirement, ils disposent d'une entrée dans le fichier /etc/dhcpd.conf du serveur afin de pouvoir obtenir une adresse et pouvoir rapatrier, via TFTP par exemple, un noyau minimal qui se chargera de l'installation. Le paramétrage des clients et leur association à une image peut passer par si_addclients (c'est d'ailleurs historique)ou par si_clusterconfig. Je ne vous éplucherais pas toutes les options qui sont disponibles, sachez que vous pouvez absolument tout faire, grouper vos clients en liste FQDN, IP, avec un domainname qui leur pend, en interactif,... Bref, man est votre meilleur ami. On retrouve les informations relatives aux nodes dans le fichier /var/lib/systemimager/clients.xml. Point important, si_clusterconfig est un outil au-dessus de la gestion de node, c'est-à-dire qu'il définit l'ensemble de votre cluster en terme de groupe, de priorité, d'image, d'override, et de node.

Le GoldenClient

Le GoldenClient est un poste de même calibre que les nodes, et qui leur servira indirectement de référence. Il doit être installé et configuré manuellement et est à l'origine de l'image référente que vous déployerez. systemimager-common et systemimager-client devront être présents sur le GoldenClient.

Les images

Les images sont des répertoires chrootables qui contiennent l'intégralité du système de fichier à déployer sur les clients. Elles sont identifiées par un nom intelligible, fourni en entrée lors de leur récupération du GoldenClient. Toutes les images sont stockées sous la racine de SystemImager, c'est-à-dire sous /var/lib/systemimager/images. Gardez sous le coude si_lsimage pour les voir, si_rmimage pour les supprimer et surtout si_getimage pour en rapatrier une (oui, aussi si_mvimage et si_cpimage mais pas besoin de vous expliquer ce que ça vaut).

Les overrides

Parce qu'on ne va pas stocker plusieurs systèmes de fichiers juste pour une différence de configuration sur une poignée de fichiers, SystemImager a défini la notion d'override. Les overrides concernent les customisations appliquées à une image en particulier, il y peut donc y avoir plusieurs overrides pour une image. De la même façon que les images ont un nom, les overrides en disposent également d'un. Les overrides contiennent une portion de l'arborescence du système de fichier, qui diffère de celle proposée par l'image, et qui viendra écraser celle issue de l'image originale après que celle-ci ait été mise en place.

ls overrides/ide/
boot/  etc/

On retrouve les overrides sous /var/lib/systemimager/overrides, et pour les pousser sur les nodes, il vous suffit d'un si_pushoverrides.

Fonctionnement

Voila commence ça se passe... Premièrement, vous avez dû monter, à la sueur de votre front, votre petit serveur DHCP/TFTP/SystemImager. Deux-trois tips sympa qui vous permettront d'avancer rapidement : - si_mkdhcpserver / si_mkdhcpstatic, qui va vous arquer sur la configuration d'un DHCP opérationnel, - si_mkbootserver, pour l'aspect PXE / TFTP, - /etc/systemimager/systemimager.conf, pour la conf. Et puis on attaque le gros œuvre !

From Scratch ! L'installation automatisée

Le plus pénible d'abord. Prenez votre GoldenClient et, gentillement, patiemment, installez-le et configurez au poil toutes les options qui vont bien. Saupoudrez de systemimager-common et de systemimager-client, vos petits outils qui vous sauveront une énorme quantité de temps. N'oubliez pas de customiser le /etc/systemimager/client.conf pour tout ce qui est port d'adressage, exclude,... si_prepareclient va vous permettre de lancer tout ce qui va bien -rsync, fichiers,... afin que votre server SystemImager puisse récupérer l'image. En clair, il déduit de la conf actuelle toutes les informations utiles, dont le partitionnement des disques.

$ si_prepareclient  --server kaster
Welcome to the SystemImager si_prepareclient command.  This command may modify
the following files to prepare your golden client for having it's image
retrieved by the imageserver.  It will also create the /etc/systemimager
directory and fill it with information about your golden client.  All modified
files will be backed up with the .before_systemimager-4.1.6 extension.

/etc/services:
This file defines the port numbers used by certain software on your system.
Entries for rsync will be added if necessary.

/tmp/filerNi0f5:
This is a temporary configuration file that rsync needs on your golden client
in order to make your filesystem available to your SystemImager server.

inetd configuration:
SystemImager needs to run rsync as a standalone daemon on your golden client
until it's image is retrieved by your SystemImager server.  If rsyncd is
configured to run as a service started by inetd, it will be temporarily
disabled, and any running rsync daemons or commands will be stopped.  Then,
an rsync daemon will be started using the temporary configuration file
mentioned above.

See "si_prepareclient --help" for command line options.

Continue? (y/[n]): y
*********************************** WARNING ***********************************
This utility starts an rsync daemon that makes all of your files accessible
by anyone who can connect to the rsync port of this machine.  This is the
case until you reboot, or kill the 'rsync --daemon' process by hand.  By
default, once you use si_getimage to retrieve this image on your imageserver,
these contents will become accessible to anyone who can connect to the rsync
port on your imageserver.  See rsyncd.conf(5) for details on restricting
access to these files on the imageserver.  See the systemimager-ssh package
for a more secure method of making images available to clients.
*********************************** WARNING ***********************************

Continue? (y/[n]): y

Signaling xinetd to restart...
...
Using "sfdisk" to gather information about disk:
/dev/sda

[...]
>>> Choosing filesystem for new initrd:  cpio
>>> Creating new initrd from staging dir:  /tmp/.systemimager.0
>> cd /tmp/.systemimager.0 && find . ! -name "*~" | cpio -H newc --create | gzip -9 > /etc/systemimager/boot/initrd.img
123093 blocks
>> ls -l /etc/systemimager/boot/initrd.img
-rw-r--r-- 1 root root 44150730 Jul  1 16:02 /etc/systemimager/boot/initrd.img

>> Evaluating initrd size to be added in the kernel boot options
>> (e.g. /etc/systemimager/pxelinux.cfg/syslinux.cfg):
>>     suggested value -> ramdisk_size=71786.5

>>> Using kernel from:          /boot/vmlinuz-2.6.31.13-server-1mnb
>> ls -l /etc/systemimager/boot/kernel
-rw-r--r-- 1 root root 2748752 Jul  1 16:02 /etc/systemimager/boot/kernel

Starting or re-starting rsync as a daemon.....
done!

This client is ready to have its image retrieved.  You must now run
the "si_getimage" command on your imageserver.

Your client has been successfully prepared.  Boot kernel (copied from
this Linux distribution) and an initrd.img (generated by the
initrd_template package) can be found in /etc/systemimager/boot.

Automatically create configuration file for systemconfigurator:
>> /etc/systemconfig/systemconfig.conf

Ici, le transport se fera par rsync, mais il est possible d'utiliser rsync over SSH, BitTorrent, multicast,... Switchez sur votre serveur SystemImager et lancez le si_getimage qui va bien, avec -golden-client et image en entrée. En optionnel, des options sur des exclusions, les assignements IP, le comportement postinstallation (reboot, beep, shutdown,...), bref, de quoi bien jouer. Une fois l'image rapatriée, et mise au frais, si_clusterconfig -e pour organiser votre cluster -tel node va avec telle image, tel overrides,... Pour la petite idée de ce à quoi ça ressemble :



kaster
absolutely_all_nodes
override_for_absolutely_all_nodes

kluster.knBSD.overBSD
1
knBSD
overBSD
knod1


kluster.kDeb.overDeb
2
kDeb
overDeb
knod2,knod3,knod4

Tous vos nodes paramétrés bien comme il faut dans votre SystemImager, il ne vous reste plus qu'à forcer leur boot réseau avec si_mkclientnetboot...

si_mkclientnetboot --client=knod2 --netboot
[netboot] using the kernel and initrd.img for architecture: i386
[netboot] using the flavor: standard

...Et de les rebooter en PXE. si_pushinstall prend alors le contrôle des choses et le server va tout simplement redescendre par SSH, brute de force, l'image sur le node.

Les synchronisations

Evidemment, je vous avais parlé de SystemImager en tant qu'outil de déploiement d'OS, oui, mais de logiciel également. En soi, le processus est le même, il s'agit d'une synchronisation -initiée par le serveur SystemImager à destination des nodes- entre l'image assignée au node et le système de fichier du node en lui-même. Ce qui diffère, ce sont les outils.

si_pushupdate

L'outil adapté à tout ce qui doit découler d'une mise à jour de l'image référente. si_pushupdate va, ici via rsync, transférer tout ce qui manque du server aux nodes. Vu que c'est du rsync, la gestion de la bande passante est optimisée -on ne redescend pas absolument toute l'image-, malgré tout, le multicast est, à mon avis, beaucoup plus adapté à ce genre de redescente, surtout si vous avez beaucoup de node à mettre à jour.

si_pushupdate --server kaster --hosts="knod2"
knod2 : ======================= WARNING =================================
knod2 :  This command will update this host with the image: kDeb
knod2 :  and overrides (in order of importance):
knod2 :
knod2 :  overDeb, override_for_absolutely_all_nodes
knod2 :
knod2 :  Some files could be deleted or overwritten, so probably it is a
knod2 :  good idea to run this command with --dry-run before and stop the
knod2 :  production on this host.
knod2 : ======================= WARNING =================================
knod2 :
knod2 : Are you sure to continue? (y / N)? y
knod2 : [...]
knod2 : Excluding (filesystem ext2): /tmp
knod2 : >> Updating image from module kDeb...
knod2 : receiving incremental file list
knod2 : deleting .readahead_collect
knod2 : sent 86986 bytes  received 23829894 bytes  621217.66 bytes/sec
knod2 : total size is 10895198915  speedup is 455.54
knod2 : >> Updating image from module overrides/override_for_absolutely_all_nodes...
knod2 : Running bootloader...Kernel /boot/...

si_pushoverrides

Comme son nom l'indique, il s'agit en réalité non pas d'aligner le node avec son image mais avec ses overrides.

si_pushoverrides -v knod2
Building clients list...
Grouping clients by common overrides...
WARNING: in case of file overlaps the overrides will be distributed using the following order (first hit wins):
WARNING: -->
Performing the updates...
>> si_pcp -v    -n knod2 /var/lib/systemimager/overrides/overDeb/ /
knod2 :/: sending incremental file list
[...]
knod2 :/: sent 898 bytes  received 203 bytes  734.00 bytes/sec
knod2 :/: total size is 2510  speedup is 2.28

Le monitoring

Monitorer un node revient, sous SystemImager, à se faire une idée d'où il en est au niveau de l'installation. Pour cela, SystemImager exploite grandement /var/lib/systemimager/clients.xml et met à disposition 2 outils, l'un étant la version graphique de l'autre, il s'agit de si_monitor et si_monitortk.

Conclusion

SystemImager apporte donc une réponse simple, complète et très satisfaisante aux besoins d'automatisation d'installation et de déploiement. De par ce fait, il est tout-à-fait dans la ligne de mire des exploitation en cluster, et se marie très bien avec des systèmes de répartition de charge dans des environnements de calcul, comme c'est le cas pour OSCAR, Torque, MAUI, et autres. Attention toutefois, car même s'il correspond également au besoin d'uniformisation dans un parc constitué de postes de travail, il peut s'avérer que la synchronisation provoque des problèmes d'incohérence et d'instabilité au niveau de l'environnement graphique ou du noyau, selon ce qui a été mis à jour. Il est donc sage de l'utiliser avec parcimonie quand vous êtes en première ligne face à vos utilisateurs. Il ne vous reste plus qu'à vous en faire une idée par vous-même, et, pourquoi pas, l'adopter !

Git : quand un filesystem fait du versionning

K-TUX — Sat, 26 Jun 2010 18:45:50 +0000

Etrange tout de même. Quand on touche aux problématiques de gestion de version, on retrouve, parmi les grands noms -CVS, SVN, Mercurial, ...- un nom court, bizarre, et quand on remonte plus loin, attisé par la curiosité, on tombe sur un post de son concepteur, Linus Torvalds, qui clame haut et fort que c'est un embryon de filesystem. Alors Git, c'est quoi ? Pourquoi est-il aussi présent en tant que gestionnaire de version ?

Présentation

Comme je vous l'ai dit, Git n'est pas un SCM (Source Code Management system), ou du moins, il n'était pas destiné à l'être. Il regroupe en réalité toutes les fonctionnalités d'un filesystem, et dispose d'un trousseau d'outils de bas niveau directement développé pour des problématiques de systèmes de fichier. Ses caractéristiques sont les suivantes :

c'est un outil simple, de bas niveau, donc efficace.
c'est un outil communautaire, qui s'appuie sur le partage des données en peer-to-peer like. Il n'y a donc pas de centralisation des informations ni des rôles / accès. Chacun est libre de cloner un dépôt, d'y travailler dessus et de mettre le dépôt distant à jour.
il fonctionne sur la base d'une somme de contrôle SHA-1 pour évaluer quelles données ont été modifiées,
- ainsi la donnée n'est stockée qu'une fois par état
- l'identification et adressage de la donnée se basent sur la somme SHA-1 qui agit alors comme un index
- cela permet une uniformisation des noms de fichiers quelque soit le dépôt
- Git peut effectuer un contrôle du fichier en comparant son vrai hash à celui de son index
Git stocke les données telles quelles, et non sous forme de diff (contrairement à Mercurial, CVS, SVN,...)
Git est implémenté pour plusieurs OS

Fonctionnement

En interne, Git contient 2 types d'instances :

Une base de donnée d'objet, située sous .dircache sous le nom d'objects, et qui contient :
- des blob - Binary Large OBject -, contenu binaire du fichier versionné, qui n'est pas directement lié au nom de fichier d'origine contenant la donnée et à son chemin. Il est facile d'accéder au contenu d'un blob via la commande
```
git show
```
- un tree, liste d'objet de type blob associés à des info complémentaires : nom du fichier, permissions. Il décrit l'état d'une hiérarchie de fichier à un état donné. On peut utiliser pour examiner un objet de type tree :
```
git show
git ls-tree
```
- un commit -ou changeset-, historique d'une arborescence de fichiers, qui lie un tree à la description des nouveaux changements fournis lors du git commit. On peut le lire via :
```
git show
git log
```
  Un commit est défini par :
  - un objet de type log, mentionnant par exemple l'auteur du commit, le commiter et un commentaire.
  - un objet de type tree
  - des pointeurs sur les commits parents -le commit initial n'a pas de parent bien sûr-
- des tags, sorte de qualificatif de commit. Il peut être exploité grâce à l'invocation des commandes
```
git tag
git cat-file
```

Un Directory cache

Le directory cache est un unique objet binaire contenant un objet tree. Il est représenté par le fichier index situé sous .dircache. Il permet de stocker l'état d'une arborescence à un instant t. Cet état ne sera pas forcément mis à jour, notamment après un pull d'un dépôt extérieur ou de modifications local (c'est un cache, quoi). Il est lié à un dépôt, et est crée lors de sa création from scratch (init-db), l'ajout et la mise à jour du cache passant par update-cache. Toutes les données relatives à un projet se situent dans un répertoire unique -par défaut nommé .git- et situé à la racine du projet. Il contient toute l'arborescence nécessaire pour stocker les informations :

|-- HEAD         # pointeur vers la branche courante
|-- config       # configuration des préférences
|-- description  # description du projet
|-- hooks/       # pre/post actions hooks
|-- index        # fichier d'index
|-- logs/        # un historique de la branche
|-- objects/     # les objets (commits, trees, blobs, tags)
`-- refs/        # pointeurs vers les branches

Une distinction est à opérer concernant le répertoire de Git et le répertoire de travail. Le répertoire de travail est en fait la localisation du projet en cours, et sa composition est automatiquement accordée selon la branche sur laquelle vous travaillez. Cette mise à jour du contenu du répertoire de travail est entièrement opérée grâce au répertoire Git qui contient toutes les informations nécessaires. Il s'agit en quelque sorte d'un cache temporaire qui permet d'offrir le support avant de committer les modifications. Tout Git repose sur les hash SHA. Quand un nouvel objet est ajouté à la base de données, il subit une compression (zlib), puis un hash et la checksum résultante (tout du moins les 2 premiers bits) va permettre d'identifier l'objet dans la base de données. Enfin l'objet est stocké. Comme aucun élément mis à part le suivi du commit peut lier une donnée à une version, Git a la mauvaise manie de stocker la donnée intégrale plutôt que de procéder par des diff par rapport aux versions précédentes, ce qui peut amener une forte consommation des ressources.

Mais cette différence implique également que Git soit plus rapide, puisqu'il n'y a pas à reconsidérer tout un historique et de devoir reconstruire la donnée lors de l'accès à une version spécifique.

En externe, Git exploite plusieurs notions qu'il faut connaitre pour pouvoir manipuler l'outil sans problème.

Le dépôt

Le dépôt est un espace bien particulier qui contient un projet. Cet espace est accessible par toute la communauté, c'est-à dire partagée via HTTP, SSH, ou Git, tout simplement.

Le projet

Le projet est constitué de l'arborescence dans lequel se trouvent vos données. Ses moindres changements d'état sont consignés par Git, mais il n'est généralement accessible qu'en local. Il est destiné à être le support de toute modification éprouvées et testées, avant de pouvoir mettre à jour le dépôt relatif à ce projet. En clair, cela commence lorsque vous rapatriez un projet depuis un dépôt. Vous avez alors votre propre projet à vous.

Les branches

Les branches sont un peu comme un projet dans un projet. C'est un environnement distinct de la branche principale et dont le contenu est à intégrer à terme au projet. Cela permet notamment de développer des fonctionnalités de manière indépendante et puis de pouvoir les intégrer à un instant donné, sans avoir à mettre tout le projet en quarantaine le temps du développement. Maintenant que nous en savons un peu plus sur ce qui se trame dans la mécanique infernale de Git, nous sommes fins prêts pour...

Les travaux pratiques

Installation

Git offre un support d'installation pour chacune des 3 grandes distributions :

Linux, la plupart du temps, via les dépôts officiels de la distribution, sinon via les sources,
Mac OS X, grâce à MacPort (MacPort sudo port install git-core) ou via un installer,
Windows, via un exécutable.

Configuration

La configuration de Git est très sommaire et consiste à vous identifier pour consigner chacune de vos modifications dans les projets : un nom, un mail, et le tour est joué.

git config --global user.name "K-Tux"
git config --global user.email "K-Tux@bux.com"

Vos paramètres seront sagement consignés dans ~/.gitconfig si vous avez précisé l'option --global (donc pour tous vos projets), sinon dans chacun des .git/.config de vos projets.

Dépot

Afin de pouvoir utiliser Git, il faut alors disposer d'un dépôt. Pour cela, vous avez le choix. Soit vous intégrez une équipe sur un projet, et donc vous récupérez le dépôt de ce projet, soit vous êtes à l'origine du projet, et il vous faut alors en créer un.

Création

La création d'un dépôt est très simple. Il suffit de se placer au niveau des sources, à la racine du projet à gitter, et de lancer un :

git init

Récupération

Pour récupérer un dépôt -on parle alors de cloner-, il suffit de lancer la commande :

git clone git://git.kernel.org/pub/scm/git/git.git

Mais vous pouvez spécifier votre propre URL de dépôt. Pas de panique, cela ne signifie pas que vous devez monter un web server en urgence, Git s'accommode très bien d'URL tapant sur du SSH, sur du HTTP, ou sur... bah du git. Vous récupérerez donc un répertoire copie conforme de celui du serveur et qui aura le nom de celui stipulé dans l'URL, le .git en moins.

Merge de projet

git pull ...

La commande sert à rapatrier un projet depuis un dépôt distant ou bien depuis une branche différente, mais effectue également un merge des 2 projets. Le merge sera alors disponible en local. Vu qu'il s'agit de merge, il peut en résulter des conflits qu'il faudra résoudre.

Mise à disposition d'un dépôt

La mise à disposition d'un dépôt peut utiliser un serveur HTTP, ou bien être accessible via SSH, comme on a pu le voir, mais il se trouve que Git propose également un moyen de partage beaucoup plus efficace. Pour pouvoir mettre à disposition un projet via un dépôt Git, il faut d'abord correctement le nommer. Pour cela, tapez juste :

git clone prj prj.git

Il faut aussi indiquer à Git si oui ou non il doit exporter le projet :

touch prj.git/git-daemon-export-ok

Et puis, bah oui, replacer le projet là où ça fait bien, sur votre petit serveur de dépôt.

En deux minutes, pour la lecture

git-daemon est un utilitaire qui permet de mettre à disposition en lecture un projet via un dépôt Git. L'outil est multifonction et se lance avec la ligne de commande :

git-daemon --base-path=/var/depots --listen=ipserver --user=git_user --group=git_group --detach --verbose

Et c'est opérationnel ! Le daemon tournera alors sur le port 9148, écoutera sur l'IP spécifiée par le --listen en utilisant l'utilisateur git_user et le groupe git_group. L'option --detach permet de lancer le daemon en arrière-plan, tout en utilisant les facilités de syslog. Plusieurs autres options sont disponibles, certaines concernent d'ailleurs le virtual hosting, à l'image de celui d'Apache. Pour cela, tombez le --base-path et jouez avec —interpolated-path.

Et pour l'écriture

C'est le souci de git-daemon. Il ne prend pas en charge l'écriture, c'est-à-dire la mise à jour par la communauté des données du dépôt. Il leur faudra donc passer par un traditionnel :

git push ...

Gestion d'un projet

Ajout de données au projet

L'ajout de données au sein d'un projet est fait par :

git add file1 file2 ...

Cet ajout correspond à la mise à jour de l'index sur les fichiers à monitorer. Avant de committer, vous pouvez toujours vérifier les différences entre ce qui existe déjà et vos modifications via git diff, et le récapitulatif via un :

git status

Commit des données modifiées

git commit

vous permet de valider vos données modifiées. A noter que git commit -a permet non seulement d'ajouter vos données mais également de les valider. Vous avez la possibilité d'avoir un aperçu de l'état actuel du projet grâce à git status. Si vous avez fait une boulette et que vous souhaitez revenir à un état donné,

git reset ...

prendra en compte le hash de l'état sur lequel vous voudriez vous remettre.

Les branches

La notion de branche est bien familière aux développeurs. Il s'agit en fait d'un environnement dédié, séparé du tronc principal du projet, qui fait l'objet de labo, afin de tester et d'implémenter de nouvelles fonctionnalités sans impacter la prod. D'ailleurs, cette différenciation implique qu'une branche prod soit effective. Dans Git, la branche principale est appelée master. Par défaut, elle est la seule branche présente, donc celle sur laquelle vous travaillez, mais il est facile d'en créer d'autres. Le nombre de branche n'est pas limité, en revanche, ce qui pose souvent souci, c'est justement de les merger tout en gardant la stabilité et la richesse des données de chacune d'entre elle. Git, comme tout bon SCM qui se respecte, permet de gérer efficacement les branches.

Création d'une branche

La création et le listing des branches passent par la commande

git branch

Pour créer une nouvelle branche, il faut fournir son petit nom en entrée, par exemple :

git branch dev

Le listing nous montre alors les différentes branches, la petite * permet de nous situer la branche sur laquelle on travaille.

git branch
dev
* master

Lorsque l'on veut travailler sur la branche dev, mais que l'on se trouve sur la master, il faut appeler

git checkout dev

Merge d'une branche

Lorsque l'on veut merger deux branches, il suffit de se mettre sur la branche destination et de lancer un

git merge branch-à-merger

Ce geste anodin semble sympatique, mais peut se révéler moins compréhensif lors de la détection de conflit.

CONFLICT (content): Merge conflict in bux.pl
Automatic merge failed; fix conflicts and then commit the result.

Le souci, c'est que la détection de conflit n'est pas évaluée avant le merge, ce qui amène Git à mettre un projet dans un état incohérent, ayant mergé tout ce qu'il pouvait jusqu'au conflit. Vous devez donc tout recoudre avec vos petites mains. Bon, vous n'êtes pas perdu, car dans les éléments impliqués (ici notre bux.pl), Git indique l'état des 2 branches avant le merge. A vous donc de décider laquelle est la plus appropriée dans ses traitements. Bien sûr, Git vous met à dispo tout un trousseau pour remonter jusqu'au problème

git status
git log
git bisect

Dé-merger une branche

Pour défaire un merge qui s'est -vraiment- très mal passé, il vous suffit de taper

git reset --hard HEAD

Cela restaurera l'état d'avant la merge.

Et caetera...

Cette petite introduction nous montre juste une partie des capacités de l'outil. D'ailleurs, on regrettera l'aspect un peu "fouilli" de Git, mais je reconnais facilement que ce pêle-mêle d'outils est très riche et trouve facilement son intérêt dans le versionning. En tout cas, la communauté est active car la dernière version en date est du 24/04/2010. Pas de doute que l'outil continuera à prendre de l'ampleur, quitte à finir par avoir sa place en tant que filesystem. D'ailleurs, pour les plus curieux d'entre vous -et les pires-, ce mois-ci, le numéro 129 de Linux Mag propose une exploitation assez surprenante de Git avec... SVN. Je n'ai pas encore eu l'occasion de mettre la main dessus, ce qui ne m'empêche pas de vous encourager à le lire !

Troubleshooting : UUID + Initrd + publication de noyau = Timeout

K-TUX — Wed, 24 Mar 2010 12:49:27 +0000

Pour certains systèmes d'installation automatisée, comme SystemImager , il est possible de mettre à jour absolument tout et n'importe quoi, simplement par rsync ou en utilisant le mode de transport multicast . Et parfois, suite à cette mise à jour, et surtout quand elle touche le contenu du /boot, on peut être amené à constater, lors du reboot, l'apparition de messages concernant des timeout sur les disques supportant le système. Petites pistes pour traquer l'origine du problème -qui n'en est pas vraiment un, vu que le timeout passé, le boot se fait normalement-.

UUID

Avant toute chose, un petit précis s'impose. Un UUID, comme Universal Unique Identifier, sert à identifier de manière formelle et catégorique un device, que ce soit un disque dur, un device USB, bref, tout ce qui touche au matériel. Il est facile de les retrouver ou de les intégrer dans la fstab et dans le menu.lst de GRUB. Beaucoup de filesystems reconnaissent ces UUIDs, y compris le NTFS de Windows. Il existe également un autre moyen d'identifier ses partitions (en plus de celui de les appeler directement par leur petit nom), le Labelling, qui consiste à attribuer un LABEL à la partition. La grande différence avec l'UUID, mise à part sa compréhension plus intuitive, est que ce Label n'est unique que localement, tandis que l'UUID est censé (je dis bien censé, puisque ce sont les mêmes algorithmes de génération qui jouent, il y a forcément des intersections) être universellement unique.

Investigation !

Initrd.img

Pour savoir ce qu'il se cache dans votre initrd.img, rien ne vaut un lsinitrd ! Un peu d'exploration, et dans les dernières lignes, par exemple, on peut trouver :

# lsinitrd /boot/initrd.img

echo waiting for device sda1 to appear (timeout 1min)
waitdev --timeout=60000000 UUID=0d4af533-85cf-4a81-a378-172ac9143140
echo waiting for device sda2 to appear (timeout 1min)
waitdev --timeout=60000000 UUID=ce132640-34f0-43bd-b256-250ef6c369f6

Et là, vous avez cerné le problème !

Dans les faits...

Donc, d'après ce que l'on a pu tirer de notre lsinitrd, on peut facilement déduire que ce qui provoque le timeout vient justement des UUIDs qui sont appelé en dur. Voyons ce que l'on a à disposition... La méthode simple :

# ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 100 2010-03-11 16:32 .
drwxr-xr-x 6 root root 120 2010-03-11 16:32 ..
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 1a3808ca-c81c-416f-9109-2ebc9c635722 -> ../../sda2
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 97a38b84-b2a2-4970-b593-8f561b827fda -> ../../sda1
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 c999ed94-737b-4a5a-8945-519e07c27610 -> ../../sda3

La méthode spécifique :

# /sbin/blkid
/dev/sda1: LABEL="ROOT" UUID="97a38b84-b2a2-4970-b593-8f561b827fda" TYPE="ext3"
/dev/sda2: LABEL="SWAP" UUID="1a3808ca-c81c-416f-9109-2ebc9c635722" TYPE="swap"
/dev/sda3: LABEL="HOMELOCAL" UUID="c999ed94-737b-4a5a-8945-519e07c27610" TYPE="ext3"

Divergence d'UUID

Le constat est simple. L'appel du initrd se base sur son UUID, et ici, les UUIDs entre l'appelé et le réel diffèrent. Pour fixer le souci, un simple mkinitrd remet à jour ces informations. Plus de timeout au boot, malheureusement, le problème reviendra avec d'autre mises à jour du initrd. Alors, aux vues de toutes les manips à faire, Reconsidérez bien l'affaire. Après tout, quelques minutes de timeout ne font pas de mal à vos utilisateurs !

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

K-TUX — Tue, 05 Jan 2010 14:16:52 +0000

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) !

Nos amis les Filesystems… Part I

K-TUX — Fri, 11 Dec 2009 07:51:50 +0000

Bonjour readers et readeuses acharnés. Aujourd'hui, nous allons parler des différents système de fichiers -Filesystem, pour briller en société- qui font la richesse et la pluridisciplinarité de Linux, et comme il y en a beaucoup et de toutes sortes, nous allons découper ça bien propre en plusieurs parties. Utilisateur Windows, ne t'inquiète pas ! Ton heure viendra, mais pas tout de suite quand même, parce que, même avec Windows 7 (dites Séveuuun), il y a encore un petit bout de chemin à faire. Avertissement pour les puristes de la technique : Cette note est tournée grand public et la mise en œuvre des techniques décrites ci-dessous ne sera pas détaillée, même si quelques liens propices vous guideront vers des howtos bien ficelés. Petites généralités. Selon notre ami Wikipédia, un système de fichier est un ensemble structuré qui permet d'organiser, de localiser, d'accéder et de maintenir des données. Le tout sur un support persistant, c'est-à-dire qui gardera les informations en l'état à l'extinction de la machine. Le plus communément, c'est donc sur votre (vos ?) disque(s) dur(s) que vous retrouverez vos fichiers. Afin de pouvoir maintenir toutes ces informations, le système de fichier crée lui-même d'autres informations, relatives, elles, aux fichiers en eux-même. C'est ce que l'on appelle des métadonnées. Sous Linux, ce sont les inodes qui contiennent ces métadonnées. Les inodes sont des structures de données contenant toutes les informations utiles d'un fichier, permissions comprises. Elles sont liées aux fichiers par une autre structure de données, le dentry. Les fichiers, les inodes et les dentries sont contenus dans ce que l'on appelle le superblock, entité qui est chargée de la maintenance et de la gestion de la structure de donnée. Il contient le nom du filesystem (par exemple ext4), sa taille, son état, des métadonnées et une référence aux bloc devices. Le superbloc est la racine du filesystem. Pour votre curiosité, Windows, lui, stocke directement ces métadonnées dans le fichier lui-même. De visu, le système de fichier se présente comme une arborescence de répertoires dont la racine est /:

/bin /boot /dev /etc /home /lib /lib64 /lost+found /media /mnt /opt /proc /root /sbin /tmp /usr /var

Ce que vous ne voyez pas, mais que vous avez pu rencontrer si vous avez, par curiosité ou par science, partitionné votre disque manuellement, c'est la swap.

La swap est en fait une petite partie du disque réservée à la mémoire. Du fait qu'elle soit située sur le disque, elle est beaucoup plus lente d'accès que la mémoire vive en elle-même, mais elle présente un avantage dans le cas où vous êtes submergé par une occupation excessive de la mémoire vive par un ou plusieurs processus. Dans ce cas, au lieu de vous bloquer définitivement pour cause de pénurie de RAM, on utilise la swap. Une règle de pouce consiste à créer une swap de taille égale à la quantité de RAM présente sur la machine.

Organisation logique.

Mais revenons-en à nos moutons. Vous vous doutez bien qu'avec la quantité et la diversité des médias existants en ce bas-monde, le système de fichier Linux ne peut raisonnablement pas être livré tel quel, figé sur une implémentation pure et dure qui serait relative à un et un seul type de média, ni être décliné pour chacun des médias existant sur cette petite planète. D'une part parce qu'il en existe vraiment beaucoup, et d'autre part parce que cela nécessiterait de faire massivement évoluer le code lors d'une évolution de média. Bref, pas du tout portable, aucune scalabilité, le cauchemar. Il en est tout autrement. User-Space, Kernel-Space.

En effet, le système de fichier Linux distingue 2 couches abstraites. Pourquoi ? Et bien pour séparer les traitements effectués par le système de fichier des manipulations de device à proprement parler.

Le schéma parle de lui-même. Nous pouvons donc voir que toutes les interactions avec le User-Space (autrement dit, tout ce qui touche à l'environnement utilisateur) passe par l'interface SYSTEM CALL, Kernel-Space qui, elle-même, devra s'adresser à un système de fichier virtuel (VFS) pour que ses traitements soient effectués à proprement dit. VFS abstrait les interfaces qui lui viennent d'un export de l'individual filesystem. Il gère également les informations concernant les filesystems supportés et ceux actuellement montés (oui, promis, j'expliquerais "monter"). Individual Filesystem, à l'origine de l'export des interfaces, fonctionnera très différemment selon le filesystem choisi (ext2, ext3, JFS, ...). Des caches sont présents à différent niveau afin d'optimiser le temps de traitement (Inode cache, Directory cache, Buffer cache). Ok, je sens que je vais un peu loin alors je vais arrêter là. Pour ceux qui en veulent plus, n'hésitez plus, allez farmer un peu sur le Net. Les types de filesystem. Les classiques. Lorsque vous installez votre Linux, sachez que vous avez la possibilité de choisir votre filesystem, et de le partitionner vous-même (c'est-à-dire le scinder en morceau de disque). Par défaut, Linux, dans ses versions récentes, installera votre filesystem sous ext4 -Extended FileSystem- (Ubuntu Karmic Koala, Fedora 12 Constantine, ...). Mais comme cela est si bien dit dans les notes d'Ubuntu, cela ne signifie pas que les autres filesystems ne sont plus supportés. Il existe en effet, historiquement, d'autres versions d'ext : ext2, ext3 sont les plus souvent rencontrées (au-delà, votre serveur est vraiment vieux). Ah. Question au fond. La différence ? Entre ? AAAH !!! Déjà, entre ext2 et ext3, nous avons principalement une différence au niveau de la journalisation. En effet, ext2 est un des dinosaures de Linux. Il était certes plus intelligent que le FAT de Windows, en ce sens qu'il organisait les fichiers et donc limitait le recours à la fragmentation, mais il restait perfectible. Vous en avez révé ? Ext3 l'a fait ! La journalisation sert essentiellement à maintenir la cohérence des métadonnées, notamment en cas de crash. Cela évite par exemple le gentil fsck de ext2 lorsque le système a subi un arrêt impromptu. Le système relit tranquillement son fichier de log, retrace les dernières transactions non commitées et remet d'aplomb un système sain en 2 temps trois mouvements. Hop, ne soyons pas radin, un peu de doc vous fera du bien ! Ext3 et Ext4, c'est une autre histoire. Ext4 est une évolution puisqu'étant encore attaché à la compatibilité descendante, il reste limité dans ses mouvements. Ext4 oriente la majorité de son travail sur les problèmes de tailles et de fragmentation. Hop, moment opportun pour un petit lien d'info sur Linuxfr.org et sur le Wiki officiel Ext4. Ext3 et Ext4 sont principalement utilisés, ce sont eux qui supportent votre Linux. Ils peuvent travailler sur disques durs, sur volumes logiques, sur partition raid, toussa toussa, sans broncher (ou si peu). Les outils et fichier impliqués font partie du noyau Linux depuis belle lurette, ce sont, entre autre :

fdisk : permet de manipuler / voir / gérer les partitions,
mkfs.ext2 ou mkfs.ext3 : créer le système de fichier (respectivement ext2 ou ext3),
fsck : monitorer et réparer votre système de fichier,
resize2fs : redimensionner le filesystem,
mount : "monter", c'est-à-dire rendre accessible en lecture (et, pourquoi pas, en écriture-exécution) un système de fichier,
/etc/fstab : fichier de configuration pour les montages automatiques au démarrage des différents filesystems. Par défaut, votre filesystem est déjà monté et inscrit dans ce fichier.

Les extensibles et les hautes disponibilités. Lorsque l'on donne, dans son immense bonté, vie à une machine Linux, elle a, comme tout être vivant, un cycle de vie. Parce que oui, dans un contexte généralisé, votre machine aussi a besoin de grandir, en terme de composant, de performances, de service et d'espace. Il existe plusieurs moyens permettant de construire et d'étendre un système de fichier. Certaines approches nécessitent un travail de réflexion en amont, à savoir si réellement on a besoin de rajouter de l'espace, si ce doit être opérationnel sans avoir à réinstaller, rapidement, de manière modulaire, si il y a une forte contrainte de temps et de disponibilité,... Bref, plus on veut, plus fallait réfléchir avant. De même, souhaitons-nous recourir à des outils qui ont fait leurs preuves depuis des années, des solutions toutes packagées, principalement hardware, ou bien préférerons-nous les versions plus intelligentes, plus intuitives, plus modulables ? Les alternatives sont nombreuses, et je ne les maîtrise pas toutes. RAID. Voilà le premier point qu'il vous vient à l'esprit. Un RAID (Redundant Array of Inexpensive Disks) est une agrégation de device de stockage qui permet d'avoir une tolérance aux éventuels accidents (panne, crash d'un disque dur,...) et qui améliore les performances d'accès aux données. En effet, composé de plusieurs disques, cela lui permet d'une part d'étaler les données sur l'ensemble des disques, mais en plus, et c'est vital, de rajouter des brides d'information concernant ces données tour à tour sur chacun des disques (RAID 5). Ces bribes d'information (bits de parité) sont stockés dans des stripes et servent à contrôler les données ajoutées et, au besoin, de les reconstruire. En conséquence, puisque ces données sont éclatées sur plusieurs disques, les temps d'accès en lecture et en écriture sont grandement améliorés. Notre ami Wiki est toujours là pour vous. Construire un RAID -logiciel, j'entends, puisqu'il n'y a jamais assez de moyens pour le tout packagé et qu'on est curieux de savoir ce qu'il y a sous le capot-, et surtout le maintenir, ce n'est pas de tout repos. Dans la meilleure des configurations, il vous faut n fois le même genre de disque dur (capacité, mémoire cache, vitesse, connectique), sinon le bonus de capacité qu'un disque pourrait avoir sur les autres sera jeté aux oubliettes. Il vous faut aussi, de préférence (mais c'est comme dans la vraie vie, tout est une histoire de bon matériel au bon moment) des disques en spare, histoire que vous ne soyez pas en position malheureuse si un autre "incident" survenait. De même, en cas de fail d'une unité du raid, la reconstruction des données peut prendre du temps. Le RAID est une bonne solution concernant la scalabilité et la haute disponibilité, mais ce n'est pas un système de fichier, c'est une technologie. Vos meilleurs amis seront :

mdadm : monitorer, créer, gérer le raid,
mkraid : créer un raid,
lsraid : lister les composants du (des) raid(s),
raidhotadd : ajout à chaud de volume dans le raid,
raidsetfaulty : forcer la sortie d'une volume en le mettant en faulty,
raidstop, raidstart,...
mknod : créer un fichier spécial block ou character
/etc/raidtab : fichier de configuration d'un raid (optionnel)
/proc/mdstat : fichier monitorant l'état du raid (pensez à watch pour le visionner en temps réel),
/var/log/messages : log système,
tous les outils gérant le filesystem sous-jacent.

Resté sur votre faim ? Par ici ! Une autre façon de faire serait de passer par LVM (Logical Volume Manager). La principale différence entre RAID et LVM, c'est que justement LVM n'est pas un RAID. LVM ne travaille pas directement sur les disques, mais sur des entités appelées Logical Volumes, crées, maintenus et gérés par tout un arsenal d'outil rattachés au package lvm2. LVM apporte donc un niveau d'abstraction supplémentaire qui permet à vous, utilisateur et administrateur, de pouvoir redimensionner, créer, supprimer, étendre,... vos partitions sans avoir à vous soucier du hardware en dessous. Plus en détail, LVM décompose le disque dur en pv, physical volumes, qu'il regroupe au sein d'un vg, Volume Group, et sur lequel il crée un lv, Logical Volume. C'est sur le Logical Volume que le filesystem s'installe, donc "quelque part" sur le Volume Group. Il est vraiment très facile d'étendre et de shrinker (réduire) l'espace disque. LVM est très stable, éprouvé en production, modulable à souhait, un brin plus souple que le RAID, et plus que propice à la scalabilité mais en revanche, il n'aide pas niveau haute-disponibilité. Il est cependant possible d'utiliser LVM sur un RAID pour ajouter les avantages du RAID -et ses inconvénients par la même occasion- à ceux de LVM. Les outils qui vous aideront :

lvm2 : le package de référence,
pv{change||ck||create||display||move||remove||resize||display||scan||s} : gestion des physical volumes (par exemple, pvcreate /dev/sda2),
vg{cfgbackup||cfgrestore||change||ck||convert||create||display||export||extend||import ||merge||mknodes||reduce||remove||rename||s||scan||split} : gestion des volume groups,
lv{change||convert||create||display||extend||reduce||remove||rename||resize||s||scan} : gestion des logical volumes,
lvm{||change||diskscan||dump||sadc||sar} : gestion lvm.

Si vous voulez en venir aux mains, faites. Le dernier point que je souhaiterais voir avec vous au niveau des extensibles et hautement disponibles, se cache sous trois lettres : ZFS. ZFS, contrairement aux deux autres points, est un filesystem à part entière, il ne s'agit donc pas d'un outil. Zeta Filesystem, de son petit nom, a été développé par Sun. Ce système de fichier présente des caractéristiques très particulières mais n'est pas intégré au noyau Linux pour une raison simple : la licence sous lequel il est distribué (CDDL) est incompatible avec GPL dans sa version 2. Mais là encore, grâce à Ricardo Correia, développeur, nous pouvons utiliser ZFS via fuse (filesystem in userspace), environnement qui met à disposition, comme son nom l'indique, les fonctionnalités des filesystems dans l'espace User. ZFS constitue un peu le fantasme de tout administrateur système. Il fait en sorte d'être toujours cohérent. Oui. Vous avez bien entendu. Il se corrige tout seul. Cette citation à elle seule, comme ça, sans preuve peut choquer. De même, il fournit une très haute capacité de stockage (nettement plus haute que tous les autres filesystems d'après notre ami Wiki). Voyons comment tout ça fonctionne. Eh bien ZFS nous rappelle un peu le fonctionnement de LVM. En effet, notre filesystem s'appuie en réalité sur des pools de stockage. Les pools permettent, comme on l'a vu précédemment, d'éviter de se soucier du hardware, partionnement compris. Dans ZFS, ils sont utilisés pour centraliser les IO (entrées-sorties) et comme lien entre les différents périphériques de stockage. Lorsqu'une donnée est destinée à être écrite sur un disque, elle passe par le pool, à ce moment-là, elle est vérifiée à la volée, dupliquée, puis stockée. ZFS dispose donc de tous les éléments nécessaires pour contrôler à n'importe quel moment la cohérence et la véracité des données et va même jusqu'à corriger la donnée corrompue sans que vous ayez à le lui demander. De la même manière, ZFS s'appuie sur du RAID Z, qui est un peu semblable à notre bon vieux RAID 5, à la différence que les stripes de données ont une largeur variable, de sorte que ZFS limite les pertes d'espace disque à leur origine. Si vous avez envie d'en savoir plus, jetez un coup d'oeil sur le site officiel, la doc officielle, et l'article d'Unix Garden sur sa mise en place. Sachez aussi que ZFS est présent nativement sous OpenSolaris, version Open Source de Solaris. Il existe beaucoup d'autres qui mériteraient d'être dans cette catégorie, mais j'arrêterais là. Sachez que je vous encourage à participer si vous estimez qu'il manque vraiment quelque chose. C'est tout pour la première partie et encore !!! Je suis loin d'être exhaustive, même en me cantonnant à Linux. Sur ce, potassez bien, farmez, complétez et n'oubliez pas de passer de Bonnes Fêtes -oui, un ASR aussi, ça se repose parfois- !!!