Product SiteDocumentation Site

3.2. Partitionner le système

3.2.1. Choisir un schéma de partitionnement intelligent

Un schéma de partitionnement intelligent dépend de l'utilisation de la machine. Une bonne règle est d'être assez large avec vos partitions et de faire attention aux facteurs suivants.
  • Les arborescences de répertoires modifiables par un utilisateur, telles que /home, /tmp et /var/tmp, doivent être sur des partitions distinctes. Cela réduit le risque qu'un déni de service provoqué par un utilisateur ne remplisse le point de montage « / » rendant ainsi le système inutilisable (remarque : ce n'est pas strictement vrai car il existe toujours un espace réservé au superutilisateur qu'un utilisateur normal ne pourra pas remplir) et cela empêche les attaques de liens directs (hardlinks). [2]
  • Toute partition qui peut fluctuer, par exemple /var (surtout /var/log) devrait être également sur une partition distincte. Sur un système Debian, vous devriez créer /var un petit peu plus grand que la normale car les paquets téléchargés (le cache d'apt) sont stockés dans /var/cache/apt/archives.
  • Toute partition où vous voulez installer des logiciels ne faisant pas partie de la distribution devrait être sur une partition distincte. Selon la norme de hiérarchie des fichiers (FHS), c'est /opt ou /usr/local. Si ce sont des partitions distinctes, elles ne seront pas effacées si vous devez réinstaller Debian.
  • D'un point de vue sécurité, il est souhaitable de mettre les données statiques sur une partition et de monter celle-ci en lecture seule. Encore mieux, mettre les données sur un périphérique en lecture seule. Voir ci-dessous pour plus d'informations.
Dans le cas d'un serveur de courriers, il est important d'avoir une partition séparée pour le répertoire des courriers (spool). Les utilisateurs distants (soit consciemment, soit inconsciemment) peuvent remplir le répertoire des courriers (/var/mail ou /var/spool/mail). Si le répertoire est sur une partition séparée, cette situation ne rendra pas le système inutilisable. Sinon (si le répertoire est sur la même partition que /var), le système pourrait avoir d'importants problèmes : les entrées des journaux ne seront pas créées, aucun paquet ne pourra plus être installé et certains programmes pourraient même avoir des problèmes à être exécutés (s'ils utilisent /var/run).
Pour les partitions pour lesquelles vous ne pouvez pas être certain de la place nécessaire, installez Logical Volume Manager (lvm-common et les binaires nécessaires pour le noyau qui peuvent être lvm10, lvm6 ou lvm5). En utilisant lvm, vous pouvez créer des groupes de volumes répartis sur plusieurs volumes physiques.

3.2.2. Choisir les systèmes de fichiers appropriés

Pendant le partitionnement du système, vous devez également décider du système de fichiers à utiliser. Le système de fichiers choisi par défaut[3] pendant l'installation de Debian pour les partitions Linux est ext3, un système de fichiers journalisé. Vous devriez toujours utiliser un système de fichiers journalisé comme ext3, reiserfs, jfs ou xfs pour réduire les problèmes découlant d'un plantage système dans les cas suivants :
  • pour les portables pour tous les systèmes de fichiers installés. Ainsi, si la batterie se vide inopinément ou si le système se gèle à cause d'un problème matériel (comme pour la configuration de X, ce qui est assez courant), vous êtes moins susceptible de perdre des données pendant le redémarrage matériel.
  • pour les systèmes de production qui stockent des quantités importantes de données (comme les serveurs de courriers, les serveurs FTP, les systèmes de fichiers en réseau, etc.), cela est recommandé pour ces partitions. Ainsi, en cas de plantage du système, le serveur nécessitera moins de temps pour récupérer et vérifier le système de fichiers et une perte de données est moins probable.
En laissant de côté les problèmes de performance concernant les systèmes de fichiers journalisés (cela pouvant parfois tourner à la guerre de religion), il est habituellement préférable d'utiliser le système de fichiers ext3. La raison pour cela est qu'il est rétrocompatible avec ext2, donc s'il y a un quelconque problème avec la journalisation, vous pouvez la désactiver et toujours avoir un système de fichiers fonctionnel. De plus, si vous avez besoin de récupérer le système avec une disquette d'amorçage (ou un CD), vous n'avez pas besoin d'un noyau personnalisé. Si le noyau est en version 2.4 ou 2.6, la prise en charge ext3 est déjà disponible, s'il s'agit d'un noyau 2.2, vous pourrez amorcer le système de fichiers même si vous n'aurez plus la capacité de journalisation. Si vous utilisez d'autres systèmes de fichiers, vous trouverez que vous ne pourrez pas effectuer de récupération à moins d'avoir un noyau 2.4 ou 2.6 avec les modules nécessaires inclus dans le noyau. Si vous êtes bloqué avec un noyau 2.2 sur la disquette de sauvegarde, cela pourrait même être encore plus difficile d'accéder à des partitions reiserfs ou xfs.
Dans tous les cas, il est possible que l'intégrité des données soit meilleure avec ext3 car il fait de la journalisation des données par fichier alors que les autres ne font que de la journalisation par métadonnées, consultez http://lwn.net/2001/0802/a/ext3-modes.php3.
Remarquez, néanmoins, que certaines partitions n'ont pas d'intérêt particulier à utiliser un système de fichiers journalisé. Par exemple, si vous utilisez une partition à part pour /tmp/, vous devriez plutôt utiliser un système de fichiers ext2 car elle sera nettoyée lors du démarrage du système.


[2] Un très bon exemple de ce type d'attaque utilisant /tmp est détaillé dans http://www.hackinglinuxexposed.com/articles/20031111.html et http://www.hackinglinuxexposed.com/articles/20031214.html (notez que l'incident est lié à Debian). C'est de manière basique une attaque dans laquelle un utilisateur local cache profondément une application setuid vulnérable en faisant un lien direct sur celle-ci, évitant de manière efficace toute mise à jour (ou suppression) du binaire lui-même réalisé par l'administrateur du système. dpkg a été récemment corrigé pour empêcher cela (consultez le http://bugs.debian.org/225692), mais d'autres binaires setuid (non contrôlés par le gestionnaire de paquets) sont risqués si les partitions ne sont pas mises en place correctement.
[3] Depuis Debian GNU/Linux 4.0, surnommée Etch.