juillet 2009 Archives

11-07-2009 18:28:27

Debian Lenny/Stable vs Ghost version 11

Le début du mois de juillet est traditionnellement la saison de refonte des configurations des postes de travaux pratiques. Même si la gestion de parc n'est pas vraiment mon domaine de prédilection, je suis intervenu en dépannage sur l'utilisation de Symantec Ghost™ version 11 pour déployer des images de postes dits multiboot : Windows XP™, DOS™ et Debian GNU/Linux Lenny/stable. Une fois de plus, le support GNU/Linux par les logiciels propriétaires laisse à désirer.

Symantec Ghost v11 et ext3

La documentation officielle du produit annonce un support du système de fichiers ext3 dans la gestion des images. Ce support apparaît aujourd'hui comme complètement dépassé et la restauration d'un système de fichiers issu de l'installation classique de la distribution Debian GNU/Linux stable échoue systématiquement.

Si le système de fichiers ext3 avait été publié récemment ou si ses spécifications n'étaient pas ouvertes, cette situation serait «prévisible». Or, il n'en est rien ; ext3 est devenu le système de fichiers par défaut des distributions GNU/Linux il y a plusieurs années et ses évolutions sont parfaitement connues.

On peut donc s'étonner légitimement en constatant qu'un logiciel de gestion de parc qui se veut professionnel n'ait pas intégré la moindre évolution. Comment se fait-il que l'on puisse procéder à un archivage à partir d'un jeu de paramètres figé sans même relever, à l'aide d'une simple lecture, l'état du système de fichiers courant ?

La commande tune2fs nous renseigne simplement sur les caractéristiques du système de fichiers. Voici un exemple extrait d'une installation récente.

# cat /etc/issue
Debian GNU/Linux 5.0 \n \l

# tune2fs -l /dev/mapper/vm--debian-usr | egrep 'features|Inode size'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Inode size:               256

L'extrait ci-dessus illustre les deux principales caractéristiques non supportées par Symantec Ghost™ en version 11. Pour pouvoir archiver une installation il est nécessaire de dégrader le système de fichiers ext3.

Formatage ext3 compatible Ghost v11

Après de multiples itérations d'archivage/restauration d'une image Symantec Ghost™, les deux paramètres sensibles qui ressortent sont les suivants.

Inode size, Taille inode

Symantec Ghost™ suppose que la taille d'inode est figée à 128 octets. La valeur par défaut de ce paramètre est maintenant de 256 octets. Lors du formatage, l'option -I permet de fixer cette valeur manuellement. Il faut consulter les pages de manuels de l'outil mkfs.ext3 pour obtenir les informations détaillées sur cette option.

La difficulté posée par ce paramètre provient du fait qu'il n’est pas possible de changer cette valeur après la création du système de fichiers. Il est donc nécessaire de procéder à un reformatage de la partition à archiver.

resize_inode

Cette propriété a pour but de réserver de la place pour permettre à la table des descripteurs de groupe de blocs de grossir plus tard. C’est utile pour permettre le changement de taille à chaud avec resize2fs. Les utilisateurs du gestionnaire de volume logique LVM sont très attachésà cette propriété.

Là encore, la propriété n'est pas supportée par le logiciel propriétaire et le système de fichiers restauré est inexploitable.

Voici donc un exemple de commande de formatage à utiliser pour obtenir un système de fichiers ext3 dégradé mais permettant de créer des archives utilisables avec Symantec Ghost™ en version 11.

# mkfs.ext3 -I 128 -O^resize_inode,^dir_index /dev/sda3

Dans cet exemple, /dev/sda3 désigne la partition sur laquelle le système GNU/Linux doit être installé.

Processus d'archivage

Comme il n'est logiquement pas possible de dégrader le système de fichiers lors de l'installation du système, on doit passer par un transfert intermédiaire lors de la création du poste maître.

On commence par procéder à une installation du système GNU/Linux selon les besoins du poste de travaux pratiques. Dans la plupart des cas, on peut se contenter d'une installation sur une partition unique sachant que l'installation doit être reconstruite en cas d'évolution.
On transfère le système de fichiers du système après installation vers une autre machine de façon à pouvoir le récupérer après reformatage de la partition. De façon classique, on peut utiliser rsync et ssh pour faire cette opération. Voici un exemple d'instruction de copie d'une arborescence système à partir du compte super-utilisateur pour préserver les identités sur les objets de l'arborescence du système de fichiers.
```
# rsync --exclude /proc \
        --exclude /sys \
        --exclude /tmp \
        --exclude /var/tmp \
        -avz / root@otherhost:/var/backup-master/
```
On réinitialise le poste et on lance le système sur un live CD. Le système KNOPPIX convient parfaitement pour ce genre d'opération ; il contient tous les outils nécessaires à ces manipulations. Une fois le système initialisé, on peut passer au formatage du système de fichiers dégradé.
```
# mkfs.ext3 -I 128 -O^resize_inode,^dir_index /dev/sda3
```
Toujours à partir du système live CD, on récupère l'arborescence du système de fichiers sauvegardé lors de l'étape précédente.
```
# mount /dev/sda3 /mnt

# rsync -avz root@otherhost:/var/backup-master/ /mnt/
<snipped/>

# mkdir /mnt/proc /mnt/sys /mnt/tmp /mnt/var/tmp

# chmod 1777 /mnt/tmp /mnt/var/tmp
```
Après redémarrage du poste, on retrouve une configuration multiboot exploitable avec Symantec Ghost™.

Pour conclure

Voilà comment échapper à un piège supplémentaire posé par un logiciel propriétaire ! Bien évidemment, si cette «recette» a le mérite de fonctionner, il doit certainement être possible de faire mieux. N'hésitez pas à me contacter si vous avez des propositions ;)).

Ce document est disponible en version imprimable au format PDF : lenny-ghost.pdf.

$Id: lenny-ghost.xml 1410 2009-07-11 16:27:57Z latu $