Vous êtes sur la page 1sur 191

Linux 

Administration système et exploitation des services réseau

Sébastien BOBILLIER  

Résumé
Ce livre présente les connaissances nécessaires à la bonne exploitation des systèmes Linux en réseaux local et étendu. Il s'adresse à tout
administrateur désireux d'assurer la gestion matérielle des serveurs, une bonne administration du système, et d’utiliser les services applicatifs
courants dans les environnements Open Source. Une connaissance raisonnable de la ligne de commande Unix ou Linux est un pré-requis
souhaitable pour tirer pleinement profit de cet ouvrage.
La gestion du matériel couvre les techniques avancées de stockage, ainsi que la reconnaissance des périphériques par le système.
L'administration du système d'exploitation traite de la gestion des comptes utilisateurs locaux ou réseaux ainsi que du bon usage des niveaux
d'administration et des services réseaux. Enfin, une bonne partie de l'ouvrage est dédiée aux équipements d'infrastructure comme les serveurs
DNS et DHCP, ainsi qu'aux services applicatifs courants tels que le partage de fichiers, la messagerie et les serveurs web. La sécurité n'est pas
oubliée, que ce soit sur les services applicatifs traités ou sur le système lui-même avec la configuration et l'exploitation du pare-feu natif des
systèmes Linux.
L’auteur a conçu ce livre comme une boîte à outils dans laquelle l'administrateur retrouve les éléments de compétence nécessaires à
l'exploitation de son réseau avec tout ou partie des services applicatifs.

Les chapitres du livre :


Avant-propos – Gestion du stockage –Démarrage du système – Gestion du réseau local – Authentification des utilisateurs – Partage de fichiers –
Résolution de noms DNS – Serveur web Apache – Messagerie – Protection des réseaux – Sécurisation du trafic – Compilation des applications et
du noyau Linux
L'auteur
Après avoir été Administrateur Systèmes et Réseaux, Sébastien Bobillier évolue depuis de nombreuses années dans le monde de la
formation. Aujourd’hui Consultant Formateur chez Global Knowledge, il transmet au lecteur toute son expérience terrain en tant que
spécialiste des systèmes Linux.

Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI

Ce livre numérique intègre plusieurs mesures de protection dont un marquage lié à votre identifiant visible sur les principales images.

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Avant­propos 
Les serveurs et systèmes embarqués Linux sont partout. D’abord considérés comme simples gadgets amusants puis 
portés  aux  nues  par  une  presse  souvent  versatile,  la  réalité  objective  est  sans  appel  :  de  plus  en  plus  de  serveurs 
Linux sont présents dans les foyers et les entreprises. L’heure n’est plus au déploiement discret d’un serveur dans une 
entreprise par un employé passionné qui profite du faible coût de déploiement pour pousser sa solution open source. 
Aujourd’hui, le choix d’un serveur Linux pour une solution d’entreprise est le fruit d’une décision réfléchie intégrant le 
coût de possession aussi bien que les possibilités d’évolution. L’administration des serveurs et la gestion des services 
suivent  naturellement  cette  évolution,  et  nécessitent  désormais  des  compétences  bien  assises.  Plus  discrète  est  la 
généralisation des Linux embarqués, qui se glissent partout, des serveurs NAS aux lecteurs multimédias domestiques, 
en passant par les téléphones et autres téléviseurs DLNA. Ils sont toutefois omniprésents dans tous les équipements 
domestiques, et exploitent de nombreuses fonctionnalités de serveurs. Profitant de leurs capacités étendues, de plus 
en  plus  d’utilisateurs  en  profitent  pour  héberger  eux­mêmes  leurs  sites  web  ou  autres  services  sur  ces  véritables 
petits serveurs Linux domestiques. 

Ce  livre  s’adresse  aux  administrateurs  souhaitant  faire  l’acquisition  des  connaissances  nécessaires  à  une  bonne 
administration  de  leurs  serveurs  Linux,  tant  du  point  de  vue  de  l’administration  du  système  lui­même  et  de  ses 
éléments de stockage que de la gestion des services applicatifs installés. Il est recommandé pour en tirer le meilleur 
profit d’avoir une bonne expérience de la ligne de commande Linux. 
Les  chapitres  de  ce  livre  couvrent  des  compétences  administratives  distinctes  et  sont  organisés  par  sujets 
fonctionnels,  du  stockage  à  la  sécurité  en  passant  par  les  principaux  services  applicatifs.  Une  lecture  linéaire  est 
possible et devrait apporter un savoir­faire construit et cohérent. On pourra aussi considérer ce livre comme une boîte 
à outils où le lecteur viendra chercher un élément technique précis en fonction de ses besoins du moment. 

Le  chapitre  consacré  au  stockage  traite  de  l’organisation  des  disques  et  de  leur  gestion  traditionnelle,  qui  sera 
nécessaire pour la plupart des installations. Les aspects avancés sont également abordés tels que les possibilités de 
sauvegarde  ou  la  gestion  de  la  tolérance  de  pannes.  Enfin,  les  volumes  logiques  et  les  snapshots  permettront  de 
s’adapter aux architectures de stockage (SAN) les plus ambitieuses. 

Le démarrage des systèmes est couvert, du gestionnaire de boot et sa configuration à l’organisation des services. La 
compréhension du mode de démarrage des services applicatifs sur un système Linux permettra une bonne adaptabilité 
aux situations de production. 

La configuration du réseau est traitée du point de vue de l’infrastructure réseau avec le service DHCP, mais aussi du 
poste de travail et des serveurs avec la configuration de l’adressage IP, fixe ou dynamique. Les captures de paquets à 
des fins d’analyses sont couvertes. 

L’authentification  des  utilisateurs  est  abordée  de  ses  aspects  classiques  et  historiques  à  l’authentification modulaire 
PAM.  On  aboutit  alors  à  l’authentification  des  utilisateurs  auprès  d’un  annuaire  LDAP,  ce  qui  conviendra  aux  plus 
grandes infrastructures. 

La partie consacrée au partage de fichiers couvre les trois protocoles courants utilisés en réseau local ou sur Internet : 
NFS, SMB et FTP. Les aspects sécuritaires des accès aux serveurs de fichiers sont bien entendu couverts. 

Le  chapitre  sur  DNS  s’adapte  à  tous  les  besoins,  du  simple  serveur  de  cache  à  l’infrastructure  complète  comprenant 
délégations et réplications de zones. Les outils de diagnostics DNS sont également traités en détail. 

La configuration des services web va du serveur Apache largement traité,  fonctionnant en mode normal ou sécurisé, 
avec ou sans gestion des hôtes virtuels, aux serveurs proxy, et à leur utilisation pour sécuriser la navigation. 

Le chapitre Messagerie apporte les connaissances nécessaires à la configuration d’un serveur Posfix et des services de 
remise de messages. Les formats de boîte aux lettres mbox et maildir sont couverts. 

La  protection  des  réseaux  sera  assurée  par  un  pare­feu  Linux,  configuré  et  géré  de  bout  en  bout,  sous  forme  de 
service, et donc lancé systématiquement au démarrage. 
Les  flux  applicatifs  pourront  être  sécurisés  par  un  tunnel  SSH,  spécialisé  pour  une  application,  ou  par  OpenVPN,  qui 
établit une véritable liaison privée entre sites. 
Enfin, l’installation personnalisée d’applications est assurée par la compilation des sources par la procédure normalisée 
de compilation GNU. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Gestion et configuration des systèmes de fichiers 

1. Gestion des systèmes de fichiers 

a. Les systèmes de fichiers courants 

Un  système  d’exploitation  est  dans  la  plupart  des  cas  installé  sur  un  disque  dur  ou  périphérique  de  stockage 
assimilé. Si on regarde de très près un disque dur neuf, on constate que son espace de stockage est constitué d’une 
suite  d’octets  sans  aucune  forme  d’organisation.  Pour  exploiter  convenablement  tout  ou  partie  de  cet  espace  de 
stockage,  il  convient  de  le  segmenter  dans  un  premier  temps,  c’est  le  partitionnement,  puis  de  créer  sur  les 
partitions à exploiter un système de fichiers. 
Le système de fichiers sert à organiser un espace de stockage brut, comme une partition de disque pour y stocker 
des  données.  Si  le  terme  courant  est  souvent  le  formatage  de  l’espace  de  stockage,  on  parle  souvent  en 
environnement Linux de création de filesystem. 

Le  terme  filesystem  (en  anglais)  fait  l’objet  d’une  convention  d’utilisation  fréquente  qui  sera  reprise  dans  cet 
ouvrage. On parle de « filesystem » lorsqu’il s’agit  d’un système de fichiers attaché à un périphérique de stockage 
unique, et on parlera de « système de fichiers » pour désigner l’espace de stockage organisé, qu’il soit composé d’un 
ou de plusieurs filesystems. 
Il existe plusieurs types de filesystems, dont les plus courants en environnement Linux sont ext, reiserfs et xfs. 

ext

ext  est  le  filesystem  historique  des  systèmes  Linux.  Il  existe  actuellement  trois  versions  de  filesystem  ext  en 
production. ext2 est la version historique, ext3 est une évolution de ext2 qui lui ajoute un journal de transactions, et 
ext4  est  une  dernière  évolution  qui  équipe  les  systèmes  les  plus  récents  et  qui  vise  à  pallier  les  limites  de  l’ext3 
(taille maximum de fichiers portée de 2 téraoctets pour ext3 à 16 téraoctets pour ext4 par exemple). 
Le journal de transactions présent en ext3 et ext4 permet d’accélérer notablement les vérifications sur les systèmes 
de fichiers et la récupération en cas de crash. 

reiserfs

Reiserfs  est  un  filesystem  journalisé  qui  offre  pour  certaines  opérations  des  performances  un  peu  meilleures  que 
ext3.  Reiserfs  se  posait  d’ailleurs  en  concurrent  de  ext  à  sa  création.  Ancien  système  de  fichier  par  défaut  des 
distributions Suse, reiserfs est aujourd’hui en voie de raréfaction. On lui reproche selon les conditions d’emplois une 
certaine fragilité ou un manque de performances globales. 

xfs

xfs  est  le  filesystem  historique  des  serveurs  unix  IRIX.  Il  a  été  placé  sous  licence  GPL  en  2000.  De  bonnes 
performances  ainsi  que  le  support  des  très  gros  espaces  de  stockages  (8  exaoctets  de  taille  maximum  pour  le 
filesystem contre 16 et 32 teraoctets pour reiserfs et ext3) en font un filesystem intéressant. 

b. Les systèmes de fichiers virtuels ou pseudo­filesystems 

Un filesystem courant a pour objet de permettre l’exploitation d’un espace de stockage physique par un utilisateur 
ou  des  applications.  Il  existe  toutefois  sur  les  systèmes  Linux  des  filesystems  virtuels  qui  n’ont  de  réalité  qu’en 
mémoire  sans  occupation  d’espace  sur  le  disque.  Ils  sont  simplement  visibles  à  l’utilisateur  sans  exploiter  un 
quelconque espace disque. 

proc

Le filesystem virtuel proc, généralement monté sous le répertoire /proc permet de visualiser des éléments systèmes 
liés à la gestion des processus par le noyau. proc montre aussi un certain nombre d’informations systèmes liées au 
matériel. 

Visualisation des informations du processeur 

On  observe  ici  les  informations  techniques  liées  au  microprocesseur  employé.  Notez  par  exemple  la  vitesse  réelle  de 
l’horloge  au  moment  de  l’exécution  de  la  commande,  qui  atteste  de  la  bonne  gestion  de  l’énergie  sur  un  système  peu 
sollicité. 

toto@serveur:~$ cat /proc/cpuinfo

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx
mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni
cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips : 1999.89
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management : ts fid vid ttp tm stc

sys

Le  filesystem  virtuel sys, généralement monté sous le répertoire /sys permet de visualiser des éléments systèmes 


liés aux périphériques. 

Visualisation de capacités hotplug d’un disque dur 

De nombreux pseudo­fichiers de /proc et /sys ont un contenu limité à un seul caractère. Ici 0 pour indiquer que le disque 
sda n’est pas enfichable à chaud. 

toto@serveur:~$ cat /sys/block/sda/removable


O

c. Création des filesystems 

Les filesystems sont créés par l’administrateur sur des espaces de stockages bruts, historiquement des partitions de 
disque. Ils sont ensuite vérifiés, ponctuellement par l’administrateur ou à intervalles réguliers automatiquement par 
le système. La création de filesystems se fait historiquement avec la commande mkfs. 

Syntaxe de la commande mkfs 

mkfs -t type device

mkfs : options et paramètres 

­t type  Précision du type de filesystem à créer : ext2, ext3, reiserfs, xfs... 

device  Fichier spécial en mode bloc qui désigne le périphérique sur lequel créer le filesystem. 

d. Vérification des filesystems 

La vérification d’un filesystem consiste essentiellement en la vérification de cohérence entre la table des inodes du 
filesystem et les blocs de données correspondants. C’est­à­dire que pour chaque inode, on vérifiera que les blocs de 
données  référencés  par  cet  inode  sont  bien  présents,  en  nombre  et  quantité  annoncés.  Pour  les  filesystems 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


journalisés,  une  option ­f oblige une vérification complète d’un filesystem semblant propre, comme par exemple un 
filesystem qui n’aurait pas subi d’opération d’écriture depuis sa dernière vérification réussie. 

La vérification de filesystems se fait avec la commande fsck. 

Syntaxe de la commande fsck 

fsck -t type device

fsck : options et paramètres 

­t type  Type du filesystem à vérifier. 

device  Fichier spécial en mode bloc qui désigne le périphérique sur lequel se trouve le filesystem à 
vérifier. 

e. Commandes spécialisées des filesystems ext 

Les  syntaxes  indiquées  ci­dessus  pour  les  commandes  mkfs  et  fsck  sont  universelles  et  doivent  fonctionner. 
Toutefois, il faut savoir que ces commandes appellent en réalité des sous­programmes (mkfs.ext2 par exemple pour 
mkfs ­t ext2), et qu’il existe par ailleurs des commandes spécialisées qui produiront le même résultat (mke2fs est un 
autre équivalent de mkfs ­t ext2). 

Contrairement à la commande fsck, e2fsck fonctionne par défaut en mode interactif. Pour un fonctionnement 
en mode non interactif, elle doit être utilisée avec l’option ­p. Elle vérifie alors automatiquement le filesystem 
sans nécessiter d’intervention de l’utilisateur. 

f. Création de filesystem ext2 ou ext3 

La commande mke2fs permet de créer directement des filesystems ext. Le format ext2 est utilisé par défaut, mais 
l’option ­j (journal) permet de créer des structures de filesystem ext3. 

Création d’un filesystem ext2 

mke2fs device

Création d’un filesystem ext3 

mke2fs -j device

Où device représente le fichier spécial en mode bloc qui désigne le périphérique sur lequel se trouve le filesystem à 
créer. 

g. Affichage et modification des filesystems ext 

La commande tune2fs permet d’afficher les paramètres d’un filesystem ext et éventuellement d’en modifier certains. 

Affichage des paramètres d’un filesystem avec tune2fs 

tune2fs -l device

Où device représente le fichier spécial en mode bloc qui désigne le périphérique sur lequel se trouve le filesystem à 
vérifier. 
La  différence  entre  le  format  ext2  et  ext3  est  la  présence  ou  non  d’un  journal  des  transactions.  La  commande 
tune2fs permet d’ajouter un journal à un filesystem ext2, et donc de le convertir en ext3. 

Affichage des paramètres d’un filesystem en ext3 

Notez que la mention has_journal figure dans la section Filesystem features, ce qui indique un filesystem de type ext3. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


alpha:/dev# tune2fs -l /dev/hda1
tune2fs 1.41.3 (12-Oct-2008)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: ff700a3b-b430-49a7-ae73-bd23f363a3fc
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode
dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 501952
Block count: 2004100
Reserved block count: 100205
Free blocks: 1656481
Free inodes: 477768
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 489
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8096
Inode blocks per group: 506
Filesystem created: Tue Aug 31 16:35:26 2010
Last mount time: Wed Sep 1 13:26:17 2010
Last write time: Wed Sep 1 13:26:17 2010
Mount count: 4
Maximum mount count: 34
Last checked: Tue Aug 31 16:35:26 2010
Check interval: 15552000 (6 months)
Next check after: Sun Feb 27 15:35:26 2011
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 74c4ea07-489a-4b95-b6e7-94440eeb208f
Journal backup: inode blocks
alpha:/dev#

Les  utilitaires  dumpe2fs,  debugfs  ou  debugreiserfs  permettent  d’obtenir  davantage  d’informations  de  bas 
niveau sur les filesystems. 

Conversion d’un filesystem ext2 en ext3 avec tune2fs 

tune2fs -j device

Où device représente le fichier spécial en mode bloc qui désigne le périphérique sur lequel se trouve le filesystem à 
modifier. 

h. Dénomination des systèmes de fichiers 

Certains paramètres des systèmes de fichiers sont modifiables après leur création. Parmi ces paramètres, certains 
prennent de plus en plus d’importance dans les systèmes Linux modernes, et simplifieront (peut­être) les opérations 
de montage. Ces paramètres sont le label et l’uuid. Ils permettent de monter les filesystems locaux sans avoir à les 
désigner  par  leur  fichier  de  bloc  spécial  comme  /dev/sdb1.  Si  cette  évolution  n’est pas forcément vécue comme un 
progrès ni une simplification par tous, sa généralisation rend sa connaissance nécessaire. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Le label des filesystems

Comme  son  nom  l’indique,  le  label  est  une  étiquette  qu’on  attribue  au  filesystem  pour  le  désigner  de  façon 
confortable. Le label doit être précisé par l’administrateur soit à la création du filesystem, soit après coup avec une 
commande de tuning. Les systèmes d’inspiration Red Hat sont les principaux utilisateurs du label. 

Ajout d’un label sur un filesystem existant 

tune2fs ­L label device  Ajoute un label au périphérique de stockage device. 

reiserfstune ­l label device  Ajoute un label au périphérique de stockage device. 

xfs_admin ­L label device  Ajoute un label au périphérique de stockage device. 

L’UUID des filesystems

L’UUID  (Universally  Unique  Identifier),  comme  le  label,  permet  de  désigner  un  périphérique  de  stockage  par  un 
identifiant  plutôt  que  par  son  fichier  de  bloc  spécial  (/dev/sdb1  par  exemple).  La  différence  avec  le  label  est  que 
l’affectation de l’uuid est automatique à la création du filesystem. Il peut néanmoins être réaffecté après­coup par les 
commandes de tuning des filesystems. De plus en plus de systèmes généralisent l’exploitation de l’uuid. C’est le cas 
notamment des distributions ubuntu. 

Si  vous  ne  savez  pas  comment  déterminer  l’UUID  d’un  nouveau  système,  n’ayez  pas  d’inquiétude,  il  est 
généralement créé de façon aléatoire, et sa taille (128 bits) est le garant de son unicité (probable). 

Modification d’un uuid sur un filesystem existant 

tune2fs ­U uuid device  Affectation de l’UUID uuid au périphérique de stockage device 

tune2fs ­U random device  Affectation d’un UUID aléatoire au périphérique de stockage device 

tune2fs ­U time device  Affectation d’un UUID basé sur l’heure de création au périphérique de 
stockage device 

reiserfstune ­u uuid device  Affectation de l’UUID uuid au périphérique de stockage device 

xfs_admin ­U uuid device  Affectation de l’UUID uuid au périphérique de stockage device 

Dans  le  tableau  ci­dessus,  device  représente  le  fichier  spécial  en  mode  bloc  qui  représente  le  périphérique 
hébergeant le filesystem sur lequel on intervient. Par exemple /dev/sda3. 

2. Gestion du swap 

a. Pourquoi le swap et en quelle quantité ? 

Le swap ou mémoire virtuelle est un espace de stockage exploité pour palier à un manque de mémoire physique sur 
le système. Quand la mémoire physique vient à manquer pour les applications, une partie des informations stockées 
en mémoire et n’ayant pas fait l’objet d’une utilisation récente est déplacée sur l’espace de swap, libérant ainsi de 
l’espace  pour  les  applications  qui  ont  un  besoin  immédiat  de  mémoire.  Si  des  applications  ont  besoin  des 
informations qui ont été basculées sur l’espace de swap, le mécanisme de swap est à nouveau engagé pour libérer 
encore de l’espace en mémoire physique, espace dans lequel les données swappées à nouveau nécessaires seront 
restituées pour exploitation par les applications. 

Il ne faut pas se tromper sur l’utilisation qui doit être faite du swap. En fonctionnement ordinaire, un serveur ou une 
station se travail Linux ne devrait pas avoir à swapper. La grande époque du swap était celle où la mémoire coûtait 
si  cher  qu’il  fallait  trouver  pour  l’équipement  d’un  serveur  un  compromis  entre  le  coût  d’un  système  et  les 
performances qu’il pouvait offrir. Aujourd’hui, les coûts relativement bas de la mémoire font qu’un système ne devrait 
avoir à swapper qu’en  cas  de  surconsommation  accidentelle  de  mémoire.  Le  swap  est  donc  en  quelque  sorte  une 
mémoire  de  secours  qui  évite  de  planter  un  serveur  en  attendant  la  mise  en  adéquation  entre  les  besoins  en 
mémoire et les ressources disponibles. 

La quantité de swap est souvent sujette à caution et selon les auteurs, les sources et les époques. Il est difficile au 
moment de l’installation non automatique d’un système de faire un choix serein. Un consensus semble se déterminer 
autour de valeurs comprises entre une et deux fois la quantité de RAM. De toute façon, les installations par défaut 
des distributions proposent généralement la création d’un espace de swap automatiquement. Pour une installation 
sur mesure, les valeurs courantes (une à deux fois la RAM) sont parfaitement acceptables, et dans le doute, l’espace 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


disque étant aussi très bon marché, il vaut mieux surdimensionner. 

b. Optimisation du swap 

Le  swap  est  optimisable  en  quantité  et  en  qualité.  Il  peut  arriver  que  le  swap  ait  été  sous­dimensionné  à 
l’installation : par exemple, on installe sur un serveur existant une application qui exige une certaine quantité de RAM 
et un swap dix fois supérieur à l’existant. 
Par ailleurs, le swap peut être déplacé vers un espace disque plus rapide : un SAN ou une baie de disque récente et 
donc plus rapide que le système disque initial est installée, et l’exploitation du swap pourrait être plus rapide sur ces 
systèmes de stockage. 
Pour ces raisons, il peut être utile de créer un nouvel espace de swap, qui s’ajoutera ou se substituera à l’espace 
initial. 

Nature de l’espace de swap

Le  swap  peut  être  constitué  de  plusieurs  espaces  de  stockage  qui  sont  des  partitions  ou  des  fichiers.  Dans  la 
mesure  où  le  noyau  accèdera  directement  et  exclusivement  aux  partitions  de  swap,  les  performances  seront 
meilleures qu’avec un fichier de swap où le filesystem représente un intermédiaire supplémentaire vers le stockage 
physique. 

Si le swap est placé sur une partition, elle doit avoir été créée de type 82 avec un outil de partitionnement adéquat 
(fdisk  Linux  par  exemple).  Si  c’est  un  fichier,  il  doit  simplement  être  accessible  en  permanence  sur  un  filesystem 
toujours monté. 

Création de l’espace de swap

Pour  pouvoir  être  exploité,  l’espace  de  swap  doit  être  préparé,  un  peu  comme  on  créerait  un  filesystem  sur  un 
espace  de  stockage  brut.  Cette  préparation  se  fait  avec  la  commande  mkswap,  et  elle  peut  être  appliquée  aussi 
bien à une partition qu’à un fichier de taille déterminée. 

Syntaxe de la commande mkswap 

mkswap espace_stockage

Où espace_stockage représente l’emplacement physique de l’espace de swap dont la dénomination peut se faire de 
différentes façons : 

Désignations possibles des espaces de stockage pour la commande mkswap 

/chemin/fichier  Structure le fichier afin qu’il puisse être exploité en tant qu’espace de swap. 

/dev/device  Structure l’espace de stockage désigné par le fichier spécial en mode bloc afin qu’il 
puisse être exploité en tant qu’espace de swap. 

­L LABEL  Structure l’espace de stockage désigné par le label LABEL afin qu’il puisse être 
exploité en tant qu’espace de swap. 

­U UUID  Structure l’espace de stockage désigné par l’uuid UUID afin qu’il puisse être exploité 
en tant qu’espace de swap. 

Exploitation du swap

Une fois l’espace de swap créé, il doit être rendu accessible au noyau par la commande swapon. Le système sera 
alors capable de swapper à partir du nouvel espace créé. 

Syntaxe de la commande swapon pour activer un espace de swap 

swapon espace_stockage

Où espace_stockage représente l’emplacement physique de l’espace de swap dont la dénomination peut se faire de 
différentes façons : 

Désignations possibles des espaces de stockage pour la commande swapon 

/chemin/fichier  Rend le fichier utilisable pour le swap par le noyau. 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


/dev/device  Rend l’espace de stockage désigné par le fichier spécial en mode bloc utilisable pour 
le swap par le noyau. 

­L LABEL  Rend le stockage dont le label est LABEL utilisable pour le swap par le noyau. 

­U UUID  Rend le stockage dont l’uuid est UUID utilisable pour le swap par le noyau. 

Désactivation d’un espace de swap

Si on souhaite que le système arrête d’exploiter un espace de swap, il faut le lui signifier avec la commande swapoff. 

Syntaxe de la commande swapoff pour desactiver un espace de swap 

swapoff espace_stockage

Où espace_stockage représente l’emplacement physique de l’espace de swap dont la dénomination peut se faire de 
différentes façons : 

Désignations possibles des espaces de stockage pour la commande swapoff 

/chemin/fichier  Arrête l’exploitation de l’espace de swap sur le fichier. 

/dev/device  Arrête l’exploitation de l’espace de swap sur le device. 

­L LABEL  Arrête l’exploitation de l’espace de swap sur le stockage dont le label est LABEL. 

­U UUID  Arrête l’exploitation de l’espace de swap sur le stockage dont l’uuid est UUID. 

Visualisation des espaces de swap

L’ensemble des espaces de swap exploités, ainsi que leur nature (fichier ou partition) peuvent être affichés avec les 
commandes swapon et swapoff évoquées précédemment. 

Syntaxe de la commande swapon pour visualiser la configuration du swap 

swapon -s

Exemple d’utilisation de la commande swapon 

La commande indique la partition ou le fichier utilisé, la taille réservée et la quantité de swap utilisée. 

A:~# swapon -s
Filename Type Size Used Priority
/dev/hda5 partition 409616 608 -1

Autre visualisation du swap 

Il  est  également  possible  de  visualiser  la  configuration  du  swap  en  consultant  le  contenu  du  fichier  swap  du  filesystem 
virtuel /proc. 

toto@cuicui:~$ cat /proc/swaps


Filename Type Size Used Priority
/dev/sda3 partition 10112908 2024
-1

3. Montage des filesystems 

a. Montage et démontage 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


La  commande  mount  permet  de  monter  le  filesytem  d’un  périphérique  de  stockage  sous  un  répertoire  local, 
généralement vide. Au minimum, il faut fournir comme argument à la commande mount le périphérique hébergeant le 
filesystem, et le répertoire qui constituera son point de montage. 
La  commande  umount  réalise  l’opération  inverse.  Elle  accepte  comme  argument  le  point  de  montage,  ou  le 
périphérique physique à démonter. 

Montage d’un filesystem 

mount -t type_fs -o options device point_montage

commande mount : options et paramètres 

type_fs  Facultatif : type de filesystem à monter. 

options  Facultatif : options de montage. 

device  Le périphérique hébergeant un filesystem à monter, sous forme de fichier spécial 
bloc. 

point_montage  Le répertoire qui servira de point d’ancrage au filesystem monté. 

Les  options  les  plus  courantes  sont  ro  (lecture  seule),  sync  (écritures  synchrones  sans  passer  par  un  cache 
mémoire), et loop (montage de données de fichiers plutôt que de filesystems). 

Le montage d’un filesystem avec l’option sync permet de s’affranchir de toute forme de cache en écriture sur 
le disque, et ainsi de fiabiliser les opérations d’écriture. La commande sync permet de vider ponctuellement 
le cache sur un filesystem qui ne bénéficie pas de cette option de montage. 

Démontage d’un filesystem 

umount -O options device point_montage

commande umount : options et paramètres 

options  Facultatif : options de démontage. 

device  Facultatif si le point de montage est précisé : le périphérique à démonter. 

point_montage  Facultatif si le périphérique est précisé : le répertoire servant de point de 


montage à libérer. 

Les  options  les  plus  courantes  sont  ­f  (force :  forcer  le  démontage)  et  ­l  (lazy :  démontage  paresseux  qui  sera 
effectif quand toutes les ressources utilisées pour le montage auront pu être libérées. 
Le  démontage  d’un  filesystem  est  indispensable  pour  en  effectuer  la  vérification  avec  la  commande  e2fsck.  Le 
filesystem  monté  sur  /  est  par  définition  indémontable  puisque  toujours  occupé.  Il  est  possible  de  forcer  la 
vérification avant le montage lors du démarrage depuis la commande shutdown. 

Vérification du filesystem racine avant montage 

shutdown -F -r now

b. Visualisation des filesystems montés 

La commande mount sans argument permet de visualiser les filesystems montés. 

Par  ailleurs,  chaque  montage  réussi  provoque  l’écriture  d’une  ligne  correspondante  dans  le  fichier  /etc/mtab. 
L’affichage du fichier /proc/mounts renvoie la même information. 

c. Fichier fstab 

- 8- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Le  fichier  /etc/fstab  permet  de  désigner  des  filesystems  à  monter  ou  des  espaces  de  swap  à  activer 
automatiquement  au  démarrage.  Accessoirement,  il  permet  aussi  de  désigner  des  filesystems  éventuellement 
montables,  comme  pour  les  périphériques  amovibles  par  exemple.  La  syntaxe  de  la  commande  mount  appelée 
ponctuellement en sera alors fortement simplifiée. 
Le  fichier  /etc/fstab  doit  comporter  sur  chaque  ligne  l’ensemble  des  éléments  nécessaires  au  montage  d’un 
filesystem, à savoir le point de montage, la désignation de l’espace de stockage, et les options de montage. Pour les 
espaces de swap, la désignation du point de montage sera sans objet. 
Le fichier /etc/fstab est composé d’une ligne par filesystem à monter, chaque ligne étant composée de six champs 
obligatoires. 

Format type d’une ligne de déclaration de montage dans /etc/fstab 

fs pointmontage type options dump fsck

Les champs sont séparés par des espaces ou des tabulations. 

Fichier /etc/fstab : format des lignes de définition des montages 

Numéro de  Champ  Désignation 


champ 

1  fs  Filesystem, désigné par son fichier de bloc spécial, son label ou son 
uuid. 

2  pointmontage  Point de montage. 

3  type  Type de filesystem. Obligatoirement swap pour le swap, auto ou 
type effectif de filesystem dans le cas contraire. 

4  options  Options de montage. En fait, les options admises par la commande 
mount. 

5  dump  Facultatif. Si la commande dump est utilisée pour la sauvegarde du 
système, ce champ doit être à 1 pour assurer la sauvegarde. Sinon, 
sa valeur par défaut est 0. 

6  fsck  Facultatif. En cas de vérification automatique des filesystems au 
démarrage, indique dans quel ordre cette vérification doit se faire. 
Valeur obligatoire de 1 pour le filesystem monté sur /, 2 pour les 
autres. 0 pour que la vérification ne soit jamais effectuée. 

Exemple de fichier /etc/fstab sur Ubuntu 

Notez que les disques sont identifiés par leur uid. 

# /etc/fstab: static file system information.


#
# <file system> <mount point> <type> <options> <dump>
<pass>
proc /proc proc defaults 0 0
# /dev/sda2
UUID=52200c0b-aee8-4ae0-9492-1f488051e4a3 / ext3
relatime,errors=remount-ro 0 1

# /dev/sdb1
UUID=b0891c0e-1812-4d23-b77d-b861f7fd2713 /home ext3
relatime,errors=remount-ro 0 2
# /dev/sda3
UUID=ee7890fb-c312-406f-b100-669c97ee8d07 none swap
sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8
0 0

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 9-


Exemple de fichier /etc/fstab sur Red Hat 

Les disques sont identifiés par leur label. 

LABEL=/ / ext3 defaults


1 1
LABEL=/boot /boot ext3 defaults
1 2
/dev/hda3 swap swap defaults
0 0
/dev/cdrom /mnt/cdrom udf,iso9660
noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto
noauto,owner,kudzu 0 0

La commande mount ­a est appelée au démarrage d’un système. Cette commande provoque le montage de tous les 
périphériques  référencés  dans  le  fichier  /etc/fstab,  à  l’exception  de  ceux  qui  présentent  l’option  noauto  dans  le 
quatrième champ. 

d. Automontage 

Le  montage  peut  être  une  opération  pénible  à  réaliser  pour  l’opérateur.  Certaines  fonctionnalités  optionnelles 
permettent de s’affranchir dans une certaine mesure de la connaissance des fonctions et commandes de montage. 
Les  bureaux  graphiques  Gnome  ou  KDE  par  exemple  gèrent  depuis  longtemps  le  montage  automatique  des 
périphériques amovibles insérés. L’automontage est une technique qui permet de monter à la volée un filesystem en 
fonction de l’accès qui y est fait par l’utilisateur. L’automontage est en voie de raréfaction sur les postes de travail 
autonomes, mais très efficace sur les systèmes de fichiers distribués. 

Configuration de l’automontage

L’automontage s’appuie sur deux fichiers de paramétrage : les tables d’automontage, et sur un service qui vérifie en 
permanence s’il est besoin de réaliser des opérations de montage. 
La  première  table  d’automontage,  la  table  maîtresse  est  configurée  dans  le  fichier  /etc/auto.master.  Elle  précise 
l’ensemble des répertoires soumis à automontage, c’est­à­dire les répertoires dans lesquels pourront avoir lieu des 
montages automatiques si une application fait appel à un contenu de ce répertoire. On créera dans ce fichier autant 
de lignes qu’il y aura de répertoires à surveiller. 

Format de la table maîtresse d’automontage (/etc/auto.master) 

- 10 - © ENI Editions - All rights reserved - Sanisa HOUAMRI


repertoire fic_sec --option=valeur

Fichier /etc/auto.master : directives et variables utilisées 

repertoire  Le répertoire dans lequel les accès seront surveillés pour voir s’il y a lieu de procéder au 
montage. 

fic_sec  Le fichier de table secondaire qui précise les montages à réaliser pour le répertoire. 

option  Option liée à la gestion de l’autofs. Option courante à connaître : timeout. La valeur est 
alors le nombre de secondes avant le démontage en cas d’inactivité. 

Le  nom  des  fichiers  de  table  secondaire  est  libre,  même  s’il  porte  généralement  le  préfixe  «  auto.  »  et  se  situe 
dans /etc. Il faudra autant de fichiers secondaires qu’on en aura décrit dans la table maîtresse. Dans bien des cas, 
une  table  secondaire  unique  est  suffisante.  Chaque  table  secondaire  correspond  au  chargement  d’un  démon 
indépendant. 

Format de fichier d’une table secondaire 

pmv options device

Fichier de table secondaire d’automontage : directives et variables 

pmv  Point de montage virtuel : le répertoire virtuel dont l’accès par une application provoquera 
le montage. 

options  Les options de montage, précédées par un tiret et séparées par des virgules. 

device  Le périphérique à monter. 

Gestion du service d’automontage

Pour prendre en compte la nouvelle configuration, il faudra redémarrer le service. Le script de lancement du service 
s’appelle généralement autofs, et il est situé dans /etc/init.d. 
 
Tout changement de table maîtresse doit s’accompagner d’un redémarrage du service.

Redémarrage du service 

/etc/init.d autofs restart

Visualisation de la configuration 

/etc/init.d autofs status

Fonctionnement de l’automontage

Pour tester la configuration de votre automontage, suivez les étapes suivantes : 

■ Créez le répertoire de travail. Ne créez pas les points de montage, ils ne doivent pas exister. 

■ Renseignez les fichiers de configuration. 

■ Redémarrez le service. 

■ Depuis le shell, positionnez­vous en aveugle dans le point de montage virtuel, celui qui est décrit dans le fichier de 
table secondaire. 

■ Vérifiez que le montage a bien eu lieu de façon transparente. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 11 -


4. Gestion des disques durs 

Dans la plupart des situations, les connaissances courantes sur la dénomination courante des disques durs (hda, sda) 
sont suffisantes, et on se concentre surtout sur la façon de les exploiter sous forme de partitions ou volumes logiques. 
Il  arrive  toutefois  qu’il  soit  nécessaire  de  paramétrer  les  disques  durs  du  point  de  vue  matériel,  pour  optimiser  les 
performances ou pour détecter des défaillances. 

a. Détermination des fichiers spéciaux 

Il  y  a  quelque  temps  encore,  les  systèmes  Linux  contenaient  dans  leur  répertoire  /dev  l’ensemble  des  fichiers 
spéciaux pour tous les périphériques gérables par le noyau. Avec le noyau 2.6 est arrivé le service udev, qui a pour 
tâche de gérer dynamiquement la création de fichiers spéciaux à la découverte d’un périphérique. 
Du  point  de  vue  de  l’utilisateur  ordinaire,  le  service  udev  travaille  dans  l’ombre  et  le  mieux  est  de  ne  pas  s’en 
soucier :  les  fichiers  spéciaux  sont  présents  quand  on  en  a  besoin  et  il  n’y  a  rien  à  vouloir  de  plus.  En  revanche, 
l’administrateur  ou  l’utilisateur  avancé  peut  créer  des  règles  comportementales  qui  permettent  de  déclencher  des 
actions  en  fonction  d’évènements  liés  au  stockage.  L’emplacement  de  ces  règles  est  précisé  dans  le  fichier  de 
configuration  de  udev :  /etc/udev/udev.conf.  En  l’absence  d’information,  c’est  la  valeur  par  défaut  qui  est 
employée, à savoir /etc/udev/rules.d. 

Exemple de règle udev 

Dans  cette  configuration  standard  d’une  distribution  Ubuntu,  on  voit  (après  quelques  efforts  d’interprétation)  que  le 
système génère des liens symboliques pour les différentes appellations courantes du lecteur de media optique. 

root@serveur # cat /etc/udev/rules.d/70-persistent-cd-rules


ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-
0:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-
0:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-
0:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-
0:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

b. Informations sur les périphériques de stockage 

Grâce au service udev, on ne trouve plus dans le répertoire /dev que les périphériques réellement présents sur le 
système. Cela constitue naturellement un premier niveau d’informations. 
La  solution  la  plus  simple  pour  obtenir  plus  de  détails  est  d’exploiter  la  commande  dmesg  qui  consigne  tous  les 
messages renvoyés par le noyau depuis son démarrage. On dit que la commande dmesg affiche le  ring­buffer du 
noyau. 

Utilisation de dmesg pour identifier les disques durs 

Il est vivement recommandé de filtrer la sortie de la commande dmesg, celle­ci étant par nature assez bavarde. 

alpha:~# dmesg | grep [sh]d


[ 0.000000] Kernel command line: root=/dev/hda1 ro quiet
[ 3.136965] hda: VBOX HARDDISK, ATA DISK drive
[ 3.822425] hda: host max PIO4 wanted PIO255(auto-tune)
selected PIO4
[ 3.822677] hda: UDMA/33 mode selected
[ 4.575784] hdc: VBOX CD-ROM, ATAPI CD/DVD-ROM drive
[ 5.275977] hdc: host max PIO4 wanted PIO255(auto-tune)
selected PIO4
[ 5.275977] hdc: UDMA/33 mode selected
[ 7.203721] hda: max request size: 128KiB
[ 7.203728] hda: 16777216 sectors (8589 MB) w/256KiB Cache,
CHS=16644/16/63
[ 7.204020] hda: cache flushes supported
[ 7.204020] hda: hda1 hda2 < hda5 >
[ 7.234912] hdc: ATAPI 32X DVD-ROM drive, 128kB Cache

- 12 - © ENI Editions - All rights reserved - Sanisa HOUAMRI


[ 7.257272] Driver ’sd’ needs updating - please use bus_type methods
[ 7.257525] sd 0:0:0:0: [sda] 4194304 512-byte hardware sectors
(2147 MB)
[ 7.257620] sd 0:0:0:0: [sda] Write Protect is off
[ 7.257627] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7.257769] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn’t support DPO or FUA
(...)

Récupération d’informations sur un périphérique par la commande udevadm 

Le  service  udev  peut  aussi  nous  fournir  des  informations  précieuses  par  le  biais  de  sa  commande  d’administration 
udevadm. 

alpha:~# udevadm info --query=all --name=/dev/hda


P: /block/hda
N: hda
S: block/3:0
S: disk/by-id/ata-VBOX_HARDDISK_VBf92d3e4d-7faf607b
S: disk/by-path/pci-0000:00:01.1-ide-0:0
E: ID_TYPE=disk
E: ID_MODEL=VBOX_HARDDISK
E: ID_SERIAL=VBf92d3e4d-7faf607b
E: ID_REVISION=1.0
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:01.1-ide-0:0

Surveillance d’événements par la commande udevmonitor (ou udevadm monitor) 

On peut surveiller quasiment en temps réel les événements système. 

toto@ubuntu:~$ udevmonitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1276268963.339194] change
/devices/pci0000:00/0000:00:14.1/host4/target4:0:0/4:0:0:0 (scsi)
KERNEL[1276268963.339804] change
/devices/pci0000:00/0000:00:14.1/host4/target4:0:0/4:0:0:0/block/sr0 (block)
(...)

Visualisation des paramètres de périphériques avec lsdev 

La commande lsdev permet de récupérer des informations sur les périphériques reconnus, notamment les valeurs DMA, 
IRQ et I/O. Ces valeurs sont lues dans les fichiers /proc/interrupts, /proc/ioports, et /proc/dma. 

toto@ubuntu:~$ lsdev
Device DMA IRQ I/O Ports
------------------------------------------------
0000:00:01.1 0170-0177 01f0-01f7 0376-0376 03f6-03f6
d000-d00f
0000:00:03.0 d020-d03f
0000:00:04.0 d040-d05f
0000:00:05.0 d100-d1ff d200-d23f
82801AA-ICH 5
ACPI 4000-4003 4004-4005 4008-400b 4020-4021
ata_piix 14 15 0170-0177 01f0-01f7 0376-0376 03f6-03f6
d000-d00f
cascade 4 2
eth0 10
floppy 2 6 03f2-03f2 03f4-03f5 03f7-03f7
vga+ 03c0-03df
toto@ubuntu:~$

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 13 -


Récupération d’informations du répertoire /dev/disk 

Enfin, on trouve sous le répertoire /dev/disk les éléments de stockage apparaissant selon la façon dont ils sont reconnus 
et identifiés par le système. 

root@serveur:/dev/disk$ ls
by-id by-label by-path by-uuid
root@serveur:/dev/disk$ cd by-uuid
root@serveur:/dev/disk/buy-uuid$ ls
52200c0b-aee8-4ae0-9492-1f488051e4a3 B0F82CDCF82CA318
b0891c0e-1812-4d23-b77d-b861f7fd2713 ee7890fb-c312-406f-b100-669c97ee8d07
root@serveur:/dev/disk/by-uuid$ file *
52200c0b-aee8-4ae0-9492-1f488051e4a3: symbolic link to `../../sda2’
b0891c0e-1812-4d23-b77d-b861f7fd2713: symbolic link to `../../sdb1’
B0F82CDCF82CA318: symbolic link to `../../sda1’
ee7890fb-c312-406f-b100-669c97ee8d07: symbolic link to `../../sda3’
root@serveur:/dev/disk/by-uuid$

c. Gestion des performances avec hdparm 

La commande hdparm permet de consulter et configurer de nombreux paramètres du disque dur, certains d’ailleurs 
dangereux pour le disque. 

Visualisation des paramètres fonctionnels avec hdparm 

alpha:~# hdparm /dev/hda


/dev/hda:
multcount = 0 (off)
IO_support = 0 (default)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16644/16/63, sectors = 16777216, start = 0

Si  le  matériel  le  supporte,  les  paramètres  fonctionnels  du  disque  peuvent  être  modifiés  avec  l’option  appropriée 
suivie  d’un  paramètre  numérique,  en  général  0  ou  1.  Les  options  les  plus  courantes  sont  c  (activation  ou 
désactivation de l’accès 32 bits au disque) et  d (activation ou désactivation de l’accès DMA). Une option demandée 
sans valeur numérique associée entraine l’affichage de la valeur courante. 

Consultation de l’accès 32 bits 

alpha:~# hdparm -c /dev/hda


/dev/hda:
IO_support = 0 (default)

Consultation puis suppression de la lecture anticipée 

alpha:~# hdparm -a /dev/hda


/dev/hda:
readahead = 256 (on)
alpha:~# hdparm -a 0 /dev/hda
/dev/hda:
setting fs readahead to 0
readahead = 0 (off)

Visualisation, activation et désactivation de l’accès DMA 

alpha:~# hdparm -d /dev/hda


/dev/hda:
using_dma = 0 (off)
alpha:~# hdparm -d 1 /dev/hda

- 14 - © ENI Editions - All rights reserved - Sanisa HOUAMRI


/dev/hda:
setting using_dma to 1 (on)
using_dma = 1 (on)
alpha:~# hdparm -d 0 /dev/hda
/dev/hda:
setting using_dma to 0 (off)
using_dma = 0 (off)

Une  autre  commande  :  sdparm,  moins  courante  permet  une  communication  de  bas  niveau  avec  les 
périphériques SCSI, par exemple pour réaliser leur désactivation pour retrait à chaud. 

d. Gestion des défaillances matérielles 

Nous avons vu que la commande fsck permettait de vérifier la cohérence d’un filesystem. Si une incohérence est due 
à  un  problème  de  gestion  de  l’écriture  (arrêt  électrique  lors  d’une  opération  d’écriture),  fsck  peut  essayer  de 
récupérer tant bien que mal la situation et une fois résolu, le problème peut être oublié. En revanche, la défaillance 
physique d’un disque, liée à un défaut de la surface magnétique par exemple, doit être traitée de façon adéquate 
pour éviter toute conséquence ultérieure. La commande badblocks référence les blocs physiquement défectueux sur 
un  disque  ou  une  partition.  La  liste  des  blocs  défectueux  est  envoyée  sur  la  sortie  standard,  mais  il  est  courant 
d’utiliser un fichier qui sera exploitable par les programmes e2fsck ou mke2fs. Dans ce cas, il faut préciser la taille 
des blocs employés pour éviter tout ennui. Si le but est simplement de vérifier l’absence de défaut sur le disque, la 
commande badblocks peut être utilisée sans aucune option. 

Détection des blocs en erreur avec badblocks 

badblocks -b taille_blocks -o fichier_sortie

Où  taille_blocks  représente  la  taille  des  blocs  du  système  de  fichiers  et  fichier_sortie  le  fichier  qui  consignera 
l’ensemble des blocs altérés. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 15 -


Sauvegardes 
La gestion de la sauvegarde revêt bien des aspects sur les systèmes Linux. Des outils historiques qui géraient dans le 
meilleur  des  cas  un  lecteur  de  bande  local  jusqu’aux  outils  modernes  sophistiqués  et  aux  logiciels  de  sauvegarde 
commerciaux,  l’éventail  est  large.  L’essentiel  est  de  connaître  les  moyens  disponibles,  et  d’adapter  sa  stratégie  de 
sauvegarde à ses besoins en fonction du temps et de l’argent qu’on est prêt à investir dans la sauvegarde. 

1. Les utilitaires d’archivage 

Les  utilitaires  d’archivage  permettent  de  réaliser  les  sauvegardes  les  plus  simples,  et  grâce  à  cette  simplicité,  sans 
doute les plus fiables. Leur principe est simple : elles envoient un ensemble de fichiers (en général une arborescence 
de répertoires) vers un fichier, qu’il s’agisse d’un fichier ordinaire ou d’un fichier spécial qui désigne un périphérique de 
stockage. 

a. La commande tar 

La  commande  tar,  d’usage  universel  dans  les  environnements  Linux,  est  à  connaître  absolument.  Sa  richesse 
fonctionnelle  peut  impressionner,  mais  si  la  commande  tar  présente  de  très  nombreuses  options,  moins  d’une 
dizaine sont utilisées dans la plupart des situations. 

Syntaxe de la commande tar pour créer une archive 

tar action compression verbosité -f fichier_archive répertoire

Syntaxe de la commande tar pour lister ou extraire une archive 

tar action compression verbosité -f fichier_archive

Commande tar : options et paramètres 

action  ­c  Crée une archive. Il faut alors indiquer en dernier paramètre le répertoire 


à partir duquel l’archive est créée. 

­t  Liste le contenu d’une archive existante. 

­x  Extrait le contenu d’une archive existante dans le répertoire courant. 

compression  Pas de compression sur l’archive manipulée. 

­z  Compression au format gzip de l’archive manipulée. 

­j  Compression au format bz2 de l’archive manipulée. 

verbosité  Pas de verbosité, affichage minimum. 

­v  Verbosité, affichage détaillé. 

fichier_archive  Le fichier qui reçoit ou héberge l’archive. Ce fichier peut être un fichier 
spécial en mode bloc ou en mode caractères. Aujourd’hui presque 
toujours un fichier ordinaire. 

répertoire  Dans le cadre d’une création d’archive, désigne le répertoire à partir 
duquel l’archive est créée. 

Même  si  ça  n’est  pas  une  obligation,  il  est  d’usage  d’affecter  une  extension  «  .tar  »  aux  fichiers  contenant  une 
archive tar, suivie d’une extension liée au mode de compression « .gz » ou « .bzip2 ». 
Dans  un  usage  de  la  commande  tar  à  des  fins  de  sauvegarde,  on  dirigera  l’archive  de  sauvegarde  vers  un 
périphérique amovible ou vers un espace de stockage distant. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Exemple d’utilisation de la commande tar 

Dans  cet  exemple,  on  crée  une  archive  tar  compressée  à  partir  d’un  répertoire,  on  efface  le  répertoire,  puis  on  le 
restaure à partir de l’archive. 

A:~# ls
trucs
A:~# # remarque : création de l’archive
A:~# tar czf sauvegarde.tar.gz trucs
A:~# ls
sauvegarde.tar.gz trucs
A:~# # remarque : destruction du répertoire trucs
A:~# rm -r trucs
A:~# ls
sauvegarde.tar.gz
A:~# # remarque : restauration de l’archive
A:~# tar xzf sauvegarde.tar.gz
A:~# ls
sauvegarde.tar.gz trucs
A:~#

Si  la  commande tar  est  employée  pour  créer  une  archive  sur  bande  magnétique  et  non  sur  disque,  il  est 
recommandé de ne pas utiliser d’option de compression. Le format compressé empêcherait une récupération 
partielle des données en cas de détérioration de la bande. 

b. La commande cpio 

La  commande  cpio  dont  l’usage  tend  à  disparaître  en  environnement  Linux  permet  de  réaliser  des  archives  non 
compressées d’un ensemble de fichiers et répertoires. 
cpio  est  d’un  usage  particulièrement  non  intuitif,  et  n’est  en  général  utilisé  que  dans  des  cas  spécifiques.  Le 
problème de cpio vient de ce que cette commande n’accepte pas qu’on lui désigne les éléments à sauvegarder en 
tant que paramètre comme le fait la commande tar. Il faut lui indiquer ces éléments sous forme de liste de fichiers 
sur son entrée standard. De même, toutes les manipulations en sortie se font par redirection de la sortie standard. 
Si  la  commande  cpio  a  survécu  malgré  ces  handicaps  d’un  autre  temps,  c’est  justement  grâce  à  ces  limitations 
syntaxiques  :  la  liste  de  fichiers  à  sauvegarder  est  presque  toujours  fournie  par  redirection  du  résultat  d’une 
commande  find.  Or,  la  commande  find  est  capable  de  faire  des  recherches  extrêmement  précises  sur  de  très 
nombreux critères. C’est donc dans les cas où l’on veut faire des sauvegardes très sélectives que l’on utilisera cpio. 

Syntaxe de la commande cpio pour créer une archive 

find répertoire critère -print | cpio options > fichier_archive

Syntaxe de la commande cpio pour lister ou extraire une archive 

cpio options < fichier_archive

Commande cpio : options et paramètres 

répertoire  Le répertoire de base à partir duquel se fait la recherche. 

critère  Critères de recherche selon la syntaxe de la commande find. 

options  ­o  Mode copy­out. Indique qu’on est en mode de création d’archive. Exclusif 


des options i et t. 

­t  Associée à l’option i, liste le contenu d’une archive existante. Exclusif de 
l’option o. 

­i  Mode copy­in. Indique qu’on est en mode d’extraction ou de consultation 
d’archive. Exclusif de l’option o. 

­v  Facultatif : rend la commande bavarde. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


fichier_archive  Le fichier (spécial ou ordinaire) qui recevra l’archive. 

Exemple d’utilisation de la commande cpio 

S’il est indispensable de savoir utiliser la commande tar naturellement, on peut raisonnablement ne pas se souvenir de la 
syntaxe cpio. 

A:~# ls
trucs
A:~# # remarque : création de l’archive
A:~# find trucs -print | cpio -o > archive.cpio
1 block
A:~# ls
archive.cpio trucs
A:~# # remarque : destruction du répertoire trucs
A:~# rm -rf trucs
A:~# # remarque : restauration de l’archive
A:~# cpio -i < archive.cpio
1 block
A:~# ls
archive.cpio trucs
A:~#

2. Les logiciels de sauvegarde 

a. AMANDA 

AMANDA :  Advanced Maryland Automatic Network Disk Archiver est une solution de sauvegarde crée initialement par 
l’université du Maryland sous licence BSD. Disponible sous licence communautaire (gratuite) ou commerciale, AMANDA 
permet de sauvegarder localement ou en réseau, sur disques ou sur bandes, les données des systèmes Linux/Unix 
ou Windows. 

b. Bacula 

Bacula est une solution de sauvegarde sous licence GPL qui permet de sauvegarder localement ou en réseau, sur 
disques ou sur bandes, les données des systèmes Linux/Unix ou Windows. 

c. BackupPC 

BackupPC est une solution de sauvegarde sous licence GPL qui permet de sauvegarder localement ou en réseau, sur 
disques ou sur bandes, les données des systèmes Linux/Unix ou Windows. 

d. Les logiciels commerciaux 

La  plupart  des  grands  éditeurs  de  logiciels  de  sauvegarde  supportent,  souvent  en  option,  la  sauvegarde  des 
systèmes Linux. Il faudra alors installer sur chaque système un agent de sauvegarde qui permettra de renvoyer les 
données vers le serveur de sauvegarde. 

3. Duplication et synchronisation de données 

a. Copie binaire avec dd 

La commande de copie bloc à bloc dd permet de réaliser des copies de bas niveau d’un périphérique. Elle est utilisée 
notamment  pour  la  duplication  de  disques  durs,  mais  aussi  pour  la  création  d’images binaires de périphériques de 
stockage. 

Syntaxe générique de la commande dd 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


dd if=entrée of=sortie bs=taille_blocs count=nombre_blocs

Commande dd : options et paramètres 

entrée  Le fichier à copier. Généralement un fichier spécial en mode bloc. 

sortie  Le fichier vers lequel copier. Fichier spécial en mode bloc ou fichier ordinaire. 

taille_blocs  Facultatif. Désigne la taille des blocs à copier. 

nombre_blocs  Facultatif. Le nombre de blocs à copier. Si le paramètre est omis, la copie s’arrête 
dès qu’elle n’est plus possible. 

Utilisation de la commande dd pour une copie de disque dur 

Copie du disque sdb vers le disque sdc. 

root@serveur# dd if=/dev/sdb of=/dev/sdc


root@serveur#

Utilisation de la commande dd pour réaliser l’image iso d’un cdrom 

Le fichier iso généré est gravable par n’importe quel logiciel ou utilisable dans une machine virtuelle. 

root@serveur# dd if=/dev/cdrom of=/home/toto/image.iso


root@serveur#

Utilisation de la commande dd pour effacer physiquement une clé usb 

Effacement  physique  de  tous  les  blocs  d’une  clé  usb  vue  comme  le  périphérique  sdd.  Attention,  les  données  ne  sont 
récupérables par aucun moyen simple. Ne vous trompez pas de disque ! 

root@serveur# dd if=/dev/zero of=/mnt/sdd


root@serveur#

Utilisation de la commande dd pour créer un fichier vide de 100 Mo 

Commande dd utilisée pour recevoir un espace de swap, ou générer de gros fichiers pour des tests de copie. 

root@serveur# dd if=/dev/zero of=/home/toto/fichiervide bs=1024 count=100000


root@serveur#

b. Génération de fichier iso avec mkisofs 

Les  fichiers  iso  sont  des  images  binaires  de  cdrom  ou  dvdrom.  Les  images  iso  sont  montables  par  la  commande 
mount, gravables par n’importe quel logiciel de gravure, et exploitables depuis les machines virtuelles où elles sont 
vues  comme  un  cdrom.  Il  peut  être  utile  de  générer  des  images  iso  à  partir  d’une  arborescence  de  fichiers  et 
répertoires ; la commande mkisofs est là pour ça. 

Syntaxe de la commande mkisofs 

mkisofs -J -o image répertoire

Commande mkisofs : options et paramètres 

­J  Facultatif : génère des enregistrements Joliet en plus de la structure de noms 


iso9960. Améliore la compatibilité avec les systèmes Windows. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


­o image  Le fichier iso qui sera généré. Généralement avec l’extension « .iso ». 

répertoire  Le répertoire à partir duquel l’image iso sera générée. 

Exemple d’utilisation de la commande mkisofs 

Le fichier iso généré peut être gravé directement par n’importe quel logiciel de gravure. 

bob@cuicui:~/Temp$ ls
data
bob@cuicui:~/Temp$ mkisofs -o imgcd.iso data
I: -input-charset not specified, using utf-8 (detected in locale settings)
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 8192
Path table size(bytes): 50
Max brk space used 23000
178 extents written (0 MB)
bob@cuicui:~/Temp$ ls
imgcd.iso data
bob@cuicui:~/Temp$ file imgcd.iso
imgcd.iso: ISO 9660 CD-ROM filesystem data ’CDROM ’
bob@cuicui:~/Temp$

mkisofs  est  le  nom  historique  de  la  commande  permettant  de  créer  des  fichiers  iso.  Toutefois,  cette 
commande  a  été  renommée  récemment  en  genisoimage,  et  mkisofs  est  présent  sur  les  distributions 
récentes sous forme de lien symbolique vers genisoimage. 

L’image iso ainsi générée est un fichier unique a priori insondable hors de son exploitation par un logiciel adapté. En 
fait, il est possible de monter le fichier image comme s’il s’agissait d’un périphérique ordinaire. 

Montage local d’une image iso 

mount -o loop fichier_image point_montage

Où  fichier_image  représente  l’image  iso  à  monter,  et  point_montage  le  répertoire  qui  recevra  ce  montage.  L’option 
loop est indispensable pour le montage d’un fichier image. 

c. Synchronisation de données avec rsync 

Dans le cadre des stratégies de préservation des données, il peut être utile de répliquer des données d’un serveur 
sur  un  autre,  soit  afin  de  garantir  une  disponibilité  géographique  de  données  identiques,  soit  pour  se  préserver 
d’une défaillance d’un disque dur ou d’un serveur. La commande rsync remplit cet office à merveille. 

rsync  propose  plusieurs  modes  de  fonctionnement,  mais  le  plus  courant  dans  le  cadre  de  synchronisation  de 
données est de disposer d’un service rsync sur un serveur, et de planifier des synchronisations régulières depuis les 
machines contenant les données à répliquer. 

Configuration d’un serveur rsync

La  configuration  se  fait  par  le  biais  de  deux  fichiers  :  le  fichier  /etc/default/rsync  qu’il  faudra  modifier,  et  le 
fichier /etc/rsyncd.conf qu’il faudra créer. 

Modification du fichier /etc/default/rsync 

RSYNC_ENABLE=true

Ce paramètre permet le démarrage automatique ou manuel de rsync en tant que service. 

Création du fichier /etc/rsyncd.conf 

uid = utilisateur

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


read only = false
[instance]
path = répertoire

Fichier /etc/rsyncd.conf : directives et paramètres 

utilisateur  Le compte au nom duquel les opérations d’écritures seront réalisées sur le serveur. 

read only = false  Indispensable pour que le service puisse écrire sur le disque. 

instance  Nom au choix, il y aura autant d’instances que de clients à répliquer. Ce nom sera 
repris sur le client lors de la demande de synchronisation. 

répertoire  Le répertoire dans lequel les données synchronisées seront écrites. Le compte 
utilisateur employé doit avoir des droits d’écriture sur ce répertoire. 

Il faudra après configuration relancer le service rsync par les moyens habituels. 

/etc/init.d/rsync restart

Synchronisation des données depuis un client

La synchronisation se fera à la demande ou depuis une tâche planifiée avec la commande rsync. 

Syntaxe de la commande rsync pour une synchronisation ponctuelle 

rsync -av --delete /répertoire/ ip_serveur::instance

Commande rsync : options et paramètres 

­a  Mode archive : réplique les données à l’identique, en préservant notamment les 


permissions et les propriétaires. 

­v  Facultatif : affiche le détail de chaque opération. Permet de visualiser la progression 


de la synchronisation. 

­­delete  Copie miroir : les données effacées sur le client le sont aussi sur le serveur. 

répertoire  Le répertoire des données locales à dupliquer. 

instance  Le nom de l’instance paramétrée dans /etc/rsyncd.conf sur le serveur. 

Synchronisation sécurisée de données avec rsync

Si la synchronisation de données doit se faire en environnement hostile, il est possible de s’en remettre à SSH pour 
le  transport  des  données.  Dans  ce  mode  de  fonctionnement,  le  démon  rsync  ne  s’exécute  pas  sur  le  serveur,  et 
l’exécutable est lancé à la volée par SSH pour toute connexion entrante. 

Synchronisation sécurisée avec rsync 

rsync -av --delete -e ssh répertoire


utilisateur@adresse_serveur:/chemin_cible

rsync avec ssh : options et paramètres 

­a  Mode archive : réplique les données à l’identique, en préservant notamment les 


permissions et les propriétaires. 

­v  Facultatif : affiche le détail de chaque opération. Permet de visualiser la progression 


de la synchronisation. 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


­­delete  Copie miroir : les données effacées sur le client le sont aussi sur le serveur. 

répertoire  Le répertoire des données locales à dupliquer. 

utilisateur  Le compte utilisateur existant sur la machine cible qui sera utilisé pour la session 
ssh. 

adresse_serveur  Adresse IP du serveur cible. 

chemin_cible  Répertoire cible pour la synchronisation de données sur la machine cible. 

Exemple de synchronisation sécurisée 

La commande rsync permet de créer un miroir entre disques sur systèmes différents à peu de frais. 

[root@beta data]# rsync -av --delete -e ssh /root/data


root@192.168.200.106:/root/svg
root@192.168.200.106’s password:
building file list ... done
created directory /root/svg
data/
data/deux/
data/deux/fichier2
data/trois/
data/un/
data/un/fichier1

sent 50047 bytes received 88 bytes 14324.29 bytes/sec


total size is 49785 speedup is 0.99
[root@beta data]#
[root@beta data]# rm -rf un
[root@beta data]# rsync -av --delete -e ssh /root/data
root@192.168.200.106:/root/svg
root@192.168.200.106’s password:
building file list ... done
deleting data/un/fichier1
deleting data/un/
data/

sent 109 bytes received 26 bytes 38.57 bytes/sec


total size is 35964 speedup is 266.40
[root@beta data]#

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


RAID 
Le RAID pour Redundant Array of Independent Disks (Ensemble redondant de disques indépendants) est une technologie 
d’exploitation des disques durs qui permet d’utiliser un espace de stockage réparti sur plusieurs disques physiques avec 
pour objectif d’augmenter les performances, la tolérance aux pannes, ou les deux. Si cette technologie est normalement 
gérée par le matériel dans des baies de disques ou des SAN, il est néanmoins possible de s’en remettre à Linux pour sa 
réalisation. Dans cette hypothèse, le noyau Linux aura à sa disposition plusieurs disques durs, et organisera les blocs 
de données sur ces disques pour présenter des partitions logiques qui recevront les filesystems. 

Nous  ne  parlons  ici  que  des  RAID  gérés  logiciellement  par  le  noyau  Linux.  Dans  le  cas  d’un  serveur  en 
production,  il  est  probable  que  le  RAID  sera  géré  par  un  contrôleur  matériel.  Dans  cette  hypothèse,  le 
contrôleur présentera au système des unités logiques (LUN) qui seront vues comme des partitions ordinaires, et le 
système se moquera bien alors de savoir si le contrôleur fait du RAID ou non. 

1. Les principaux niveaux de RAID 

a. Le RAID 0 

Le RAID 0 a pour objectif exclusif la rapidité d’accès aux données, et ne gère pas la tolérance de panne. Il est très 
important  de  savoir  qu’en  RAID  0,  la  défaillance  du  moindre  des  éléments  entraine  la  perte  totale  des  volumes 
exploités. Le principe du RAID 0 est de répartir les informations à écrire en blocs, et d’écrire les blocs en même temps 
sur les disques physiques qui composent le volume RAID. 
L’espace exploitable sur un volume en RAID 0 est égal à la somme des espaces disques utilisés. 

b. Le RAID 1 

Le  RAID  1,  contrairement  au  RAID  0  ne  cherche  absolument  pas  à  améliorer  les  performances,  mais  uniquement  à 
sécuriser les données. Dans le RAID 1, chaque bloc de données est dupliqué et écrit en autant d’exemplaires qu’il y a 
de disques dans le volume RAID. Ainsi, si un disque vient à défaillir, les données restent disponibles. 

L’espace exploitable sur un volume en RAID 1 est égal à l’espace disponible sur un disque. 

c. Le RAID 5 

Le RAID 5 cumule les avantages du RAID 0 et du RAID 1. On doit disposer d’au moins trois disques pour le configurer. 
Lors d’une opération d’écriture sur un volume RAID 5, des blocs de données sont écrits sur chacun des disques qui 
composent le volume, à l’exception d’un bloc de parité sur un disque qui se déduit à partir des blocs de données par 
un "ou exclusif". En cas de défaillance d’un disque, les blocs de données manquants seront recalculés en réalisant un 
"ou exclusif" de tous les blocs restants, données et parité. 
L’espace exploitable sur un volume en RAID 5 est égal à la somme des espaces disques utilisés moins un et moins un 
éventuel disque de secours (spare). 

2. Configuration du RAID 

a. Création du volume RAID 

Les  volumes  RAID  se  configurent  assez  facilement  avec  la  commande  mdadm.  Il  faudra  disposer  de  plusieurs 
espaces de stockages, disques durs entiers ou partitions, déterminer le niveau de RAID souhaité, et choisir le nom 
ou numéro du volume à créer. 

La  commande  mdadm  trouve  sa  configuration,  notamment  l’ordre  de  scanner  toutes  les  partitions  trouvées 
dans  /proc/partitions  dans  son  fichier  de  configuration  /etc/mdadm/mdadm.conf.  Il  n’est  généralement  pas 
nécessaire de modifier la configuration par défaut. 

Syntaxe de la commande mdadm pour la création ou la désactivation de volume RAID 

mdadm action volume -l niveau -n nombre_disques stockages

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Création de volume avec mdadm : options et paramètres 

action  ­C : crée un volume RAID. 

­S : désactive un volume et libère les ressources. 

volume  Le fichier de bloc à créer pour représenter le nouveau volume. Souvent /dev/mdx, 
mais peut être un nom quelconque. 

niveau  Valeur du niveau de RAID, généralement 0, 1 ou 5. 

nombre_disques  Nombre d’espaces de stockage à employer, suivi des fichiers de blocs représentant 
ces espaces. 

stockages  Les périphériques de stockages séparés par des espaces et désignés par leur fichier 
spécial bloc. 

Exemple de création de volume raid1 sur Debian 

On exploite deux disques durs /dev/sdb et /dev/sdc pour créer un volume RAID1 

root@serveur# mdadm -C /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdc


mdadm: array /dev/md0 started
root@serveur#

b. Vérification d’un volume RAID 

C’est encore la commande mdadm qui va nous permettre de connaître la nature d’un volume RAID inconnu. 

Vérification de volume RAID 

mdadm -D volume

Où volume est le fichier spécial de périphérique en mode bloc qui représente le volume RAID. 

Exemple de vérification d’un volume RAID 

Il  est  important  de  connaître  et  d’utiliser  les  commandes  de  diagnostic  pour  une  bonne  gestion  et  documentation  du 
stockage. 

# mdadm -D /dev/md0
A:~# mdadm -D /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Wed Jan 13 22:52:26 2010
Raid Level : raid5
Array Size : 4194176 (4.00 GiB 4.29 GB)
Used Dev Size : 2097088 (2048.28 MiB 2147.42 MB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Wed Jan 13 22:54:49 2010


State : clean, degraded, recovering
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1

Layout : left-symmetric
Chunk Size : 64K

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Rebuild Status : 90% complete

UUID : a20a3883:3badc821:e24ccd6d:eee2883d (local to host A)


Events : 0.4

Number Major Minor RaidDevice State


0 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
3 8 32 2 spare rebuilding /dev/sdc

Le fichier /proc/mdstat donne aussi des informations sur l’état des disques RAID sur un système Linux. 

Exemple de fichier /proc/mdstat 

Le fichier mdstat fournit un affichage synthétique des volumes RAID et des disques le composant. 

Personalities : [raid0]
md0 : active raid0 sdb[1] sda[0]
4194176 blocks 64k chunks

unused devices: <none>

c. Exploitation des volumes RAID 

Une fois les volumes créés par la commande mdadm, ils sont désignés par leur fichier de bloc spécial et supporteront 
la création d’un filesystem ainsi que le montage, qu’il soit manuel ou appelé depuis le fichier /etc/fstab. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Logical Volume Manager 
Le  système  de  partitionnement  traditionnel  des  disques  impose  certaines  limitations  comme  un  nombre  de  partitions 
limité à quatre, et le caractère obligatoirement contigu de l’espace partitionné. Si de nombreux utilitaires permettent de 
redimensionner les partitions à la volée , il reste impossible d’étendre une partition avec de l’espace non contigu, par 
exemple  sur  un  autre  disque  dur.  Pour  pallier  ces  limitations,  la  plupart  des  éditeurs  de  systèmes  d’exploitation  ont 
proposé des gestions d’espaces disque plus ou moins propriétaires, comme les disques dynamiques pour Windows ou 
les  volumes  NSS  chez  Novell.  Pour  les  systèmes  Linux,  la  solution  s’appelle  Logical  Volume  Manager  (gestionnaire  de 
volumes logiques). Les volumes logiques permettent de créer un nombre illimité de volumes, de les étendre à volonté, y 
compris à partir d’espace se trouvant sur des disques et des contrôleurs différents. 

Il  est  d’usage  de  conserver  les  termes  anglais  lorsqu’on  parle  d’éléments  LVM,  cela  aidera  notamment  à  se  souvenir 
facilement des commandes d’exploitation. Certains éléments, comme les Logical Volumes qui supportent une traduction 
facile et naturelle infirment néanmoins cet usage. 

1. Architecture des volumes logiques 

Une architecture LVM se compose de PV : Physical Volumes, VG : Volume Groups et de LV : Logical Volumes. 

Un  volume  logique  est  l’équivalent  fonctionnel  d’une  partition  traditionnelle,  il  est  identifié  par  un  fichier  spécial  en 
mode bloc, et supportera généralement un filesystem en vue d’un montage. 
Les  Logical  Volumes  sont  composés  de  blocs  de  données,  puisés  dans  une  couche  d’abstraction  appelée  Volume 
Group, elle­même alimentée par des espaces de stockage bruts (disques ou partitions) appelés Physical Volumes. 

Dans une architecture LVM basée sur plusieurs volumes physiques, la défaillance du moindre d’entre eux rend 
tous  les  volumes  logiques  qui  en  dépendent  inopérants.  Il  conviendra  donc  de  ne  créer  des  volumes 
physiques que depuis des volumes à tolérance de panne comme des éléments soumis à RAID, qu’il soit logiciel ou 
matériel. 

2. Commandes LVM 

Les commandes de gestion des LVM sont construites selon un préfixe lié à l’objet qu’on veut gérer, et un suffixe selon 
l’action à entreprendre. 

Construction des commandes LVM 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


préfixe  suffixe 

pv  create  Création d’un élément LVM. 

vg  extend  Extension d’un VG ou d’un LV. 

lv  reduce  Réduction d’un VG ou d’un LV. 

display  Affichage des informations d’un élément LVM. 

a. Création des éléments 

On commencera par créer les PV (physical volumes) à partir d’espaces de stockage. Il peut s’agir de disques entiers, 
ou de partitions traditionnelles, dont le type aura été modifié à 8e. Il est à noter que la construction de PV à partir de 
partitions traditionnelles est généralement réservée à des besoins de test, et qu’un usage en production pour des 
volumes de données s’appuie presque toujours sur des disques entiers. 

Création des volumes physiques

Les volumes physiques sont créés avec la commande pvcreate. 

Syntaxe de la commande pvcreate 

pvcreate device

Où device représente le fichier spécial blocs qui héberge le volume physique, disque ou partition. 

Création du groupe de volumes

Les groupes de volumes sont créés avec la commande vgcreate. 

Syntaxe de la commande pvcreate 

vgcreate nom_vg pv_device

vgcreate : options et paramètres 

nom_vg  Nom du groupe de volume. Valeur au choix. 

pv_device  Fichier spécial blocs qui héberge le ou les pv qui alimentent le vg. 

Le groupe de volume ainsi créé apparaîtra sous forme de répertoire du nom du groupe de volume créé, directement 
sous /dev. Attention, ce répertoire n’apparaîtra réellement que lorsqu’un premier volume logique sera créé à partir 
du groupe de volume. 

Création du volume logique

Les  volumes  logiques  sont  créés  avec  la  commande  lvcreate.  On  peut  créer  autant  de  volumes  logiques  que  l’on 
veut tant qu’il reste de l’espace disponible dans le Volume Group. 

Syntaxe de la commande lvcreate 

lvcreate -L taille -n nom_lv nom_vg

lvcreate : options et paramètres 

taille  Taille du volume logique, sous forme de valeur numérique directement suivie de 
l’unité. 

nom_lv  Nom du volume logique. Valeur au choix. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


nom_vg  Nom du groupe de volume à partir duquel le volume logique sera créé. 

Le volume logique ainsi créé apparaîtra sous forme de fichier spécial en mode blocs dans le répertoire portant le nom 
de son groupe de volumes sous /dev. C’est ce fichier spécial qui sera employé lors des opérations de montage. 

b. Diagnostics LVM 

Les architectures LVM sont souvent déroutantes, du fait du grand nombre d’opérations nécessaires pour arriver à la 
création  d’un  volume  logique.  De  plus,  si  on  se  figure  assez  bien  ce  que  peut  être  un  volume  physique,  la  nature 
abstraite du groupe de volume le rend difficile à appréhender. Pour ces raisons, il est essentiel de se faire une idée 
précise de l’ensemble des éléments utilisés dans une architecture LVM et de les documenter consciencieusement. Par 
chance,  les  outils  de  diagnostics  LVM  sont  précis,  et  ils  permettent  à  chaque  étape  de  vérifier  le  bon  déroulement 
des opérations. 

Affichage des informations de volume physique

Les  informations  détaillées  de  tous  les  volumes  physiques  présents  sur  un  système  seront  affichées  par  la 
commande pvdisplay. Si vous préférez la concision, vous pouvez essayer pvs. 

Exemple d’utilisation de la commande pvdisplay 

Il est important d’identifier les volumes physiques avec la commande pvdisplay. L’utilitaire fdisk indiquerait un disque sans 
table des partitions et laisserait à penser qu’on est en présence d’un disque vierge. 

A:~# pvdisplay
"/dev/sdb" is a new physical volume of "2,00 GB"
--- NEW Physical volume ---
PV Name /dev/sdb
VG Name
PV Size 2,00 GB
Allocatable NO
PE Size (KByte) 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID UHSnwO-EKMh-QbDn-1qj0-f7Az-KKkx-3XcyZz
A:~#

Exemple d’utilisation de la commande pvs 

L’essentiel en deux lignes. 

A:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sdb lvm2 -- 2,00G 2,00G
A:~#

Affichage des informations de groupes de volumes

Les informations détaillées de tous les groupes de volumes présents sur un système sont affichées par la commande 
vgdisplay. Si vous préférez la concision, vous pouvez essayer vgs. 

Exemple d’utilisation de la commande vgdisplay 

L’affichage des détails des groupes de volume permet de connaître la taille totale disponible des groupes. 

A:~# vgdisplay
--- Volume group ---
VG Name vg1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 2,00 GB
PE Size 4,00 MB
Total PE 511
Alloc PE / Size 0 / 0
Free PE / Size 511 / 2,00 GB
VG UUID D6QwUK-Lltf-uGg5-vH8r-ZmaK-dU0L-Lyyu3T
A:~#

Exemple d’utilisation de la commande vgs 

A:~# vgs
VG #PV #LV #SN Attr VSize VFree
vg1 1 0 0 wz--n- 2,00G 2,00G
A:~#

Affichage des informations de volumes logiques

Les informations détaillées de tous les volumes logiques présents sur un système seront affichées par la commande 
lvdisplay. Pour la concision, essayez lvs. 

Exemple d’utilisation de la commande lvdisplay 

A:~# lvdisplay
--- Logical volume ---
LV Name /dev/vg1/data1
VG Name vg1
LV UUID Ll7105-aLpz-axKC-Hcuq-pPSq-QZaK-8h5PLC
LV Write Access read/write
LV Status available
# open 0
LV Size 400,00 MB
Current LE 100
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
A:~#

Exemple d’utilisation de la commande lvs 

A:~# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
data1 vg1 -wi-a- 400,00M
A:~#

c. Extension de volume logique 

Un des principaux avantages des volumes logiques est l’extension facile des volumes logiques. Nous avons vu qu’un 
volume  logique  est  constitué  de  Logical  Extents  fournis  par  un  objet  Volume  Group.  Si  des  Logical  Extents  sont 
encore  disponibles  dans  le  Volume  Group,  il  est  alors  facile  d’étendre  le  Logical  Volume  à  partir  de  ces  Logical 
Extents. En clair, s’il reste de l’espace non affecté dans le groupe de volume, on peut l’ajouter à un volume logique 
déjà créé. Dans le cas contraire, il faudra d’abord étendre le Volume Group en y ajoutant un ou plusieurs Physical 
Volumes. 

Extension d’un Volume Group

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


L’extension  d’un  Volume  Group  se  fait  à  partir  de  Physical  Volume(s)  avec  la  commande  pvextend.  Les  Physical 
Volumes sont alors créés comme précédemment avec la commande pvcreate. 

Syntaxe de la commande vgextend 

vgextend nom_vg pv_device

vgcreate : options et paramètres 

nom_vg  Nom du groupe de volume à étendre. 

pv_device  Fichier spécial blocs qui héberge le ou les PV qui alimentent le VG. 

Extension d’un Logical Volume

L’extension d’un Logical Volume se fait avec la commande lvextend. 

Syntaxe de la commande lvextend 

lvextend -L taille lv

lvcreate : options et paramètres 

taille  Taille du volume logique étendu, sous forme de valeur numérique directement suivie de l’unité. 
Si la taille est précédée d’un signe +, cette taille s’ajoute à celle du volume existant. 

lv  Volume logique à étendre, désigné par son fichier spécial en mode blocs. 

Un Logical Volume n’est qu’un espace de stockage, indépendamment du filesystem qui y est apposé. En cas 
d’extension du Logical Volume, il faudra prévoir d’étendre aussi le filesytem pour pouvoir exploiter l’espace 
supplémentaire. 

d. Réduction de LV 

La réduction des éléments LVM est possible, même si ce genre de manœ uvre est toujours délicate et doit être bien 
maîtrisée. 

Réduction d’un Logical Volume

La réduction d’un volume logique se fait avec la commande lvreduce. Les Logical Extent sont retirés dès l’exécution 
de la commande et toutes les données s’y trouvant sont perdues. Toutes les précautions devront donc être prises 
pour éviter des pertes de données. 

Réduction d’un LV 

lvreduce -L taille lv

lvreduce : options et paramètres 

taille  Taille à retirer du volume logique étendu, sous forme de valeur numérique directement suivie de 
l’unité. 

lv  Volume logique à réduire, désigné par son fichier spécial en mode blocs. 

Réduction d’un Volume Group

Un Volume Group peut être réduit par la commande vgreduce. 

Réduction d’un VG 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


vgreduce vg pv

vgreduce : options et paramètres 

vg  Le groupe de volume à réduire. 

pv  Le (ou les) volume(s) physique(s) à retirer du groupe de volumes. 

3. Exploitation des volumes logiques 

a. Données sur les volumes logiques 

Une fois les Logical Volumes créés, il faut pour les exploiter y apposer un filesystem. Il faut bien comprendre que d’un 
point  de  vue  fonctionnel,  les  volumes  logiques  sont  le  strict  équivalent  des  partitions  traditionnelles  directement 
créées  avec  fdisk,  et  de  type  Linux.  La  démarche  sera  donc  strictement  identique  à  celle  employée  en 
partitionnement traditionnel, si ce n’est que le fichier spécial en mode bloc sera celui du Logical Volume. 

Exemple de création d’un file system ext3 sur un LV 

Les  volumes  logiques  supportent  la  création  de  filesystem  comme  les  partitions  traditionnelles.  Notez  le  fichier  de  bloc 
spécial sous lequel le volume logique est reconnu. 

A:~# mke2fs -j /dev/vg1/lv99


mke2fs 1.41.3 (12-Oct-2008)
É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)
25688 i-noeuds, 102400 blocs
5120 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=67371008
13 groupes de blocs
8192 blocs par groupe, 8192 fragments par groupe
1976 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
8193, 24577, 40961, 57345, 73729

Écriture des tables d’i-noeuds : complété


Création du journal (4096 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 31 montages ou


après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
A:~#

De même, il sera nécessaire pour exploiter ce filesystem de monter le volume logique, que ce soit de façon manuelle 
ou par le biais du fichier /etc/fstab. 

Exemple de montage de volume logique 

A:/mnt# mount /dev/vg1/lv99 /mnt/data99


A:/mnt#

b. Exploitation du snapshot LVM pour les sauvegardes 

La nature souple et évolutive des LVM les rend parfaitement aptes à stocker de grands volumes de données. Or, un 
problème récurent se pose lors de la sauvegarde de ces gros volumes de données. En effet, le temps nécessaire à la 
sauvegarde interdit souvent de réaliser les opérations hors ligne. La solution est apportée par la fonctionnalité de 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


snapshot (instantané) disponible sur les architectures LVM. 
On réalise le snapshot du volume logique à sauvegarder alors qu’il est monté et en exploitation, et on effectue la 
sauvegarde sur le snapshot qui est une copie conforme du volume logique au moment précis où il a été réalisé. Il 
faut bien comprendre qu’un snapshot n’est pas un outil de sauvegarde en tant que tel, mais un moyen au service 
d’une stratégie de sauvegarde. 

Réalisation du snapshot

Le snapshot se fait avec la commande lvcreate. Un snapshot est donc un volume logique à part entière, et il pourra 
être monté et exploité en cas de besoin. 
Il  faudra  déterminer  la  taille  du  snapshot  lors  de  sa  création.  Le  volume  logique  de  snapshot  ne  stocke 
physiquement  que  les  différences  entre  le  volume  en  production  (celui  qui  a  été  snapshoté)  et  le  volume  de 
snapshot. S’il  n’y a pas d’écritures réalisées sur le volume en production, la consommation en espace de stockage 
pour  le  snapshot  sera  quasi  nulle.  Si  toutes  les  données  sont  modifiées  sur  le  volume  en  production,  le  snapshot 
exploitera physiquement un espace disque de l’ordre de celui consommé par le volume de données au moment du 
snapshot. L’espace exploité par le snapshot pourra être surveillé avec la commande lvdisplay. 

Syntaxe de la commande lvcreate pour la création de snapshot 

lvcreate -L taille -s -n nom_snapshot lv_origine

lvcreate pour snapshot : options et paramètres 

­L taille  Taille du snapshot à créer. 

­s  Option qui indique qu’on crée un snapshot de volume logique, et non un volume 
logique ordinaire. 

­n nom_snapshot  Le nom du volume de snapshot. Il est recommandé d’avoir une convention de 
dénomination explicite. 

lv_origine  Le nom du volume logique en production à partir duquel le snapshot sera réalisé. 

Exemple de création de snapshot 

Le snapshot est un volume logique presque comme les autres. 

A:/mnt# lvcreate -L 1G -s -n clicclac /dev/vg1/data1


Logical volume "clicclac" created
A:/mnt#

Exemple de visualisation de l’espace disque réellement occupé par un snapshot 

Dans l’exemple ci­dessous, les données n’ont pas été modifiées sur le volume d’origine entre le lvcreate ­s et le lvdisplay. 
On observe donc la valeur "Allocated to snapshot" à 0%. 

A:/mnt# lvdisplay /dev/vg1/clicclac


--- Logical volume ---
LV Name /dev/vg1/clicclac
VG Name vg1
LV UUID xyakf0-2zMf-B3qG-S9gT-KTqw-ZJI3-W06GWi
LV Write Access read/write
LV snapshot status active destination for /dev/vg1/data1
LV Status available
# open 0
LV Size 1,49 GB
Current LE 381
COW-table size 1,00 GB
COW-table LE 256
Allocated to snapshot 0,00%
Snapshot chunk size 4,00 KB
Segments 1
Allocation inherit

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


Read ahead sectors auto
- currently set to 256
Block device 253:1
A:/mnt#

Dans ce deuxième exemple, des données ont été ajoutées sur le volume d’origine, obligeant le système à conserver deux 
versions  :  les  données  snapshotées,  disponibles  pour  la  sauvegarde,  et  les  données  nouvelles  écrites  sur  le  disque  et 
affectées au volume en production. La valeur "Allocated to snapshot" est désormais à 1,45 %. 

A:/mnt/data1# lvdisplay /dev/vg1/clicclac


--- Logical volume ---
LV Name /dev/vg1/clicclac
VG Name vg1
LV UUID xyakf0-2zMf-B3qG-S9gT-KTqw-ZJI3-W06GWi
LV Write Access read/write
LV snapshot status active destination for /dev/vg1/data1
LV Status available
# open 0
LV Size 1,49 GB
Current LE 381
COW-table size 1,00 GB
COW-table LE 256
Allocated to snapshot 1,45%
Snapshot chunk size 4,00 KB
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
A:/mnt/data1#

Sauvegarde des données snapshotées

Du point de vue des LVM, il n’y a plus rien à faire. Les données sont disponibles, figées dans le temps au moment où 
le snapshot a été réalisé, et elles sont sauvegardables par n’importe quel moyen usuel. 

Exemple de sauvegarde des données snapshotées 

Dans cet exemple, on monte le volume logique de snapshot dans un répertoire /mnt/clicclac, et on réalise une archive tar 
compressée des données que l’en stocke sur un périphérique USB. 

A:/mnt# mkdir clicclac


A:/mnt# mount /dev/vg1/clicclac clicclac
A:/mnt# ls clicclac
bigfile.tar etc growingfile lost+found midfile.tar usr
A:/mnt# tar czf /media/usb/svg_snap.tgz /mnt/clicclac
tar: Suppression de « / » au début des noms des membres
A:/mnt#

- 8- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Le processus init et les niveaux d’exécution 

1. Les niveaux d’exécution 

Le fonctionnement d’un système Linux est régi par des niveaux d’exécution. Même si ce concept apparaît davantage 
aujourd’hui  comme  un  héritage  du  passé  que  comme  un  réel  outil  d’administration  d’un  poste  de  travail  ou  d’un 
serveur Linux, sa connaissance est indispensable à une bonne gestion du système. 

Tout d’abord, il faut admettre qu’un système Linux est toujours dans un niveau d’exécution quelque soit son activité, 
qu’il s’agisse d’un serveur apache en train de répondre à une requête, ou d’un serveur neuf encore dans son carton. 
La gestion des niveaux d’exécution consistera à déterminer quel doit être le comportement du système quand il entre 
dans un niveau donné. 

a. Qu’est­ce qu’un niveau d’exécution ? 

Pour faire simple, un niveau d’exécution est un niveau fonctionnel dans lequel on aura déterminé la liste des services 
à  arrêter  ou  à  démarrer.  Quand  un  système  entre  dans  un  niveau  d’exécution,  il  regarde  s’il  doit  arrêter  et/ou 
démarrer des services. 

b. Les niveaux d’exécution possibles 

Le niveau 0

Le plus simple : le système est arrêté. Attention, cela ne signifie pas que ce niveau ne doit pas être configuré, il faut 
tout  de  même  gérer  ce  qui  se  passe  quand  le  système  entre  en  niveau  0,  c’est  à  dire  quels  sont  les  services  à 
arrêter quand on éteint physiquement une machine. 

Le niveau 1 ou single

Un niveau un peu particulier : il est réservé aux opérations de maintenance et ne permet qu’une seule connexion, 
celle du compte root. De plus, la plupart des services sont arrêtés dans ce niveau, ce qui signifie que le système a 
une activité minimum. C’est parfait pour l’administrateur qui souhaite effectuer des opérations de maintenance sans 
interférer avec la production. 

Le niveau 2

Sur la plupart des systèmes, ce niveau n’est pas utilisé. Il est laissé à la disposition de l’administrateur qui pourra 
établir à partir de ce niveau un mode de fonctionnement particulier avec seulement certains services démarrés. 
Sur  les  systèmes  Debian  et  dérivés  (Ubuntu  par  exemple),  ce  niveau  est  en  revanche  le  niveau  fonctionnel  par 
défaut. 

Le niveau 3

Sur  la  plupart  des  systèmes,  le  niveau  3  est  fonctionnel,  c’est­à­dire  que  tous  les  services  sont  démarrés,  mais 
l’interface graphique n’est pas disponible. 

Le niveau 4

Sur la plupart des systèmes, ce niveau n’est pas utilisé. Il est laissé à la disposition de l’administrateur qui pourra 
établir à partir de ce niveau un mode de fonctionnement particulier avec seulement certains services démarrés. 

Le niveau 5

Sur  la  plupart  des  systèmes,  le  niveau  5  est  fonctionnel,  c’est­à­dire  que  tous  les  services  sont  démarrés,  et 
l’interface graphique est disponible. 

Sur les systèmes Debian et dérivés (Ubuntu par exemple), ce niveau n’est pas utilisé en général. 

Le niveau 6

Temporaire  par  définition,  le  niveau  6  est  celui  d’un  système  en  train  de  redémarrer.  La  configuration  du  niveau  6 
consistera donc à déterminer quels services doivent être arrêtés au redémarrage du système. Après le redémarrage, 
un nouveau niveau d’exécution s’appliquera (en général le niveau par défaut) et les services associés à ce niveau 
seront démarrés. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


c. Qui décide de ce qu’on met dans les différents niveaux ? 

Dans l’immense majorité des cas, c’est la définition initiale des niveaux d’exécution qui est exploitée. C’est­à­dire que 
le  gestionnaire  de  la  distribution  (Ubuntu,  Mandriva,  Red  Hat,  etc.)  choisit  ce  qui  doit  se  passer  dans  chacun  des 
niveaux d’exécution donné, et l’administrateur du système fait avec. 

Toutefois,  il  peut  arriver  que  l’administrateur  du  système  préfère  gérer  lui  même  la  configuration  de  ses  niveaux 
d’exécution. Il peut alors choisir à quel niveau fonctionnel correspond chacun des niveaux d’exécution et quels sont 
les services associés. À chaque niveau d’exécution correspond alors un ensemble de services. 

2. Configuration du processus init 

Nous avons parlé jusqu’à  présent  des  niveaux  d’exécution  comme  d’une  liste  de  services  à  arrêter  ou  démarrer.  La 
question  est maintenant  de  savoir  comment  le  système  va  prendre  connaissance  de  son  niveau  d’exécution  et  des 
services qui y sont référencés. 

a. Le premier processus démarré sur le système 

Si on regarde quels sont les processus s’exécutant sur le système, on trouve en première position le processus init. 
Il porte un PPID inhabituel (0), et il est le père de nombreux autres processus. 

Les processus 

De nombreux processus ont le numéro 1 comme PPID. 

[root@beta ~]# ps -ef | head


UID PID PPID C STIME TTY TIME CMD
root 1 0 0 09:07 ? 00:00:12 init [5]
root 2 1 0 09:07 ? 00:00:00 [migration/0]
root 3 1 0 09:07 ? 00:00:00 [ksoftirqd/0]
root 4 1 0 09:07 ? 00:00:00 [watchdog/0]
root 5 1 0 09:07 ? 00:00:09 [events/0]
root 6 1 0 09:07 ? 00:00:00 [khelper]
root 7 1 0 09:07 ? 00:00:00 [kthread]
root 10 7 0 09:07 ? 00:00:04 [kblockd/0]
root 11 7 0 09:07 ? 00:00:00 [kacpid]
[root@beta ~]#

Ce processus est le premier lancé au chargement du noyau. Il a évidemment un rôle privilégié, et son comportement 
est régi par un fichier de configuration : /etc/inittab. 

b. Le fichier inittab 

Selon  les  distributions,  le  fichier  /etc/inittab  revêt  des  contenus  très  différents,  mais  sa  structure  est  toujours  la 
même. 

Structure du fichier /etc/inittab 

identifiant:niveau:mode_action:commande

Fichier /etc/inittab : structure d’une ligne de définition 

identifiant  Chaîne alphanumérique d’un ou deux caractères. Identifie la ligne. Pas d’autres 
contraintes que d’éviter d’avoir deux lignes avec le même identifiant. 

niveau  Le ou les niveaux d’exécution (en chiffres) pour lesquels la ligne est pertinente. 

mode_action  À choisir parmi quelques mots­clés, définit la façon dont la commande du quatrième 
champ sera exécutée. 

commande  La commande à exécuter au(x) niveau(x) défini(s) dans le deuxième champ selon le 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


mode d’action du troisième champ. 

Modes d’actions courants 

● initdefault : un peu particulier, initdefault ne régit pas la façon dont la commande du quatrième champ sera 
exécutée. D’ailleurs, quand le mode d’action est initdefault, le quatrième champ est vide. initdefault ne sert 
en fait qu’à définir le niveau d’exécution du système par défaut. 

● sysinit  :  sert  à  exécuter  des  scripts  à  l’initialisation  du  système,  indépendamment  du  niveau  d’exécution. 
Pour cette raison, sysinit n’admet pas de valeur pour le deuxième champ. 

● wait : exécute la commande du quatrième champ (souvent un script), et attend la fin de cette exécution pour 
passer aux lignes suivantes du fichier inittab. 

● respawn : exécute la commande du quatrième champ, et laisse tourner le processus à l’arrière­plan. Passe 
ensuite  aux  lignes  suivantes  du  fichier  inittab.  Si  le  processus  appelé  par  la  commande  s’arrête,  init  le 
relancera systématiquement. 

Fichier inittab d’une distribution RedHat 

Les commentaires ont été supprimés pour des raisons de lisibilité. 

id:5:initdefault:
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
x:5:respawn:/etc/X11/prefdm -nodaemon

c. Rappels sur le lancement des services 

Sur un système Linux, les services sont lancés par des scripts normalisés qui répondent à au moins deux conditions : 

● Ils se trouvent tous dans le répertoire /etc/init.d (ou sont disponibles à cet emplacement sous forme de lien 
symbolique). 

● Ils admettent tous les paramètres start et stop pour le lancement et l’arrêt du service. 

Syntaxe universelle de gestion de service 

/etc/init.d/nom action

Gestion de services avec la commande service 

service nom action

Gestion de service : paramètres 

nom  Le nom du service à gérer. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


action  start ou stop pour démarrer ou arrêter le service. status est aussi une option couramment 
supportée qui indique l’état du service. 

La commande service, quand elle est disponible, peut être considérée comme préférable car elle lance le service en 
s’affranchissant  autant  que  possible  de  l’environnement  ambiant  (pwd  et  variables).  Le  service  est  ainsi  démarré 
dans un environnement plus neutre. 

Format standard d’un script de gestion de service 

#!/bin/bash
case $1 in
start)
# commande de lancement du service
;;
stop)
# commande d’arrêt du service
;;
esac

d. Liens entre les niveaux d’exécution et les services 

Si on regarde le fichier /etc/inittab, on trouve une section contenant 7 lignes commandant pour chacun des niveaux 
d’exécution un script /etc/init.d/rc en mode wait. Nous ne détaillerons pas le fonctionnement de ce script ici, mais 
retenons  simplement  qu’il  commande  l’exécution de chaque fichier du répertoire  /etc/rcn.d (n étant le numéro du 
niveau  d’exécution) avec le paramètre  start  si  la  première  lettre  du  nom  du  fichier  est  un S,  et  avec  le  paramètre 
stop si la première lettre du nom du fichier est un K. Chacun des fichiers de /etc/rcn.d est un lien symbolique vers 
un  script  de  lancement  de  service  de  /etc/init.d  et  cette  construction  permet  de  dire  quels  services  doivent  être 
démarrés ou arrêtés pour chacun des niveaux d’exécution. 

Selon les distributions, il se peut que les scripts rc et les répertoires rcn.d soient placés à des emplacements 
différents.  La  cohérence  est  assurée  par  la  bonne  gestion  des  chemins  dans  les  scripts  systèmes  et  la 
création de liens symboliques quand c’est nécessaire. 

Ces liens peuvent être créés manuellement avec la commande ln. 

Création de liens de gestion de services avec la commande ln 

Ces liens doivent être créés pour chacun des niveaux d’exécutions possibles. 

cd /etc/rcx.d
ln -s ../init.d/service Cnnservice

Lien de lancement de services : paramètres 

x  Le niveau d’exécution pour lequel on veut gérer le démarrage ou l’arrêt du service. 

C  Commutateur de démarrage (S) ou d’arrêt (K). 

nn  Numéro d’ordre à deux chiffres. Le script sera géré plus ou moins tôt par rapport aux autres du 
même service. 

service  Nom du service à gérer. 

e. Gestion des niveaux d’exécution 

La commande runlevel indique le niveau d’exécution en cours. 

Affichage du niveau d’exécution 

runlevel

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


La commande telinit permet de changer à chaud le niveau d’exécution d’un système. 

Changement de niveau d’exécution 

telinit niveau

Où niveau représente le niveau d’exécution dans lequel on souhaite placer le système. 

Gestion du niveau d’exécution 

Le changement à chaud de niveau d’exécution ne devrait être réalisé que sur un système dont on connaît la configuration. 

alpha:~# runlevel
N 2
alpha:~# telinit 3
alpha:~#
alpha:~# runlevel
N 3
alpha:~#

Ponctuellement, le niveau d’exécution à charger peut aussi être fourni au noyau en tant que paramètre lors 
de  son  chargement.  Le  choix  du  niveau  d’exécution  peut  donc  aussi  se  faire  depuis  le  gestionnaire  de 
démarrage en plaçant simplement le niveau souhaité sur la ligne de chargement du noyau. 

f. Commandes de gestions des liens de services 

Les commandes update­rc.d et chkconfig permettent de s’affranchir de la gestion contraignante des liens d’appels 
de services selon les niveaux d’exécution. Les deux commandes ne sont pas disponibles sur tous les systèmes, et il 
se  peut  même  que  la  création  manuelle  de  liens  soit  la  seule  solution  fonctionnelle.  Dans  tous  les  cas,  il  est 
pédagogiquement  intéressant  de  vérifier  l’action  de  ces  commandes  sur  les  liens  en  place  dans  les 
répertoires /etc/rcn.d. 

Création des liens de gestion de services 

update-rc.d service defaults

chkconfig --add service

Où service représente le nom du service présent dans le répertoire /etc/init.d. Le paramètre defaults implique que 
le service sera démarré dans les niveaux fonctionnels par défaut, et arrêté dans les niveaux non fonctionnels (0 pour 
système arrêté, 1 pour le mode maintenance, et 6 pour une machine en cours de redémarrage). 

Suppression des liens de gestion de services 

update-rc.d service remove

chkconfig --del service

Vérification des états d’un service selon les niveaux 

chkconfig --list service

Exemple d’utilisation de la commande chkconfig 

La  commande  chkconfig  permet  aussi  bien  la  création  de  liens  que  la  visualisation  des  services  selon  les  niveaux 
d’exécution. 

[root@beta ~]# ls /etc/rc5.d/*nfs


ls: /etc/rc5.d/*nfs: No such file or directory
[root@beta ~]# chkconfig --add nfs
[root@beta ~]# ls /etc/rc5.d/*nfs
/etc/rc5.d/K20nfs

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


[root@beta ~]# chkconfig --list nfs
nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@beta ~]#

Exemple d’utilisation de la commande update­rc.d 

alpha:/etc/init.d# ls /etc/rc2.d/*cron
ls: ne peut accéder /etc/rc2.d/*cron: Aucun fichier ou répertoire de ce type
alpha:/etc/init.d# update-rc.d cron defaults
Adding system startup for /etc/init.d/cron ...
/etc/rc0.d/K20cron -> ../init.d/cron
/etc/rc1.d/K20cron -> ../init.d/cron
/etc/rc6.d/K20cron -> ../init.d/cron
/etc/rc2.d/S20cron -> ../init.d/cron
/etc/rc3.d/S20cron -> ../init.d/cron
/etc/rc4.d/S20cron -> ../init.d/cron
/etc/rc5.d/S20cron -> ../init.d/cron
alpha:/etc/init.d# ls /etc/rc2.d/*cron
/etc/rc2.d/S20cron
alpha:/etc/init.d#

g. Script indépendant du niveau d’exécution : rc.local 

Une fois tous les scripts liés au niveau courant exécutés, un dernier script : rc.local est exécuté. 

Script rc.local sur une distribution ubuntu 

Prêt à servir... 

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

exit 0

Un  script  /etc/rc.boot  peut  se  rencontrer  sur  certains  systèmes  anciens.  Il  est  également  appelé  par  le 
processus init. 

3. Utilisation des niveaux d’exécution 

Quelle que soit la distribution Linux, l’administrateur a toujours à sa disposition des niveaux d’exécution disponibles 
non  utilisés  par  défaut.  Bien  entendu,  il  ne  sert  à  rien  de  configurer  des  niveaux  d’exécution  pour  le  plaisir.  Dans 
l’immense  majorité  des  cas,  le  système  prévoit  un  niveau  fonctionnel  par  défaut,  et  tout  le  fonctionnement  en 
production va se faire au sein de ce niveau. Dans quelques cas particuliers toutefois, l’administrateur peut choisir de 
configurer certains niveaux pour des besoins fonctionnels particuliers, et chaque niveau d’exécution correspondra à un 
mode de fonctionnement du serveur, avec tout ou partie des services démarrés. 

En  jouant  sur  les  liens  contenus  dans  les  répertoires  rcn.d, et en remplaçant le K de la première lettre par un S ou 
inversement, on provoque, pour le niveau d’exécution donné, le démarrage ou l’arrêt du service. Ainsi, si un service 
donné est appelé par un lien K en niveau 3 et un lien S en niveau 4, l’administrateur pourra en démarrant son système 
dans un de ces deux niveaux choisir le niveau fonctionnel du système. 

On  peut  se  demander  quelle  est  l’importance  du  numéro  d’ordre  situé  derrière  le  S  ou  le  K.  Les  scripts  sont  traités 
dans l’ordre où le shell les présente, et ce sont les caractères alphanumériques du nom du lien qui déterminent l’ordre 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


de lancement ou d’arrêt des scripts. La seule contrainte pour l’affectation de ce numéro est donc le moment auquel le 
script doit être lancé. Si un service est dépendant d’un autre, le script à lancer en dernier doit alors avoir un numéro 
d’ordre supérieur au premier. 

Les  niveaux  d’exécution  n’étant  plus  guère  utilisés  en  tant  qu’outils  d’administration,  les  arrêts  de  services 
sont souvent mal gérés par défaut. Il convient si on souhaite utiliser les niveaux d’exécution comme éléments 
de  gestion  d’un  système  d’inventorier  précisément  quels  sont  les  services  qui  doivent  démarrer  et  quels  sont  les 
services qui doivent s’arrêter à chaque changement. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


Démarrage et chargement du noyau 

1. Le gestionnaire de démarrage GRUB 

Si le processus init est le premier à se lancer sur un système Linux, c’est que le noyau l’appelle systématiquement au 
démarrage. Reste à trouver qui lance le noyau : c’est le rôle du gestionnaire de démarrage. 
Le gestionnaire de démarrage est un petit programme se trouvant généralement sur le MBR (Master Boot Record) et 
dont la fonction est de provoquer le chargement du noyau. Il faut pour cela qu’il connaisse l’emplacement du fichier 
noyau (et sa partition d’appartenance), et la partition qui sera montée sur /, la racine du système de fichiers. 

Si  de  nombreux  programmes  existent  pour  remplir  cette  fonction,  GRUB  (GRand  Unified  Boot  loader)  est  celui  qu’on 
retrouve aujourd’hui sur la quasi­totalité des distributions Linux. Le gestionnaire de démarrage le plus répandu avant 
GRUB était LILO (LInux LOader). LILO affichait ses quatre lettres au démarrage au gré de son chargement et on savait 
ainsi, en cas d’échec, jusqu’où le système avait pu aller. 

a. Configuration de GRUB 

GRUB  lit  sa  configuration  dans  un  fichier /boot/grub/menu.lst.  Pour  lancer  le  noyau,  ce  fichier  référence  certains 
éléments. Selon les systèmes, la configuration principale peut aussi se faire dans un fichier /boot/grub/grub.conf. 
Le fichier menu.lst n’est alors qu’un lien vers ce fichier. 

Format type d’une section de déclaration de noyau dans menu.lst 

title titre
root partition_noyau
kernel /chemin/noyau ro root=partition_slash options
initrd /chemin/image_modules

Fichier /boot/grub/menu.lst 

titre  Si GRUB doit proposer le choix entre plusieurs chargements de noyaux, la section 
titre permet d’identifier le noyau qu’on va charger. 

partition_noyau  La partition hébergeant le noyau, au format (hdx,y) où x représente le numéro de 
disque dur, et y le numéro de la partition. La numérotation commence à zéro. 

noyau  Le fichier exécutable du noyau. Exprimé par rapport à la partition désignée par le 
paramètre root. 

partition_slash  La partition qui sera montée sous « / », désignée au format Linux traditionnel 
(/dev/hda1), ou bien sous forme de label ou encore d’UUID. 

options  Certaines options, séparées par des espaces modifiant le comportement du noyau. 
Option courante : ro (read only). 

image_modules  Le fichier image qui permet de monter un ramdisk contenant tous les modules du 
noyau à charger. Exprimé par rapport à la partition désignée par le paramètre root. 

Exemple de menu.lst sur ubuntu 

Notez que les périphériques sont représentés par les uuid. 

default 0
timeout 10

title Ubuntu 9.10, kernel 2.6.31-16-generic


kernel /boot/vmlinuz-2.6.31-16-generic root=UUID=52200c0b-aee8-4ae0-9492
-1f488051e4a3 ro quiet splash
initrd /boot/initrd.img-2.6.31-16-generic
quiet

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


La  directive  default  dans  le  fichier  de  configuration  de  GRUB  indique  le  noyau  à  charger  en  l’absence d’action  de 
l’utilisateur, et timeout indique au bout de combien de temps charger le noyau par défaut. 

L’option ro pour le montage de la partition racine (celle qui sera montée sur slash) permet d’exécuter les outils de 
diagnostic  sans  dommage  durant  la  phase  de  démarrage  en  cas  de  défaillance  du  filesystem.  L’option  quiet 
empêche le noyau d’être trop bavard au démarrage. 

En  cas  de  besoin,  la  commande rdev  permet  de  vérifier  quel  est  la  partition  montée  sur  /.  Historiquement,  cette 
commande  permettait  aussi  sur  les  architectures  i386  de  patcher  une  image  de  noyau  en  écrivant  les  valeurs 
spécifiques représentant la partition adéquate. Cette commande ne devrait être utilisée qu’en dernier ressort. 

Détermination de la partition racine avec rdev 

alpha:~# rdev
/dev/hda1 /
alpha:~#

b. Le fonctionnement de GRUB 

Grub propose au démarrage le chargement du noyau du système Linux. Si plusieurs versions de noyau coexistent, 
GRUB  proposera  simplement  la  liste  des  noyaux  à  démarrer.  Cette  liste  est  affichée  à  partir  d’un  ensemble  de 
déclarations  de  noyaux  ou  systèmes  amorçables  dans  le  fichier  /boot/grub/menu.lst.  Pour  l’utilisateur,  il  suffit 
d’attendre quelques secondes pour obtenir le chargement du noyau déclaré par défaut dans le fichier menu.lst, ou 
bien de sélectionner avec les flèches de direction et la touche [Entrée] le noyau à charger. 

Choix du noyau à démarrer avec GRUB 

2. Utilisation de GRUB en mode interactif 

a. Édition des sections déjà présentes 

Si  la  déclaration  d’un  noyau  dans  le  fichier  /boot/grub/menu.lst n’est  pas  conforme  à  nos  attentes  (erreurs  de 
saisie à la création du fichier, besoins spécifiques), GRUB offre une particularité très appréciable : l’édition interactive 
des sections déjà présentes dans le fichier de configuration. Il suffit pour cela pendant la période de temporisation 
avant chargement du noyau de se positionner sur la section à modifier, et de taper la touche e. GRUB passe alors 
en  mode  édition,  et  vous  présente  les  lignes  de  la  section  de  déclaration  de  noyau  trouvées  dans  son  fichier  de 
configuration. Vous pouvez alors vous déplacer sur chacune de ces lignes, et choisir de les modifier avec un nouvel 
appui sur la touche e. Lorsque vous êtes satisfait de vos modifications, vous pouvez tenter le chargement du noyau 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


par un appui sur la touche b (boot). Ce mode de fonctionnement représente sans aucun doute un des avantages 
majeurs de GRUB. En effet, il est désespérant de se trouver face à un système qui n’a plus les moyens de démarrer 
et de n’avoir aucune possibilité d’interaction. 

b. Chargement d’un noyau non listé 

Si  on  ne  dispose  pas  d’entrées  à  modifier  dans  GRUB  (en  cas  de  perte  du  fichier  menu.lst  par  exemple),  il  est 
possible  d’indiquer  directement  au  gestionnaire  de  démarrage  l’ensemble  des  éléments  nécessaires.  Il  suffira 
pendant la période de temporisation d’appuyer sur la touche c pour ouvrir une invite interactive. 
Il  faudra  ensuite  taper  une  à  une  les  lignes  qui  gèrent  le  chargement  du  noyau,  telles  qu’elles  seraient 
normalement configurées dans le fichier /boot/grub/menu.lst. 

Procédure de chargement d’un noyau non listé : 

■ Taper « c » pendant la temporisation de GRUB. 

■ Taper « root (hdx,y) » où x représente le numéro de disque et y le numéro de la partition hébergeant le noyau (la 
numérotation commence à zéro). 

■ Taper « kernel /chemin/noyau root=partition ro quiet » où partition est la partition devant être montée sous « / », 
identifiée soit par son fichier spécial en mode blocs sous /dev, soit par son label, soit par son uuid. 

■ Taper « initrd /chemin/image » où image est le fichier image de module présent en principe avec le fichier noyau. 

■ Taper enfin « boot » pour provoquer le chargement de votre noyau. 

Exemple de chargement manuel d’un noyau : 

c (pendant la temporisation avant démarrage)


root (hd0,0)
kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda1 ro quiet
initrd /boot/initrd.img-2.6.26-2-686
boot

Il va sans dire que cette démarche suppose une connaissance précise du plan de partitionnement du système, ainsi 
que des noms des fichiers noyaux et images. L’acquisition  de  ces  éléments  ne  posera  pas  de  problème  si  on  est 
capable de démarrer d’une façon ou d’une autre, mais se révèlera plus problématique dans le cas contraire. Dans 
ces conditions, la récupération de ces éléments devra se faire via un système tiers, un live­cd par exemple. 

3. Réinstallation de GRUB 

a. Réinstallation simple depuis un système actif 

La  commande  grub­install  permet  de  réinstaller  GRUB  sur  un  système  avec  beaucoup  de  facilité.  Cette  méthode 
n’est en revanche pas toujours efficace et fonctionne idéalement à chaud, juste après une suppression accidentelle 
du gestionnaire de démarrage par exemple. 

Installation de GRUB avec grub­install 

grub-install --root-directory=rep_noyau disque_cible

grub­install : options et paramètres 

rep_noyau  Facultatif : si le noyau n’est pas sur le filesystem principal, désigne le répertoire 


monté où se trouve le noyau. 

disque_cible  Le fichier de bloc spécial qui représente le disque sur le MBR duquel GRUB doit être 
installé. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


b. Réinstallation depuis un système non démarrable 

La  solution  la  plus  fiable  pour  réinstaller  un  gestionnaire  de  démarrage  GRUB  sur  un  système  qui  ne  peut  plus 
démarrer consiste à charger sur l’ordinateur un live­cd et de réaliser la réinstallation de GRUB depuis ce live­cd. La 
distribution choisie pour le live­cd importe peu, Knoppix ou Ubuntu feront très bien l’affaire. Il suffit ensuite, après 
être entré dans le mode interactif de GRUB (il suffit de taper grub depuis un terminal) de préciser le disque qui devra 
recevoir le gestionnaire de démarrage, et de lancer la commande setup qui réalisera l’installation proprement dite 
du gestionnaire. 

Installation de GRUB

■ Depuis un terminal du live­cd actif, chargez GRUB en mode interactif en tapant « grub ». 

■ Dans le shell GRUB, précisez la partition qui héberge le fichier noyau en tapant « root (hdx,y) » où x représente le 
numéro du disque et y le numéro de partition, la numérotation commençant à zéro. 

■ Tapez ensuite « setup (hdx) » où x représente le numéro du disque sur lequel GRUB doit être installé. 

■ Tapez « quit » pour quitter le mode interactif de GRUB. 

■ Selon le cas, vérifiez ou créez le fichier /boot/grub/menu.lst afin qu’il référence correctement le ou les noyaux à 
charger. 

4. Maintenance et mode single 

a. Passage en mode single planifié 

Le  mode  single  permet  de  réaliser  des  opérations  de  maintenance  sur  un  système.  Dans  ce  mode  de 
fonctionnement,  seule  la  connexion  du  compte  root  est  possible,  et  presque  aucun  service  n’est  démarré.  Le 
système est donc dans un état le plus stable possible, et aucune interaction malencontreuse n’est à redouter car 
l’administrateur travaille seul. 

Passage en mode single 

telinit 1

b. Ouverture d’un shell en cas d’échec au démarrage 

Il  est  possible  de  passer  un  paramètre  au  noyau  lui  indiquant  un  processus  à  démarrer.  Si  ce  processus  est  un 
shell,  il  permet  d’ouvrir  une  session  interactive  et  de  modifier  les  fichiers  locaux  et  démarrer  manuellement  des 
services. 

Il suffit d’éditer la ligne chargeant le noyau dans GRUB et d’ajouter le paramètre init=/bin/bash. 

Ouverture d’un shell directement au démarrage 

kernel fichier_noyau root=fs_racine ro init=/bin/bash

Où fichier_noyau représente le noyau normalement chargé, et fs_racine, le système de fichiers racine normalement 
chargé. Seul le paramètre init=/bin/bash doit être ajouté à la ligne de commande. 

Procédure d’ouverture de shell au démarrage

■ Démarrer physiquement le système. 

■ Modifier le chargement par défaut en tapant la touche « e » depuis la liste des systèmes disponibles. 

■ Ajouter le paramètre init=/bin/bash à la fin de la ligne kernel. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


■ Charger le noyau en tapant la touche « b ». 

L’appel  d’un  shell  directement  depuis  le  noyau  permet  d’accéder  au  système  sans  avoir  à  s’authentifier. 
Cette procédure montre s’il en était besoin que l’accès physique à une machine sensible doit toujours être 
protégé.  Il  est  certes  possible  de  protéger  GRUB  de  l’édition  par  un  mot  de  passe,  mais  l’accès  par  un  média 
amovible au filesystem reste un danger. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Configuration du réseau 

1. Configuration universelle du réseau 

Chaque  distribution  Linux  essaye  de  faire  en  sorte  que  les  paramètres  réseau  soient  aussi  faciles  que  possible  à 
configurer. Le but est souvent de ne pas souffrir de la comparaison avec Windows, et de faire en sorte que l’utilisateur 
ait  à  sa  disposition  une  interface  intuitive  et  facile  à  configurer.  Cette  configuration  se  fait  avec  des  utilitaires, 
graphiques ou non, et des fichiers de configuration que liront les scripts de lancement du réseau. 
Indépendamment  de  ces  éléments  de  confort  apportés  par  les  distributions  ou  les  bureaux  graphiques,  on  aura 
toujours,  quelle  que  soit  la  distribution  et  l’environnement,  les  commandes  de  base  permettant  la  configuration  du 
réseau, à savoir l’adresse ip, la route par défaut, et l’adresse des serveurs DNS. La démarche indiquée ci­après, si elle 
n’est pas la plus rapide (quoique), a l’avantage de l’universalité. 

a. Détermination de l’interface réseau 

Les systèmes Linux utilisent un nom symbolique par interface réseau, qu’il s’agisse d’une interface réelle ou virtuelle, 
ethernet ou autre. Dans le cas courant où le système est connecté à un réseau ethernet et n’utilise  qu’une seule 
carte, cette carte sera désignée « eth0 ». On pourra déterminer la liste de toutes les interfaces réseaux existant sur 
un système, configurée ou non par la commande ifconfig. 

Détermination des interfaces réseau par la commande ifconfig 

ifconfig -a

b. Affectation de l’adresse IP : ifconfig 

La commande ifconfig a de nombreux usages, et elle est surtout connue pour afficher les adresses MAC et IP pour 
un système déjà configuré. Néanmoins, la commande ifconfig peut aussi être utilisée pour affecter dynamiquement 
l’adresse et le masque d’une machine. 

Affectation d’une adresse IP avec la commande ifconfig 

ifconfig interface adresse_ip


ifconfig interface netmask masque

Même si ça n’est pas le plus courant des usages, il est possible d’ajouter une deuxième adresse IP à une interface 
déjà configurée. 

Ajout d’une adresse IP secondaire à une interface 

ifconfig interface:sous-interface adresse_ip

Commande ifconfig : options et paramètres 

interface  Nom Linux de l’interface. Par exemple eth0. 

sous­interface  Nom arbitraire de la sous­interface. Chaîne de caractères quelconque. 

adresse_ip  Adresse IP à affecter à la machine. 

masque  Valeur du masque de sous­réseau associé à l’adresse IP. 

c. Configuration du client DNS : fichier /etc/resolv.conf 

Les machines Linux disposent nativement d’un client DNS appelé resolver. Toute application fonctionnant sur Linux 
et ayant besoin de faire une requête DNS s’appuiera sur ce composant. 
Il exploite le fichier de configuration simple /etc/resolv.conf où doit se trouver la référence d’au moins un serveur 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


DNS. 

Format simplifié du fichier /etc/resolv.conf 

search domaine
nameserver adresse_ip

Fichier /etc/resolv.conf : directives et variables utilisées 

search  Facultatif : indique le suffixe de recherche employé sur le poste Linux. Permet de ne 
pas taper l’intégralité du nom de domaine pleinement qualifié (FQDN) dans les 
applications. Le fichier /etc/resolv.conf admet plusieurs domaines de recherches 
précisés par search. 

domaine  Le FQDN du domaine constituant le suffixe de recherche. 

nameserver  Indique l’adresse IP du serveur DNS qui assurera les résolutions. Le 
fichier /etc/resolv.conf admet plusieurs serveurs DNS précisés par nameserver. 

adresse_ip  Adresse IP du serveur DNS à interroger. 

Certaines documentations préconisent l’usage  de  la  commande  hostname ­d pour connaître le suffixe DNS 


d’un système. Il s’agit du suffixe attaché au nom d’hôte, et non au client DNS. Il n’est donc pas consulté lors 
des résolutions DNS. 

d. Configuration de la passerelle par défaut : route 

La commande route permet de définir des routes statiques sur une machine Linux. Dans le cadre d’une configuration 
simple et ponctuelle, on pourra l’utiliser pour définir la passerelle par défaut. Il s’agira en fait de déclarer une route 
statique indiquant la route par défaut. 

Syntaxe de la commande route pour indiquer une route statique 

route add -net réseau_dest netmask masque gw ip_passerelle

Syntaxe de la commande route pour indiquer la passerelle par défaut 

route add -net 0.0.0.0 gw ip_passerelle


route add default gw ip_passerelle

Commande route : options et paramètres 

add  Indique que l’on ajoute une route à la table de routage. 

­net  Indique que la destination est un réseau. 

réseau_dest  Le réseau à atteindre par la route statique qu’on paramètre. 

0.0.0.0  La route par défaut. 0.0.0.0 représente tous les réseaux possibles. 

gw  Annonce la valeur de la passerelle. 

ip_passerelle  Adresse IP de la passerelle à utiliser. 

default  Équivalent à ­net 0.0.0.0 

masque  Le masque de sous­réseau associé à la route ajoutée. 

Un  serveur  Linux  utilisé  en  tant  que  routeur  supporte  aussi  les  principaux  protocoles  de  routage.  Le  logiciel 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


historique  routed  supporte  uniquement  le  protocole  de  routage  RIP,  alors  que  la  suite  logicielle  plus  moderne 
quagga permet d’exploiter la quasi­totalité des protocoles de routages IP. 

e. Configuration du nom d’hôte : hostname 

Le  nom  d’hôte  de  la  machine  peut  être  affecté  dynamiquement  avec  la  commande  hostname.  Il  permet  aussi 
d’afficher le nom d’hôte du système s’il est appelé sans argument. 

Syntaxe de la commande hostname pour affecter un nom d’hôte 

hostname nom_hote

nom_hote représentant le nom qu’on souhaite affecter au système. 
Attention,  cette  valeur  est  conservée  en  mémoire  vive,  et  sera  perdue  dès  que  le  système  redémarrera.  Les 
systèmes ordinaires en production doivent donc conserver cette valeur dans un fichier de configuration qui est lu à 
chaque  démarrage.  Ce  fichier  dépend  de  la  distribution.  C’est  par  exemple  /etc/hostname  pour  les  distributions 
d’origine  Debian,  et  /etc/sysconfig/network  pour  les  distributions  d’origine  RedHat.  Les  scripts  exécutés  au 
démarrage du système se chargent d’appeler  la  commande hostname et récupèrent la valeur du nom du système 
dans le fichier. 

Exemple de contenu d’un fichier /etc/hostname 

root@firmin:~$ cat /etc/hostname


firmin

2. Spécificité des distributions 

Les seules règles universelles pour la configuration du réseau sont celles décrites dans les paragraphes précédents. 
Les  distributions  Linux  courantes  ont  néanmoins  des  procédures  de  configuration  par  scripts  et  fichiers  de 
configuration  qu’on  peut  classer  en  deux  grandes  familles  :  celles  dont  la  configuration  réseau  est  située  dans  le 
répertoire  /etc/network,  et  celles  dont  la  configuration  réseau  est  située  dans  le 
répertoire /etc/sysconfig/network­scripts. 

a. Configuration réseau dans /etc/network 

C’est le cas des distributions Debian et dérivées. Les éléments de configuration sont situés dans un fichier au format 
simple : /etc/interfaces. 

Format du fichier de configuration /etc.network/interfaces pour une adresse IP statique 

auto interface
iface interface inet static
address adresse_ip
netmask masque
gateway ip_passerelle

Format du fichier de configuration /etc.network/interfaces pour une adresse IP dynamique 

auto interface
iface interface inet dhcp

Fichier interfaces : options et paramètres 

auto  Indique que l’interface devra être activée automatiquement au démarrage. 

interface  Le nom linuxien de l’interface à configurer (exemple : eth0). 

inet  Indique qu’on va affecter une adresse Ipv4. 

static  Indique que l’adresse IP configurée sera statique. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


adresse_ip  Adresse IP à affecter à l’interface. 

masque  Masque de sous­réseau à affecter à l’interface. 

ip_passerelle  Adresse IP de la passerelle par défaut. 

dhcp  Indique que l’adresse IP configurée sera dynamique et obtenue par requête DHCP. 

Ces fichiers n’ont évidemment aucune action en eux­mêmes, ils sont appelés par le script de lancement du service 
réseau (en général /etc/init.d/networking), lequel script invoquera la commande  ifup (interface up) pour activer les 
interfaces avec leurs paramètres réseau. 

b. Configuration réseau dans /etc/sysconfig/network­scripts 

C’est le cas des distributions RedHat et dérivées. Les éléments de configuration sont situés dans un fichier au format 
simple par interface situé dans le répertoire /etc/sysconfig/network­scripts. Ces fichiers ont tous le préfixe ifcfg­ suivi 
du nom de l’interface à configurer. 

Format du fichier ifcfg­interface pour une adresse IP statique 

DEVICE=interface
BOOTPROTO=none
ONBOOT=yes
IPADDR=adresse_ip
NETMASK=masque
GATEWAY=ip_passerelle

Format du fichier ifcfg­interface pour une adresse IP dynamique 

DEVICE=interface
BOOTPROTO=dhcp
ONBOOT=yes

Fichier ifcfg : options et paramètres 

interface  Le nom Linux de l’interface à configurer (exemple : eth0). 

BOOTPROTO=dhcp  Indique que l’adresse IP configurée sera dynamique et obtenue par requête 
DHCP. 

ONBOOT=yes  Indique que l’interface devra être activée automatiquement au démarrage. 

adresse_ip  Adresse IP à affecter à l’interface. 

masque  Masque de sous­réseau à affecter à l’interface. 

ip_passerelle  Adresse IP de la passerelle par défaut. 

Quel que soit le format des fichiers de configuration réseau, le paramètre précisant l’adresse de passerelle à 
proximité de la configuration d’une interface pourrait faire penser que la passerelle est attachée à l’interface. 
Or une passerelle par défaut, quel que soit le système, est unique et liée à la table de routage du système et non 
à une quelconque interface. 

3. Autres commandes et fichiers de gestion du réseau 

Nous avons vu que les paramètres réseau pouvaient être configurés avec les seules commandes ifconfig et route. Il 
existe  néanmoins  de  nombreux  autres  utilitaires  qui  permettent  d’administrer,  configurer  et  diagnostiquer  le 
fonctionnement du réseau. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


a. Gestion des adresses MAC avec arp 

Tout équipement réseau qui exploite le protocole IP sur un réseau ethernet est tenu, pour établir la correspondance 
entre  les  adresses  IP  et  les  adresses  MAC,  d’utiliser  le  protocole  ARP.  Dans  un  fonctionnement  dynamique,  cas  le 
plus courant, une machine connaissant l’adresse IP de son destinataire mais ayant besoin de renseigner son en­tête 
MAC  pour  communiquer  envoie  un  broadcast  pour  demander  si  quelqu’un  sur  le  réseau  possède  l’adresse  IP  en 
question.  Si  la  machine  destinataire  est  à  portée  de  broadcast  (c’est­à­dire  dans  le  réseau  local),  elle  répond  en 
unicast  et  indique  son  adresse  MAC.  La  résolution  ARP  est  alors  réalisée.  Les  correspondances  établies  entre 
adresses  MAC  et  adresses  IP  sont  conservées  un  certain  temps  en  mémoire  dans  ce  qu’on  appelle  le  cache  ARP. 
Dans  quelques  cas  particuliers,  on  peut  aussi  affecter  de  façon  statique  une  correspondance  entre  adresse  IP  et 
adresse MAC. 
La commande arp permet d’observer et éventuellement de gérer les valeurs contenues dans ce cache. 

Syntaxe de la commande arp pour observer le cache 

arp -n

Le paramètre ­n n’est pas obligatoire, mais il dispense le système de réaliser une recherche DNS inverse qui ralentit 
énormément l’affichage. 

Syntaxe de la commande arp pour effacer une entrée du cache 

arp -d adresse_ip

Syntaxe de la commande arp pour affecter une valeur au cache 

arp -s adresse_ip adresse_mac

Où adresse_ip représente l’adresse IP de l’entrée que l’on souhaite gérer, et adresse_mac représente l’adresse MAC 
d’une  entrée  à  associer  à  une  adresse  IP.  Les  adresses  MAC  sont  exprimées  sous  forme  d’octets  en  hexadécimal 
séparés par des doubles points. 
L’usage  courant  est  naturellement  de  laisser  l’intégralité  des  associations  entre  adresses  MAC  et  adresses  IP  se 
réaliser  dynamiquement.  Si  on  souhaite  néanmoins  configurer  un  grand  nombre  d’associations  statiques,  il  sera 
intéressant de renseigner un fichier /etc/ethers, et d’appeler la commande arp avec l’option ­f. 

Format du fichier /etc/ethers 

adresse_mac1 adresse_ip1
adresse_mac2 adresse_ip2
...
adresse_macn adresse_ipn

Exploitation de la commande arp 

On  utilise  ici  la  commande  arp  pour  afficher  le  contenu  du  cache  arp  avant  et  après  activité.  On  affecte  ensuite 
manuellement  une  adresse  MAC  à  une  adresse  IP,  puis  on  prend  en  compte  le  contenu  du  fichier  /etc/ethers  pour 
configurer plusieurs associations. 

alpha:~# arp -n
alpha:~# ping 192.168.199.1
PING 192.168.199.1 (192.168.199.1) 56(84) bytes of data.
(...)
alpha:~# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.199.1 ether 08:00:27:e4:07:62 C eth0
alpha:~# arp -s 192.168.199.222 00:01:02:a1:b2:b3
alpha:~# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.199.222 ether 00:01:02:a1:b2:b3 CM eth0
192.168.199.1 ether 08:00:27:e4:07:62 C eth0
alpha:~# cat /etc/ethers
00:00:00:01:02:03 192.168.199.33
00:00:00:01:02:04 192.168.199.34
00:00:00:01:02:05 192.168.199.35

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


00:00:00:01:02:06 192.168.199.36
alpha:~# arp -f
alpha:~# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.199.222 ether 00:01:02:a1:b2:b3 CM eth0
192.168.199.33 ether 00:00:00:01:02:03 CM eth0
192.168.199.35 ether 00:00:00:01:02:05 CM eth0
192.168.199.34 ether 00:00:00:01:02:04 CM eth0
192.168.199.36 ether 00:00:00:01:02:06 CM eth0
192.168.199.1 ether 08:00:27:e4:07:62 C eth0
alpha:~#

b. TCP Wrappers 

Il est possible de gérer les accès à un système Linux selon les adresses IP ou les noms d’hôtes des clients. On peut 
gérer une liste de « tous ceux qui sont autorisés », ou bien une liste de « tous ceux qui sont interdits ». Même si les 
techniques modernes d’intrusion et de piratage rendent ce type de contrôle d’accès presque insignifiant, cela reste 
tout de même une forme de contrôle rudimentaire qui peut décourager les touristes. 

L’implémentation TCPWrappers utilisée sur les systèmes Linux s’appuie sur la bibliothèque libwrap. 

Les deux fichiers permettant ce contrôle sont /etc/hosts.allow pour les clients autorisés, et /etc/hosts.deny pour 
les clients non autorisés. Ils sont lus par le démon tcpd qui appliquera les contrôles d’accès en conséquence. De par 
leur principe de fonctionnement, ces fichiers devraient être utilisés indépendamment : si on autorise certains hôtes à 
se connecter, cela signifie que tous les autres sont interdits, et donc le fichier d’interdiction perd de son intérêt. Si 
toutefois  les  deux  fichiers  étaient  présents  dur  un  système,  seul  le  fichier  /etc/hosts.allow  serait  appliqué,  et  le 
fichier /etc/hosts.deny serait ignoré. 

Format des fichiers hosts.allow et hosts.deny 

service: clients

TCP Wrappers : fichiers de contrôle d’accès 

service  Le nom du service dont l’accès est contrôlé. ALL est une valeur courante qui représente tous les 
services éligibles. 

clients  Nom DNS ou adresse IP des clients. Plusieurs valeurs peuvent être renseignées séparées par 
des espaces. supporte de nombreux jokers et formats. ALL est une valeur courante qui 
représente toutes les adresses IP. 

Exemple de fichier hosts.allow 

Notez le premier exemple dont l’adresse se termine par un point. Cette syntaxe un peu particulière permet de désigner les 
adresses dont la partie précédant le point concorde. 

# Toutes les adresses commençant par 10.1 sont éligibles


ftp:10.1.
# Seule l’adresse 172.12.5.28 peut se connecter
sshd: 172.12.5.28
# Toutes les adresses du réseau 192.168.1.0 peuvent se connecter
ALL: 192.168.1.0/255.255.255.0

4. Configuration Wi­Fi 

Les  distributions  et  les  bureaux  graphiques  fournissent  des  utilitaires  graphiques  pour  l’administration  des  réseaux 
Wi­Fi  dont  l’utilisation  est  intuitive.  Nous  allons  donc  voir  ici  comment  configurer  pas  à  pas  une  connexion  Wi­Fi  en 
lignes de commandes. Les principaux outils seront ifconfig, iwconfig, et iwlist. 

a. Détermination de l’interface Wi­Fi 

Nous  savons  que  la  commande  ifconfig  ­a  permet  d’observer  toutes  les  interfaces  réseaux  présentes  sur  un 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


système, même si elles ne sont pas activées. Une carte Wi­Fi doit donc forcément se trouver dans la liste renvoyée 
par  cette  commande.  Toutefois,  si  le  système  comporte  plusieurs  cartes  réseau,  une  commande  spécifique  nous 
permettra d’affiner notre choix. 

Visualisation des interfaces Wi­Fi avec iwconfig 

Toutes les interfaces renvoyant une référence à 802.11 sont des interfaces Wi­Fi. Dans cet exemple, c’est la carte eth1. 

toto@ubuntu:~$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 IEEE 802.11 Nickname:""


Access Point: Not-Associated
Link Quality:5 Signal level:0 Noise level:166
Rx invalid nwid:0 invalid crypt:0 invalid misc:0

vboxnet0 no wireless extensions.

b. Visualisation des réseaux disponibles 

La commande iwlist permet de faire l’inventaire des réseaux disponibles. 

Syntaxe de la commande iwlist pour la visualisation des réseaux environnants 

iwlist interface scan

Où interface est le nom de la carte réseau Wi­Fi, et scan le paramètre qui indique la nature de l’action à opérer. 

Exemple de scan avec iwlist 

Dans cet exemple, on voit que deux réseaux sont disponibles. Le premier est émis par un point d’accès dont l’adresse MAC 
est  00:0A:66:13:E7:01,  fonctionnant  en  802.11g  (2,4  GHz  et  54  Mb/s),  et  dont  le  SSID  est  pifou.  L’encryption  est 
réalisée  en  WPA­TKIP.  Le  deuxième  provient  d’un  point  d’accès  dont  l’adresse  MAC  est  CA:9D:2E:E6:B7:56,  émettant 
aussi en 802.11g, avec le ssid hotspot et sans aucune sécurité. 

toto@ubuntu:~$ sudo iwlist eth1 scan


eth1 Scan completed :
Cell 01 - Address: 00:0A:66:13:E7:01
ESSID:"pifou"
Mode:Managed
Frequency=2.437 GHz (Channel 6)
Quality:5/5 Signal level:-50 dBm Noise level:-78 dBm
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
12 Mb/s; 48 Mb/s
Cell 02 - Address: CA:9D:2E:E6:B7:56
ESSID:"hotspot"
Mode:Managed
Frequency:2.427 GHz (Channel 4)
Quality:1/5 Signal level:-83 dBm Noise level:-84 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 9 Mb/s
18 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 12 Mb/s
24 Mb/s; 48 Mb/s

c. Connexion à un réseau non sécurisé 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


Une fois le réseau déterminé, on peut s’y connecter par la commande iwconfig. 

Association à un réseau sans fil ouvert 

iwconfig interface essid nom_ssid

Où interface  représente  l’interface réseau Wi­Fi gérée par le système, et nom_ssid le nom du réseau Wi­Fi (Service 


Set Identifier) auquel on souhaite se connecter. 

- 8- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Diagnostic réseau 

1. Outils de diagnostics en couche réseau 

a. ping 

La célèbre commande ping rend toujours d’immenses services. Elle permet bien entendu de tester la connectivité IP 
de bout en bout, de tester la résolution DNS native, mais aussi d’obtenir des informations plus subtiles, comme par 
exemple l’indication qu’une route est inaccessible. 
La commande ping exploite le protocole ICMP (Internet Control Message Protocol). 

Exemple de réponse au ping 

Dans  cet  exemple,  la  réponse  au  ping  est  différente  selon  que  la  route  existe  et  que  la  machine  cible  du  ping  est 
indisponible, ou que la route est inconnue. 

A:~$ route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.200.0 * 255.255.255.0 U 1 0 0 eth0
A:~$ ping 172.17.18.19
connect: Network is unreachable
A:~$ route add -net 172.17.0.0 netmask 255.255.0.0 gw 192.168.200.254
A:~$ ping 172.17.18.19
PING 172.17.18.19 (172.17.18.19) 56(84) bytes of data.
From 172.17.18.19 icmp_seq=1 Destination Host Unreachable
From 172.17.18.18 icmp_seq=2 Destination Host Unreachable
A:~$

b. Indicateurs de la commande route 

La commande  route, utilisée pour configurer des routes statiques, fournit également des éléments de diagnostics. 
Elle permet de savoir quels sont les réseaux locaux ou distants (accessibles par une passerelle), ou encore de voir 
qu’une route est rejetée par le noyau. Ces informations sont données par les indicateurs de la commande route. 

Commande route : principaux indicateurs 

U  Up : la route est active et exploitable. 

H  Host : la cible est un hôte (et non un réseau). 

G  Gateway : la cible est accessible par une passerelle. 

D  Dynamic : la route a été configurée par un protocole de routage. 

!  Le noyau a rejeté la route. 

Exemple d’indications de la commande route 

Toutes les routes sont actives et exploitables. 

[root@beta ~]# route


Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
10.1.2.3 192.168.200.200 255.255.255.255 UGH 0 0 0 eth0
192.168.199.0 * 255.255.255.0 U 0 0 0 eth1
192.168.200.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


default 192.168.200.254 0.0.0.0 UG 0 0 0 eth0
[root@beta ~]#

c. traceroute 

La commande traceroute comme la commande ping permet de tester la connectivité avec un système distant, mais 
en donnant l’ensemble des routeurs qui permettent d’acheminer le paquet. En cas de problème de connectivité, on 
peut donc déterminer à quel endroit le paquet est bloqué ou s’est perdu. 

Exemple d’utilisation de la commande traceroute 

Dans  cet  exemple,  on  constate  que  pour  atteindre  la  machine  192.168.199.10,  il  faut  d’abord  passer  par  le  routeur 
10.8.0.1. 

tata@stotion:~$ traceroute 192.168.199.10


traceroute to 192.168.199.10 (192.168.199.10), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 44.928 ms 50.972 ms 51.015 ms
2 192.168.199.10 (192.168.199.10) 51.056 ms 51.112 ms 51.149 ms
tata@stotion:~$

2. Outils de diagnostics en couches transport et application 

a. netstat 

La commande netstat permet d’observer les connexions établies avec le système local. Ces connexions peuvent être 
de type TCP, UDP, ou socket. Les connexions TCP et UDP sont en général établies avec des systèmes distants, alors 
que  les  sockets  sont  des  fichiers  de  type  particuliers  qui  servent  de  point  d’échange  entre  des  composants 
applicatifs sans passer par le réseau. Par exemple, le serveur d’affichage X qui était à l’origine une application client­
serveur utilisée en réseau utilise désormais un socket pour les communications entre le client X et son serveur situés 
sur la même machine. 
Dans un but de diagnostic du fonctionnement réseau, on s’intéressera principalement aux connexions TCP et UDP. 

Syntaxe de la commande netstat pour voir les connexions actives 

netstat -n

Où l’option ­n, facultative, empêche la résolution inverse sur les adresses IP et sur les numéros de ports. L’affichage 
est plus rapide. 

Observation des processus responsables de connexions réseau 

netstat -p

Exemple d’utilisation de la commande netstat 

Observons  ici  la  commande  netstat  appelée  toutes  les  secondes  pour  surveiller  la  connexion  avec  une  application  du 
système local. L’exemple propose un script contenant une boucle infinie et dont toutes les commandes sont placées sur 
une seule ligne. Si on a un besoin répété de cette commande sous cette forme, on aura intérêt à créer un fichier de script. 

while true ; do clear ; netstat -an | head -20 ; sleep 1 ; done

On pourra sortir de cette boucle par la combinaison des touches [Ctrl] C. 

b. nc 

La commande nc ou netcat est un outil qui permet de lire ou écrire des données au travers de connexions réseau. 
Par exemple, si on est confronté à une application quelconque qui fonctionne en TCP sur le port 1234 et qu’on ne 
dispose d’aucun outil de diagnostic, nc permet d’établir une connexion sur le port TCP/1234, d’envoyer des données 
brutes, et d’observer la réponse du serveur. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Syntaxe de la commande nc 

nc -u adresse_ip port

Commande nc : options et paramètres 

­u  Facultatif. Précise que l’on souhaite travailler en UDP. Si ce paramètre est omis, 
toutes les requêtes sont faites en TCP. 

adresse_ip  L’adresse IP de la machine avec laquelle on souhaite communiquer. 

port  Le port par lequel on souhaite s’adresser à la machine distante. 

Exemple d’utilisation de nc pour interroger un serveur web 

Dans  cet  exemple,  le  serveur  interrogé  répond  bien  en  html  au  code  http  (GET  /)  qui  lui  demande  d’afficher  sa  page 
d’accueil par défaut. On voit bien ici que l’utilisation de nc à des fins de diagnostic nécessite une connaissance précise des 
protocoles sous­jacents. 

toto@ubuntu:~$ nc 172.17.6.26 80
GET /
<html><body><h1>It works!</h1></body></html>
toto@ubuntu:~$

3. Diagnostics et informations en couche application 

a. lsof 

La commande lsof permet d’établir la liste des fichiers ouverts par des processus sur un système. lsof exécutée sans 
options affiche simplement l’ensemble des fichiers appartenant à tous les processus actifs. 

Affichage des fichiers ouverts par la commande xeyes 

Les colonnes les plus directement utiles sont PID, USER et NAME. 

A# lsof | grep xeyes


COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
xeyes 9584 toto cwd DIR 8,3 12288 7258113 /tmp
xeyes 9584 toto rtd DIR 8,3 4096 2 /
xeyes 9584 toto txt REG 8,3 20416 2366803 /usr/bin/xeyes
xeyes 9584 toto mem REG 8,3 22568 2362738 /usr/lib/libXfixes.so.3.1.0
xeyes 9584 toto mem REG 8,3 39232 1966225 /usr/lib/libXcursor.so.1.0.2
xeyes 9584 toto mem REG 8,3 1170770 6463538 /usr/lib/locale/fr_FR.utf8/
LC_COLLATE
xeyes 9584 toto mem REG 8,3 19008 2146517 /lib/libuuid.so.1.3.0
xeyes 9584 toto mem REG 8,3 22560 2364984 /usr/lib/libXdmcp.so.6.0.0
xeyes 9584 toto mem REG 8,3 14488 2364981 /usr/lib/libXau.so.6.0.0
xeyes 9584 toto mem REG 8,3 97904 2364446 /usr/lib/libICE.so.6.3.0

b. Journaux sur /var/log/syslog & /var/log/messages 

Les  fichiers  /var/log/syslog  sur  les  distributions  d’origine  Debian  et  /var/log/messages  sur  les  distributions 
d’origine  Red  Hat  concentrent  l’essentiel  des  remontés  de  journaux  toutes  applications  confondues.  Ils  sont 
alimentés par le démon syslogd pour Red Hat ou rsyslogd pour Debian et s’incrémentent à chaque événement subit 
ou  provoqué  par  une  application  compatible  syslog.  Ainsi,  les  événements  associés  au  réseau,  qu’ils  proviennent 
d’une  application  client­serveur  ou  de  la  gestion  du  réseau  par  le  système  elle­même  seront  probablement 
mentionnés dans ces fichiers journaux. 

Sur les systèmes d’origine Debian, un fichier /var/log/deamon.log est spécifiquement réservé aux journaux d’activité 
des services. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Visualisation des événements relatifs aux cartes réseau 

Les journaux représentent les principales sources d’information en cas de dysfonctionnement applicatif. 

toto@ubuntu:/tmp$ grep eth /var/log/syslog | head


Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1)
starting connection ’Auto orange’
Jun 24 19:21:08 ubuntu NetworkManager: <info> (eth1): device state change: 3 -> 4
(reason 0)
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1) Stage 1 of 5
(Device Prepare) scheduled...
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1) Stage 1 of 5
(Device Prepare) started...
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1) Stage 2 of 5
(Device Configure) scheduled...
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1) Stage 1 of 5
(Device Prepare) complete.
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1) Stage 2 of 5
(Device Configure) starting...
Jun 24 19:21:08 ubuntu NetworkManager: <info> (eth1): device state change: 4 -> 5
(reason 0)
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1/wireless):
connection ’Auto orange’ requires no security. No secrets needed.
Jun 24 19:21:08 ubuntu NetworkManager: <info> Activation (eth1) Stage 2 of 5
(Device Configure) complete.

4. Libpcap et les captures de paquets 

a. La bibliothèque libpcap 

Pour  récupérer  des  informations  précises  sur  le  fonctionnement  réseau  d’une  application,  il  arrive  que  l’on  doive 
capturer directement l’ensemble des éléments qui passent sur le réseau. Les outils pour y parvenir sont nombreux 
sur tous les systèmes. En environnement Linux, ces outils s’appuient pour la plupart sur la bibliothèque libpcap qui 
fournit une interface de bas niveau normalisée pour la capture de paquets. libpcap a été créée à partir des premiers 
développements  d’une  commande  de  capture  appelée  tcpdump.  Elle  fut  par  la  suite  exploitée  par  de  nombreux 
logiciels d’analyse réseau dont le célèbre wireshark. 

b. tcpdump 

tcpdump est un outil qui envoie sur la sortie standard (l’écran) une information résumée des captures réalisées par 
la carte réseau. tcpdump travaillant en temps réel (moyennant le temps de traitement par le programme), il est utile 
pour  surveiller  directement  l’activité  réseau  d’une  machine.  Si  on  dirige  les  captures  vers  un  fichier,  alors  les 
informations complètes des paquets capturées sont conservées et utilisables par d’autres outils compatibles avec le 
format libpcap. 

Syntaxe de la commande tcpdump 

tcpdump -w fichier -i interface -s fenêtre -n filtre

tcpdump : options et paramètres 

­w fichier  Facultatif : pour envoyer le résultat de la capture vers un fichier au format libpcap. 

­i interface  Facultatif : pour réaliser la capture depuis une interface précise. 

­s fenêtre  Facultatif : pour limiter la taille des trames capturées. Surtout utilisé avec le 


paramètre 0 (pas de limite). 

­n  Facultatif : ne pas remplacer les valeurs numériques par des expressions littérales. 

filtre  Détermine le trafic à capturer. Mots­clés principaux : host, port, src, dest. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Exemple d’utilisation de tcpdump 

L’exemple  ci­dessous  nous  montre  des  éléments  de  trafic  capturés  à  la  volée  par  tcpdump.  Notez  que  la  brièveté  des 
informations  proposées  (ici  des  échanges  liés  au  Spanning  Tree  Protocol  entre  commutateurs)  ne  permet  pas  d’analyse 
profonde, mais surtout de constater de visu la nature des informations échangées. 

root@serveur:~$ tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth6, link-type EN10MB (Ethernet), capture size 96 bytes
10:07:59.961927
10:08:00.019503 STP 802.1d, Config, Flags [none], bridge-id
8007.00:25:46:b4:3c:80.800c, length 43
10:08:02.034712 STP 802.1d, Config, Flags [none], bridge-id
8007.00:25:46:b4:3c:80.800c, length 43
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@serveur:~$

Cet  exemple  plus  précis  envoie  vers  un  fichier  au  format  libpcap  les  requêtes  http  vers  un  serveur  à  l’adresse  IP 
192.168.50.24. 

root@serveur:~$ tcpdump -w fichier.cap -i eth0 -s 0 -n port 80 and host


192.168.50.24
root@serveur:~$

c. Wireshark 

Wireshark  (anciennement  ethereal)  est  une  application  de  capture  de  trames  multiplate­forme  disponible 
notamment sur les environnements Windows et Linux. Wireshark s’appuie sur la bibliothèque libpcap et permet de 
sauvegarder les données capturées à ce format ou d’exploiter des captures faites par d’autres utilitaires. Wireshark 
propose pour chacune des captures un découpage selon les couches du modèle OSI des informations capturées, ce 
qui est à la fois pratique et très pédagogique. 

Procédure standard de capture avec wireshark 

■ Lancez l’applicatif Wireshark. 

■ Dans le menu Capture, choisissez Interfaces. 

■ Repérez la carte réseau à laquelle est associée votre adresse IP. 

■ Cliquez sur Start pour lancer la capture. 

■ Visualisez les paquets en cours de captures. 

■ Arrêtez la capture en cliquant sur Stop dans le menu Capture. 

Exemple de capture de paquets avec wireshark 

Notez l’écran divisé horizontalement en trois panneaux : le paquet à analyser, les détails couche par couche, et la valeur 
hexadécimale des informations capturées. Ici, on voit qu’il s’agit d’une requête DNS de type A pour la résolution du nom 
start.ubuntu.com. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


 

Sur  un  réseau  encombré,  on  risque  d’être  noyé  sous  une  avalanche  de  paquets  capturés  qui  n’ont  pas 
forcément  de  rapport  avec  ce  que  l’on  cherche.  On  gagnera  en  visibilité  en  appliquant  un  filtre  d’affichage 
(champ Filter sur l’écran principal). Cette opération a l’avantage d’être réversible (bouton Clear). 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Configuration automatique avec DHCP 

1. Le protocole DHCP 

DHCP  (Dynamic  Host  Configuration  Protocol)  est  un  protocole  client­serveur  qui  a  pour  objet  d’affecter 
automatiquement une adresse IP ainsi que des paramètres fonctionnels aux hôtes du réseau. Il est exploité par tout 
équipement qui ne peut pas être configuré de façon statique par un administrateur réseau. 

a. Fonctionnement 

Découverte d’un serveur

Les clients DHCP font une requête sur le réseau dans l’espoir de trouver un serveur DHCP. Cette requête initiale ne 
peut être qu’un broadcast : la station à l’origine de la requête ne connaît même pas sa propre adresse, il est donc 
peu probable qu’elle connaisse par avance l’adresse d’un serveur DHCP. 
Les paquets envoyés pour la découverte portent le nom normalisé de DHCPDISCOVER. 

Première réponse du serveur

Si un serveur DHCP présent sur le réseau entend la requête d’un client, il lui fera une proposition d’adresse et de 
paramètres réseau. Comme le client auquel le serveur d’adresse répond n’a pas encore d’adresse IP, cette réponse 
se fera également sous forme de broadcast. 

Les paquets envoyés pour la réponse du serveur portent le nom normalisé de DHCPOFFER. 

Acceptation de l’offre

Le client DHCP satisfait de l’offre qui lui a été faite, va l’accepter. À ce stade, cette réponse pourrait être envisagée 
en unicast puisque le client a déjà une proposition d’adresse IP et connaît celle du serveur. Toutefois, cet échange 
se  fera  encore  en  broadcast.  En  effet :  si  un  deuxième  serveur  DHCP  est  en  concurrence  avec  le  premier  pour 
fournir une adresse, ce broadcast d’acceptation envoyé à un autre serveur mais reçu par les deux prétendants fait 
office de fin de non­recevoir pour le serveur non choisi. 

Les paquets envoyés pour l’acceptation de l’offre du serveur portent le nom normalisé de DHCPREQUEST. 

Accusé de réception du serveur

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Enfin,  le  serveur  prend  acte  de  l’affectation  de  l’adresse,  et  clos  la  transaction  par  un  accusé  de  réception.  Le 
serveur profite de ce dernier échange pour annoncer la durée de l’allocation de l’adresse. On appelle cette durée le 
bail DHCP, et sa durée varie selon la configuration du serveur entre quelques heures et quelques jours. 

Les paquets envoyés pour accusé de réception portent le nom normalisé de DHCPACK. 

b. Le service DHCP sur les systèmes Linux 

Le service DHCP le plus répandu sur les systèmes Linux est le service DHCP de l’ISC (Internet System Consortium). 
L’ISC  est  un  organisme  créé  en  1994  pour  veiller  au  développement  et  à  la  pérennité  du  serveur  DNS  BIND, 
développement  émanant  à  l’origine  de  l’université  de  Berkeley.  ISC  DHCP  est  un  développement  original  de  l’ISC 
pour fournir une implémentation de référence de ce protocole. 

Le  service  est  lancé  par  un  script  normalisé  dans  /etc/init.d.  Son  nom  varie  selon  les  distributions  et 
implémentations. 

2. Configuration du serveur 

L’essentiel de la configuration d’un serveur DHCP ISC se trouve dans le fichier /etc/dhcpd.conf. 
On y trouvera les directives de fonctionnement, les options générales du serveur, et la déclaration des ressources à 
allouer. Chacune des lignes de paramètres devra se terminer par un point virgule. 

a. Le fonctionnement général du serveur 

Directives principales de comportement du serveur dans dhcpd.conf. 

default-lease-time durée;
authoritative;
log-facility niveau;

dhcpd.conf : comportement du serveur 

default­lease­time durée  Indique la durée du bail DHCP en secondes. 

authoritative  Facultatif. Un client qui demande le renouvellement d’une adresse hors 
plage doit y renoncer. 

log­facility cible  Gestion des journaux : renvoie les événements vers le "facility" cible du 
serveur syslog. 

b. Les paramètres transmis aux clients 

On  peut  dans  le  fichier  de  configuration  définir  des  paramètres  fonctionnels  qui  seront  transmis  aux  clients.  Ces 
paramètres sont annoncés par la directive option. 

Déclaration d’options dans le fichier dhcpd.conf 

option domain-name suffixe;


option domain-name-servers serveurs_dns;
option nis-domain domaine_nis;
option nis-servers serveurs-nis;

dhcpd.conf : déclaration d’options 

suffixe  Suffixe DNS pour les clients. 

serveur_dns  Serveur DNS utilisé par les clients. Si plusieurs serveurs doivent être proposés, les 
valeurs sont séparées par des virgules. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


domaine_nis  En voie de raréfaction. Domaine NIS pour les clients. 

serveurs_nis  En voie de raréfaction. Serveur NIS utilisé par les clients. Si plusieurs serveurs 
doivent être proposés, les valeurs sont séparées par des virgules. 

c. Déclaration de plages d’adresses 

Les adresses à allouer sont définies dans une ou plusieurs sections  subnet du fichier  dhcpd.conf. Au sein de ces 


sections,  on  trouvera  en  plus  des  plages  d’adresses  les  options  DHCP  qui  seront  envoyées  avec  les  propositions 
d’adresses.  Les  options  les  plus  courantes  sont  la  passerelle  par  défaut  à  utiliser  avec  l’adresse  proposée,  ainsi 
que les serveurs DNS à utiliser. Les options peuvent être déclarées en dehors ou au sein des sections subnet, elles 
concerneront alors selon le cas l’ensemble des adresses allouées ou seulement celles du sous­réseau. En cas de 
conflit entre options (la même option est déclarée dans la configuration générale et dans la section subnet), c’est 
l’option du subnet qui prévaut. 

Déclaration de subnet dans le fichier dhcpd.conf 

subnet reseau netmask masque {


range debut fin;
option routers routeur;

dhcpd.conf : déclaration de subnet 

reseau  L’adresse de réseau dans lequel se trouveront les adresses à attribuer. 

masque  Masque associé au réseau géré. 

debut  Définition de la plage des adresses qui seront proposées aux clients. La première 
adresse de la plage. 

fin  Définition de la plage des adresses qui seront proposées aux clients. La dernière adresse 
de la plage. 

routeur  La passerelle par défaut associée aux adresses proposées. 

d. Paramètres spécifiques à une machine 

Il  est  possible  d’affecter  spécifiquement  à  une  machine  des  options  particulières.  Cette  machine  fera  alors  l’objet 
d’une déclaration particulière avec la directive host, un peu comme on configurerait un subnet à une seule adresse. 

On pourra utiliser cette méthode pour affecter spécifiquement à un hôte du réseau une adresse IP fixe pour une 
machine  qui,  bien  que  client  DHCP,  devrait  systématiquement  utiliser  la  même  adresse.  On  peut  par  exemple 
imaginer  une  imprimante  réseau  dont  l’interface  de  configuration  peu  confortable  encourage  à  la  laisser  en 
configuration dynamique, et pour laquelle la réservation dhcp garantirait l’attribution de l’adresse voulue. 

Réservation d’adresse dans dhcpd.conf 

host machine {
hardware ethernet adresse-mac;
fixed-address adresse_ip;
option routers routeur;
option domain-name suffixe;
option domain-name-servers serveur_dns;
}

dhcpd.conf : configuration d’hôte 

machine  Déclaration de paramètres pour un hôte. Si l’identification par adresse mac est 
utilisée, le nom machine est sans importance. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


adresse­mac  L’adresse MAC de l’hôte à configurer. 

adresse_ip  Adresse IP de l’hôte en cours de configuration. 

e. Serveur à plusieurs interfaces 

Les  serveurs  DHCP  possédant  plusieurs  interfaces  réseau  doivent  restreindre  leurs  communications  aux  seules 
cartes  compétentes.  Par  exemple,  si  un  serveur  possède  une  interface  configurée  en  10.11.12.1  et  une  autre  en 
192.168.200.1, et qu’il propose des adresses dans le subnet 192.168.200.0, il est évident qu’il ne doit écouter les 
requêtes et proposer des adresses que sur l’interface correspondante (192.168.200.1). La difficulté vient de ce que 
cet élément de configuration ne se trouve pas dans /etc/dhcpd.conf mais dans /etc/defaults/dhcp3­server. 

f. Visualisation des baux dhcp 

Le serveur DHCP conserve une information sur chacun des baux alloués dans un fichier  dhcpd.leases se trouvant 
dans le répertoire /var/lib/dhcp/. 
Ce fichier est accessible à la consultation mais ne devrait pas être modifié. 

Exemple de fichier dhcpd.leases 

Notez les horaires de renouvellement et d’expiration du bail DHCP. 

lease {
interface "eth0";
fixed-address 192.168.1.51;
option subnet-mask 255.255.255.0;
option routers 192.168.1.254;
option dhcp-lease-time 864000;
option dhcp-message-type 5;
option domain-name-servers 194.2.0.20,194.2.0.50;
option dhcp-server-identifier 192.168.1.1;
renew 6 2010/07/10 14:55:34;
rebind 3 2010/07/14 14:33:58;
expire 4 2010/07/15 20:33:58;
}

3. Configuration du client 

La commande dhclient permet aux stations clientes d’effectuer les requêtes DHCP. Si la commande n’est pas lancée 
manuellement  par  un  administrateur,  elle  est  appelée  par  les  scripts  d’initialisation  réseau.  Si  la  station  client  ne 
possède pas d’adresse IP, elle effectue toutes les étapes de la procédure de requête DHCP. Dans le cas contraire, 
elle demande au serveur un renouvellement de bail.  dhclient peut également être utilisée pour libérer une adresse 
affectée précédemment par un serveur DHCP. 

Exemple d’utilisation de dhclient pour requérir une adresse 

Notez les étapes de l’affectation d’adresse DHCPDISCOVER, DHCPOFFER, DHCPREQUEST et DHCPACK. 

root@serveur# dhclient eth1


Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:22:68:98:8a:da
Sending on LPF/eth1/00:22:68:98:8a:da
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 172.18.142.243 from 172.18.142.225
DHCPREQUEST of 172.18.142.243 on eth1 to 255.255.255.255 port 67

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


DHCPACK of 172.18.142.243 from 172.18.142.225
bound to 172.18.142.243 -- renewal in 49 seconds.
root@serveur#

Exemple de libération d’adresse IP 

On constate un paquet DHCPRELEASE envoyé à l’exécution de la commande. 

root@serveur# dhclient -r eth1


There is already a pid file /var/run/dhclient.pid with pid 2735
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth1/00:22:68:98:8a:da
Sending on LPF/eth1/00:22:68:98:8a:da
Sending on Socket/fallback
DHCPRELEASE on eth1 to 172.18.142.225 port 67
root@serveur#

4. Agent relais DHCP 

Les  échanges  DHCP  se  faisant  par  broadcast  et  les  broadcasts  ne  passant  pas  les  routeurs,  les  requêtes  DHCP 
comme  les  réponses  des  serveurs  n’ont  aucune  action  en  dehors  du  réseau  local.  La  solution  simple  consiste 
évidemment à mettre un serveur DHCP sur chacun des segments où ils sont nécessaires. Toutefois, si on ne souhaite 
utiliser qu’un seul serveur pour plusieurs réseaux, il existe une solution : les agents relais DHCP. 

a. Principe du relais DHCP 

L’intégralité  de  la  configuration  DHCP,  comprenant  la  déclaration  de  tous  les  subnets  et  toutes  les  plages 
d’adresses,  locaux  ou  distant,  se  trouvera  sur  un  serveur  DHCP  unique.  Une  partie  des  clients  en  revanche  se 
trouvera sur un segment ethernet différent. Pour que les communications puissent s’établir entre les clients distants 
et  le  serveur,  l’agent  relais  DHCP  qui  se  trouvera  lui  aussi  sur  le  segment  devra  traiter  les  broadcasts  reçus,  et 
relayer  la  requête  sous  forme  d’unicast  vers  le  serveur  DHCP.  Les  unicasts  pouvant  passer  les  routeurs, 
l’information  arrivera  à  bon  port.  Le  serveur  DHCP  répondra  alors  sous  forme  d’unicast  à  destination  de  l’agent 
relais, et l’agent relais enverra un broadcast qui sera récupéré par la station cliente. 

Le client DHCP n’a pas conscience de traiter avec un agent relais, mais pense qu’un serveur DHCP réel est présent 
sur son segment. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


 

b. Configuration de l’agent de relais 

L’agent  de  relais  est  lancé  de  façon  interactive  par  la  commande  dhcrelay.  Sur  la  plupart  des  distributions,  cette 
commande  est  appelée  depuis  un  script  de  lancement  de  service,  et  ses  paramètres  de  fonctionnement  sont  lus 
dans un fichier de configuration. 

Syntaxe de la commande dhcrelay 

dhcrelay -i interface adresse_serveur

dhcrelay : options et paramètres 

­i interface  Facultatif. Spécifie l’interface par laquelle l’agent de relais sera à l’écoute du serveur 
DHCP et des requêtes des clients. 

adresse_serveur  L’adresse IP du serveur auquel transmettre les requêtes DHCP. 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Évolution de l’authentification 

1. Les premiers systèmes Unix et le fichier passwd 

a. Mots de passe dans le fichier /etc/passwd 

Depuis le début de leur existence, les systèmes Unix utilisent le fichier  /etc/passwd comme base de comptes des 
utilisateurs.  Ce  fichier  est  utilisé  naturellement  pour  les  ouvertures  de  session  sur  le  système.  Comme  son  nom 
l’indique  encore,  il  contenait  en  plus  des  identifiants  utilisateurs  leurs  mots  de  passe  cryptés.  Si  des  éléments 
logiciels  autres  que  l’ouverture  de  session  ont  besoin  des  informations  de  compte  (connexion  ftp,  ouverture  de 
session distante, etc.), ils vont également consulter ce fichier. Dans cette situation originelle simple, on a affaire à 
une  base  de  compte  unique  et  des  applications  multiples  qui  exploitent  cette  base  de  compte.  Toutes  les 
applications doivent reconnaître le format de cette base d’information. 

b. Mots de passe dans le fichier /etc/shadow 

Avec l’évolution des techniques d’attaques des mots de passe, le besoin est venu de placer les mots de passe dans 
un  fichier  non  accessible  aux  utilisateurs  ordinaires.  Ils  sont  alors  stockés  dans  un  fichier /etc/shadow  fermé  aux 
utilisateurs.  Les  paramètres  d’authentification  avec  shadow  sont  gérés  par  un  fichier  /etc/login.defs.  Les 
paramètres présents par défaut dans ce fichier sont en général satisfaisants. 

Gestion des erreurs d’authentification dans le fichier login.defs 

Parmi les nombreux paramètres du fichier login.defs, ceux concernant le login sont les plus fréquemment modifiés. 

toto@ubuntu:~$ grep LOGIN /etc/login.defs


LOGIN_RETRIES 5
LOGIN_TIMEOUT 60
toto@ubuntu:~$

2. D’autres bases d’informations 

Pour la consultation des éléments d’identification, la situation s’est compliquée quand il a fallu intégrer d’autres bases 
de comptes, différentes du fichier passwd et surtout plus complexes. Ces bases d’identités sont souvent centralisées, 
comme c’est le cas pour NIS (Network Information Server) ou LDAP (Leightweight Directory Access Protocol). La première 
solution  envisagée  fut  naturellement  de  réécrire  les  programmes  qui  exploitaient  initialement  le  fichier /etc/passwd 
afin qu’ils soient capables de consulter les bases centralisées sur le réseau. Cette méthode manquait cruellement de 
souplesse,  puisqu’elle  obligeait  à  reprendre  beaucoup  de  programmes  en  profondeur  à  chaque  fois  qu’une 
modification était apportée au mode de stockage des bases centralisées. 

3. NSS 

NSS (Name Service Switch) est une première réponse à la multiplicité des bases d’information locales ou centralisées. 
NSS a pour objet de normaliser la résolution de nom au sein d’un système. NSS permet de résoudre un nom en une 
autre  information  associée,  comme  par  exemple  un  nom  d’utilisateur  et  son  uid,  un  nom  de  groupe  et  son  gid,  ou 
encore un nom d’hôte et son adresse IP. 

Dans un fonctionnement NSS, un fichier /etc/nsswitch.conf détermine pour différents types de résolutions la source 
d’information à privilégier, et les applications ayant besoin de ces informations vont consulter les sources dans l’ordre 
imposé  par  le  fichier  nsswitch.conf.  La  résolution  s’appuie  alors  sur  des  bibliothèques  NSS  (libnss_X.so  où  X 
représente le service de résolution employé), et les applications n’ont pas besoin de connaître directement la méthode 
de résolution employée. 

Format du fichier nsswitch.conf 

résolution: source_1 source_n

nsswitch.conf : format du fichier 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


résolution  Le type de résolution à effectuer. 

source_1  Obligatoire. La première source de résolution à employer. 

source_n  Facultatif. La ou les autres sources de résolution possibles à utiliser après la première. 

Exemple de fichier nsswitch.conf 

On voit dans cet exemple que les résolutions de type passwd, group et shadow feront leur résolution grâce à la bibliothèque 
libnss_compat.so, alors que la résolution de noms d’hôtes se fera par les bibliothèques libnss_files.so et libnss_dns.so. Ce 
qui veut dire que les éléments d’identification des utilisateurs seront  trouvés dans les fichiers locaux de /etc, alors que la 
résolution de noms d’hôtes s’appuiera d’abord sur le fichier local (/etc/hosts) avant de se reporter sur un service dns. 

passwd: compat
group: compat
shadow: compat

hosts: files dns


networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

Sur  un  système  Linux  moderne,  NSS  n’est  plus  utilisé  que  pour  des  opérations  d’identification,  c’est­à­dire 
trouver des informations sur une identité. Tout ce qui relève de l’authentification est dévolu à un mécanisme 
plus élaboré : PAM. 

4. Modules d’authentification 

Si  NSS  représente  déjà  un  progrès  par  rapport  aux  fichiers  statiques  utilisés  dans  les  premiers  temps,  la  révolution 
viendra  avec  PAM  (Pluggable  Authentication  Module).  PAM  est  un  mécanisme  complémentaire  de  NSS  qui  assure  une 
authentification sur mesure par l’exécution de modules au choix de l’administrateur. 
Lors  d’une  ouverture  de  session  Linux,  l’utilisateur  va  présenter  un  identifiant  et  un  mot  de  passe.  Grâce  à  la 
résolution NSS, on en déduira les identifiants uid/gid, ainsi que les autres paramètres nécessaires (date d’expiration, 
etc.).  PAM  de  son  côté  va  en  fonction  de  sa  configuration  exécuter  des  modules  pour  assurer  l’authentification mais 
aussi éventuellement pour effectuer certaines tâches liées à l’ouverture de session, comme la définition de variables 
par exemple. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


PAM 

1. Le principe 

PAM se positionne en interface entre les applications et les méthodes d’authentification. 

Le  principal  objectif  de  PAM  est  de  proposer  une  couche  d’abstraction  entre  les  applications  et  les  méthodes 
d’authentification. Ainsi, une application qui se veut souple et évolutive quant aux méthodes d’authentification qu’elle 
emploie n’aura d’autre besoin que d’être compatible avec PAM. Cela signifie qu’elle devra être capable de s’adresser à 
la couche d’authentification PAM, et le reste ne la regarde pas. En parallèle, les procédés d’authentification quels qu’ils 
soient, doivent être exploitables par la mécanique PAM. 
Une application demande à PAM si un utilisateur peut se connecter. PAM en fonction de sa configuration, appelle des 
modules fonctionnels qui vont exploiter une méthode d’authentification. Si le résultat est positif (l’utilisateur  a  fourni 
les bons éléments d’authentification), PAM renvoie l’autorisation de connexion à l’application. 
PAM  a  un  autre  avantage.  Nous  venons  de  voir  que  la  demande  d’authentification  entrainait  le  chargement  de 
modules. Il se trouve que le nombre de ces modules n’est pas limité et qu’ils peuvent être cumulés. Il est donc tout à 
fait possible de demander une double authentification selon deux méthodes différentes. De plus, on peut profiter de la 
séquence  d’authentification  sous  PAM  pour  provoquer  le  chargement  de  bibliothèques  sans  rapport  avec 
l’authentification. De nombreuses actions peuvent donc être gérées dès l’authentification réussie. 
En  résumé  :  lors  de  la  demande  d’authentification,  des  modules  PAM  sont  chargés  en  fonction  d’un  fichier  de 
configuration, et ces modules provoquent certaines actions, relevant de l’authentification proprement dite ou d’autres 
actions. 

2. Les modules PAM 

a. Les principaux modules PAM 

Les modules PAM, appelés lors des opérations d’authentification sont nombreux et d’usages variés. Certains d’entre 
eux  sont  néanmoins  rencontrés  très  fréquemment  et  leur  existence  est  à  connaître.  D’autres  sont  plus  ou  moins 
fréquents selon les distributions, mais connaître leur fonctionnement et leurs objectifs permet de mieux comprendre 
la mécanique et la philosophie de PAM. 

Ces modules sont dans des fichiers dont l’emplacement normalisé est /lib/security. 

Principaux modules PAM 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


pam_securetty.so  Interdit le login par le compte root excepté sur les terminaux listés 
dans /etc/securetty. 

pam_nologin.so  Si le fichier /etc/nologin existe, affiche son contenu à toute tentative d’ouverture de 
session et interdit le login à tout autre que root. 

pam_env.so  Déclare des variables d’environnement lues dans /etc/environnement ou dans le 
fichier donné en référence par le paramètre « envfile= ». 

pam_unix.so  Permet l’authentification par la méthode traditionnelle des fichiers /etc/passwd 
et /etc/shadow. 

pam_deny.so  Voie de garage. Est généralement exécuté si aucun autre module n’est exécuté avec 
succès.  

pam_permit.so  Renvoie un retour positif inconditionnellement. 

pam_limits.so  Affecte certaines limitations fonctionnelles à des utilisateurs ou des groupes en 
fonction des données du fichier /etc/security/limits.conf. 

pam_cracklib.so  S’assure que le mot de passe employé présente un niveau de sécurité suffisant. 

pam_selinux.so  Si selinux est activé sur le système, ce module va s’assurer que le shell sera bien 
exécuté dans le contexte de sécurité adéquat. 

pam_lastlog.so  Affiche les informations sur la dernière ouverture de session réussie. 

pam_mail.so  Vérifie la présence de nouveaux mails pour un utilisateur (messagerie interne). 

b. Fonctionnement en piles de modules 

Pour  une  action  donnée,  l’authentification  par  exemple,  plusieurs  modules  PAM  peuvent  être  appelés.  On  dit  alors 
qu’on a affaire à une pile de module PAM. Le fonctionnement en pile est un des apports majeurs des services PAM. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


3. Configuration de PAM 

a. Structure des fichiers de configuration 

Les premières versions de PAM trouvaient leur configuration dans un fichier /etc/pam.conf. La grande complexité de 
PAM  a  rapidement  rendu  nécessaire  une  structure  plus  modulaire  pour  les  éléments  de  configuration.  La  quasi­
totalité  des  implémentations  actuelles  exploite  donc  un  répertoire  /etc/pam.d  contenant  autant  de  fichiers  que 
d’applications exploitant PAM. Si le répertoire /etc/pam.d existe, le fichier /etc/pam.conf n’est pas consulté. 
Chaque  application  s’appuyant  sur  PAM  aura  besoin  d’un  fichier  (en  général  du  même  nom  que  l’application)  qui 
contiendra sa configuration PAM. 

Format d’un fichier de /etc/pam.d 

Le  fichier  contiendra  autant  de  lignes  qu’on  souhaite  appeler  de  modules  avec  pour  chaque  ligne  la  structure 
suivante : 

type contrôle module arguments

Fichier de pam.d : format standard 

type  Représente le type d’action qui nécessite le recours à PAM. Les quatre valeurs possibles 
sont : auth, account, password et session. 

contrôle  Indique comment le module doit réagir au succès ou à l’échec de son exécution. Les 
valeurs courantes sont required, requisite, sufficient et optional. 

module  Le nom du module appelé. Le format normalisé est : pam_service.so. Où service 
représente le nom courant du module. 

arguments  Paramètres optionnels envoyés au module pour modifier son fonctionnement. 

Les  valeurs  possibles  de  type  et  de  contrôle  seront  expliquées  plus  loin,  mais  nous  avons  déjà  la  possibilité  de 
comprendre la structure du fichier de configuration. Dans l’extrait ci­dessous, on voit que la ligne ne concerne que les 
opérations d’authentification (auth), que l’exécution du module est obligatoire (required), que le module exploite la 
méthode d’authentification traditionnelle unix, c’est­à­dire les fichiers passwd et shadow (pam_unix.so), et enfin que 
ce module doit accepter une authentification faite avec un mot de passe vide (nullok). Notez que le paramètre nullok 
est spécifique au module, et que chaque module supportera tous les paramètres voulus par son développeur. 

Extrait d’un fichier de configuration pam pour l’application login 

Dans  cet  exemple,  il  est  question  d’authentification  (auth),  l’exécution  du  module  est  obligatoire  (required),  le  module 
exploite  le  fichier  des  mots  de  passe  historique  (pam_unix.so).  Enfin,  l’utilisation d’un  mot  de  passe  vide  est  autorisée 
comme indiqué par l’argument (nullok). 

auth required pam_unix.so nullok

b. Les types d’action de PAM 

Chaque ligne d’un fichier de configuration PAM doit commencer par l’un des quatre mots­clés qui détermine dans quel 
type d’action le module est compétent. 

● auth  :  l’activité  d’authentification  proprement  dite.  Les  modules  appelés  avec  l’action  auth  sont  exécutés 
pour ou pendant l’authentification. 

● account : accès à des informations des comptes autres que les éléments d’authentifications proprement dits. 

● session : actions à réaliser avant ou après l’ouverture de session. 

● password : gestion des mots de passe. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Extrait du fichier de configuration pam pour l’application login 

Cet exemple, extrait très allégé d’un fichier login standard illustre bien le concept de pile aussi bien que la nature modulaire 
de PAM. 

On y trouve d’abord deux modules appelés pour l’authentification : pam_securetty profite de l’authentification pour vérifier 
que  le  compte  n’est  pas  celui  du  superutilisateur,  et  pam_unix,  qui  réalise  l’authentification  proprement  dite  à  partir  du 
fichier /etc/passwd. 

Le  même  module  pam_unix  est  aussi  déclaré  sous  le  type  account.  Si  des  applications  compatibles  PAM  ont  besoin 
d’informations sur des comptes d’utilisateurs, elles auront besoin du module pam_unix sous le type account. 

Le  module  pam_env  est  appelé  sous  le  type  session,  cela  assure  son  exécution  (et  donc  la  déclaration  de  variables)  au 
sein de la session utilisateur. 

Le module pam_cracklib est appelé sous le type password. Si une application de gestion de mots de passe compatible PAM 
souhaite modifier un mot de passe, elle devra en passer par le contrôle de complexité effectué par le module cracklib. 

auth required pam_securetty.so


auth required pam_unix.so
account required pam_unix.so
session required pam_env.so readenv=1 envfile=/etc/default/locale
password required pam_cracklib.so retry=3 minlen=6

c. Les comportements des modules 

Les modules vont être appelés avec un « control_flag » (marqueur de contrôle) qui va déterminer le comportement 
sur échec ou réussite du module. 
Cet élément obligatoire est le deuxième champ sur la ligne de configuration. 

● required  :  le  module  doit  obligatoirement  renvoyer  un  succès.  Si  un  module  d’authentification  est  required, 
son échec empêche l’ouverture de session. Les autres modules de la pile sont néanmoins exécutés. 

● requisite : le module doit obligatoirement renvoyer un succès. Si un module d’authentification est requisite, 
son échec empêche le l’ouverture de session. Les autres modules de la pile ne sont pas exécutés. 

● sufficient  :  si  le  module  est  exécuté  avec  succès  et  si  aucun  module  required  ou  requisite  n’a  échoué,  les 
autres modules de la pile sont ignorés. 

● optional : le module peut réussir ou échouer sans influencer le reste de la pile. C’est­à­dire que si un module 
optional échoue, et qu’un module required de la même pile réussit, alors le résultat global de l’exécution de 
la pile est positif. 

Exemples de fichiers de configuration PAM 

Observons ici deux fichiers PAM, l’un gdm gérant l’ouverture de session graphique sous environnement Gnome, et l’autre 
gdm­autologin  assurant  l’ouverture  automatique  sans  mot  de  passe  de  la  session  graphique.  Les  différences  entre  ces 
deux  modes  de  fonctionnement  portant  sur  l’authentification  de  l’utilisateur,  nous  ne  nous  intéresserons  dans  cet 
exemple qu’aux modules déclarés sous le type auth. 

Les premiers modules chargés, pam_nologin et pam_env sont communs aux deux fichiers. Pour mémoire, pam_nologin 
interdit la connexion des utilisateurs ordinaires si le fichier /etc/nologin existe et a été renseigné par l’administrateur, et 
pam_env définit diverses variables au moment de l’authentification. 

Le  fichier  gdm  inclut  ensuite  le  sous­fichier  common­auth  qui  va  appeler  les  éléments  d’authentification  voulus  sur  ce 
système  (au  minimum  pam_unix  pour  l’authentification  traditionnelle),  puis  charge  le  module  pam_gnome_keyring  qui 
permettra  à  des  utilisateurs  dûment  authentifiés  sous  Gnome  d’accéder  à  certaines  fonctionnalités  qui  nécessiteraient 
normalement une réauthentification. 

Le fichier gdm­autologin en revanche ne charge plus qu’un module : pam_permit qui renvoie un résultat positif dans tous 
les  cas,  dont  l’exécution  est  obligatoire  (le  module  est  required),  et  qui  va  donc  autoriser  l’ouverture  de  session 
inconditionnellement. 

Le fichier de configuration pam pour l’ouverture de session manuelle Gnome : gdm 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth optional pam_gnome_keyring.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_gnome_keyring.so auto_start
@include common-password

Le fichier de configuration pam pour l’ouverture de session automatique Gnome : gdm­autologin 

auth requisite pam_nologin.so


auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
auth required pam_permit.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
@include common-password

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


LDAP 

1. Généralités 

a. Les annuaires 

En  1990,  l’ITU  (International  Telecommunication  Union)  propose  une  norme  de  structuration  des  annuaires 
électroniques. Cette norme, visant à proposer à tous les développeurs qui y souscrivent un cadre de fonctionnement 
et de référencement commun porte le nom de X500. 
Les premiers logiciels à exploiter cette norme furent naturellement les messageries électroniques. La NDS (Netware 
Directory  Services)  célèbre  en  son  temps,  fut  le  premier  usage  marquant  des  technologies  d’annuaires  X500  au 
service  d’un  système  d’exploitation  réseau.  Les  annuaires  sont  aujourd’hui  largement  répandus,  soit  au  sein  du 
système d’exploitation réseau (l’Active Directory de Microsoft), soit sous forme d’annuaire « neutre », à la disposition 
d’autres applications. On parle alors d’annuaires « pages blanches ». 

b. Structure et terminologie 

Les  annuaires  électroniques  X500  présentent  des  caractéristiques  de  structure  communes.  Les  annuaires  sont 
hiérarchisés, et ont forcément un point d’origine généralement appelé Root. Tout élément de l’annuaire est appelé 
objet ;  certains  éléments  sont  structurants  et  d’autres  strictement  informatifs.  Les  éléments  structurants  sont 
appelés conteneurs et sont de types divers comme l’organisation, le domaine ou encore l’unité organisationnelle. 

Tout objet de l’annuaire renferme en son sein des informations de formats divers. Ces informations sont appelées 
attributs de l’objet. 

c. Schéma 

Les annuaires sont à l’origine prévus pour stocker et gérer des identités, et on y trouvera naturellement des objets 
représentant  des  personnes,  et  des  attributs  permettant  d’identifier  et  de  définir  la  personne,  comme  le  nom,  le 
prénom, le téléphone et l’adresse de messagerie. L’ensemble des types d’objets possibles dans l’annuaire, et pour 
chaque objet l’ensemble des attributs utilisables est défini dans le schéma de l’annuaire. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Toutefois, il est naturel pour un éditeur ou un utilisateur de vouloir stocker dans son annuaire des informations de 
nature  particulière  pour  les  besoins  propres  de  ses  applications.  Si  le  schéma  d’origine  ne  le  permet  pas,  on  peut 
alors  réaliser  une  extension  de  schéma.  L’extension  de  schéma  consiste  à  définir  pour  un  annuaire  de  nouveaux 
types d’objets, ou de nouveaux attributs pour un type d’objet existant. Par exemple, si une entreprise dispose d’un 
annuaire recensant l’ensemble de son personnel, et que ledit personnel doit porter des chaussures de sécurité, on 
aura intérêt à étendre le schéma pour ajouter aux objets utilisateur l’attribut « pointure » plutôt que de gérer une 
liste plus ou moins à jour sur un tableur. 

Le type de chaque objet (unité organisationnelle, utilisateur, groupe, etc.) est appelé classe. Une classe d’objets se 
définit par l’ensemble des attributs qui la compose. Parmi ces attributs, un aura une importance particulière dans la 
dénomination de l’objet, c’est le CN (Common Name). 

d. Le protocole LDAP 

La norme X500 ne prévoyant pas à l’origine de protocole d’interrogation des annuaires, une proposition de protocole 
a été faite en 1993 par l’université du Michigan pour un créer un protocole qui, fonctionnant sur TCP/IP, assurerait 
des requêtes simples à un annuaire X500 : c’était la naissance de LDAP (Leightweight Directory Access Protocol). Les 
annuaires  X500  en  place  durent  donc  implémenter  une  couche  serveur  pour  le  protocole  LDAP  afin  de  pouvoir 
répondre aux requêtes des clients exploitant ce nouveau protocole. 

Rapidement,  le  succès  du  protocole  LDAP  fut  tel  qu’on  oublia  le  rôle  fondateur  de  X500  pour  ne  plus  parler  que 
d’annuaires LDAP. Et on parle aujourd’hui d’annuaire LDAP pour tout annuaire capable de répondre à des requêtes 
LDAP. Les éléments de structure et de dénominations X500 ont néanmoins perduré et on parle toujours d’objets, de 
conteneurs et de schéma. 

e. Désignation des objets 

Nous  avons  vu  que  les  objets  de  l’annuaire  s’inséraient  dans  une  arborescence.  Pour  une  désignation  sans 
ambiguïté  des  objets  dans  un  annuaire,  il  existe  une  notation  formelle  qui  reprend  la  position  de  l’objet  dans 
l’arborescence de l’annuaire, ainsi que son type. Cette notation est le DN (Distinguished Name). 

Format type d’un nom distinctif 

classe1=nom_objet1,classe2=nom_objet2,...,classen=nom_objetn

Où  les  paramètres  classex  représentent  la  classe  de  l’objet  décrit  (cn,  ou,  uid,  etc.),  et  les  paramètres  objetsx 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


représentent les noms des objets décrits. 
Le  nom  distinctif  reprend  toute  l’arborescence  de  l’objet  référencé  jusqu’à  la  racine  de  l’annuaire,  chaque 
changement  de  niveau  étant  représenté  par  des  virgules.  Pour  chaque  objet  cité,  la  classe  de  cet  objet  est 
obligatoirement mentionnée. 

Le  nom  distinctif  sera  employé  pour  désigner  un  objet  de  l’annuaire,  et  son  utilisation  sera  obligatoire  pour  les 
opérations d’authentification. 

f. Authentification auprès d’un annuaire LDAP 

Les annuaires gèrent leur propre sécurité. Si souvent les requêtes anonymes sont autorisées pour des consultations 
en lecture, il faudra s’authentifier auprès de l’annuaire pour les opérations d’écriture. Cette authentification se fait en 
fournissant  le  nom  distinctif  et  le  mot  de  passe  d’un  compte  de  l’annuaire  ayant  les  droits  nécessaires  sur  les 
éléments à gérer. En terminologie LDAP, on parle de « bind » (liaison) pour l’authentification. 

g. Le format LDIF 

LDIF (LDAP Data Interchange Format ­ Format d’échange des données LDAP) a pour objet de permettre l’exportation ou 
l’importation des données depuis ou vers un annuaire LDAP. LDIF décrit un format de fichier texte qui contient tout 
ou  partie  des  données  d’un  annuaire  LDAP.  On  peut  y  mentionner  l’intégralité  des  objets  et  de  leurs  attributs,  ou 
seulement une sélection. Le format LDIF est employé par de nombreux utilitaires LDAP. 

Format type d’une entrée de fichier LDIF 

dn: nom_distinctif
attribut1: valeur1
attribut2: valeur2
...
attributn: valeurn

Il est tentant de considérer LDIF comme un format privilégié pour échanger des données d’un annuaire vers 
un autre, en cas de migration ou d’échanges de données. En fait, les fichiers LDIF décrivent les objets d’un 
annuaire  conformément  à  son  schéma,  et  il  est  bien  rare  que  deux  annuaires  différents  présentent 
rigoureusement le même schéma. Pour ces raisons, le format LDIF n’est en général utilisé que pour manipuler les 
données d’un  même  annuaire,  dans  le  cas  d’une  sauvegarde  par  exemple.  Les  solutions  de  méta­annuaires qui 
permettent ce type de synchronisation exploitent généralement un format plus ouvert comme le format XML. 

2. Le serveur OpenLDAP 

OpenLDAP est l’implémentation de serveur LDAP open source la plus courante sur les systèmes Linux. Si elle manque 
cruellement de convivialité par rapport à ses équivalents commerciaux, elle n’en est pas moins répandue dans toutes 
sortes  d’implémentation  qui  vont  de  la  centralisation  de  l’authentification  à  la  gestion  de  comptes  et  carnets 
d’adresses pour les messageries. 

a. Gestion du Service 

Le service openldap est géré par un script normalisé dans le répertoire /etc/init.d. Son nom est variable et dépend 
de la distribution. L’ambiguïté vient du fait que le protocole applicatif est LDAP, alors que le nom de l’exécutable est 
slapd et le nom du produit applicatif openldap. 

b. Configuration 

Dans un fonctionnement standard, la configuration initiale ne représente pas un travail considérable. Il s’agit surtout 
d’avoir  un  contexte  de  base  :  une  sorte  de  point  de  départ  de  l’arborescence  dans  lequel  se  trouveront  tous  les 
objets  créés  dans  l’annuaire.  La  configuration  se  trouve  dans  un  fichier  slapd.conf,  généralement  situé  dans  le 
répertoire  /etc/ldap  ou  /etc/openldap.  Ce  fichier  comprend  aussi  la  déclaration  de  l’administrateur  de  l’annuaire 
ainsi que son mot de passe. 

Déclaration du contexte de base dans le fichier slapd.conf 

suffix "dc=domaine"

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Où  domaine  représente  le  contexte  principal  de  l’arborescence.  Cette  valeur  est  fréquemment  renseignée  lors  de 
l’installation par les scripts de post­installation des paquetages. Il est possible pour un annuaire openldap de gérer 
plusieurs arborescences. 

Déclaration du compte administrateur dans le fichier slapd.conf 

rootdn "cn=compte_admin,dc=domaine"

Où  compte_admin  représente  le  compte  administrateur  de  l’annuaire.  Attention,  contrairement  à  d’autres 
implémentations LDAP, il n’est pas obligatoire que le compte administrateur soit aussi un objet de l’annuaire. 

Déclaration du mot de passe administrateur dans le fichier slapd.conf 

rootpw {format_cryptage}mot_de_passe_crypté

Où  format_cryptage  représente  l’algorithme  de  hachage  utilisé  pour  crypter  le  mot  de  passe  (SHA1,  MD5,  crypt,  ou 
texte clair). 

Pour  simplifier  la  saisie  du  mot  de  passe,  la  commande  slappasswd  permet  de  générer  la  chaîne  de  caractères 
constituée du mode de cryptage et du mot de passe crypté, directement insérable dans slapd.conf. 

Exemple d’utilisation de la commande slappasswd 

La  commande  slappasswd  envoyant  son  résultat  sur  la  sortie  standard,  il  faut  ruser  un  peu  pour  l’intégrer  au  fichier 
slapd.conf. 

[root@beta openldap]# slappasswd -s motdepasse


{SSHA}oW6wu+yUpFnaB6tg+4cMWnAa8OmDXV62
[root@beta openldap]# echo "rootpw $(slappasswd -s motdepasse)" >> slapd.conf
[root@beta openldap]#

À ce stade, l’annuaire est fonctionnel après redémarrage du service, mais vide. Il reste à l’alimenter avec les clients 
LDAP. 

3. Les outils clients LDAP 

On  dispose  pour  Linux  d’outils  en  ligne  de  commande  permettant  de  réaliser  des  opérations  sur  les  serveurs  LDAP. 
Ces outils sont généralement fournis dans un paquetage applicatif appelé ldap­utils. Leur syntaxe peu engageante 
implique un petit temps d’adaptation pour les exploiter confortablement. 

a. Recherche d’informations avec ldapsearch 

Sans  doute  le  plus  couramment  utilisé  des  outils  clients  en  ligne  de  commande  LDAP.  La  commande  ldapsearch 
permet d’effectuer des requêtes sur un annuaire LDAP et de récupérer le résultat au format LDIF. 
Le  cas  le  plus  simple  consiste  à  demander  localement  (directement  sur  le  serveur)  l’export  total  de  toutes  les 
informations d’un annuaire et on utilise souvent cette possibilité pour vérifier la présence d’un objet ou simplement 
que l’annuaire répond bien aux requêtes. 

Syntaxe de la commande ldapsearch pour exporter toutes les informations publiques d’un annuaire 

ldapsearch -x -b contexte

Export avec ldapsearch : options et paramètres 

­x  Utilise une authentification simple (cas général). 

­b contexte  Réalise la recherche à partir du DN du conteneur contexte. 

Syntaxe de la commande ldapsearch pour récupérer des informations précises selon critères de recherche 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


ldapsearch -x -D dn_admin -W -h ip_serveur -b contexte -s sub attribut=valeur

Recherche avec ldapsearch : options et paramètres 

­D dn_admin  Fait l’authentification avec le nom distinctif dn_admin. 

­W  Demande interactivement le mot de passe. Peut être remplacé par ­w (minuscule) 
suivi du mot de passe en clair dans la ligne de commande. 

­h ip_serveur  S’adresse au serveur dont l’adresse est ip_serveur. 

­s sub  Réalise une recherche récursive dans tous les niveaux subordonnés au contexte de 
recherche. 

attribut  Le nom de l’attribut qui sera le critère de recherche. 

valeur  La valeur de l’attribut recherché. Le caractère « * » représente n’importe quelle 
valeur existante.  

Exemples de recherche avec ldapsearch 

On veut afficher tous les utilisateurs se trouvant dans l’annuaire dont le numéro de téléphone commence par 01. 

user@ubuntu:~$ ldapsearch -x -D cn=admin,dc=pas,dc=net -w password


-h 172.17.7.20 -b dc=pas,dc=net -s sub telephoneNumber=01*
# extended LDIF
#
# LDAPv3
# base <dc=pas,dc=net> with scope subtree
# filter: telephoneNumber=01*
# requesting: ALL
#

# toto, lyon, pas.net


dn: cn=toto,ou=lyon,dc=pas,dc=net
objectClass: person
cn: toto
sn: toto
telephoneNumber: 0123456789

# tutu, paris, pas.net


dn: cn=tutu,ou=paris,dc=pas,dc=net
objectClass: person
cn: tutu
sn: tutu
telephoneNumber: 0178945632

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

On  souhaite  maintenant  afficher  l’ensemble  des  utilisateurs  de  l’unité  organisationnelle  paris.  Notez  le  contexte  de 
recherche (­b ou =paris,dc=pas,dc=net) et le filtre de recherche qui vise à vérifier que l’attribut téléphone est renseigné.
(telephoneNumber=*). 

user@ubuntu:~$ ldapsearch -x -D cn=admin,dc=pas,dc=net -w password


-h 172.17.7.20 -b ou=paris,dc=pas,dc=net -s sub telephoneNumber=*
# extended LDIF
#
# LDAPv3
# base <ou=paris,dc=pas,dc=net> with scope subtree

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


# filter: telephoneNumber=*
# requesting: ALL
#

# tata, paris, pas.net


dn: cn=tata,ou=paris,dc=pas,dc=net
objectClass: person
cn: tata
sn: tata
telephoneNumber: 9876543210

# tutu, paris, pas.net


dn: cn=tutu,ou=paris,dc=pas,dc=net
objectClass: person
cn: tutu
sn: tutu
telephoneNumber: 0178945632

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Toutes les connexions aux serveurs LDAP sont effectuées avec l’option ­x indiquant une authentification en 
texte clair. Cela constitue naturellement un risque en matière de sécurité. La connexion avec authentification 
SASL permettrait de remédier à cette situation. Toutefois, sa complexité de mise en œ uvre et le fait que la plupart 
des consultations se font en mode anonyme font que l’authentification SASL est rarement utilisée. 

b. Ajout d’objets dans un annuaire avec ldapadd 

Pour l’essentiel,  la  commande ldapadd va lire le contenu d’un fichier LDIF contenant les données à modifier, et les 


ajouter à l’annuaire. La construction du fichier se doit d’être rigoureuse mais ne présente pas de difficulté. 

Syntaxe simplifiée de la commande ldapadd 

ldapadd -x -D dn_admin -W -h ip_serveur -f fichier_ldif

ldappadd : options et paramètres 

­x  Utilise une authentification simple (cas général). 

­D dn_admin  Fait l’authentification avec le nom distinctif dn_admin. 

­W  Demande interactivement le mot de passe. Peut être remplacé par ­w (minuscule) 
suivi du mot de passe en clair dans la ligne de commande. 

­h ip_serveur  S’adresse au serveur dont l’adresse est ip_serveur. 

­f fichier_ldif  Ajoute les objets référencés dans le fichier fichier_ldif. 

Exemple de fichier LDIF pour ajout par la commande ldapadd 

Appelons ce fichier toto.ldif 

dn: cn=toto,dc=pas,dc=net
objectClass: person
cn: toto
sn: toto
telephoneNumber: 0123456789

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Exemple d’utilisation de ldapadd 

root@serveur# ldapadd -D cn=admin,dc=pas,dc=net -W -h 192.168.1.10 -f toto.ldif


root@serveur#

c. Modification d’objet existant avec ldapmodify 

La  commande  ldapmodify  va  également  être  utilisée  avec  un  fichier  ldif  comme  argument,  et  ses  paramètres 
d’utilisation sont les mêmes que ceux de la commande ldapadd. 

Syntaxe simplifiée de la commande ldapmodify 

ldapmodify -D dn_admin -W -h ip_serveur -f fichier_ldif

Exemple de fichier LDIF pour ajout par la commande ldapmodify 

dn: cn=toto,dc=pas,dc=net
changetype: modify
replace: telephoneNumber
telephoneNumber: 9876543210

d. Suppression d’objet avec ldapdelete 

La commande ldapdelete peut s’employer directement sans passer par un fichier ldif. 

Exemple de suppression d’objet avec ldapdelete 

root@serveur# ldapdelete -D cn=admin,dc=pas,dc=net -w password -h


127.0.0.1 -x cn=toto,dc=pas,dc=net
root@serveur#

e. Modification de mot de passe avec ldappasswd 

La  commande  ldappasswd  permet  d’affecter  un  mot  de  passe  encrypté  à  un  objet  utilisateur  présent  dans 
l’annuaire. 

Syntaxe simplifiée de la commande ldappasswd 

ldappasswd -x -D dn_admin -W -h ip_serveur -s motdepasse dn_utilisateur

ldappasswd : options et paramètres 

­s motdepasse  Le mot de passe que l’on souhaite affecter au nouvel utilisateur. Peut être remplacé 
par ­S (majuscule) pour une frappe interactive du nouveau mot de passe. 

dn_utilisateur  Le nom distinctif de l’utilisateur dont il faut modifier le mot de passe. 

Exemple d’utilisation de la commande ldappasswd 

La  première  commande  affecte  le  mot  de  passe  à  l’utilisateur  tata.  Notez  l’usage  des  options  ­w  et  ­s  qui  permettent 
d’inclure les mots de passe (mot de passe d’authentification et mot de passe de l’utilisateur) directement dans la ligne de 
commande sans avoir à les taper de façon interactive. 

La deuxième commande provoque l’affichage de toutes les propriétés de l’utilisateur tata, et on voit bien le mot de passe 
crypté apparaître sous l’attribut userPassword. 

user@ubuntu:~$ ldappasswd -x -D cn=admin,dc=pas,dc=net -w password

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


-h 172.17.7.20 -s motdepasse cn=tata,ou=paris,dc=pas,dc=net
user@ubuntu:~$ ldapsearch -x -D cn=admin,dc=pas,dc=net -w password
-h 172.17.7.20 -s sub -b dc=pas,dc=net cn=tata
# extended LDIF
#
# LDAPv3
# base <dc=pas,dc=net> with scope subtree
# filter: cn=tata
# requesting: ALL
#

# tata, paris, pas.net


dn: cn=tata,ou=paris,dc=pas,dc=net
objectClass: person
cn: tata
sn: tata
telephoneNumber: 9876543210
userPassword:: e1NTSEF9RVpNNVV6RFN1M2xKbUgwZVhDTmpVWGhacEtSOTNxSFU=

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
user@ubuntu:~$

f. Allègement des syntaxes pour les utilitaires clients LDAP 

Chacun des utilitaires clients en lignes de commande peut trouver certains éléments de configuration dans le fichier 
ldap.conf.  La  syntaxe  des  commandes  en  sera  allégée  d’autant.  Son  emplacement  est 
généralement /etc/ldap/ldap.conf, mais il peut varier au gré des implémentations. 

Fichier ldap.conf courant 

BASE contexte
HOST ip_serveur

Fichier ldap.conf : principaux paramètres 

BASE contexte  Réalise les recherches à partir du DN du conteneur contexte. 

HOST ip_serveur  Les requêtes s’adressent au serveur dont l’adresse est ip_serveur. 

Il est également possible de déclarer le contexte de base LDAP par la variable LDAPBASE. Le renseignement 
du fichier ldap.conf constitue toutefois une méthode plus universelle. 

g. Clients graphiques 

Les applications compatibles LDAP intègrent un client leur permettant de réaliser des requêtes auprès de l’annuaire 
pour  assurer  leur  fonctionnement.  Par  exemple,  un  client  de  messagerie  est  en  général  capable  d’aller  vérifier  la 
validité d’un compte ou de faire une recherche auprès d’un annuaire LDAP. Toutefois, si on utilise un annuaire LDAP 
au service d’une application, il sera souvent pratique de disposer d’un outil graphique « universel », qui permettra de 
vérifier  le  bon  fonctionnement  de  l’annuaire  et  éventuellement  de  l’alimenter  indépendamment  de  l’application 
cliente. Ces outils sont assez nombreux et de qualités diverses. On peut citer luma, gq, lat. 

Exemple de visualisation depuis le client graphique luma 

- 8- © ENI Editions - All rights reserved - Sanisa HOUAMRI


 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 9-


Authentification par LDAP des systèmes Linux 
Nous considérons que nous disposons déjà d’un annuaire configuré et peuplé de comptes comme indiqué aux sections 
"Le serveur OpenLDAP" et "Les outils clients LDAP", avec les attributs nécessaires à l’authentification Linux. 

1. Configuration NSS 

L’authentification ne sera possible que si les informations des utilisateurs sont accessibles via NSS. 

a. Configuration de la bibliothèque NSS pour LDAP 

La  bibliothèque  NSS  responsable  de  l’interrogation  de  l’annuaire  doit  disposer  des  informations  nécessaires.  Pour 
cela,  il  faut  renseigner  le  fichier  de  configuration  LDAP  pour  la  bibliothèque  nss  ldap.  Ce  fichier  s’appelle 
généralement ldap.conf et est situé directement dans le répertoire /etc. 

Cette  configuration  nécessite  que  la  bibliothèque  NSS  soit  capable  de  gérer  les  informations  LDAP.  Cette 
fonctionnalité est généralement apportée par un paquet applicatif appelé libnss_ldap. 

Exemple de fichier /etc/dap.conf 

Ce fichier utilisé par NSS rappelle fortement celui utilisé par les clients LDAP. 

host 127.0.0.1
base dc=pas,dc=net
ldap_version 3
rootbinddn cn=admin,dc=pas,dc=net

b. Renseignement des sources de nom 

Le  fichier  /etc/nsswitch  doit  être  configuré  pour  référencer  LDAP  en  tant  que  source  d’information  prioritaire. 
Toutefois,  il  doit  pouvoir  continuer  de  fonctionner  avec  les  fichiers  locaux  pour  le  cas  où  l’annuaire  ne  serait  pas 
disponible. 

Modification du fichier nsswitch avec LDAP comme source de nom prioritaire 

passwd : ldap files


group: ldap files
shadow: ldap files

c. Vérification des sources de noms 

Il est souvent difficile de diagnostiquer les problèmes liés à l’authentification LDAP. En effet, le fonctionnement peut 
être  empêché  par  une  indisponibilité  de  l’annuaire,  des  comptes  utilisateurs  mal  créés,  ou  une  mauvaise 
configuration du client. L’utilitaire getent permet à ce stade de vérifier que le client est capable d’interroger l’annuaire 
LDAP et de récupérer les bonnes informations. 

Exemple de vérification des informations de compte avec getent 

La  configuration  d’une  authentification  LDAP  n’étant  pas  particulièrement  aisée,  cette  vérification  à  mi­parcours  est  la 
bienvenue. 

root@station:/etc$ getent passwd titi


titi:*:1101:1101:titi:/home/titi/bin/bash
root@station:/etc$

2. Configuration PAM 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


a. Identification des services nécessaires 

Selon les besoins, tout ou partie des services qui exploitent PAM doivent pouvoir s’appuyer sur une authentification 
LDAP. Par exemple, les applications login, su et ssh seulement pour des besoins administratifs, ou bien tout élément 
capable  de  demander  une  authentification.  Dans  le  principe  PAM,  il  faudrait  identifier  tous  les  éléments  de 
configuration  pour  chacune  des  applications  concernées,  et  modifier  leur  configuration  pour  qu’ils  exploitent  LDAP 
comme mécanisme d’authentification possible. 
Les distributions Linux modernes nous facilitent heureusement la tâche en concentrant dans des fichiers common­
action chez Debian ou system­auth chez Red Hat la configuration de toutes les applications partageant les mêmes 
modes  d’authentification.  Il  nous  suffira  donc  de  modifier  ces  fichiers  pour  modifier  le  mode  d’authentification  de 
toutes les applications courantes. 

b. Configuration des fichiers pam 

Les types d’action PAM  account et auth doivent être modifiés pour permettre l’authentification LDAP. Si on regarde 
leur  contenu  initial,  on  voit  qu’ils  configurent  le  module  pam_unix.so,  en  général  avec  le  contrôle  required  ou 
sufficient. La première règle est de ne pas toucher à cette configuration. En effet, même si on souhaite utiliser un 
annuaire LDAP pour les opérations d’authentification,  le  mécanisme  traditionnel  doit  absolument  être  conservé,  ne 
serait­ce  que  pour  permettre  une  authentification  locale  en  cas  de  défaillance  de  l’annuaire.  La  configuration 
reviendra donc à ajouter pour les actions account et auth une ligne indiquant comme sufficient une authentification 
par  le  module  LDAP  (pam_ldap.so).  On  s’affranchira  d’une  double  entrée  de  mot  de  passe  en  ajoutant  l’option 
use_first_pass qui permet la réutilisation du mot de passe entré à la première tentative de connexion. 

Extrait de fichier system­auth modifié sur une distribution Red Hat 

Le  paramètre  use_first_pass  indique  au  système  qu’il  doit  tenter  l’authentification  sur  le  module  pam_ldap  avec  les 
mêmes identifiants que ceux qui ont été utilisés pour le module pam_unix. L’utilisateur  est  ainsi  dispensé  d’une double 
frappe. 

auth sufficient pam_unix.so nullok


auth sufficient pam_ldap.so use_first_pass
account sufficient pam_unix.so
account sufficient pam_ldap.so

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Partage de données avec NFS 
NFS est le protocole historique de partage de fichiers sur les systèmes Unix. Si son grand âge le rend moins populaire 
chez les jeunes linuxiens, il reste intéressant de le connaître pour sa rapidité et sa simplicité de mise en œ uvre pour un 
partage entre deux systèmes Linux ou Unix. De plus, NFS subit ces deniers temps un regain d’intérêt grâce à certaines 
applications qui l’exploitent comme les infrastructures Vmware pour accéder à des espaces de stockages peu onéreux, 
ou les lecteurs multimédias domestiques qui accèdent à des serveurs de fichiers. 

1. Partage de répertoires 

a. Observation des partages actifs 

Les partages NFS actifs sur un système sont déclarés pour un répertoire local, et sont accessibles à certains clients 
avec certaines options. Les clients autorisés ainsi que les options sont déclarés lors de l’activation du partage. Si on 
rencontre un système déjà configuré, il peut être utile de faire un diagnostic des partages actifs sur ce système. Ce 
diagnostic est réalisé par la commande exportfs. 

Exemple d’utilisation de la commande exportfs pour observer les partages actifs 

Dans cet exemple, le répertoire /perso est partagé pour la seule adresse 192.168.0.20, alors que /nas est partagé pour 
tous les clients. 

alpha:~# exportfs
/data/perso <192.168.0.20>
/nas <world>
alpha:~#

Il est possible d’observer les statistiques liées à l’activité NFS avec la commande nfsstat. 

Visualisation des statistiques NFS 

La commande nfsstat sert surtout à vérifier une activité ou absence d’activité sur un serveur NFS. 

toto@serveur:~$ nfsstat
Server rpc stats:
calls badcalls badauth badclnt xdrcall
12 0 0 0 0

Server nfs v3:


null getattr setattr lookup access readlink
2 18% 2 18% 0 0% 2 18% 1 9% 0 0%
read write create mkdir symlink mknod
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
fsstat fsinfo pathconf commit
0 0% 3 27% 1 9% 0 0%

Client rpc stats:


calls retrans authrefrsh
0 0 0

toto@serveur:~$

b. Partage ponctuel 

La  commande  exportfs  permet  également  de  déclarer  un  partage  de  façon  interactive.  Elle  est  utilisée  pour  la 
déclaration de partages ponctuels. 

Syntaxe de la commande exportfs pour un partage ponctuel 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


exportfs adresse_client:/chemin_partage

Commande exportfs : options et paramètres 

adresse_client  Adresse IP du client ou du réseau qui peut se connecter au partage. Le joker « * » 
permet d’autoriser tous les clients à se connecter. 

chemin_partage  Chemin absolu du répertoire à partager. 

Bien entendu, le contrôle d’accès sur la seule adresse IP ne présente plus de garantie de sécurité depuis longtemps. 

c. Service NFS et partage permanent 

On peut naturellement déclarer un partage permanent activé à chaque démarrage du service NFS. Cette déclaration 
se  fait  dans  un  fichier  /etc/exports.  Notez  qu’il  arrive  selon  les  distributions  que  ce  fichier  n’existe  pas  après 
l’installation du service et qu’il faille le créer de toutes pièces. 

Format du fichier /etc/exports 

partage1 adresse_client1
partage2 adresse_client2

Ce fichier est lu à chaque démarrage du service NFS, ou à chaque appel de la commande exporfs avec l’option ­a. 
Notez que les partages sont tous exprimés par leur chemin absolu, c’est­à­dire exprimés depuis la racine du système 
de fichiers. 
Le script de gestion du service NFS assure le lancement de trois démons normalisés. 

● portmap : gère les requêtes RPC (Remote Procedure Call). 

● nfsd : espace utilisateur du service NFS. Lance les threads NFS pour les connexions clientes. 

● mountd : gère les requêtes de montage des clients. 

La commande rpcinfo permet d’effectuer une requête RPC sur un serveur et d’afficher les démons gérés. 

d. Options de partage 

Certaines  options  modifient  le  comportement  du  serveur  NFS  pour  chacun  des  partages  hébergés.  Elles  sont 
précisées dans la commande exportfs si on l’utilise dynamiquement, ou dans le fichier /etc/exports si on utilise NFS 
en tant que service. 

Options NFS courantes 

ro  Accès en lecture seule. 

rw  Accès en lecture et écriture. 

sync  Accès en écriture synchrone. Les données sont écrites immédiatement. 

async  Accès en écriture asynchrone. Utilisation d’un cache en écriture. 

root_squash  Comportement par défaut. Le compte root perd ses prérogatives sur le partage 
atteint. 

no_root_squash  Le compte root conserve ses prérogatives sur le partage atteint. 

nolock  N’appose pas de verrouillage sur les fichiers accédés. 

Exemple d’utilisation de la commande exportfs avec l’option de lecture seule 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Si plusieurs options sont configurées, elles doivent être séparées par des virgules. 

root@serveur# exportfs -o ro *:/data


root@serveur#

Exemple de fichier /etc/exports avec l’option de lecture seule 

Le paramètre * ou une adresse IP de client autorisé sont indispensables au bon fonctionnement. 

/data *(ro)

Exemple d’affichage des partages actifs avec leurs options 

Les options explicites ainsi que les options par défaut sont affichées. 

alpha:~# exportfs -v
/perso 192.168.0.20(rw,wdelay,root_squash,no_subtree_check)
/data <world>(ro,wdelay,root_squash,no_subtree_check)
alpha:~#

2. Configuration des clients 

a. Affichage des partages distants 

La commande showmount permet d’afficher les informations d’un serveur NFS distant. 

Affichage des partages distants avec showmount 

showmount --exports serveur

Où serveur représente l’adresse IP du serveur dont on veut obtenir les partages. 

b. Montage d’un répertoire distant 

Les ordinateurs clients accèdent à un partage NFS par une opération de montage. Ils exploitent ensuite le partage 
monté comme s’il s’agissait d’une arborescence locale. 

Montage d’un partage NFS 

mount -t nfs adresse_serveur:/chemin_partage point_de_montage

Montage NFS : options et paramètres 

­t nfs  Indique que le périphérique à monter est un partage NFS distant et fait appel au 
sous­programme client NFS. 

adresse_serveur  L’adresse IP du serveur NFS. 

chemin_partage  Le chemin absolu du répertoire partagé sur le serveur. 

point_de_montage  Le répertoire local du client sur lequel sera monté le partage NFS. 

3. Gestion des identités 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


a. Les droits du client 

Il  peut  être  assez  surprenant  quand  on  se  connecte  à  un  partage  NFS  de  constater  qu’aucune  demande 
d’identification  ne  nous  est  présentée.  On  se  retrouve  connecté  à  la  ressource  sans  avoir  eu  à  montrer  patte 
blanche.  NFS  considère  en  fait  que  les  identifiants  des  utilisateurs  sont  cohérents  entre  le  serveur  et  ses  clients, 
c’est­à­dire que tous les comptes sont identiques sur toutes les machines, et que leurs identifiants utilisateurs (uid) 
sont tous les mêmes. 

Quand  un  client  se  connecte  à  un  partage  NFS,  il  présente  son  uid,  et  aura  sur  le  serveur  les  droits  exacts  de 
l’utilisateur ayant le même uid sur le serveur. Aucun autre contrôle n’est effectué. 

b. Le cas particulier du superutilisateur 

Comme le compte root a l’uid 0 quelque soit le système Linux, un client se connectant à un serveur avec son compte 
superutilisateur aurait en théorie les pleins pouvoirs sur le partage. Cette situation embarrassante est résolue par 
l’application  implicite  d’une  option  de  partage  :  root_squash.  En  effet,  si  un  serveur  reçoit  une  demande  de 
connexion d’un compte avec l’uid 0, il modifie son identifiant et lui applique sur le partage l’uid d’un compte de service 
NFS. Ce compte (selon les distributions nfsanonymous, nfsnobody, nobody...) aura donc en général sur le système 
serveur les seuls droits de l’ensemble d’utilisateurs « other ». 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Partage de données avec SAMBA 
Samba est une solution logicielle d’interopérabilité avec Windows disponible sur les systèmes Linux et Unix. Le nom de 
Samba vient du protocole SMB : Server Message Block utilisé pour le partage de ressources sur les réseaux Microsoft. Il 
permet notamment le partage de fichiers ou d’imprimantes sur des serveurs Linux à destination de clients Windows. La 
suite  logicielle  Samba  comprend  aussi  un  client  qui  permet  aux  machines  Linux  d’accéder à des ressources partagées 
sur un serveur Windows. 

1. Configuration générale 

a. Les démons samba 

Samba  repose  sur  deux  démons  appelés  nmbd  et  smbd.  L’annonce  des  services  et  en  général  tout  le 
fonctionnement NetBIOS over IP repose sur le démon  nmbd. Les partages de fichiers et d’imprimantes eux­mêmes 
s’appuient sur le démon smbd. 
Le script de gestion du service généralement présent dans les distributions lance ces deux démons à chacun de ses 
démarrages. 

b. Les fichiers de configuration 

Les  démons  samba  trouvent  leur  configuration  dans  le  fichier  de  configuration  smb.conf,  généralement  dans  le 
répertoire /etc/samba. 

Le  fichier  de  configuration  est  divisé  en  sections  normalisées,  chacune  étant  commencée  par  un  titre  entouré  de 
crochets.  Les  paramètres  de  fonctionnement  seront  dans  chacune  des  sections  présentés  sous  la  syntaxe 
paramètre = valeur. 

Format synthétique de smb.conf 

[section1]
paramètre1 = valeur1
paramètre2 = valeur2
[section2]
paramètre3 = valeur3
paramètre4 = valeur4

Il existe un outil fort utile appelé testparm qui valide le format d’un fichier de configuration samba. Il renvoie en outre 
un état épuré (sans les lignes de commentaire) de la configuration sur la sortie standard. Naturellement, cette sortie 
pourra  être  redirigée  vers  un  fichier  et  générer  un  smb.conf  lisible  et  de  taille  raisonnable.  Il  est  à  noter  que  la 
commande testparm  ignore  tout  paramètre  du  fichier  de  configuration  s’il est configuré à sa valeur par défaut. Ce 
comportement peut être modifié avec l’option ­v. Toutes les options applicables sont alors affichées. 

Exemple d’exploitation de testparm pour génération d’un fichier smb.conf simple 

Cette  méthode  est  souvent  utilisée  pour  utiliser  un  fichier  de  configuration  largement  commenté,  et  un  fichier  réel  de 
dimension raisonnable. 

alpha:/etc/samba# mv smb.conf big.smb.conf


alpha:/etc/samba# wc -l big.smb.conf
326 big.smb.conf
alpha:/etc/samba# testparm big.smb.conf > smb.conf
Load smb config files from big.smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

alpha:/etc/samba# wc -l smb.conf
31 smb.conf
alpha:/etc/samba# testparm -v big.smb.conf > toutes-options.info.smb.conf

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


alpha:/etc/samba#

Les  versions  pré­installées  de  samba  proposent  toujours  un  fichier  smb.conf  pré­configuré.  Si  ce  fichier  peut 
constituer une bonne base de départ, sa taille (326 lignes chez Debian) risque d’impressionner les débutants, et on 
gagnera  peut­être  à  réaliser  un  fichier  de  toutes  pièces,  avec  uniquement  les  éléments  dont  on  a  explicitement 
besoin. 

c. Configuration globale 

Dans sa configuration la plus simple, une implémentation samba comprend un serveur qui héberge une ou plusieurs 
ressources. Certains paramètres concernent le fonctionnement global et l’identité de ce serveur et se retrouveront 
dans une section appelée global du fichier smb.conf. 
Dans les exemples qui suivent, nous nous placerons dans la situation d’un serveur simple, hors domaine Windows, 
qui présente des partages à des clients Windows. 

Éléments courants de la section [global] dans smb.conf 

workgroup = groupe_de_travail
server string = commentaire
log file = /chemin/log.%m
max log size = log_maxi
security = user (defaut)
encrypt passwords = true (defaut)

Section [global] du fichier smb.conf 

groupe_de_travail  Le nom du groupe de travail du serveur. Notez que ce paramètre désigne aussi le 
nom du domaine dans un fonctionnement en domaine. 

commentaire  Commentaire associé au serveur. Visible par exemple dans le voisinage réseau des 
machines Windows. 

log.%m  Définition du format standard des fichiers journaux. 

log_maxi  Définition de la taille maximum des fichiers de journaux. 

user  Facultatif car paramètre par défaut. Paramètre de sécurité qui oblige à une 
authentification avec un compte utilisateur. 

encrypt  Facultatif car paramètre par défaut. Nécessaire pour tous les clients modernes qui 
passwords   présenteront naturellement des mots de passe cryptés (depuis NT4SP3). 

2. Partage de répertoire 

Le partage de répertoire se fait par l’ajout d’une section dans le fichier smb.conf. 

Format type d’une section partage dans smb.conf 

[nom_partage]
comment = commentaire
path = chemin
readonly = lecture_seule
browseable = yes

Déclaration de partage dans smb.conf. 

nom_partage  Le nom sous lequel le partage sera vu par les machines Windows. 

commentaire  Facultatif. Définition du commentaire associé au partage. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


chemin  Définition du chemin du répertoire à partager. Le répertoire doit exister dans le 
système de fichier Linux. 

lecture_seule  Définition de l’accès au partage en lecture seule ou en lecture­écriture. lecture_seule 
aura la valeur yes ou no selon la configuration choisie. Notez que ce paramètre 
s’applique au partage et que l’accès reste soumis aux permissions du système de 
fichiers Linux. 

browseable  Gestion de la visibilité du partage depuis les clients. 

Si on regarde l’ensemble des paramètres possibles pour le fichier smb.conf, on peut légitimement être impressionné 
par  leur  quantité.  Il  faut  savoir  que  nombre  de  paramètres  fonctionnels  peuvent  être  exprimés  de  plusieurs  façons. 
Prenons  l’exemple  de  l’accès  à  un  partage  en  lecture  seule  vu  dans  la  déclaration  des  partages.  Les  propositions 
suivantes sont toutes équivalentes : 

readonly = yes 

readonly = true 

writable = no 

writable = false 

writeable = no 

writeable = false 

3. Gestion des identités 

a. Algorithmes de hachage et stockage des mots de passe 

Sur la très grande majorité des systèmes d’exploitation et applications, les mots de passe ne sont pas stockés en 
clair  au  sein  du  système.  Les  mots  de  passe  des  comptes  sont  cryptés  et  c’est  la  version  cryptée  qui  est  seule 
stockée. Le mot de passe en clair est oublié aussitôt qu’il a été créé. 
Quand un utilisateur se connecte et tape ses éléments d’identification, le mot de passe est aussitôt crypté, et cette 
version fraîchement cryptée du mot de passe est comparée avec la version cryptée stockée dans la base de comptes 
du système. Ainsi, le mot de passe ne circule jamais en clair sur le réseau. 
Les algorithmes employés pour crypter le mot de passe appartiennent à la famille des algorithmes de hachage. Ils 
ont  un  fonctionnement  un  peu  particulier  en  ce  sens  qu’ils  permettent  de  crypter,  mais  jamais  de  décrypter  des 
données  :  ils  sont  à  sens  unique,  et  de  ce  fait  un  peu  à  part  dans  le  monde  de  la  cryptographie.  Ce  mode  de 
fonctionnement explique pourquoi quand un utilisateur perd son mot de passe, on peut lui en réaffecter un, mais pas 
lui dire quel était le mot de passe oublié. La seule information stockée est la version cryptée du mot de passe, et elle 
est par hypothèse indéchiffrable. 

Les algorithmes de hachages les plus courants s’appellent MD4, MD5 et SHA1. Ils sont utilisés pour stocker les mots 
de passe, les opérations de signature numérique ou les contrôles d’intégrité. 

b. Authentification auprès des serveurs Samba 

Un  serveur  Linux  avec  la  suite  logicielle  Samba  installée  utilise  nativement  les  comptes  du  système  pour  les 
authentifications Samba. Ainsi, toute connexion de la part d’un client se fait avec un compte hébergé par le système 
Linux. Cette situation risque toutefois de poser un problème. Le client Windows va présenter un mot de passe crypté 
par l’algorithme de hachage natif des systèmes Windows MD4 : Message Digest 4, alors que les mots de passe des 
systèmes  Linux  exploitent  l’algorithme  MD5 :  Message  Digest  5.  Le  mot  de  passe  crypté  présenté  par  le  client 
Windows  ne  sera  donc  pas  le  même  que  celui  stocké  dans  le  fichier  /etc/shadow  du  système  Linux  et 
l’authentification sera donc impossible, même si le mot de passe en clair est le même. 
Pour  que  les  clients  Windows  puissent  s’authentifier  après  de  systèmes  Linux,  il  faut  donc  que  ces  systèmes 
hébergent  une  version  du  mot  de  passe  cryptée  en  MD4  en  plus  du  mot  de  passe  natif  Linux  crypté  en  MD5.  Ces 
deux mots de passe sont gérés indépendamment et peuvent même être différents. 

c. Génération des mots de passe MD4 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


La commande spécifique smbpasswd permet la création d’un mot de passe MD4 pour un compte Linux existant. Ce 
mot de passe est stocké à part, généralement dans un fichier /etc/samba/smbpasswd. 

Syntaxe de la commande smbpasswd pour affecter un mot de passe 

smbpasswd -a nom_compte

Commande smbpasswd : options et paramètres 

­a  Facultatif. Nécessaire si le compte ne dispose pas encore de mot de passe samba. 

nom_compte  Le compte Linux auquel il faut affecter un mot de passe samba. 

d. Synchronisation avec les mots de passe Linux 

Il  est  possible  de  demander  à  synchroniser  les  mots  de  passe  samba  avec  les  mots  de  passe  du  système  Linux. 
Attention,  comme  expliqué  précédemment,  les  mots  de  passe  sont  encryptés  dans  les  deux  systèmes  avec  deux 
algorithmes  de  hachage  différents,  par  définition  irréversibles.  La  synchronisation  ne  peut  donc  se  faire  qu’au 
moment où le mot de passe est saisi en clair lors de l’utilisation de la commande smbpasswd. Le mot de passe en 
clair est alors encrypté deux fois avec les deux algorithmes différents, et les deux bases de compte sont modifiées. 
Cette synchronisation est activée par une directive dans le fichier smb.conf. 

Activation de la synchronisation de mots de passe dans smb.conf 

unix password sync = yes

e. Suppression ou désactivation d’un compte samba 

On  peut  souhaiter  interrompre  pour  un  utilisateur  l’accès  aux  ressources  partagées  sur  un  serveur  samba.  La 
commande  smbpasswd  permet  de  supprimer,  désactiver  ou  de  réactiver  le  compte  samba,  indépendamment  du 
compte Linux associé. 

Commande smbpasswd pour désactiver un compte samba 

smbpasswd -d nom_compte

Commande smbpasswd pour réactiver un compte samba 

smbpasswd -e nom_compte

Commande smbpasswd pour supprimer un compte samba 

smbpasswd -x nom_compte

Où  nom_compte  représente  le  compte  utilisateur  samba  à  manipuler.  Il  est  à  noter  que  les  opérations  sur  les 
comptes samba n’ont aucune incidence sur le compte Linux correspondant. 

4. Le client Samba 

Le  client  samba  permet  d’accéder à un partage d’une machine Windows ou Samba depuis un client Linux. Il permet 


éventuellement à un client Linux de se connecter à un serveur Samba Linux, mais on l’envisagera plutôt pour accéder 
à des données sur un partage Windows depuis une machine Linux. Les deux commandes principales du client samba 
sont smbclient et smbmount. 

a. Exploitation ponctuelle de ressources avec smbclient 

On utilise essentiellement smbclient pour obtenir des informations sur les ressources partagées hébergées par un 
serveur SMB. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Utilisation de smbclient pour récupérer des informations sur un serveur smb 

smbclient -L adresse_serveur -U nom_utilisateur

smbclient pour affichage des partages : paramètres 

adresse_serveur  L’adresse IP du serveur dont on veut observer les ressources. 

nom_utilisateur  Indique le nom de l’utilisateur qui fait la requête auprès du serveur. Doit être un 
compte existant et valide sur le serveur. 

On  pourra  également  utiliser  la  commande  smbclient  de  façon  interactive  en  se  connectant  à  une  ressource 
partagée et en accédant à un shell qui permettra de réaliser des opérations sur les fichiers. 

Utilisations de smbclient en mode interactif 

smbclient \\\\adresse_serveur\\partage -U nom_utilisateur


smbclient //adresse_serveur/partage -U nom_utilisateur

Où partage représente le nom du partage hébergé par le serveur. Les multiples antislash sont nécessaires même s’ils 
obligent à une syntaxe un peu curieuse. En fait, il s’agit d’un chemin UNC : Uniform Naming Convention, utilisé pour 
désigner une ressource dans les environnements Windows. Un chemin UNC est composé du nom du serveur précédé 
de deux antislashs, puis du chemin de la ressource, séparé par un slash à chaque niveau. Or, il se trouve que dans 
les  environnements  Linux,  l’antislash  est  un  caractère  réservé  qui  indique  que  le  shell  ne  doit  pas  interpréter  le 
caractère suivant. Pour écrire un véritable antislash, il faut donc le faire précéder d’un premier antislash qui indique 
que le deuxième doit être considéré comme un antislash naturel. Une alternative plus légère consiste à redresser les 
slashs et à utiliser les slashs droits. Les deux syntaxes sont admises. 
Une  fois  cette  commande  exécutée  et  après  avoir  tapé  le  mot  de  passe  de  l’utilisateur,  on  est  dans  un  shell 
spécifique smbclient qui permet de réaliser des opérations sur les fichiers. Les principaux usages seront évidemment 
de récupérer ou d’envoyer des fichiers vers le partage. On peut se déplacer dans l’arborescence avec la commande 
cd,  puis  les  deux  commandes  essentielles  seront get  pour  récupérer  des  fichiers,  et put  pour  envoyer  des  fichiers 
vers le partage. 

Exemple d’utilisation de smbclient en mode interactif 

L’utilitaire smbclient présente un jeu de commandes semblable à celui des clients FTP. 

alpha:~# smbclient \\\\192.168.0.1\\data -U toto


Enter toto’s password:
Domain=[WSERVEUR] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: \> ls
. D 0 Wed Feb 3 19:28:33 2010
.. D 0 Wed Feb 3 19:28:33 2010
deux D 0 Wed Feb 3 18:50:05 2010
un D 0 Wed Feb 3 19:28:38 2010

40915 blocks of size 262144. 34718 blocks available


smb: \> cd un
smb: \un\> ls
. D 0 Wed Feb 3 19:28:38 2010
.. D 0 Wed Feb 3 19:28:38 2010
fichier.txt A 27 Wed Feb 3 19:15:49 2010
truc.bmp A 0 Wed Feb 3 18:46:44 2010

40915 blocks of size 262144. 34718 blocks available


smb: \un\> get fichier.txt
getting file \un\fichier.txt of size 27 as fichier.txt (2,0 kb/s) (average 2,0 kb/s)
smb: \un\> exit
alpha:~# ls
fichier.txt
alpha:~#

b. Montage d’un partage smb avec smbmount 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Si  smbclient  permet  un  accès  ponctuel  à  des  partages,  il  existe  un  moyen  plus  confortable  d’exploiter  des 
répertoires partagés depuis un client Linux : le montage d’un partage sur la station Linux. 

La commande smbmount permet de réaliser le montage d’un partage SMB sur un répertoire local comme on peut le 
faire d’un filesystem local ou d’un partage NFS. 

Syntaxes de la commande smbmount 

smbmount \\\\adresse_serveur\\partage point_montage -o user=nom_utilisateur

smbmount //adresse_serveur/partage point_montage -o user=nom_utilisateur

smbmount : options et paramètres 

adresse_serveur  L’adresse IP du serveur dont on veut accéder au partage. 

partage  Le nom du partage hébergé par le serveur. 

point_montage  Le répertoire existant sur lequel sera monté le partage. 

nom_utilisateur  Le nom de l’utilisateur qui fera la requête auprès du serveur. Doit être un compte 
existant et valide sur le serveur. 

Il  existe  une  alternative  à  cette  syntaxe,  c’est  de  réaliser  le  montage  par  la  commande  mount  en  appelant 
smbmount en tant que sous­programme. Cette syntaxe présente l’avantage d’uniformiser toutes les opérations de 
montage, et donc de ne retenir qu’une syntaxe générique. 

Syntaxe de la commande mount pour partage smb 

mount -t smbfs -o username=nom_utilisateur //adresse_serveur/partage point_montage

L’option  ­t  smbfs  provoque  l’appel  du  sous­programme  smbmount  pour  réaliser  le  montage,  mais  à  partir  d’une 
syntaxe quasi­standard pour réaliser le montage. 

c. Montage d’un partage CIFS 

Pour  répondre  aux  besoins  d’ouverture  du  protocole,  SMB  s’est  normalisé,  a  évolué  et  s’appelle  désormais  CIFS : 
Common Internet File System. La suite logicielle Samba désigne désormais son client et les éléments logiciels sous ce 
nom. Les habitudes ayant la peau dure, l’usage de la dénomination SMB perdure encore largement. 
Selon  les  versions  de  samba  employées,  on  peut  n’utiliser  que  smb,  cifs  seul  ou  smb  et  cifs  indifféremment.  La 
tendance est à la disparition de smb au profit de cifs. 

Syntaxe de la commande mount pour partage cifs 

mount -t cifs -o username=nom_utilisateur //adresse_serveur/partage point_montage

Il  est  possible  de  vérifier  côté  serveur  quels  sont  les  clients  connectés.  La  commande  smbstatus  permet 
d’afficher les connexions smb actives. 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Partage de fichiers avec FTP 

1. Le protocole FTP 

a. Historique 

FTP :  File  Transfer  Protocol  est  un  protocole  client­serveur  assez  ancien  qui  fut  l’un  des  premiers  à  permettre  le 
partage de fichiers entre deux ordinateurs. Il a un passé glorieux, et fut par exemple employé avant la création du 
protocole SMTP pour transférer les messages électroniques d’un ordinateur à un autre. 

Aujourd’hui,  son  âge  et  une  certaine  rigidité  le  rendent  moins  apte  à  un  partage  de  fichiers  confortable.  Il  reste 
néanmoins  très  utilisé,  notamment  par  les  hébergeurs  Internet  qui  proposent  généralement  à  leurs  clients  de 
mettre à jour les sites web hébergés par FTP. 

b. Paramètres techniques 

FTP  est  transporté  par  TCP  et  fonctionne  sur  le  port  21  pour  la  transmission  des  commandes.  Le  port  20  est 
historiquement utilisé pour passer les données téléchargées mais ça n’est plus un comportement universel. 

FTP supporte l’authentification des clients, mais avec un degré de sécurité faible le rendant inapte au transfert de 
fichiers sensibles. En effet, FTP est bien connu pour transporter le mot de passe de ses clients en clair sans aucun 
cryptage. Pour ces raisons, FTP est généralement utilisé aujourd’hui dans un usage spécifique : le mode anonyme. 
Les serveurs FTP peuvent reconnaître un compte unique anonyme et lui autoriser un accès limité, généralement en 
lecture  seule  sur  certains  répertoires.  Le  compte  doit  obligatoirement  s’appeler  anonymous,  et  le  serveur  a  la 
possibilité  de  demander  un  mot  de  passe,  qui  pourra  être  n’importe  quelle  suite  de  caractères.  Le  mot  de  passe 
sera alors conservé pour des raisons de traçabilité même si le client n’a aucune obligation sur ce mot de passe. 

c. Mode FTP actif et FTP passif 

Historiquement, les clients FTP travaillaient en mode actif où la session est établie sur le port 21 du serveur, et où 
les  données  sont  envoyées  depuis  le  port  20  et  à  l’initiative  du  serveur  vers  un  port  quelconque  du  client.  Ce 
fonctionnement qui date d’avant la généralisation des pare­feu ne va pas sans poser de problème dans la mesure 
où il est vu par le pare­feu comme une session ouverte depuis le serveur sur un port imprévisible du client. 

Le mode  passif  est  venu  corriger  cet  état  de  fait  en  faisant  établir  les  deux  sessions  par  le  client.  Le  port  utilisé 
pour  les  données  est  alors  quelconque,  annoncé  par  le  serveur  en  mode  commande,  et  utilisé  par  le  client  pour 
l’ouverture de la session de données. 

2. Les clients FTP 

a. Les clients FTP graphiques 

Les clients FTP graphiques sont nombreux et existent pour toutes les plates­formes. On peut citer filezilla qui est un 
produit open source très populaire sur les systèmes Windows. La configuration et l’usage des clients FTP graphique 
variant selon les produits et ne présentant pas de difficulté majeure, leur utilisation ne sera pas traitée ici. 

b. Le client FTP en lignes de commandes 

La plupart des systèmes incluent un client FTP en lignes de commandes. Le mode de fonctionnement de ces clients 
peut  les  rendre  inconfortables  pour  un  usage  fréquent  mais  ils  sont  extrêmement  pratiques  pour  tester  la 
configuration d’un serveur FTP. 

Le chargement de ces clients se fait le plus simplement du monde par la commande ftp. 
L’avantage principal du client FTP en ligne de commande est qu’il permet de réaliser toutes les opérations voulues 
une  à  une,  et  donc  de  comprendre  en  cas  de  dysfonctionnement  où  se  situe  l’échec.  Au  contraire,  les  clients 
graphiques  ont  tendance  à  automatiser  un  grand  nombre  d’opérations.  Pour  une  connexion  FTP  avec  Internet 
Explorer  par  exemple,  la  connexion  est  automatiquement  anonyme,  et  un  mot  de  passe  standard  est 
automatiquement envoyé. 

Client FTP : commandes courantes 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


open  Ouvre une session FTP vers le serveur donné en référence. Le client demandera 
interactivement l’adresse du serveur. 

close  Ferme une session FTP en cours. 

ls  Affiche les fichiers contenus dans le répertoire courant distant. 

cd  Change le répertoire courant distant. La syntaxe est la même que dans un shell Linux. 

get  Télécharge (récupère) un fichier du répertoire courant distant dans le répertoire courant local. 

put  Télécharge (envoie) un fichier du répertoire courant local vers le répertoire courant distant. 

3. Le serveur Pure­FTPd 

Pure­FTPd est un serveur FTP qui vise à proposer un service de transfert de fichier simple, stable et efficace. Il se veut 
adapté aussi bien aux débutants qu’aux situations de production en entreprise. Sa principale caractéristique est de 
pouvoir être lancé facilement en ligne de commande sans s’appuyer sur un fichier de configuration. 

a. Fonctionnement pour accès des utilisateurs à leurs répertoires personnels 

C’est  le  fonctionnement  par  défaut,  et  les  utilisateurs  possédant  un  compte  et  un  répertoire  personnel  peuvent 
accéder à leurs données avec leur identifiant et leur mot de passe habituel. Attention, ce mode de fonctionnement 
est généralement déconseillé dans la mesure où le transit du mot de passe en clair met en danger le mot de passe 
Linux des utilisateurs. 

Lancement du service 

pure-ftpd

b. Fonctionnement en accès anonyme 

L’accès anonyme est possible si un compte utilisateur ftp a été créé sur le serveur. Les clients connectés en mode 
anonyme travaillent alors dans le répertoire /home/ftp. 

Il est possible de travailler en mode anonyme seul en appelant pure­ftpd avec l’option ­­anonymousonly. 

c. Options de fonctionnement 

Pure­ftpd  fonctionnant  généralement  sans  fichier  de  configuration,  la  ligne  de  commande  lançant  le  service  sera 
enrichie d’options de configuration en fonction du résultat voulu. Certaines implémentations toutefois exploitent un 
ou plusieurs fichiers de configuration qui sont interprétés par le script de lancement du service. La liste ci­dessous 
présente certaines des options les plus courantes. 

pure­ftpd : options courantes 

­­help  Affiche les options possibles. 

­­displaydotfile  Affiche aussi les fichiers cachés aux clients. 

­­anonymousonly   Fonctionnement en serveur anonyme uniquement (si le compte ftp 
existe). 

­­noanonymous  Empêche toute connexion anonyme (même si le compte ftp existe). 

­­maxidletime  Temps maximum d’inactivité avant déconnexion forcée. 

­­anonymouscantupload  Empêche les utilisateurs anonymes de transférer des fichiers vers le 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


serveur. 

­­anonymouscancreatedirs  Permet aux utilisateurs anonymes de créer des répertoires. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Généralités 
Le système DNS est le support de nombreuses fonctionnalités sur Internet allant de la navigation à l’envoi de courriers 
électroniques. Sa bonne configuration est essentielle dans le cadre d’un réseau local, et primordiale sur Internet. 

1. Les débuts de la résolution de noms et l’apparition du DNS 

Depuis  le  début  des  réseaux  IP,  le  principe  de  la  résolution  de  noms  est  de  faire  correspondre  un  nom  facile  à 
mémoriser à une adresse IP, seule information réellement exploitable pour contacter une machine distante. 

nom­de­machine <­­> 130.130.28.12 

Tant que les machines publiques sur Internet étaient peu nombreuses, toutes les résolutions se faisaient au moyen 
d’un fichier appelé hosts qu’on téléchargeait à intervalle régulier pour se tenir au courant des nouveautés.   
Le  DNS  a  été  conçu  pour  pallier  les  limites  du  fichier  hosts  téléchargé,  et  devait  répondre  à  certains  impératifs  de 
conception. 

Le DNS est dynamique

Les enregistrements doivent pouvoir être ajoutés de façon unique dans le système, et devenir rapidement disponibles 
pour tous. 

Le DNS est répliqué

On  ne  peut  se  permettre  de  dépendre  d’un  seul  serveur,  et  les  informations  existent  toujours  en  plusieurs 
exemplaires. 

Le DNS est hiérarchisé

Les informations sont classées en une arborescence qui permet leur organisation. Chaque niveau de la hiérarchie est 
appelé « zone », et le sommet de cette hiérarchie est la zone « . ». 

Le DNS est distribué

Les  informations  sont  réparties  en  une  multitude  de  « sous­bases »  (les  zones  DNS),  et  l’ensemble  de  ces  petites 
bases  d’informations  compose  l’intégralité  des  enregistrements  DNS.  Ce  fonctionnement  a  l’avantage  de  faciliter 
l’administration en répartissant la charge sur des milliers de serveurs. 

Le DNS est sécurisé

Cet impératif est apparu plus tardivement, et n’est pas encore implémenté sur tous les serveurs DNS. On a toutefois 
désormais la possibilité de sécuriser de bout en bout les opérations du DNS. Les services de sécurité disponibles sont 
l’authentification, le contrôle d’accès et le contrôle d’intégrité. 

2. Concept de zones DNS 

Le nombre pléthorique d’enregistrements DNS ne permettrait pas leur gestion sans aucune forme d’organisation (cela 
reviendrait  à  avoir  un  fichier  hosts  contenant  des  millions  de  lignes).  Leur  organisation  hiérarchique  était  donc 
indispensable,  et  c’est  la  raison  d’être  des  zones  DNS.  Chaque  niveau  de  la  hiérarchie  est  une  zone.  Chaque 
arborescence est un domaine. 
On a arbitrairement créé une zone appelée « . » (point), qui est à la racine de la hiérarchie, et qui contient tous les 
tld : top level domain (domaine de niveau supérieur). Les tld sont les extensions bien connues telles que com, fr, net, 
be, etc. Tous les domaines que nous connaissons et utilisons sont des sous­arborescences des tld. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


 

Dans  l’exemple ci­dessus,  la  zone  france  contient  les  sous­zones  rhone,  nord  et  idf.  Mais  on  peut  aussi  dire  que  la 
zone « . » contient les sous­zones fr, com et edu. Les zones situées hiérarchiquement sous une zone sont appelées 
zones "enfant". 
L’intérêt  de  cette  organisation  est  de  dédier  un  serveur  (en  fait  au  moins  deux  pour  des  raisons  de  tolérance  de 
pannes)  à  la  gestion  d’une  zone.  Et  comme  la  hiérarchie  DNS  est  virtuellement  illimitée,  en  largeur  comme  en 
profondeur, un serveur DNS ne gère en fait qu’une petite portion de l’espace de nom. Toujours dans notre exemple, si 
un serveur DNS héberge les données de la zone france, il est consulté pour toute résolution de nom se terminant par 
« france.fr », mais il n’héberge pas nécessairement les données des zones rhone, nord et idf, et peut se contenter de 
rediriger  la  requête  vers  le  serveur  de  la  zone  enfant.  On  parle  alors  de délégation  dans  le  sens  où  on  délègue  la 
gestion d’une zone enfant à un autre serveur. 
Pour des raisons de tolérance de panne, les données de chaque zone DNS doivent être répliquées au moins une fois, 
c’est­à­dire exister à au moins deux exemplaires. Un serveur aura autorité sur la zone et sera responsable des mises 
à jour. On dit qu’il est SOA : Start Of Authority. Les zones hébergées sur ce serveur sont de type master, et ceux qui 
hébergent une réplique de la zone sont configurés en tant que slave. 

3. Mécanisme de la résolution de nom 

Quand une application d’une machine doit faire une résolution de nom, elle s’adresse au composant resolver de son 
système d’exploitation. Le resolver va alors envoyer une requête de résolution de nom au serveur DNS référencé sur 
cette machine. Les requêtes de client à serveur se font sur le port 53 et sont transportées par le protocole UDP. 

Si  le  serveur  interrogé  dispose  localement  de  l’information,  il  répond  directement.  On  dit  qu’il  fait  une  réponse 
authoritative (autoritaire). 

Si le serveur interrogé ne dispose pas de l’information, il va consulter la seule zone qu’il connaît, la zone « . », qui lui 
donnera  l’adresse  d’un  des  13  serveurs  racines  de  l’Internet.  Le  serveur  interrogera  alors  ce  serveur  racine  pour 
connaître  l’adresse d’un  serveur  de  la  zone  du tld  : top  level  domain  (domaine  de  premier  niveau).  Lequel  serveur 
sera interrogé à son tour pour connaître l’adresse d’un serveur de nom gérant la zone directement sous le tld. Enfin, 
ce serveur sera interrogé pour savoir s’il dispose de l’enregistrement voulu dans ce domaine. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


 

Schéma simplifié de la résolution de nom : 
1.  Le  client  à  son  serveur  de  référence  (fournisseur  d’accès  ou  serveur  local)  :  quelle  est  l’adresse  pour  le  nom 
www.abc.fr ? 
2. Le serveur local à un serveur racine : donne­moi l’adresse d’un serveur connaissant la zone fr. 

3. Tiens, le serveur à l’adresse 193.176.144.6 pourra te renseigner. Il possède les informations de la zone fr. 
4. Le serveur local au serveur de la zone fr : donne­moi l’adresse d’un serveur connaissant la zone abc.fr. 
5. Tiens : le serveur à l’adresse 213.41.120.195 pourra te renseigner. 
6. Le serveur local au serveur de la zone abc.fr : possèdes­tu un enregistrement www dans ton domaine abc.fr ? 
7. Oui, voici son adresse IP : 62.193.202.6. 
8. Le serveur local à la station cliente : tu m’as demandé www.abc.fr et son adresse IP est 62.193.202.6. 

4. Les enregistrements 

Les zones n’ayant qu’un rôle structurant, il faudra pour assurer les résolutions de nom créer des enregistrements qui 
feront  correspondre  un  nom  à  une  adresse  IP  ou  à  une  autre  information.  Ces  enregistrements  sont  appelés 
Ressources Records (enregistrement de ressources), souvent notés RR et constituent les informations fondamentales 
du DNS.   

Le FQDN, Fully  Qualified  Domain  Name (Nom de Domaine Pleinement Qualifié) représente le nom d’hôte, avec toute 


son  arborescence  parente,  jusqu’à  la  zone  «  .  »  .  Par exemple,  www.saintmarcelin.fr  représente  l’enregistrement 
www  dans  la  zone  saintmarcelin.fr,  fr  étant  la  dernière  zone  avant  la  zone  point.  Quand  on  ne  veut  aucune 
ambiguïté quant à la nature d’un nom DNS, on représente le FQDN avec la zone point matérialisée, c’est­à­dire qu’on 
écrit  un  point  comme  dernier  caractère  du  FQDN.  On  obtient  donc  «  www.saintmarcelin.fr.  ».  Cette  notation  est 
courante, voire indispensable dans les fichiers de configuration du serveur DNS. 
Le  système  DNS  a  pour  vocation  première  d’assurer  un  service  de  résolution  de  nom.  C’est­à­dire  de  faire 
correspondre à un nom d’hôte une adresse IP. Ses créateurs ont toutefois prévu que le système DNS serait capable 
d’assurer la résolution pour différents types de noms et d’améliorer ainsi la finesse du service. 

a. Enregistrement de type A 

Le  plus  facile  à  appréhender  et  le  plus  courant.  C’est  l’enregistrement  qui  fait  correspondre  une  adresse  IP  à  un 
nom. Par exemple quand on tape http://www.site.fr, www est un enregistrement de type A dans la zone site.fr. Il 
correspond à une adresse IP qui est celle du serveur web hébergeant le site en question. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Résolutions dans la zone domaine.fr 

www → 82.25.120.5 

support → 125.12.43.2 

vpn → 82.25.120.6 

b. Enregistrement de type AAAA 

Récent mais de plus en plus fréquent. Cet enregistrement fait correspondre à un nom une adresse IPv6. 

Résolutions dans la zone domaine.fr 

www → 2001:610:12:123a:28:15ff:fed9:97e6 

support → 2001:610:12:123a:28:15ff:fed9:97e8 

c. Enregistrement de type PTR 

Pointer, le contraire de A. Si les enregistrements de type A font correspondre une adresse IP à un nom d’hôte, les 
PTR font exactement le contraire. Ils existent dans des zones un peu particulières nommées IN­ADDR.ARPA. 
Le nom normalisé de la zone sera formé par les octets de la partie réseau de l’adresse IP ordonnés en sens inverse, 
suivi de la chaîne de caractères « .in­addr.arpa ». 

Résolutions dans la zone 1.168.192.in­addr.arpa 

10 → serveur1.entreprise.local (pour serveur1.entreprise.local → 192.168.1.10) 

15 → printer1.entreprise.local (pour printer1.entreprise.local → 192.168.1.15) 

Résolutions dans la zone 85.in­addr.arpa 

25.8.92 → www.abc.fr (pour www.abc.fr → 85.92.8.25) 

29.123.65 → www.def.net (pour www.def.net → 85.65.123.29) 

d. Enregistrement de type CNAME 

Canonical Name (alias ou surnom). Ce type d’enregistrement fait correspondre un nom à un autre nom. Par exemple 
si vous créez un serveur web pour les usages internes de votre entreprise sur un serveur existant qui s’appellerait 
« production1.maboite.com », vous pouvez créer un CNAME « intranet » plus intuitif pour les utilisateurs. 

Résolutions dans la zone maboite.com 

intranet → production1 

imprimante1 → printer1 

e. Enregistrement de type MX 

Mail Exchanger (Indicateur de serveur de messagerie pour un domaine). Ce type d’enregistrement fait savoir à des 
agents de transfert de messagerie quel est le serveur destinataire final d’un courriel. L’exemple ci­dessous est à titre 
d’illustration et ne présage pas du format d’un enregistrement MX. 

Résolution dans la zone domaine.fr 

@domaine.fr → smtp.domaine.fr → 82.25.120.6 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


f. Enregistrement de type SOA 

Start Of Authority (début d’autorité). Indique le serveur ayant la responsabilité de la zone. Toute zone fonctionnelle 
a un enregistrement SOA. 

Résolution dans la zone domaine.fr 

domaine.fr → ns.hebergeur.net 

g. Enregistrement de type NS 

Name Server (serveur de nom). Indique les serveurs de noms pour la zone. Toute zone fonctionnelle a au moins un 
enregistrement NS. 

Résolution dans la zone domaine.fr 

domaine.fr → ns.hebergeur.net 

5. DNS sur Linux 

a. Le serveur DNS 

Les  services  DNS  s’exécutant  sur  Linux  sont  presque  exclusivement  basés  sur  le  logiciel  BIND  (Berkeley  Internet 
Name  Domain).  Comme  son  nom  l’indique,  il  a  été  conçu  dans  l’université  de  Berkeley  en  Californie.  Les  premiers 
développements  datent  des  années  80  et  son  maintien  est  actuellement  assuré  par  l’« Internet  System 
Consortium »  (ISC),  une  association  à  but  non  lucratif  qui  gère  un  certain  nombre  de  logiciels  structurants  de 
l’Internet et des réseaux locaux. 

b. Le client DNS 

Les machines Linux disposent nativement d’un client DNS appelé resolver. Toute application fonctionnant sur Linux 
et ayant besoin de faire une requête DNS s’appuiera sur ce composant. 

Il exploite le fichier de configuration simple /etc/resolv.conf. 

Format simplifié du fichier /etc/resolv.conf 

search domaine
domain domaine
nameserver A.B.C.D

Fichier /etc/resolv.conf : directives et variables utilisées 

search  Facultatif : indique le suffixe de recherche employé sur le poste Linux. Permet de ne 
pas taper l’intégralité du FQDN dans les applications. Le fichier /etc/resolv.conf 
admet plusieurs domaines de recherches précisés par search. 

domain  Facultatif et obsolète : indique un suffixe de recherche unique employé sur le poste 
Linux. 

domaine  Le FQDN du domaine constituant le suffixe de recherche. 

nameserver  Indique l’adresse IP du serveur DNS qui assurera les résolutions. Le 
fichier /etc/resolv.conf admet plusieurs serveurs DNS précisés par nameserver. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Configuration de base du serveur 

1. Fonctionnement du serveur BIND 

Le serveur DNS BIND repose sur un exécutable named et sur un fichier de configuration named.conf. 

a. Structure du fichier named.conf et principaux éléments de configuration 

Ci­dessous  un  exemple  générique  de  fichier  named.conf.  Selon  les  cas,  on  le  trouvera  sous  une  forme  entière  et 
monolithique, mais il est fréquent de le trouver éclaté en plusieurs morceaux pour des raisons de lisibilité. Les sous­
fichiers  sont  alors  appelés  par  la  directive  include.  Le  rôle  principal  du  fichier  est  de  déclarer  les  zones  qui  seront 
gérées par ce serveur, mais également de préciser tout élément de configuration. 

Format simplifié de named.conf 

include "/chemin/fichier";
options {
directory "/chemin/repertoiredetravail";
forwarders { A.B.C.D };
};
zone "NOMDEZONE1" {
type type;
file "/CHEMIN/NOMFICHIER1";
};
zone "NOMDEZONE2" {
type type;
file "/CHEMIN/NOMFICHIER2";
};

Fichier named.conf : principales directives utilisées 

include  Indique le nom d’un "sous­fichier" de configuration. Évite d’avoir un fichier 
named.conf trop grand pour être administré confortablement.  

options  Conteneur pour certains mots­clés, notamment directory et forwarders. 

directory  Dans une directive option. Indique le répertoire utilisé pour le stockage sur disque 
des données de cache du serveur. 

forwarders  Placé dans une directive option pour les configurations simples (redirection 
inconditionnelle). Si le serveur ne dispose pas dans ses fichiers de la résolution 
demandée, renvoyer la demande vers le serveur dont l’adresse IP est donnée en 
référence. 

zone  Conteneur pour le nom d’une zone DNS gérée par le serveur. 

type  Dans une directive zone. Indique le type de zone stockée. Les principales valeurs 
sont hint (serveurs racine), master (serveur maître d’une zone), et slave (réplique 
depuis un master).  

file  Dans une directive zone. Indique le fichier contenant les informations de zone. 

b. Les fichiers de définition de zone pré­installés 

Selon  les  implémentations,  un  certain  nombre  de  zones  sont  présentes  par  défaut  à  l’installation  du  serveur  pour 
assurer  un  fonctionnement  standard  et  permettre  les  résolutions  courantes.  Par  exemple,  la  zone  localhost  qui 
permet de résoudre le nom localhost en 127.0.0.1, y compris au sein du service DNS et pas seulement dans le fichier 
hosts. 

Ces fichiers de zones sont créés à l’installation, et correctement référencés dans le fichier named.conf. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Exemple de fichier named.conf sur une distribution Debian : 

Notez la déclaration des zones par défaut, ainsi que l’appel de deux sous­fichiers de configuration appelés par la directive 
include. 

include "/etc/bind/named.conf.options";

zone "." {
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

include "/etc/bind/named.conf.local";

Notez  les  directives  include,  qui  renvoient  vers  deux  fichiers  vides  à  l’installation  (ils  ne  contiennent  que  des 
commentaires).  Le  reste  de  la  configuration  se  résume  à  la  déclaration  de  zones,  dont  la  seule  indispensable  à  la 
résolution de nom publique est la zone « . » évoquée plus haut. 

2. Serveur de cache 

Un  serveur  DNS  de  cache  assure  une  résolution  de  nom,  mais  n’héberge  aucune  donnée  de  résolution  locale  et 
s’appuie  sur  une  infrastructure  déjà  existante.  Il  se  contente  de  relayer  les  demandes  vers  d’autres  serveurs.  Ce 
faisant, ce serveur mettra en cache pour une durée déterminée toutes les résolutions enregistrées. 
Par  définition,  un  serveur  de  cache  ne  dispose  pas  localement  de  zones  DNS  personnalisées.  C’est­à­dire  qu’il 
n’assurera pas lui­même de résolution de type « Quelle est l’adresse IP correspondant au nom www.sitegenial.com ? 
»  :  Il  n’héberge  tout  simplement  pas  ce  type  d’information,  et  devra  pour  répondre  aux  requêtes  s’en  remettre  à 
d’autres serveurs mieux renseignés. 

a. Configuration du serveur de cache 

C’est la bonne nouvelle : un serveur BIND fraîchement installé est naturellement un serveur de cache. Il n’y a donc 
pas de configuration particulière à réaliser, il s’agit simplement d’installer un serveur fonctionnel sans information de 
zone locale. 

b. Redirection 

Nous savons qu’un serveur de cache n’héberge pas localement d’enregistrements de ressources. S’il doit faire une 
résolution,  il  va  s’adresser  aux  seuls  serveurs  qu’il  connaisse,  à  savoir  les  serveurs  racine.  Cette  méthode  de 
résolution  n’est  pas  forcément  la  plus  rapide,  et  on  pourrait  souhaiter  tirer  parti  du  cache  de  serveurs  déjà  en 
fonctionnement, comme ceux d’un hébergeur ou d’un  fournisseur  d’accès. Il faut pour cela indiquer à notre serveur 
l’adresse  d’autres  serveurs  vers  lesquels  il  pourra  rediriger  ses  requêtes.  Ce  type  de  redirection  est  appelé 
inconditionnelle car toutes les résolutions non lourdes sont redirigées. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Configuration de la redirection dans named.conf 

options {
forwarders {
A.B.C.D;
};
};

Fichier named.conf : directives utilisées pour la redirection 

options  Annonce la section options dans le fichier named.conf. Les redirections 
inconditionnelles sont annoncées dans une section options. 

forwarders  Dans une directive options. Annonce la ou les adresse(s) IP du ou des redirecteur(s). 

3. Commande de pilotage rndc 

Comme  tous  les  services  Unix  ou  Linux,  BIND  est  lancé  ou  arrêté  par  un  script  dans  /etc/init.d.  Pour  une  gestion 
précise du service, on dispose d’une commande de pilotage : rndc. Cette commande associée à quelques mots­clés 
permet de transmettre au serveur diverses instructions. 
Il n’est pas obligatoire d’utiliser rndc dans le cadre d’une administration courante. Mais alors toute modification d’un 
fichier  de  configuration  quel  qu’il  soit  imposerait  le  redémarrage  complet  du  service,  et  donc  son  interruption 
temporaire.  rndc  devrait  donc  être  utilisé  systématiquement,  surtout  si  le  serveur  gère  un  grand  nombre  de  zones, 
comme c’est le cas pour un hébergeur par exemple. 

Syntaxe 

rndc action [paramètre]

Commande rndc : actions possibles 

reload  Recharge les fichiers de configuration et les informations de zone. 

reload zone zone  Recharge les fichiers d’une zone unique. 

reconfig  Charge les fichiers de configuration pour les nouvelles zones uniquement.  

flush  Efface le cache du serveur. 

flush zone  Efface le cache du serveur pour la zone spécifiée. 

status  Affiche l’état du serveur 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Gestion de zones DNS 

1. Gestion de zones locales 

a. Création d’un fichier de zone directe 

Les  informations  nécessaires  à  la  résolution  devront  se  trouver  dans  un  fichier  de  déclaration  de  zone. 
L’emplacement de ce fichier est libre, puisqu’il est défini dans une section zone de named.conf. Toutefois, un usage 
établi veut que ce fichier soit placé dans le répertoire /var/named. Notez que selon les distributions, il peut aussi se 
trouver dans le répertoire /etc ou dans /etc/bind. 

Ce  fichier  aura  le  format  très  strict  indiqué  ci­dessous.  Dans  la  plupart  des  cas,  un  refus  de  démarrer  est  dû  à  un 
fichier  de  zone  mal  formé.  Il  est  composé  des  déclarations  de  durée  de  vie  en  cache  des  informations,  du  serveur 
ayant autorité sur la zone, des serveurs de noms desservant cette zone, et de l’ensemble des enregistrements de 
ressources (RR) de cette zone. 

Format type du fichier de zone directe 

$TTL ttl
nomzone IN SOA serveur mailadmin (
serial
refresh
retry
expire
negative )

nomzone IN NS serveur

Fichier de zone directe : format type de l’en­tête 

ttl  Time To Live (durée de vie) : indique la durée de conservation en secondes des 
données en mémoire cache. Cette valeur est précédée par la directive $TTL. 

nomzone  FQDN de la zone gérée par ce fichier. Souvent remplacé par un arobase (@) pour 
alléger le fichier. Attention, puisqu’il s’agit d’un FQDN, le nom de la zone doit se 
terminer par un point.  

IN  Obsolète mais courant : classe Internet (aucune autre classe n’est plus utilisée). 

SOA  Start Of Authority. Enregistrement obligatoire pour indiquer que ce serveur est 
légitime sur cette zone.  

serveur  FQDN du serveur ayant autorité sur la zone. 

mailadmin  Adresse e­mail de l’administrateur du serveur. L’arobase étant un caractère réservé 
dans les fichiers de zone, il est conventionnellement remplacé par un point. 
admin@saintmarcelin.fr devient donc admin.saintmarcelin.fr.  

serial  Valeur numérique. Numéro de série du fichier. Utile quand la zone est répliquée sur 
d’autres serveurs pour savoir si les données ont changé et si la réplication doit être 
faite.  

refresh  Valeur numérique. Utilisé quand la zone est répliquée. Indique au serveur esclave à 
quel intervalle tester la validité de sa zone.  

retry  Valeur numérique. Utilisé quand la zone est répliquée. S’il est impossible pour 
l’esclave de contacter le serveur maître, indique au bout de combien de temps 
réessayer.  

expire  Valeur numérique. Utilisé quand la zone est répliquée. S’il est impossible pour 
l’esclave de contacter le serveur maître, indique au bout de combien de temps les 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


enregistrements non rafraîchis perdent leur validité et ne doivent plus être utilisés.  

negative  Valeur numérique. Indique combien de temps le serveur doit conserver en cache une 
réponse négative.  

NS  Enregistrement indiquant quel est le serveur de nom pour cette zone. 

b. Création d’un fichier de zone inverse 

Le  fichier  de  zone  inverse  aura  la  même  structure  qu’un  fichier  de  zone  directe.  Comme  indiqué  plus  haut,  le  nom 
normalisé de la zone est formé par les octets de la partie réseau de l’adresse IP ordonnés en sens inverse, suivi de 
la  chaîne  de  caractères  «  .in­addr.arpa  ».  Par  exemple,  la  zone  inverse  pour  le  réseau  192.168.99.0  sera  : 
99.168.192.in­addr.arpa,  et  c’est  ce  nom  qui  devra  être  employé  dans  le  fichier  de  zone  et  dans  le  fichier 
named.conf. 

Format type du fichier de zone inverse 

$TTL ttl
nomzoninv IN SOA serveur mailadmin (
serial
refresh
retry
expire
negative )

nomzoneinv IN NS serveur

Fichier de zone inverse : format type de l’en­tête 

nomzoneinv  Nom normalisé de la zone inverse : subnet­inversé.in­addr.arpa. Où subnet­inversé 
représente les octets du subnet en ordre inversé. Attention, le nom de la zone 
inverse est un FQDN, il doit donc se terminer par un point.  

SOA  Start Of Authority. Enregistrement obligatoire pour indiquer que ce serveur est 
légitime sur cette zone.  

serveur  FQDN du serveur ayant autorité sur la zone. 

NS  Enregistrement indiquant quel est le serveur de nom pour cette zone. 

Constatez  que  c’est rigoureusement la même chose que pour la zone directe. C’est le format des enregistrements 


qui fait l’essentiel de la différence. 

c. Création d’enregistrements dans les fichiers de zone 

Une fois les fichiers de zone créés, il suffit d’ajouter autant d’enregistrement de ressource que l’on souhaite, à raison 
d’un par ligne. 

Format d’un enregistrement de ressource dans un fichier de zone directe 

nom IN typeRR valeur-résolue

Format d’un enregistrement de ressource dans un fichier de zone inverse 

adresse-hôte IN PTR nom

Fichier de zone directe : format des enregistrements 

nom  Nom simple ou FQDN auquel il faut faire correspondre une adresse IP. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


IN  Obsolète mais nécessaire : classe Internet. 

typeRR  Type d’enregistrement. Souvent de type A : fait correspondre une adresse IP à un 
nom. Valeurs courantes : A, CNAME, MX. 

valeur­résolue  Ce à quoi on fait correspondre le nom. Dans le cas d’un enregistrement de type A, 
une adresse IP. 

adresse­hôte  L’octet ou les octets qui associés à l’adresse du réseau de la zone inverse formeront 
l’adresse IP à résoudre.  

PTR  Type pointeur : fait correspondre un nom à une adresse IP. Hors enregistrements 
SOA et NS, c’est le seul type qu’on rencontre dans les zones inverses. 

L’ajout  d’un  grand  nombre  d’enregistrements  est  évidemment  fastidieux,  et  gagnera  à  être  réalisé  sous  forme  de 
script. 

Exemple de script simple d’alimentation d’un fichier de zone : 

Les hébergeurs et autres DNS gérant de gros volumes d’enregistrement utilisent naturellement des scripts beaucoup plus 
élaborés. 

#!/bin/bash
echo "Nom à ajouter à la zone ?"
read nom
echo "Adresse IP correspondant ?"
read ip
echo "$nom IN A $ip" >> /var/named/saintmarcelin.fr

d. Déclaration de zone principale dans le fichier named.conf 

Une fois que l’on dispose d’un fichier de zone, il faut faire savoir au serveur qu’il doit le charger au démarrage. Ceci 
se fera avec une déclaration de zone normalisée dans le fichier named.conf. 

Format type de la déclaration de zone dans named.conf 

zone "nomzone" {
type master;
file "fichier";
};

Fichier named.conf : directives et syntaxe de la déclaration de zone 

nomzone  Le FQDN de la zone gérée par le serveur. 

type master  Précise qu’il s’agit d’une zone maîtresse à synchroniser éventuellement vers des 
serveurs esclaves. 

fichier  Chemin absolu du fichier à lire pour prendre connaissance des éléments propres à la 
zone (configuration, RR, etc.). 

e. Prise en compte de la nouvelle configuration 

Il faut ensuite faire en sorte que le serveur DNS recharge ses fichiers de configuration afin de prendre en compte les 
nouveautés.  Deux  solutions  pour  cela  :  le  redémarrage  du  service  ou  le  chargement  de  la  nouvelle  zone  par 
commande de pilotage rndc. 

Rechargement du service 

/etc/init.d/bind9 restart

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Chargement de la nouvelle zone par rndc 

rndc reload saintmarcelin.fr

2. Gestion de zones secondaires 

Une zone DNS ne devrait pas dépendre d’un serveur unique et il est courant de créer sur un deuxième serveur des 
zones secondaires, strictement identiques aux zones primaires, et synchronisées à intervalles réguliers. 

a. Déclaration de la zone secondaire dans named.conf 

Il n’est évidemment pas nécessaire de créer les fichiers de zones, puisqu’ils seront synchronisés depuis le serveur 
autoritaire. On parle couramment de serveur maître et de serveurs esclaves. 

Le chargement de la zone esclave se fait avec une déclaration de zone normalisée dans le fichier named.conf. 

Format type de la déclaration de zone secondaire dans named.conf 

zone "nomzone" {
type slave;
masters { adresse_maître ; } ;
file "fichier";
};

Fichier named.conf : directives et syntaxe de la déclaration de zone 

nomzone  Le FQDN de la zone gérée par le serveur. 

type slave  Précise qu’il s’agit d’une zone esclave à synchroniser depuis un serveur maître. 

adresse_maître  Adresse IP du serveur autoritaire. 

fichier  Chemin absolu du fichier dans lequel stocker les éléments synchronisés. Le compte 
de service doit avoir les droits d’écriture sur le répertoire de travail. 

b. Prise en compte de la nouvelle configuration 

Il faut ensuite faire en sorte que le serveur DNS recharge ses fichiers de configuration afin de prendre en compte les 
nouveautés.  Deux  solutions  pour  cela  :  le  redémarrage  du  service  ou  le  chargement  de  la  nouvelle  zone  par 
commande de pilotage rndc. 

Rechargement du service 

/etc/init.d/bind9 restart

Chargement de la nouvelle zone par rndc 

rndc reload saintmarcelin.fr

3. Délégation de zone 

Une  délégation  de  zone  consiste  à  faire  gérer  par  un  serveur  tiers  une  zone  enfant  d’une  zone  hébergée  par  un 
serveur parent. C’est le principe de la délégation qui permet de distribuer l’ensemble de l’espace de nom DNS sur des 
milliers de serveurs. La délégation se configurera sur le serveur parent. 
On ajoutera dans le fichier de zone du parent deux Ressources Record : l’un de type NS pour indiquer qu’il existe un 
serveur  de  nom  pour  la  zone  enfant,  et  l’autre  de  type  A  pour  connaître  l’adresse  IP  de  ce  serveur  de  nom. 
L’enregistrement NS assurant la délégation est appelé glue record (enregistrement colle). 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Configuration de la délégation dans le fichier de la zone parente 

zone_enfant IN NS dns_enfant
dns_enfant IN A A.B.C.D

Éléments 

zone_enfant  Nom simple de la zone enfant. 

IN  Obsolète mais obligatoire : classe Internet. 

NS  Cet enregistrement est de type Name Server (serveur de nom). 

dns_enfant  Nom du serveur DNS qui gère la zone enfant. 

A   C’est un enregistrement de type A. 

A.B.C.D  Adresse IP du serveur de nom pour la zone enfant. 

4. Outils de test 

a. ping 

Même  si  ça  n’est  pas  sa  fonction  première,  ping  peut  tout  à  fait  servir  de  test  rudimentaire  pour  la  résolution  de 
noms. On sera alors limité à tester la réponse des serveurs par défaut, renseignés dans /etc/resolv.conf. 

Utilisation de ping pour tester une résolution de nom 

Quand on utilise ping pour tester une résolution de noms, c’est la traduction de l’adresse qui importe et non la réponse 
ICMP de la machine distante. 

donald:/etc/bind# ping donald.formation.fr


PING donald.formation.fr (192.168.1.1) 56(84) bytes
64 bytes from donald.formation.fr (192.168.1.1): icmp
64 bytes from donald.formation.fr (192.168.1.1): icmp
64 bytes from donald.formation.fr (192.168.1.1): icmp

b. nslookup 

nslookup est l’outil le plus populaire pour l’interrogation des serveurs DNS. Il est présent sur la grande majorité des 
plates­formes Unix et Windows. 
nslookup est utilisé la plupart du temps en mode interactif. C’est­à­dire qu’après avoir tapé nslookup, on se trouve 
dans son interface où on tapera des commandes spécifiques. Les serveurs de noms interrogés par défaut sont ceux 
référencés dans /etc/resolv.conf. Ceci pourra éventuellement être modifié par la suite. 

Utilisation de nslookup pour une résolution de nom 

Par défaut, nslookup adresse aux serveurs DNS des requêtes de type A. 

donald:/etc/bind# nslookup
> server
Default server: 192.168.1.1
Address: 192.168.1.1#53
> coincoin.formation.fr
Server: 192.168.1.1
Address: 192.168.1.1#53

coincoin.formation.fr canonical name = donald.formation.fr.

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Name: donald.formation.fr
Address: 192.168.1.1
>

nslookup 

nom  Taper un nom DNS directement dans l’interface nslookup revient à en demander la 
résolution. nslookup indiquera alors quel serveur DNS il a interrogé, et la réponse qui 
lui a été faite. Il peut s’agir d’un nom complet (FQDN) ou d’un nom simple si on 
s’appuie sur un suffixe de recherche défini dans /etc/resolv.conf. 

server A.B.C.D  La commande server suivie de l’adresse IP d’un serveur à interroger indique à 
nslookup que toutes les interrogations futures devront être adressées à ce serveur. 

set type=TYPE  Par défaut, nslookup fait des requêtes de type A (résolution ordinaire de nom en 
adresse IPv4). La commande set type permet d’adresser des requêtes d’un autre 
type. On s’en sert couramment pour connaître par exemple les serveurs de noms ou 
de messagerie associés à une zone.  

Utilisation de nslookup pour trouver l’adresse d’un serveur de messagerie 

On peut utiliser nslookup pour tous les types d’enregistrements courants (ici MX). 

donald:/etc/bind# nslookup
> set type=MX
> elysee.org
Server: 192.168.1.1
Address: 192.168.1.1#53

Réponse ne faisant pas autorité :


elysee.org MX preference = 10, mail exchanger = mail.elysee.org

mail.elysee.org internet address = 64.182.1.213


>

c. dig 

dig est le nouvel outil proposé par l’ISC pour l’interrogation et le diagnostic des serveurs DNS. Passant pour être le 
plus  précis  et  abouti  des  outils  de  test,  il  devrait  éventuellement  finir  par  s’imposer  comme  solution  de  référence. 
Toutefois, les habitudes prises par les administrateurs DNS laissent présager encore de beaux jours pour nslookup. 
dig  est  utilisé  en  mode  non  interactif,  c’est­à­dire  que  chaque  utilisation  de  dig  devra  donner  l’ensemble  des 
paramètres nécessaires à la résolution. 

Syntaxe simplifiée de dig 

dig nom

dig A.B.C.D nom TYPE

Éléments 

nom  Le nom complet (FQDN) dont on veut assurer la résolution. 

A.B.C.D  L’adresse IP du serveur DNS à interroger. En cas d’omission, les serveurs de noms 
interrogés sont ceux référencés dans /etc/resolv.conf.  

TYPE  Par défaut, dig fait des requêtes de type A (résolution ordinaire de nom en adresse 
IPv4). Le paramètre type s’il est précisé permet d’adresser des requêtes d’un autre 
type. On s’en sert couramment pour connaître par exemple les serveurs de noms ou 
de messagerie associés à une zone.  

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Exemple d’utilisation de dig 

De loin la plus précise des commandes de diagnostic DNS. 

donald:/etc/bind# dig @127.0.0.1 coincoin.formation.fr

; <<>> DiG 9.2.4 <<>> @127.0.0.1 coincoin.formation.fr


;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18067
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;coincoin.formation.fr. IN A

;; ANSWER SECTION:
coincoin.formation.fr. 86400 IN CNAME donald.formation.fr.
donald.formation.fr. 86400 IN A 192.168.1.1

;; AUTHORITY SECTION:
formation.fr. 86400 IN NS donald.formation.fr.

;; Query time: 9 msec


;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 15 19:49:45 2006
;; MSG SIZE rcvd: 90

d. host 

host est un outil simple pour faire une requête DNS en mode non interactif. 

Syntaxe simplifiée pour la commande host 

host nom

host nom -t type A.B.C.D

Éléments 

nom  Le nom DNS dont il faut assurer la résolution. Il peut s’agir d’un FQDN ou du nom 
simple qui sera complété par le suffixe de recherche s’il est défini 
dans /etc/resolv.conf.  

­t type  Facultatif : le type de requête qui est adressée. Par défaut le type est sélectionné 
automatiquement parmi les types A, AAAA et MX.  

A.B.C.D  Facultatif : l’adresse IP du serveur DNS à interroger. Si cet élément n’est pas 
renseigné, ce sont les serveurs présents dans /etc/resolv.conf qui sont utilisés. 

Utilisation de host pour tester une résolution de nom 

host présente un résultat concis. 

donald:/etc/bind# host coincoin.formation.fr


coincoin.formation.fr is an alias for donald.formation.fr.
donald.formation.fr has address 192.168.1.1

donald:/etc/bind#

Utilisation de host pour récupérer les enregistrements NS 

donald:/etc/bind# host -t NS formation.fr

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


formation.fr name server donald.formation.fr.

donald:/etc/bind#

e. Mesure des performances 

La  commande  time  qui  mesure  le  temps  consommé  par  une  application  permet  de  mesurer  la  performance  d’une 
résolution  DNS.  Elle  indique  le  temps  total  consommé  par  la  commande,  et  le  temps  consommé  par  les  processus 
dans les espaces d’exécution système et utilisateur. 

Observation du temps pris par une résolution DNS 

Les  temps  mesurés  dépendent  de  la  bande  passante  disponible,  de  la  disponibilité  du  serveur,  et  de  la  rapidité  de  la 
machine cliente. 

toto@serveur:~$ time nslookup www.eni-editions.fr


Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: www.eni-editions.fr
Address: 81.80.245.20

real 0m0.256s
user 0m0.000s
sys 0m0.010s
toto@serveur:~$

- 8- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Sécurisation du DNS 

1. Limitation des clients 

Il est possible de limiter les requêtes autorisées. La directive allow­query dans le fichier de configuration permet de 
définir les hôtes ou réseaux auxquels un serveur acceptera de répondre. 

Limitation des clients autorisés dans le fichier named.conf 

allow-query { réseaux-autorisés; };

Où réseaux­autorisés représente la ou les adresses de réseaux ou d’hôte qui pourront s’adresser au serveur. 

2. Utilisation d’un compte de service 

a. Pourquoi un compte de service ? 

Aux origines, il était fréquent de faire tourner un serveur bind sous l’identité du compte d’administration root. C’est­
à­dire que le compte root était propriétaire du processus. Les conséquences pouvaient être fâcheuses : si du code 
sensible (dangereux) était envoyé au processeur par l’exécutable named, il l’était au nom de root, c’est­à­dire avec 
les pleins pouvoirs sur le système. Or, cette situation présente des risques. Il peut s’agir de bogues contenus dans 
le  code  exécutable  de  named,  ou  bien  de  vulnérabilités  du  programme  qui  permettraient  à  une  personne  mal 
intentionnée d’envoyer du code exécutable via le processus. 

La solution retenue est en général d’exécuter named sous une identité différente de root, et d’utiliser un compte de 
service : un compte utilisateur ne permettant pas de connexion directe au système, mais qui sera propriétaire du 
processus. Ainsi, si du code malicieux venait à être exécuté via le processus named, il n’aurait pas plus de pouvoir 
que ceux du compte de service, et ne pourrait donc pas mettre en péril le système. 

La plupart des implémentations modernes de bind exploitent nativement l’utilisation d’un compte de service. 

Compte de service named sur une distribution Red Hat 

Le compte est créé automatiquement à l’installation du service. 

[root@RH9 root]# grep named /etc/passwd


named:x:25:25:Named:/var/named:/sbin/nologin

b. Lancement de named avec un compte de service 

Encore une fois, toutes les implémentations de  bind utilisées dans des distributions modernes de Linux exploitent 
nativement  un  compte  de  service.  La  démarche  indiquée  ici  est  donc  nativement  incluse  dans  les  scripts  de 
lancement de service. 

Syntaxe simplifiée de la commande named pour utilisation d’un compte de service 

named -u utilisateur

Éléments 

named  L’exécutable principal de bind. Dans la plupart des implémentations, lancé depuis le 
script de gestion du service.  

utilisateur  Appelé par le paramètre "­u", indique le compte de service propriétaire du 
processus. Ce compte doit naturellement être défini dans le fichier /etc/passwd. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


3. Bind en mode chroot 

a. Pourquoi enfermer le processus ? 

Nous  avons  vu  plus  haut  qu’une  utilisation  malencontreuse  du  processus  named  pouvait  entraîner  le  risque 
d’actions dangereuses pour le système. L’enfermement du processus dans un répertoire dédié permet de limiter les 
risques. Le but est de faire croire au processus qu’il s’exécute dans un système ordinaire, alors qu’il est cantonné 
dans  une  arborescence  parallèle,  et  qu’il  ne  peut  en  aucun  cas  interagir  avec  le  reste  du  système.  Le  terme  « 
enfermement » n’est pas usurpé, on parle en anglais de le mettre « in jail », c’est­à­dire en prison. 
On dit alors qu’on utilise bind en mode chroot, contraction de change root (changement de racine). 
Il est recommandé d’utiliser le mode chroot avec un compte de service. Un processus qui aurait les prérogatives de 
root pourrait s’octroyer le droit de sortir du répertoire où il est enfermé. 

b. Création de l’environnement nécessaire 

Dans la mesure où le processus est berné et qu’il croit s’exécuter dans un environnement ordinaire, il doit avoir à sa 
disposition tous les éléments nécessaires à son fonctionnement. Il faut bien comprendre que le processus n’aura 
aucun  moyen  d’aller  chercher  quoique  ce  soit  en  dehors  de  son  répertoire.  La  mise  en  place  d’un bind  en  mode 
chroot suppose donc une phase préliminaire de création de son environnement de travail. 

Étapes de création de l’environnement de travail :

● Création du répertoire de chroot. 

● Création  de  la  fausse  arborescence  "/"  dans  le  répertoire  de  chroot.  Tous  les  répertoires  utilisés  par  le 
processus named doivent s’y trouver. 

● Copie des fichiers de configuration dans le répertoire de chroot. 

● Lancement du processus en mode chroot. 

c. Lancement du programme en mode chroot 

Il n’est pas vraiment difficile de lancer bind en mode chroot. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Syntaxe de la commande named pour utilisation en mode chroot 

named -c config -u utilisateur -t repertoire

Éléments employés dans la syntaxe : 

named  L’exécutable principal de bind. Dans la plupart des implémentations, lancé depuis le 
script de gestion du service.  

config  Facultatif. Indique le fichier de configuration à employer au chargement. En 
principe /etc/named.conf ou /etc/bind/named.conf.  

utilisateur  Le compte de service propriétaire du processus. Ce compte doit naturellement être 
défini dans le fichier /etc/passwd.  

repertoire  Le répertoire dans lequel named sera enfermé. Souvent /var/named.  

Il sera bon de vérifier dans les journaux que le processus parvient bien à démarrer dans son nouvel environnement. 
En général, quelques essais sont nécessaires. 

4. Échange sécurisé entre serveurs 

De  nombreuses  fonctions  d’Internet  reposent  sur  le  DNS,  depuis  la  simple  navigation  jusqu’à  l’envoi d’e­mails.  Les 
tentatives de phishing, de plus en plus nombreuses, montrent bien les dangers que peut présenter une incertitude 
sur la résolution de noms. Si quelqu’un se connecte au site de sa banque en ligne en utilisant l’url exacte mais que le 
nom est résolu en l’adresse IP d’un faussaire, les conséquences peuvent évidemment être dramatiques. Dans le cas 
du DNS, la sécurisation reposera surtout sur l’authentification et l’intégrité des données. C’est­à­dire qu’on veut être 
certain que c’est bien le bon serveur qui nous répond, et que les données ne subissent pas de modification pendant 
le trajet. 

Nous allons utiliser ici le mécanisme TSIG : Transaction SIGnature (signature des transactions). Ce mécanisme repose 
sur la présence d’un secret partagé par les serveurs qui échangent des données. 

a. Génération du secret partagé 

Il existe un outil de génération des clés : dnssec­keygen. Il a de nombreux usages, mais nous le verrons ici dans le 
cadre d’une exploitation TSIG. 

Syntaxe dnssec­keygen pour utilisation dans le cadre de TSIG 

dnssec-keygen -a HMAC-MD5 -b taillecle -n nametype nomsecret

dnssec­keygen : variables et paramètres 

­a HMAC­MD5  ­a définit la méthode de cryptage. HMAC­MD5 est la seule valeur supportée pour 
TSIG.  

­b taillecle  ­b définit la valeur de la clé employée. Pour HMAC­MD5, taillecle doit être compris 
entre 1 et 512. 128 est une valeur courante généralement satisfaisante.  

­n nametype  ­n définit le propriétaire de la clé. Dans le cadre d’un fonctionnement TSIG, nametype 
aura généralement la valeur HOST pour signifier que la sécurisation se passe de 
machine à machine.  

nomsecret  Le nom du secret. Peut être n’importe quelle chaîne alphanumérique.  

La  commande  aboutit  à  la  génération  de  deux  fichiers  Knomsecret.+xxx.yyyyy.key  et 
Knomsecret.+xxx.yyyyy.private. 

Exemple d’utilisation de dnssec­keygen 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


donald:~# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST supersecret
Ksupersecret.+157+26824

donald:~# cat Ksupersecret.+157+26824.key


supersecret. IN KEY 512 3 157
yItYGlAQtGcM7VqGjZdJAg==

donald:~# cat Ksupersecret.+157+26824.private


Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: yItYGlAQtGcM7VqGjZdJAg==

b. Déclaration du secret dans named.conf 

Sur les serveurs concernés par la sécurisation, on inclura dans le fichier named.conf la définition du secret. 

Syntaxe de la déclaration de secret dans named.conf 

key nomsecret {
algorithm hmac-md5;
secret "yItYGlAQtGcM7VqGjZdJAg==";
};

Éléments employés dans cette syntaxe : 

key  Annonce la déclaration de la clé. 

nomsecret  Le nom du secret utilisé à la génération. 

algorithm  A pour paramètre le type d’algorithme utilisé. 

hmac­md5  Obligatoire pour TSIG.  

secret  A pour paramètre le secret généré dans le fichier Knomsecret.+xxx.yyyyy.key (la 
chaîne de caractères entre guillemets). 

c. Les deux serveurs doivent utiliser la clé 

La clé partagée étant déclarée sur les deux serveurs, il faut maintenant leur faire savoir qu’ils doivent l’utiliser pour 
garantir la sécurité de certaines communications. Il faudra donc ajouter une nouvelle commande dans named.conf. 

Syntaxe d’utilisation de la clé dans named.conf 

server ip_dest {
keys { nomsecret; };
};

Éléments employés dans cette syntaxe : 

server  Annonce un comportement pour un serveur déterminé. 

ip_dest  L’adresse IP du serveur pour lequel directive s’applique. 

keys  Annonce le secret utilisé pour sécuriser les échanges. 

nomsecret  Le nom du secret utilisé à la génération. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


d. Tout service est refusé en l’absence de signature 

Le  paragraphe  précédent  a  donné  aux  serveurs  la  capacité  de  communiquer  de  façon  sécurisée.  Il  faut  ensuite 
rendre obligatoire cette sécurisation pour les requêtes entre serveurs dans le cadre d’une délégation par exemple. 

Syntaxe 

zone « truc.fr » {
type master;
file « db.truc.fr »;
allow-recursion { key supersecret; };
};

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Configuration de base d’un serveur Apache 

1. Apache et les serveurs web 

Le  célèbre  Apache  est  le  serveur  Web  le  plus  connu  et  depuis  1996  au  moins  le  plus  répandu  sur  Internet.  Sa 
popularité vient de sa grande stabilité et de sa bonne tenue à la charge. Il est présent dans toutes les architectures à 
serveur de contenu dynamique LAMP et WAMP (Linux/Windows­Apache­MySQL­PHP), et sa structure modulaire le rend 
apte à la plupart des utilisations. 
Le serveur web est composé d’un script de lancement de service qui, en fonction d’un fichier de configuration, chargera 
les démons apache et d’éventuels modules fonctionnels. 

La  richesse  fonctionnelle  d’Apache  implique  souvent  un  fichier  de  configuration  impressionnant.  Toutefois,  la 
configuration d’un serveur basique est finalement assez simple à réaliser. 

2. Fichier de configuration 

a. Format du fichier de configuration 

Le  fichier  de  configuration  d’Apache,  selon  versions  et  options  de  compilation  httpd.conf,  apache.conf  ou 
apache2.conf,  est  composé  de  directives  suivies  de  valeurs.  Certaines  directives  sont  intégrées  dans  des 
conteneurs afin que leur champ d’application soit limité. 

Format type du fichier de configuration Apache 

directive1 valeur1
directive2 valeur2
...
<directive_conteneur valeur>
directive3 valeur3
directive4 valeur4
...
</directive_conteneur>

On  note  ici  des  directives  présentes  directement  dans  le  fichier  de  configuration,  et  d’autres  intégrées  dans  une 
section.  Cette  section  limitera  le  champ  d’application  des  directives  à  un  certain  contexte  de  fonctionnement.  La 
configuration d’Apache consistera à choisir les bonnes directives, leur affecter les bonnes valeurs, et construire les 
sections nécessaires. 
Parmi  les  innombrables  directives  Apache,  certaines  sont  fondamentales  et  devront  se  retrouver  dans  toute 
configuration Apache. 

Fichier de configuration : directives courantes 

ServerRoot  Indique le répertoire racine des fichiers de configuration. 

User  Désigne le compte de service propriétaire des processus Apache. 

Group  Désigne le groupe de service propriétaire des processus Apache. 

ErrorLog  Fichier de journalisation des erreurs. 

Include  Indique un fichier de configuration annexe à intégrer dans le fichier apache2.conf. 

Listen  Indique un port sur lequel le serveur sera à l’écoute. 

DocumentRoot  Indique le répertoire contenant les fichiers html. 

Exemple de fichier de configuration minimaliste 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Notez  que  si  cette  configuration  peut  fonctionner,  le  serveur  manquera  un  peu  de  confort,  par  exemple  en  ne 
reconnaissant  pas  les  fichiers  index.html  ou  index.htm.  Il  faudra  donc  préciser  dans  l’URL  le  nom  des  fichiers  html  à 
atteindre  en  tapant  par  exemple  http://A.B.C.D/index.html  si  le  répertoire  /var/www  contient  un  fichier  index.html.  De 
plus, les scripts de lancement de service pouvant être troublés par ce fichier de configuration minimaliste et en un seul 
morceau, il sera sans doute préférable de lancer l’exécutable apache directement sans passer par le script. 

ServerRoot /etc/apache2
User www-data
Group www-data
ErrorLog /var/log/apache2/error.log
Listen 80
DocumentRoot /var/www

b. Les directives de conteneur 

Nous avons vu que les directives servaient à appliquer un élément de configuration au serveur. Par exemple, la ligne 
de configuration Listen 80 dans le fichier de configuration est composée de la directive Listen qui indique sur quel 
port le serveur doit attendre des requêtes, et de la valeur 80 qui est le port HTTP standard. Placée directement dans 
le fichier de configuration, cette directive s’appliquera à l’ensemble du serveur. 
Il  existe  toutefois  des  éléments  de  configuration  qui  ne  concernent  qu’un  aspect  fonctionnel  du  serveur.  Par 
exemple,  des  directives  qui  ne  devraient  s’appliquer  qu’à  une  partie  limitée  d’un  site  web,  comme  des  pages  web 
protégées  toutes  situées  dans  une  arborescence  spécifique  du  système  de  fichiers.  Pour  ce  type  d’usage, Apache 
utilise des directives de conteneur. 
Les  directives  de  conteneur  ont  deux  vocations  :  grouper  un  ensemble  de  directives  de  configuration,  et  les 
appliquer à une partie limitée du serveur Apache. 

Syntaxe générique d’une directive de conteneur 

<directive_conteneur valeur>
directive3 valeur3
directive4 valeur4
...
</directive_conteneur>

Notez  que  toute  section  définie  par  une  directive  de  conteneur  entoure  la  directive  des  caractères  < >,  et  que  la 
section est terminée par le nom de la directive, précédé d’un slash. Entre le début et la fin de section se trouvent 
toutes les directives ordinaires qui s’appliquent au contexte fonctionnel défini par la directive de conteneur. 

Exemple de directive de conteneur 

La directive Directory est sans doute la directive de conteneur la plus facile à appréhender. Elle admet comme argument un 
répertoire et définit des paramètres spécifiques au contenu web situé dans ce répertoire. Dans l’exemple  ci­dessous, on 
indique que dans le répertoire /var/www/special et seulement dans ce répertoire, les liens symboliques peuvent être suivis 
par le serveur lors de la lecture des pages web. 

<Directory /var/www/special>
Options FollowSymLinks
</Directory>

c. Validation de la syntaxe 

Il est possible (et même prudent) de valider la syntaxe d’un fichier de configuration avant de lancer le service. 

Validation de la syntaxe du fichier apache2.conf 

exe_apache -t

Où exe_apache représente l’exécutable de lancement du serveur Apache. Les valeurs généralement rencontrées sont 
httpd, apache et apache2. 

d. Démarrage et arrêt du serveur 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


En situation de production, le démarrage et l’arrêt du serveur se fera par l’utilisation du script de gestion de service 
situé dans /etc/init.d. En phase de test toutefois, il est utile de démarrer ou d’arrêter le serveur ponctuellement. 

Démarrage ponctuel du serveur Apache 

exe_apache -k start

Arrêt du serveur Apache 

exe_apache -k stop

Où exe_apache représente l’exécutable de lancement du serveur Apache. Les valeurs généralement rencontrées sont 
httpd, apache et apache2. 
Il  est  aussi  possible  de  piloter  le  démon  apache  par  la  commande  de  contrôle  apache2ctl  avec  entre  autres  les 
mêmes paramètres start et stop. 

3. Les modules Apache 

a. Chargement des modules 

Le serveur web Apache a une structure modulaire, c’est­à­dire  que  les  fonctions  fondamentales  du  serveur  seront 


fournies par l’exécutable apache, alors que les fonctions accessoires seront assurées par des modules chargés à la 
demande  depuis  le  fichier  de  configuration.  Ces  modules  nécessitant  souvent  des  éléments  de  configuration 
supplémentaires, les directives associées aux modules devront être ajoutées elles aussi au fichier de configuration. 

Format standard de chargement de directive dans apache2.conf 

LoadModule id_module fichier_module


directive valeur

Fichier de configuration : Chargement de module 

LoadModule  Directive de chargement des modules. 

id_module  Identifiant de module. Valeur normalisée propre à chaque module. 

fichier_module  Le chemin absolu du fichier de module fourni avec Apache. 

Exemple de chargement de module 

Dans cet exemple le module chargé est dir_module dont la fonction est de simplifier l’écriture des URL par les utilisateurs 
et d’afficher un fichier html (en général index.html) même s’il n’est pas explicitement précisé. Le fichier exécutable de ce 
module est mod_dir.so. Une fois ce module chargé, il est possible d’appeler la directive DirectoryIndex qui demande de 
charger index.html si aucun fichier n’est précisé dans l’URL. 

LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so


DirectoryIndex index.html

b. Visualisation des modules 

La commande apache utilisée de façon interactive permet d’afficher les modules chargés. Les modules peuvent avoir 
deux origines : ils ont été appelés par la commande load depuis le fichier de configuration, ou ils ont été compilés 
dans le cœ ur du programme et sont chargés systématiquement. 

Visualisation des modules compilés dans le programme 

exe_apache -l

Visualisation des modules chargés 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


exe_apache -M

Exemple de visualisation des modules chargés 

L’option ­M affiche les modules statiques et ceux chargés depuis le fichier de configuration par la directive LoadModule. 

alpha:/etc/apache2# apache2 -l
Compiled in modules:
core.c
mod_log_config.c
mod_logio.c
worker.c
http_core.c
mod_so.c
alpha:/etc/apache2# apache2 -M
Loaded Modules:
core_module (static)
log_config_module (static)
logio_module (static)
mpm_worker_module (static)
http_module (static)
so_module (static)
alias_module (shared)
auth_basic_module (shared)
authn_file_module (shared)
authz_default_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgid_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
mime_module (shared)
negotiation_module (shared)
setenvif_module (shared)
status_module (shared)
Syntax OK
alpha:/etc/apache2#

c. Choix des modules 

Les modules dépendent naturellement de l’usage qui est fait du serveur. L’usage consiste à identifier les besoins, 
déterminer les directives associées à ces besoins, et vérifier sur la documentation en ligne Apache (section Directive 
de configuration à l’exécution) quels sont les modules impliqués. 

Supposons  qu’on  veuille  donner  aux  utilisateurs  l’accès  à  des  pages  personnelles  situées  dans  leur  répertoire 
personnel.  La  directive  UserDir  est  justement  faite  pour  cela.  Elle  admet  comme  paramètre  un  chemin  relatif  qui 
indique  l’emplacement  du  répertoire  personnel  de  l’utilisateur  où  placer  les  ressources  html  de  l’utilisateur.  Les 
documents seront alors accessibles par l’url http://serveur/~utilisateur/. 
Si  on  consulte  cette  directive  dans  la  documentation  en  ligne,  on  constate  qu’elle  est  dépendante  du  module 
mod_userdir. Il faudra donc configurer cette directive et s’assurer que le module sera chargé. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


 

Exemple de configuration de l’accès utilisateur 

Avec  la  configuration  de  l’accès  utilisateur,  l’url  http://serveur/~toto/doc.html  donnera  accès  au 
fichier /home/toto/web/doc.html sur le serveur. 

LoadModule userdir_module modules/mod_userdir.so


UserDir web

4. Gestion des ressources 

Contrairement à une idée reçue, le serveur Apache n’est pas forcément le plus rapide du marché et des produits au 
code  plus  simple  permettent  des  temps  de  réponses  plus  rapides  à  matériel  équivalent.  Toutefois  Apache,  par  sa 
gestion  intelligente  des  ressources,  et  la  pré­allocation  de  processus  permet  une  bien  meilleure  adaptation  à  la 
charge. 
Regardons les processus lancés par Apache sur un serveur inactif : 

alpha:~# ps -ef | grep apache


root 3244 1 0 Feb05 ? 00:00:04 /usr/sbin/apache2 -k start
www-data 3245 3244 0 Feb05 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 3247 3244 0 Feb05 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 3252 3244 0 Feb05 ? 00:00:00 /usr/sbin/apache2 -k start
alpha:~#

On constate la présence d’un processus exécuté par root, et de trois autres par le compte de service www­data. Le 
premier processus ne sert qu’à lancer les autres, qui eux traiteront les requêtes des clients. Le serveur observé ici ne 
gère  aucune  connexion  cliente,  et  pourtant,  trois  processus  ont  été  pré­alloués  pour  être  prêts  à  gérer  toute 
demande de clients. La gestion du premier service par le compte root est obligatoire, car c’est le seul apte à ouvrir le 
port 80 sur un système Linux. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI
Hôtes virtuels 
Il  est  fréquent  qu’un  serveur  Apache  physique  héberge  plusieurs  sites  web  différents.  C’est  ce  qui  permet  aux 
hébergeurs  de  gérer  les  sites  web  de  dizaines  de  clients  sur  un  seul  serveur.  Cette  technologie  est  connue  en 
environnement Apache sous le nom de « Virtual Host » (hôte virtuel). 

1. Configuration globale 

a. Gestion des contenus 

Si un serveur doit gérer des hôtes virtuels, c’est  qu’il doit héberger plusieurs contenus ou sites web différents. Il 
faudra  simplement  héberger  chacun  de  ces  contenus  dans  des  répertoires  différents  et  dûment  identifiés. 
L’hébergement  d’un  grand  nombre  de  sites  web  sur  un  seul  serveur  requiert  une  certaine  discipline  et  des 
conventions de dénomination rigoureuses. 

b. Organisation des sites virtuels 

Le fichier de configuration devra être quelque peu modifié. Chaque hôte virtuel lira ses éléments de configuration 
spécifiques  dans  des  conteneurs  déclarés  par  la  directive  VirtualHost.  Certaines  directives  de  portée  généraliste 
(DocumentRoot par exemple) ne seront plus exploitées, et devront être précisées pour chacun des hôtes virtuels 
dans le conteneur correspondant. 
Si  un  serveur  Apache  gère  des  hôtes  virtuels,  il  ne  fait  plus  que  cela.  C’est­à­dire  qu’il n’y  a  pas  de  configuration 
standard à laquelle s’ajoutent des configurations spécifiques pour les hôtes virtuels. Dès lors que des hôtes virtuels 
sont configurés, tout accès au serveur se fait par un hôte virtuel, fût­il le site de base. 

2. Configuration des hôtes virtuels 

Il existe deux techniques d’implémentation des hôtes virtuels : les hôtes virtuels sur adresses IP où le serveur fournit 
un  contenu  différent  selon  l’adresse  IP  par  laquelle  il  est  contacté,  et  les  hôtes  virtuels  par  noms  d’hôtes  où  le 
serveur fournit un contenu différent en fonction du nom d’hôte présent dans l’URL par lequel il est contacté. 

a. Hôtes virtuels sur adresse IP 

Le support des hôtes virtuels sur adresse IP est possible mais rarement utilisé. Dans cette configuration, le serveur 
dispose de plusieurs adresses IP et répond différemment selon que le serveur subit une requête HTTP sur l’une ou 
l’autre de ses interfaces. Une directive VirtualHost doit être utilisée pour chaque adresse IP utilisée. Elle contient la 
déclaration de répertoire contenant les données html correspondant au site virtuel. Cette déclaration se fait par la 
directive DocumentRoot. 

Déclaration de sites virtuels dans le fichier de configuration Apache 

<VirtualHost adresse_1:80>
ServerName nom1
DocumentRoot rep1
</VirtualHost>

<VirtualHost adresse_2:80>
ServerName nom2
DocumentRoot rep2
</VirtualHost>

Fichier de configuration : déclaration d’hôtes virtuels 

<VirtualHost>  Déclaration d’un hôte virtuel : tout ce qui se trouve dans le conteneur concerne 
l’hôte virtuel. 

adresse_x:80  L’hôte virtuel est éligible aux requêtes arrivant sur l’adresse IP configurée du 
serveur et sur le port 80. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


ServerName nom  Facultatif s’il existe une résolution de nom inverse. Sinon, peut renvoyer un 
message d’erreur non bloquant. 

DocumentRoot  Les pages web de cet hôte virtuel sont dans le répertoire rep. 
rep 

b. Hôtes virtuels sur nom d’hôte 

Le support des hôtes virtuels sur nom d’hôte nécessite une directive NameVirtualHost qui devra être placée dans 
le  contexte  général  du  fichier  de  configuration,  et  autant  de  directives  de  conteneur  VirtualHost  que  le  serveur 
devra héberger de sites virtuels. Pour bien comprendre l’organisation des sites virtuels, il faut se dire qu’il n’y a pas 
un site principal et des sites virtuels, mais que tout site hébergé doit faire l’objet d’un site virtuel. 
Comme  le  site  virtuel  est  reconnu  sur  son  nom  d’hôte,  la  directive  ServerName  doit  être  présente 
systématiquement dans les conteneurs d’hôte virtuel, et le nom associé doit être précisément celui par lequel les 
clients accéderont au serveur (le nom contenu dans l’URL). 
La  dernière  directive  obligatoire  dans  une  déclaration  d’hôte  virtuel  est  la  directive  DocumentRoot  qui  précisera 
l’emplacement des données web associées au site virtuel. 

Déclaration de site virtuel dans le fichier de configuration Apache 

NameVirtualHost *:80

<VirtualHost *:80>
ServerName nom1
DocumentRoot rep1
</VirtualHost>

<VirtualHost *:80>
ServerName nom2
DocumentRoot rep2
</VirtualHost>

Fichier de configuration : déclaration d’hôtes virtuels 

NameVirtualHost *:80  On gère des hôtes virtuels par noms. L’écoute des requêtes se fait sur le port 
80. 

<VirtualHost>  Déclaration d’un hôte virtuel : tout ce qui se trouve dans le conteneur 
concerne l’hôte virtuel. 

*:80  L’hôte virtuel est éligible aux requêtes arrivant sur n’importe quelle adresse IP 
du serveur et sur le port 80. 

ServerName nom  Cet hôte virtuel sera éligible aux requêtes vers le nom de serveur nom. Il sera 
actif pour les requêtes vers http://nom. 

DocumentRoot rep  Les pages web de cet hôte virtuel sont dans le répertoire rep. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Restriction de l’accès utilisateur 
Apache offre de nombreuses possibilités de restrictions de l’accès utilisateur et il existe de nombreux moyens de gérer 
l’accès  aux  données.  Il  est  à  noter  que  ce  paragraphe  ne  traite  que  de  méthodes  d’authentification  des  utilisateurs, 
mais n’apporte aucune confidentialité. C’est­à­dire que l’accès aux données pourra être soumis à authentification, mais 
que les pages web circuleront en clair entre le serveur et le navigateur. Si on souhaite la confidentialité des échanges, il 
faudra utiliser le protocole SSL vu plus loin. 

1. Restriction de l’accès aux pages web 

a. Déclaration du répertoire à protéger 

La  restriction  se  fait  pour  un  répertoire  dont  le  contenu  n’est  visible  qu’après  authentification.  Si  on  souhaite 
restreindre l’accès à un site complet, il suffit de restreindre l’accès au répertoire racine du contenu web. Toutefois, 
l’usage  veut  qu’une  page  d’accueil  soit  disponible  à  tous,  et  que  toute  navigation  ultérieure  soit  soumise  à 
authentification. 

Déclaration d’une section de répertoire dans apache2.conf 

<Directory répertoire>
...
</Directory>

Où répertoire représente le chemin absolu du répertoire dont il faut protéger l’accès. Notez les points de suspension 
qui représentent les directives spécifiques qui seront appliquées au contenu de ce répertoire. 

b. Directives d’authentification 

Dans la section de répertoire soumis à authentification, il faut ensuite ajouter toutes les directives nécessaires selon 
le mode d’authentification choisi. Certaines de ces directives se retrouveront dans la plupart des circonstances. 

Demande d’authentification 

AuthName "texte"
Require valid-user
Directive_auth paramètre_auth

Fichier apache2.conf : demande d’authentification pour un répertoire 

AuthName  Définit le titre de la boîte de dialogue qui imposera une authentification à l’utilisateur. 

texte  Titre de la boîte de dialogue qui imposera une authentification à l’utilisateur. 

Require valid­user  Directive imposant un fonctionnement spécifique avec son paramètre valid­user qui 
exige que l’utilisateur soit correctement authentifié. 

Directive_auth  La ou les directives d’authentification en fonction de la méthode choisie. 

Nous  avons  employé  ici  le  paramètre  valid­user  pour  indiquer  que  tout  utilisateur  authentifié  peut  accéder  aux 
données  protégées.  On  aurait  aussi  pu  employer  user  x  ou  group  y  pour  limiter  l’accès  à  un  utilisateur  ou  aux 
membres d’un groupe. 

2. Authentification locale 

a. Création d’une base de compte locale 

La  création  d’un  fichier  de  comptes  locaux  pour  l’authentification  des  visiteurs  apache  est  une  façon  simple  et 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


courante  de  gérer  les  identités.  Il  s’agit  d’un  fichier  unique  contenant  une  ligne  par  utilisateur  déclaré.  Cette 
méthode convient donc bien dans le cadre d’un nombre limité d’utilisateurs. 

La commande htpasswd permet de créer la base de compte puis de l’alimenter. 

Création du premier compte utilisateur 

htpasswd -c fichier nom_utilisateur

Ajout de compte utilisateur 

htpasswd fichier nom_utilisateur

Suppression d’un compte utilisateur 

htpasswd -D fichier nom_utilisateur

Commande htpasswd : options et paramètres 

­c  Nécessaire si le fichier n’existe pas encore. Si le fichier existe déjà, il est écrasé. 

fichier  Le fichier contenant la base de compte. 

nom_utilisateur  Le nom du compte créé. 

­D  Supprime l’utilisateur dont le nom est donné en référence. 

Exemple de fichier de mot de passe 

Le fichier affiche sur chaque ligne le nom du compte utilisateur et son mot de passe crypté. 

alpha:~# cat httpmdp


toto:x4OpUoo9KBR1o
titi:o9zeMsxnhS45M
tata:hQcfUWksuIAmk
alpha:~#

b. Chargement des modules d’authentification 

Certains  modules  doivent  être  chargés  pour  que  nos  directives  soient  reconnues.  Il  faudra  charger  au  minimum  le 
module  auth_basic  pour  permettre  l’authentification  par  fichier  local,  le  module  authn_file  pour  gérer  cette 
authentification,  et  enfin  le  module  authz_user,  qui  gère  l’autorisation  de  l’accès  aux  pages  protégées.  Cette 
profusion  de  modules  peut  inquiéter,  mais  un  minimum  de  rigueur  rend  les  choses  plus  faciles  :  pour  chacune  des 
directives employées, la documentation en ligne précisera systématiquement quels modules doivent être chargés. 

Chargement des modules 

Les trois modules sont nécessaires à l’authentification des utilisateurs. 

LoadModule auth_basic_module /chemin/mod_auth_basic.so


LoadModule authn_file_module /chemin/mod_authn_file.so
LoadModule authz_user_module /chemin/mod_authz_user.so

c. Configuration de l’authentification locale 

Dans  la  section  de  répertoire  soumis  à  authentification,  il  faudra  ensuite  ajouter  les  directives  nécessaires  à 
l’authentification locale. 

Directives pour authentification locale 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


AuthType Basic
AuthUserFile fichier

Où fichier représente le fichier contenant la base de compte utilisée pour l’authentification avec les mots de passe 
des utilisateurs. 

Exemple de fichier apache2.conf avec authentification 

ServerRoot /etc/apache2
User www-data
Group www-data
ErrorLog /var/log/apache2/error.log
Listen 80
DocumentRoot /var/www

LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so


DirectoryIndex index.html

LoadModule auth_basic_module /usr/lib/apache2/modules/mod_auth_basic.so


LoadModule authn_file_module /usr/lib/apache2/modules/mod_authn_file.so
LoadModule authz_user_module /usr/lib/apache2/modules/mod_authz_user.so
<Directory /var/www>
AuthType basic
AuthUserFile /root/httpmdp
AuthName "Veuillez vous identifier"
Require valid-user
</Directory>

3. Authentification par annuaire LDAP 

Il  existe  plusieurs  moyens  pour  exploiter  un  annuaire  LDAP  en  tant  que  base  d’authentification.  La  configuration  ci­
dessous est donc donnée à titre d’exemple. 

a. Vérification de disponibilité des informations de l’annuaire 

Considérons que nous disposons d’un annuaire LDAP avec les caractéristiques suivantes : 

● Adresse IP : 192.168.1.11 

● Contexte des comptes utilisateurs : ou=users,dc=annu,dc=fr 

● Nom distinctif de l’administrateur : cn=admin,dc=annu,dc=fr 

Exemple d’interrogation de l’annuaire 

Il  est  vivement  recommandé  de  vérifier  que  l’annuaire  est  bien  en  ligne  et  accessible  avec  les  bonnes  informations 
(adresse IP et contexte LDAP) avant de configurer l’authentification LDAP pour une application quelle qu’elle soit. 

toto@serveur# ldapsearch -x -D cn=admin,dc=annu,dc=fr -W -h


192.168.1.11 -b ou=users,dc=annu,dc=fr -s sub ObjectClass=*
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=annu,dc=fr> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# annu.fr
dn: dc=annu,dc=fr
objectClass: domain

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


dc: annu
(...)
# toto, users.annu.fr
dn: uid=toto,ou=users,dc=annu,dc=fr
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
(...)
toto@serveur#

b. Chargement des modules nécessaires 

Les modules nécessaires à l’authentification LDAP sont les suivants : 

● auth_basic 

● authn_file 

● authz_user 

● authnz_ldap 

c. Configuration de l’authentification 

Il  faudra  ensuite  utiliser  les  directives  d’authentification  dans  une  section  de  répertoire.  Le  point  d’orgue  de  la 
configuration sera déclaration de la directive AuthLDAPUrl. 

Directives utilisées pour l’authentification LDAP 

Si la syntaxe peut sembler impressionnante, elle n’est pas due au hasard ou à l’imagination du développeur. Le format des 
URL LDAP est défini dans la RFC2255 et est utilisé dans quelques applications. 

AuthName "Texte"
AuthType Basic
Require Valid-user
AuthLDAPUrl ldap://192.168.1.11/ou=users,dc=annu,dc=fr?cn?sub?objectclass=*

4. Authentification simple par fichier .htaccess 

Les bonnes pratiques Apache indiquent d’utiliser une directive Directory à chaque fois qu’une configuration spécifique 
doit  s’appliquer  au  contenu  d’un  répertoire  et  de  placer  dans  le  bloc  défini  par  cette  directive  les  éléments  de 
configuration  spécifiques  à  ce  répertorie.  Une  méthode  alternative  consiste  à  placer  un  fichier  .htaccess  dans  le 
répertoire en question, et d’y intégrer les directives devant s’appliquer au contenu du répertoire. 

Exemples comparés d’exploitation 

Extrait de fichier de configuration Apache avec la directive Directory : 

...
<Directory /var/www/prot>
AllowOverride all
authType basic
AuthName "Veuillez vous identifier"
Require valid-user
AuthUserFile /etc/httpd/mdp
</Directory>
...

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Contenu  du  fichier  /var/www/prot/.htaccess  utilisé  pour  configurer  une  authentification  depuis  le  répertoire  des  données 
html : 

authType basic
AuthName "Veuillez vous identifier"
Require valid-user
AuthUserFile /etc/httpd/mdp

Il peut arriver que les deux configurations se trouvent en conflit, et qu’une directive soit configurée de façon spécifique 
pour  un  répertoire  dans  un  contexte  directory,  et  que  la  même  directive  soit  configurée  différemment  dans  un 
fichier  .htaccess  du  même  répertoire.  En  ce  cas,  la  directive  AllowOverride  permet  de  préciser  quelle  sera  la 
configuration retenue. 

Valeurs courantes de la directive AllowOverride 

all  Valeur par défaut : Toute directive est autorisée dans les fichiers .htaccess. 

none  Aucune directive n’est autorisée dans les fichiers .htaccess et les fichiers .htaccess 
sont ignorés. 

AuthConfig  Autorise les directives relatives aux mécanismes d’authentification. 

Il est vivement recommandé de ne pas appliquer de directive AllowOverride All au répertoire racine de votre 
serveur  web  (Valeur  par  défaut  !).  Il  faut  plutôt  définir  cette  valeur  à  None,  et  créer  une  directive  Directory 
avec  la  directive  AllowOverride  configurée  pour  le  seul  répertoire  concerné.  Cette  méthode  augmente  la  sécurité, 
mais aussi la performance en évitant au serveur web de chercher un hypothétique fichier .htaccess dans chacun des 
répertoires visités. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Configuration d’Apache avec SSL 
SSL : Secure Socket Layer est un protocole de sécurisation des couches applicatives. Il fonctionne avec de nombreux 
protocoles,  mais  son  usage  le  plus  répandu  est  la  sécurisation  de  http  (https).  SSL  apporte  des  services 
d’authentification, de confidentialité et de contrôle d’intégrité. 

1. Cryptographie et certificats 

Une  explication  exhaustive  de  la  cryptographie  et  des  certificats  numériques  X509  dépasserait  de  beaucoup  les 
objectifs  de  ce  livre.  Toutefois,  l’utilisation  de  certificats  est  obligatoire  pour  sécuriser  l’accès  aux  pages  web  d’un 
serveur par SSL (https). 

a. Concepts cryptographiques 

Toute  infrastructure  cryptographique  repose  sur  des  algorithmes  de  cryptage.  Ces  algorithmes  appartiennent 
forcément à trois familles distinctes : les algorithmes symétriques où on crypte et décrypte avec une clé unique, les 
algorithmes asymétriques, où l’on  dispose  d’une paire de clés, l’une pour crypter et l’autre pour décrypter, et enfin 
les algorithmes de hachage, à sens unique et n’exploitant pas de clé de cryptage. 
La  cryptographie  asymétrique  exploite  deux  clés.  Par  convention,  on  décide  qu’une  de  ces  clés  sera  privée  et  ne 
devra  être  exploitée  que  par  son  propriétaire,  et  l’autre  sera  publique,  et  pourra  être  vue  de  tous,  même  des 
personnes hostiles. La consommation importante en ressources processeur de la cryptographie asymétrique la rend 
inapte  au  cryptage  de  grandes  quantités  de  données,  mais  les  nombreuses  possibilités  offertes  par  les  clés 
publiques et privées en font un outil incontournable. La clé publique servira au cryptage de petites données (comme 
d’autres  clés,  symétriques  par  exemple),  alors  que  la  clé  privée  sera  utilisée  pour  les  opérations  de  signature 
numérique (on signe avec quelque chose qui n’appartient qu’à soi). 

b. Les certificats numériques X509 

Si  les  algorithmes  utilisés  couramment  sur  Internet  et  dans  les  entreprises  sont  réputés  fiables,  l’analyse  des 
systèmes  cryptographiques  montre  que  la  vulnérabilité  vient  souvent  des  risques  liés  à  la  transmission  de  la  clé 
publique d’un utilisateur ou d’un serveur. La conception même de la cryptographie asymétrique fait que cette clé est 
strictement inutilisable seule, et qu’elle ne permet en rien de déduire la valeur de la clé privée. Toutefois, les failles 
des  échanges  confidentiels  ou  des  signatures  numériques  de  documents  reposent  toutes  sur  des  clés  publiques 
dont  le  nom  du  propriétaire  serait  usurpé.  En  clair,  une  clé  publique  circule,  mais  ce  n’est  pas  la  bonne,  et  un 
intrigant fait passer sa clé publique pour celle d’un autre. La personne trompée pourrait alors crypter des éléments 
très confidentiels avec la mauvaise clé et donc mettre ces informations en danger. 
Les certificats numériques X509 ont pour but d’établir de façon formelle un lien entre une identité (nom, adresse IP, 
etc.) et une clé publique. Les certificats ne peuvent être contrefaits car ils sont signés par un tiers en qui toutes les 
parties placent leur confiance. Ces tiers sont appelés « Certificate Authority » (autorité de certification). Ils peuvent 
être publics et reconnus de tous ou privés et utilisés dans un cadre restreint. Dans ce cas­là, les applications clientes 
devront être configurées pour reconnaître l’autorité de certification qui aura émis les certificats. 
Dans le cadre de l’utilisation de certificat pour un serveur web, le serveur doit disposer d’un certificat qui atteste de 
son  identité  :  une  clé  publique  liée  à  son  nom  d’hôte.  Lors  d’une  connexion  https  de  la  part  d’un  navigateur,  le 
serveur envoie son certificat, le navigateur en vérifie la validité, puisque le nom sous lequel on accède au serveur est 
bien celui annoncé dans le certificat. Dans le cas contraire, le navigateur oppose une alerte de sécurité. L’utilisateur 
est alors libre de laisser la connexion sécurisée s’établir ou non, mais sans savoir si le serveur auquel il s’adresse est 
légitime ou s’il s’agit d’un usurpateur. 

c. Génération locale d’un certificat 

Le fonctionnement de HTTP avec SSL requiert qu’un certificat contenant la clé publique du serveur web soit envoyé 
au navigateur client et que cette clé publique soit toujours envoyée sous forme de certificat. Apache configuré pour 
SSL doit donc disposer d’un certificat qu’il pourra envoyer à ses clients. 

Le certificat utilisé pour Apache pourra être fourni par une autorité de certification publique ou privée fournie par une 
application spécialisée. Dans cette hypothèse, l’autorité fournira un certificat qui sera exporté sous forme de fichier, 
copié sur le disque du serveur Apache, et exploité par le serveur. 
Dans le cas d’un usage ponctuel ou à des fins de test, on peut aussi générer localement un certificat prêt à l’emploi 
qui  sera  exploitable  par  le  serveur  Apache.  Il  existe  des  utilitaires  spécialisés  dans  cette  fonction,  mais  qui  sont 
généralement  liés  à  une  distribution,  ou  on  peut  le  créer  de  toutes  pièces  avec  les  utilitaires  de  la  bibliothèque 
openssl.  Pour  des  besoins  limités  au  test  de  la  configuration  ssl  d’Apache,  on  choisira  la  solution  la  plus  simple,  à 
savoir utiliser les mêmes clés pour générer le certificat et pour le signer. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Génération du certificat auto­signé 

openssl req -x509 -nodes -newkey rsa:taille -keyout fichier_clé -out fichier_certificat

Commande openssl pour génération de certificat : options et paramètres 

req  Demande de certificat. 

­x509  On souhaite un certificat auto­signé et non une demande de signature. 

­nodes  La clé de serveur ne doit pas être protégée par un mot de passe. 

­newkey rsa:taille  On crée de nouvelles clés asymétriques RSA dont la taille est donnée en 
nombre de bits. 

­keyout fichier_clé  Le fichier qui contiendra la clé privée du serveur. 

­out fichier_certificat  Le fichier qui contiendra le certificat du serveur. 

La  commande  ci­dessus  génère  la  demande  de  certificat.  Les  champs  normalisés  du  certificat  sont  demandés 
interactivement  à  l’utilisateur.  La  plupart  de  ces  champs  sont  informatifs,  mais  dans  le  cadre  de  l’utilisation  de 
certificat  pour  un  serveur  web,  le  champ  Common  Name  (nom  commun)  doit  impérativement  correspondre  au  nom 
DNS qui figurera dans l’URL d’accès au serveur. Dans le cas contraire, le navigateur du client opposera une alerte de 
sécurité lors de la vérification du certificat de serveur. 

Exemple de génération de certificat 

Il est impératif de renseigner correctement le champ Common Name (CN). C’est celui qui sera associé formellement à la 
clé publique dans le certificat numérique. 

root@serveur# openssl req -x509 -nodes -newkey rsa:1024 -keyout


serveur.cle -out certificat.pem
Generating a 1024 bit RSA private key
......++++++
.................++++++
writing new private key to ’serveur.cle’
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ’.’, the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lyon
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:R&D
Common Name (eg, YOUR name) []:192.168.1.1
Email Address []:
root@serveur#

2. Configuration ssl 

a. Chargement du module SSL 

Le module nécessaire au fonctionnement SSL est mod_ssl. 

Chargement du module 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


LoadModule ssl_module /chemin/mod_ssl.so

Où chemin est le chemin absolu du fichier de module. Le chemin par défaut dépend de la façon dont Apache a été 
compilé et donc de la distribution. 

b. Configuration des clés de serveur 

Il faut ensuite préciser au serveur quelles sont les clés à utiliser pour son fonctionnement SSL. Il doit disposer de sa 
clé privée, et de son certificat qui contiendra sa clé publique. 

Configuration des clés 

SSLCertificateFile /chemin/fichier_certificat
SSLCertificateKeyFile /chemin/fichier_clé

Fichier apache2.conf : Déclaration des clés de serveur 

SSLCertificateFile  Désignation du fichier contenant le certificat de serveur. 

SSLCertificateKeyFile  Désignation du fichier contenant la clé privée de serveur. 

c. Gestion du fonctionnement SSL 

Il  n’y  a  plus  qu’à  demander  au  serveur  d’écouter  sur  le  port  https,  et  à  démarrer  le  moteur  SSL  qui  une  fois 
l’authentification réalisée, permettra le cryptage des échanges entre le client et le serveur. 

Ouverture du port https 

Listen 443

Activation du moteur SSL 

SSLEngine on

Ces deux paramètres étant bien entendu à ajouter dans le fichier de configuration Apache. 

d. Authentification des clients par certificat 

Le fonctionnement SSL standard que nous venons d’établir est celui qu’on trouve sur Internet en général et satisfera 
à  la  plupart  des  besoins.  Il  est  toutefois  possible  d’utiliser  les  certificats  non  pour  transmettre  une  clé  de  session 
chiffrée  et  donc  assurer  la  confidentialité  mais  pour  garantir  l’identité  d’un  client  se  connectant  au  serveur.  Dans 
cette configuration, le navigateur client doit disposer d’un certificat qui sera vérifié par le serveur web. Pour ce faire, 
le serveur Apache doit posséder le certificat de l’autorité ayant émis les certificats clients. 

Gestion de l’authentification par certificats dans le fichier de configuration Apache 

SSLVerifyClient require
SSLCACertificateFile certificat-ca

Où certificat­ca représente le fichier de certificat d’autorité qui aura signé les certificats clients. Les certificats clients 
sont à installer dans le magasin de certificats du navigateur Internet. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Serveur proxy 

1. Les serveurs proxy 

Un  serveur  proxy  est  chargé  d’effectuer  une  requête  au  nom  d’un  client  vers  un  autre  serveur  pour  un  protocole 
donné. Le terme français pour proxy est d’ailleurs « mandataire », le serveur étant mandaté pour effectuer une action 
au  nom  du  client.  On  dit  qu’un  serveur  proxy  travaille  en  rupture  de  flux.  La  plupart  des  proxys  travaillent  avec  le 
protocole HTTP, et si on parle de proxy sans préciser le protocole applicatif, il s’agit d’un proxy web (HTTP). 

a. Protection des clients 

Les serveurs proxys étant les seuls à aller sur Internet (en principe, tout client doit passer par le proxy pour obtenir 
un contenu provenant d’Internet), ils sont en première ligne en cas d’agissement hostile de l’extérieur. Un serveur 
proxy correctement configuré assurera donc une protection naturelle des navigateurs Internet sur le réseau. 

b. Serveurs de cache 

Toutes les requêtes passent par le proxy, le proxy récupère les données sur le serveur et les retransmet au client. 
Dans la plupart des cas, le serveur conserve sur son disque une copie de ces données afin de répondre directement 
aux  clients  suivants  s’ils  font  les  mêmes  requêtes.  La  navigation  des  clients  est  donc  accélérée  puisqu’il  n’est pas 
nécessaire de systématiquement relayer les demandes vers les serveurs web. 
La généralisation du haut débit rend les bénéfices de proxys serveurs de cache moins spectaculaires. 

c. Filtrages 

Les  serveurs  proxys  ont  la  possibilité  de  refuser  tout  ou  partie  de  leurs  requêtes  à  certains  clients.  On  peut  alors 
refuser en bloc toute navigation, ou filtrer certaines url pour empêcher la navigation sur des sites non professionnels 
par exemple. Le serveur proxy est supérieur au pare­feu  pour  cette  fonction  car  le  proxy « comprend  » ce  qui  est 
demandé (une URL), alors que le pare­feu se borne à autoriser ou interdire tout trafic sur un port (80 pour Internet) 
sans distinguer les sites web visités. 

d. Inconvénients 

Les  serveurs  proxy  ne  sont  pas  sans  inconvénients.  Ils  supposent  une  configuration  spécifique  des  clients  (on 
précise alors l’adresse IP du proxy au navigateur), et sont limités à un protocole applicatif, nécessitant alors d’autres 
mécanismes  de  protection  ou  d’optimisation  pour  chacun  des  protocoles.  Pour  chaque  déploiement  envisagé  de 
proxy, il conviendra donc d’estimer précisément les avantages et inconvénients générés par le proxy. 

2. Le serveur proxy squid 

a. Configuration de base 

Squid est composé d’un service dont le script de lancement normalisé trouve sa configuration dans un fichier unique 
squid.conf, généralement situé dans /etc/squid. 

La  configuration  de  squid  dans  un  mode  de  fonctionnement  standard  (rupture  de  flux  pour  les  accès  clients  et 
quelques  listes  d’accès  pour  gérer  les  autorisations)  n’a  rien  de  bien  difficile,  mais  dans  la  plupart  des 
implémentations,  le  fichier  de  configuration  par  défaut  de  squid  a  de  quoi  impressionner.  Sur  le  paquetage  fourni 
avec  debian  par  exemple,  le  fichier  fait  près  de  5000  lignes,  dont  environ  un  pour  cent  seulement  sont  lues  au 
démarrage du service. 

Fichier squid.conf d’un paquetage debian sans commentaires 

Constatez  qu’un  certain  nombre  de  liste  de  contrôle  d’accès  (acl)  ainsi  que  de  règles  sont  définies  par  défaut.  Ceci  ne 
dispense pas d’une configuration précise du proxy pour assurer la meilleure sécurité. 

# grep ^[^#] squid.conf


acl all src all

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
icp_access allow localnet
icp_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid/access.log squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern (Release|Package(.gz)*)$ 0 20% 2880
refresh_pattern . 0 20% 4320
acl shoutcast rep_header X-HTTP09-First-Line ^ICY\s[0-9]
upgrade_http0.9 deny shoutcast
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache
extension_methods REPORT MERGE MKACTIVITY CHECKOUT
visible_hostname beta
hosts_file /etc/hosts
coredump_dir /var/spool/squid

Sans configuration particulière, un serveur proxy squid fait naturellement office de serveur de cache, et protège les 
réseaux locaux par une rupture de flux (les requêtes des navigateurs ne vont pas sur Internet, mais s’arrêtent au 
proxy qui va consulter les serveurs en leur lieu et place). 

Avant qu’il puisse fonctionner, un serveur a tout de même besoin d’un minimum de configuration. 

Configuration minimum d’un proxy squid dans le fichier squid.conf 

http_port numero_port
cache_dir ufs repertoire taille rep_niveau_1 rep_niveau_2
visible_hostname nom_serveur

Fichier squid.conf : configuration de base 

numero_port  Le numéro de port sur lequel le serveur écoute et qui doit être configuré sur les 
navigateurs. La valeur par défaut est 3128, et 8080 est une valeur historique 
courante. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


repertoire  Le répertoire dans lequel les données mises en cache sont stockées. 

taille  Taille en Mégaoctets maximum pour les données mises en cache. Valeur par défaut : 
100 Mo. 

rep_niveau_1  Nombre de sous­répertoires de premier niveau maximum du répertoire de cache. 
Valeur par défaut : 16. 

rep_niveau_2  Nombre de sous­répertoires de deuxième niveau maximum du répertoire de cache. 
Valeur par défaut : 256. 

nom_serveur  Nom d’hôte du serveur proxy. Ce nom apparaît notamment dans les journaux 
d’activité. 

b. Gestion des accès clients 

Il s’agit ensuite de préciser qui peut ou ne peut pas accéder à Internet par l’Intermédiaire du serveur proxy. 

La  première  étape  est  de  définir  des  hôtes  ou  ensembles  d’hôtes  (groupes,  réseaux)  auquel  on  appliquera  une 
autorisation. Ces groupes sont créés sous le nom d’acl (acces control list). 

Définition de listes de contrôle d’accès dans le fichier squid.conf 

acl nom_liste type_acl A.B.C.D/M

Fichier squid.conf : définition d’acl 

nom_liste  Le nom de la liste créé. Valeur alphanumérique quelconque. 

type_acl  src  Définition des adresses d’expéditeurs. 

dst  Définition des adresses de destinataires. 

A.B.C.D/M  Adresse de réseau et masque de sous réseau (nombre de bits du masque). 

Adresse d’hôte et masque de sous réseau (nombre de bits du masque). 

Intervalle d’adresses : A.B.C.D­E.F.G.H/M (nombre de bits à 1 du masque). 

Exemple de définition d’acl 

Notez la définition de l’acl « all » qui désigne tous les réseaux possibles. 

acl all src all


acl rezo_local src 192.168.1.0/24
acl serveurs_interdits dst 172.11.5.2-172.11.5.5/24

Il n’y a plus qu’à faire savoir à squid quoi faire de ces acl. 

Autorisation des acl dans le fichier squid.conf 

http_access autorisation nom_acl

Fichier squid.conf : autorisation d’acl 

autorisation  Autorisation ou refus de l’acl. Les deux valeurs possibles sont allow et deny. 

nom_acl  Le nom de la liste à autoriser ou refuser. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Exemple d’autorisations d’acl 

Chaque acl est traitée selon un contrôle d’accès allow ou deny. 

acl all src all


acl rezo_local src 192.168.1.0/24
acl serveurs_interdits dst 172.11.5.2-172.11.5.5/24
http_access deny serveurs_interdits
http_access allow rezo_local
http_access deny all

Il est possible de définir des acl dans un fichier extérieur au fichier de configuration principal. 

Intégration d’un fichier d’acl dans le fichier de configuration 

acl nom_acl "fichier_acl"

Où  fichier_acl  représente  le  chemin  absolu  du  fichier  contenant  les  acls.  Ce  fichier  doit  impérativement  être  entre 
doubles quotes. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Les MTA 
Les  MTA  (Mail  Transfer  Agent)  sont  les  serveurs  assurant  l’envoi  et  la  réception  de  messages  électroniques  et 
constituent l’ossature de tout système de messagerie sur les réseaux IP. Ils sont les serveurs qui gèrent les courriers 
électroniques  pour  un  domaine  de  messagerie  donné.  Chaque  serveur  de  messagerie  public  est  un  MTA  et  tous  les 
MTA communiquent entre eux sur Internet par le protocole SMTP. 

1. Le protocole SMTP 

Le  protocole  SMTP  (Simple  Mail  Transfer  Protocol)  est  utilisé  pour  transférer  des  courriers  électroniques  vers  des 
serveurs de messagerie. SMTP peut être employé depuis un client de messagerie (Outlook, Thunderbird, etc.) pour 
remettre  un  message  électronique  à  son  serveur  de  messagerie,  mais  aussi  entre  les  serveurs  de  messagerie  de 
l’expéditeur et celui du destinataire. Nous avons vu au chapitre DNS que les enregistrements MX associés au nom de 
domaine du destinataire permettaient de trouver l’adresse IP du serveur. Une fois arrivé à destination, le message 
est  conservé  jusqu’à  ce  que  son  destinataire  en  prenne  connaissance.  La  lecture  du  message  peut  se  faire 
directement sur le serveur ou après téléchargement auprès d’un MDA (Mail Delivery Agent) par un protocole de retrait 
de courrier (POP ou IMAP). 
SMTP exploite une syntaxe basique facilement testable depuis un client telnet ou nc. 

Exemple d’utilisation en ligne de commande du protocole SMTP 

alpha:~# telnet 192.168.199.10 25


Trying 192.168.199.10...
Connected to 192.168.199.10.
Escape character is ’^]’.
ehlo toto.com
220 alpha.localdomain ESMTP Postfix
250-alpha.localdomain
250-PIPELINING
250-SIZE 1000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <toto@toto.com>
250 2.1.0 Ok
RCPT TO: <toto>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Bonjour
Comment ca va ?
.
250 2.0.0 Ok: queued as E264474E02
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
alpha:~#

La  commande  ehlo  est  utilisée  par  défaut  sur  tous  les  systèmes  récents  et  elle  demande  au  serveur 
d’afficher  ses  extensions  SMTP  supportées.  Les  systèmes  plus  anciens  (avant  2001)  utilisent  la  commande 
helo. 

2. Présentation de Sendmail 

SendMail est le plus ancien et peut­être historiquement le plus célèbre MTA utilisé sur Internet. Il a été écrit avant 
même la création du protocole SMTP et à l’époque, les messages étaient transférés en FTP d’un serveur à un autre. Il 
n’était pas non plus question de MDA ni de protocole de retrait de courrier et toute lecture de message reçu se faisait 
directement sur le serveur. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Sendmail  ne  soulève  pas  immédiatement  l’enthousiasme  de  tous  pour  deux  raisons  :  datant  d’une  époque  où  les 
risques  de  piratage  se  limitaient  à  des  blagues  de  potaches,  il  a  souvent  été  configuré  sans  grandes  options  de 
sécurité  et  a  ainsi  participé  à  son  corps  défendant  au  relais  de  millions  de  spams.  D’autre  part,  les  difficultés 
d’approche de la configuration de Sendmail peuvent décourager les plus enthousiastes. 
Les  nombreuses  évolutions  et  réécritures  de  Sendmail  en  font  aujourd’hui  un  outil  parfaitement  fiable,  et  il  passe 
pour être un des MTA les plus puissants et les plus rapides du marché. 

3. Présentation d’Exim 

Exim  est  un  MTA  relativement  récent  (ses  premiers  développements  datent  de  1995)  qui  poursuit  un  objectif  de 
robustesse et de flexibilité. Il est le MTA fourni par défaut sur les distributions Debian et la plupart de ses dérivées. 

4. Présentation de Postfix 

Postfix  est  dans  le  domaine  de  l’open  source  le  MTA  le  plus  populaire,  et  il  est  presque  facile  à  configurer.  De 
nombreux hébergeurs et fournisseurs d’accès utilisent Postfix pour gérer les boîtes mail de leurs clients. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Le serveur SMTP Postfix 

1. Configuration de Posfix 

a. Gestion des identités 

Un MTA doit gérer des comptes de messagerie pour son domaine, ce qui implique que le serveur doit gérer la liste 
des utilisateurs titulaires d’une adresse mail dans le domaine de messagerie. Les MTA sont généralement capables 
d’exploiter des bases de comptes utilisateurs sous différents formats : fichiers locaux de bases de comptes locales, 
annuaire ldap, bases de données MySQL, etc. 

La  solution  la  plus  simple,  toujours  disponible  et  qui  ne  nécessite  aucune  configuration  particulière,  est  d’utiliser 
directement les comptes du système Linux. 

b. Gestion des alias 

En général, la base de comptes utilisée par un MTA désigne quelles adresses mail sont susceptibles de recevoir des 
messages  électroniques.  Toutefois,  il  arrive  qu’un  utilisateur  soit  le  gestionnaire  de  plusieurs  boîtes  mail.  Il  est 
fréquent  par  exemple  que  l’administrateur  d’un  réseau  doive  répondre  aux  messages  adressés  à 
postmaster@domaine.ext. C’est même une préconisation de la RFC SMTP. Pour ce type d’usage, un MTA utilise une 
base  de  correspondances  entre  comptes  appelés  alias.  Postfix  utilise  un  fichier  de  déclaration  des 
alias /etc/aliases et les exploite dans une base de données générée à partir du fichier d’alias par une commande 
postalias. 

Fichier de déclaration des alias 

# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: toto

Toute  modification  du  fichier  /etc/aliases  devra  être  suivie  d’une  redéclaration  de  la  base  par  la  commande 
postalias. 

Génération de la base à partir du fichier 

alpha:~# postalias /etc/aliases


alpha:~#

c. La commande postfix 

Le service postfix est généralement lancé par un script de configuration normalisé. Il est toutefois possible d’utiliser 
la commande postfix directement, notamment en phase de test et diagnostics. 

Utilisation de la commande postfix 

postfix action

Commande postfix : actions courantes 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


status  Affiche l’état fonctionnel du service. 

stop  Arrête le service proprement. Les processus en cours sont autorisés à se terminer. 

start  Vérifie puis démarre le service. 

check  Vérifie la validité de l’environnement de fonctionnement du service. 

reload  Recharge la configuration. Préférable à un stop/start. 

abort  Arrête le service de façon immédiate et autoritaire. Les processus en cours sont stoppés 
brutalement. 

flush  Tente de délivrer tous les mails en instance : ceux qui ont déjà fait l’objet d’une erreur et 
qui sont en attente de nouvelle tentative. 

d. Les fichiers de configuration 

Le  service  Postfix  trouve  sa  configuration  dans  un  fichier  nommé  main.cf,  généralement  situé  dans  le 
répertoire /etc/postfix. 

myorigin = domaine_origine
mydestination = domaine_destination
mynetwork = réseau/bitmasque
relayhost = relais_MTA

Fichier main.cf : principaux paramètres 

domaine_origine  Ce que le serveur met après l’@ en sortie. Peut être différent du domaine local 
initialement configuré. C’est le domaine vu de l’extérieur. 

domaine_destination  Le serveur traite les mails à destination de ce domaine. Peut être identique au 
domaine d’origine. 

réseau/bitsmasque  Le serveur accepte de relayer les mails provenant directement de ce réseau. 
En principe le réseau local. 

relais_MTA  Si le paramètre relayhost est employé, les mails sont envoyés vers l’extérieur 
exclusivement via le MTA relais_MTA. 

L’utilisation du paramètre relayhost n’a rien d’obligatoire, et dans l’esprit du protocole SMTP, ne devrait pas 
être nécessaire. Toutefois, de nombreux fournisseurs d’accès refusent que du trafic SMTP sorte directement 
de  leurs  réseaux  s’il  n’a  pas  été  émis  par  leurs  propres  MTA.  Le  paramètre  relayhost  permet  donc  de  s’en 
remettre exclusivement à un MTA externe pour toute transmission de courrier. 

Avec un fichier de configuration minimaliste ne comportant que les paramètres énoncés ci­dessus, un serveur postfix 
serait déjà en mesure de remplir son office de MTA. En attendant qu’un client de messagerie ne vienne les remettre 
à  son  destinataire  (avec  un  protocole  de  retrait  de  courrier,  POP  ou  IMAP),  les  messages  sont  stockés  dans  le 
répertoire /var/mail sous le nom de l’utilisateur destinataire. 
Pour  tester  le  fonctionnement  à  cette  étape  de  la  configuration,  on  peut  écrire  un  mail  depuis  un  client  SMTP 
(Outlook, Thunderbird, etc.) configuré pour utiliser le serveur postfix comme serveur SMTP. La lecture du message à 
ce niveau de configuration ne peut se faire que depuis une session shell sur le serveur postfix avec la commande 
mail. La commande mail est traitée dans la partie clients de messagerie. 

e. Vérification de la configuration active 

Il  est  possible  de  vérifier  la  configuration  effective  d’un  serveur  postfix  pour  détecter  les  problèmes  majeurs  de 
fonctionnement (répertoires manquants, etc.) et les paramètres appliqués par le serveur à partir du fichier main.cf. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Validation de l’environnement fonctionnel 

postfix check

Paramètres effectifs 

postconf -n

2. Gestion de domaines virtuels 

Dans  une  configuration  simple,  un  serveur  postfix  ne  gère  qu’un  seul  domaine  de  messagerie  :  celui  associé  à 
l’entreprise  ou  à  l’organisation  qui  l’héberge.  Il  peut  arriver  toutefois  qu’on  souhaite  gérer  sur  un  même  serveur 
plusieurs  domaines  de  messagerie.  C’est  l’objet  des  domaines  virtuels.  Les  domaines  virtuels  sont  utilisés  par  les 
hébergeurs, qui peuvent gérer plusieurs centaines de domaines clients sur un seul serveur, mais aussi en entreprise, 
ou un service informatique gère la messagerie de deux entités distinctes, par exemple suite à un rachat. 

a. Définition des domaines virtuels 

Nous avons vu plus haut que le fichier main.cf devait contenir sous la directive mydestination le nom du domaine 
de messagerie géré. Ce domaine principal, cohérent avec le nom complet du serveur est appelé domaine canonique. 
Si  on  souhaite  gérer  d’autres  domaines,  il  faudra  dans  un  premier  temps  les  déclarer  sous  la  directive 
virtual_alias_domain. 

Déclaration de domaines virtuels dans main.cf 

virtual_alias_domain domaine2, domaine3

Où domaine2 et domaine3 représentent les domaines virtuels gérés par le serveur. 

b. Gestion des identités pour les domaines virtuels 

Il  faut  ensuite  spécifier  quel  compte  utilisateur  est  affecté  à  quelle  boîte  aux  lettres  de  quel  domaine.  Cette 
association  doit  être  faite  dans  un  fichier  dont  le  nom  et  l’emplacement  sont  spécifiés  par  la  directive 
virtual_alias_maps dans le fichier de configuration main.cf. Le nom usuel de ce fichier est /etc/postfix/virtual. 

Déclaration du fichier d’alias dans main.cf 

virtual_alias_maps = hash:/etc/postfix/virtual

Il suffit ensuite de créer le fichier d’alias avec le format suivant : 

Format du fichier d’alias 

adresse_mail1 compte_linux
adresse_mail2 compte_linux

Exemple de fichier d’alias 

root@serveur# cat /etc/postfix/virtual


toto@domaine.com toto
titi@domaine2.com chti
tutu@domaine2.com tutu
root@serveur#

Création du fichier d’alias à un format exploitable par postfix 

postmap /etc/postfix/virtual

Cette commande crée un fichier au format Berkeley DB à partir du fichier d’alias en texte clair. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Exemple de création de fichier d’alias 

La commande postmap crée un fichier virtual.db à partir du fichier texte virtual. 

alpha:/etc/postfix# cat virtual


toto@autredomaine.com toto
alpha:/etc/postfix# postmap virtual
alpha:/etc/postfix# ls virtual*
virtual virtual.db
alpha:/etc/postfix# file virtual.db
virtual.db: Berkeley DB (Hash, version 9, native byte-order)
alpha:/etc/postfix#

3. Gestion de quotas 

Il est possible de limiter l’espace disque consommé par les boîtes aux lettres. Cette limitation s’obtient facilement par 
le paramètre mailbox_size_limit dans le fichier de configuration. De la même façon, il est possible de limiter la taille 
d’un message avec le paramètre message_size_limit. 

Gestion des tailles maximums dans main.cf 

mailbox_size_limit = taille_max_boite
message_size_limit = taille_max_mail

Limitation de l’espace disque dans main.cf 

taille_max_boite  Limite d’une boîte aux lettres en octets. 

taille_max_mail  Limite d’un message en octets. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Remise locale des messages 
Pour un MTA, le but ultime outre l’envoi des messages est de recevoir les courriers à destination des utilisateurs de son 
domaine de messagerie. Rien n’est prévu pour la remise du courrier aux utilisateurs. La solution courante est de prévoir 
un  MDA  (Mail  Delivery  Agent)  pour  que  les  messages  puissent  être  récupérés  depuis  un  MUA  (Mail  User  Agent), 
communément appelé client de messagerie. En attendant, les fichiers sont stockés localement par le MTA. 

1. La commande mail 

Dans  un  fonctionnement  moderne,  un  MTA  doit  gérer  le  courrier  qui  arrive  de  l’extérieur  et  expédier  le  courrier  en 
partance, mais les tâches comme la rédaction de messages ou la lecture des messages arrivés sont effectuées depuis 
un  client  de  messagerie  avec  lequel  l’utilisateur  aura  plus  de  confort  pour  travailler.  Toutefois,  en  attendant  qu’un 
client de messagerie soit configuré pour envoyer des mails, et qu’un serveur de remise de courrier soit installé pour 
permettre  la  remise  des  messages  aux  clients,  il  est  pratique  de  pouvoir  utiliser  la  commande  historique  mail 
directement depuis le serveur. 

a. Envoi de courrier avec la commande mail 

La commande mail permet d’envoyer des courriers assez confortablement. On peut rédiger et envoyer son mail en 
une ligne de commande unique, mais il est généralement plus confortable d’utiliser la commande de façon interactive. 

Étapes pour l’envoi d’un message par la commande mail 

■ Tapez  la  commande  mail  suivie  du  nom  du  destinataire.  Ce  peut  être  le  nom  simple  du  compte  utilisateur  ou 
l’adresse mail du destinataire. 

■ À l’invite, renseignez le sujet de votre message. 

■ Tapez ensuite votre message, avec autant de lignes que vous le souhaitez. Il n’y a pas d’invite pour cette partie 
de la saisie. 

■ Une fois votre texte tapé, sur une nouvelle ligne de saisie, tapez le caractère point : « . » seul sur sa ligne. 

■ Si  l’invite «Cc:  » est  présentée,  entrez  si  nécessaire  les  destinataires  en  copie.  (Cc  signifie  « Carbon  copy »  ou 
copie carbone comme à l’époque  où  les  photocopies  n’existaient pas). S’il  n’y a pas de destinataire à mettre en 
copie, tapez simplement entrée. 

■ Votre mail est remis au MTA local et sera traité par lui. 

Exemple d’envoi de message avec la commande mail 

L’exploitation de la commande mail à des fins de diagnostic peut faire gagner un temps précieux. 

alpha:/home/tic# mail tac


Subject: Invitation
Salut,
Tu viens manger des noisettes ?

Tic
.
Cc:
alpha:/home/tic#

b. Lecture de courrier avec la commande mail 

Plus  encore  que  pour  l’envoi  de  messages,  la  commande  mail  est  utile  pour  lire  les  messages  reçus  sans  avoir 
besoin d’installer  un  service  de  retrait  de  messages.  En  effet,  un  client  de  messagerie  peut  facilement  envoyer  un 
mail en s’adressant directement au MTA en SMTP. En revanche, pour ce qui est de lire les messages reçus depuis un 
client  de  messagerie,  il  faut  pouvoir  s’adresser  au  serveur  par  un  protocole  de  retrait  :  POP  ou  IMAP.  Si  aucun 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


serveur POP ou IMAP n’est installé, la commande mail est la solution la plus pratique pour lire ses messages. 

Lecture d’un message reçu avec la commande mail 

■ Tapez la commande mail et constatez la présence d’une liste de messages non lus. 

■ Tapez le numéro du message reçu que vous souhaitez consulter. 

■ Après lecture du message, quittez l’interface en tapant q. 

Exemple d’utilisation de la commande mail pour consulter un message reçu 

tac@alpha:~$ mail
Mail version 8.1.2 01/15/2001. Type ? for help.
"/var/mail/tac": 4 messages 4 new
>N 1 tic@pas.net Sun Mar 7 02:12 15/398 salut
N 2 tic@pas.net Sun Mar 7 02:14 17/438 Invitation
N 3 tic@pas.net Sun Mar 7 09:10 14/402 Hello
N 4 tic@pas.net Sun Mar 7 09:10 14/412 Are you Chip or Dale ?
& 2
Message 2:
From tic@pas.net Sun Mar 7 02:14:01 2010
X-Original-To: tac
To: tac@pas.net
Subject: Invitation
Date: Sun, 7 Mar 2010 02:14:01 +0100 (CET)
From: tic@pas.net (root)

Tu viens manger des noisettes ?


Salut,

Tic

& q
Saved 1 message in /home/tac/mbox
Held 3 messages in /var/mail/tac
tac@alpha:~$

2. Formats mbox et maildir 

Une fois un message reçu par un MTA, il doit être stocké en attendant sa remise à un utilisateur. Historiquement deux 
formats principaux permettent de conserver ces messages de façon structurée : mbox et Maildir. 

a. Le format mbox 

Le format mbox est utilisé pour stocker les messages reçus par un utilisateur. C’est un format rudimentaire et assez 
ancien,  dans  lequel  tous  les  messages  sont  concaténés  et  un  seul  fichier  contient  l’ensemble  des  mails  reçus.  Ce 
format  a  l’avantage de la simplicité, et il est facilement exploitable, même avec un simple éditeur texte (il suffit de 
repérer  le  mail  recherché  dans  le  contenu  du  fichier).  Les  débuts  de  messages  sont  identifiés  par  la  séquence  de 
caractères From en tête de ligne. En revanche, il souffre de limitations inhérentes à son mode de fonctionnement. 
L’accès concurrent de plusieurs programmes au fichier est très dangereux puisque toute opération d’écriture sur un 
fichier au format mbox par deux programmes différents conduirait à la corruption du fichier, et donc à la perte de la 
boîte aux lettres. En conséquence, des mécanismes de verrouillage du fichier mbox existent, mais malheureusement, 
il arrive que des programmes différents ne reconnaissent pas le même mécanisme de verrouillage et conduisent donc 
à des catastrophes. La solution sera apportée plus tard avec le format maildir. 

b. Le format maildir 

Le  format  maildir  utilise  une  structure  de  répertoires  pour  le  stockage  des  mails  reçus  par  un  utilisateur. 
Contrairement  au  format  mbox,  maildir  utilise  un  fichier  par  mail  reçu.  Toute  manipulation  faite  sur  un  message 
n’affecte donc aucunement le reste des données. 
Un  répertoire  de  courrier  au  format  maildir  contient  trois  sous­répertoires :  tmp,  new  et  cur.  Les  messages  sont 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


d’abord stockés dans tmp, puis déplacés dans new. Enfin, après lecture par un programme utilisateur, les messages 
sont  déplacés  dans  cur.  Les  mails  sont  stockés  dans  leur  répertoire  d’affectation  sous  un  nom  unique  mais  sans 
aucun rapport avec le titre du message. 

c. Utilisation du format maildir par postfix 

Par défaut, postfix utilise le format mbox pour stocker les mails reçus par les utilisateurs. Il est toutefois possible (et 
souvent recommandé) de lui faire utiliser le format maildir à la place. Cette opération est réalisée simplement par une 
déclaration dans le fichier main.cf. Le répertoire Maildir sera alors créé dans le répertoire personnel de l’utilisateur à 
la réception de premier mail. 

Déclaration du format Maildir dans le fichier main.cf 

home_mailbox = Maildir/

La commande mail exploite naturellement le seul format mbox. Il n’est donc pas possible de l’utiliser  si  les 


boîtes  mails  sont  au  format  maildir.  Les  messages  doivent  alors  être  récupérés  par  un  moyen  compatible 
comme un serveur POP ou IMAP compatible maildir. 

3. Procmail 

Il  est  possible  de  demander  au  MTA  un  traitement  sur  les  messages  entrants  avant  stockage.  Postfix  peut  ainsi 
mandater un programme tiers pour cet usage. Le plus connu d’entre eux est procmail. Il suffit de demander à postfix 
d’utiliser procmail (facile) et ensuite de le configurer pour qu’il applique un traitement aux courriers entrants (un peu 
moins facile). Ce traitement peut être à des fins de réorganisation (mettre certains messages dans des répertoires), 
de  filtrage  (refuser  les  messages  qui  contiennent  des  mots  interdits),  ou  encore  d’appeler  un  autre  programme 
(encore un) pour appliquer un traitement plus lourd que procmail ne saurait faire seul. 

a. Demander à postfix d’utiliser procmail 

Déclaration d’utilisation de procmail par postfix dans le fichier main.cf 

mailbox_command = /usr/local/bin/procmail

b. Configurer procmail 

Procmail lit sa configuration dans un fichier .procmailrc se trouvant dans le répertoire local de l’utilisateur. Ce fichier 
contient des règles qu’il applique séquentiellement à tout courrier entrant. Le traitement s’arrête  dès  qu’une règle 
est satisfaite. 

Format d’une règle dans le fichier ~/.procmailrc 

:0 drapeaux
condition
action

Fichier ~/.procmailrc : options et paramètres 

:0  Marque le début d’une règle de traitement. 

drapeaux  Facultatif. Sur quoi la recherche doit s’appliquer. Valeur H pour l’en­tête seulement, B 
pour le corps du message. 

condition  Expression régulière permettant d’isoler les mails correspondant à la règle. 

action  Que faire du message sélectionné. 

Exemples de règle dans le fichier ~/.procmailrc 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Dans  l’exemple  ci­dessous,  la  recherche  s’effectue  sur  l’en­tête  du  message  seulement  (c’est  la  valeur  par  défaut)  et 
isolera les mails contenant les mots « From » en début de ligne, et la chaîne de caractères « toto » dans la même ligne. La 
troisième ligne de la condition déplacera le mail reçu vers le répertoire tousmesamis/toto dans le répertoire de courrier (et 
donc dans le sous­répertoire de la boîte de réception dans le client de messagerie). 

:0
* ^From.*toto
tousmesamis/toto

Pour impression de tout mail dont la taille est inférieure à 1000 octets. 

:0
* < 1000
| /usr/bin/lp

4. Alternatives à la messagerie 

Pendant longtemps, la consommation en ressources de la messagerie, tant en espace disque qu’en bande passante 
sur le réseau a été un problème pour les administrateurs. Des commandes alternatives permettent de communiquer 
avec  les  utilisateurs  connectés  indépendamment  de  la  messagerie  et  avec  une  consommation  de  ressources  très 
inférieure. 

a. write et wall 

Il  est  possible  d’envoyer  des  messages  courts  avec  les  commandes  write  et  wall.  La  commande  write  permet 
d’envoyer un message à un utilisateur connecté, alors que wall (write all) diffuse le message à tous les utilisateurs 
connectés. 

Envoi de messages avec write 

write nom_utilisateur
(frappe du message terminée par Ctrl-D)

write < fichier_message

Où  nom_utilisateur  représente  un  utilisateur  existant  sur  le  système  et  connecté  à  une  session  interactive,  et 
fichier_message un fichier contenant le texte à envoyer. 

Diffusion d’un message avec wall 

wall
(frappe du message terminée par Ctrl-D)

wall < fichier_message

b. issue et issue.net 

Le  contenu  du  fichier  /etc/issue  est  affiché  avant  la  demande  d’identification  locale  et  permet  éventuellement  de 
communiquer avec les utilisateurs. 
Le contenu du fichier /etc/issue.net est affiché avant l’authentification d’un utilisateur se connectant en telnet. 

c. motd 

Le contenu du fichier /etc/motd (Message Of The Day) est affiché après une ouverture de session réussie. 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Remise distante des messages 

1. Fonctionnement conjoint des MTA, MDA et des MUA 

Le rôle d’un MTA (Mail Transfer Agent) en ce qui concerne la réception de messages se cantonne à la récupération et 
au stockage des mails entrants. Pour que l’utilisateur puisse lire et traiter confortablement son courrier, il utilise un 
MUA (Mail User Agent ou client de messagerie) qui fonctionne avec un protocole de retrait de courrier : POP ou IMAP. 
Postfix n’étant qu’un MTA et ne gérant pas ces protocoles, il faut lui adjoindre un service MDA (Mail Delivery Agent) de 
retrait de courrier pour les utilisateurs. Nous couvrirons ici la configuration de deux des principaux MDA : les services 
courrier et Dovecot. 
Quand un message arrive au MTA, il a d’un point de vue SMTP terminé son voyage. Le MTA l’enregistre donc dans un 
espace de stockage local, dans notre cas au format mbox ou maildir. Si un serveur POP ou IMAP est installé, son rôle 
sera  après  avoir  identifié  l’utilisateur  de  retrouver  les  messages  arrivés  dans  cet  espace  de  stockage,  et  de  les 
fournir au client de messagerie. 

a. Le protocole POP3 

Le protocole POP3 fonctionne sur le port 110 et est transporté par TCP. Il télécharge les messages depuis une boîte 
utilisateur  vers  un  client  de  messagerie.  Les  messages  sont  ensuite  normalement  effacés  de  la  boîte  et  libèrent 
l’espace  disque  du  serveur.  Toutefois,  il  est  de  plus  en  plus  fréquent  de  configurer  POP  depuis  le  client  afin  qu’il 
laisse une copie des messages sur le serveur. 

b. Le protocole IMAP4 

Le  protocole  IMAP4  fonctionne  sur  le  port  143  et  est  transporté  par  TCP.  Il  télécharge  les  en­têtes  de  messages 
depuis le serveur, et le client décide ensuite de l’action à mener sur ces messages : consulter, effacer, déplacer, etc. 
Les  messages  sont  conservés  sur  le  serveur,  mais  il  est  possible  de  configurer  les  clients  IMAP  afin  qu’ils 
synchronisent les messages téléchargés pour une consultation hors­ligne. 

2. Serveurs Courier­IMAP et Courier­POP 

Les  serveurs  Courier­pop  et  Courier­imap  appartiennent  à  une  suite  applicative  appelée  «  Courier  Mail  Server  ». 
Cette suite logicielle a été conçue pour fournir l’ensemble des services courants de gestion de courrier électronique, 
mais étant de nature modulaire, ses composants sont souvent utilisés seuls pour fournir un service précis. 

a. Format de messages pour les services courrier 

Les services Courier­pop et Courier­imap vont trouver les mails arrivés exclusivement dans un répertoire au format 
maildir. Tout fonctionnement avec le format mbox est impossible. Il faudra donc configurer postfix pour qu’il utilise le 
format maildir. 

b. Configuration des services 

C’est  la  bonne  nouvelle,  il  n’y  a  en  principe  rien  d’autre  à  faire  que  d’installer  le  service  et  de  le  démarrer.  Les 
paramètres  par  défaut  sont  satisfaisants  pour  les  fonctionnements  standards.  Les  fichiers  de  configuration  se 
trouvent généralement dans le répertoire /etc/courier, et s’appellent pop3d pour le service POP, et imapd pour le 
service IMAP. 
Si  le  répertoire  de  stockage  des  courriers  au  format  maildir  ne  devait  pas  utiliser  le  nom  par  défaut  (Maildir),  il 
faudrait préciser dans ces fichiers de configuration le nom utilisé. 

Nom de répertoire maildir dans le fichier de configuration pop3d ou imapd 

MAILDIRPATH=nomrepmaildir

Où nomrepmaildir représente le répertoire employé pour le stockage des messages reçus au format maildir. 
Si le serveur dispose de plusieurs interfaces physiques, on peut limiter les interfaces d’écoute du démon imap. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Restrictions de l’interface active dans le fichier de configuration pop3d ou imapd 

address = adresse_interface

Où adresse_interface représente l’adresse IP de l’interface apte à recevoir les connexions clientes. 

c. Validation de l’authentification 

Lors de l’utilisation de Courier­POP ou de Courier­IMAP, un client de messagerie présente l’identifiant et le mot de 
passe  de  l’utilisateur  dont  il  veut  relever  le  courrier.  Ces  éléments  d’identification  sont  alors  validés  par  la 
bibliothèque  d’authentification  «  courier  »  commune  aux  deux  services.  Il  peut  être  utile  de  vérifier  en  lignes  de 
commandes  que  le  compte  utilisé  est  bien  exploitable  pour  l’authentification  par  cette  bibliothèque.  L’utilitaire 
authtest est là pour ça. 

Vérification de la validité d’un compte avec authtest 

authtest utilisateur motdepasse

Où  utilisateur et  motdepasse  sont  les  éléments  d’authentification  que  le  client  de  messagerie  présentera  pour  se 
connecter en imap ou pop au serveur. 

Exemple d’utilisation de authtest 

Jusque­là tout va bien... 

alpha:/etc/courier# authtest tic password


Authentication succeeded.

Authenticated: tic (system username: tic)


Home Directory: /home/tic
Maildir: (none)
Quota: (none)
Encrypted Password: $1$YSIbmjnM$makfir51Gla3ZpfRq5dmu.
Cleartext Password: password
Options: (none)
alpha:/etc/courier#

3. Serveur Dovecot 

Dovecot est un autre serveur de retrait de courrier développé dans le but d’assurer un maximum de performances et 
de sécurité. Sa mise en œ uvre est relativement simple, mais du fait de sa richesse fonctionnelle, les possibilités de 
configuration sont nombreuses et souvent décourageantes. 
Dovecot supporte nativement les formats de boîtes aux lettres mbox et maildir. 

a. Configuration de Dovecot 

Le  serveur  Dovecot  trouve  sa  configuration  dans  un  fichier  dovecont.conf,  généralement  situé  dans  le 
répertoire  /etc/dovecot.  Si  le  service  doit  être  utilisé  dans  une  infrastructure  simple  et  courante,  il  faudra 
simplement modifier sa configuration afin qu’il accepte les authentifications par mots de passe en texte clair. Il peut 
paraître surprenant de ne pas sécuriser les mots de passe sur un serveur de messagerie, mais dans une utilisation 
traditionnelle, le message lorsqu’il circule sur Internet n’est absolument pas protégé et est visible de tous. Sécuriser 
alors la seule étape client­serveur revient alors à assurer une sécurité un peu illusoire sur le contenu du message. 
Le mot de passe du client de messagerie ne circule plus en clair, mais le message n’est protégé que de ses voisins 
immédiats. Il est toutefois possible de configurer son client de messagerie pour utiliser les protocoles POP ou IMAP 
sur  SSL,  la  confidentialité  est  alors  apportée  sur  le  tronçon  client­serveur  mais  il  faut  bien  garder  en  tête  que  le 
message a sans doute transité en clair sans aucune protection avant d’arriver sur le serveur. La véritable sécurité 
sur le contenu des messages ne peut être apportée que par un protocole agissant de bout en bout comme SMIME. 

Autorisation des authentifications en texte clair dans le fichier dovecot.conf 

disable_plaintext_auth = no

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Cette  ligne  peut  être  ajoutée  à  tout  endroit  du  fichier  de  configuration  mais  existe  généralement  sous  forme 
commentée dans les fichiers pré­configurés livrés avec les logiciels. 

b. Visualisation de la configuration 

Le  nombre  de  paramètres  possible  dans  le  fichier  dovecot.conf  peut  impressionner  et  rendre  son  interprétation 
difficile.  De  plus,  il  peut  être  utile  de  vérifier  un  paramètre  de  configuration  sans  avoir  à  parcourir  les  dizaines  ou 
centaines  de  lignes  du  fichier.  La  commande  dovecot  appelée  avec  l’option  ­a  permet  de  voir  les  paramètres 
effectifs sur le serveur. 

Exemple d’utilisation de la commande dovecot pour visualiser la configuration 

Le résultat ci­dessous est tronqué. 

alpha:/etc/dovecot# dovecot -a | wc -l
139
alpha:/etc/dovecot# dovecot -a | head -20
# 1.0.15: /etc/dovecot/dovecot.conf
base_dir: /var/run/dovecot
log_path:
info_log_path:
log_timestamp: %Y-%m-%d %H:%M:%S
syslog_facility: mail
protocols: imap imaps pop3 pop3s
listen: *
ssl_listen:
ssl_disable: no
ssl_ca_file:
ssl_cert_file: /etc/ssl/certs/dovecot.pem
ssl_key_file: /etc/ssl/private/dovecot.pem
ssl_key_password:
ssl_parameters_regenerate: 168
ssl_cipher_list:
ssl_verify_client_cert: no
disable_plaintext_auth: no
verbose_ssl: no
shutdown_clients: yes
alpha:/etc/dovecot#

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Routage et filtrage 

1. Configuration d’un serveur Linux en tant que routeur 

La fonction de routage est intégrée nativement dans le noyau Linux. Il n’y a donc pas de questions à se poser, toute 
machine Linux est un routeur en puissance. En revanche, cette fonction n’est pas active par défaut au démarrage. Il 
faut donc la configurer avant toute opération de routage. 

a. Activation du routage sur un serveur Linux 

Nous savons que tout système Linux présente un filesystem virtuel /proc qui permet d’observer en direct un certain 
nombre  de  comportements  et  paramètres.  L’activation  du  routage  se  fait  en  modifiant  le  contenu  du 
fichier  /proc/sys/net/ipv4/ip_forward.  Ce  fichier  contient  un  seul  caractère,  par  défaut  0  pour  indiquer  que  le 
routage est inactif. 

Modification du fichier ip_forward pour activer le routage 

echo 1 > /proc/sys/net/ipv4/ip_forward

Une  fois  cette  manipulation  effectuée,  la  machine  Linux  est  prête  à  router  les  paquets  se  présentant  sur  ses 
interfaces. Ce paramètre est volatile et sera perdu dès la machine éteinte. Toutefois, on peut évidemment annuler le 
routage en effectuant l’opération inverse. 

Modification du fichier ip_forward pour désactiver le routage 

echo 0 > /proc/sys/net/ipv4/ip_forward

Autre possibilité, la commande sysctl qui permet de modifier dynamiquement des paramètres fonctionnels du noyau. 
sysctl permet de modifier directement tous les fichiers se trouvant sous l’arborescence /proc/sys. 

Activation du routage avec sysctl 

sysctl net.ipv4.ip_forward=1

Ces commandes sont effectives toute la durée de la session et doivent être retapées après chaque redémarrage. On 
peut bien entendu les placer dans un script de service appelé au démarrage, ou modifier le fichier /etc/sysctl.conf. 

Activation permanente du routage dans le fichier /etc/sysctl.conf 

net.ipv4.ip_forward = 1

b. Consultation de la table de routage 

À ce stade, le routeur Linux est parfaitement capable de router les paquets. Toutefois, il ne pourra le faire que vers 
des réseaux connus, c’est­à­dire référencés dans sa table de routage. 
La table de routage est maintenue en mémoire mais elle peut être consultée par quelques commandes. 

Affichage de la table de routage par la commande route 

route -n

Le paramètre  ­n  est  facultatif,  mais  il  fait  gagner  beaucoup  de  temps  à  l’affichage  car  il  dispense  la  commande  de 
tenter  de  résoudre  les  adresses  renvoyées  en  noms.  Or,  si  l’adresse en question n’est  pas  renseignée  dans  une 
zone DNS inverse, cette requête se fait pour rien et il faut attendre plusieurs secondes pour que l’affichage arrive. 

Affichage de la table de routage par la commande netstat 

netstat -nr

Où l’option ­r demande à la commande d’afficher la table de routage et ­n de ne pas faire de résolution de noms. La 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


commande netstat a de nombreux usages, mais elle est souvent utilisée dans ce simple cadre de consultation de la 
table de routage. 

Exemple d’affichages de table de routage 

L’affichage de la table de routage est souvent le seul moyen simple de consulter la valeur de la passerelle par défaut. 

beta:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

c. Gestion des routes statiques 

Les seules entrées présentes automatiquement dans la table de routage sont les réseaux auxquels le routeur est 
directement connecté, ainsi que la passerelle par défaut. Le routeur peut donc exploiter ces entrées de la table de 
routage  sans  autre  configuration.  Si  le  routeur  doit  router  des  paquets  vers  d’autres  réseaux,  il  faudra  ajouter 
manuellement les routes dans la table de routage. 

Ajout de route statique dans la table de routage 

route add -net réseau_cible netmask masque gw routeur

Ajout de route statique : options et paramètres 

­net  La route ajoutée est celle d’un réseau. (La cible pourrait être un hôte seul même si 
cette configuration est moins fréquente.) 

réseau_cible  L’adresse du réseau que la nouvelle route permet d’atteindre. 

masque  Le masque de sous­réseaux associé à la nouvelle route. 

gw routeur  Indique le routeur à emprunter pour atteindre le réseau cible. 

Ajout de passerelle par défaut 

route add default gw routeur

route add -net 0.0.0.0 gw routeur

Dans la deuxième syntaxe, 0.0.0.0 représente la route par défaut. Cette représentation de la route par défaut est 
universelle et applicable sur la quasi­totalité des systèmes exploitant une table de routage IP. 
Bien  entendu,  il  est  possible  de  supprimer  les  routes  statiques  qui  ne  sont  plus  nécessaires  ou  enregistrées  par 
erreur. 

Suppression de route statique de la table de routage 

route del -net réseau_cible netmask masque

Exemple d’ajout de route 

beta:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
beta:~# route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.1.99
beta:~# route -n

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 192.168.1.99 255.0.0.0 UG 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Exemple de suppression de route 

beta:~# route del -net 10.0.0.0 netmask 255.0.0.0


beta:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
beta:~#

2. Iptables 

Les  iptables  sont  utilisées  pour  gérer  le  filtrage  de  paquets  IP  au  sein  d’un  système  Linux.  Elles  exploitent  une 
commande  unique  :  iptables,  et  se  configurent  par  l’application  successive  de  règles  de  gestion  de  paquets.  Les 
iptables peuvent filtrer le trafic en transit dans un routeur Linux, mais aussi le trafic entrant et sortant de tout serveur 
ou poste de travail à une seule interface. 

Si les iptables constituent un outil très puissant de gestion du trafic, la médaille a son revers et leur configuration est 
tout  sauf  intuitive.  Avec  une  approche  structurée,  on  peut  toutefois  assez  rapidement  appréhender  leur 
fonctionnement.  Les  paragraphes  ci­dessous  exposent  les  concepts  fondamentaux  des  iptables,  afin  de  les  utiliser 
plus tard dans des configurations de pare­feu. 

a. Les tables 

Les  iptables  s’appuient  sur  des  tables  associées  à  un  mode  fonctionnel.  Selon  le  type  de  règle  que  l’on  souhaite 
ajouter  au  fonctionnement  des  iptables,  on  précisera  la  table  associée.  Les  tables  principales  utilisées  sont  filter 
pour le filtrage de paquets et nat pour la translation d’adresses entre un réseau privé et un réseau public. 
La table filter est la table par défaut. Aussi, quand on établit une règle iptables dans un but de filtrer les paquets 
est­elle sous­entendue et donc non précisée. 
La table nat sert à la translation d’adresses et doit être systématiquement précisée quand elle est invoquée. 

b. Les chaînes 

Une chaîne iptables représente un type de trafic du point de vue de sa circulation dans une machine. Les chaînes 
permettent  de  préciser  si  une  règle  doit  s’appliquer  à  du  trafic  qui  entre  dans  une  machine,  qui  en  sort  ou  qui  la 
traverse. 
La  chaîne  INPUT  désigne  le  trafic  entrant,  la  chaîne  OUTPUT  désigne  le  trafic  sortant,  et  la  chaîne  FORWARD 
désigne le trafic qui traverse la machine, entrant par une interface et sortant par une autre. Attention, même si un 
paquet qui traverse le routeur est d’un point de vue physique respectivement entrant, traversant et sortant, iptables 
le  considérera  comme  traversant  seulement  (chaîne  FORWARD).  Les  chaînes  INPUT  et  OUTPUT  sont  réservées  au 
trafic à destination ou en provenance explicite de l’hôte soumis aux règles. 
Une  autre  chaîne  appelée  POSTROUTING  et  utilisée  dans  la  configuration  du  NAT  a  pour  objet  d’appliquer  un 
traitement à un paquet après une opération de routage. 
Les chaînes sont toujours indiquées en majuscules dans une syntaxe iptables. 

c. Les actions 

Quand une règle est satisfaite, une action est engendrée par le système sur le paquet testé. Les principales actions 
sont ACCEPT qui laisse passer le paquet et DROP, qui le détruit. 
Dans une syntaxe iptables, l’action (target dans le manuel en ligne) est annoncée par le paramètre ­j. 

Les actions sont toujours indiquées en majuscules dans une syntaxe iptables. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


d. Le traitement des règles 

Les règles sont appliquées une par une à tout paquet filtré. Si une règle est satisfaite, une action est engagée sur le 
paquet et le traitement s’arrête. Si une règle n’est pas satisfaite, la règle suivante est testée. Dans le cas où aucune 
des  règles  n’est  satisfaite,  le  paquet  subit  un  traitement  par  défaut  paramétré  dans  une  règle  spécifique  appelée 
politique (policy). 
Il est possible d’afficher les règles appliquées dans l’ordre pour chacune des chaînes. 

Affichage des règles effectives 

iptables -L

Exemple d’affichage des règles 

Cet  exemple  affiche  les  règles  en  vigueur  sur  un  système  Linux  non  configuré.  On  y  voit  la  politique  appliquée  pour 
chacune des chaînes, et on constate l’absence de règles de filtrage. 

alpha:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)


target prot opt source destination

Chain OUTPUT (policy ACCEPT)


target prot opt source destination

La commande iptables ­L affiche une interprétation des règles en vigueur. Si on souhaite connaître les syntaxes qui 
ont permis d’établir ces règles, il est préférable d’utiliser l’option ­S. 

Exemple d’affichage des règles selon les syntaxes 

L’option  ­S  est  particulièrement  utile  quand  on  est  confronté  à  un  système  configuré  par  un  tiers  et  qu’on  ne  sait  pas 
quelles sont les commandes qui ont conduit à une configuration. 

alpha:~# iptables -S

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
alpha:~#

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


Administration d’un pare­feu avec les iptables 

1. Politiques 

a. Principe des politiques de pare­feu 

Un pare­feu peut fonctionner selon deux modes distinct : « tout ce qui n’est pas autorisé est interdit », ou « tout ce 
qui n’est pas interdit est autorisé ». Pour définir le comportement par défaut, les iptables permettent de définir pour 
chaque chaîne une action par défaut. 

Définition de la politique par défaut des iptables 

iptables -P chaine action

Où chaine représente le type de trafic (INPUT, OUTPUT et FORWARD), et action le comportement souhaité (DROP ou 
ACCEPT). 

Exemple de définition de politique 

Dans cet exemple, on interdit à tout trafic de sortir de l’hôte en appliquant une politique de rejet des paquets sortants. 

root@test:~$ ping -c 1 192.168.0.10


PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=0.880 ms
--- 192.168.0.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.880/0.880/0.880/0.000 ms
root@test:~$ iptables -P OUTPUT DROP
root@test:~$ ping -c 1 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
--- 192.168.0.10 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
root@test:~$

b. Configuration d’une politique de base 

Si l’hôte à configurer est appelé à devenir un pare­feu, il est probable que tout trafic soit interdit par défaut. Cette 
configuration  courante  consiste  à  définir  sur  les  trois  chaînes  INPUT,  OUTPUT  et  FORWARD  une  politique  de  non­
traitement des paquets. 

Configuration d’une politique restrictive 

iptables -P INPUT DROP


iptables -P OUTPUT DROP
iptables -P FORWARD DROP

2. Filtrage de paquets 

a. Politique et règles 

Après  avoir  configuré  une  politique  qui  décrit  le  comportement  de  base  du  pare­feu,  il  faut  créer  des  règles 
spécifiques aux éléments de trafics que l’on souhaite laisser passer ou interdire. La philosophie du pare­feu est : on 
définit le comportement général avec les politiques, et on gère au cas par cas les comportements spécifiques avec 
des règles. 

b. Création de règle 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Pour chaque élément de trafic devant être autorisé ou interdit, il faudra créer une règle spécifique. 

Syntaxe création d’une règle de gestion de trafic 

iptables -A chaine -s ip_source -d ip_dest -p protocole --dport port -j action

iptables : création de règle 

­A chaine  On ajoute une règle dans la chaîne chaine (INPUT, OUTPUT ou FORWARD). 

­s ip_source  Facultatif : l’adresse IP source d’où proviennent les paquets soumis à la règle. Si 
l’adresse est une adresse de réseau, préciser le masque. 

­d ip_dest  Facultatif : l’adresse IP de destination vers laquelle vont les paquets soumis à la 
règle. Si l’adresse est une adresse de réseau, préciser le masque. 

­p protocole  Indique le protocole utilisé dans le paquet soumis à la règle. Valeurs courantes : 
udp, tcp, icmp. 

­­dport port  Facultatif : indique le port de destination du paquet soumis à la règle. 

­j action  Indique comment traiter le paquet soumis à la règle. (ACCEPT ou DROP). 

Autorisation des ping sortant et entrant 

Chaque type de flux doit faire l’objet d’une règle iptable. 

alpha:~# iptables -A OUTPUT -p icmp -j ACCEPT


alpha:~# iptables -A INPUT -p icmp -j ACCEPT
alpha:~#

Autorisation du trafic http traversant en provenance d’un réseau 

alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p tcp -dport 80 -j ACCEPT


alpha:~#

Une  configuration  erronée  sur  un  pare­feu  peut  avoir  des  conséquences  dramatiques.  Il  est  recommandé 
pour  vérifier  sa  bonne  configuration  d’utiliser  un  scanner  de  ports  depuis  une  machine  distante.  La 
commande nmap ­F suivie de l’adresse IP de la machine protégée permet de vérifier très rapidement (Fastmode) 
que les ports sont bien bloqués ou ouverts. 

c. Gestion des règles 

Les  règles  sont  appliquées  dans  leur  ordre  de  création  et  le  système  leur  applique  automatiquement  un  numéro 
d’ordre. 

Affichage des numéros de règles effectives 

iptables -L chaine --line-numbers -n

Où chaine représente la chaîne de traitement (INPUT, OUTPUT ou FORWARD). Le paramètre ­n n’est pas obligatoire, 
mais accélère fortement l’affichage en dispensant la commande de tenter de résoudre les adresses en noms. 

Suppression d’une règle 

iptables -D chaine numéro

Où numéro représente le numéro de la ligne obtenu avec la commande précédente et où chaine représente la chaîne 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


de traitement (INPUT, OUTPUT ou FORWARD). 

Insertion d’une règle 

iptables -I chaine numéro conditions -j action

Où conditions représente les critères de sélection du paquet soumis à la règle (adresses IP, ports et protocoles). 

Exemple de gestion de règles 

La gestion dynamique des règles est tellement pénible que l’usage établi veut plutôt que l’on exploite un fichier de script 
comprenant toutes les règles, et qu’on le recharge complètement après modification. 

alpha:~# iptables -L FORWARD --line-numbers -n


Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:23
2 ACCEPT udp -- 192.168.1.0/24 0.0.0.0/0 udp dpt:53
3 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:80
alpha:~# iptables -D FORWARD 1
alpha:~# iptables -L FORWARD --line-numbers -n
Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT udp -- 192.168.1.0/24 0.0.0.0/0 udp dpt:53
2 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:80
alpha:~# iptables -I FORWARD 1 -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
alpha:~# iptables -L FORWARD --line-numbers -n
Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:22
2 ACCEPT udp -- 192.168.1.0/24 0.0.0.0/0 udp dpt:53
3 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:80
alpha:~#

d. Gestion des flux retours 

Dans la plupart des applications réseau, un hôte envoie un paquet à destination d’un autre qui lui répond. On a donc 
une  communication  à  double  sens.  Or,  dans  la  configuration  d’un  pare­feu,  on  visualise  bien  les  flux  aller  :  par 
exemple, depuis un navigateur vers un serveur web sur le port 80, mais moins bien les réponses des serveurs qui se 
font sur un port aléatoire à l’initiative du client supérieur à 1024. 
Dans les premiers âges des pare­feu, la solution consistait à autoriser tout trafic entrant dont le port était supérieur 
à  1024.  Les  pare­feu  avaient  alors  davantage  vocation  à  empêcher  les  gens  de  sortir  plutôt  que  d’éviter  les 
intrusions dans le réseau. 
Depuis  quelques  années,  les  pare­feu  dits  «  stateful  » (à  état)  sont  capables  d’autoriser  dynamiquement  les  flux 
retours du moment qu’ils sont la réponse à un flux en sortie explicitement autorisé. 

Autorisation implicite des flux retours 

iptables -A chaine -m state --state ESTABLISHED,RELATED -j ACCEPT

L’option ­m state permet de réaliser un filtre en fonction de l’état du paquet traité. Les états acceptés : ESTABLISHED 
et  RELATED  représentent  respectivement  des  paquets  en  réponse  à  un  flux  aller  autorisé,  et  des  paquets  issus 
d’une nouvelle connexion, mais à l’initiative d’une connexion établie et autorisée (par exemple le trafic de données 
ftp relatif à un trafic de commandes ftp). 

Exemple de configuration complète d’un pare­feu 

On configure ici un pare­feu qui ne laisse rien passer, à l’exception des réponses aux trafics établis, ainsi que les protocoles 
nécessaires à la navigation Internet (http, https et dns). 

alpha:~# iptables -P INPUT DROP


alpha:~# iptables -P OUTPUT DROP
alpha:~# iptables -P FORWARD DROP
alpha:~# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p tcp --dport 80 -j ACCEPT
alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p tcp --dport 443 -j ACCEPT
alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p udp --dport 53 -j ACCEPT

Dans cet exemple, on configure un pare­feu qui ne laisse rien passer, à l’exception des réponses aux trafics établis, 
ainsi que les protocoles nécessaires à la navigation Internet (http, https et dns). 

L’application  fail2ban  permet  en  cas  de  tentatives  de  connexion  infructueuses  à  des  applications  ou  au 
système  lui­même  de  créer  dynamiquement  une  règle  qui  bloquera  toute  communication  de  la  part  de 
l’attaquant. 

3. Gestion du NAT 

a. Rappel sur le principe du NAT 

Le NAT consiste à réécrire l’en­tête IP d’un paquet qui passe d’un réseau public vers un réseau privé et inversement. 

Les  adresses  IP  publiques  étant  non  routables  sur  l’Internet,  un  paquet  qui  proviendrait  d’une  adresse  privée  ne 
pourrait pas trouver de route retour, parce qu’aucun routeur n’accepterait de le renvoyer chez lui. De toute façon, les 
réseaux privés étant démultipliés à l’infini (il existe des millions de réseaux 192.168.1.0), il ne serait pas possible de 
maintenir dans les tables de routage des routeurs d’Internet une route cohérente vers le réseau d’origine. 
La solution consiste donc pour sortir d’un réseau privé à remplacer l’adresse IP de l’expéditeur privé par l’adresse IP 
publique  (unique  sur  Internet)  du  routeur  réalisant  le  NAT.  La  traçabilité  des  translations  (remplacement  des 
adresses IP privées) se fait par rapport au port expéditeur utilisé : pour chaque translation réalisée, le routeur garde 
en mémoire le port expéditeur employé. Le paquet retour arrivant sur l’adresse  publique  du  routeur  et  sur  le  port 
employé par l’expéditeur, l’adresse originelle du client est facilement retrouvée par le routeur NAT. 

b. Diagnostic de la configuration NAT d’un routeur 

Le  NAT  est  géré  dans  une  table  spécifique  appelée  NAT.  Toute  configuration  touchant  au  NAT  se  fera  avec  la 
commande  iptables  en  précisant  qu’on  travaille  sur  la  table  NAT.  Les  chaînes  traitées  dans  la  table  NAT  sont 
PREROUTING, POSTROUTING et OUTPUT, représentant le trafic à modifier avant le routage, après, ou directement 
en sortie de la machine. 

Affichages de la configuration NAT 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


iptables -t nat -L
iptables -t nat -S

c. Connexion d’un réseau privé à un réseau public 

Dans  cette  configuration  qui  est  aussi  la  plus  courante,  l’adresse  IP  d’expéditeur  des  hôtes  du  réseau  privé  est 
remplacée par l’adresse publique du routeur NAT. 

Configuration du NAT 

iptables -t nat -A POSTROUTING -o carte-ext -j action-nat

Nat avec iptables : options et paramètres 

­t nat  La règle concerne la table de NAT. 

­A POSTROUTING  On ajoute une règle à la chaîne POSTROUTING, pour un traitement après routage. 

­o carte­ext  Désigne la carte réseau par laquelle les paquets sortent du pare­feu. 

­j action­nat  Désigne le mode d’action du NAT, supporte deux options : SNAT si l’adresse publique 
est fixe, et MASQUERADE si l’adresse publique est dynamique. 

Exemple de configuration du NAT 

alpha:~# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE


alpha:~#

Dans cet exemple, eth1 est l’interface connectée au réseau public. 

4. Scripts de configuration des règles de filtrage 

a. Red Hat et les iptables 

Les  systèmes  Red  Hat  et  leurs  dérivés  proposent  un  service  iptables  qui  permet  d’appliquer  une  configuration  de 
filtrage  ou  de  NAT  automatiquement.  Le  démarrage  du  service  applique  la  configuration,  et  son  arrêt  annule  tout 
filtrage.  Ce  fonctionnement  est  extrêmement  pratique  et  permet  de  gérer  un  pare­feu  Red­Hat  de  façon  très 
confortable. 

b. Création de service personnalisé de pare­feu avec les iptables 

On  constate  assez  vite  que  la  création  de  règles  de  filtrage  et  de  NAT  avec  les  iptables  a  quelque  chose  de 
fastidieux. Par conséquent, après avoir déterminé les règles dont on a besoin, on aura tout intérêt à les placer dans 
un script. 

Exemple de script de configuration de pare­feu 

Ce type de script dispense d’avoir à gérer les règles une par une en cas de modification de la configuration. Il est beaucoup 
plus  facile  d’insérer  une  ligne  dans  le  script  que  de  décaler  la  numérotation  des  règles  en  mémoire.  Toutefois,  il  faut 
annuler toute règle avant chaque application du script. 

#!/bin/bash
# nom du fichier : /etc/parefeu_on
# Politique de base
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# NAT avec eth0 en interne et eth1 en sortie - adresse IP publique fixe

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 81.2.3.4
# gestion des paquets retours
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# trafic autorisé en sortie
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 53 -j ACCEPT

Bien entendu, il ne faudra pas oublier de le rendre exécutable. 
Il sera également utile de créer un script d’annulation de toute règle de filtrage. Il peut en effet être utile d’autoriser 
plus ou moins provisoirement tout trafic, pour une mise à jour du pare­feu ou un usage applicatif ponctuel. 

Exemple de script d’annulation de filtrage 

#!/bin/bash
# nom du fichier : parefeu_off
# Effacement des règles
iptables -F
# Politique permissive
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Enfin, on peut créer un script de gestion de service normalisé. 

Exemple de script de service de pare­feu 

Ce script est naturellement à placer dans le répertoire /etc/init.d. 

#!/bin/bash
# nom du fichier : parefeu
case $1 in
start)
/etc/parefeu_on
;;
stop)
/etc/parefeu_off
;;
status)
iptables -L
;;
*)
echo "Syntaxe : /etc/init.d/parefeu start|stop|status
;;
esac

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Détection des intrusions et des vulnérabilités 

1. Les systèmes IDS 

a. Les limitations des pare­feu 

Les pare­feu dans leur fonctionnement historique filtrent les paquets sur les valeurs contenues dans les en­têtes de 
couche réseau ou transport, et donc sur les adresses IP ou les ports utilisés. Pour contourner la protection apportée 
par les pare­feu, de nombreuses applications utilisent des ports courants (tcp 80 notamment) pour faire passer leur 
propre trafic applicatif. Les pare­feu, souvent configurés pour laisser passer les flux sur ces ports courants, n’y voient 
que du feu. 
Pour  assurer  un  meilleur  contrôle,  il  faut  utiliser  un  équipement  plus  élaboré,  capable  de  regarder  et  d’analyser le 
trafic applicatif, directement et sans se faire tromper par l’annonce d’un port erroné. Ces équipements sont appelés 
« sondes » en français parce que sondant l’intérieur des paquets, ou encore IDS (Intrusion Detection System). 

b. Techniques d’analyse 

Pour  identifier  les  trafics  malicieux,  les  IDS  disposent  de  trois  techniques  :  la  détection  d’anomalies,  l’analyse  de 
protocoles et l’analyse de signatures. 
La détection d’anomalies a pour objet de détecter un comportement anormal, comme par exemple un volume ICMP 
démesuré, qui indiquerait que l’on est la cible ou l’émetteur d’une attaque par dénis de service. 
L’analyse de protocole ne cherche pas à repérer une action réellement malicieuse, mais plutôt un trafic applicatif qui 
ne  respecterait  pas  à  la  lettre  les  règles  de  fonctionnement  des  protocoles  employés.  C’est  un  peu  l’histoire  du 
braqueur de banque qui se fait arrêter bêtement parce que ses pneus sont lisses. 
Enfin, l’analyse de signatures permet d’identifier des attaques ou comportements malsains déjà référencés. C’est la 
technique la plus efficace et qui n’est pas sujette à erreur, puisqu’on ne gère que des attaques ou intrusions ayant 
déjà eu lieu chez un tiers, et donc dûment identifiées. 

c. Sources d’information 

Les  techniques  d’analyse,  qu’il  s’agisse  d’analyse  de  signatures,  de  protocoles  ou  de  détections  d’anomalies 
s’appuient  sur  des  informations  qui  évoluent  avec  le  temps.  Il  est  évident  que  l’analyse  de  signature  ne  peut 
s’appliquer que si l’IDS connaît la signature de l’attaque en cours. De plus, la nature des menaces peut évoluer. Par 
exemple, un hôte qui aurait envoyé de gros volumes de trafics SMTP dans les années 80 indiquerait qu’un serveur de 
messagerie fonctionne bien. La même situation aujourd’hui pourrait montrer que l’hôte en question est infecté par 
un cheval de Troie et qu’il envoie de gros volumes de SPAM. 
Les IDS doivent impérativement récupérer à intervalle régulier les mises à jour de leurs techniques d’analyse ainsi 
que  les  bases  de  signatures.  Les  éditeurs  d’IDS  doivent  systématiquement  maintenir  leurs  bases  d’informations  à 
jour, et les administrateurs des IDS doivent tout aussi régulièrement télécharger ces bases. 

De nombreux organismes, associations et entreprises permettent de se tenir au courant des évolutions en matière 
de techniques d’intrusion et de nuisance. Il est recommandé de connaître l’existence des principaux, et dans le cadre 
d’une  administration  réseau  avec  prise  en  compte  de  la  sécurité,  d’assurer  une  veille  technologique  sur  ces 
domaines. 

Principaux organismes de veille et de recherche 

Bugtraq  Liste de diffusion dédiée à l’annonce des vulnérabilités, leur exploitation et leur 
correction. 

CERT  Computer Emergency Response Team. Cette organisation étudie les vulnérabilités, 
effectue de la recherche sur les évolutions en terme de réseaux et de sécurité, et 
propose des services liés à la sécurité. 

CIAC  Computer Incident Advisory Capability. Organisme de veille et de recherche géré par le 
U.S. Department Of Energy. 

2. SNORT 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


a. Les composants 

Snort est le plus connu des IDS libre. Il analyse tout trafic et apporte un complément de sécurité appréciable, voire 
indispensable sur un réseau. Snort est composé d’un moteur d’analyse, et d’un ensemble de règles. 
Snort  est  composé  d’un  service  et  de  fichiers  de  configuration  généralement  situés  sous  /etc/snort.  Le  fichier  de 
configuration principal est snort.conf. Les règles appliquées sont situées dans un sous­répertoire rules. 

Snort dispose également d’une commande oinkmaster de mise à jour des règles qui trouve sa configuration dans un 
fichier oinkmaster.conf. 

b. Gestion des sources d’information 

SNORT exploite des fichiers de règles qui doivent être téléchargés sur le site web de l’éditeur. 

Déclaration d’un fichier de règles dans oinkmaster.conf 

url = http://www.snort.org/snort-rules/fichier_règles

Où fichier_règles représente le fichier des règles au format tar.gz. Il est nécessaire d’être abonné auprès de l’éditeur 
mais d’autres sites web proposent des fichiers de mise à jour gratuits. Naturellement, la qualité du suivi dépend des 
gestionnaires de ces fichiers de règles. 
Après  toute  modification  du  fichier  de  définition  des  signatures,  et  par  la  suite  à  intervalle  régulier  par  une 
planification  cron,  il  faut  demander  à  snort  de  télécharger  ses  nouvelles  règles.  Cette  opération  se  réalise  avec  la 
commande oinkmaster. 

Chargement des règles 

oinkmaster -o rep_règles

Où rep_règles représente le répertoire qui contient les règles de fonctionnement de snort, souvent /etc/snort/rules. 
Les fichiers de règles doivent être appelés dans le fichier snort.conf par le paramètre include, ce qui est le cas avec 
les paramètres par défaut et les signatures de l’éditeur. 

c. Gestion des alertes 

Quand Snort détecte un trafic malicieux, il laisse une trace dans un fichier journal via syslog, et envoie une copie du 
paquet  dans  un  fichier  au  format  tcpdump  (format  libpcap,  visible  avec  wireshark  par  exemple).  Il  a  aussi  la 
possibilité d’envoyer  les  informations  vers  une  base  de  données  (Oracle,  MySQL,  et  PostGreSQL  sont  entre  autres 
supportés). 

Exemple de déclaration d’utilisation de syslog dans snort.conf 

Cette déclaration indique que les éléments doivent être envoyés vers un serveur syslog dont l’adresse IP est ip_serveur, 
sous la catégorie « alerte ». 

output alert_syslog: host=ip_serveur, LOG_ALERT

3. OpenVAS 

OpenVAS pour Open Vulnerability Assessment scanner est une variante libre du scanner de vulnérabilités Nessus. 

a. Le serveur OpenVAS 

Le serveur est le cœ ur de la suite applicative OpenVAS, il scanne et analyse les hôtes du réseau à la recherche de 
vulnérabilités connues (NVT : Network Vulnerability Tests). 

b. Les clients OpenVAS 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Les clients OpenVAS sont des éléments logiciels en ligne de commande ou avec une interface graphique qui assurent 
l’analyse des hôtes du réseau à la recherche de vulnérabilités pour renvoyer les résultats au serveur. 

c. Récupération des vulnérabilités 

OpenVas  propose  une  source  publique  de  vulnérabilités  connues  sous  le  nom  OpenVas  NVT  Feed.  Il  permet  aux 
serveurs  de  se  tenir  au  courant  des  dernières  vulnérabilités  connues,  et  contient  plus  de  15000  NVT  (Network 
Vulnerability Tests). 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


OpenSSH 

1. Utilisations de OpenSSH 

Les sessions interactives sur les systèmes Unix ont d’abord été conduites par des terminaux passifs, qui se bornaient 
à  gérer  les  entrées  et  sorties,  connectées  à  une  unité  centrale  par  un  port  série.  Les  frappes  au  clavier  étaient 
envoyées  brutes  à  l’unité  centrale,  et  l’unité  centrale  envoyaient  en  retour  des  ordres  d’affichage  à  l’écran.  Les 
ordinateurs  étant  alors  hors  de  prix,  le  coût  relativement  modeste  des  terminaux  passifs  permettait  de  mutualiser 
l’utilisation d’un ordinateur. 

Avec la généralisation des réseaux IP et la démocratisation des ordinateurs personnels, l’administration distante des 
systèmes  Unix  s’est  faite  ensuite  par  le  protocole  telnet.  Le  principe  est  rigoureusement  le  même  qu’avec  les 
terminaux passifs, si ce n’est que les frappes au clavier et ordres d’affichage sont envoyés dans des paquets telnet 
transportés par IP. Le problème est que la gestion de la sécurité avec le protocole telnet est largement insuffisante : 
une authentification est réalisée en texte clair, et aucune confidentialité n’est apportée aux échanges entre le client et 
le serveur. 
Le protocole SSH vise à apporter des services d’authentification et de confidentialité à des échanges entre clients et 
serveur  pour  le  transport  sécurisé  de  données.  Il  est  dans  la  plupart  des  cas  simples  utilisé  en  tant  que  «  telnet 
sécurisé  »  mais  il  est  aussi  capable  d’assurer  le  transport  sécurisé  d’autres  protocoles  applicatifs.  L’implémentation 
open source du protocole SSH est « OpenSSH  », créé et maintenu par les membres du projet OpenBSD. 

2. Gestion des authentifications 

a. Authentification par mot de passe 

L’utilisation  la  plus  simple  du  client  SSH,  qui  consiste  à  ouvrir  une  session  shell  distante  de  façon  sécurisée  sur 
réseau IP, exploite un mode d’authentification simple, à savoir utiliser un compte local sur le serveur et demander au 
client  de  s’authentifier avec le nom et le mot de passe de ce compte présent sur le serveur. Le mot de passe est 
alors  vérifié  et  l’authentification  est  validée.  Toutefois,  cette  phase  d’authentification  par  mot  de  passe  sert 
uniquement à vérifier la validité du client. Lequel client peut à son tour avoir des doutes sur l’identité et la légitimité 
du  serveur :  en  clair,  suis­je  bien  en  train  de  parler  à  mon  serveur,  ou  à  un  faux  serveur  qui  exploiterait  les 
commandes  tapées  pour  récupérer  des  informations  sur  mes  systèmes ?  Pour  éviter  tout  risque  d’usurpation  du 
serveur,  le  client  réalise  une  vérification  de  l’identité  du  serveur  à  la  première  connexion.  En  fait,  une  empreinte 
numérique du serveur est réalisée, et après validation de cette empreinte par le client, elle est conservée dans un 
fichier appelé known_hosts, présent dans un répertoire caché .ssh dans le répertoire personnel de l’utilisateur. 

Exemple de fichier known_hosts 

Le fichier known_hosts présente une (très longue) ligne par serveur connu. 

beta:~# cat .ssh/known_hosts


|1|LPx02U8nHnkSb0czyqVrdXPcW04=|jS0/QdS0HydzPZj8QXxHXC4j6EM= ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAv+kXth0/RSAroNfqeV+IkEMetdWRWYBvbNOqUDDSL/fLylBip9le40xfTe1j
FXuYqAWR+mQMo8Pg37/PUWeetlBCvG4F486UbqUn2Ol5B/1GZqzG7nvbOLcp7CDr6vmqgrk2QZvUZcohWc4L9S6z
zvk3EmQ1AMa+BKo4m+FCG9E1mK4bFtvchVqL1amzGg1jd2QuTzMGNibTdrEi9gSr2TrJ5Se9AhNQkIzZPvrqvVAD
itiggcYNetxaNkPKfW8DdClq+qOVVAQuWnZiO63Mp/0+b+JEutFgNsX8mkt9nx34Yws7s3BnIuT7oU+shxnuy/vj
5But4uUry5tFaTxXCw==
beta:~#

b. Authentification par clés 

Une  méthode  sans  doute  plus  fiable  pour  authentifier  les  connexions  SSH  consiste  à  utiliser  des  clés 
d’authentification  stockées  localement  sur  le  disque  de  l’utilisateur.  L’authentification  par  clés  ne  dispense  pas 
obligatoirement  de  la  saisie  d’un mot de passe, mais garantie à l’utilisateur  que  la  machine  distante  est  bien  celle 
avec laquelle on veut travailler et non pas une usurpatrice. 

Création de la paire de clés sur le client

Pour  que  le  serveur  puisse  être  formellement  identifié,  il  doit  disposer  de  la  clé  publique  du  client.  Cette  clé  lui 
permettra  de  crypter  des  données  déchiffrables  par  le  seul  client  propriétaire  de  la  clé  privée  correspondante.  Il 
convient donc dans un premier temps de générer cette clé publique sur le client. Comme il s’agit  de  cryptographie 
asymétrique, la génération d’une clé publique est obligatoirement simultanée à celle de la clé privée correspondante. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


La commande ssh­keygen permet de créer ces clés publiques et privées. 

Génération d’un couple de clés 

ssh-keygen -t algorithme

Où algorithme représente l’algorithme employé pour la génération des clés du client. Il peut s’agir de RSA (version 1 
ou  2  de  SSH)  ou  DSA  (version  2  de  SSH).  RSA  et  DSA  sont  deux  algorithmes  de  cryptage  asymétriques  souvent 
utilisés pour l’authentification. Si l’algorithme n’est pas précisé, la valeur par défaut RSA est employée. 

Génération d’un couple de clés avec les valeurs par défaut 

On  génère  ici  un  couple  de  clés  avec  l’algorithme  par  défaut  (RSA)  pour  l’utilisateur  tata.  La  représentation  graphique 
(randomart) de la clé n’est pas systématique et dépend de la version de la commande. 

tata@stotion:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tata/.ssh/id_rsa):
Created directory ’/home/tata/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tata/.ssh/id_rsa.
Your public key has been saved in /home/tata/.ssh/id_rsa.pub.
The key fingerprint is:
f3:5c:f1:34:6c:1b:a6:4c:5b:c4:6d:30:48:01:76:f4 tata@stotion
The key’s randomart image is:
+--[ RSA 2048]----+
| o+=++o |
| . ..+..o|
| o E. |
| o X + |
| S = o |
| + . |
| o |
| |
| |
+-----------------+
tata@stotion:~$

La  commande  ssh­keygen  provoque  la  création  de  deux  fichiers,  par  défaut  dans  un  répertoire  .ssh  situé 
directement dans le répertoire personnel de l’utilisateur. Ces deux fichiers sont par défaut id_rsa pour la clé privée 
et id_rsa.pub pour la clé publique correspondante. Même si ça n’est pas obligatoire, il est vivement recommandé de 
protéger la clé privée par un mot de passe qui sera demandé lors de sa création. 

Contenus de fichiers de clés privées et publiques 

On observe le contenu des fichiers de clés privées et publiques. Notez que les droits par défaut sont limités sur le fichier de 
clé privée, et ouverts sur le fichier de clé publique. 

tata@stotion:~/.ssh$ ls -l
total 8
-rw------- 1 tata tata 1743 2010-09-03 09:38 id_rsa
-rw-r--r-- 1 tata tata 394 2010-09-03 09:38 id_rsa.pub
tata@stotion:~/.ssh$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs0jrYKKQKiS4f/cCQMhOcc2WTMmGrbXXv3oyz67KUwkm4JumEU1
YkOaNi+WM4nVbkzC7rkUnlXQMxu/EpZLoraNySMHZjUgYiWiRuM4pI0z/atPfjVlwPtGzfUKlqSsP4NCark/9G0
WlMgEXlgpEdeJDmMBRuj98PJjOI/cRGRTgR6JEoevFWMPTDRpoBix3YizVY+dA+unJQPaNKWhoDnCZg7xWi+ZRg
T2Q1PcbqYKt4xLio+Eei0dvlgu5r5hSvymOdWbXwykywoloIxnzIPiUe7CAxm+KCBA23LQw73pREd1cglS6Gd23
b5Byv/oI6etqs4WOmcJa40Ymvtfbjw== tata@stotion
tata@stotion:~/.ssh$ cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B08C4C3C4B021A76

TzO6ofHOv8sVRDoPj+o7dXfPuXDJaOmQSGhDkWUTC9iGHYnGdHgsig5EKWEez0Zj
YucF9doTpLCv9UsRac6WHRjlQb7AUjk9phEjrKYW4gAfoXNcFY5IiC7fca9i8NQk
YCj4mtzmbJAFc0W9Ax8g0UzZ8bwElIacI28pAdSvVqVHQ6omnVBoWhXhgWTUZaKp

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


2XbY5gJ7miKW3Y9IPZ3JLukB3j4rTZ0bu8j/UedyXuogpZgYF2vW0GfvtBbfP31F
(...)
RZfBnf+3+KxTvnAtJsMSZc4Glg+9Gch9V+mjU2SfW+T+bUnYLB/6Mpo1aq/akj3r
0G6w12SgjqiOuuXnsCdU8Ox1olCqiHFrk0DyPmwoxcSQygpm2r7FIwL4MPxbELJO
zfk+0wJOmsUANJzeBKd4LXmZykYsAOmf3zZNlS+iU/ZhCBqFmn3/5w==
-----END RSA PRIVATE KEY-----
tata@stotion:~/.ssh$

À  chaque  connexion,  le  serveur  regarde  dans  le  répertoire  local  de  l’utilisateur  essayant  de  se  connecter  si  un 
répertoire .ssh/authorized_keys existe, et s’il contient la clé publique du client. Si c’est le cas, l’authentification du 
serveur  peut  être  réalisée  par  le  client.  Le  client  devra  donc  copier  son  fichier  de  clé  publique  dans  le  répertoire 
~/.ssh.authorized_keys du serveur par le moyen de son choix. (clé usb, copie réseau). 

c. L’agent SSH 

Pour les administrateurs ayant fréquemment besoin d’accéder à plusieurs machines par SSH, un « agent SSH », lancé 
par  la  commande  ssh­agent,  permet  de  conserver  en  mémoire  les  clés  privées  utilisées  pour  les  authentifications. 
Les clés privées sont transmises une fois pour toutes à l’agent par la commande  ssh­add. Si un mot de passe de 
protection  de  la  clé  est  nécessaire,  il  est  demandé  à  cette  occasion.  Les  clés  sont  ensuite  disponibles  sans 
intervention directe de l’utilisateur pour toute authentification. 
La  commande  ssh­add  consulte  le  répertoire  .ssh  dans  le  répertoire  personnel  de  l’utilisateur  et  recherche 
d’éventuelles  clés  privées  dans  les  fichiers  id_rsa, id_dsa,  et  identity.  Les  clés  stockées  par  l’agent  SSH  peuvent 
être consultées par la commande ssh­add ­l. 

Lancement de l’agent par la commande ssh­agent 

L’agent alimente des variables lors de son fonctionnement qui permettent de le gérer plus facilement. 

tata@stotion:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-sRuvox4519/agent.4519; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4520; export SSH_AGENT_PID;
echo Agent pid 4520;
tata@stotion:~$

ssh­agent : variables courantes 

SSH_AGENT_PID  Le pid de l’agent en cours d’exécution. 

SSH_AUTH_SOCK  Le socket créé par le processus. 

Prise en compte de clés par l’agent SSH 

La commande ssh­add sans argument permet la prise en compte des clés par l’agent SSH qui doit naturellement avoir été 
lancé auparavant. 

tata@stotion:~$ ssh-add
Enter passphrase for /home/tata/.ssh/id_rsa:
Identity added: /home/tata/.ssh/id_rsa (/home/tata/.ssh/id_rsa)
tata@stotion:~$

Visualisation des clés privées stockées par le ssh­agent 

La commande ssh­add ­l permet de vérifier que les clés ont bien été prises en compte par l’agent. 

tata@stotion:~$ ssh-add -l
2048 f3:5c:f1:34:6c:1b:a6:4c:5b:c4:6d:30:48:01:76:f4 tata@stotion (RSA)
2048 f3:5c:f1:34:6c:1b:a6:4c:5b:c4:6d:30:48:01:76:f4 /home/tata/.ssh/id_rsa (RSA)
tata@stotion:~$

L’agent SSH est avant tout une solution de gestion de clés et n’est pas destiné à créer les clés SSH. L’agent 
SSH ne peut travailler que sur des clés déjà créées par la commande ssh­keygen. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


3. Confidentialité des communications 

a. Session interactive avec SSH 

La session interactive est ouverte depuis un client vers un serveur avec un compte utilisateur présent sur le serveur. 

Ouverture de session interactive avec SSH 

ssh utilisateur@adresse_serveur

Session interactive avec SSH : option et paramètres 

utilisateur  Le compte utilisateur présent sur le serveur avec lequel on se connecte. 

adresse_serveur  L’adresse IP du serveur auquel on se connecte. 

Exemple d’ouverture de session interactive avec SSH 

alpha:~# hostname ; whoami


alpha
root
alpha:~# ssh toto@192.168.0.11
toto@192.168.0.11’s password:

toto@beta:~$ hostname ; whoami


beta
toto
toto@beta:~$

b. Copie de fichiers avec SSH 

La commande scp s’appuie sur le démon SSH et permet de copier des fichiers de façon sécurisée avec les services 
d’authentification et de confidentialité offerts par SSH. La copie peut se faire du client vers le serveur ou depuis le 
serveur vers le client. 

Copie de fichier du client vers le serveur avec scp 

scp fichier_local utilisateur@adresse_serveur:fichier_distant

Copie de fichier depuis le serveur vers le client avec scp 

scp utilisateur@adresse_serveur:fichier_distant fichier_local

Copie de fichiers avec scp : options et paramètres 

fichier_local  Chemin relatif ou absolu du fichier local devant être copié. 

fichier_distant  Chemin absolu du fichier distant devant être copié. 

utilisateur  Compte utilisateur existant sur le serveur utilisé pour la copie. 

adresse_serveur  Adresse IP du serveur hébergeant le service SSH. 

c. Utilisation d’applications dans des tunnels SSH 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


La  création  d’un  tunnel  SSH  permet  de  sécuriser  une  communication  client­serveur  pour  un  protocole  à  priori  peu 
sécurisé. On établit depuis le poste client un tunnel SSH vers le serveur, et tout le trafic entre ces deux machines est 
sécurisé.  Le  serveur  génère  alors  un  autre  trafic  non  sécurisé  vers  la  machine  cible  du  trafic.  Les  connexions  des 
clients qui souhaitent emprunter le tunnel se font en fait vers le client SSH. 

Création d’un tunnel applicatif SSH 

ssh -L port:cible_trafic:port_cible utilisateur@serveur

Tunnel SSH : options et paramètres 

­L  Renvoie un port local vers un serveur SSH (établissement de tunnel). 

port  Le port local à renvoyer. 

cible_trafic  Adresse IP ou nom de la machine cible du trafic. 

port_cible  Port vers lequel renvoyer le trafic sur la machine cible. 

utilisateur  Compte utilisateur sur le serveur utilisé pour l’établissement du tunnel. 

serveur  Adresse IP ou nom du serveur extrémité du tunnel. 

Dans ce fonctionnement, un tunnel est établi entre un client et un serveur. Sur le client, le trafic à destination du port 
local est renvoyé au travers du tunnel SSH vers la machine cible sur le port cible. 

d. Renvoi de sessions X11 via SSH 

Le serveur X ne prévoyant nativement pas de sécurité forte pour ses échanges clients­serveurs, un usage courant 
de SSH consiste à faire circuler dans un tunnel SSH des applications graphiques. Il faut pour cela autoriser le serveur 
SSH à relayer ce type de trafic, puis d’utiliser un client compatible avec ce mode de fonctionnement. 

L’autorisation  du  renvoi  de  sessions  X  via  SSH  se  fait  en  modifiant  le  fichier  de  configuration  du  serveur 
SSH /etc/ssh/sshd_config. 

Autorisation du renvoi des connexions X dans sshd_config.conf 

X11Forwarding yes

Connexion depuis un client SSH 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


ssh -X utilisateur@serveur

Où utilisateur représente le compte utilisé pour la connexion, et serveur l’adresse IP ou le nom du serveur auquel on 
se connecte. Les applications graphiques peuvent alors être lancées depuis la session SSH cliente. 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


OpenVPN 
OpenVPN est une solution logicielle open source de création de tunnels sécurisés (VPN). Contrairement aux VPN usuels, 
elle ne s’appuie pas sur IPSEC mais sur SSL. Elle assure des services d’authentification, de confidentialité et de contrôle 
d’intégrité. 

1. Les modes de fonctionnement OpenVPN 

OpenVPN  supporte  deux  types  principaux  de  fonctionnement  réseau  :  le  mode  point­à­point  et  le  mode  site­à­site. 
Dans tous les cas, des services d’authentification et de confidentialité sont assurés en standard. 

a. Authentification 

Les extrémités de tunnel, c’est­à­dire les deux machines assurant le cryptage des flux sortants et le décryptage des 
flux  entrants,  doivent  être  mutuellement  authentifiées.  Il  ne  faut  pas  qu’il  y  ait  de  doute  sur  l’authenticité  du 
correspondant.  OpenVPN  supporte  plusieurs  modes  d’authentification,  mais  les  deux  plus  courants  sont 
l’authentification  par  clé  partagée,  et  l’authentification  par  certificats  numérique  X509.  La  première  solution  est 
infiniment  plus  simple  à  mettre  en  œ uvre  mais  passe  pour  être  moins  sécurisée.  La  seconde,  si  elle  est 
recommandée,  est  toutefois  beaucoup  plus  difficile  à  déployer  si  on  n’a  pas  une  connaissance  intime  des 
infrastructures  à  clés  publiques  qui  permettent  de  générer  les  certificats.  Il  est  souvent  préférable  d’avoir  une 
solution à clé partagée qui fonctionne correctement plutôt qu’une infrastructure à clé publique bancale mal maitrisée 
et donc difficile à maintenir. 

b. Confidentialité 

La  confidentialité  des  communications  est  assurée  par  la  bibliothèque  OpenSSL.  Le  cryptage  des  échanges  est 
assuré  par  l’algorithme  Blowfish  par  défaut,  mais  les  algorithmes  symétriques  courants  sont  utilisables  (AES 
notamment). 

c. Fonctionnement réseau 

Le mode de fonctionnement le plus simple et le plus facile à appréhender est le mode point­à­point dans lequel les 
deux protagonistes du vpn sont ceux qui doivent communiquer ensemble de façon sécurisée : ils sont à les fois les 
extrémités de tunnel et les extrémités de trafic. Il est aussi possible de relier deux réseaux entre eux en mode site­
à­site. Deux serveurs OpenVPN assurent alors la mise en place du tunnel, mais les extrémités de trafic sont les deux 
réseaux reliés. Les serveurs OpenVPN assurent alors un rôle de routage entre les réseaux. Enfin, il est possible de 
faire du VPN d’accès distant dans lequel une machine est reliée à un réseau. 
OpenVPN peut fonctionner en mode bridgé, dans ce cas il mettra en connexion deux réseaux distants, un peu comme 
si  on  avait  ajouté  un  câble  entre  les  switches  des  deux  réseaux  à  relier,  fût­il  un  câble  de  200  km.  Ce  mode  de 
fonctionnement peut être considéré comme anecdotique, et le mode routé est de loin le plus utilisé. 
Les paquets cryptés sont transportés par UDP par défaut mais l’utilisation de TCP est possible. 

2. Création d’un tunnel point­à­point 

a. Gestion de l’authentification 

La  méthode  d’authentification  par  clé  partagée  suppose  la  présence  d’un  fichier  de  clé  au  format  reconnu  par 
OpenVPN. Ce fichier doit être présent sur le serveur et le client, et donc copié par un moyen sécurisé. (clé usb, scp) 
Le fichier peut être généré directement par la commande openvpn. 

Génération du fichier de clé secrète 

openvpn --genkey --secret fichier_cle

Où fichier_cle représente le fichier contenant la clé secrète. 

Exemple de génération de clé 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


On génère ici un fichier de clé secrète qui permettra l’authentification entre les machines aux extrémités du tunnel. 

alpha:/etc/openvpn# openvpn --genkey --secret secret.key


alpha:/etc/openvpn# cat secret.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
ae11344ce37de44dcce059ecf9fa573f
a2694d5531bc7ed144a12a099c4ef8ce
(... )
1d37552cd4f29ff6b719588056a60777
579cc2aff71bf339f5293bf08f2ce4df
-----END OpenVPN Static key V1-----
alpha:/etc/openvpn#

b. Fichiers de configuration 

Les fichiers de configuration se trouvent par défaut dans un répertoire /etc/openvpn. Si l’usage veut que les fichiers 
portent les noms client.conf et serveur.conf, n’importe quel fichier avec l’extension .conf fera l’affaire. 

Format du fichier de configuration OpenVPN 

remote serveur
dev tun
ifconfig IP_locale IP_distante
secret fichier_cle
route réseau_distant masque

Fichier de configuration OpenVPN : directives courantes 

remote serveur  Sur le client uniquement. serveur indique le nom ou l’adresse ip du 
serveur auquel connecter le VPN. 

dev tun  Crée une d’encapsulation de type tunnel (par opposition à 
l’encapsulation ethernet bridgée). 

ifconfig IP_locale IP_distante  Établit les adresses locales et distantes des extrémités de trafic. 
Ces adresses seront visibles sous forme d’interface virtuelle dans la 
configuration réseau de l’hôte. 

secret fichier_cle  Indique le fichier contenant la clé partagée, identique sur les deux 
machines. 

route réseau_distant masque  Paramètre client : indique l’adresse du réseau privé derrière le 


serveur pour que le trafic à destination de ce réseau soit 
correctement routé par le VPN. 

Exemple de fichiers de configuration OpenVPN 

Fichier de configuration côté serveur. 

alpha:/etc/openvpn# cat server.conf


dev tun
ifconfig 10.8.0.1 10.8.0.2
secret secret.key

Fichier de configuration côté client. 

beta:/etc/openvpn# cat client.conf


remote alpha

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


dev tun
ifconfig 10.8.0.2 10.8.0.1
secret secret.key
route 192.168.1.0 255.255.255.0

c. Mise en œuvre du tunnel vpn 

Une fois les fichiers créés sur le serveur et le client, il suffit de démarrer de part et d’autre le service par son script de 
démarrage. 

La validation de fonctionnement peut se faire par un ping entre les deux adresses de tunnel. Une capture de trames 
permettra aussi d’observer un trafic entre les deux machines sur le port UDP/1194 par défaut. 

Exemple de test d’un tunnel point­à­point 

On  lance  le  service  par  son  script  normalisé,  on  vérifie  la  présence  d’une  interface  virtuelle,  et  on  contrôle  le 
fonctionnement du tunnel par un trafic quelconque. 

beta:~# ifconfig tun0


tun0: erreur lors de la recherche d’infos sur l’interface: Périphérique non trouvé
beta:~# /etc/init.d/openvpn start
Starting virtual private network daemon: client.
beta:~# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.2 P-t-P:10.8.0.1 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

beta:~# ping 10.8.0.1


PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.864 ms

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Compilation des applications 

1. Généralités 

a. Principe de la compilation 

Les programmes utilisés en informatique en général appartiennent à deux familles : les programmes interprétés et 
les programmes compilés. Un programme interprété est écrit dans un langage de programmation (basic, perl, shell, 
etc.),  et  doit  pour  son  exécution  être  lu  par  un  programme  spécifique  appelé  interpréteur.  À  chacune  de  ses 
exécutions, l’interpréteur doit reparcourir le code du programme. Un programme compilé est écrit avec un langage de 
programmation  (Pascal,  C,  C++,  etc.),  et  est  ensuite  passé  au  travers  d’un  compilateur.  Le  compilateur  est  un 
programme  exécutable  qui  lit  le  code  du  programme  à  compiler  (appelé  code  source),  et  qui  génère  lors  de  cette 
opération  un  autre  programme  exécutable,  binaire,  qui  pourra  s’exécuter  indépendamment  du  compilateur.  La 
plupart des programmes utilisés en environnement Linux sont de type compilé, et le noyau Linux en est un exemple 
particulier. 

b. Quand faut­il compiler ? 

Les applicatifs sont la plupart du temps fournis sous forme de paquetage déjà compilé, et prêts à l’emploi. Dans ces 
conditions,  la  compilation  est  une  opération  qui  revient  au  créateur  du  paquetage,  et  l’utilisateur  n’a  pas  à  s’en 
préoccuper. Le succès de distributions comme Ubuntu vient en partie du très grand nombre de paquetages présents 
et disponibles à la demande. 
Il  arrive  toutefois  qu’on  doive  compiler  soi­même  une  application.  Par  exemple  parce  qu’on  souhaite  avoir  une 
version de logiciel récente qui n’est pas disponible sous forme de paquetage, ou bien que le paquetage n’existe pas 
dans  notre  distribution.  Par  ailleurs,  la  compilation  peut  être  personnalisée  par  des  options,  et  le  créateur  d’un 
paquetage  a  forcément  fait  pour  son  paquet  des  choix  arbitraires  quant  à  ces  options  de  compilation.  Dans  ces 
conditions, on peut souhaiter compiler soi­même son application et obtenir ainsi un fonctionnement spécifique. 

c. Rappels sur les utilitaires de décompression 

Les sources de programmes utilisées lors de la compilation d’applications sont presque toujours fournies sous forme 
d’archives  compressées.  Il  faut  donc  se  souvenir  des  syntaxes  permettant  de  gérer  les  archives  au  format  tar 
compressé, de loin le plus courant. 

Décompression d’une archive au format tar compressé en gzip 

tar xzf archive.tgz

Décompression d’une archive au format tar compressé en bzip2 

tar xjf archive.tar.bzip2

L’extension des fichiers est strictement conventionnelle et peut varier. 

2. Procédure de compilation GNU 

Dans la plupart des situations, la compilation est une opération qui échoie au développeur : le développeur écrit son 
programme, le compile, et livre le code exécutable prêt à l’emploi. Les compétences nécessaires à la compilation sont 
donc généralement ignorées du grand public. Le monde open source change un peu la donne où les codes sources de 
tous  les  programmes  sont  par  définition  disponibles  et  où  il  arrive  que  fréquemment  que  l’utilisateur  final  doive 
compiler lui­même son application. Une procédure de compilation standard a donc été définie, afin qu’un utilisateur non 
averti soit capable de réaliser cette opération. 

a. Récupération des sources 

Le  code  source  d’une  application  open  source  est  par  définition  toujours  disponible,  en  général  sur  un  site  web 
attaché  au  projet  de  développement  de  l’application.  Le  site  web  sourceforge.net  accueille  en  particulier  de 
nombreux projets de développement. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


Une  fois  les  sources  téléchargées,  il  suffit  de  les  extraire  de  leur  archive  et  de  se  placer  dans  le  répertoire  ainsi 
extrait. Toutes les opérations relatives à la compilation se réaliseront depuis la racine de ce répertoire. 

b. Configuration de la compilation 

La  compilation  suppose  un  certain  nombre  de  pré­requis :  la  présence  du  compilateur,  l’éventuelle  présence  de 
bibliothèques  nécessaires  à  la  compilation  du  programme,  et  surtout  un  fichier  de  réponses  qui  sera  lu  par  le 
compilateur  pendant  la  compilation.  Dans  le  cadre  de  la  procédure  standard  de  compilation  GNU,  un  script  nommé 
configure doit se trouver dans le répertoire racine des sources, et ce script est précisément chargé de réaliser ces 
trois opérations. Ce script a été écrit par le développeur du programme et est livré avec les sources. 
Lors  de  son  exécution,  éventuellement  avec  des  options  de  compilation,  ce  script  va  vérifier  l’environnement  et 
renvoyer  un  message  d’erreur  en  cas  de  défaut  de  l’environnement  de  compilation  (compilateur  et  bibliothèques 
nécessaires). Si tout va bien, ce script finit par la génération de fichiers de réponses (un par sous­répertoire présent 
dans  le  répertoire  des  sources)  nommés  Makefile.  Ces  fichiers  de  réponses  sont  eux­mêmes  créés  à  partir  des 
options  passées  au  script  de  configuration  et  d’un  fichier  modèle  Makefile.in.  Si  l’observation  du  contenu  de  ces 
fichiers  peut  répondre  à  une  curiosité  bien  légitime,  elle  n’est  absolument  pas  nécessaire  pour  la  suite  des 
opérations. 

Exécution du script configure sans option 

On lance le script de configuration depuis le répertoire racine des sources. On constate à la fin du traitement la mention « 
creating Makefile » qui est le but ultime de l’exécution du script. 

[root@beta rdesktop-1.6.0]# ./configure


checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
(...)
checking for setmntent... yes
checking build system type... i686-redhat-linux-gnu
checking host system type... i686-redhat-linux-gnu
configure: creating ./config.status
config.status: creating Makefile
[root@beta rdesktop-1.6.0]#

Gestion des défaillances par le script de configuration 

Le script de configuration détecte ici l’absence de bibliothèques nécessaires. On est ici particulièrement chanceux avec un 
conseil précis de la part du script, ce qui est loin d’être le cas général. 

[root@beta rdesktop-1.6.0]# ./configure


checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
(...)
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for X... no

ERROR: Could not find X Window System headers/libraries.


Probably you need to install the libx11-dev package.
To specify paths manually, use the options --x-includes and --x-libraries.
[root@beta rdesktop-1.6.0]#

c. Personnalisation des programmes compilés 

Le développeur peut prévoir lors de la rédaction de son script de configuration des options de compilation. Le fichier 
Makefile  sera  alors  généré  en  fonction  des  options  ajoutées  lors  du  lancement  du  script  configure.  La  liste  des 
options est disponible en tapant la commande ./configure ­­help. 

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Exécution du script configure avec options 

On exécute d’abord le script configure avec l’option ­­help pour prendre connaissance des options disponibles, puis avec la 
ou les options choisies. 

[root@beta rdesktop-1.6.0]# ./configure --help


`configure’ configures rdesktop 1.6.0 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as


VAR=VALUE. See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking...’ messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache’
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..’]
(...)
[root@beta rdesktop-1.6.0]#
[root@beta rdesktop-1.6.0]# ./configure --with-ipv6
checking for gcc... gcc
(...)
configure: creating ./config.status
config.status: creating Makefile
[root@beta rdesktop-1.6.0]#

d. Compilation 

La compilation se réalise simplement par la commande make, exécutée sans paramètre ni option depuis le répertoire 
racine des sources où se trouvent les fichiers Makefile et Makefile.in. Cette opération est assez longue et aboutit si 
tout  se  passe  bien  à  la  génération  des  fichiers  binaires  compilés.  Il  est  à  noter  qu’à  cette  étape,  ces  fichiers  se 
trouvent exclusivement dans l’arborescence des sources. 

Compilation mal préparée 

On tente ici de réaliser une compilation par la commande make sans avoir auparavant configuré la compilation. 

[root@beta rdesktop-1.6.0]# make


make: *** Pas de cibles spécifiées et aucun makefile n’a été trouvé. Arrêt.
[root@beta rdesktop-1.6.0]#

Compilation sans encombre 

La commande de compilation make a trouvé ses fichier de réponse. 

[root@beta rdesktop-1.6.0]# make


(...)
gcc -g -O2 -Wall -I/usr/include -DPACKAGE_NAME=\"rdesktop\"
-DPACKAGE_TARNAME=\"rdesktop\" -DPACKAGE_VERSION=\"1.6.0\"
-DPACKAGE_STRING=\"rdesktop\ 1.6.0\" -DPACKAGE_BUGREPORT=\"\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DL_ENDIAN=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_LOCALE_H=1 -DHAVE_LANGINFO_H=1 -Dssldir=\"/usr\"
-DEGD_SOCKET=\"/var/run/egd-pool\" -DWITH_RDPSND=1 -DRDPSND_OSS=1

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


-DHAVE_DIRENT_H=1 -DHAVE_DIRFD=1 -DHAVE_DECL_DIRFD=1 -DHAVE_ICONV_H=1
-DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_STATVFS_H=1
-DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_MOUNT_H=1
-DSTAT_STATVFS=1 -DHAVE_STRUCT_STATVFS_F_NAMEMAX=1 -DHAVE_STRUCT_STATFS_F_NAMELEN=1
-DHAVE_MNTENT_H=1 -DHAVE_SETMNTENT=1
-DKEYMAP_PATH=\"/usr/local/share/rdesktop/keymaps/\" -o rdesktop
rdesktop.o xwin.o xkeymap.o ewmhints.o xclip.o cliprdr.o rdpsnd.o
rdpsnd_dsp.o rdpsnd_oss.o tcp.o iso.o mcs.o secure.o licence.o
rdp.o orders.o bitmap.o cache.o rdp5.o channels.o rdpdr.o serial.o
printer.o disk.o parallel.o printercache.o mppc.o pstcache.o lspci.o
seamless.o ssl.o -L/usr/lib -lcrypto -lX11
[root@beta rdesktop-1.6.0]#

e. Les cibles de la commande make 

La  commande  make  permet  de  réaliser  la  compilation  proprement  dite,  mais  la  même  commande  appelée  avec 
certains arguments permet de réaliser des actions diverses autour de la compilation. On appelle ces arguments des 
cibles. Toutes les cibles ne sont pas toujours disponibles, et leur présence dépend des objectifs du développeur. Les 
cibles d’installation des binaires ou de nettoyage simple des sources sont néanmoins toujours disponibles. 

f. Installation des binaires 

Depuis  le  répertoire  des  sources,  il  faut  ensuite  taper  la  commande make  install  pour  provoquer  l’installation des 
fichiers  binaires  compilés  dans  leurs  répertoires  de  destination  au  sein  de  l’arborescence  du  système  de  fichiers 
Linux. L’installation peut aussi provoquer la copie des fichiers de manuel ou de configuration. 

Installation automatique de tous les éléments compilés 

La commande make exécutée avec la cible install copie les fichiers binaires compilés ainsi que tout élément prévu par le 
développeur. Les droits d’écriture sur les répertoires cibles sont nécessaires. 

[root@beta rdesktop-1.6.0]# make install


mkdir -p /usr/local/bin
/usr/bin/install -c rdesktop /usr/local/bin
/usr/bin/install:
(...)
[root@beta rdesktop-1.6.0]#

g. Nettoyage des sources 

La commande make clean exécutée depuis le répertoire racine des sources nettoie l’arborescence de tout élément 
déjà compilé et permet de relancer une autre compilation à partir des mêmes sources et du même environnement. 
La  commande  make  mrproper  permet  comme  son  nom  l’indique  un  nettoyage  complet  de  tout  élément  généré 
localement, des fichiers compilés aux fichiers de configuration (Makefile) générés auparavant. 

Nettoyage simple des sources 

La commande make exécutée avec la cible clean efface tous les éléments générés par la compilation mais laisse les fichiers 
de configuration en place. 

[root@beta rdesktop-1.6.0]# ls Makefile


Makefile
[root@beta rdesktop-1.6.0]# make clean
rm -f *.o *~ vnc/*.o vnc/*~ rdesktop rdp2vnc
[root@beta rdesktop-1.6.0]# ls Makefile
Makefile
[root@beta rdesktop-1.6.0]#

h. Désinstallation d’un programme 

La  commande  make  uninstall  exécutée  depuis  le  répertoire  racine  des  sources  nettoie  le  système  de  tous  les 

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


fichiers installés par la commande make install. 

Récapitulatif de la procédure de compilation standard GNU 

cd rep_sources
./configure
make
make install

Où rep_sources représente le répertoire des sources, obtenu par extraction de l’archive tar compressée. 

3. Environnement des applications 

a. Les bibliothèques 

Une bibliothèque (library en anglais) est un ensemble d’éléments pré­programmés utilisable par les développeurs. Ils 
peuvent ainsi gagner du temps par la réutilisation de fonctions courantes et s’affranchir de la ré­écriture de fonctions 
triviales. L’usage de bibliothèques en environnement graphique permet aussi de donner une unité aux programmes 
avec des éléments d’interfaces cohérents. 
La  bibliothèque  libstdc++  est  presque  toujours  disponible  sur  les  systèmes  Linux  car  exploitée  par  de  nombreux 
programmes,  et  les  applications  graphiques  exploitent  fréquemment  les  bibliothèques  gtk  ou  qt.  Il  existe  des 
centaines  de  bibliothèques  actives  utilisées  en  environnement  Linux.  Elles  sont  normalement  situées  dans  le 
répertoire /usr/lib. 
La  plupart  des  programmes  sont  compilés  de  façon  dynamique  (par  opposition  à  statique).  C’est­à­dire  qu’ils 
reposent sur les mêmes bibliothèques que celles employées par le développeur, mais qui sont présentes localement 
sur le système. Les applications doivent donc impérativement disposer des bonnes bibliothèques au moment de leur 
exécution. 
On peut vérifier quelles sont les bibliothèques nécessaires à un exécutable par la commande ldd. 

Visualisation des bibliothèques utilisées par un exécutable 

On observe pour chaque bibliothèque le fichier correspondant présent sur le disque. 

alpha:~# ldd /bin/ls


linux-gate.so.1 => (0xb775b000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7744000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb772b000)
libacl.so.1 => /lib/libacl.so.1 (0xb7723000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75c8000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb75af000)
/lib/ld-linux.so.2 (0xb775c000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb75ab000)
libattr.so.1 => /lib/libattr.so.1 (0xb75a6000)
alpha:~#

La commande ldconfig permet de créer les liens entre les applications et les bibliothèques présentes sur le système. 
Elle regarde dans son fichier de configuration /etc/ld.so.conf quels sont les chemins à analyser lors de la recherche 
de bibliothèques. Un fichier /etc/ld.so.cache contenant la liste des bibliothèques est alors généré. 

Prise en compte des bibliothèques locales 

ldconfig

Affichage des bibliothèques exploitables 

ldconfig -p

Création du fichier de cache avec ldconfig 

On efface ici le cache pour vérifier que le fichier est bien créé par la commande. 

root@beta:~$ rm /etc/ld.so.cache

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


root@beta:~$ ls /etc/ld.so.cache
ls: ne peut accéder /etc/ld.so.cache: Aucun fichier ou dossier de ce type
root@beta:~$ ldconfig
root@beta:~$ ls /etc/ld.so.cache
/etc/ld.so.cache
root@beta:~$

Visualisation des bibliothèques 

On constate que la commande ldconfig ­p s’appuie sur le fichier de cache qu’elle a auparavant généré. 

[root@beta ~]# ldconfig -p


776 libs found in cache `/etc/ld.so.cache’
libz.so.1 (libc6) => /usr/lib/libz.so.1
libz.so (libc6) => /usr/lib/libz.so
libxslt.so.1 (libc6) => /usr/lib/libxslt.so.1
libxslt.so (libc6) => /usr/lib/libxslt.so
libxml2.so.2 (libc6) => /usr/lib/libxml2.so.2
libxml2.so (libc6) => /usr/lib/libxml2.so
libxmlsec1.so.1 (libc6) => /usr/lib/libxmlsec1.so.1
libxmlsec1.so (libc6) => /usr/lib/libxmlsec1.so
libxklavier.so.11 (libc6) => /usr/lib/libxklavier.so.11
(...)
[root@beta ~]#

Il est aussi possible pour un usage ponctuel de renseigner un chemin de bibliothèques dans une variable système 
LD_LIBRARY_PATH. 

Déclaration de chemins de bibliothèques 

LD_LIBRARY_PATH=chemin1:chemin2:...:cheminn
export LD_LIBRARY_PATH

Où les cheminx représentent le chemin absolu du répertoire contenant les directives. 

b. Visualisation des appels systèmes 

Il  est  possible  de  tester  le  fonctionnement  des  applications  en  visualisant  les  appels  systèmes  réalisés  par 
l’application lors de son exécution. La commande strace appliquée à un programme intercepte les appels systèmes 
réalisés  par  un  processus  ainsi  que  les  signaux  reçus  par  ce  processus.  Cette  commande,  utile  aux  développeurs, 
est  d’un  usage  délicat  pour  les  non­spécialistes.  La  commande  ltrace,  similaire  se  cantonne  aux  chargements  de 
bibliothèque et ignore les appels systèmes. 

Exemple d’utilisation de la commande strace 

On constate l’appel de diverses bibliothèques lors de l’exécution de la commande echo. 

[root@beta ~]# strace echo bonjour


execve("/bin/echo", ["echo", "bonjour"], [/* 35 vars */]) = 0
brk(0) = 0x9d71000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=60638, ...}) = 0
mmap2(NULL, 60638, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe8000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\317\270\0004\
0\0\0"..., 512) = 512
(...)
brk(0) = 0x9d71000
brk(0x9d92000) = 0x9d92000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=56464512, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7de6000
close(3) = 0

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7ff6000
write(1, "bonjour\n", 8bonjour
) = 8
close(1) = 0
munmap(0xb7ff6000, 4096) = 0
exit_group(0) = ?
[root@beta ~]#

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


Compilation du noyau 
Du point de vue de la compilation, le noyau est presque une application comme les autres, avec un code source, une 
procédure de compilation et une procédure d’installation. 

1. Les composants du noyau 

Le noyau Linux est responsable de la gestion du matériel. La notion de pilote de périphérique n’existe pas directement 
en  environnement  Linux  puisque  les  éléments  permettant  de  communiquer  correctement  avec  un  périphérique  sont 
compris dans le code du noyau. On se rend assez vite compte du confort de cette situation : le noyau récent compris 
dans  une  distribution  Linux  permet  de  gérer  directement  l’ensemble  des  périphériques  d’un  système  sans  avoir  à 
installer  des  pilotes  supplémentaires.  En  contrepartie,  le  code  du  noyau  pour  gérer  l’ensemble  des  périphériques 
existant a tendance à devenir de plus en plus imposant, et son chargement intégral entraînerait une consommation de 
mémoire  démesurée.  Pour  cette  raison,  le  noyau  a  une  structure  modulaire,  et  seuls  les  modules  nécessaires  au 
fonctionnement du système sont chargés en mémoire. 

a. Le cœur de noyau 

Ce  que  l’on  peut  appeler  le  «  cœ ur  de  noyau  »  est  la  partie  irréductible  du  noyau,  celle  qui  sera  intégralement 
chargée  en  mémoire.  Elle  ne  contient  en  principe  que  des  éléments  dont  on  est  sûr  qu’ils  seront  nécessaires  à 
l’utilisation.  Le  cœ ur  de  noyau  est  un  fichier  se  trouvant  dans  le  répertoire  /boot  et  dont  la  taille  est  de  quelques 
MégaOctets. 

b. Les modules 

L’importance des modules de noyau

Les modules ont un rôle primordial car beaucoup de fonctions essentielles sont gérées sous forme de modules. Si un 
noyau ne dispose pas des modules nécessaires au fonctionnement du système, les fonctions afférentes ne seront 
tout simplement pas disponibles. 

Tentative de chargement d’une ressource non supportée 

Cet exemple est réalisé sur un système dont le noyau ne supporte pas le format de filesystem ext3. 

light:/mnt# mount /dev/hda3 partition


mount: unknown filesystem type ’ext3’
light:/mnt#

Les  modules  sont  des  fichiers  portant  l’extension  .ko  qui  sont  chargés  en  mémoire  en  fonction  des  besoins.  Des 
commandes sont disponibles pour consulter la liste des modules chargés, en retirer de la mémoire ou en charger de 
nouveaux. 

Les  noyaux  de  versions  anciennes  (2.4  notamment)  exploitent  des  fichiers  de  modules  portant  l’extension 
« .o ». 

Manipulations ponctuelles des modules

Affichage des modules chargés en mémoire 

lsmod

Affichage des modules disponibles sur le système 

modprobe -l

Les  fichiers  correspondants  à  ces  modules  se  trouvent  conventionnellement  dans  un  répertoire  /lib/modules  et 
dans une sous­arborescence du nom noyau courant, tel que renvoyé par la commande uname ­r. 

Retrait d’un module chargé en mémoire 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


rmmod nom_module
ou
modprobe -r nom_module

Où nom_module représente le nom du module présent en mémoire tel qu’il a été affiché par la commande lsmod. Les 
deux commandes rmmod et modprobe ­r ont le même résultat. 

Chargement d’un module en mémoire 

insmod fichier_module
ou
modprobe nom_module

Où nom_module représente le nom du module tel qu’il serait affiché par la commande lsmod, alors que fichier_module 
représente  le  nom  du  fichier  de  module  présent  sur  le  disque.  En  fait,  le  nom  du  module  est  obtenu  en  retirant 
l’extension .ko au nom du fichier. 

Chargement d’un module 

Le chargement manuel du module qui manquait précédemment rend possible le montage de la partition ext3. 

light:/mnt# insmod /lib/modules/2.6.26-2-686/kernel/fs/ext3/ext3.ko


light:/mnt# mount /dev/hda3 partition
light:/mnt# mount
/dev/hda1 on / type ext2 (rw,errors=remount-ro)
(...)
/dev/hda3 on /mnt/partition type ext3 (rw)
light:/mnt#

Chargement forcé d’un module

Les modules sont en principe chargés au démarrage en fonction de la détection du matériel présent. Il est toutefois 
possible  de  forcer  le  chargement  d’un  module  en  alimentant  un  fichier  de  configuration  des  modules.  Tout  module 
mentionné dans un fichier /etc/modules sera chargé inconditionnellement au démarrage. 

Configuration des modules

Le  fichier  /etc/modules.conf  permet  de  configurer  certains  modules  et  notamment  de  définir  des  associations 
forcées entre périphérique et modules. 

Exemple de fichier /etc/modules.conf 

# Association forcée du pilote tg3 avec la carte réseau


alias eth0 tg3

À titre de vérification ou pour voir si les associations entre le matériel et les modules se sont bien réalisées, il est 
possible d’afficher des informations sur les modules chargés avec la commande modinfo. 

Visualisation des informations liées à un module 

On voit notamment le fichier .ko contenant le code du module, quelques informations d’environnement et les alias gérés 
dynamiquement par le système pour les matériels liés à ce module. 

root@serveur:/boot$ modinfo r8169


filename: /lib/modules/2.6.32-24-generic/kernel/drivers/net/r8169.ko
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
srcversion: D37E06388C6313C1D062CC3
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI


alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
alias: pci:v000010ECd00008136sv*sd*bc*sc*i*
alias: pci:v000010ECd00008129sv*sd*bc*sc*i*
depends: mii
vermagic: 2.6.32-24-generic SMP mod_unload modversions
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
root@serveur:/boot$

c. Autour du noyau 

Nous savons maintenant que le noyau est constitué d’une entité insécable, et de modules chargés en mémoire à la 
demande.  Lors  de  la  phase  de  démarrage,  le  gestionnaire  de  démarrage  charge  le  noyau,  et  les  modules 
correspondants  à  la  configuration  matérielle  du  système  sont  également  chargés.  Pour  accélérer  la  phase  de 
détection  du  matériel  et  le  chargement  des  modules  associés,  la  plupart  des  systèmes  modernes  exploitent  un 
ramdisk (disque virtuel dont le support physique est la mémoire) contenant l’ensemble des modules. Ce ramdisk est 
généré après la compilation du noyau, et est appelé directement par le gestionnaire de démarrage. 

d. Gestion des versions du noyau 

Le noyau porte un numéro de version de type A.B.C, par exemple 2.6.15. « A » donne la version principale du noyau, 
actuellement,  et  pour  sans  doute  encore  quelques  temps,  la  version  2.  «  B  »  représente  la  version  courante  du 
noyau. Cette valeur est systématiquement paire sur les versions de noyaux stables et impaire sur les versions en 
développement.  Enfin,  «  C  »  est  incrémenté  en  fonction  des  évolutions  mineures  de  noyau,  essentiellement  les 
corrections de bogues et les prises en charge de nouveaux matériels. 
La commande uname ­r permet d’afficher la version du noyau en cours d’exécution. 

Affichage de la version du noyau courant 

toto@serveur:~$ uname -r
2.6.32-24-generic
toto@serveur:~$

2. Procédure de compilation et d’exploitation 

La procédure de compilation doit toujours être consultée dans le fichier README présent avec les sources du noyau. 
Les  éléments  spécifiques  du  noyau  sont  documentés  dans  un  répertoire Documentation fourni avec les sources. Le 
fichier README ne documente que la procédure de compilation. 

a. Récupération des sources 

Le  code  source  du  noyau  est  téléchargeable  librement  depuis  le  site  «  http://www.kernel.org  ».  Les  principales 
versions y sont disponibles. Les liens « Full source » permettent de télécharger le code source complet du noyau. 
Le noyau étant livré sous forme d’une archive tar.bz2, il faut d’abord la décompresser. Comme pour toute compilation 
d’application, la majeure partie du travail se passera dans le répertoire issu de l’extraction de l’archive. 
Si  on  travaille  sur  les  sources  de  noyau  copiées  lors  de  l’installation  du  système,  le  répertoire  de  travail  devrait 
être /usr/src/linux. La documentation se trouvera alors naturellement dans /usr/src/linux/Documentation. En cas de 
travail sur des sources nouvelles, un répertoire neutre est recommandé. 

b. Génération du fichier de réponse 

La compilation s’effectue en fonction des informations données dans un fichier .config qui se trouve dans la racine du 
répertoire  des  sources.  Ce  fichier  indique  pour  chaque  élément  du  noyau  s’il  doit  être  présent  dans  le  cœ ur  de 
noyau, présent sous forme de module, ou absent du noyau compilé. 
Selon le système employé, plusieurs moyens sont à notre disposition pour générer ce fichier de réponse. 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 3-


Génération du fichier de réponses : commandes possibles 

make config  Pose la question à l’utilisateur pour chacun des modules. 

make menuconfig  Présente une interface texte améliorée. 

make xconfig  Présente une interface graphique. 

make gconfig  Présente une interface graphique. 

make defconfig  Génère un fichier de réponse en s’appuyant sur toutes les valeurs de compilation par 
défaut. 

make oldconfig  Génère un fichier de réponse en s’appuyant sur un fichier .config déjà utilisé pour 
une version plus ancienne du noyau. 

Si la compilation du noyau ne présente pas de difficulté particulière, le renseignement du fichier de réponse requiert 
une compétence étendue et la connaissance précise du matériel. 

Exemple de création du fichier de réponses 

La compilation précise du noyau nécessite une connaissance de toutes les technologies matérielles gérées par ce noyau. 

[root@beta linux-2.6.34.4]# make config


HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/basic/hash
HOSTCC scripts/kconfig/conf.o
(...)
PentiumPro memory ordering errata workaround (X86_PPRO_FENCE) [Y/n/?] y
HPET Timer Support (HPET_TIMER) [Y/n/?] y
Maximum number of CPUs (NR_CPUS) [8] (NEW) 8
SMT (Hyperthreading) scheduler support (SCHED_SMT) [Y/n/?] y
Multi-core scheduler support (SCHED_MC) [Y/n/?] y
Preemption Model
1. No Forced Preemption (Server) (PREEMPT_NONE)
> 2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT)
choice[1-3]: 2
Reroute for broken boot IRQs (X86_REROUTE_FOR_BROKEN_BOOT_IRQS) [N/y/?] (NEW) n
Machine Check / overheating reporting (X86_MCE) [Y/n/?] n
Toshiba Laptop support (TOSHIBA) [M/n/y/?] n
Dell laptop support (I8K) [M/n/y/?] m
Enable X86 board specific fixups for reboot (X86_REBOOTFIXUPS) [N/y/?]n
(...)
CRC-CCITT functions (CRC_CCITT) [M/y/?] m
CRC16 functions (CRC16) [M/y/?] m
CRC calculation for the T10 Data Integrity Field (CRC_T10DIF) [N/m/y/?] (NEW) m
CRC ITU-T V.41 functions (CRC_ITU_T) [M/y/?] m
CRC32 functions (CRC32) [Y/?] y
CRC7 functions (CRC7) [N/m/y/?] (NEW) n
CRC32c (Castagnoli, et al) Cyclic Redundancy-Check (LIBCRC32C) [Y/m/?] y
#
# configuration written to .config
#

[root@beta linux-2.6.34.4]#

Premières lignes du fichier de configuration 

[root@beta linux-2.6.34.4]# head -15 .config


#

- 4- © ENI Editions - All rights reserved - Sanisa HOUAMRI


# Automatically generated make config: don’t edit
# Linux kernel version: 2.6.34.4
# Mon Aug 16 16:57:44 2010
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
[root@beta linux-2.6.34.4]#

Taille indicative du fichier de configuration 

[root@beta linux-2.6.34.4]# wc -l .config


3641 .config
[root@beta linux-2.6.34.4]#

La configuration des modules pour une version de noyau installée doit se trouver dans un fichier config­version dans 
le répertoire /boot. 

Visualisation des fichiers de configuration des noyaux 

root@serveur:/boot$ ls config*
config-2.6.27-11-generic config-2.6.32-21-generic config-2.6.32-24-generic
config-2.6.28-16-generic config-2.6.32-22-generic
config-2.6.31-21-generic config-2.6.32-23-generic
root@serveur:/boot$ cat config-2.6.32-24-generic
#
# Automatically generated make config: don’t edit
# Linux kernel version: 2.6.32-24-generic
# Thu Aug 19 01:38:31 2010
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
(...)
root@serveur:/boot$

c. Compilation du noyau et des modules 

La compilation se réalise le plus simplement du monde en tapant la commande make depuis le répertoire racine des 
sources. La durée de l’opération dépend de la puissance de la machine sur laquelle elle est réalisée, mais une bonne 
heure est souvent nécessaire. Pour un noyau en version 2.6, la commande make provoque la compilation du noyau 
et des modules. 

Compilation du noyau et des modules 

C’est parti pour une heure ou deux... 

[root@beta linux-2.6.34.4]# make


scripts/kconfig/conf -s arch/x86/Kconfig
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/generated/utsrelease.h

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 5-


UPD include/generated/utsrelease.h
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/x86/kernel/asm-offsets.s
(...)
CC arch/x86/kernel/cpu/cpufreq/speedstep-lib.o
CC arch/x86/kernel/cpu/cpufreq/speedstep-smi.o
LD arch/x86/kernel/cpu/cpufreq/built-in.o
CC [M] arch/x86/kernel/cpu/cpufreq/powernow-k8.o
CC [M] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.o
CC [M] arch/x86/kernel/cpu/cpufreq/speedstep-centrino.o
CC [M] arch/x86/kernel/cpu/cpufreq/p4-clockmod.o
CC arch/x86/kernel/cpu/mcheck/mce.o
CC arch/x86/kernel/cpu/mcheck/mce-severity.o
CC arch/x86/kernel/cpu/mcheck/mce_intel.o
(...)

L’exécution  de  la  commande  make  provoque  la  compilation  du  noyau  et  de  ses  modules.  Elle  appelle  aussi  la 
commande depmod qui génère le fichier modules.dep de dépendance des modules. 

d. Installation des modules 

Les  modules  sont  installés  par  la  commande  spécifique  make  modules_install.  Ils  sont  copiés  dans  un 
répertoire /lib/modules, sous un répertoire correspondant à la version du noyau. 

Visualisation des répertoires contenant les modules 

Chaque version de noyau installé a son répertoire de modules correspondant. 

root@serveur:~$ ls /lib/modules/
2.6.27-11-generic 2.6.28-16-generic 2.6.32-22-generic
2.6.27-7-generic 2.6.31-21-generic 2.6.32-23-generic
2.6.27-9-generic 2.6.32-21-generic 2.6.32-24-generic
root@serveur:~$

e. Installation du noyau 

Le  noyau  hors­modules se trouve dans le répertoire des sources dans une arborescence arch/x86/boot  pour  les 


versions 32 bits ou arch/ia64/boot pour les versions 64 bits sous le nom bzImage. Son installation dans le système 
en production se fait en copiant simplement ce fichier dans le répertoire /boot. Le nom utilisé par défaut (bzImage) 
est tout à fait exploitable, mais il est préférable de le renommer pour tenir compte de la version compilée. 

Des  compilations  réalisées  avec  des  versions  anciennes  de  noyau  peuvent  générer  un  fichier  zImage  et  non 
bzImage. Le préfixe z ou bz indique le format de compression du fichier noyau (gzip pour z et bzip2 pour bz). 

Un noyau nouvellement compilé doit toujours être installé en plus du noyau existant. Ne jamais remplacer un 
noyau qui fonctionne par un nouveau noyau. 

Installation du noyau 

L’usage veut que le fichier de noyau ait un nom normalisé qui reflète sa version. 

root@serveur# cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.15


root@serveur#

f. Création du ramdisk des modules 

Il  faut  mettre  à  disposition  du  noyau  un  ramdisk  contenant  l’ensemble  des  modules  compilés  pour  la  nouvelle 
version. Ce ramdisk nécessite un fichier image, qui peut être construit avec deux commandes différentes en fonction 
de  la  génération  du  système  employé.  La  commande  historique  est  mkinitrd.  Elle  tend  à  disparaître  au  profit  de 
mkinitramfs. 

- 6- © ENI Editions - All rights reserved - Sanisa HOUAMRI


Création d’un ramdisk avec la commande mkinitrd 

mkinitrd nom_image version

Création d’un ramdisk avec la commande mkinitramfs 

mkinitramfs -o nom_image version

Où nom_image représente le nom du fichier image de ramdisk à créer, et version le numéro de version du noyau. Ce 
numéro correspond en fait au répertoire des modules situé dans /lib/modules. 

Exemple de création d’un ramdisk 

root@serveur:/boot$ mkinitrd /boot/initrd-2.6.28.img 2.6.28


root@serveur:/boot$ file initrd-2.6.28.img
initrd.img-2.6.32-24-generic: gzip compressed data, from Unix, last modified: Fri
Aug 20 07:54:31 2010
root@serveur:/boot$

Le  fichier  ramdisk  est  en  fait  une  archive  cpio  compressée  au  format  gzip.  Les  commandes  de  création  de  ramdisk 
génèrent directement leurs fichiers à ce format. 

Un système récent ne devrait proposer que la commande mkinitramfs. Si toutefois mkinitrd était disponible 
aussi,  elle  ne  devrait  pas  être  utilisée.  mkinitrd  s’appuie  sur  devfs  et  non  udev,  et  ne  supporte  pas  les 
disques sata. 

g. Configuration du gestionnaire de démarrage 

Il  ne  suffit  pas  d’avoir  compilé  le  noyau  et  de  l’avoir  placé  au  bon  endroit,  encore  faut­il  que  le  gestionnaire  de 
démarrage  soit  configuré  pour  être  capable  de  charger  ce  noyau.  Il  conviendra  donc  d’ajouter  une  entrée  au 
gestionnaire  de  démarrage  en  conséquence.  Attention,  il  ne  faut  rien  retirer  à  la  configuration  du  gestionnaire  de 
démarrage : on ne touche pas à ce qui marche déjà. Il suffit d’ajouter une entrée dans le fichier de configuration du 
gestionnaire en se basant au besoin sur les entrées déjà présentes. 

Ajout d’une entrée au gestionnaire de démarrage 

La préservation des entrées existantes permet de toujours pouvoir démarrer sur une configuration stable. 

# noyau fonctionnel d’origine


title Debian GNU/Linux, kernel 2.6.26-2-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda1 ro quiet
initrd /boot/initrd.img-2.6.26-2-686

# noyau ajouté à tester


title ESSAI - modules statiques
root (hd0,0)
kernel /boot/vmlinuz-2.6.20 root=/dev/hda1 ro quiet
initrd /boot/initrd.img-2.6.20

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 7-


Patch du noyau 

1. Ajout de patch 

Il est possible pour bénéficier d’un noyau récent de télécharger les sources complètes du noyau, de les compiler et de 
les installer en tant que nouveau noyau. Une méthode alternative consiste à utiliser les sources de l’ancien noyau et 
de les patcher avant de les recompiler. 

Les patchs se téléchargent sur le site http://www.kernel.org et s’ajoutent aux sources nues du noyau. L’application 
d’un  patch  se  fait  en  général  avec  la  commande  patch  et  peut  se  faire  spécifiquement  avec  un  script  livré  avec  le 
noyau  s’appelant patch­kernel.  Le  script  patch­kernel  se  trouve  dans  un  répertoire  scripts  des  sources  du  noyau, 
alors que la commande patch est livrée avec la distribution Linux. 

Application d’un patch à des sources 

patch -pn < fichier_patch

Application de patch : options et paramètres 

­pn  Dépend de la conception du fichier de patchs. Remonte de n niveaux hiérarchiques 
dans les chemins des fichiers exprimés.  

fichier_patch  Le fichier contenant les patchs à appliquer. 

Un fichier de patch est en fait le résultat d’une commande diff appliquée à deux arborescences de sources différentes. 
Le fichier résultant contiendra donc une référence à chacun des fichiers de l’arborescence qui doivent être modifiés. Si 
le niveau hiérarchique des fichiers décrits dans le patch ne correspond pas à celui des sources à modifier, le paramètre 
­p permet de décaler cette hiérarchie. 

Exemple d’application d’un patch 

Les fichiers de patch sont extrêmement sensibles à la conformité des sources auxquelles ils sont appliqués. On n’obtiendra 
un résultat satisfaisant que si on applique le bon patch aux bonnes sources. 

[root@beta linux-2.6.34]# patch -p1 < patch-2.6.34.4


patching file Documentation/.gitignore
patching file Documentation/hwmon/ltc4245
patching file Documentation/kernel-parameters.txt
patching file Makefile
patching file arch/arm/Kconfig
patching file arch/arm/common/sa1111.c
patching file arch/arm/include/asm/atomic.h
patching file arch/arm/include/asm/tlbflush.h
patching file arch/arm/kernel/kprobes-decode.c
patching file arch/arm/kernel/perf_event.c
patching file arch/arm/mach-mx2/devices.c
patching file arch/arm/mach-omap2/board-rx51-peripherals.c
patching file arch/arm/mach-pxa/cm-x300.c
patching file arch/arm/mach-realview/Kconfig
patching file arch/arm/mach-realview/include/mach/barriers.h
patching file arch/arm/mm/cache-v7.S
patching file arch/arm/mm/copypage-feroceon.c
patching file arch/arm/mm/copypage-v4wb.c
patching file arch/arm/mm/copypage-v4wt.c
patching file arch/arm/mm/copypage-xsc3.c
(...)
[root@beta linux-2.6.34]#

2. Retrait de patchs 

Le  retrait  d’un  patch  appliqué  se  fait  avec  la  même  commande  et  la  même  syntaxe,  à  laquelle  on  ajoute  le 

© ENI Editions - All rights reserved - Sanisa HOUAMRI - 1-


commutateur ­R. 

Application d’un patch à des sources 

patch -pn -R < fichier_patch

Application de patch : options et paramètres 

­pn  Dépend de la conception du fichier de patchs. Remonte de n niveaux hiérarchiques 
dans les chemins des fichiers exprimés.  

­R  Retire le patch au lieu de l’appliquer. 

fichier_patch  Le fichier contenant les patchs à appliquer. 

Exemple de suppression d’un patch 

[root@beta linux-2.6.34]# patch -p1 -R < patch-2.6.34.4


patching file Documentation/.gitignore
patching file Documentation/hwmon/ltc4245
patching file Documentation/kernel-parameters.txt
patching file Makefile
patching file arch/arm/Kconfig
patching file arch/arm/common/sa1111.c
patching file arch/arm/include/asm/atomic.h
(...)

- 2- © ENI Editions - All rights reserved - Sanisa HOUAMRI