Vous êtes sur la page 1sur 343

LINUX 

Préparation à la certification LPIC-2 (examens LPI 201 et LPI 202)

Sébastien BOBILLIER  

Résumé
Les examens LPI 201 et LPI 202 sont les deux examens qui permettent d’obtenir la certification LPIC-2 « Advanced Level Linux Professional ».
Ce programme de certification du Linux Professional Institute est de plus en plus reconnu par les recruteurs qui voient dans cette certification un
pré-requis à l’embauche ou à l’accession à un poste d’administrateur.
Les examens LPI 201 et 202 prouvent aux professionnels que vous maitrisez l’administration avancée d’un système Linux quelle que soit la
distribution : ils sanctionnent une compétence pratique en termes d'administration d'un réseau de petite ou moyenne taille (administration des
services réseaux courants, gestion de la sécurité du réseau et des échanges…).
Pour vous aider à préparer efficacement cette certification, ce livre couvre tous les objectifs officiels de la dernière version de l’examen, tant d’un
point de vue théorique que d’un point de vue pratique. Il a été rédigé en français (il ne s’agit pas d’une traduction) par un formateur professionnel
reconnu, également consultant, certifié Linux. Ainsi, les savoir-faire pédagogique et technique de l’auteur conduisent à une approche claire et
visuelle, d’un très haut niveau technique.
Chapitre par chapitre, vous pourrez valider vos acquis théoriques, à l’aide d’un grand nombre de questions-réponses (110 au total) mettant en
exergue aussi bien les éléments fondamentaux que les caractéristiques spécifiques aux concepts abordés.
Chaque chapitre s’achevant par des travaux pratiques (32 au total) vous aurez les moyens de mesurer votre autonomie. Ces manipulations
concrètes, au-delà même des objectifs fixés par l’examen, vous permettront de vous forger une première expérience significative et d’acquérir de
véritables compétences techniques sur des mises en situations réelles.
À cette maîtrise du produit et des concepts, s’ajoute la préparation spécifique à la certification : vous pourrez accéder gratuitement à 1 examen
blanc en ligne, destiné à vous entraîner dans des conditions proches de celles de l’épreuve.

Les chapitres du livre :


Descriptif - Introduction – Gestion du stockage – Démarrage du système – Gestion du réseau local – Authentification des utilisateurs – Partages
de fichiers – Résolutions 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, spécialiste des systèmes Linux, il accompagne régulièrement des
candidats à la certification LPI et ce livre est le fruit de toute son expérience dans le domaine.

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 - Samuel CASAL - 1-


Préparation  à  la  Certification  LINUX  LPIC­2  examens  LPI  201  et  LPI 
202 
Les examens LPI 201 et LPI 202 sont les deux examens qui permettent d’obtenir la certification LPIC­2 "Advanced 
Level  Linux  Professional".  Ce  programme  de  certification  du  Linux  Professional  Institute  est  de  plus  en  plus reconnu 
par  les  recruteurs  qui  voient  dans  cette  certification  un  pré­requis  à  l’embauche  ou  à  l’accession  à  un  poste 
d’administrateur. 
Les  examens  LPI  201  et  202  prouvent  aux  professionnels  que  vous  maîtrisez  l’administration  avancée  d’un système 
Linux  quelle  que  soit  la  distribution  :  ils  sanctionnent  une  compétence  pratique  en  termes  d’administration  d’un 
réseau de petite ou moyenne taille (administration des services réseaux courants, gestion de la sécurité du réseau et 
des échanges…). 

Pour vous aider à préparer efficacement cette certification, ce livre couvre les objectifs officiels dont la liste est donnée 
en annexe. Il se divise en 12 chapitres comportant chacun l’organisation ci­après : 

● Une  définition  des  objectifs  à  atteindre  :  permet  d’exposer  précisément  les  compétences  données  par  le 
chapitre une fois celui­ci validé. 

● Une partie cours théoriques : permet de définir les termes et concepts abordés et de schématiser sous forme 
d’un fil conducteur les différents points à assimiler. 

● Une partie  validation  des  acquis proposée sous forme de questions/réponses (110 au total). Ces questions 


mettent en exergue aussi bien les éléments fondamentaux que les caractéristiques spécifiques aux concepts 
abordés. La partie réponses reprend les questions posées avec des réponses rédigées pour chacune d’elles. 

● Les travaux pratiques : ils permettent d’illustrer précisément certaines parties du cours et vous donnent aussi 
les  moyens  de  mesurer  votre  autonomie.  Ces  manipulations  concrètes,  au­delà même des objectifs fixés par 
l’examen,  vous  permettront  de  vous  forger  une  première  expérience  significative  et  d’acquérir  de  véritables 
compétences techniques sur des mises en situations réelles. 

Pour la préparation spécifique à l’examen, vous pouvez accéder gratuitement à 1 examen blanc en ligne à l’adresse 
http://www.edieni.com  afin  de  vous  entraîner  dans  conditions  proches  de  celles  de  l’épreuve.  Sur  ce  site,  chaque 
question posée s’inscrit dans l’esprit de la certification et, pour chacune, les réponses sont suffisamment commentées 
pour contrôler et identifier vos ultimes lacunes. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


La certification LPI 

1. Intérêt de la certification 

L’univers  Open  Source  fourmille  de  personnes  aux  compétences  diverses  et  aux  bases  plus  ou  moins  solides.  Les 
gourous  sont  innombrables  sur  internet,  et  les  travaux  réalisés  par  certains  amateurs  sont  bluffants,  parfois 
supérieurs à ce que font des salariés spécialistes du domaine. 

Les entreprises pourraient être ravies de cette masse de compétences disponible, et embaucher parfois même à bas 
prix  ces  utilisateurs  passionnés.  Le  problème,  c’est  que  cette  compétence  s’acquiert  souvent  en  autodidacte,  sans 
beaucoup  de  méthode,  et  fréquemment  en  dehors  de  tout  cadre  professionnel,  ce  qui  empêche  les  candidats  de 
mettre en avant leurs états de services en entreprise. En outre, l’apprentissage autodidacte ne se fait pas par amour 
du logiciel (quoique), et les utilisateurs amateurs ont souvent une vision très parcellaire de la chose, centrée sur leurs 
centres d’intérêt personnels. 
Les  programmes  de  certification  ont  pour  objet  de  valider  une  compétence,  indépendamment  de  tout  parcours 
universitaire ou scolaire. Ils visent à sanctionner un niveau concret, et en ce qui concerne la certification LPI, à vérifier 
que le candidat a une vision transversale du sujet, sans impasse manifeste sur aucun des sujets traités. 

2. La certification LPI en quelques points 

Le programme de certification LPI est le principal programme de certification Linux multidistributions et indépendant 
de tout éditeur. Il est conçu par une communauté de professionnels du monde Linux et de formateurs. Les examens 
sont conçus pour sanctionner toute impasse sur un des sujets testés. On peut les présenter dans tous les centres de 
test agréés Pearson VUE ou Prometric. 
Le  programme  de  certification  LPI  est  reconnu  par  de  nombreux  éditeurs  et  professionnels  du  secteur  comme  IBM, 
Novell, Intel ou HP. Il est en outre un pré­requis à d’autres programmes de certifications comme Ubuntu ou alimenté 
par d’autres éditeurs comme Suse. À ce jour, on dénombre plus de 85000 certifiés LPI dans le monde avec plus de 
250000 examens présentés. 

3. Le programme de la certification LPI 

a. Niveau 1 

Le  niveau  1  de  la  certification  LPI  s’obtient  en  passant  les  deux  examens  LPI  101  et  102.  Il  sanctionne  une 
connaissance de base (ce qui ne veut pas dire que c’est facile) des systèmes Linux, des commandes de base et du 
shell.  On  peut  considérer  ces  compétences  comme  un  pré­requis  à  toute  évolution  sérieuse  dans  l’administration 
des systèmes Linux. L’acquisition des compétences liées à la certification LPI Niveau 1 ne conduit pas à l’autonomie 
complète sur le sujet, mais à un bon niveau de confort dans l’exécution de tâches encadrées. 

b. Niveau 2 

Le  niveau  2  de  la  certification  LPI  s’obtient  en  passant  les  deux  examens  LPI  201  et  202.  Il  sanctionne  une 
compétence  pratique  en  terme  d’administration  d’un  réseau  de  taille  petite  ou  moyenne,  sur  l’administration  des 
services  réseau  courants.  La  gestion  de  la  sécurité  du  réseau  et  des  échanges  est  également  traitée.  Un 
administrateur système et réseaux certifié LPI niveau 2 est autonome dans l’administration de son réseau et ses 
machines. 

c. Niveau 3 

Le niveau 3 de la certification LPI s’obtient en passant l’examen LPI 301, auquel on peut adjoindre cinq examens de 
spécialisation numérotés 302 à 306 traitant des environnements mixtes, de la sécurité, de la haute disponibilité et 
de la virtualisation, des technologies internet, et enfin de la messagerie. La certification LPI niveau 3 est présentée 
par LPI comme le niveau ultime de la certification Linux. 

4. Le passage d’examen 

Le passage d’une certification LPI laisse souvent un goût amer. La difficulté des questions semble insurmontable, et 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


on  est  souvent  tenté  de  penser  que  cette  certification  injuste  ne  sanctionne  pas  réellement  une  compétence  mais 
plutôt la capacité d’apprendre par cœ ur l’ensemble des pages de manuel des commandes Linux. Naturellement, cette 
prouesse n’étant pas à la portée d’êtres humains à la vie sociale ordinaire, il faudra chercher ailleurs les clés de la 
réussite. 
Comme dans tous les questionnaires à choix multiples, il convient d’abord en cas d’incertitude d’éliminer les réponses 
fantaisistes,  la  bonne  réponse  se  trouve  alors  souvent  dans  une  liste  réduite  à  deux  ou  trois  propositions.  Par 
ailleurs, il faut se souvenir que le passage de la certification LPI repose d’une part sur une connaissance théorique, 
mais aussi, et surtout, sur une compétence pratique longuement acquise sur les systèmes Linux. Dans le principe, on 
se  forme,  on  passe  quelques  années  à  administrer  des  systèmes  en  production,  et  on  passe  la  certification  pour 
prouver  qu’on  a  assimilé  un  savoir­faire.  Il  est  évident  que  ça  n’est  pas  possible  pour  tout  le  monde,  et  pour 
beaucoup,  notamment  sur  le  marché  du  travail  hexagonal,  la  certification  est  plutôt  vue  comme  le  moyen  de 
décrocher l’emploi qui apportera l’expérience véritable. Cette équation apparemment insoluble peut tout de même se 
résoudre,  et  cet  ouvrage  est  là  pour  vous  y  aider.  Simplement,  il  ne  suffira  pas  d’avoir  réalisé  l’ensemble  des 
exercices  et  travaux  pratiques,  mais  il  faudra  aussi  les  avoir  digérés.  C’est­à­dire  qu’il  faudra  avoir  compris  les 
concepts sous­jacents, l’intérêt des commandes employées, et être capable de les employer en dehors du contexte 
des exercices. 
Si on n’a pas sous la main une infrastructure Linux en production pour s’entraîner, une bonne approche consiste à lire 
ce livre et à réaliser les travaux pratiques qui clôturent chaque chapitre. Dans un premier temps, on se rassure en 
constatant  que  tout  fonctionne  normalement  (si  on  suit  scrupuleusement  les  indications,  tous  les  exercices 
fonctionnent).  En  effet,  il  est  très  important  de  ne  pas  se  décourager :  la  certification  LPI  suppose  que  l’on  soit  à 
l’aise avec tous les concepts et commandes, une lecture démotivée et l’apprentissage sans conviction de commandes 
admises  mais  non  comprises  ne  suffira  pas.  Une  fois  rasséréné  par  la  réalisation  réussie  des  exercices,  on  peut 
recommencer la lecture, approfondir les points obscurs, et s’enhardir à essayer des variantes pour les exercices. Des 
possibilités ouvertes seront laissées dans les travaux pratiques, libre à vous de les réaliser. 

À ce jour, les examens LPI se passent toujours en anglais, et il est recommandé d’avoir une bonne connaissance de 
l’anglais technique. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Ce livre 

1. Les informations techniques 

Ce livre vise essentiellement à préparer à la certification LPI. Son contenu technique est donc orienté dans ce sens. 
Certains  détails  fonctionnels  ou  certaines  commandes  exposées  ici  sont  aujourd’hui  un  peu  désuets,  mais  la 
certification LPI exige leur connaissance. 

La  certification  LPI  niveau  2  sanctionne  des  candidats  disposant  d’une  excellente  connaissance  pratique  des 
systèmes  Linux  et  des  services  applicatifs  courants.  Les  questions  sont  parfois  piégeuses,  justement  pour  vérifier 
que  le  candidat  possède  une  expérience  concrète  de  l’administration  et  qu’il  s’est  déjà  trouvé  dans  des  situations 
particulières  en  marge  du  fonctionnement  courant  "quand  tout  va  bien".  On  trouvera  donc  ici  les  explications,  les 
connaissances, et autant que possible les astuces qu’une longue pratique devrait apporter. 

Les informations sur les commandes et applications Linux sont bien entendu publiques et largement disponibles, ne 
serait­ce  que  par  le  manuel  en  ligne.  Les  syntaxes  des  commandes  exposées  ici  ne  présentent  que  les  options 
véritablement importantes : soit parce qu’elles sont utilisées couramment en production, soit parce que les objectifs 
spécifiques LPI les rendent particulièrement importantes. Le candidat peut donc, au moins dans un premier temps, se 
concentrer sur les connaissances essentielles. 

2. Les travaux pratiques 

Les travaux pratiques proposés s’appuient sur un environnement mixte composé de deux serveurs et d’une station 
de travail Linux. Le premier des serveurs sera installé avec une distribution Debian, et l’autre avec une distribution 
CentOS, qui a l’avantage d’être très proche des systèmes Red Hat, tout en étant beaucoup plus facile à se procurer. 
La station de travail sera installée à partir d’une distribution Ubuntu. 

Lors  d’un exercice sur l’installation  d’un  gestionnaire  de  démarrage,  un  live  CD  DSL  (Damn  Small  Linux)  sera  utilisé 
ponctuellement. 

Les machines auront comme nom d’hôte alpha pour le serveur Debian, beta pour le serveur CentOS, et station pour 
la  station  de  travail  Ubuntu.  Leurs  adresses  IP  devront  se  trouver  dans  votre  plan  d’adressage  et  sont  sans 
importance pour la réalisation des exercices, le tout étant de rester cohérent. Les adresses utilisées pour les travaux 
pratiques  seront  192.168.200.101  pour  le  serveur  alpha,  192.168.200.102  pour  le  serveur  beta,  et  une  adresse 
quelconque dans le même sous­réseau pour la station de travail. À vous de remplacer ces adresses par vos adresses 
choisies. 
L’environnement  de  travail  est  virtualisé  pour  permettre  le  montage  facile  d’une  maquette  réaliste  sans  avoir  à 
déployer un matériel considérable. La virtualisation a également l’avantage de permettre de réaliser des opérations 
lourdes sur le stockage à moindre coût. Le logiciel de virtualisation choisi est VirtualBox OSE, qui a l’avantage d’être 
disponible gratuitement, et de pouvoir s’installer aussi bien sur les postes de travail Windows que Linux. L’adaptation 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


à un autre logiciel de virtualisation ne devrait pas présenter de difficulté majeure. 
Si vous souhaitez travailler dans un environnement réel, les travaux pratiques sont très facilement adaptables, avec 
trois  postes  de  travail  dont  un  en  double  carte,  un  switch  et  quelques  câbles  réseau.  Quelques  disques  durs 
supplémentaires seront alors nécessaires. 
Quel que soit l’environnement choisi, un accès internet est nécessaire à la réalisation de la plupart des exercices. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Préparation des travaux pratiques 

1. Téléchargement des logiciels 

● Le logiciel de virtualisation VirtualBox est téléchargeable à l’adresse suivante  : 

http://www.virtualbox.org/wiki/Downloads. 

● L’image iso de la distribution Debian est téléchargeable à l’adresse suivante : 

http://www.debian.org/CD/netinst.  La  version  "net  install"  de  la  distribution  est  légère  et  les  composants 
additionnels s’installeront à la demande. 

● L’image iso de la distribution CentOS est téléchargeable à l’adresse suivante : 

http://mirror.centos.org/centos/5/isos. Téléchargez la version DVD. 

● L’image iso de la distribution Ubuntu est téléchargeable à l’adresse suivante : 

http://www.ubuntu.com/desktop/get­ubuntu/download. 

● L’image iso de la distribution DSL est téléchargeable à l’adresse suivante : 

http://www.damnsmalllinux.org/download.html. 

Les travaux pratiques sont réalisés à partir de la version 3.1.6 de VirtualBox, version Lenny (5) pour Debian, version 
5  pour  CentOS,  et  version  Lucid  Lynx  (10.04)  pour  Ubuntu.  L’utilisation  de  versions  différentes  ne  devrait  pas 
bouleverser  le  déroulement  des  exercices.  DSL  peut  être  utilisé  dans  sa  dernière  version  disponible  et  peut  être 
remplacé par n’importe quel autre live CD si nécessaire. 
Il  est  souvent  préférable  de  choisir  les  versions  32  bits  des  systèmes  (i386)  pour  travailler  en  environnement 
virtualisé. 

2. Gestion des supports virtuels 

a. Éléments nécessaires 

● Image iso d’un système CentOS. 

● Image iso d’un système Debian. 

● Image iso d’un système DSL. 

● Image iso d’un système Ubuntu. 

● Logiciel VirtualBox installé. 

b. Manipulations 

■ Depuis l’interface VirtualBox, déroulez le menu Fichier et chargez le Gestionnaire de supports virtuels. 

■ Dans le gestionnaire de supports virtuels, cliquez sur l’onglet Image disque optique. 

■ Cliquez sur Ajouter. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


■ Choisissez le fichier iso du système Debian. 

■ Répétez l’opération pour les autres fichiers images. 

3. Installation du serveur alpha 

a. Éléments nécessaires 

● Logiciel VirtualBox installé. 

b. Création de la machine virtuelle 

■ Depuis l’interface VirtualBox, cliquez sur Nouveau pour lancer l’assistant de création de machine virtuelle. 

■ Dans l’écran Nom de la machine virtuelle et type de système d’exploitation, tapez alpha dans le champ Nom, 
sélectionnez Linux comme Système d’exploitation, et Debian comme Version. 

■ Dans l’écran  Mémoire,  réglez  la Taille  de  la  mémoire  vive  de  base  à  au  moins  128  Mo.  Cette  valeur  doit  être 
suffisante  pour  une  installation  sans  interface  graphique.  Si  vous  choisissez  d’installer  un  serveur  X,  il  faudra 
naturellement augmenter la mémoire en conséquence. 

■ Dans l’écran Disque dur virtuel, laissez les paramètres par défaut. 

■ Dans l’écran Type de conteneur disque dur, conservez le choix par défaut. 

■ Dans  l’écran  Disque  virtuel,  emplacement  et  taille,  conservez  le  choix  par  défaut.  La  taille  de  8  Go  affichée 
n’occupera pas réellement votre disque dur. 

■ Dans l’écran Récapitulatif, cliquez sur Terminer. 

c. Personnalisation de la machine virtuelle 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Stockage. 

■ Dans l’écran Supports/Arborescence Stockage, cliquez sur le cdrom (vide). 

■ Dans l’écran Supports/Attributs, déroulez le menu Lecteur optique et choisissez le cdrom virtuel Debian. Validez. 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Réseau. 

■ Dans la fenêtre Réseau, modifiez le Mode d’accès réseau en Accès par pont. Validez. 

d. Démarrage de la machine virtuelle et installation du système 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Cliquez sur le bouton Lancer pour démarrer la machine virtuelle. 

■ Cliquez sur l’écran de la machine virtuelle démarrée pour capturer la souris et le clavier. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


■ Dans l’Installer boot menu, choisissez Install. 

■ Dans l’écran Choose language, choisissez French. 

■ Dans l’écran suivant Choose language, conservez le choix France. 

■ Dans l’écran Choisir la disposition du clavier, conservez le choix Français. 

■ Dans l’écran Configurer le réseau, effacez le choix par défaut et tapez alpha. 

■ Dans l’écran suivant Configurer le réseau, choisissez Continuer sans renseigner le nom de domaine. 

■ Dans l’écran Partitionner les disques, choisissez Assisté ­ utiliser un disque entier. 

■ Dans l’écran suivant Partitionner les disques, choisissez le seul disque présenté. 

■ Dans  l’écran suivant  Partitionner  les  disques, choisissez  Tout  dans  une  seule  partition (recommandé pour les 
débutants). 

■ Dans  l’écran  suivant  Partitionner  les  disques,  choisissez  Terminer  le  partitionnement  et  appliquer  les 
changements. 

■ Dans l’écran suivant Partitionner les disques, validez la configuration du disque en sélectionnant Oui. 

■ Dans  l’écran  Créer  les  utilisateurs  et  choisir  les  mots  de  passe,  tapez  password  comme  Mot  de  passe  du 
superutilisateur. Confirmez le mot de passe. 

■ Dans  l’écran  Créer  les  utilisateurs  et  choisir  les  mots  de  passe,  tapez  toto  comme  Nom  complet  du  nouvel 
utilisateur. 

■ Dans l’écran Créer les utilisateurs et choisir les mots de passe, tapez toto comme Identifiant pour le compte 
utilisateur. 

■ Dans l’écran Créer les utilisateurs et choisir les mots de passe, tapez password comme Mot de passe pour le 
nouvel utilisateur. Confirmez le mot de passe. 

■ Dans  l’écran Configurer  l’outil  de  gestion  des  paquets,  choisissez  France  comme  Pays  du  miroir  de  l’archive 
Debian. 

■ Dans  l’écran  Configurer  l’outil  de  gestion  des  paquets,  choisissez  un  miroir  quelconque  comme  Miroir  de 
l’archive Debian. 

■ Dans l’écran Configurer l’outil de gestion des paquets, renseignez au besoin le Mandataire HTTP (vide dans la 
plupart des cas). 

■ Dans l’écran Configuration de popularity­contest, sélectionnez le choix Non pour refuser l’envoi de statistiques 
sur l’utilisation des paquets. 

■ Dans l’écran Sélection des logiciels, désélectionnez Environnement graphique de bureau et conservez Système 
standard. 

■ Dans l’écran Installer le programme de démarrage GRUB sur un disque dur, confirmez l’installation de GRUB sur 
le secteur d’amorçage. 

■ Dans l’écran Configuration de console­setup, sélectionnez Continuer pour valider la fin de l’installation. 

■ Après  l’installation,  retirez  le  cdrom  virtuel  en  le  désélectionnant  dans  le  menu  Périphériques/Périphériques 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


optiques de la machine virtuelle. 

4. Installation du serveur beta 

a. Éléments nécessaires 

● Logiciel VirtualBox installé. 

b. Création de la machine virtuelle 

■ Depuis l’interface VirtualBox, cliquez sur Nouveau pour lancer l’assistant de création de machine virtuelle. 

■ Dans l’écran  Nom  de  la  machine  virtuelle  et  type  de  système  d’exploitation,  tapez beta dans le champ Nom, 
sélectionnez Linux comme Système d’exploitation, et Red Hat comme Version. 

■ Dans l’écran Mémoire, réglez la Taille de la mémoire vive de base à 256 Mo. Si votre système hôte ne peut pas 
fournir  autant  de  mémoire,  vous  pouvez  diminuer  cette  valeur  et  choisir  ensuite  de  ne  pas  installer  d’interface 
graphique. 

■ Dans l’écran Disque dur virtuel, laissez les paramètres par défaut. 

■ Dans l’écran Type de conteneur disque dur, conservez le choix par défaut. 

■ Dans  l’écran  Disque  virtuel,  emplacement  et  taille,  conservez  le  choix  par  défaut.  La  taille  de  8 Go  affichée 
n’occupera pas réellement votre disque dur. 

■ Dans l’écran Récapitulatif, cliquez sur Terminer. 

c. Personnalisation de la machine virtuelle 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Stockage. 

■ Dans l’écran Supports/Arborescence Stockage, cliquez sur le cdrom (vide). 

■ Dans  l’écran  Supports/Attributs,  déroulez  le  menu  Lecteur  optique  et  choisissez  le  cdrom  virtuel  CentOS. 
Validez. 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Réseau. 

■ Dans la fenêtre Réseau, modifiez le Mode d’accès réseau en Accès par pont. Validez. 

d. Démarrage de la machine virtuelle et installation du système 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Cliquez sur le bouton Lancer pour démarrer la machine virtuelle. 

■ Cliquez sur l’écran de la machine virtuelle démarrée pour capturer la souris et le clavier. 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


■ Dans l’écran d’installation, tapez Entrée pour lancer l’installation. 

■ Dans l’écran CD found, sélectionnez Skip pour éviter la vérification du disque dur. 

■ Dans l’écran What language..., sélectionnez French. 

■ Dans  l’écran  Veuillez  sélectionner  le  clavier  de  votre  système,  sélectionnez  Français  (latin1)  ou  un  autre 
clavier adapté. 

■ Dans l’écran Avertissement, choisissez Oui pour valider l’initialisation de la table des partitions. 

■ Dans  l’écran  L’installation  requiert  le  partitionnement  de  votre  disque  dur...,  conservez  le  choix  par  défaut, 
sans importance sur un disque neuf. 

■ Dans l’écran Avertissement, choisissez Oui pour valider la suppression des partitions. 

■ Dans l’écran Périphériques réseau, cliquez sur Éditer pour modifier la configuration de la carte réseau. 

■ Dans l’écran Éditer l’interface, désélectionnez Activez le support IPv6. Pour la configuration IPv4, sélectionnez 
Configuration manuelle et indiquez une adresse IP de votre subnet connecté à internet. Dans tous les exercices, 
nous  utiliserons  l’adresse  192.168.200.102  que  vous  remplacerez  par  une  adresse  compatible  avec  votre 
espace d’adressage. 

■ Dans la section Nom d’hôte, indiquez le nom d’hôte manuellement. Le serveur s’appellera beta. 

■ Dans l’écran Paramètres Divers, indiquez votre passerelle locale et le serveur DNS de votre fournisseur d’accès. 

■ Dans l’écran de gestion du fuseau horaire, désélectionnez Horloge système en UTC et conservez la localisation 
Europe/Paris. 

■ Dans l’écran de gestion du  mot de passe root, indiquez password comme mot de passe. 

■ Dans  l’écran  de  gestion  des  paquets  logiciels,  cochez  la  sélection  Server  et  sélectionnez  Personnaliser 
maintenant. 

■ Dans  la  section  Développement,  cochez  les  sélections  Bibliothèques  de  développement,  Développement  de 
logiciel Gnome, Développement du logiciel X et Outils de développement. 

e. Personnalisation du système installé 

■ Après redémarrage du système, cliquez sur Avancer dans l’écran de bienvenue. 

■ Dans l’écran Pare­feu, sélectionnez Désactivé. Passez outre l’avertissement. 

■ Dans l’écran Selinux, sélectionnez Désactivé. Passez outre l’avertissement. 

■ Dans l’écran Date et heure, modifiez si nécessaire l’heure du système. 

■ Dans l’écran Créer un utilisateur, créez un compte utilisateur toto avec le mot de passe password. 

■ Dans l’écran Carte son, testez si vous le souhaitez la carte son du système virtuel. 

■ Terminez l’assistant et redémarrez le système. 

■ Après  l’installation,  retirez  le  cdrom  virtuel  en  le  désélectionnant  dans  le  menu  Périphériques/Périphériques 
optiques de la machine virtuelle. 

© ENI Editions - All rights reserved - Samuel CASAL - 5-


5. Installation de la station de travail 

a. Éléments nécessaires 

● Logiciel VirtualBox installé. 

b. Création de la machine virtuelle 

■ Depuis l’interface VirtualBox, cliquez sur Nouveau pour lancer l’assistant de création de machine virtuelle. 

■ Dans l’écran Nom de la machine virtuelle et type de système d’exploitation, tapez station dans le champ Nom, 
sélectionnez Linux comme Système d’exploitation, et Ubuntu comme Version. 

■ Dans l’écran Mémoire, réglez la Taille de la mémoire vive de base à 256 Mo. Si votre système hôte ne peut pas 
fournir autant de mémoire, vous pouvez diminuer cette valeur et choisir d’installer un système moins gourmand 
en ressources comme xubuntu. 

■ Dans l’écran Disque dur virtuel, laissez les paramètres par défaut. 

■ Dans l’écran Type de conteneur disque dur, conservez le choix par défaut. 

■ Dans  l’écran  Disque  virtuel,  emplacement  et  taille,  conservez  le  choix  par  défaut.  La  taille  de  8 Go  affichée 
n’occupera pas réellement votre disque dur. 

■ Dans l’écran Récapitulatif, cliquez sur Terminer. 

c. Personnalisation de la machine virtuelle 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Stockage. 

■ Dans l’écran Supports/Arborescence Stockage, cliquez sur le cdrom (vide). 

■ Dans  l’écran  Supports/Attributs,  déroulez  le  menu  Lecteur  optique  et  choisissez  le  cdrom  virtuel  Ubuntu. 
Validez. 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Réseau. 

■ Dans la fenêtre Réseau, modifiez le Mode d’accès réseau en Accès par pont. Validez. 

d. Démarrage de la machine virtuelle et installation du système 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Cliquez sur le bouton Lancer pour démarrer la machine virtuelle. 

■ Cliquez sur l’écran de la machine virtuelle démarrée pour capturer la souris et le clavier. 

■ Dans l’écran Install, sélectionnez Français dans le panneau de gauche et cliquez sur Installer Ubuntu. 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


■ Dans l’écran Emplacement géographique, vérifiez l’heure et le fuseau horaire. 

■ Dans l’écran Disposition du clavier, vérifiez le clavier proposé. 

■ Dans l’écran Préparation de l’espace disque, sélectionnez Tout effacer et utiliser le disque entier. 

■ Dans  l’écran Identité,  dites  que  vous  vous  appelez toto  et  que  votre  mot  de  passe  est  password.  Modifiez  le 
nom de l’ordinateur en station. 

■ Dans l’écran Prêt à installer, cliquez sur Installer pour démarrer l’installation. 

■ Après  l’installation,  retirez  le  cdrom  virtuel  en  le  désélectionnant  dans  le  menu  Périphériques/Périphériques 
optiques de la machine virtuelle. 

e. Configuration de l’adresse IP de la station 

■ Dans  la  station  de  travail  Ubuntu,  développez  le  menu  Système,  puis  Préférences,  et  choisissez  Connexions 
réseaux. 

■ Dans la fenêtre Connexions réseau, cliquez sur Ajouter. 

■ Dans la fenêtre Modification de la connexion filaire 1, renseignez le champ Nom de la connexion avec la valeur 
Fixe eth0. 

■ Dans l’onglet Paramètres IPv4, choisissez la Méthode : Manuel. Ajoutez une adresse et renseignez l’adresse IP 
avec une adresse de votre plan d’adressage. Utilisez votre passerelle par défaut, et utilisez le serveur DNS de 
votre fournisseur d’accès. Appliquez votre configuration. 

■ Au besoin, cliquez sur l’icône de gestion de réseau pour choisir la connexion Fixe eth0. 

Le compte root étant désactivé par défaut sur les systèmes Ubuntu, toutes les commandes nécessitant des 
prérogatives d’administrateur devront être précédées de la commande sudo. 

6. Ajout de périphérique supplémentaire à une machine existante 

Les  manipulations  suivantes  ne  sont  pas  à  réaliser  immédiatement.  Certains  exercices  nécessiteront  l’ajout  de 
matériel sur certaines machines virtuelles. 

a. Ajout de disque dur (sata) 

L’ajout  de  disque  dur  se  passe  en  deux  étapes :  la  création  de  disque  dans  le  gestionnaire  de  supports,  et 
l’affectation de ce disque à la machine virtuelle. 

b. Création d’un nouveau disque dur 

■ Depuis l’interface VirtualBox, déroulez le menu Fichier et chargez le Gestionnaire de supports virtuels. 

■ Dans le gestionnaire de supports virtuels, cliquez sur l’onglet Disques durs. 

■ Cliquez sur Nouveau. 

■ Dans l’écran Type de conteneur disque dur, conservez le choix par défaut. 

■ Dans  l’écran  Disque  virtuel,  emplacement  et  taille,  donnez  un  nom  facilement  identifiable  à  votre  fichier  de 

© ENI Editions - All rights reserved - Samuel CASAL - 7-


disque dur conservez la valeur de la taille par défaut. La taille de 2 Go affichée n’occupera pas réellement votre 
disque dur. 

■ Validez et terminez l’assistant. 

c. Affectation du disque dur à la machine virtuelle 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Stockage. 

■ Dans  l’écran  Supports/Arborescence  Stockage,  cliquez  sur  le  bouton  d’ajout  de  contrôleur.  Choisissez  un 
contrôleur de type SATA. 

■ Sous la section Contrôleur SATA, cliquez sur le bouton d’ajout de disque 

■ L’assistant prend le premier disque disponible dans le gestionnaire de supports virtuels, il faut donc sélectionner 
le disque ajouté, et dans le panneau Attributs, dérouler le menu Disque dur pour choisir le bon support. 

d. Ajout de carte réseau 

Chaque  machine  virtuelle  dispose  en  quelque  sorte  de  quatre  cartes  réseau  dont  seule  la  première  est  activée. 
Ajouter une carte revient donc à activer une carte déjà pré­installée. 

e. Activation de la carte réseau sur la machine virtuelle 

■ Dans l’interface VirtualBox, sélectionnez votre machine virtuelle dans le panneau de gauche. 

■ Dans le panneau de droite, cliquez sur le lien Réseau. 

■ Sélectionnez l’onglet Carte 2 et cochez Activer la carte réseau. 

■ Choisissez le mode d’accès réseau en fonction de vos besoins. 

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Avoir des notions de base sur les filesystems et les tables d’inodes.
Connaître le partitionnement ordinaire des disques de PC.  
Utilisation basique de l’utilitaire fdisk. 
Connaissance sommaire du stockage sur bande magnétique (/dev/st*, /dev/nst* et mt). 

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Connaître les différences principales des différents formats de filesytems.
Connaître les filesystems virtuels. 
Créer et vérifier un filesystem. 
Créer et gérer un espace de swap.  
Gérer le montage automatique de filesystems au démarrage. 
Configurer un automontage. 
Connaître le fonctionnement du service udev. 
Configurer un disque dur avec hdparm. 
Archiver des données. 
Copier ou synchroniser des données avec rsync.  
Connaître les principaux niveaux de RAID. 
Créer et gérer des disques en RAID logiciel. 
Créer et exploiter des volumes logiques. 
Étendre et réduire des volumes logiques.  
Réaliser un volume logique de snapshot. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


Gestion et configuration des systèmes de fichier 

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 fichier 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  fichier  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 filesystem. 

Il existe plusieurs types de filesystem, dont les plus courants en environnement Linux sont ext, reiserfs et xfs. Leur 
connaissance est nécessaire pour le passage de la certification LPI. 

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ème Linux des filesytem 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. Les filesystems à connaître pour la certification LPI sont proc et sys. 

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é. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


toto@serveur:~$ cat /proc/cpuinfo
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 filesystem 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. Valeurs à connaître : 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 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


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  filesystem 
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 filesystem 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). La plupart des questions de la certification LPI utilisent cette syntaxe courante. 

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 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


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

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. Leur connaissance détaillée n’est pas demandée pour la certification LPI. 

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 filesystem 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  ainsi  que  sa  présence  dans  les  examens  LPI  rendent  sa 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


connaissance nécessaire. 

Le label des filesystem

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 filesystem

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 

© ENI Editions - All rights reserved - Samuel CASAL - 5-


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

- 6- © ENI Editions - All rights reserved - Samuel CASAL


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

/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

© ENI Editions - All rights reserved - Samuel CASAL - 7-


3. Montage des filesystems 

a. Montage et démontage 

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. 

- 8- © ENI Editions - All rights reserved - Samuel CASAL


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 

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 filesystem 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

© ENI Editions - All rights reserved - Samuel CASAL - 9-


UUID=ee7890fb-c312-406f-b100-669c97ee8d07 none swap
sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8
0 0

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. La certification LPI prévoit la connaissance de l’automontage, 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 

- 10 - © ENI Editions - All rights reserved - Samuel CASAL


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) 

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. 

© ENI Editions - All rights reserved - Samuel CASAL - 11 -


■ 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. 

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

- 12 - © ENI Editions - All rights reserved - Samuel CASAL


[ 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
[ 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

© ENI Editions - All rights reserved - Samuel CASAL - 13 -


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:~$

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

- 14 - © ENI Editions - All rights reserved - Samuel CASAL


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
/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 - Samuel CASAL - 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  commende  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 - Samuel CASAL - 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 
restore à 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, nous savons depuis le niveau 1 LPI que 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. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


­v  Facultatif : rend la commande bavarde. 

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. 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Syntaxe générique de la commande dd 

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 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


­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. 

­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 

© ENI Editions - All rights reserved - Samuel CASAL - 5-


uid = utilisateur
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 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


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. 

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 - Samuel CASAL - 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 filesystem. 

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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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

L’extension  d’un  Volume  Group  se  fait  à  partir  de  Physical  Volume(s)  avec  la  commande  pvextend.  Les  Physical 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


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 
maitrisé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 - Samuel CASAL - 5-


vgreduce vg pv

vgreduce : options et paramètres 

vg  Le groupe de volume à réduire. 

pv  Le (ou les) volumes physiques à 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 - Samuel CASAL


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
Read ahead sectors auto

© ENI Editions - All rights reserved - Samuel CASAL - 7-


- 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 - Samuel CASAL


Validation des acquis : questions/réponses 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Pourquoi est­il nécessaire de créer un filesystem pour exploiter un espace de stockage sur disque ? 
2 Combien d’espace disque les filesystems virtuels ou pseudo­filesystems peuvent­ils occuper ? 

3 Les UUID servent à identifier formellement un système de fichiers. Qui garantit leur unicité ? 

4 Comment est optimisée l’écriture de données sur un système disque lent ? 
5 Pourquoi est­il difficile de vérifier la cohérence du filesystem racine monté sur / ? 

6 En quoi la commande lsdev est­elle dépendante de pseudo­filesystems ? 
7 Pourquoi les options de compression de la commande tar devraient­elles être réservées aux sauvegardes sur 
disque ? 
8 La copie d’un cdrom par la commande dd pour la réalisation d’une image iso nécessite­t­elle que le cdrom soit 
monté ? 
9 Combien de disques durs sont nécessaires pour réaliser un RAID 5 ? 
10 Quelle est la différence entre une partition et un volume logique LVM ? 

2. Réponses 

1 Pourquoi est­il nécessaire de créer un filesystem pour exploiter un espace de stockage sur disque ? 
Parce que c’est le filesystem qui permet d’organiser l’espace de stockage. Sans lui, une partition ou un volume logique 
n’est qu’une  suite  d’octets sans aucun sens. Le filesystem gère les noms de fichiers et l’emplacement physique des 
espaces  de  stockage.  Une  bande  magnétique  est  un  exemple  d’espace  de  stockage  sans  filesystem  :  les  données  y 
sont forcément contiguës, et il n’est pas possible de modifier un fichier. Il faut l’effacer et le réécrire. 

2 Combien d’espace disque les filesystems virtuels ou pseudo­filesystems peuvent­ils occuper ? 
Aucun. Comme leur nom l’indique, les filesystems virtuels n’ont pas d’existence physique. Ils demeurent en mémoire, 
et sont montés sur un répertoire du système de fichiers réel. 
3 Les UUID servent à identifier formellement un système de fichiers. Qui garantit leur unicité ? 
Le  hasard.  L’UUID  est,  sur  des  systèmes  de  plus  en  plus  nombreux,  la  façon  naturelle  de  désigner  un  système  de 
fichiers.  Même  si  les  UUID  peuvent  être  affectés  ou  modifiés  à  l’initiative  de  l’administrateur,  ils  sont  en  général 
renseignés automatiquement à la création de systèmes de fichiers et le hasard sur 128 bits est le seul garant de leur 
unicité. 

4 Comment est optimisée l’écriture de données sur un système disque lent ? 
Par une écriture asynchrone : les données écrites sur le disque sont d’abord enregistrées en mémoire, puis plus tard 
écrites  physiquement  sur  le  disque.  Ce  mode  de  fonctionnement,  utilisé  par  défaut  dans  le  cadre  d’un  montage 
ordinaire ne va pas sans risque. Les données sont considérées comme enregistrées de façon sûre par les applications, 
et donc par l’utilisateur. En cas de panne de courant, les données en instance d’écriture contenues en mémoire sont 
perdues. 

5 Pourquoi est­il difficile de vérifier la cohérence du filesystem racine monté sur / ? 
Parce  que  les  commandes  de  vérification  s’exécutent  sur  des  filesystems  démontés.  Le  filesystem  racine  contient 
nombre  d’exécutables  en  cours  de  fonctionnement  sur  un  système  actif,  et  souvent  les  commandes  de  vérification 
elles­mêmes.  Il  est  donc  impossible  de  le  démonter  puisque  les  programmes  en  cours  d’exécution  interdisent  cette 
opération. La solution est donc de forcer la vérification au redémarrage, avant que le filesystem ne soit monté. Soit en 
modifiant  les  compteurs  de  vérification  périodique  avec  la  commande  e2fsck,  soit  en  forçant  la  vérification  depuis  la 
commande shutdown avec l’option ­F. 
6 En quoi la commande lsdev est­elle dépendante de pseudo­filesystems ? 
Parce que la commande lsdev comme beaucoup d’autres trouve les informations dont elle a besoin dans des fichiers de 
pseudo filesystems (/proc/interrupts, /proc/ioports, et /proc/dma). Ceci illustre à quel point les pseudo­filesystems sont 
riches en informations utiles. 

7 Pourquoi les options de compression de la commande tar devraient­elles être réservées aux sauvegardes sur 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


disque ? 
Parce  que  la  compression  des  données  les  rend  plus  difficiles  à  exploiter  en  cas  de  perte  partielle.  Or,  les  bandes 
magnétiques historiquement utilisées avec la commande tar présentaient souvent des zones faiblement magnétisées 
qui les exposaient à des pertes partielles. Dans ces circonstances, l’absence de compression limitait la perte aux seuls 
fichiers touchés par la zone faible. 

8 La copie d’un cdrom par la commande dd pour la réalisation d’une image iso nécessite­t­elle que le cdrom soit 
monté ? 
Non.  Le  filesystem  doit  être  monté  s’il  faut  copier  des  fichiers  déterminés.  Or,  la  commande  dd  copie  des  blocs  de 
données sans comprendre leur contenu. Elle manipule directement le matériel et non des fichiers. En conséquence, il 
n’est pas nécessaire que le cdrom soit monté pour en réaliser une image. 

9 Combien de disques durs sont nécessaires pour réaliser un RAID 5 ? 
Au moins trois. Deux pour les données et un troisième pour la parité. Si un disque de rechange (spare) est inclus dans 
la  configuration,  ce  nombre  passe  à  quatre  :  deux  disques  de  données,  un  disque  de  parité,  et  un  disque  prêt  à 
remplacer un autre disque défaillant. 

10 Quelle est la différence entre une partition et un volume logique LVM ? 
Cela dépend. D’un point de vue fonctionnel aucun : les deux se verront affecter un filesystem et seront montés sur un 
répertoire.  Toutefois,  seul  le  volume  logique  pourra  être  agrandi  en  cas  de  besoin  (par  la  commande  lvextend).  Cet 
agrandissement  ne  modifiera  néanmoins  pas  le  filesystem  qui  devra  être  réorganisé  par  une  commande  de 
redimensionnement de filesystem (resize2fs). 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 

1. Exploitation d’un espace de swap sur fichier 

On prévoit l’installation sur la machine alpha d’une application de gestion de documentation extrêmement gourmande 
en  mémoire  vive.  Le  budget  permettant  l’achat  de  mémoire  supplémentaire  pour  le  fonctionnement  confortable  de 
cette  application  ne  sera  pas  débloqué  avant  quelques  mois.  On  vous  demande  en  conséquence  de  faire  en  sorte 
que le serveur puisse supporter la charge sans plantage, même si les performances doivent s’en trouver dégradées. 
Vous décidez donc de créer un espace de swap supplémentaire. 

a. Création d’un fichier de swap 

Commandes utiles

● cat 

● chmod 

● dd 

● file 

● mkswap 

● swapon 

Manipulations

1.  Affichez le swap exploité. 

2.  Créez à la racine du système un fichier de 512 Mo avec la commande dd (si votre 


système hôte manque de disque, choisissez une valeur plus faible). 

3.  Empêchez les regards indiscrets de consulter le contenu de ce fichier. 

4.  Structurez le fichier pour qu’il soit exploitable en espace de swap par le noyau. 

5.  Vérifiez avec la commande file que l’opération s’est bien passée. 

Résumé des commandes et résultat à l’écran

Affichage du swap courant : 

alpha:~# cat /proc/swaps


Filename Type Size Used Priority
/dev/hda5 partition 369452 0 -1
alpha:~# swapon -s
Filename Type Size Used Priority
/dev/hda5 partition 369452 0 -1
alpha:~#

Création d’un fichier de 512 Mo à la racine : 

alpha:~# dd if=/dev/zero of=/swap bs=1024 count=524288


524288+0 enregistrements lus
524288+0 enregistrements écrits
536970912 bytes (537 MB) copied, 8,31308 s, 63,1 MB/s
alpha:~#
alpha:~# file /swap
/swap: data

© ENI Editions - All rights reserved - Samuel CASAL - 1-


alpha:~# ls -lh /swap
-rw-r--r-- 1 root root 512M aoû 31 22:26 /swap
alpha:~#

Gestion des droits sur le fichier : 

alpha:~# chmod 600 /swap


alpha:~# ls -lh /swap
-rw------- 1 root root 512M aoû 31 22:26 /swap
alpha:~#

Structuration du fichier : 

alpha:~# mkswap /swap


Setting up swapspace version 1, size = 536866 kB
no label, UUID=61bbc852-9a4c-4911-9c79-323beddc6389
alpha:~#

Vérification : 

alpha:~# file /swap


/swap: Linux/i386 swap file (new style), version 1 (4K pages),
size 131071 pages, no label, UUID=61bbc852-9a4c-4911-9c79-323beddc6389
alpha:~#

b. Activation de l’espace de swap 

Commandes utiles

● cat 

● swapon 

Manipulations

1.  Faites savoir au noyau qu’il doit exploiter ce nouvel espace de swap. 

2.  Vérifiez que le noyau a bien pris en compte le nouvel espace. 

Résumé des commandes et résultat à l’écran

Activation de l’espace de swap : 

alpha:~# swapon /swap


alpha:~#

Vérification par deux commandes différentes : 

alpha:~# swapon -s
Filename Type Size Used Priority
/dev/hda5 partition 369452 588 -1
/swap file 524280 0 -2
alpha:~# cat /proc/swaps
Filename Type Size Used Priority
/dev/hda5 partition 369452 588 -1
/swap file 524280 0 -2
alpha:~#

c. Référencement dans fstab 

Commandes utiles

- 2- © ENI Editions - All rights reserved - Samuel CASAL


● cat 

● reboot 

● shutdown 

● swapon 

● vi 

Manipulations

1.  Ajoutez dans le fichier fstab une ligne référençant le nouvel espace de swap. 

2.  Redémarrez le système. 

3.  Vérifiez la prise en compte du nouvel espace. 

Résumé des commandes et résultat à l’écran

Fichier /etc/fstab modifié : 

# /etc/fstab: static file system information.


#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 errors=remount-ro 0 1
/dev/hda5 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

# Ajout du nouvel espace de swap

/swap none swap sw 0 0

Vérification après redémarrage : 

alpha:~# cat /proc/swaps


Filename Type Size Used Priority
/dev/hda5 partition 369452 0 -1
/swap file 524280 0 -2
alpha:~#

2. Configuration d’un disque en RAID 0 

Non contente d’utiliser beaucoup de mémoire, l’application prévue nécessite un espace de stockage performant sans 
obligation de fiabilité. Vous envisagez alors de créer un volume logique en RAID 0. 

Ajoutez  deux  disques  durs  virtuels  SATA  de  2  Go  à  la  machine  alpha  selon  la  procédure  vue  en  introduction.  Ces 
disques devraient être vus par le système en tant que /dev/sda et /dev/sdb. 

a. Installation de la gestion RAID 

Sur le serveur alpha, installez les outils de gestion RAID en tapant la commande suivante : 

apt-get install mdadm

Si l’assistant vous propose des options de personnalisation, acceptez tous les choix par défaut. 

b. Inventaire des disques installés 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Commandes utiles

● dmesg 

● ls 

Manipulations

1.  Dans le répertoire /dev, listez tous les éléments commençant par hd ou sd. 

2.  Consultez le « ring buffer » du noyau pour vérifier que les disques ont bien été 
reconnus au démarrage du noyau. 

3.  Identifiez le disque système (celui qui doit être partitionné) et les deux disques ajoutés. 

4.  Constatez la présence dans le répertoire /dev de deux fichiers spéciaux en mode bloc 
sda et sdb. 

Résumé des commandes et résultat à l’écran

Affichage des fichiers spéciaux de /dev commançant par hd ou sd : 

alpha:~# cd /dev
alpha:/dev# ls [hs]d*
hda hda1 hda2 hda5 hdc sda sdb
alpha:/dev#

c. Création du disque RAID 

Commandes utiles

● cat 

● ls 

● mdadm 

Manipulations

1.  Créez un disque RAID 0 sous le nom md0. 

2.  Vérifiez la présence du disque RAID créé par deux moyens différents. 

Résumé des commandes et résultat à l’écran

Création du disque RAID 0 : 

alpha:/dev# mdadm -C /dev/md0 -l 0 -n 2 /dev/sda /dev/sdb


mdadm: array /dev/md0 started.
alpha:/dev#

Vérification de la présence du disque RAID 0 par trois moyens différents : 

alpha:/dev# ls /dev/md0
/dev/md0
alpha:/dev# cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 sdb[1] sda[0]
4194176 blocks 64k chunks

unused devices: <none>


alpha:/dev# mdadm -D /dev/md0
/dev/md0:

- 4- © ENI Editions - All rights reserved - Samuel CASAL


Version : 00.90
Creation Time : Wed Sep 1 13:31:52 2010
Raid Level : raid0
Array Size : 4194176 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Wed Sep 1 13:31:52 2010


State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Chunk Size : 64K

UUID : 678f9e3e:f92b3780:1b3376be:99c3df95 (local to host alpha)


Events : 0.1

Number Major Minor RaidDevice State


0 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
alpha:/dev#

3. Création et exploitation d’un volume logique sur le disque RAID 0 

Le  disque  en  RAID  0  étant  créé,  vous  souhaitez  l’exploiter  comme  support  d’un  volume  logique.  Cette  solution  est 
celle qui offrira le plus de souplesse quant aux évolutions futures du stockage. 

a. Installation des outils de gestion des LVM 

Sur le serveur alpha, installez les outils de gestion LVM en tapant la commande suivante : 

alpha:/dev# apt-get install lvm2


Lecture des listes de paquets... Fait
Construction de l’arbre des dépendances
Lecture des informations d’état... Fait
Les paquets supplémentaires suivants seront installés :
dmsetup
Les NOUVEAUX paquets suivants seront installés :
dmsetup lvm2
0 mis à jour, 2 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 393ko dans les archives.
Après cette opération, 1073ko d’espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?
Réception de : 1 http://security.debian.org lenny/updates/main lvm2 2.02.39-8 [355kB]
(...)

b. Création du volume logique 

Commandes utiles

● lvcreate 

● lvdisplay 

● pvcreate 

● pvdisplay 

© ENI Editions - All rights reserved - Samuel CASAL - 5-


● vgcreate 

● vgdisplay 

Manipulations

1.  Créez un PV à partir de votre disque RAID 0. 

2.  Vérifiez. 

3.  Créez un VG appelé volgrp alimenté par votre PV. 

4.  Vérifiez. 

5.  Créez un LV de 1 Go appelé documentation à partir de votre VG. 

6.  Vérifiez 

Résumé des commandes et résultat à l’écran

Création du Physical Volume à partir du disque RAID 0 : 

alpha:/dev# pvcreate /dev/md0


Physical volume "/dev/md0" successfully created
alpha:/dev#

Vérification : 

alpha:/dev# pvdisplay
"/dev/md0" is a new physical volume of "4,00 GB"
--- NEW Physical volume ---
PV Name /dev/md0
VG Name
PV Size 4,00 GB
Allocatable NO
PE Size (KByte) 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID mBhGL1-i7oD-tc1k-7VX3-CQ1r-Q0AT-jAEgtj

alpha:/dev#

Création du Volume Group alimenté par votre Physical Volume : 

alpha:/dev# vgcreate volgrp /dev/md0


Volume group "volgrp" successfully created
alpha:/dev#

Vérification : 

alpha:/dev# vgdisplay
--- Volume group ---
VG Name volgrp
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 4,00 GB

- 6- © ENI Editions - All rights reserved - Samuel CASAL


PE Size 4,00 MB
Total PE 1023
Alloc PE / Size 0 / 0
Free PE / Size 1023 / 4,00 GB
VG UUID Dw1Qm8-BHeq-jNXN-uXVK-eaMF-gzA1-B7QwX8

alpha:/dev#

Création du Logical Volume de documentation : 

alpha:/dev# lvcreate -n documentation -L 1G volgrp


Logical volume "documentation" created
alpha:/dev#

Vérification : 

alpha:/dev# lvdisplay
--- Logical volume ---
LV Name /dev/volgrp/documentation
VG Name volgrp
LV UUID xIYS6m-mq88-13br-wbp7-sp5B-iN2b-wA1GEk
LV Write Access read/write
LV Status available
# open 0
LV Size 1,00 GB
Current LE 256
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

alpha:/dev#

c. Création de filesystem 

Commandes utiles

● mke2fs 

● tune2fs 

Manipulations

1.  Créez un filesystem de type ext2 sur votre volume logique. 

2.  Finalement, non modifiez­le plutôt en un filesystem ext3. 

3.  Affectez­lui le label « documentation ». 

4.  Vérifiez. 

Résumé des commandes et résultat à l’écran

Création du filesystem ext2 : 

alpha:/dev# mke2fs /dev/volgrp/documentation


mke2fs 1.41.3 (12-Oct-2008)
Étiquette de système de fichiers=
Type de système d’exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
65536 i-noeuds, 262144 blocs
13107 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0

© ENI Editions - All rights reserved - Samuel CASAL - 7-


Nombre maximum de blocs du système de fichiers=268435456
8 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376

Écriture des tables d’i-noeuds : 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 29 montages ou


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

Finalement, ext3 : 

alpha:/dev# tune2fs -j /dev/volgrp/documentation


tune2fs 1.41.3 (12-Oct-2008)
Création de l’i-noeud du journal : complété
Le système de fichiers sera automatiquement vérifié tous les 29 montages ou
après 180 jours, selon la première éventualité. Utiliser tune2fs -c ou -i
pour écraser la valeur.
alpha:/dev#

Affectation d’un label documentation : 

alpha:/dev# tune2fs -L "documentation" /dev/volgrp/documentation


tune2fs 1.41.3 (12-Oct-2008)
alpha:/dev#

Vérification : 

alpha:/dev# tune2fs -l /dev/volgrp/documentation | grep name


Filesystem volume name: documentation
alpha:/dev#

d. Montage du filesystem 

Commandes utiles

● cat 

● mkdir 

● mount 

● umount 

Manipulations

1.  Montez votre filesystem en lecture seule sous un répertoire /documentation. 

2.  Vérifiez. 

3.  Démontez­le. 

4.  Ajoutez une ligne au fichier fstab afin que votre filesystem soit monté automatiquement 
au démarrage. 

5.  Vérifiez la validité de votre syntaxe sans redémarrer le système. 

Résumé des commandes et résultat à l’écran

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Création du point de montage et montage du filesystem : 

alpha:/dev# mkdir /documentation


alpha:/dev# mount -o ro /dev/volgrp/documentation /documentation
alpha:/dev#

Vérification selon trois méthodes différentes : 

alpha:/dev# mount
/dev/hda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/mapper/volgrp-documentation on /documentation type ext3 (ro)
alpha:/dev#
alpha:/dev# cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/hda1 / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
/dev/mapper/volgrp-documentation /documentation ext3 ro,errors=continue,data=ordered 0 0
alpha:/dev#
alpha:/dev# cat /etc/mtab
/dev/hda1 / ext3 rw,errors=remount-ro 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/mapper/volgrp-documentation /documentation ext3 ro 0 0
alpha:/dev#

Démontage du filesystem : 

alpha:/dev# umount /documentation


alpha:/dev#

Fichier /etc/fstab modifié : 

# /etc/fstab: static file system information.


#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/hda1 / ext3 errors=remount-ro 0 1
/dev/hda5 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

# Ajout du nouvel espace de swap

/swap none swap sw 0 0

# Montage du volume de documentation

/dev/volgrp/documentation /documentation ext3 ro 0 0

Vérification : 

alpha:/dev# mount -a

© ENI Editions - All rights reserved - Samuel CASAL - 9-


alpha:/dev# cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/hda1 / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
/dev/mapper/volgrp-documentation /documentation ext3
ro,errors=continue,data=ordered 0 0
alpha:/dev#

4. Extension du volume logique 

À peine le volume créé, on vous annonce que l’espace de stockage prévu (1 Go) a été sous­dimensionné. Il faudrait 
plutôt disposer de 3 Go. Vous vous félicitez d’avoir préféré les volumes logiques aux partitions traditionnelles. 

a. Agrandissement du LV 

Commandes utiles

● df 

● lvdisplay 

● lvextend 

Manipulations

1.  Vérifiez la taille du volume logique. 

2.  Vérifiez la taille du filesystem monté. 

3.  Passez la taille du volume logique documentation à 3 Go. 

4.  Vérifiez la taille du volume logique. 

5.  Vérifiez la taille du filesystem monté. 

Résumé des commandes et résultat à l’écran

Vérification de la taille du volume logique : 

alpha:/dev# lvdisplay /dev/volgrp/documentation


--- Logical volume ---
LV Name /dev/volgrp/documentation
VG Name volgrp
LV UUID xIYS6m-mq88-13br-wbp7-sp5B-iN2b-wA1GEk
LV Write Access read/write
LV Status available
# open 1
LV Size 1,00 GB
Current LE 256
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

Vérification de la taille du filesystem monté : 

alpha:/dev# df -h

- 10 - © ENI Editions - All rights reserved - Samuel CASAL


Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda1 7,6G 1,3G 6,0G 17% /
tmpfs 62M 0 62M 0% /lib/init/rw
udev 10M 616K 9,4M 7% /dev
tmpfs 62M 0 62M 0% /dev/shm
/dev/mapper/volgrp-documentation
1008M 34M 924M 4% /documentation
alpha:/dev#

Augmentation de la taille du volume logique à 3 Go : 

alpha:/dev# lvextend -L 3G /dev/volgrp/documentation


Extending logical volume documentation to 3,00 GB
Logical volume documentation successfully resized
alpha:/dev#

Vérification de la taille du volume logique : 

alpha:/dev# lvdisplay
--- Logical volume ---
LV Name /dev/volgrp/documentation
VG Name volgrp
LV UUID xIYS6m-mq88-13br-wbp7-sp5B-iN2b-wA1GEk
LV Write Access read/write
LV Status available
# open 1
LV Size 3,00 GB
Current LE 768
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

alpha:/dev#

Vérification de la taille du filesystem monté : 

alpha:/dev# umount /documentation


alpha:/dev# mount /documentation
alpha:/dev#
alpha:/dev# df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda1 7,6G 1,3G 6,0G 17% /
tmpfs 62M 0 62M 0% /lib/init/rw
udev 10M 616K 9,4M 7% /dev
tmpfs 62M 0 62M 0% /dev/shm
/dev/mapper/volgrp-documentation
1008M 34M 924M 4% /documentation
alpha:/dev#

Le volume logique est passé à trois Go, mais le filesystem monté, prisonnier de sa structure reste figé à sa taille 
d’origine. 

b. Agrandissement du filesystem 

Commandes utiles

● e2fsck 

● mount 

● resize2fs 

● umount 

© ENI Editions - All rights reserved - Samuel CASAL - 11 -


Manipulations

1.  Démontez le filesystem. 

2.  Vérifiez son intégrité. 

3.  Redimensionnez­le avec la commande resize2fs. 

4.  Montez­le et vérifiez la nouvelle taille. 

Résumé des commandes et résultat à l’écran

Démontage du filesystem et vérification de son intégrité : 

alpha:/dev# umount /documentation


alpha:/dev# e2fsck /dev/volgrp/documentation
e2fsck 1.41.3 (12-Oct-2008)
documentation : propre, 11/65536 fichiers, 12644/262144 blocs
alpha:/dev#

Redimensionnement du filesystem : 

alpha:/dev# resize2fs /dev/volgrp/documentation


resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/volgrp/documentation to 786432 (4k) blocks.
Le système de fichiers /dev/volgrp/documentation a maintenant une taille de 786432 blocs.

alpha:/dev#

Montage du fil et vérification de sa taille : 

alpha:/dev# mount /documentation


alpha:/dev# df -h | grep docu
/dev/mapper/volgrp-documentation
3,0G 34M 2,8G 2% /documentation
alpha:/dev#

- 12 - © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Affichage des processus et de leurs identifiants.
Édition de fichiers. 

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Comprendre le processus de démarrage d’un système Linux.
Comprendre l’usage des niveaux d’exécution. 
Gérer le lancement de services en fonction du niveau d’exécution. 
Connaître l’existence et le rôle du script rc.local. 
Changer de niveau d’exécution sur un système démarré. 
Modifier un fichier de configuration de GRUB. 
Ajouter interactivement une option ponctuelle au noyau au démarrage. 
Réinstaller GRUB sur un système défaillant. 
Passer en mode single par plusieurs moyens.  

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL - 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 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 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


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é. 

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

© ENI Editions - All rights reserved - Samuel CASAL - 3-


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. 

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

- 4- © ENI Editions - All rights reserved - Samuel CASAL


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 - Samuel CASAL - 5-


Validation des acquis : questions/réponses 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Quelle est la différence entre un service, un démon et un niveau d’exécution ? 
2 Les scripts de gestion de services admettent souvent les paramètres restart et reload. Lequel de ces deux 
paramètres consomme le moins de ressources système lors de son appel ? 

3 Quel script indépendant des niveaux d’exécution est toujours exécuté au démarrage d’un système après tous 
les scripts liés au niveau d’exécution courant ? 

4 Quel est le résultat à l’écran de la commande dmesg ? 
5 Pour la configuration du gestionnaire de démarrage GRUB, les distributions d’inspiration Debian privilégient le 
fichier /boot/grub/menu.lst alors que les systèmes d’origine Red Hat préfèrent le fichier /etc/grub.conf. Comment 
la cohérence est­elle maintenue pour que le gestionnaire de démarrage GRUB retrouve toujours sa 
configuration dans le même fichier ? 
6 Quel est l’emplacement usuel pour positionner un gestionnaire de démarrage ? 
7 Quel est l’intérêt du paramètre ro (read only) généralement passé au noyau par le gestionnaire de boot qui 
indique que le chargement du noyau doit se faire en lecture seule ? 
8 Quel paramètre passé au noyau lors de son démarrage permet d’accéder au système de façon rudimentaire 
dans un équivalent du mode single ? 
9 La commande telinit permet de changer de niveau d’exécution sur un système en fonctionnement. Que faut­il 
faire pour qu’un niveau d’exécution donné soit chargé directement au démarrage ? 
10 Pourquoi la copie de l’intégralité des fichiers d’un disque système sur le disque d’une autre machine ne suffit­
elle pas à la rendre fonctionnelle ? 

2. Réponses 

1 Quelle est la différence entre un service, un démon et un niveau d’exécution ? 
Un démon est un terme tiré de l’anglais daemon qui représente un service. Un service est un programme résident qui 
s’exécute sur un serveur, prêt à gérer des événements sur le système. Un niveau d’exécution est un état fonctionnel 
d’un  serveur  dans  lequel  plus  ou  moins  de  services  doivent  être  en  cours  d’exécution  ou  arrêtés.  Un  démon  et  un 
service  représentent  donc  la  même  chose,  et  un  niveau  d’exécution  décrit  l’état  dans  lequel  doivent  se  trouver  les 
services disponibles sur le système. 
2 Les scripts de gestion de services admettent souvent les paramètres restart et reload. Lequel de ces deux 
paramètres consomme le moins de ressources système lors de son appel ? 
Le paramètre restart appliqué à un script de gestion de service exécute l’équivalent d’un stop puis d’un start. Le ou les 
processus sont donc arrêtés, puis relancés en relisant les éléments de configuration. Le paramètre reload en revanche 
maintient les processus en cours d’exécution, mais leur fait reprendre en compte dynamiquement leur configuration, 
généralement en envoyant au processus un signal 1 (hup). 

3 Quel script indépendant des niveaux d’exécution est toujours exécuté au démarrage d’un système après tous 
les scripts liés au niveau d’exécution courant ? 
Le  script  rc.local  est  systématiquement  exécuté  au  démarrage,  après  tous  les  scripts  liés  au  niveau  d’exécution 
courant. L’administrateur peut y intégrer toute commande qui doit être exécutée au démarrage indépendamment du 
niveau d’exécution. 
4 Quel est le résultat à l’écran de la commande dmesg ? 
La commande dmesg affiche tous les messages que le noyau aurait pu afficher depuis son démarrage s’il avait disposé 
d’un  terminal  actif  ou  d’un  fichier  journal  sur  un  filesystem  monté.  En  l’absence  de  ces  éléments  (au  démarrage,  le 
noyau  n’a  rien  de  tout  cela),  le  noyau  maintient  en  mémoire  son  journal  d’événements  dans  ce  qu’on  appelle  en 
anglais le "kernel ring buffer". La commande dmesg envoie son contenu sur la sortie standard. 

5 Pour la configuration du gestionnaire de démarrage GRUB, les distributions d’inspiration Debian privilégient le 
fichier /boot/grub/menu.lst alors que les systèmes d’origine Red Hat préfèrent le fichier /etc/grub.conf. Comment 
la cohérence est­elle maintenue pour que le gestionnaire de démarrage GRUB retrouve toujours sa 
configuration dans le même fichier ? 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


Par  un  lien  symbolique.  L’histoire  d’unix  et  de  Linux  est  pleine  de  particularités  liées  à  une  distribution  ou  un 
développeur alternatifs. Pour rester en conformité avec les usages, le passé ou les règles posix, l’usage des liens est 
généralisé.  Les  liens  symboliques  sont  préférés  car  un  lien  matériel  n’est  pas  capable  de  référencer  un  élément  en 
dehors de son filesystem, et il n’est pas certain que les fichiers préférés et les fichiers normalisés soient sur le même 
filesystem. 

6 Quel est l’emplacement usuel pour positionner un gestionnaire de démarrage ? 
Le Master Boot Record (MBR). Un emplacement du disque dur situé avant la table des partitions et lu en premier par le 
BIOS est l’emplacement privilégié pour un gestionnaire de démarrage. 
7 Quel est l’intérêt du paramètre ro (read only) généralement passé au noyau par le gestionnaire de boot qui 
indique que le chargement du noyau doit se faire en lecture seule ? 
En cas de problème sur la partition qui contient le noyau, les outils de diagnostics peuvent s’exécuter sans dommage 
sur des éléments accédés en lecture seule. 

8 Quel paramètre passé au noyau lors de son démarrage permet d’accéder au système de façon rudimentaire 
dans un équivalent du mode single ? 
Le paramètre init= permet de spécifier quel exécutable doit être lancé directement après le chargement du noyau. Si 
cet  exécutable  est  un  shell,  alors  le  système  démarre  et  exécute  un  shell  indépendamment  de  tout  service.  C’est 
également une façon d’accéder à un système dont on a perdu le mot de passe. 
9 La commande telinit permet de changer de niveau d’exécution sur un système en fonctionnement. Que faut­il 
faire pour qu’un niveau d’exécution donné soit chargé directement au démarrage ? 
Modifier le fichier inittab. Il contient une ligne de définition du niveau d’exécution par défaut annoncée par le mot­clé 
initdefault. 
10 Pourquoi la copie de l’intégralité des fichiers d’un disque système sur le disque d’une autre machine ne suffit­
elle pas à la rendre fonctionnelle ? 
Parce que le noyau Linux doit être appelé par un gestionnaire de démarrage, lequel se trouve en dehors des partitions 
de disque, et n’est donc pas copiable par les outils de gestion de fichiers ordinaires. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 

1. Création d’un niveau d’exécution sur mesure avec applications spécifiques 

Il n’est pas (plus) d’usage en production de gérer des niveaux d’exécution personnalisés. Cette opération constitue 
néanmoins un très bon exercice pour la compréhension des niveaux d’exécution. 

a. Définition des besoins fonctionnels 

Des  besoins  applicatifs  particuliers  apparaissent.  Vous  pensez  que  la  gestion  des  de  ces  services  par  niveaux 
d’exécution est la meilleure réponse à ces besoins. 
Votre serveur A doit être fonctionnel avec ses services usuels démarrés dans son niveau d’exécution par défaut, et 
disposer des mêmes services avec en plus le démarrage d’une application spécifique dans un niveau personnalisé. 
Afin de pouvoir surveiller l’application nouvelle quand elle sera installée, vous envisagez de créer une application de 
surveillance de la mémoire. 

Comme le niveau par défaut des serveurs Debian est le niveau 2, vous le conserverez comme niveau par défaut, et 
vous personnaliserez le niveau 3 afin que l’application spéciale (et en attendant votre application de surveillance) y 
soit systématiquement démarrée. 

b. Création de l’application spécifique 

Vous souhaitez disposer dans un niveau d’exécution donné d’enregistrements périodiques de la consommation de 
mémoire  sur  le  serveur.  Vous  créerez  le  programme  provoquant  l’enregistrement  périodique  des  données  en 
mémoire, ainsi que son script de lancement normalisé. Créez dans le répertoire /opt/scripts avec l’éditeur de votre 
choix le fichier surveillemem suivant : 

#!/bin/bash
while true
do
maintenant=$(date "+%H:%M:%S - ")
echo -n $maintenant >> /var/log/surveillemem.log
grep Dirty /proc/meminfo >> /var/log/surveillemem.log
sleep 30
done

Commandes utiles

● chmod 

● tail 

● vi 

Manipulations

1.  Rendez ce fichier exécutable. 

2.  Créez dans le répertoire /etc/init.d un script normalisé de lancement de service pour 
l’application surveillemem. 

3.  Rendez ce fichier exécutable. 

4.  Testez le bon fonctionnement du programme en lançant le service correspondant. 

5.  Laissez tourner quelques minutes. 

6.  Vérifiez le contenu du fichier /var/log/surveillemem.log. 

Résumé des commandes et résultat à l’écran

© ENI Editions - All rights reserved - Samuel CASAL - 1-


Fichier surveillemem : 

#!/bin/bash
while true
do
maintenant=$(date "+%H:%M:%S - ")
echo -n $maintenant >> /var/log/surveillemem.log
grep Dirty /proc/meminfo >> /var/log/surveillemem.log
sleep 30
done

Modification des droits sur le fichier surveillemem : 

alpha # ls -l /opt/scripts
-rw-r--r-- 1 root root 187 2010-07-13 15:31 surveillemem
alpha # chmod a+x /opt/scripts/surveillemem
alpha # ls -l /opt/scripts
-rwxr-xr-x 1 root root 187 2010-07-13 15:33 surveillemem

Script /etc/init.d/surveillemem de lancement de service pour gérer l’application surveillemem : 

#!/bin/bash
case $1 in
start)
/opt/scripts/surveillemem &
;;
stop)
pkill surveillemem
;;
esac

Modification des droits sur le fichier de gestion de service : 

alpha # ls -l /etc/init.d/surveillemem
-rw-r--r-- 1 root root 102 2010-07-13 15:37 surveillemem
alpha # chmod a+x /etc/init.d/surveillemem
alpha # ls -l /etc/init.d/surveillemem
-rwxr-xr-x 1 root root 187 2010-07-13 15:37 surveillemem

Essai du service : 

alpha # /etc/init.d/surveillemem start


alpha # tail -f /var/log/surveillemem.log
18:13:25 -Dirty : 15 kB
18:13:55 -Dirty : 228 kB
18:14:25 -Dirty : 224 kB
18:14:55 -Dirty : 65 kB
( Ctrl - C )
alpha # pgrep -l surveillemem
2203 surveillemem
alpha # /etc/init.d/surveillemem stop
alpha # pgrep -l surveillemem
alpha #

c. Modification du niveau personnalisé 

Créer un niveau de fonctionnement personnalisé revient à s’assurer que les services voulus dans ce niveau seront 
correctement appelés au démarrage du système. Il suffit pour cela de faire en sorte que le répertoire rcn.d (où n est 
le niveau d’exécution que l’on souhaite paramétrer contienne un lien dont le nom commence par S (en majuscule), 
et  dont  la  cible  soit  le  script  de  service  normalisé  dans  /etc/init.d.  Le  mécanisme  d’initialisation  du  système 
d’exploitation se chargera d’appeler tous les fichiers de rcn.d dont la première lettre est un S avec le paramètre « 
start  ». Comme  ces  fichiers  sont  en  fait  des  liens  vers  les  scripts  de  démarrage  des  services  et  que  ces  services 
doivent répondre au paramètre « start » en démarrant, chaque lien provoquera bien le lancement du service. 

Commandes utiles

- 2- © ENI Editions - All rights reserved - Samuel CASAL


● ln 

Manipulations

1.  Créez un lien d’arrêt de l’application en niveau 0 (tout est arrêté en niveau 0). 

2.  Créez un lien d’arrêt de l’application en niveau 1 (aucune application superflue en 
niveau 1). 

3.  Créez un lien d’arrêt en niveau 2 (notre scénario ne prévoit pas que l’application soit 
exécutée en niveau 2). 

4.  Créez un lien de démarrage en niveau 3 (le niveau trois est le niveau fonctionnel 
complet avec l’application surveillemem). 

5.  Créez un lien de démarrage ou d’arrêt pour les niveaux 4 et 5 (ces niveaux n’étant pas 
utilisés dans le scénario, la fonction du lien a peu d’intérêt). 

6.  Créez un lien d’arrêt en niveau 6 (toutes les applications sont arrêtées lors d’un 
redémarrage). 

Résumé des commandes et résultat à l’écran

Création du lien d’arrêt en niveau 0 : 

alpha:~# cd /etc/rc0.d
alpha:/etc/rc0.d# ln -s ../init.d/surveillemem K05surveillemem
alpha:/etc/rc0.d#

Création du lien d’arrêt en niveau 1 : 

alpha:/etc/rc0.d# cd ../rc1.d
alpha:/etc/rc1.d# ln -s ../init.d/surveillemem K05surveillemem
alpha:/etc/rc1.d#

Création du lien d’arrêt en niveau 2 : 

alpha:/etc/rc1.d# cd ../rc2.d
alpha:/etc/rc2.d# ln -s ../init.d/surveillemem K05surveillemem
alpha:/etc/rc2.d#

Création du lien de démarrage  en niveau 3 : 

alpha:/etc/rc2.d# cd ../rc3.d
alpha:/etc/rc3.d# ln -s ../init.d/surveillemem S95surveillemem
alpha:/etc/rc3.d#

Création des liens pour les niveaux 4 et 5 : 

alpha:/etc/rc3.d# cd ../rc4.d
alpha:/etc/rc4.d# ln -s ../init.d/surveillemem K05surveillemem
alpha:/etc/rc4.d# cd ../rc5.d
alpha:/etc/rc5.d# ln -s ../init.d/surveillemem K05surveillemem
alpha:/etc/rc5.d#

Création du lien d’arrêt en niveau 6 : 

alpha:/etc/rc5.d# cd ../rc6.d
alpha:/etc/rc6.d# ln -s ../init.d/surveillemem K05surveillemem
alpha:/etc/rc6.d#

d. Changement de niveau d’exécution à chaud 

N’ayant  pas  modifié  le  niveau  d’exécution  par  défaut,  le  système  doit  démarrer  en  niveau  2.  Vous  décidez  de 
changer de niveau d’exécution à chaud pour vérifier que le lancement du service est bien initié. 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Commandes utiles

● pgrep 

● reboot 

● runlevel 

● shutdown 

● telinit 

Manipulations

1.  Redémarrez la machine. 

2.  Vérifiez que l’application surveillemem ne s’est pas lancée au démarrage. 

3.  Vérifiez le niveau d’exécution courant après démarrage. 

4.  Commandez au système de passer au niveau d’exécution 3 à chaud. 

5.  Vérifiez que l’application surveillemem est en cours d’exécution. 

6.  Repassez en niveau 2. 

Résumé des commandes et résultat à l’écran

Vérification du niveau en cours : 

alpha:~# runlevel
N 2
alpha:~#

Vérification de la non­exécution de l’application témoin (surveillemem) : 

alpha:~# pgrep -l surveillemem


alpha:~#

Changement à chaud du niveau d’exécution : 

alpha:~# telinit 3
INIT : Switching to runlevel: 3
alpha:~#

Vérification du niveau en cours : 

alpha:~# runlevel
2 3
alpha:~#

Vérification de l’exécution de l’application témoin (surveillemem) : 

alpha:~# pgrep -l surveillemem


2193 surveillemem
alpha:~#

Retour au niveau 2 : 

alpha:~# telinit 2
INIT : Switching to runlevel: 2
alpha:~#

e. Suppression des liens 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


Votre responsable applicatif vous informe que l’application à déployer a une consommation mémoire fixe de 32 ko. 
Déçu, vous décidez alors de supprimer les liens de gestion de service. Ne vous souvenant plus de la commande qui 
permet d’effacer un lien symbolique, vous vous tournez vers une commande directe de gestion de service. 

Commande utile

● update­rc.d 

Manipulations

1.  Supprimez tous les liens des répertoires rcn.d sans utiliser la commande rm (le script 
contenu dans init.d étant toujours présent, il se peut que la commande employée ait 
des scrupules. Faites le nécessaire). 

Résumé des commandes et résultat à l’écran

Suppression des liens de gestion de service : 

alpha:/etc/rc3.d# update-rc.d surveillemem remove


update-rc.d: /etc/init.d/surveillemem exists during rc.d purge (use -f to force)
alpha:/etc/rc3.d# update-rc.d -f surveillemem remove
Removing any system startup links for
/etc/init.d/surveillemem ...
/etc/rc0.d/K05surveillemem
/etc/rc1.d/K05surveillemem
/etc/rc2.d/K05surveillemem
/etc/rc3.d/S95surveillemem
/etc/rc4.d/K05surveillemem
/etc/rc5.d/K05surveillemem
/etc/rc6.d/K05surveillemem
alpha:/etc/rc3.d#

2. Réinstallation de GRUB après corruption 

Il peut arriver que le gestionnaire de boot soit corrompu ou écrasé par accident. Un peu inquiet à cette idée, vous 
décidez de vous entraîner à réinstaller GRUB sur un système qui en est dépourvu. 

Dans  un  premier  temps,  vous  copierez  l’intégralité  des  données  de  la  machine  alpha  (systèmes  et  données 
d’applications) sur un disque dur que nous appellerons clonehd. Vous créerez ensuite une nouvelle machine virtuelle 
qui  exploitera  ce  disque,  mais  qui  sera  naturellement  incapable  de  démarrer.  Enfin,  vous  installerez  GRUB  sur  ce 
disque afin que le démarrage puisse avoir lieu normalement. 

a. Copie des données du disque 

Commandes utiles

● cp 

● dmesg 

● grep 

● mkdir 

● mke2fs 

● mount 

Manipulations

© ENI Editions - All rights reserved - Samuel CASAL - 5-


1.  Ajoutez le disque dur IDE clonehd à la machine virtuelle alpha. Pour simplifier la 
manipulation et éviter toute interaction malencontreuse, supprimez le contrôleur et les 
disques SATA. 

2.  Ajoutez l’image DSL.iso en tant que cdrom de la machine alpha. 

3.  Démarrez la machine alpha en bootant sur le livecd DSL (l’option de démarrage "dsl 
lang=fr 2" permet d’avoir un clavier français et de démarrer sans interface graphique). 

4.  Depuis un terminal sur DSL, interrogez le ring­buffer du noyau pour voir si les deux 
disques ont été reconnus. 

5.  Créez une partition de 1 giga sur le deuxième disque dur. 

6.  Créez un filesystem ext3 sur cette partition. 

7.  Créez deux répertoires /un et /deux dans le filesystem du système virtuel. 

8.  Montez le filesystem du premier disque dur (système de alpha) sur /un. 

9.  Montez le filesystem du second disque dur (nouveau disque clonehd) sur /deux. 

10.  Copiez les données du premier disque sur le second. Utilisez une option qui préserve 
tous les attributs des fichiers, entre autres dates et permissions. 

11.  Arrêtez la machine virtuelle. 

Résumé des commandes et résultat à l’écran

Détection des disques : 

[~]# dmesg | grep hd


<6> ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
<6> ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
<4>hda: VBOX HARDDISK, ATA DISK drive
<4>hdb: VBOX HARDDISK, ATA DISK drive
<4>hdc: VBOX CD-ROM, ATAPI CD/DVD-ROM drive
<4>hda: attached ide-disk driver.
<6>hda: 16777216 sectors (8590 MB) w/256KiB Cache, CHS=1044/255/63
<4>hdb: attached ide-disk driver.
<6>hdb: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=520/128/63
<6> hda: hda1 hda2 < hda5 >
<6> hdb: unknown partition table
<4>hdc: attached ide-scsi driver.

Création de la partition : 

[~]# fdisk /dev/hdb


Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won’t be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/hdb: 2147 MB, 2147483648 bytes


128 heads, 63 sectors/track, 520 cylinders
Units = cylinders of 8064 * 512 = 4128768 bytes

Device Boot Start End Blocks Id System

Command (m for help): n


Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-520, default 1):

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-520, default 520): 400

Command (m for help): p

Disk /dev/hdb: 2147 MB, 2147483648 bytes


128 heads, 63 sectors/track, 520 cylinders
Units = cylinders of 8064 * 512 = 4128768 bytes

Device Boot Start End Blocks Id System


/dev/hdb1 1 400 1612768+ 83 Linux

Command (m for help): w


The partition table has been altered!

Calling ioctl() to re-read partition table.


Syncing disks.

Création du filesystem sur la partition. 

[~]# mke2fs -j /dev/hd1


mke2fs 1.34-WIP (21-May-2003)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
201760 inodes, 403192 blocks
20159 blocks (5.00%) reserved for the super user
First data block=0
13 block groups
32768 blocks per group, 32768 fragments per group
15520 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Writing inode tables: 0/13 1/13 2/13 3/13 4/13 5/13 6/13 7/13 8/13 9/13 10/13
11/13 12/13 done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 22 mounts or


180 days, whichever comes first. Use tune2fs -c or -i to override.

Montage des partitions. 

[~]# mkdir /un /deux


[~]# mount /dev/hda1 /un
[~]# mount /dev/hdb1 /deux
[~]# ls /un
bin cdrom dev home lib
media opt root selinux sys
usr vmlinuz root data etc
initrd.i lost+found mnt proc sbin
srv tmp var
[~]# ls /deux
lost+found

Copie des données. 

[~]# cp -a /un/* /deux


[~]# ls /deux
bin cdrom dev home lib
media opt root selinux sys
usr vmlinuz root data etc
initrd.i lost+found mnt proc sbin
srv tmp var

Arrêt du système. 

© ENI Editions - All rights reserved - Samuel CASAL - 7-


[~]# shutdown -h now

b. Création de la machine virtuelle clone 

Créez  une  nouvelle  machine  virtuelle  appelée  clone.  Affectez­lui  le  disque  clonehd  que  vous  aurez  auparavant 
retiré de la machine virtuelle alpha, et conservez toutes les valeurs par défaut. 
Mettez­la en route, et constatez son incapacité à démarrer bien qu’elle dispose d’un disque partitionné avec tous 
les fichiers système. 

c. Installation de GRUB 

Commandes utiles

● grub 

● grub : root 

● grub : setup 

Manipulations

Affectez  à  la  machine  virtuelle  clone  l’image  iso  DSL  et  redémarrez­la.  Vous  disposez  alors  d’un  shell  root  sur  le 
système virtuel. 

1.  Chargez l’interface GRUB. 

2.  Définissez la partition dont le filesystem sera monté sur /. 

3.  Installez GRUB sur le disque dur. 

4.  Quittez GRUB. 

Résumé des commandes et résultat à l’écran

[~]# grub
GRUB version 0.91 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]

grub> root (hd0,0)


Filesystem type is ext2fs, partittion type 0x83

grub> setup (hd0)


Checking if "boot/grub/stage1" exists... yes
Checking if "boot/grub/stage2" exists... yes
Checking if "boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded. succeeded
Running "install /boot/grub/stage1 d (hd0) (hd0)1+17 p
(hd(0,0)/boot/grub/stage 2 /boot/grub/menu.lst"... succeeded
Done.

grub>quit

d. Démarrage et vérification 

Déconnectez l’image iso DSL et redémarrez la machine virtuelle. Le démarrage doit normalement s’exécuter. 

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Connaissances générales réseaux et modèle OSI.
Connaissances sommaire du démon syslog.  

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Configurer le réseau d’un système en lignes de commandes.
Gérer des routes statiques.  
Utiliser les utilitaires de gestion arp. 
Configurer les tcp wrappers. 
Connaître les commandes de gestion des réseaux Wi­Fi. 
Capturer des trames sur le réseau.  
Configurer un serveur DHCP basique. 
Configurer une réservation DHCP. 
Exploiter un client DHCP. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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­dessous, 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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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.  En  outre,  la  certification  LPI 
exige la connaissance de ces techniques de gestion des accès. 
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 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Nous  savons  que  la  commande  ifconfig  ­a  permet  d’observer  toutes  les  interfaces  réseaux  présentes  sur  un 
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

© ENI Editions - All rights reserved - Samuel CASAL - 7-


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

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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 et celui qu’il faut connaître pour la certification LPI 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 - Samuel CASAL


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 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


utilisée, le nom machine est sans importance. 

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

- 4- © ENI Editions - All rights reserved - Samuel CASAL


DHCPREQUEST of 172.18.142.243 on eth1 to 255.255.255.255 port 67
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 - Samuel CASAL - 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 - Samuel CASAL


Validation des acquis 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Quelle commande permet de lier une adresse IP secondaire à une interface ? 
2 Si une machine a deux interfaces réseau, faut­il configurer une deuxième passerelle par défaut ? 

3 Quel intérêt y a­t­il à renseigner le fichier /etc/ethers qui associe des adresses MAC à des adresses IP et à le 
faire prendre en compte par la commande arp ­f ? 
4 Dans le cadre de l’usage des TCP Wrappers et du démon tcpd, comment les conflits éventuels entre le fichier 
hosts.deny et le fichier hosts.allow sont­ils résolus ? 
5 La commande ifconfig renvoie­t­elle des informations sur une connexion Wi­Fi ? 

6 Pourquoi est­il fréquent d’utiliser le paramètre ­n avec les commandes arp, route, ou netstat ? 
7 Si un fichier ouvert empêche le démontage d’un filesystem, comment peut­on trouver le nom du fichier en 
question et l’utilisateur qui l’a ouvert ? 
8 Pour quel usage la bibliothèque logicielle libpcap s’est­elle imposée ? 
9 La requête DHCP d’un client est envoyée sous forme de broadcast car le client ne connaît pas l’adresse du 
serveur DHCP. Pourquoi la réponse du serveur se fait­elle sous forme de broadcast également ? 

10 Si un serveur DNS est annoncé dans la configuration générale d’un serveur DHCP, et qu’un autre serveur DNS 
est annoncé dans une section subnet, quel(s) serveur(s) DNS obtiennent les clients du subnet ? 

2. Réponses 

1 Quelle commande permet de lier une adresse IP secondaire à une interface ? 
C’est  la  commande  ifconfig,  qui  selon  les  paramètres  utilisés,  peut  affecter  entre  autres,  l’adresse  IP  principale,  le 
masque de sous­réseau, l’adresse MAC, et une adresse IP secondaire si le besoin s’en fait sentir. 
2 Si une machine a deux interfaces réseau, faut­il configurer une deuxième passerelle par défaut ? 
Surtout  pas.  Si  on  définit  deux  passerelles  par  défaut  dans  les  fichiers  de  configuration  des  interfaces,  les  scripts 
d’initialisation du réseau lisent ces deux paramètres l’un après l’autre, et ne retiennent que le dernier. De toute façon, 
comme son nom l’indique, la passerelle par défaut est utilisée en dernier ressort quand la destination se trouve sur un 
réseau dont on ne connaît pas la route. Or, la table de routage est unique et indépendante des interfaces : la passerelle 
par défaut doit donc être un paramètre unique et indépendant des interfaces. 
3 Quel intérêt y a­t­il à renseigner le fichier /etc/ethers qui associe des adresses MAC à des adresses IP et à le 
faire prendre en compte par la commande arp ­f ? 
Si le fichier /etc/ethers est renseigné et exploité, le système connaît les associations entres les adresses MAC et les 
adresses  IP  qui  s’y  trouvent.  En  conséquence,  toute  communication  avec  lesdites  adresses  IP  peut  se  faire 
directement  sans  passer  par  une  requête  ARP.  Le  bénéfice  est  absolument  minime,  les  requêtes  ARP  étant  rapides, 
petites et en volume insignifiantes par rapport à l’ensemble du trafic. On peut y trouver un intérêt en terme de sécurité 
dans la mesure où on évite les broadcasts liés à ces requêtes, et où on est donc plus discret sur le réseau. 
4 Dans le cadre de l’usage des TCP Wrappers et du démon tcpd, comment les conflits éventuels entre le fichier 
hosts.deny et le fichier hosts.allow sont­ils résolus ? 
En principe, un seul de ces fichiers devrait exister. Si c’est hosts.allow, seuls les hôtes mentionnés dans le fichier sont 
autorisés,  et  si  c’est  hosts.deny,  tous  sont  autorisés  sauf  ceux  du  fichier.  En  cas  de  conflit,  la  solution  la  plus 
restrictive est appliquée, et le fichier hosts.deny est ignoré. 

5 La commande ifconfig renvoie­t­elle des informations sur une connexion Wi­Fi ? 
Pas vraiment. La commande ifconfig donnera des informations sur toutes les interfaces présentes sur un système, y 
compris  les  interfaces  Wi­Fi.  En  revanche,  elle  ne  fournit  aucune  information  relative  au  fonctionnement  sans  fil  : 
SSID, la qualité du signal et l’encryptage. La commande iwconfig en revanche est parfaitement compétente. Elle permet 
d’afficher les informations relatives à une connexion Wi­Fi, et même de la configurer. 

6 Pourquoi est­il fréquent d’utiliser le paramètre ­n avec les commandes arp, route, ou netstat ? 
Parce qu’il dispense la commande de faire une résolution de nom inverse : ces commandes récupèrent en principe des 
données numériques brutes (adresses IP, adresses MAC et numéro de ports). Or, pour des raisons cosmétiques, elles 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


affichent  par  défaut  les  noms  correspondant  à  ces  données  numériques,  notamment  le  nom  DNS  éventuellement 
associé  à  une  adresse  IP  manipulée.  Mais  s’il  n’existe  aucun  enregistrement  DNS  pour  l’adresse  en  question,  la 
commande essaiera toutefois d’en faire la résolution, et n’abandonnera qu’au timeout du resolver DNS. Donc, pour un 
élément  de  confort  incertain  (il  n’est  pas  sûr  que  l’utilisateur  préfère  les  noms  aux  adresses),  la  commande  perd 
plusieurs  secondes  à  essayer  des  résolutions  sans  espoir.  L’usage  de  l’option  ­n  dispense  la  commande  de  ces 
recherches fastidieuses, et diminue donc notablement le temps de réponse. 
7 Si un fichier ouvert empêche le démontage d’un filesystem, comment peut­on trouver le nom du fichier en 
question et l’utilisateur qui l’a ouvert ? 
Avec la commande lsof, qui donne les fichiers ouverts, le nom et le numéro du processus responsable, et le nom de 
l’utilisateur propriétaire du processus. 
8 Pour quel usage la bibliothèque logicielle libpcap s’est­elle imposée ? 
Pour  la  capture  de  trames.  Les  applications  qui  l’utilisent  sont  nombreuses  et  on  peut  citer  notamment  tcpdump  et 
wireshark.  Une  bibliothèque  ouverte  permet  à  des  logiciels  différents  d’utiliser  le  même  format  de  données,  on  peut 
donc utiliser tcpdump pour capturer un échange entre deux machines, wireshark pour l’observer en détail, et un logiciel 
d’analyse pour repérer les traces caractéristiques d’un virus par exemple. 

9 La requête DHCP d’un client est envoyée sous forme de broadcast car le client ne connaît pas l’adresse du 
serveur DHCP. Pourquoi la réponse du serveur se fait­elle sous forme de broadcast également ? 
Tout  simplement  parce  que  le  client  ne  dispose  pas  encore  d’une  adresse  IP,  et  qu’une  adresse  de  destinataire  est 
indispensable pour réaliser un unicast. 
10 Si un serveur DNS est annoncé dans la configuration générale d’un serveur DHCP, et qu’un autre serveur DNS 
est annoncé dans une section subnet, quel(s) serveur(s) DNS obtiennent les clients du subnet ? 
Celui du subnet. Les paramètres généraux sont prévus pour s’appliquer à tout client, sauf information contraire dans 
une section plus précise. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 

1. Configuration d’un serveur DHCP sur le serveur alpha 

Les stations de travail se multiplient sur le réseau, et la gestion des adresses IP devient problématique. Vous décidez 
d’installer un serveur DHCP. 

a. Configuration d’une adresse IP fixe pour le serveur alpha 

Commandes et fichiers utiles

● /etc/network/interfaces 

● /etc/resolv.conf 

● ifdown 

● ifup 

● vi 

Manipulations

1.  Configurez le serveur alpha avec une adresse IP fixe. L’adresse doit être permanente et 
être conservée après redémarrage. Dans les exercices, on utilisera l’adresse 
192.168.200.101. 

2.  Vérifiez que le resolver exploite un serveur DNS valide. 

3.  Vérifiez que l’adresse IP est bien prise en compte. 

4.  Vérifiez que la passerelle par défaut est bien prise en compte. 

Résumé des commandes et résultat à l’écran

Fichier /etc/network/interfaces modifié : 

# This file describes the network interfaces available on your system


# and how to activate them. For more information, see interfaces(5).

# The loopback network interface


auto lo
iface lo inet loopback

# The primary network interface


allow-hotplug eth0
iface eth0 inet static
address 192.168.200.101
netmask 255.255.255.0
network 192.168.200.0
broadcast 192.168.200.255

gateway 192.168.200.254

Prise en compte de la nouvelle configuration : 

alpha:~# ifdown eth0


alpha:~# ifdup eth0
alpha:~#

© ENI Editions - All rights reserved - Samuel CASAL - 1-


Fichier /etc/resolv.conf : 

nameserver 194.2.0.20
nameserver 194.2.0.50

Vérification de l’adresse IP : 

alpha:~# ifconfig eth0


eth0 Link encap:Ethernet HWaddr 08:00:27:d1:b6:8f
inet adr:192.168.200.101 Bcast:192.168.200.255 Masque:255.255.255.0
adr inet6: fe80::a00:27ff:fed1:b68f/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:681 errors:0 dropped:0 overruns:0 frame:0
TX packets:379 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:64675 (63.1 KiB) TX bytes:51934 (50.7 KiB)
Interruption:10 Adresse de base:0xd020

alpha:~#

Vérification de la route par défaut par deux commandes différentes : 

alpha:~# netstat -nr


Table de routage IP du noyau
Destination Passerelle Genmask Indic MSS Fenêtre irtt Iface
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.200.254 0.0.0.0 UG 0 0 0 eth0
alpha:~# route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.200.254 0.0.0.0 UG 0 0 0 eth0
alpha:~#

b. Installation des paquetages applicatifs 

Sur le serveur alpha, installez le service DHCP par la commande suivante : 

apt-get install dhcp3-server

Acceptez les options par défaut. Si le démarrage du service échoue, pas d’inquiétude. Les choses iront mieux après 
configuration. 
Sur la station de travail, installez le logiciel de capture de trames wireshark par la commande suivante : 

sudo apt-get install wireshark

c. Configuration du service 

Directives utiles

● option 

● range 

● subnet 

Manipulations

1.  Dans le fichier /etc/dhcp3/dhcpd.conf, déclarez un réseau correspondant à votre 
adresse de réseau (192.168.200.0/24). 

2.  Au sein du subnet, déclarez une plage d’adresses allant de 192.168.200.50 à 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


192.168.200.99. 

3.  Au sein du subnet, déclarez 192.168.200.254 comme adresse de passerelle par 
défaut. 

4.  Au sein du subnet, déclarez votre serveur DNS actif. 

5.  Configurez la durée des baux par défaut à 24h. 

Résumé des commandes et résultat à l’écran

Fichier /etc/dhcp3/dhcpd.conf modifié (cette section doit être ajoutée au contenu déjà présent du fichier) : 

default-lease-time 86400;
subnet 192.168.200.0 netmask 255.255.255.0 {
range 192.168.200.50 192.168.200.99;
option routers 192.168.200.254;
option domain-name-servers 192.168.200.254;
}

2. Exploitation du service DHCP 

a. Configuration de la station de travail 

La station Ubuntu doit déjà être configurée en tant que client DHCP. Pour redemander explicitement une adresse 
IP,  il  suffit  de  cliquer  sur  l’icône  représentant  le  réseau  dans  la  barre  d’écran  supérieure.  Un  clic  sur  Auto  eth0 
provoquera une demande de bail DHCP. 
Vérifiez ensuite que la station a bien obtenu une adresse et que cette adresse provient bien du serveur alpha. (Il 
peut être nécessaire de désactiver un éventuel serveur DHCP déjà actif sur le réseau) 

Résumé des commandes et résultat à l’écran

toto@station:~$ ifconfig eth0


eth0 Link encap:Ethernet HWaddr 00:22:25:d7:97:e6
inet adr:192.168.200.50 Bcast:192.168.200.255 Masque:255.255.255.0
adr inet6: fe80::222:15ff:fed7:97e6/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:301626 erreurs:0 :0 overruns:0 frame:0
TX packets:186828 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:325369697 (325.3 MB) Octets transmis:18332970 (18.3 MB)
Interruption:26 Adresse de base:0x4000

toto@station:~$ cat /var/lib/dhcp3/dhclient.leases


lease {
interface "eth0";
fixed-address 192.168.200.20;
option subnet-mask 255.255.255.0;
option routers 192.168.200.254;
option dhcp-lease-time 864000;
option dhcp-message-type 5;
option domain-name-servers 212.27.40.241,212.27.40.240;
option dhcp-server-identifier 192.168.200.254;
renew 6 2010/07/10 14:55:34;
rebind 3 2010/07/14 14:33:58;
expire 4 2010/07/15 20:33:58;
}
toto@station:~$

b. Réservation d’une adresse IP pour une imprimante 

La  configuration  de  l’imprimante  de  l’entreprise  n’est  pas  aisée  et  de  ce  point  de  vue,  le  serveur  DHCP  sera  le 
bienvenu.  Toutefois,  pour  des  raisons  évidentes  de  confort  d’administration,  cette  imprimante  doit 
systématiquement obtenir la même adresse IP. Vous décidez donc de réserver une adresse IP pour l’imprimante. 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Directives utiles

● fixed­address 

● hardware 

● host 

● option 

Manipulations

1.  Dans le fichier /etc/dhcp3/dhcpd.conf, déclarez un hôte correspondant à votre 
imprimante. 

2.  Dans la section hôte, déclarez l’adresse MAC de l’imprimante. 

3.  Dans la section hôte, déclarez l’adresse IP 192.168.200.11 pour l’imprimante. 

4.  Dans la section hôte, déclarez la passerelle par défaut. 

Extrait du fichier dhcpd.conf après configuration

host printer1 {
hardware ethernet 00:12:34:56:78:9A;
fixed-ip-address 192.168.200.11;
option routers 192.168.200.254;
}

c. Capture de paquets depuis la station de travail : échanges DHCP 

Votre  curiosité  naturelle  vous  pousse  à  regarder  de  plus  près  les  échanges  DHCP  entre  la  station  et  le  serveur. 
Vous utiliserez pour cela les outils standard de capture de trames tcpdump et wireshark. 

Commandes utiles

● dhclient 

● tcpdump 

● wireshark 

Manipulations

Les manipulations sont à réaliser sur la station de travail Ubuntu. 

1.  Depuis un terminal, libérez l’adresse IP précédemment obtenue. 

2.  Depuis un autre terminal, capturez les paquets échangés sur l’interface eth0 et sur les 
ports 67 et 68 (échanges DHCP). Utilisez la commande tcpdump avec les privilèges 
administrateur. 

3.  Depuis le premier terminal, provoquez une requête DHCP. 

4.  Constatez le résultat à l’écran grâce à la sortie standard de la commande tcpdump. 

5.  Renouvelez l’opération, mais cette fois, envoyez le résultat vers un fichier dhcp.cap. 

6.  Ouvrez ce fichier avec wireshark. 

7.  Observez le résultat de la capture. 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


Résumé des commandes et résultat à l’écran

Terminal 1­ Libération de l’adresse IP : 

toto@station:~$ sudo dhclient -r eth0


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

Listening on LPF/eth0/08:00:27:7b:c8:79
Sending on LPF/eth0/08:00:27:7b:c8:79
Sending on Socket/fallback
DHCPRELEASE on eth0 to 192.168.200.254 port 67
toto@ubuntu:~$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:7b:c8:79
adr inet6: fe80::a00:27ff:fe7b:c879/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:24315 erreurs:0 :0 overruns:0 frame:0
TX packets:6943 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:24613918 (24.6 MB) Octets transmis:482889 (482.8 KB)
Interruption:10 Adresse de base:0xd020
toto@station:~$

Terminal 2 ­ Capture avec tcpdump : 

toto@station:~$ sudo tcpdump -i eth0 -n port 67 and port 68


tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
toto@station:~$

Terminal 1 ­ Requête DHCP : 

toto@station:~$ sudo dhclient eth0


Internet Systems Consortium DHCP Client V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/08:00:27:7b:c8:79
Sending on LPF/eth0/08:00:27:7b:c8:79
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPOFFER of 192.168.200.102 from 192.168.200.254
DHCPREQUEST of 192.168.200.102 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.200.102 from 192.168.200.254
bound to 192.168.200.102 -- renewal in 329015 seconds.
toto@station:~$

Terminal 2 ­ Résultat de tcpdump : 

(...)
12:06:59.003789 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 08:00:27:7b:c8:79, length 300
12:06:59.008562 IP 192.168.200.254.67 > 192.168.200.102.68: BOOTP/DHCP,
Reply, length 548
12:06:59.051798 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 08:00:27:7b:c8:79, length 300
12:06:59.056980 IP 192.168.200.254.67 > 192.168.200.102.68: BOOTP/DHCP,
Reply, length 548
12:06:59.842693 IP 192.168.200.101.67 > 192.168.200.50.68: BOOTP/DHCP,
Reply, length 300
[ Ctrl - C ]
5 packets captured
6 packets received by filter

© ENI Editions - All rights reserved - Samuel CASAL - 5-


0 packets dropped by kernel
toto@station:~$

Terminal 1 ­ Libération de l’adresse IP : 

toto@station:~$ sudo dhclient -r eth0


(...)
toto@station:~$

Terminal 2 ­ Capture avec tcpdump et résultat dans un ficher : 

toto@station:~$ sudo tcpdump -w dhcp.cap -i eth0 -n port 67 or port 68


tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
[ Ctrl - C ]
toto@station:~$

Terminal 1 ­ Requête DHCP : 

toto@station:~$ sudo dhclient eth0


(...)
toto@station:~$

Observation des échanges avec wireshark. 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Connaître la structure du fichier /etc/passwd.
Connaître l’existence et le principe du fichier hosts. 

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Interpréter une configuration NSS.
Comprendre l’authentification modulaire PAM. 
Connaître les principaux modules PAM. 
Modifier la configuration PAM pour permettre un changement du mode d’authentification. 
Connaître le format de fichier LDIF. 
Interroger un annuaire LDAP. 
Gérer les mots de passe dans un annuaire OpenLDAP  
Ajouter ou modifier des éléments d’un annuaire OpenLDAP. 
Configurer l’authentification d’un système Linux sur un annuaire OpenLDAP. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


É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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL - 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 - Samuel CASAL


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 tel que prévu pour la certification LPI, 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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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


-h 172.17.7.20 -s motdepasse cn=tata,ou=paris,dc=pas,dc=net

© ENI Editions - All rights reserved - Samuel CASAL - 7-


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 - Samuel CASAL


 

© ENI Editions - All rights reserved - Samuel CASAL - 9-


Authentification par LDAP des systèmes Linux 
Dans  le  cadre  des  objectifs  LPI,  nous  supposons  ici  que  nous  disposons  déjà  d’un  annuaire  en  ligne,  et  que  des 
comptes y sont créés avec tous 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 - Samuel CASAL - 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 - Samuel CASAL


Validation des acquis 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Pourquoi les mots de passe des systèmes actuels ne sont plus stockés dans le fichier /etc/passwd comme 
c’était le cas aux origines des systèmes Unix ? 

2 Pourquoi y a­t­il un paramètre dns dans le fichier /etc/nsswitch.conf ? 

3 En quoi l’arrivée de PAM a­t­elle facilité le travail des développeurs pour ce qui relève des opérations 
d’authentification ? 

4 Quel est l’intérêt du concept de pile de modules PAM ? 
5 Dans quel cas un module d’authentification PAM appelé avec le contrôle de comportement sufficient ne conduit 
pas à la réussite de l’authentification ? 
6 Que se passe­t­il après la réussite d’un module appelé avec le contrôle de comportement required ? 
7 Comment utiliser le format d’échange LDIF des annuaires LDAP pour exporter les données d’un annuaire LDAP 
comme l’Active Directory vers un autre annuaire LDAP comme OpenLDAP ? 
8 Pourquoi une commande spécifique (ldappasswd) est­elle nécessaire pour modifier le mot de passe d’un 
compte utilisateur openldap, alors que la commande ldapmodify permet déjà d’écrire dans n’importe quel 
attribut des objets de l’annuaire ? 
9 Existe­t­il une méthode ponctuelle qui permette de définir le contexte de recherche des clients LDAP autre que 
le renseignement de la directive BASE dans le fichier ldap.conf. ? 
10 Pourquoi dans une authentification LDAP d’un système Linux, conserve­t­on presque toujours le recours à 
l’authentification locale par fichier de mots de passe (/etc/shadow) ? 

2. Réponses 

1 Pourquoi les mots de passe des systèmes actuels ne sont plus stockés dans le fichier /etc/passwd comme 
c’était le cas aux origines des systèmes Unix ? 
Les  mots  de  passe  étaient  à  l’origine  stockés  dans  le  fichier  /etc/passwd  avec  les  autres  informations  liées  aux 
comptes utilisateurs. Ce fichier devant être accessible en lecture par tous les utilisateurs, les mots de passe étaient 
cryptés par un algorithme de hachage. Avec l’évolution de la puissance de calcul des ordinateurs, il est devenu possible 
de deviner un mot de passe, d’abord en cryptant toutes les entrées d’un dictionnaire, puis toutes les combinaisons de 
caractères  possibles.  Trouver  la  chaîne  de  caractère  qui  une  fois  cryptée  est  la  même  que  celle  du  fichier  revient  à 
trouver le mot de passe. Pour contrer cette possibilité, les mots de passe ont été retirés du fichier /etc/passwd, et placé 
dans un fichier /etc/shadow, non accessible aux utilisateurs. 

2 Pourquoi y a­t­il un paramètre dns dans le fichier /etc/nsswitch.conf ? 
Le  fichier  nsswitch.conf  contient  tous  les  paramètres  de  résolution  de  noms,  ainsi  que  les  bases  d’informations 
nécessaires à leur résolution. Ainsi, il indique généralement que la résolution des noms d’hôtes (hosts) doit se faire en 
premier lieu avec un fichier local (paramètre files), puis par un service dns s’il est configuré (paramètre dns). 

3 En quoi l’arrivée de PAM a­t­elle facilité le travail des développeurs pour ce qui relève des opérations 
d’authentification ? 
Parce  que  les  développeurs  n’ont  pas  d’autre  souci  que  de  rendre  leurs  applications  compatibles  avec  la  bibliothèque 
d’authentification  PAM.  Si  les  techniques  d’authentification  évoluent,  il  n’est  pas  nécessaire  de  modifier  l’application, 
mais uniquement sa configuration PAM dans laquelle on précisera les modules nouveaux ou différents sur lesquels doit 
reposer cette authentification. 

4 Quel est l’intérêt du concept de pile de modules PAM ? 
De  pouvoir  englober  dans  l’opération  d’authentification  l’exécution  de  plusieurs  modules.  Les  applications  pratiques 
sont  nombreuses  :  on  peut  accepter  un  utilisateur  si  une  authentification  distante  est  réussie  (LDAP)  ou  si 
l’authentification  locale  aboutit.  On  peut  aussi  exiger  qu’une  authentification  particulière  (biométrie  par  exemple) 
réussisse,  ainsi  qu’une  authentification  traditionnelle  par  mot  de  passe.  Enfin,  et  c’est  utilisé  couramment,  on  peut 
profiter  de  l’étape  de  l’authentification  pour  exécuter  d’autres  actions  comme  de  charger  des  variables  (module 
pam_env) ou d’interdire certains logins utilisateurs (module pam_nologin). 
5 Dans quel cas un module d’authentification PAM appelé avec le contrôle de comportement sufficient ne conduit 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


pas à la réussite de l’authentification ? 
Si un module appelé avec le contrôle de comportement required ou requisite a échoué auparavant. 

6 Que se passe­t­il après la réussite d’un module appelé avec le contrôle de comportement required ? 
On continue. La réussite d’un module required ne provoque pas l’arrêt du traitement de la pile. Les autres modules de 
la pile sont exécutés. 
7 Comment utiliser le format d’échange LDIF des annuaires LDAP pour exporter les données d’un annuaire LDAP 
comme l’Active Directory vers un autre annuaire LDAP comme OpenLDAP ? 
Très difficilement. Le format LDIF est intimement lié au schéma de l’annuaire, et deux annuaires différents ont presque 
toujours un schéma différent. Les attributs LDAP ne seront donc pas les mêmes de part et d’autre, et une exportation 
contiendrait  forcément  des  éléments  non  assimilables  par  le  deuxième  annuaire.  On  pourrait  ponctuellement  réussir 
quelques échanges en restreignant les données exportées et importées à des classes d’objets et attributs communs 
aux  deux  annuaires.  Les  services  fonctionnels  permettant  des  échanges  complets  (méta­annuaires)  s’appuient 
toujours  sur  une  phase  de  remise  en  forme  des  données.  On  parle  fréquemment  d’une  opération  de  mapage 
d’attributs. 

8 Pourquoi une commande spécifique (ldappasswd) est­elle nécessaire pour modifier le mot de passe d’un 
compte utilisateur openldap, alors que la commande ldapmodify permet déjà d’écrire dans n’importe quel 
attribut des objets de l’annuaire ? 
Parce  que  la  commande  ldapmodify  écrirait  l’attribut  mot  de  passe  en  clair,  alors  que  la  commande  ldappasswd  gère 
nativement plusieurs algorithmes de cryptage. 
9 Existe­t­il une méthode ponctuelle qui permette de définir le contexte de recherche des clients LDAP autre que 
le renseignement de la directive BASE dans le fichier ldap.conf. ? 
Oui, on peut renseigner la variable LDAPBASE avec le contexte de recherche que devront utiliser les clients LDAP. Cette 
méthode  souffre  toutefois  de  la  volatilité  des  variables,  et  la  déclaration  devra  rester  valable  dans  l’environnement 
d’exécution  des  commandes  clientes  (on  exporte  généralement  la  variable  depuis  un  processus  parent  de  celui  des 
commandes clientes). 
10 Pourquoi dans une authentification LDAP d’un système Linux, conserve­t­on presque toujours le recours à 
l’authentification locale par fichier de mots de passe (/etc/shadow) ? 
Pour  conserver  l’usage  du  système  en  cas  d’indisponibilité  de  l’annuaire  LDAP.  Les  contrôles  de  comportement  des 
modules  LDAP  sont  tout  à  fait  adaptés  à  cet  usage,  en  permettant  l’authentification  par  annuaire  LDAP,  mais  en  se 
rabattant sur une méthode alternative en cas d’échec. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 
Devant  les  perspectives  d’extension  de  l’entreprise  et  les  milliers  de  postes  de  travail  possibles,  vous  prenez 
conscience  de  la  nécessité  d’une  authentification  centralisée  et  à  grande  échelle.  Vous  décidez  donc  d’installer  un 
serveur LDAP sur beta. 

1. Création et alimentation d’un annuaire LDAP sur le serveur beta 

a. Installation des paquetages applicatifs 

Sur le serveur beta, installez le service LDAP ainsi que les utilitaires clients avec la commande suivante : 

yum install openldap-servers


yum install openldap-clients

Sur la station de travail, installez les utilitaires clients avec la commande suivante : 

sudo apt-get install ldap-utils

b. Configuration de l’annuaire 

Fichiers et commandes utiles

● /etc/openldap/slapd.conf 

● slappasswd 

● vi 

Manipulations

1.  Sur le serveur beta, dans le fichier slapd.conf, trouvez la déclaration de contexte par 
défaut et remplacez­le par « pas.net » (dc=pas,dc=net). N’oubliez pas de modifier 
également le suffixe du rootdn. 

2.  Dans le fichier slapd.conf, renseignez le mot de passe administrateur avec la valeur 
« password ». 

3.  Redémarrez le service. 

Résumé des commandes et résultat à l’écran

L’ensemble  des  modifications  est  fait  ici  en  lignes  de  commandes  sans  passer  par  un  éditeur  de  texte.  La 
certification LPI n’exige naturellement pas ce type de démarche qui relèverait plutôt du niveau 1. 

Modification des valeurs de suffixe dans le fichier /etc/openldap/slapd.conf : 

root@beta openldap]# grep suffix slapd.conf


suffix "dc=my-domain,dc=com"
[root@beta openldap]# sed -i s/"dc=my-domain,dc=com"/"dc=pas,dc=net"/ slapd.conf

Vérification : 

[root@beta openldap]# grep "dc=pas,dc=net" slapd.conf


suffix "dc=pas,dc=net"
rootdn "cn=Manager,dc=pas,dc=net"
[root@beta openldap]#

Affectation du mot de passe administrateur dans le fichier /etc/openldap/slapd.conf  

© ENI Editions - All rights reserved - Samuel CASAL - 1-


[root@beta openldap]# grep rootpw slapd.conf
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
[root@beta openldap]# slappasswd -s password
{SSHA}7xWHl+/YmWtgW7IqJpWBlzGFzvhHaPom
[root@beta openldap]# echo "rootpw $(slappasswd -s password)" >> slapd.conf
[root@beta openldap]#

Vérification : 

[root@beta openldap]# grep rootpw slapd.conf


# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
rootpw {SSHA}/qNLfdcQeazSkiX6O4rKm8kL/E73iFyu
[root@beta openldap]#

Arrêt et lancement du service : 

[root@beta openldap]# service ldap stop


Arrêt de slapd : [ ECHOUE ]
[root@beta openldap]# service ldap start
Vérification des fichiers de configuration pour slapd : config file testing succeeded
[ OK ]
Démarrage de slapd : [ OK ]
[root@beta openldap]#

Fichier /etc/openldap/slapd.conf après modification (commentaires retirés) : 

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
database bdb
suffix "dc=pas,dc=net"
rootdn "cn=Manager,dc=pas,dc=net"
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
rootpw {SSHA}r8ldo8lBQ063ct6nFDl/RjJR0QwOPZvp

c. Interrogation simple de l’annuaire 

Un annuaire openldap étant par définition une chose discrète, vous décidez à ce stade de faire une interrogation 
simple de l’annuaire, pour voir s’il veut bien répondre. 

Commandes utiles

● ldapsearch 

● pgrep 

● service 

Manipulations

1.  Sur le serveur beta, vérifiez que le service slapd s’exécute. 

2.  Depuis le serveur beta, faites une requête la plus simple possible visant à obtenir une 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


réponse de l’annuaire (même si à ce stade l’annuaire n’a pas de contenu). 

Résumé des commandes et résultat à l’écran

Vérification de l’exécution du service par deux commandes différentes : 

[root@beta openldap]# pgrep -l slapd


3494 slapd
[root@beta openldap]# service ldap status
slapd (pid 2977) en cours d’exécution...
[root@beta openldap]#

Requête simple : 

[root@beta openldap]# ldapsearch -x


# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
[root@beta openldap]#

d. Création du contexte de base 

Commandes utiles

● ldappadd 

● vi 

Manipulations

1.  Créez un fichier LDIF contenant la déclaration du contexte de base. 

2.  Importez ce fichier dans l’annuaire. 

Fichier base.ldif : 

dn: dc=pas, dc=net


objectClass: domain
dc: pas

Résumé des commandes et résultat à l’écran

Vérification du fichier base.ldif : 

[root@beta ~]# cat base.ldif


dn: dc=pas, dc=net
objectClass: domain
dc: pas
[root@beta ~]#

Importation du fichier dans l’annuaire : 

[root@beta openldap]# ldapadd -x -D cn=Manager,dc=pas,dc=net -W -f ~/base.ldif


Enter LDAP Password :
adding new entry "dc=pas,dc=net"

© ENI Editions - All rights reserved - Samuel CASAL - 3-


[root@beta openldap]#

e. Création de comptes utilisateur 

Commandes utiles

● ldappadd 

● vi 

Manipulations

1.  Créez un fichier LDIF contenant les données de deux utilisateurs. 

2.  Importez ce fichier dans l’annuaire. 
Fichier ajout.ldif : 

dn: uid=toto,dc=pas,dc=net
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: toto
cn: toto
sn: toto
uidNumber: 601
gidNumber: 1000
homeDirectory: /home/toto
loginShell: /bin/bash
userPassword: password

dn: uid=titi,dc=pas,dc=net
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: titi
cn: titi
sn: titi
uidNumber: 602
gidNumber: 1000
homeDirectory: /home/titi
loginShell: /bin/bash
userPassword: password

Résumé des commandes et résultat à l’écran

[root@beta openldap]# ldapadd -x -D cn=Manager,dc=pas,dc=net -W -f ~/ajout.ldif


Enter LDAP Password :
adding new entry "uid=toto,dc=pas,dc=net"
adding new entry "uid=titi,dc=pas,dc=net"
[root@beta openldap]#

f. Interrogation d’un annuaire peuplé 

Commandes utiles

● ldapsearch 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


Manipulations

1.  Depuis le serveur beta, faites une requête visant à obtenir la totalité des données de 
l’annuaire. 

Résumé des commandes et résultat à l’écran

Requête LDAP : 

[root@beta openldap]# ldapsearch -x -b "dc=pas,dc=net" -D


cn=Manager,dc=pas,dc=net -W -s sub
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=pas,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# pas.net
dn: dc=pas,dc=net
objectClass: domain
dc: pas

# toto, pas.net
dn: uid=toto,dc=pas,dc=net
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: toto
cn: toto
sn: toto
givenName: toto
uidNumber: 601
gidNumber: 1000
homeDirectory: /home/toto
loginShell: /bin/bash
userPassword:: cGFzc3dvcmQ=
(...)
[root@beta openldap]#

g. Interrogation de l’annuaire depuis un client 

Avant de passer aux choses sérieuses, il nous reste à vérifier que le client sur la station de travail atteint bien les 
données de l’annuaire. 

Fichiers et commandes utiles

● ldap.conf 

● ldapsearch 

Manipulations

1.  Depuis la station de travail, faites une interrogation du contenu de l’annuaire en 
précisant tous les éléments nécessaires dans la ligne de commande. 

2.  Renseignez les paramètres BASE et HOST dans le fichier /etc/ldap/ldap.conf. 

3.  Refaites une requête sur le serveur avec une syntaxe allégée en vous appuyant sur les 
données du fichier ldap.conf. 

© ENI Editions - All rights reserved - Samuel CASAL - 5-


Résumé des commandes et résultat à l’écran

Requête depuis la station de travail : 

toto@station:~$ ldapsearch -x -h 192.168.200.102 -b dc=pas,dc=net


-D cn=Manager,dc=pas,dc=net -W -s sub
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=pas,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# pas.net
dn: dc=pas,dc=net
objectClass: domain
dc: pas

# toto, pas.net
dn: uid=toto,dc=pas,dc=net
(...)
toto@station:~$

Fichier /etc/ldap/ldap.conf modifié : 

#
# LDAP Defaults
#

# See ldap.conf(5) for details


# This file should be world readable but not world writable.

BASE dc=pas,dc=net
HOST 192.168.200.102
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

Requête allégée : 

toto@station:~$ ldapsearch -x -D cn=Manager,dc=pas,dc=net -W -s sub


Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=pas,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# pas.net
dn: dc=pas,dc=net
objectClass: domain
dc: pas

# toto, pas.net
(...)
toto@station:~$

2. Authentification du poste de travail par l’annuaire LDAP 

a. Installation des éléments applicatifs nécessaires à l’authentification LDAP 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Sur la station, installez les bibliothèques pam nécessaires à l’authentification LDAP : 

sudo apt-get install ldap-auth-client


sudo apt-get install ldap-auth-config

Répondez  au  mieux  aux  questions  qui  vous  sont  éventuellement  posées,  vous  reviendrez  de  toute  façon  sur  les 
fichiers  à  configurer.  En  cas  de  doutes,  renseignez  une  valeur  farfelue  facilement  identifiable  pour  voir  quels 
éléments l’assistant aura renseignés. 

b. Configuration de la résolution de noms LDAP 

Commandes et fichiers utiles

● /etc/ldap.conf 

● /etc/nsswitch.conf 

● getent 

Manipulations

1.  Dans le fichier nsswitch.conf, ajoutez le mot­clé ldap aux sections passwd, group et 
shadow. 

2.  Afin que les résolutions de noms puissent se faire par LDAP, renseignez les paramètres 
host et base dans le fichier /etc/ldap.conf. Pour une meilleure stabilité, commentez ou 
supprimez la ligne uri ldapi://. 

3.  Vérifiez que la résolution se fait correctement, et qu’un nom d’utilisateur est bien 
associé à un compte utilisateur dans l’annuaire. 

Résumé des commandes et résultat à l’écran

Extrait de fichier /etc/nsswitch.conf modifié : 

passwd : ldap compat


group : ldap compat
shadow : ldap compat

Extrait de fichier /etc/ldap.conf modifié : 

host 192.168.200.201
base dc=pas,dc=net
# uri ldapi://192.168.200.201

Test de la résolution de noms : 

toto@station:/etc$ getent passwd titi


titi:*:602:1000:titi:/home/titi:/bin/bash
toto@station:/etc$

c. Configuration de l’authentification pam avec LDAP 

Les fichiers pam ont sans doute déjà été modifiés par les scripts de post­installation et la configuration doit déjà 
être  fonctionnelle.  La  distribution  Ubuntu  étant  un  peu  avant­gardiste,  nous  allons  remettre  les  paramètres  pam 
aux valeurs standard attendues par la certification LPI. 

Commandes et fichiers utiles

● /etc/pam.d/common­account 

© ENI Editions - All rights reserved - Samuel CASAL - 7-


● /etc/pam.d/common­auth 

Manipulations

1.  Dans le fichier /etc/pam.d/common­auth, constatez la présence d’une ligne pour le 
module pam_unix et déclarez­la comme étant sufficient. 

2.  Dans le fichier /etc/pam.d/common­auth, constatez la présence d’une ligne pour le 
module pam_ldap (ou ajoutez­la) et déclarez­la comme étant sufficient. 

3.  Dans le fichier /etc/pam.d/common­account, constatez la présence d’une ligne pour le 
module pam_unix et déclarez­la comme étant sufficient. 

4.  Dans le fichier /etc/pam.d/common­account, constatez la présence d’une ligne pour le 
module pam_ldap (ou ajoutez­la) et déclarez­la comme étant sufficient. 

5.  Pour créer au besoin un répertoire personnel à un nouvel utilisateur qui se connecterait, 
ajoutez au fichier /etc/pam.d/common­session une ligne chargeant le module 
pam_mkhomedir.so sous le type session, avec le contrôle required, et avec l’option 
skel=/etc/skel. 

Fichiers modifiés

Fichier /etc/pam.d/common­auth : 

auth sufficient pam_unix.so nullok_secure


auth sufficient pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

Fichier /etc/pam.d/common­account : 

account sufficient pam_unix.so


account sufficient pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so

Fichier /etc/pam.d/common­session : 

session [default=1] pam_permit.so


session requisite pam_deny.so
session required pam_permit.so
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel
session optional pam_ldap.so
session optional pam_ck_connector.so nox11

d. Validation fonctionnelle 

La  station  Ubuntu  devrait  maintenant  être  capable  d’ouvrir  une  session  avec  un  compte  utilisateur  situé  sur 
l’annuaire LDAP du serveur beta. 
La modification de tout paramètre pam étant par essence dangereuse, il est recommandé de tester la configuration 
avec  une  commande  ne  nécessitant  pas  de  redémarrer  comme  la  commande  su.  En  cas  d’échec,  on  aura  tout  le 
loisir de reprendre la configuration sans avoir à réinstaller un système incapable de démarrer. 

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Montage de filesystems.
Édition de fichiers. 

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Connaître les démons NFS.
Exporter des partages NFS ponctuels.  
Configurer un service NFS. 
Connaître les commandes de diagnostic NFS. 
Comprendre la gestion des droits des accès clients NFS. 
Connecter un client à un partage NFS. 
Connaître les démons samba.  
Configurer le partage samba des répertoires personnels des utilisateurs.  
Connaître les options samba les plus courantes.  
Gérer les mots de passe samba.  
Connecter un client à un partage samba.  
Connaître les modes de fonctionnement FTP. 
Configurer un serveur FTP. 
Exploiter un client FTP. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


serveur. 

­­anonymouscancreatedirs  Permet aux utilisateurs anonymes de créer des répertoires. 

4. Le serveur vsftpd 

vsftpd pour « very secure FTP daemon » est un autre serveur FTP très populaire sur les systèmes Linux. Il s’appuie sur 
un service et un fichier de configuration :  vsftpd.conf. Une connaissance sommaire de vsftpd est demandée pour la 
certification LPI. 

Format des options pour le fichier vsftpd.conf 

paramètre=valeur

La plupart des paramètres ont pour valeur YES ou NO. 

Fichier vsftpd.conf : paramètres courants 

anonymous_enable  Autorise ou non l’accès anonyme. 

local_enable  Autorise ou non les utilisateurs à accéder à leur répertoire personnel. 

write_enable  Autorise ou non le téléchargement de fichiers vers le serveur. 

anon_upload_enable  Autorise ou non le téléchargement vers le serveur pour les utilisateurs 
anonymes. 

anon_mkdir_write_enable  Autorise ou non la création de répertoires pour les utilisateurs 
anonymes. 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Validation des acquis 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Comment les clients en lignes de commande accèdent­ils aux données d’un partage, qu’il soit de type NFS ou 
Samba ? 

2 Est­il possible de partager les répertoires référencés dans le fichier /etc/exports sans avoir à lancer le service 
NFS ? 
3 Pourquoi l’option root_squash est­elle appliquée par défaut à un partage NFS ? 

4 Quel est le processus lancé par le chargement d’un script de gestion de service NFS ? 
5 Sur une connexion à un serveur NFS non fiable, quelle option serait adéquate pour assurer à un client NFS que 
les opérations d’écriture sont formellement réalisées ? 
6 Est­il possible de vérifier la validité d’un fichier de configuration SAMBA sans charger le service ? 
7 Comment empêcher les utilisateurs de voir un partage SAMBA dans le cadre d’une exploration réseau ? 
8 Comment créer un mot de passe à partir du mot de passe unix d’un compte déjà présent sur le système ? 
9 Peut­on synchroniser les mots de passe Unix avec les mots de passe SAMBA ? 
10 Pourquoi le mode actif s’est­il progressivement raréfié au profit du mode passif sur les clients FTP ? 

2. Réponses 

1 Comment les clients en lignes de commande accèdent­ils aux données d’un partage, qu’il soit de type NFS ou 
Samba ? 
Par  une  opération  de  montage.  Le  répertoire  partagé  est  monté  sur  un  répertoire  local.  Attention,  même  si  c’est  la 
commande universelle mount qui est employée, des éléments logiciels clients doivent être présent sur le système pour 
permettre le montage. 
2 Est­il possible de partager les répertoires référencés dans le fichier /etc/exports sans avoir à lancer le service 
NFS ? 
Oui, avec la commande exportfs, appelée avec le paramètre ­a. 
3 Pourquoi l’option root_squash est­elle appliquée par défaut à un partage NFS ? 
Parce que le contrôle d’accès aux partages NFS est basé sur l’identifiant (uid) des clients se connectant. Le compte root 
ayant toujours le même identifiant utilisateur 0, l’option root_squash lui fait perdre ses prérogatives afin que n’importe 
quel  utilisateur  root  n’ait  pas  les  pleins  pouvoirs  sur  un  partage  NFS.  Ce  comportement  est  toutefois  modifiable  en 
indiquant explicitement l’option no_root_squash au chargement du partage. 
4 Quel est le processus lancé par le chargement d’un script de gestion de service NFS ? 
NFS est en fait dépendant de trois processus : portmapd, nfsd et mountd. Le nom du script de lancement de service 
est très variable d’une distribution à l’autre (nfs pour Red Hat, nfk­kernel­server pour Debian). 

5 Sur une connexion à un serveur NFS non fiable, quelle option serait adéquate pour assurer à un client NFS que 
les opérations d’écriture sont formellement réalisées ? 
L’option  de  montage  sync  empêche  les  écritures  asynchrones.  Ainsi,  le  serveur  s’interdit  tout  usage  de  cache  en 
écriture,  et  le  client  n’est  notifié  de  la  réussite  d’une  opération  d’écriture  qu’une  fois  qu’elle  a  été  physiquement 
réalisée. 

6 Est­il possible de vérifier la validité d’un fichier de configuration SAMBA sans charger le service ? 
Oui,  avec  la  commande  testparm.  La  commande  testparm  vérifie  la  validité  du  fichier  de  configuration  et  affiche  les 
commandes actives sur la sortie standard. Il est à noter que les paramètres par défaut ne sont pas affichés, à moins 
que la commande n’ait été appelée avec l’option ­v. 

7 Comment empêcher les utilisateurs de voir un partage SAMBA dans le cadre d’une exploration réseau ? 
Le paramètre browseable dans la définition d’un partage dans le fichier de configuration permet de gérer la visibilité d’un 
partage par les clients. 

8 Comment créer un mot de passe à partir du mot de passe unix d’un compte déjà présent sur le système ? 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


On  ne  peut  pas.  Le  mot  de  passe  d’un  compte  unix  est  crypté  avec  l’algorithme  de  hachage  MD5,  par  définition 
irréversible. Les mots de passe SMB devant être créés cryptés avec l’algorithme MD4, il n’est pas possible de créer ce 
mot de passe à partir des données cryptées présentes sur le système. 
9 Peut­on synchroniser les mots de passe Unix avec les mots de passe SAMBA ? 
Oui,  en  incluant  la  directive  "unix  passwd  sync  =   yes"  dans  le  fichier  de  configuration.  Attention,  les  algorithmes  de 
hachage  étant  différents,  cette  synchronisation  ne  peut  se  faire  que  quand  le  mot  de  passe  SAMBA  est  exprimé  en 
clair. On a alors deux opérations d’encryption : une en MD5 pour la base de compte Unix, et l’autre en MD4 pour la base 
de compte SAMBA. 

10 Pourquoi le mode actif s’est­il progressivement raréfié au profit du mode passif sur les clients FTP ? 
Parce que le mode actif utilisé historiquement exploite un numéro de port pour les données initié par le serveur vers le 
client,  et  que  les  pare­feu  voient  généralement  d’un  assez  mauvais  œil.  Dans  le  mode  passif,  le  client  initie  les 
sessions de commandes comme les sessions de données, ce qui est beaucoup mieux compris par les pare­feu. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 

1. Mise en place de partages SAMBA sur le serveur alpha 

De nombreux postes de travail Windows sont présents sur votre réseau, et vous souhaitez mettre à leur disposition 
un serveur de fichiers. Vous décidez donc d’installer le service Samba sur le serveur alpha. Ce serveur doit permettre 
aux  utilisateurs  d’accéder  aux  documents  de  leur  répertoire  personnel  sur  le  serveur,  et  aussi  de  présenter  un 
partage commun de type « fourre­tout » pour l’échange libre de données entre utilisateurs. 

a. Installation des services applicatifs 

Sur le serveur alpha, installez la couche applicative SAMBA par la commande suivante : 

apt-get install samba

Acceptez tous les choix par défaut. 

b. Affichage de la configuration par défaut 

Commandes utiles

● vi 

● testparm 

Manipulations

1.  Le service fraîchement installé, affichez les paramètres en vigueur appliqués par le 
serveur tirés du fichier smb.conf. 

2.  Affichez maintenant les paramètres en vigueur, mais cette fois en incluant les 
paramètres par défaut non explicitement mentionnés dans le fichier smb.conf. 

Résumé des commandes et résultat à l’écran

Paramètres explicites : 

alpha:/etc/samba# testparm
Load smb config files from /etc/samba/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

[global]
server string = %h server
obey pam restrictions = Yes
passdb backend = tdbsam
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n
*password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
panic action = /usr/share/samba/panic-action %d

© ENI Editions - All rights reserved - Samuel CASAL - 1-


[homes]
comment = Home Directories
valid users = %S
create mask = 0700
directory mask = 0700
browseable = No
(...)
alpha:/etc/samba#

Tous les paramètres : 

alpha:/etc/samba# testparm -v
Load smb config files from /etc/samba/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

[global]
dos charset = CP850
unix charset = UTF-8
display charset = LOCALE
workgroup = WORKGROUP
realm =
netbios name = ALPHA
netbios aliases =
netbios scope =
server string = %h server
interfaces =
bind interfaces only = No
config backend = file
security = USER
auth methods =
encrypt passwords = Yes
update encrypted = No
client schannel = Auto
(... 375 lignes en tout !)
alpha:/etc/samba#

c. Gestion des mots de passe 

Commandes utiles

● smbpasswd 

Manipulations

1.  Affectez un mot de passe SAMBA au compte utilisateur toto présent sur le serveur 
alpha. 

Résumé des commandes et résultat à l’écran

alpha:/etc/samba# smbpasswd -a toto


New SMB password:
Retype new SMB password:
alpha:/etc/samba#

d. Accès des utilisateurs à leurs répertoires personnels depuis la station de travail 

Tous  les  utilisateurs  disposant  d’une  machine  Windows  étant  absents,  vous  décidez  de  faire  les  premiers  essais 
fonctionnels depuis la station de travail Ubuntu. Vous utilisez pour cela le client graphique de la station de travail. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Commandes utiles

● Utilisation de l’interface graphique 

Manipulations

1.  Ouvrez une session sur la station de travail. 

2.  Dans le menu Raccourcis, cliquez sur Se connecter à un serveur. 

3.  Dans le menu Type de service, choisissez Partage Windows. 

4.  Renseignez le champ Serveur avec l’adresse IP de alpha. 

5.  Renseignez le champ Partage avec le nom toto. 

6.  Cliquez sur le bouton Se connecter. 

7.  Dans la fenêtre d’authentification, renseignez le mot de passe de l’utilisateur. 

8.  Le répertoire de l’utilisateur doit maintenant être accessible. 

e. Création d’un partage commun 

Commandes et fichiers utiles

● chmod 

● mkdir 

● smb.conf 

● testparm 

● vi 

Manipulations

1.  Sur alpha, créez un répertoire /public. 

2.  Faites en sorte que tous les utilisateurs puissent lire et écrire dans ce répertoire. 

3.  Éditez le fichier de configuration SAMBA sur alpha. 

4.  Ajoutez une section de partage accessible en lecture et écriture pour le répertoire 
public. 

5.  Faites en sorte que ce partage soit visible lors d’une navigation réseau (de type 
voisinage réseau Windows). 

6.  Faites en sorte que le contenu des répertoires créés à distance soit effaçable par tous 
(droits rwx pour l’ensemble other sur les répertoires créés). 

7.  Testez la validité de votre syntaxe sans recharger le service. 

8.  Rechargez le service samba. 

Résumé des commandes et résultat à l’écran

Création du répertoire : 

alpha:/home/toto# mkdir /public


alpha:/home/toto# chmod o+rwx /public/
alpha:/home/toto#

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Section de partage dans smb.conf : 

[public]
path = /public
writeable = yes
browseable = yes
directory mask = 0777

Validité de la syntaxe : 

alpha:/public# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[public]"
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

Rechargement du service : 

alpha:/home/toto# /etc/init.d/samba reload


alpha:/home/toto#

f. Accès des utilisateurs au nouveau partage 

Commandes utiles

● Utilisation de l’interface graphique 

Manipulations

1.  Ouvrez une session sur la station de travail. 

2.  Dans le menu Raccourcis, cliquez sur Se connecter à un serveur. 

3.  Dans le menu Type de service, choisissez Partage Windows. 

4.  Renseignez le champ Serveur avec l’adresse IP de alpha. 

5.  Ne renseignez pas le champ Partage afin d’afficher tous les partages configurés comme 
visibles. 

6.  Cliquez sur le bouton Se connecter. 

7.  Dans la fenêtre d’authentification, renseignez le mot de passe de l’utilisateur. 

8.  Le répertoire public doit maintenant être visible. Notez que le répertoire personnel 
n’apparaît pas, car configuré comme étant non visible (Browseable = No). 

2. Mise en place de partages NFS sur le serveur beta 

L’installation prochaine d’une solution de virtualisation nécessite la mise en place d’un serveur NFS au sein du réseau. 
L’accès  se  fera  avec  le  compte  root  et  l’écriture  devra  être  possible  sur  le  partage.  Vous  décidez  de  configurer  un 
service NFS sur le serveur beta. 

a. Installation des services applicatifs 

Sur la station de travail Ubuntu, installez la couche applicative NFS par la commande suivante : 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


sudo apt-get install nfs-common

Les services NFS doivent déjà être installés sur le serveur beta. 

b. Configuration du partage 

Commandes et fichiers utiles

● /etc/exports 

● exportfs 

● mkdir 

● vi 

Manipulations

1.  Démarrez le service NFS sur beta. 

2.  Vérifiez qu’aucun partage n’est actuellement actif. 

3.  Créez un répertoire /virtu. 

4.  Créez un fichier de configuration /etc/exports qui partage ce répertoire en lecture et 
écriture avec accès normal du compte root. 

5.  Prenez en compte le partage sans redémarrer le service nfs. Vérifiez. 

Résumé des commandes et résultat à l’écran

Démarrage du service : 

[root@beta init.d]# service nfs start


Démarrage des services NFS :
[ OK ]
Démarrage du quota NFS :
[ OK ]
Démarrage du démon NFS :
[ OK ]
Démarrage de NFS mountd :
[ OK ]
[root@beta init.d]#

Vérification des partages actifs : 

[root@beta init.d]# exportfs


[root@beta init.d]#

Création du répertoire : 

[root@beta init.d]# mkdir /virtu


[root@beta init.d]#

Fichier /etc/exports : 

/virtu *(rw,no_root_squash)

Prise en compte du partage : 

[root@beta init.d]# exportfs -a


[root@beta init.d]# exportfs
/virtu <world>
[root@beta init.d]#

© ENI Editions - All rights reserved - Samuel CASAL - 5-


c. Connexion depuis la station cliente 

Commandes utiles

● mkdir 

● mount 

Manipulations

1.  Créez un répertoire virtu sous /mnt qui servira de point de montage. 

2.  Montez le partage NFS /virtu du serveur beta sur le point de montage /mnt/virtu/. 

Résumé des commandes et résultat à l’écran

Création du point de montage : 

toto@ubuntu:/mnt$ sudo mkdir /mnt/virtu


[sudo] password for toto:
toto@ubuntu:/mnt$ ls
virtu
toto@ubuntu:/mnt$

Montage du partage : 

toto@ubuntu:/mnt$ sudo mount -t nfs 192.168.200.102:/virtu virtu


toto@ubuntu:/mnt$ ls virtu
deux trois un
toto@ubuntu:/mnt$

3. Configuration d’un serveur FTP sur le serveur alpha 

Il  arrive  très  ponctuellement  que  certains  utilisateurs  aient  à  vous  remettre  des  fichiers  trop  volumineux  pour  être 
envoyés par courrier électronique. Vous décidez alors de mettre en place un service FTP. Un peu inquiet en matière 
de  sécurité,  vous  décidez  que  le  service  sera  chargé  à  la  demande,  et  permettra  des  accès  anonymes  en 
téléchargement montant, sans que les utilisateurs connectés puissent consulter le contenu du répertoire de travail 
FTP. 

a. Installation du service applicatif 

Sur le serveur alpha, installez la couche applicative pure­ftpd par la commande suivante : 

apt-get install pure-ftpd

b. Configuration et lancement du service 

Commandes utiles

● adduser 

● chmod 

● passwd 

● pure­ftpd 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Manipulations

1.  Ajoutez un compte utilisateur ftp. 

2.  Verrouillez le compte utilisateur et limitez les droits sur son répertoire personnel. Il doit 
pouvoir écrire et créer des documents, mais pas les voir. Le groupe et les autres 
utilisateurs ne doivent avoir aucun droit sur le répertoire. 

3.  Lancez le service en fonctionnement anonyme uniquement. 

Résumé des commandes et résultat à l’écran

Création du compte ftp : 

alpha:/# adduser ftp


Ajout de l’utilisateur « ftp »...
Ajout du nouveau groupe « ftp » (1001)...
Ajout du nouvel utilisateur « ftp » (1001) avec le groupe « ftp »...
Création du répertoire personnel « /home/ftp »...
Copie des fichiers depuis « /etc/skel »...
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l’utilisateur ftp
Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée
Nom complet []: ftp user
N° de bureau []:
Téléphone professionnel []:
Téléphone personnel []:
Autre []:
Ces informations sont-elles correctes ? [O/n]
alpha:/#

Verrouillage du compte : 

alpha:/# passwd -l ftp


Mot de passe changé.
alpha:/#

Limitation des droits : 

alpha:/# chmod u=wx,go= /home/ftp


alpha:/# ls -ld /home/ftp
d-wx------ 2 ftp ftp 4096 jui 16 13:59 /home/ftp
alpha:/#

Lancement du service : 

alpha:/# pure-ftpd -anonymousonly

c. Connexion depuis la station cliente Ubuntu 

Commandes utiles

● ftp 

● vi 

Manipulations

1.  Créez un fichier texte par le moyen de votre choix. 

2.  Lancez le client FTP. 

3.  Ouvrez une session FTP anonyme vers le serveur alpha. 

© ENI Editions - All rights reserved - Samuel CASAL - 7-


4.  Essayez de voir le contenu du répertoire. 

5.  Envoyez votre fichier vers le serveur. 

Résumé des commandes et résultat à l’écran

Création du fichier : 

toto@ubuntu:~$ echo "bla bla" > fichier


toto@ubuntu:~$ echo "bla" >> fichier
toto@ubuntu:~$ cat fichier
bla bla
bla
toto@ubuntu:~$

Ouverture de session FTP : 

toto@ubuntu:~$ ftp
ftp> open 192.168.200.101
Connected to 192.168.200.101.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 1 of 50 allowed.
220-Local time is now 14:12. Server port: 21.
220-Only anonymous FTP is allowed here
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (192.168.200.101:toto): anonymous
230 Anonymous user logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Essai de lecture du contenu de répertoire : 

ftp> ls
200 PORT command successful
150 Connecting to port 49524
226-Sorry, we were unable to read [.]
226-Options: -l
226 0 matches total
ftp>

Envoi de fichier vers le serveur : 

ftp> put fichier


local: fichier remote: fichier
200 PORT command successful
150 Connecting to port 50945
226-File successfully transferred
226 0.006 seconds (measured here), 1.93 Kbytes per second
12 bytes sent in 0.00 secs (5.8 kB/s)
ftp>
ftp> bye
221-Goodbye. You uploaded 1 and downloaded 0 kbytes.
221 Logout.
toto@ubuntu:~$

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Savoir éditer des fichiers texte.
Avoir des connaissances générales IP.  

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Connaître l’architecture et le principe de la résolution DNS.
Connaître les principaux types d’enregistrements DNS. 
Configurer un client DNS. 
Configurer un serveur de cache DNS. 
Configurer une redirection de la résolution DNS. 
Exploiter la commande de pilotage rndc. 
Gérer des zones DNS directes et inverses.  
Créer des enregistrements de ressources dans des zones DNS.  
Gérer des zones DNS secondaires.  
Configurer une délégation de zone DNS.  
Connaître les principaux outils de test de résolution DNS. 
Sécuriser un serveur DNS. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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 - Samuel CASAL - 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 - Samuel CASAL


 

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 - Samuel CASAL - 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 enregistrent 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 - Samuel CASAL


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. 
Si des alternatives existent à l’usage de BIND pour la résolution de noms sur Linux (maradns, djbdns par exemple), 
seule la connaissance de BIND est exigée pour la certification LPI. 

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 - Samuel CASAL - 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 - Samuel CASAL - 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. Quand on parle d’installer et de configurer un serveur de cache, comme 
dans  les  objectifs  de  la  certification  LPI,  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 - Samuel CASAL


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 - Samuel CASAL - 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. Pour la certification LPI, retenez plutôt /var/named. 
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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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.  

Exemple d’utilisation de dig 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


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


formation.fr name server donald.formation.fr.

© ENI Editions - All rights reserved - Samuel CASAL - 7-


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 - Samuel CASAL


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; };

Ou 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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 5-


Validation des acquis 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Pourquoi existe­t­il plusieurs types d’enregistrements DNS ? 
2 Quel lien existe entre la messagerie et la résolution DNS ? 

3 En quoi un serveur de cache améliore­t­il le fonctionnement global d’un réseau ? 

4 Comment installer le composant resolver DNS sur un système Linux standard ? 
5 Peut­on se passer de la directive include dans le fichier named.conf ? 

6 Comment un serveur DNS local au sein d’une entreprise peut­il tirer parti du cache d’un serveur plus sollicité 
comme celui de son fournisseur d’accès par exemple ? 

7 Comment peut­on prendre en compte des éléments nouveaux sur un serveur DNS, comme des enregistrements 
nouvellement créés sans recourir au rechargement complet du service ? 
8 De toutes les commandes de test de résolution DNS, laquelle donnera les résultats les plus précis et les plus 
circonstanciés ? 
9 Comment se mettre à l’abri d’une vulnérabilité du code exécutable DNS quand on craint une intrusion ou 
malveillance par exploitation de cette vulnérabilité ? 

10 Dans le cadre d’une délégation, pourquoi est­il indispensable d’avoir une communication possible entre le 
serveur délégant et le serveur délégué ? 

2. Réponses 

1 Pourquoi existe­t­il plusieurs types d’enregistrements DNS ? 
Pour stocker des informations de natures différentes. Ainsi, il est possible pour un client de demander à son serveur 
DNS une information précise. Par exemple : Quel est le serveur maître pour telle zone ? Quels sont les serveurs DNS 
disponibles pour telle zone ? 
2 Quel lien existe entre la messagerie et la résolution DNS ? 
Les  enregistrements  MX  référencent  pour  un  domaine  DNS  le  ou  les  serveurs  de  messagerie.  Un  serveur  de 
messagerie  fonctionnel  peut  ne  recevoir  aucun  message  de  l’extérieur  si  son  enregistrement  MX  n’est  pas 
correctement référencé. 
3 En quoi un serveur de cache améliore­t­il le fonctionnement global d’un réseau ? 
En  conservant  en  mémoire  les  résolutions  déjà  effectuées,  le  serveur  répond  beaucoup  plus  vite  aux  requêtes 
suivantes. Dans la mesure où sur un réseau ordinaire, la plupart des requêtes portent sur les mêmes enregistrements 
courants  (google,  sncf,  ebay,  etc.),  tous  les  clients  qui  obtiennent  une  réponse  mise  en  cache  ont  une  réponse 
immédiate sans que le serveur ait besoin de relancer une résolution publique. 

4 Comment installer le composant resolver DNS sur un système Linux standard ? 
Le resolver fait partie de la pile IP sur toutes les distributions Linux, et il n’est donc pas besoin de l’installer. 
5 Peut­on se passer de la directive include dans le fichier named.conf ? 
Bien  sûr.  Cette  directive  permet  d’appeler  des  fichiers  contenant  des  éléments  de  configuration  annexe  et  de  les 
intégrer dans la configuration du serveur. Toutefois, si on choisit de placer tous les éléments de configuration dans un 
seul fichier named.conf, cela ne pose aucun problème, si ce n’est celui d’avoir à gérer un fichier un peu long. 

6 Comment un serveur DNS local au sein d’une entreprise peut­il tirer parti du cache d’un serveur plus sollicité 
comme celui de son fournisseur d’accès par exemple ? 
En  le  déclarant  dans  une  redirection  (directive  forwarders).  Le  serveur  résoudra  alors  lui­même  tous  les 
enregistrements appartenant à des zones locales, et s’en remettra au serveur de son fournisseur d’accès pour toute 
autre résolution. 
7 Comment peut­on prendre en compte des éléments nouveaux sur un serveur DNS, comme des enregistrements 
nouvellement créés sans recourir au rechargement complet du service ? 
Grâce à la commande de pilotage rndc, qui permet justement de prendre en compte des évolutions de la configuration 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


ou des données hébergées en agissant sur une seule zone et en évitant donc le rechargement complet du service qui 
solliciterait bien davantage de ressources. 
8 De toutes les commandes de test de résolution DNS, laquelle donnera les résultats les plus précis et les plus 
circonstanciés ? 
C’est  la  commande  dig,  considérée  comme  le  fleuron  des  outils  de  diagnostics  DNS.  Si  certaines  distributions  ont 
présenté dig comme l’outil universel destiné à remplacer avantageusement tous les autres, la plupart des utilisateurs 
préfèrent toujours aujourd’hui la commande nslookup. 

9 Comment se mettre à l’abri d’une vulnérabilité du code exécutable DNS quand on craint une intrusion ou 
malveillance par exploitation de cette vulnérabilité ? 
Deux techniques sont exploitables et elles sont souvent utilisées conjointement. D’abord en enfermant le processus 
named  dans  un  environnement  d’exécution  étanche.  On  dit  qu’on  met  le  processus  en  prison  (in  jail)  par  un 
changement de racine (chroot). La prison en question est une arborescence contenant une copie de tous les éléments 
dont  aura  besoin  le  processus  pour  son  fonctionnement  comme  les  bibliothèques  ou  fichiers  de  configuration.  Par 
ailleurs, on exécute le processus au nom d’un compte de service aux pouvoirs limités, si bien que l’exploitation d’une 
éventuelle vulnérabilité ne donnerait pas à l’attaquant plus de droits que ceux du compte en question. 

10 Dans le cadre d’une délégation, pourquoi est­il indispensable d’avoir une communication possible entre le 
serveur délégant et le serveur délégué ? 
Le  principe  d’une  délégation  est  en  quelque  sorte  de  sous­traiter  la  gestion  d’une  zone  enfant  à  un  autre  serveur. 
Toutes les requêtes faites au serveur parent pour la zone enfant seront dynamiquement dirigées vers le serveur de la 
zone enfant. S’il n’y a pas de communication, cette redirection n’est tout simplement pas possible. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 

1. Installation d’un serveur DNS 

Pour accélérer la navigation internet au sein du réseau, vous décidez de mettre en place un serveur DNS interne à 
votre entreprise. Ainsi, tous les clients qui font les résolutions DNS les plus courantes profiteront du cache du serveur 
local. 

a. Installation des services applicatifs 

Sur le serveur alpha, installez le serveur bind avec la commande suivante : 

apt-get install bind9

Le service doit déjà être installé sur le serveur beta. 

b. Vérification 

Commandes utiles

● pgrep 

● ps 

● rndc 

Manipulations

1.  Vérifiez que le service est en cours d’exécution en observant les processus actifs. 

2.  Vérifiez que le service est en cours d’exécution en interrogeant le script de lancement. 

3.  Vérifiez que le service est en cours d’exécution en utilisant la commande de pilotage 
rndc. 

Résumé des commandes et résultat à l’écran

Observation du processus : 

alpha:~# pgrep -l named


4491 named
alpha:~#

Interrogation du script : 

alpha:~# /etc/init.d/bind9 status


bind9 is running.
alpha:~#

Utilisation de la commande de pilotage : 

alpha:~# rndc status


version: 9.6-ESV-R1
CPUs found: 1
worker threads: 1
number of zones: 14
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0

© ENI Editions - All rights reserved - Samuel CASAL - 1-


query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
alpha:~#

c. Configuration des clients 

Commandes et fichiers utiles

● /etc/resolv.conf 

● vi 

Manipulations

1.  Modifiez la configuration du serveur alpha afin qu’il s’interroge lui­même pour toute 
requête DNS. 

2.  Modifiez la configuration de la station de travail Ubuntu afin qu’elle utilise le serveur 
alpha pour toute requête DNS. 

Fichiers modifiés

fichier /etc/resolv.conf sur le serveur alpha 

nameserver 192.168.200.101

Fichier /etc/resolv.conf sur la station de travail 

nameserver 192.168.200.101

2. Configuration du serveur de cache 

Si l’installation  s’est bien passée, que votre serveur connaît une route vers l’extérieur,  et  que  le  port  UDP  53  n’est 


pas filtré, votre serveur doit pouvoir faire n’importe quelle résolution dans l’espace de nom public. 

a. Vérification de la résolution des noms dans l’espace de nom public 

Commandes utiles

● ping 

Manipulations

1.  Faites un ping sur une adresse publique connue. 

Résumé des commandes et résultat à l’écran

Ping sur une adresse publique : 

alpha:~# ping www.gnu.org


PING gnu.org (199.232.41.10) 56(84) bytes of data.
64 bytes from www.gnu.org (199.232.41.10): icmp_seq=1 ttl=52 time=136 ms
64 bytes from www.gnu.org (199.232.41.10): icmp_seq=2 ttl=52 time=140 ms
alpha:~#

N’oubliez pas que lors du test d’une résolution avec la commande ping, c’est la première ligne qui nous intéresse, 
celle qui traduit le nom en adresse IP, et non l’éventuelle réponse au ping, qui peut par ailleurs être filtrée. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


b. Essais de mise en cache (facultatif) 

Commandes utiles

● ping 

Manipulations

1.  Juste après une résolution réussie, faites en sorte que votre serveur ne puisse plus 
quitter le réseau, en débranchant le routeur de votre switch par exemple. 

2.  Refaites le même ping alors que le serveur n’accède plus à l’extérieur. 

3.  Faites un ping sur un autre nom quelconque. 

Résumé des commandes et résultat à l’écran

Ping sur une valeur conservée en cache : 

alpha:~# ping www.gnu.org


PING gnu.org (199.232.41.10) 56(84) bytes of data.
alpha:~#

Ping sur une valeur nouvelle : 

alpha:~# ping www.kernel.org


ping unknown host www.kernel.org
alpha:~#

c. Redirection 

Vous disposez maintenant d’un serveur capable de faire des résolutions de noms. Afin que votre serveur puisse à 
son tour bénéficier du cache du serveur de votre fournisseur d’accès, déclarez une redirection. 

Commandes et fichiers utiles

● named.conf (named.conf.options) 

● vi 

Manipulations

1.  Éditez le fichier /etc/bind/named.conf.options. 

2.  Décommentez la ligne forwarders en supprimant le double slash ainsi que les deux 
lignes directement en dessous. 

3.  Remplacez 0.0.0.0 par l’adresse IP du serveur DNS de votre fournisseur d’accès. 

4.  Rechargez le service par la commande de votre choix. 

Résumé des commandes et résultat à l’écran

Fichier /etc/bind/named.conf/options : 

options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want


// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable


// nameservers, you probably want to use them as forwarders.

© ENI Editions - All rights reserved - Samuel CASAL - 3-


// Uncomment the following block, and insert the addresses replacing
// the all-0’s placeholder.

forwarders {
194.2.0.50;
};

auth-nxdomain no; # conform to RFC1035


listen-on-v6 { any; };
};

Rechargement du service : 

alpha:/etc/bind# /etc/init.d/bind9 restart


Stopping domain name service...: bind9.
Starting domain name service...: bind9.
alpha:/etc/bind#

3. Création de zones personnalisées directes et inverses 

Encouragé par ces succès, vous décidez d’utiliser votre serveur DNS pour héberger une zone locale. Cette zone vous 
permettra  de  créer  des  enregistrements  qui  référenceront  vos  ressources  locales  comme  les  imprimantes  par 
exemple. Pour faire les choses dans les règles de l’art, vous décidez de créer une zone directe pas.net et une zone 
inverse correspondant au réseau 192.168.200.0. 

a. Création des fichiers de zones sur le serveur A 

Vous allez créer le fichier pour la zone directe pas.net et pour la zone inverse 200.168.192.in­addr.arpa. Ces fichiers 
devront  déclarer  A  comme  serveur  maître  pour  ces  zones.  L’adresse  mail  du  contact  administratif  sera 
root@pas.net. 

Commandes et fichiers utiles

● fichiers de zone 

● vi 

Manipulations

1.  Dans /etc/bind, créez deux fichiers db.pas.net et db.192.168.200. 

2.  Dans les deux fichiers, créez l’enregistrement SOA avec alpha comme serveur 
autoritaire. Appuyez vous sur /etc/bind/db.empty pour connaître les valeurs de cache 
par défaut. N’oubliez pas que les noms de zones sont des FQDN, et qu’ils doivent donc 
être terminés par un point. L’adresse mail du contact administratif est root@pas.net. 

3.  Créez les enregistrements NS pour chacun des fichiers. Pour les deux zones, le serveur 
alpha est le serveur de nom. 

4.  Créez dans la zone directe un enregistrement de type A pour associer une adresse IP 
au serveur alpha. 

Résumé des commandes et résultat à l’écran

Fichier /etc/bind/pas.net : 

$TTL 86400
pas.net. IN SOA alpha.pas.net. root.pas.net. (
1
604800
86400
2419200
86400 )

- 4- © ENI Editions - All rights reserved - Samuel CASAL


pas.net. IN NS alpha.pas.net.
alpha.pas.net. IN A 192.168.200.101

Fichier /etc/bind/db.192.168.200 : 

$TTL 86400
200.168.192.in-addr.arpa. IN SOA alpha.pas.net. root.pas.net. (
1
604800
86400
2419200
86400 )

200.168.192.in-addr.arpa. IN NS alpha.pas.net.

b. Déclaration des fichiers de zone 

Le but est maintenant de faire savoir à votre serveur qu’il doit charger les deux fichiers de zone que vous venez de 
créer à chaque démarrage du service. 

Commandes et fichiers utiles

● named.conf (named.conf.local) 

● vi 

Manipulations

1.  Dans /etc/bind/named.conf.local, créez une section zone référençant votre zone directe 
en tant que zone maîtresse. 

2.  Dans /etc/bind/named.conf.local, créez une section zone référençant votre zone inverse 
en tant que zone maîtresse. 

3.  Rechargez le service. 

Résumé des commandes et résultat à l’écran

Fichier /etc/bind/named.conf.local : 

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "pas.net" {
type master;
file "/etc/bind/db.pas.net";
};

zone "200.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.200";
};

Rechargement du service : 

alpha:/etc/bind# /etc/init.d/bind9 restart


Stopping domain name service...: bind9.
Starting domain name service...: bind9.
alpha:/etc/bind#

© ENI Editions - All rights reserved - Samuel CASAL - 5-


Il  est  impératif  que  votre  service  redémarre  sans  encombre.  Un  tail de  /var/log/syslog  vous  dira  si  les 
zones sont bien chargées et si le service a correctement démarré. 

c. Création d’enregistrements 

Vous décidez maintenant de créer quelques enregistrements de différentes natures pour tester le fonctionnement 
de votre serveur. 

Commandes et fichiers utiles

● Fichiers de zone 

● vi 

Manipulations

1.  Dans votre fichier de zone directe, créez un enregistrement beta.pas.net de type A 
correspondant à l’adresse IP du serveur beta. 

2.  Dans votre fichier de zone directe, créez un enregistrement serveur­a de type CNAME 
correspondant au FQDN alpha.pas.net. 

3.  Dans votre fichier de zone directe, créez un enregistrement alfa de type CNAME 
correspondant au nom court alpha. 

4.  Dans votre fichier de zone inverse, créez un enregistrement 101 de type PTR 
correspondant au nom du serveur alpha. 

5.  Dans votre fichier de zone inverse, créez un enregistrement 102 de type PTR 
correspondant au nom du serveur beta. 

6.  Rechargez les informations de zone. 

Résumé des commandes et résultat à l’écran

Enregistrements de ressources dans le fichier de zone pas.net 

beta.pas.net. IN A 192.168.200.102
serveur-a IN CNAME alpha.pas.net.
alfa IN CNAME alpha

Enregistrements de ressources dans le fichier de zone 200.168.192.in­addr.arpa 

101 IN PTR alpha.pas.net.


102 IN PTR beta.pas.net.

Rechargement des informations de zone : 

alpha:/etc/bind# rndc reload


server reload successful
alpha:/etc/bind#

4. Interrogation du serveur 

Ayant à cœ ur de vérifier que tout se passe bien, vous conduisez quelques tests depuis la station de travail Ubuntu. 

a. Utilisation de nslookup 

Commande utile

● nslookup 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Manipulations

1.  Précisez que le serveur à interroger est alpha. 

2.  Demandez l’adresse correspondant au nom alpha.pas.net. 

3.  Demandez l’adresse correspondant au nom serveur­a.pas.net. 

4.  Demandez le nom correspondant à l’adresse 192.168.200.102. 

Résumé des commandes et résultat à l’écran

Résolution depuis la station avec nslookup 

toto@ubuntu:~$ nslookup
> server 192.168.200.101
Default server: 192.168.200.101
Address: 192.168.200.101#53
> alpha.pas.net
Server: 192.168.200.101
Address: 192.168.200.101#53

Name: alpha.pas.net
Address: 192.168.200.101
> serveur-a.pas.net
Server: 192.168.200.101
Address: 192.168.200.101#53

serveur-a.pas.net canonical name = alpha.pas.net.


Name: alpha.pas.net
Address: 192.168.200.101
> 192.168.200.102
Server: 192.168.200.101
Address: 192.168.200.101#53

102.200.168.192.in-addr.arpa name = beta.pas.net.


>

b. Utilisation de dig 

Commande utile

● dig 

Manipulations

1.  Demandez au serveur alpha l’adresse de beta.pas.net. 

Résumé des commandes et résultat à l’écran

toto@ubuntu:~$ dig @192.168.200.101 beta.pas.net

; <<>> DiG 9.6.1-P1 <<>> @192.168.200.101 beta.pas.net


; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34012
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;beta.pas.net. IN A

;; ANSWER SECTION:
beta.pas.net. 86400 IN A 192.168.200.102

© ENI Editions - All rights reserved - Samuel CASAL - 7-


;; AUTHORITY SECTION:
pas.net. 86400 IN NS alpha.pas.net.

;; ADDITIONAL SECTION:
alpha.pas.net. 86400 IN A 192.168.200.101

;; Query time: 10 msec


;; SERVER: 192.168.200.101#53(192.168.200.101)
;; WHEN: Fri Jul 16 16:06:25 2010
;; MSG SIZE rcvd: 82

toto@ubuntu:~$

5. Création d’un serveur secondaire 

Inquiet pour la disponibilité du service, vous décidez de répliquer vos zones sur un deuxième serveur. Vous décidez 
donc d’exploiter le serveur beta en tant que serveur secondaire pour vos deux zones. 
Les  distributions  Red  Hat  proposent  un  service  bind  chrooté  d’origine.  Rien  de  problématique,  l’environnement  de 
travail  se  situera  intégralement  dans  le  répertoire  /var/named/chroot,  et  le  fonctionnement  chrooté  est  déjà 
configuré dans le script de lancement du service. 

a. Configuration du serveur secondaire 

Lors de la synchronisation, les fichiers de zones seront créés localement sur le serveur beta. Il faut s’assurer que le 
compte de service (named) ait bien le droit d’écriture sur son répertoire de stockage. 

Commandes et fichiers utiles

● named.conf 

● chmod 

Manipulations

1.  Créez un fichier named.conf dans le répertoire /var/named/chroot/etc. 

2.  Déclarez les deux zones esclaves pas.net et 200.168.192.in­addr.arpa ayant pour 
maître le serveur alpha. Assurez un stockage local des fichiers de zone dans le 
répertoire chrooté /var/named. 

3.  Faites en sorte que le groupe du compte de service named puisse écrire dans le 
répertoire de stockage des fichiers de zones (/var/named/chroot/var/named). 

4.  Démarrez le service et constatez l’absence d’erreur. 

Résumé des commandes et résultat à l’écran

Fichier /var/named/chroot/etc/named.conf : 

zone "pas.net" {
type slave;
masters { 192.168.200.101 ; };
file "/var/named/pas.net";
};
zone "200.168.192.in-addr.arpa" {
type slave;
masters { 192.168.200.101 ; };
file "/var/named/200.168.192.in-addr.arpa";
};

Affectation des droits au compte de service named : 

[root@beta var]# ls -ld /var/named/chroot/var/named/

- 8- © ENI Editions - All rights reserved - Samuel CASAL


drwxr-x--- 4 root named 4096 jui 16 17:01 /var/named/chroot/var/named/
[root@beta var]# chmod g+w /var/named/chroot/var/named/
[root@beta var]# ls -ld /var/named/chroot/var/named/
drwxrwx--- 4 root named 4096 jui 16 17:01 /var/named/chroot/var/named/
[root@beta var]#

Démarrage du service : 

[root@beta var]# service named start


Démarrage de named :
[ OK ]
[root@beta var]#

Vérification : 

[root@beta var]# tail /var/log/messages


Jul 16 17:02:48 beta named[641]: running
Jul 16 17:02:48 beta named[641]: zone pas.net/IN: Transfer started.
Jul 16 17:02:48 beta named[641]: transfer of ’pas.net/IN’ from 192.168.200.101#53:
connected using 192.168.200.51#58348
Jul 16 17:02:48 beta named[641]: zone pas.net/IN: transferred serial 1
Jul 16 17:02:48 beta named[641]: transfer of ’pas.net/IN’ from 192.168.200.101#53:
end of transfer
Jul 16 17:02:49 beta named[641]: zone 200.168.192.in-addr.arpa/IN: Transfer started.
Jul 16 17:02:49 beta named[641]: transfer of ’200.168.192.in-addr.arpa/IN’ from
192.168.200.101#53: connected using 192.168.200.51#48705
Jul 16 17:02:49 beta named[641]: zone 200.168.192.in-addr.arpa/IN: transferred serial 1
Jul 16 17:02:49 beta named[641]: transfer of ’200.168.192.in-addr.arpa/IN’ from
192.168.200.101#53: end of transfer
[root@beta var]#
[root@beta var]# ls /var/named/chroot/var/named/
200.168.192.in-addr.arpa data pas.net slaves
[root@beta var]#

b. Configuration du serveur primaire 

Il ne vous reste plus qu’à indiquer au serveur maître qu’il doit désormais composer avec un partenaire. 

Commandes et fichiers utiles

● Fichiers de zone 

● dig 

● tail 

● vi 

Manipulations

1.  Déclarez pour vos deux zones le serveur beta comme nouveau serveur de type NS. 

2.  Ajoutez un enregistrement de type A référençant le client Ubuntu. 

3.  Incrémentez le numéro de série des zones. 

4.  Rechargez les zones. 

5.  Vérifiez en consultant le journal système du serveur alpha que le redémarrage du 
service s’est bien passé. 

6.  Vérifiez sur le serveur beta que les modifications ont bien été prises en compte. 

Résumé des commandes et résultat à l’écran

© ENI Editions - All rights reserved - Samuel CASAL - 9-


Fichier de zone directe modifié : 

$TTL 86400
pas.net. IN SOA alpha.pas.net. root.pas.net. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
pas.net. IN NS alpha.pas.net.
pas.net. IN NS beta.pas.net.
alpha.pas.net. IN A 192.168.200.101
beta.pas.net. IN A 192.168.200.102
serveur-a IN CNAME alpha.pas.net.
alfa IN CNAME alpha
client IN A 192.168.200.199

Fichier de zone inverse modifié : 

$TTL 86400
200.168.192.in-addr.arpa. IN SOA alpha.pas.net. root.pas.net. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
200.168.192.in-addr.arpa. IN NS alpha.pas.net.
200.168.192.in-addr.arpa. IN NS beta.pas.net.
101 IN PTR alpha.pas.net.
102 IN PTR beta.pas.net.
199 IN PTR client.pas.net.

Rechargement des zones : 

alpha:/etc/bind# rndc reload


server reload successful
alpha:/etc/bind# tail /var/log/daemon.log
Jul 16 17:29:56 alpha named[4638]: loading configuration from ’/etc/bind/named.conf’
Jul 16 17:29:56 alpha named[4638]: using default UDP/IPv4 port range: [1024, 65535]
Jul 16 17:29:56 alpha named[4638]: using default UDP/IPv6 port range: [1024, 65535]
Jul 16 17:29:56 alpha named[4638]: reloading configuration succeeded
Jul 16 17:29:56 alpha named[4638]: reloading zones succeeded
Jul 16 17:29:56 alpha named[4638]: zone 200.168.192.in-addr.arpa/IN: loaded serial 2
Jul 16 17:29:56 alpha named[4638]: zone 200.168.192.in-addr.arpa/IN: sending
notifies (serial 2)
Jul 16 17:29:56 alpha named[4638]: zone pas.net/IN: loaded serial 2
Jul 16 17:29:56 alpha named[4638]: zone pas.net/IN: sending notifies (serial 2)
alpha:/etc/bind#

Vérification sur le serveur esclave avec dig : 

[root@beta named]# dig @127.0.0.1 client.pas.net

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @127.0.0.1 client.pas.net


; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27701
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;client.pas.net. IN A

;; ANSWER SECTION:
client.pas.net. 86400 IN A 192.168.200.199

- 10 - © ENI Editions - All rights reserved - Samuel CASAL


;; AUTHORITY SECTION:
pas.net. 86400 IN NS beta.pas.net.
pas.net. 86400 IN NS alpha.pas.net.

;; ADDITIONAL SECTION:
beta.pas.net. 86400 IN A 192.168.200.102
alpha.pas.net. 86400 IN A 192.168.200.101

;; Query time: 5 msec


;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 16 17:31:37 2010
;; MSG SIZE rcvd: 119

[root@beta named]#

Consultation des journaux sur le serveur esclave : 

[root@beta named]# tail /var/log/messages


Jul 16 17:30:54 beta named[1352]: client 192.168.200.102#58123:
received notify for zone ’pas.net’
Jul 16 17:30:54 beta named[1352]: zone pas.net/IN: refused notify
from non-master: 192.168.200.102#58123
Jul 16 17:30:58 beta named[1352]: client 192.168.200.101#26310:
received notify for zone ’200.168.192.in-addr.arpa’
Jul 16 17:30:58 beta named[1352]: zone 200.168.192.in-addr.arpa/IN: Transfer started.
Jul 16 17:30:59 beta named[1352]: transfer of ’200.168.192.in-
addr.arpa/IN’ from 192.168.200.101#53: connected using 192.168.200.102#55607
Jul 16 17:30:59 beta named[1352]: zone 200.168.192.in-addr.arpa/IN: transferred serial 2
Jul 16 17:30:59 beta named[1352]: transfer of ’200.168.192.in-
addr.arpa/IN’ from 192.168.200.101#53: end of transfer
Jul 16 17:30:59 beta named[1352]: zone 200.168.192.in-addr.arpa/IN:
sending notifies (serial 2)
Jul 16 17:30:59 beta named[1352]: client 192.168.200.102#62475:
received notify for zone ’200.168.192.in-addr.arpa’
Jul 16 17:30:59 beta named[1352]: zone 200.168.192.in-addr.arpa/IN:
refused notify from non-master: 192.168.200.102#62475
[root@beta named]#

© ENI Editions - All rights reserved - Samuel CASAL - 11 -


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Édition de fichiers texte.

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Configurer un serveur Apache basique.
Connaître les principales directives Apache. 
Connaître les principaux modules Apache. 
Configurer l’accès des utilisateurs à leurs pages personnelles.  
Configurer des hôtes virtuels. 
Configurer l’authentification des utilisateurs. 
Connaître les concepts des certificats numériques. 
Configurer un site web sécurisé en SSL. 
Connaître le fonctionnement d’un serveur proxy. 
Assurer une configuration basique du serveur proxy squid. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


 

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 - Samuel CASAL - 5-


- 6- © ENI Editions - All rights reserved - Samuel CASAL
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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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. 
Si  la  meilleure  méthode  est  sans  conteste  l’exploitation  de  la  directive  Directory,  il  est  (vivement)  recommandé  pour 
passer la certification LPI d’être familiarisé avec le concept des fichiers .htaccess. 

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 - Samuel CASAL


...

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 - Samuel CASAL - 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  et  leur  connaissance  précise  n’est  pas  requise  pour  la  certification  LPI.  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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


Validation des acquis 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Quel est l’intérêt du fonctionnement modulaire d’Apache ? 
2 Comment peut­on valider la syntaxe d’un ficher de configuration Apache sans pour autant démarrer le service ? 

3 Quelle source d’information est quasi indispensable à l’utilisation correcte des modules Apache et des directives 
de configuration de ces modules ? 
4 Dans la plupart des situations courantes d’un serveur avec hôtes virtuels, comment le serveur sait­il quel hôte 
virtuel est consulté parmi tous ceux disponibles ? 
5 Dans le cadre d’une authentification simple gérée localement par un serveur Apache, quelle commande permet 
de créer les comptes utilisateurs dans la base locale ? 
6 Que peut­on placer dans un fichier .htaccess ? 
7 En quoi les fichiers .htaccess sont ils dépendant dans leur fonctionnement de la directive AllowOverride ? 
8 Globalement, à quoi sert un certificat numérique X509 ? 
9 En quoi un serveur proxy traditionnel fonctionne­t­il en rupture de flux ? 
10 Dans un serveur proxy squid, est­il possible de positionner des acls squid dans des fichiers de définition 
annexes ? 

2. Réponses 

1 Quel est l’intérêt du fonctionnement modulaire d’Apache ? 
Au­delà du simple affichage de pages web, le serveur web Apache supporte des dizaines de fonctions complémentaires, 
certaines  courantes,  d’autres  marginales.  La  nature  modulaire  d’Apache  permet  de  ne  charger  que  les  modules 
nécessaires à son fonctionnement, et donc d’avoir un code exécutable chargé plus léger. 
2 Comment peut­on valider la syntaxe d’un ficher de configuration Apache sans pour autant démarrer le service ? 
En exécutant la commande apache avec l’option ­t. 
3 Quelle source d’information est quasi indispensable à l’utilisation correcte des modules Apache et des directives 
de configuration de ces modules ? 
Il est difficile de configurer correctement un serveur Apache complexe sans s’appuyer sur le site web de documentation 
officiel d’Apache. En premier lieu parce que ces directives sont innombrables : plus de 400 directives dans la version 
2.2 pour une bonne centaine de modules, et aussi parce qu’Apache est une matière vivante et que ces modules sont 
en perpétuelle évolution. 
4 Dans la plupart des situations courantes d’un serveur avec hôtes virtuels, comment le serveur sait­il quel hôte 
virtuel est consulté parmi tous ceux disponibles ? 
Le serveur consulte l’url demandée par le client et regarde sous quel nom le serveur a été sollicité. C’est la méthode la 
plus  courante,  utilisée  notamment  par  les  hébergeurs  et  les  fournisseurs  d’accès  qui  peuvent  héberger  sur  un  seul 
serveur physique plusieurs dizaines de sites web sous forme d’hôtes virtuels. 

5 Dans le cadre d’une authentification simple gérée localement par un serveur Apache, quelle commande permet 
de créer les comptes utilisateurs dans la base locale ? 
C’est la commande htpasswd, qui permet de créer, modifier et supprimer des comptes. Notez que cette commande est 
utile  dans  le  cadre  d’une  authentification  locale  simple,  qui  est  d’usage  dans  les  cas  les  plus  simples,  mais  qui  ne 
représente qu’une des nombreuses possibilités d’authentification disponibles avec Apache. 
6 Que peut on placer dans un fichier .htaccess ? 
Les  mêmes  directives  qu’on  aurait  pu  placer  dans  un  contexte  Directory.  La  configuration  se  trouve  alors  dans  un 
fichier localisé au plus près des données web plutôt que dans le fichier de configuration Apache. 
7 En quoi les fichiers .htaccess sont ils dépendants dans leur fonctionnement de la directive AllowOverride ? 
Il n’y a en principe pas de raison que le serveur Apache recherche dans chacun de ses répertoires un éventuel fichier 
de  configuration  complémentaire.  La  directive  AllowOverride  est  donc  nécessaire  pour  indiquer  que  l’on  accepte  la 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


possibilité d’une configuration complémentaire, et qu’il convient de rechercher systématiquement ce fichier. 

8 Globalement, à quoi sert un certificat numérique X509 ? 
À bien des choses dans les usages qu’on peut en faire mais dans son essence, un certificat numérique associe une 
identité  à  une  clé  publique.  Cette  identité  peut  être  une  référence  utilisateur,  un  nom,  une  adresse  IP,  etc.  Cette 
association  est  garantie  car  elle  est  signée  par  une  autorité  de  certification  à  laquelle  par  hypothèse  tout  le  monde 
accorde sa confiance. Si on devait trouver une analogie dans la vie courante, on pourrait parler d’une pièce d’identité qui 
associe un nom à une photo (clé publique), le tout étant signé par une autorité (la préfecture). 

9 En quoi un serveur proxy traditionnel fonctionne­t­il en rupture de flux ? 
Dans un fonctionnement avec serveur proxy (mandataire), le client s’adresse au serveur proxy en indiquant le serveur 
web cible. Le serveur proxy prend en compte la requête, et adresse à son tour une requête au serveur cible, mais en 
son nom. On a donc un flux de données du client vers le proxy, et un autre flux du proxy vers le serveur cible. Le proxy 
en profite au passage pour réaliser des opérations de filtrage, statistique, mise en cache, etc. 
10 Dans un serveur proxy squid, est­il possible de positionner des acls squid dans des fichiers de définition 
annexes ? 
Oui,  la  directive  acl  employée  dans  le  fichier  de  configuration  de  squid  peut  référencer  directement  un  paramètre 
réseau, ou désigner un fichier qui contient ce même paramètre. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 
Pour les besoins internes de l’entreprise, on vous demande de mettre en place deux serveurs web de type intranet. 
L’un  contiendra  des  données  accessibles  à  tous,  y  compris  aux  visiteurs  de  l’entreprise,  et  l’autre  contiendra  des 
données confidentielles et ne devra être accessible qu’aux seuls utilisateurs référencés. De plus, craignant les écoutes 
indiscrètes, on vous demande de faire en sorte qu’aucune capture de données sensibles ne soit possible sur le réseau. 
Vous devrez donc envisager une protection en SSL. 

Bien  que  disposant  de  deux  serveurs  physiques,  soucieux  d’économiser  vos  efforts,  vous  décidez  d’implémenter  les 
deux serveurs web sur un seul serveur physique. Votre choix se porte sur le serveur beta. 

1. Configuration d’un serveur web avec deux sites virtuels 

a. Gestion des noms DNS 

Vos sites web seront différenciés par l’URL utilisée pour y accéder. Il faut donc que deux noms différents référencent 
la même adresse IP. 

Commandes utiles

● rndc 

● vi 

Manipulations

1.  Créez dans le domaine DNS pas.net sur le serveur alpha deux enregistrements public et 
prive, de type CNAME, ayant pour cible beta.pas.net. 

2.  Incrémentez le numéro de version du fichier. 

3.  Rechargez la zone. 

4.  Alternativement : si votre serveur DNS n’est pas opérationnel, vous pouvez aussi créer 


deux entrées dans le fichier hosts de la station de travail. 

Résumé des commandes et résultat à l’écran

Fichier /etc/hosts sur client : 

127.0.0.1 localhost
192.168.200.102 public.pas.net prive.pas.net

Fichier /etc/bind/db.pas.net modifié sur alpha : 

$TTL 86400
pas.net. IN SOA alpha.pas.net. root.pas.net. (
8
604800
86400
2419200
86400 )

pas.net. IN NS alpha.pas.net
alpha.pas.net. IN A 192.168.200.101
beta.pas.net. IN A 192.168.200.102
serveur-a IN CNAME alpha.pas.net.
alfa IN CNAME alpha
public IN CNAME beta
prive IN CNAME beta

Rechargement des données de zone : 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


alpha:/etc/bind# rndc reload
server reload successful
alpha:/etc/bind#

b. Gestion des contenus 

Vous n’êtes pas en charge de la création du contenu des sites web. Vous créez donc deux contenus symboliques 
vous permettant de vérifier que l’accès aux différents sites est bien différencié. 

Commandes utiles

● mkdir 

● vi 

Manipulations

1.  Créez un répertoire /var/web/public pour le site web public. 

2.  Créez un répertoire /var/web/prive pour le site web privé. 

3.  Créez dans chacun de ces répertoires un fichier index.html selon le modèle suivant. Ces 
fichiers devront être identifiables afin qu’on sache si on est en site privé ou public. 

<html>
<body>
<h1>Contenu de site</h1>
</body>
</html>

Résumé des commandes et résultat à l’écran

[root@beta ~]# mkdir -p /var/web/public


[root@beta ~]# mkdir -p /var/web/prive
[root@beta ~]#
[root@beta ~]# echo "<html><body><h1>Contenu public - acces libre</h1></body></html>" >
/var/web/public/index.html
[root@beta ~]# echo "<html><body><h1>Contenu prive - acces controle</h1></body></html>" >
/var/web/prive/index.html
[root@beta ~]#

c. Génération d’un fichier de configuration simple 

La complexité du fichier de configuration fourni avec le paquetage applicatif vous impressionne un peu. Répugnant à 
faire des choses sans les comprendre, vous décidez de laisser ce fichier de côté pour l’instant et de faire tous vos 
essais de configuration avec un fichier créé de toutes pièces. L’exploitation du fichier standard pourra se faire par la 
suite une fois tous les essais réalisés. 
Votre objectif pour l’instant est de créer un serveur web qui réponde aux requêtes HTTP. 

Commandes utiles

● httpd 

● useradd 

● vi 

Directives apache utiles

- 2- © ENI Editions - All rights reserved - Samuel CASAL


● ServerRoot 

● User 

● Group 

● ErrorLog 

● Listen 

● DocumentRoot 

● LoadModule 

● DirectoryIndex 

● ServerName 

Manipulations

1.  Créez un compte utilisateur apache­user. 

2.  Créez un fichier /etc/httpd/httpd.conf. 

3.  Indiquez au serveur que la base de la configuration se trouvera dans le 
répertoire /etc/httpd. 

4.  Indiquez au serveur que les processus devront être détenus par le compte utilisateur 
apache­user. 

5.  Indiquez au serveur que les processus devront être détenus par le groupe apache­
user. 

6.  Indiquez au serveur que les erreurs devront être consignées dans un 
fichier /var/log/httpd/error.log. 

7.  Indiquez au serveur que l’écoute des requêtes entrantes doit se faire sur le port 80. 

8.  Indiquez au serveur que le contenu web se trouvera dans un 
répertoire /var/web/public/. 

9.  Indiquez au serveur que son nom principal est 192.168.200.102. 

10.  Indiquez au serveur qu’il doit charger le module /usr/lib/httpd/mod_dir.so sous le 
nom dir_module. 

11.  Indiquez au serveur que les fichiers index.html doivent être affichés par défaut même 
s’ils ne sont pas mentionnés dans l’URL. 

12.  Validez la syntaxe de votre fichier de configuration en précisant bien que c’est votre 
fichier que vous voulez tester et non le fichier d’exemple fourni avec le paquetage 
applicatif. 

13.  Démarrez le serveur web sans passer par le script de gestion de service et en précisant 
que vous utilisez votre fichier de configuration personnel (/etc/httpd/httpd.conf). 

14.  Testez l’accès depuis la station de travail. Selon le navigateur employé, il se peut que 
notre page web rudimentaire ne s’affiche pas très bien. Ne tenez compte que du 
contenu. 

Résumé des commandes et résultat à l’écran

Création du compte de service : 

[root@beta conf]# useradd apache-user


[root@beta conf]#

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Fichier /etc/httpd/httpd.conf 

ServerRoot /etc/httpd
User apache-user
Group apache-user
Errorlog /var/log/httpd/error.log.
Listen 80
DocumentRoot /var/web/public
ServerName 192.168.200.102
LoadModule dir_module modules/mod_dir.so
DirectoryIndex index.html

Validation de la syntaxe et démarrage du serveur : 

[root@beta httpd]# httpd -f /etc/httpd/httpd.conf -t


Syntax OK
[root@beta httpd]# httpd -f /etc/httpd/httpd.conf -k start
[root@beta httpd]# pgrep -l http
3530 httpd
3531 httpd
3532 httpd
3533 httpd
3534 httpd
3535 httpd
[root@beta httpd]#

d. Adaptation pour gestion de sites virtuels 

Encouragé par ce succès, vous décidez de mettre en place la gestion de sites virtuels afin que votre serveur renvoie 
des contenus différents selon le nom par lequel on y accède. 

Commandes utiles

● httpd 

● vi 

Directives apache utiles

● NameVirtualHost 

● VirtualHost 

Manipulations

1.  Arrêtez le démon httpd avant de modifier le fichier de configuration. 

2.  Indiquez au serveur qu’il va gérer des hôtes virtuels par noms sur toutes les interfaces 
possibles sur le port 80. 

3.  Créez deux structures de sites virtuels qui répondront sur toutes les interfaces 
possibles sur le port 80. 

4.  Renseignez pour chacun des sites virtuels le nom de serveur associé (public.pas.net et 
prive.pas.net). 

5.  Renseignez pour chacun des sites virtuels le répertoire de contenu web associé 
(/var/web/public et /var/web/prive). 

6.  Validez la syntaxe de votre fichier de configuration. 

7.  Démarrez le démon httpd avec votre fichier de configuration. 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


8.  Depuis le client, testez l’accès depuis un navigateur à l’url http://public.pas.net. 

9.  Depuis le client, testez l’accès depuis un navigateur à l’url http://prive.pas.net. 

Résumé des commandes et résultat à l’écran

Arrêt du démon httpd : 

[root@beta httpd]# httpd -f /etc/httpd/httpd.conf -k stop


[root@beta httpd]# pgrep -l http
[root@beta httpd]#

Fichier /etc/httpd/httpd.conf modifié : 

ServerRoot /etc/httpd
ServerName 192.168.200.102
User apache-user
Group apache-user
Errorlog /var/log/httpd/error.log.
Listen 80
DocumentRoot /var/web/public
LoadModule dir_module modules/mod_dir.so
directoryIndex index.html
NameVirtualHost *:80
<VirtualHost *:80>
ServerName public.pas.net
DocumentRoot /var/web/public
</VirtualHost>
<VirtualHost *:80>
ServerName prive.pas.net
DocumentRoot /var/web/prive
</VirtualHost>

2. Contrôle d’accès par mot de passe sur un site en ssl 

a. Génération des certificats 

Il  est  temps  maintenant  de  protéger  l’accès  au  site  privé  contre  les  écoutes  indiscrètes.  Vous  allez  créer  les 
certificats numériques nécessaires au fonctionnement SSL. Dans la mesure où il n’y a pas d’usage public de ce site 
web, il est possible d’utiliser des certificats générés localement (et gratuitement). 

Commandes utiles

● openssl 

Manipulations

1.  Dans le répertoire /etc/httpd, générez deux fichiers beta.cle et certificat.pem 
correspondant respectivement à la clé privée du serveur beta et à sa clé publique sous 
forme de certificat auto­signé. Les clés générées doivent être de 1024 bits et le nom 
associé au certificat sera impérativement prive.pas.net. 

Résumé des commandes et résultat à l’écran

[root@beta httpd]# openssl req -x509 -nodes -newkey rsa:1024


-keyout beta.cle -out certificat.pem
Generating a 1024 bit RSA private key
...................++++++
..++++++
writing new private key to ’beta.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.

© ENI Editions - All rights reserved - Samuel CASAL - 5-


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) [GB]:FR
State or Province Name (full name) [Berkshire]:Trifouillis
Locality Name (eg, city) [Newbury]:lezois
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server’s hostname) []:prive.pas.net
Email Address []:
[root@beta httpd]#

b. Configuration SSL 

Commandes utiles

● vi 

Directives utiles

● Listen 

● LoadModule 

● NameVirtualHost 

● SSLCertificateFile 

● SSLCertificateKeyFile 

● SSLEngine 

Manipulations

1.  Indiquez au serveur qu’il doit charger le module mod_ssl.so sous le nom ssl_module. 

2.  Indiquez au serveur qu’il doit utiliser le fichier certificat.pem en tant que certificat à 
présenter aux navigateurs. 

3.  Indiquez au serveur qu’il doit utiliser le fichier beta.cle en tant que fichier de clé privée. 

4.  Indiquez au serveur qu’il va gérer un hôte virtuel aussi sur le port 443. 

5.  Indiquez au serveur que le site virtuel privé est désormais accessible sur le port 443. 

6.  Indiquez au serveur qu’il doit écouter sur le port 443 et activez le fonctionnement SSL 
pour le site virtuel privé. 

7.  Rechargez le service Apache. 

8.  Testez l’accès en SSL depuis la station cliente Ubuntu. Ne vous laissez pas 
impressionner par l’avertissement de sécurité. Dites que vous comprenez les risques, 
ajoutez une exception, obtenez le certificat et enfin confirmez l’exception de sécurité. 

Résumé des commandes et résultat à l’écran

Fichier httpd.conf modifié : 

(...)
NameVirtualHost *:80

- 6- © ENI Editions - All rights reserved - Samuel CASAL


<VirtualHost *:80>
ServerName public.pas.net
DocumentRoot /var/web/public
</VirtualHost>
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on
ServerName prive.pas.net
DocumentRoot /var/web/prive
</VirtualHost>
LoadModule ssl_module modules/mod_ssl.so
SSLCertificateFile certificat.pem
SSLCertificateKeyFile beta.cle
Listen 443

c. Gestion de l’authentification 

Enfin, l’accès au site privé étant protégé en SSL, il ne reste plus qu’à protéger l’accès à la partie confidentielle par 
une  authentification  par  mot  de  passe.  Pour  vos  premiers  essais,  vous  décidez  de  configurer  ce  contrôle  d’accès 
pour  un  seul  répertoire  (/var/web/prive/auth)  et  de  placer  les  directives  de  configuration  dans  un  fichier 
caché .htaccess dans ce répertoire. 

Commandes utiles

● chmod 

● chown 

● htpasswd 

● vi 

Directives utiles

● AuthName 

● AuthType 

● AuthUserFile 

● LoadModule 

● Require 

Manipulations

1.  Créez un fichier de mots de passe Apache /etc/httpd/mdp avec un compte utilisateur 
valide. 

2.  Affectez ce fichier aux seuls comptes et groupes de service Apache. 

3.  Gérez les droits sur ce fichier pour qu’aucun autre compte utilisateur n’y ait accès. 

4.  Indiquez au serveur qu’il doit charger le module /usr/lib/httpd/mod_auth_basic.so 
sous le nom auth_basic_module. 

5.  Indiquez au serveur qu’il doit charger le module /usr/lib/httpd/mod_authz_user.so 
sous le nom authz_user_module. 

6.  Indiquez au serveur qu’il doit charger le module /usr/lib/httpd/mod_authn_file.so 
sous le nom authn_file_module. 

© ENI Editions - All rights reserved - Samuel CASAL - 7-


7.  Dans le répertoire à protéger (/var/web/prive/auth), créez un fichier .htaccess 
contenant les directives nécessaires à l’authentification par fichier de mots de passe. 

8.  Rechargez le service Apache. 

9.  Testez l’accès au site protégé depuis la station cliente Ubuntu. Vous devez vous 
connecter en SSL, et subir une demande d’authentification. 

Résumé des commandes et résultat à l’écran

Gestion du fichier de mots de passe : 

[root@beta httpd]# htpasswd -c /etc/httpd/mdp toto


New password: ********
Re-type new password: ********
Adding password for user toto
[root@beta httpd]#
[root@beta httpd]# chown apache-user:apache-user mdp
[root@beta httpd]# chmod 440 mdp
[root@beta httpd]#
[root@beta httpd]# ls -l mdp
-r--r----- 1 apache-user apache-user 19 aoû 2 10:46 mdp
[root@beta httpd]# cat mdp
toto:2.eT/SXrEPV3E
[root@beta httpd]#

Ajouts au fichier httpd.conf : 

(...)
LoadModule ssl_module modules/mod_ssl.so
SSLCertificateFile certificat.pem
SSLCertificateKeyFile beta.cle
Listen 443

LoadModule auth_basic_module modules/mod_auth_basic.so


LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authn_file_module modules/mod_authn_file.so

Fichier .htaccess : 

authType basic
AuthName "Veuillez vous identifier"
Require valid-user
AuthUserFile /etc/httpd/mdp

3. Mise en place d’un serveur proxy sur le serveur alpha 

Après  avoir  géré  les  serveurs  web,  il  est  temps  de  vous  occuper  des  clients.  Pour  protéger  et  optimiser  le 
fonctionnement  de  la  navigation  internet,  vous  décidez  d’implémenter  un  serveur  proxy  sur  le  serveur  alpha.  Ce 
serveur répond à deux objectifs : mettre en cache les données fréquemment consultées et interdire l’accès à un site 
de jeux en ligne qui fait fureur actuellement dans l’entreprise. 

a. Installation des binaires 

Installez le serveur squid sur alpha avec la commande suivante : 

apt-get install squid

b. Configuration de base 

Afin  de  parfaitement  maîtriser  votre  implémentation,  vous  décidez  encore  une  fois  de  créer  un  fichier  de 
configuration de toutes pièces. 

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Commandes utiles

● chown 

● mkdir 

● mv 

● vi 

Directives utiles

● cache_dir 

● http_port 

● visible_hostname 

Manipulations

1.  Créez un répertoire /var/proxy qui contiendra les données mises en cache. 

2.  Affectez ce répertoire au compte de service squid. 

3.  Dans le répertoire /etc/squid, créez une copie de sauvegarde du fichier squid.conf 
sous le nom ini.squid.conf. 

4.  Créez un nouveau fichier /etc/squid/squid.conf. 

5.  Indiquez dans le nouveau fichier de configuration que le proxy recevra les requêtes 
clients sur le port 8080. 

6.  Indiquez que le répertoire de cache sera /var/proxy avec comme taille maximum 500 
Mo, 16 répertoires de premier niveau de cache et 256 répertoires de second niveau de 
cache. 

7.  Indiquez que le nom du serveur proxy qui apparaîtra dans les fichiers journaux est 
prox. 

8.  Ne démarrez pas le service pour le moment. 

Résumé des commandes et résultat à l’écran

Création du répertoire de cache : 

alpha:~# mkdir /var/proxy


alpha:~# chown proxy /var/proxy
alpha:~# ls -ld /var/proxy
drwxr-xr-x 2 proxy root 4096 aoû 3 10:32 /var/proxy
alpha:~#

Copie de sauvegarde du fichier de configuration : 

alpha:/etc/squid# pwd
/etc/squid
alpha:/etc/squid# ls
squid.conf
alpha:/etc/squid# mv squid.conf ini.squid.conf
alpha:/etc/squid#

Nouveau fichier squid.conf : 

http_port 8080
cache_dir ufs /var/proxy 500 16 256

© ENI Editions - All rights reserved - Samuel CASAL - 9-


visible_hostname prox

c. Déclaration et autorisation des acls 

Si  malgré  nos  avertissements  vous  avez  essayé  de  lancer  le  service  proxy,  vous  devez  avoir  eu  un  message 
d’erreur indiquant que l’acl all n’était pas définie. En effet, même si on ne souhaite pas gérer de filtrage d’aucune 
sorte, l’acl all au moins doit être définie. 
Vous allez donc maintenant déclarer l’acl et indiquer que tout trafic est autorisé pour tout le monde, et une acl fun 
pour indiquer l’adresse IP du serveur de jeux en ligne interdit. 

Directives utiles

● acl 

● http_access 

Manipulations

1.  Déclarez l’acl all correspondant à toutes les sources possibles. 

2.  Configurez le navigateur de la station de travail afin qu’il exploite le serveur alpha en 
tant que serveur mandataire. 

3.  Démarrez le service squid sur alpha. 

4.  Testez l’accès à un site quelconque depuis le client et constatez que vous n’allez nulle 
part. 

5.  Indiquez que tout trafic correspondant à l’acl all est autorisé. 

6.  Redémarrez le service squid sur alpha. 

7.  Testez l’accès à un site quelconque depuis le client et constatez que cela fonctionne 
beaucoup mieux. 

8.  Déclarez l’acl fun correspondant à l’adresse IP d’un site interdit en destination. 

9.  Interdisez tout trafic correspondant à l’acl fun. 

10.  Redémarrez le service squid sur alpha. 

Résumé des commandes et résultat à l’écran

Fichier squid.conf modifié : 

http_port 8080
cache_dir ufs /var/proxy 100 16 256
visible_hostname prox

acl fun dst 12.34.56.78


acl all src all
http_access deny fun
http_access allow all

Démarrage du service : 

alpha:/etc/squid# /etc/init.d/squid stop


Stopping Squid HTTP proxy: squid.
alpha:/etc/squid# /etc/init.d/squid start
Starting Squid HTTP proxy: squidCreating squid cache structure (warning).
2010/09/02 00:05:38| Creating Swap Directories
.
alpha:/etc/squid#

d. Validation fonctionnelle 

- 10 - © ENI Editions - All rights reserved - Samuel CASAL


Configurez le navigateur de la station cliente pour qu’elle exploite le proxy installé sur alpha avec le port 8080. 

1.  Depuis le navigateur Firefox, déroulez le menu Editions et cliquez sur Préférences. 

2.  Cliquez sur l’onglet Avancé et sur le sous­onglet Réseau. Cliquez sur le bouton 
Paramètres. 

3.  Sélectionnez la configuration manuelle du proxy avec comme proxy HTTP l’adresse IP du 
serveur alpha, et le port 8080. 

4.  Naviguez normalement. 

5.  Essayez une connexion sur l’url http://12.34.56.78 et vérifiez que le proxy squid vous la 
refuse. 

© ENI Editions - All rights reserved - Samuel CASAL - 11 -


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Édition de fichiers.
Savoir configurer un client de messagerie. 

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Connaître le fonctionnement de l’envoi de courrier sur internet.
Connaître les principaux MTA. 
Assurer une configuration simple de Postfix. 
Configurer des domaines virtuels avec Postfix. 
Configurer les MDA courrier­pop et courrier­imap. 
Connaître le MDA Dovecot. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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.  Une  connaissance  sommaire  de  cette 
commande est nécessaire pour la certification LPI. 

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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


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 

La configuration complète de procmail dépasse le champ des objectifs de la certification LPI niveau 2 et donc de cet 
ouvrage, mais quelques exemples de configuration simples peuvent être appliqués sans difficulté. 

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é. 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


Exemples de règle dans le fichier ~/.procmailrc 

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 - Samuel CASAL


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.  La  certification  LPI  prévoit  de  connaître  les  serveurs  courrier­pop,  courrier­
imap, 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 - Samuel CASAL - 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 dont il faut connaître l’existence pour la certification LPI. Il a été 
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 - Samuel CASAL


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 - Samuel CASAL - 3-


Validation des acquis 
Testez vos connaissances en répondant aux questions suivantes. Ces questions n’appellent pas toujours des réponses 
définitives.  Les  questions  posées  en  certification,  bien  qu’abordant  les  mêmes  sujets,  seront  pour  la  plupart  posées 
sous  forme  de  questionnaire  à  choix  multiples,  ou  bien  demanderont  une  réponse  courte,  tapée  en  toutes  lettres  au 
clavier. 

1. Questions 

1 Dans le fonctionnement d’un serveur de messagerie de type MTA, qu’appelle­t­on généralement un alias ? 
2 Postfix supporte un paramètre relayhost. Dans quelle circonstance son usage peut­il devenir obligatoire ? 

3 Est­il possible avec postfix de gérer un domaine de messagerie au sein du réseau local mais de présenter à 
l’extérieur un autre nom de domaine plus présentable ? 
4 Quand un serveur postfix reçoit un message, comment sait­il qu’il doit le traiter personnellement et non le 
relayer ? 
5 Peut­on vérifier la validité de la configuration d’un serveur postfix sans avoir à démarrer le service ? 

6 Dans la syntaxe SMTP ou quand on envoie un message avec la commande mail, comment indique­t­on qu’on a 
terminé la rédaction du message ? 
7 Comment peut­on automatiser un traitement sur les messages entrants sur un MTA ? 
8 Si un administrateur veut envoyer un message urgent à tous les utilisateurs connectés en mode console (local, 
telnet ou ssh), dispose­t­il d’une alternative à l’envoi d’un message en SMTP ? 
9 Quelle différence y a­t­il entre le contenu du fichier /etc/issue et du fichier /etc/motd ? 

10 Est­il possible de valider une authentification auprès des serveurs courier (Courier­POP et Courier­IMAP) sans 
avoir à configurer un client de messagerie ? 

2. Réponses 

1 Dans le fonctionnement d’un serveur de messagerie de type MTA, qu’appelle­t­on généralement un alias ? 
C’est  l’association  d’une  identité  avec  un  compte  existant.  Par  exemple,  on  doit  en  général  pouvoir  envoyer  un 
message  à  l’adresse  de  service  webmaster@site.com.  Pour  dispenser  le  webmaster  de  consulter  à  la  fois  sa  boîte 
personnelle et la boîte webmaster, on crée un alias entre les deux identités. 
2 Postfix supporte un paramètre relayhost. Dans quelle circonstance son usage peut­il devenir obligatoire ? 
La généralisation des spams a un peu compliqué l’envoi de messages sur internet par le protocole SMTP. Si l’adresse IP 
publique  attribuée  à  une  organisation  par  son  fournisseur  d’accès  a  un  passé  douteux,  il  se  peut  que  l’adresse  en 
question  soit  blacklistée  et  donc  rejetée  par  les  MTA  des  correspondants.  Remettre  tout  message  sortant  à  son 
fournisseur  d’accès  qui  se  chargera  de  l’envoyer  est  une  solution  intéressante  si  on  ne  souhaite  pas  engager  une 
procédure de retrait des blacklists de l’adresse IP. 

3 Est­il possible avec postfix de gérer un domaine de messagerie au sein du réseau local mais de présenter à 
l’extérieur un autre nom de domaine plus présentable ? 
Oui, il faut pour cela renseigner la directive myorigin dans le fichier de configuration de postfix. C’est un comportement 
courant, par exemple quand une entreprise change de nom. 
4 Quand un serveur postfix reçoit un message, comment sait­il qu’il doit le traiter personnellement et non le 
relayer ? 
Il compare le domaine de destination annoncé (les caractères qui suivent l’arobase) avec ceux définis par la directive 
mydestination  dans  le  fichier  de  configuration  de  postfix.  Si  c’est  la  même  chose,  le  serveur  postfix  sait  qu’il  est 
compétent pour traiter le message. 

5 Peut­on vérifier la validité de la configuration d’un serveur postfix sans avoir à démarrer le service ? 
Oui, avec la commande postfix check. Il est également possible d’afficher  les  paramètres  effectifs  de  la  configuration 
avec la commande postconf ­n. 

6 Dans la syntaxe SMTP ou quand on envoie un message avec la commande mail, comment indique­t­on qu’on a 
terminé la rédaction du message ? 
En écrivant une ligne formée d’un seul point. Le point doit être le caractère unique sur la ligne, immédiatement validé 
par un retour chariot. 
7 Comment peut­on automatiser un traitement sur les messages entrants sur un MTA ? 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


En  appelant  la  commande  de  gestion  procmail.  procmail  doit  être  référencé  dans  le  fichier  de  configuration  postfix  et 
possède lui aussi son propre fichier de règles. 
8 Si un administrateur veut envoyer un message urgent à tous les utilisateurs connectés en mode console (local, 
telnet ou ssh), dispose­t­il d’une alternative à l’envoi d’un message en SMTP ? 
Oui, la très vieille commande wall est là pour ça. Elle envoie un message texte à tous les utilisateurs connectés. On 
l’emploie fréquemment avant de redémarrer un système ou d’arrêter un service. 
9 Quelle différence y a­t­il entre le contenu du fichier /etc/issue et du fichier /etc/motd ? 
Tous deux sont affichés à un utilisateur se connectant, mais /etc/issue est affiché avant l’ouverture de session, et est 
donc visible à tous, alors que le contenu du fichier /etc/motd n’est visible qu’après une ouverture de session réussie. 
10 Est­il possible de valider une authentification auprès des serveurs courier (Courier­POP et Courier­IMAP) sans 
avoir à configurer un client de messagerie ? 
Oui, la commande authtest permet cette validation. Elle ne présage pas d’un succès fonctionnel complet en production, 
mais du moins vérifie­t­on que les bibliothèques d’authentification courier sont présentes et correctement configurées. 

- 2- © ENI Editions - All rights reserved - Samuel CASAL


Travaux pratiques 
Afin de parfaire la communication dans l’entreprise, on vous demande de mettre en place un service de messagerie. 

1. Gestion des envois 

a. Installation d’un serveur postfix sur le serveur alpha 

Installez un serveur postfix sur le serveur alpha en tapant la commande suivante : 

apt-get install postfix

Si  l’assistant  d’installation  vous  pose  des  questions,  choisissez  « Pas  de  configuration  »  pour  indiquer  que  vous 
souhaitez réaliser l’ensemble de la configuration par vous­même. 
Notez  que  l’installation  de  postfix  entraîne  la  suppression  du  service  de  messagerie  natif  Exim  des  distributions 
Debian. 

b. Configuration du service 

Commandes utiles

● postconf 

● postfix 

● tail 

● vi 

Fichier utile

● main.cf 

Manipulations

1.  Dans le répertoire /etc/postfix, créez un fichier main.cf. 

2.  Dans le fichier main.cf, indiquez que vos mails proviendront du domaine pas.net. 

3.  Dans le fichier main.cf, indiquez que votre serveur gère les mails à destination du 
domaine pas.net. 

4.  Dans le fichier main.cf, indiquez l’adresse de votre réseau local. 

5.  Vérifiez les paramètres effectifs de votre configuration postfix. 

6.  Vérifiez la cohérence de votre configuration postfix. 

7.  Démarrez le service et vérifiez que tout s’est bien passé. 

Résumé des commandes et résultat à l’écran

Fichier de configuration /etc/postfix/main.cf : 

myorigin = pas.net
mydestination = pas.net
mynetwork = 192.168.200.0/24

© ENI Editions - All rights reserved - Samuel CASAL - 1-


Vérification des paramètres effectifs : 

alpha:/etc/postfix# postconf -n
config_directory = /etc/postfix
mydestination = pas.net
myorigin = pas.net
alpha:/etc/postfix#

Vérification de la cohérence de la configuration : 

alpha:/etc/postfix# postfix check


alpha:/etc/postfix#

Démarrage du service et vérification : 

alpha:/etc/postfix# /etc/init.d/postfix start


Starting Postfix Mail Transport Agent: postfix.
alpha:/etc/postfix# tail -1 /var/log/syslog
Aug 12 15:30:43 alpha postfix/master[5008]: daemon started --
version 2.5.5, configuration /etc/postfix
alpha:/etc/postfix#

c. Gestion des alias postfix 

Commandes et fichiers utiles

● /etc/aliases 

● postalias 

Manipulations

1.  Vérifiez la présence du fichier d’alias par défaut. 

2.  Créez la base d’alias que devra utiliser le service postfix après son démarrage. 

Résumé des commandes et résultat à l’écran

alpha:~# cat /etc/aliases


# /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
alpha:~#
alpha:~# postalias /etc/aliases
alpha:~#

d. Intégration DNS 

Afin  qu’on  puisse  envoyer  des  messages  depuis  d’autres  MTA,  vous  décidez  de  créer  un  enregistrement  MX  pour 
référencer votre domaine. 

Commandes utiles

- 2- © ENI Editions - All rights reserved - Samuel CASAL


● rndc 

● vi 

Manipulations

1.  Créez dans le domaine DNS pas.net sur le serveur alpha un enregistrement MX de 
priorité 10 avec comme MTA le nom alpha.pas.net. 

2.  Incrémentez le numéro de version du fichier. 

3.  Rechargez la zone. 

Résumé des commandes et résultat à l’écran

Fichier /etc/bind/db.pas.net modifié sur alpha: 

$TTL 86400
pas.net. IN SOA alpha.pas.net. root.pas.net. (
15
604800
86400
2419200
86400 )

pas.net. IN NS alpha.pas.net.
pas.net. IN NS beta.pas.net.
alpha.pas.net. IN A 192.168.200.101
beta.pas.net. IN A 192.168.200.102
serveur-a IN CNAME alpha.pas.net.
alfa IN CNAME alpha
client IN A 192.168.200.212
public IN CNAME beta
prive IN CNAME beta
pas.net. IN MX 10 alpha.pas.net.

Rechargement des données de zone : 

alpha:/etc/bind# rndc reload


server reload successful
alpha:/etc/bind#

e. Envoi et réception de mails en lignes de commande depuis le serveur alpha 

Commandes utiles

● adduser 

● mail 

● su 

Manipulations

1.  Sur le serveur alpha, créez un utilisateur titi avec le mot de passe password. 

2.  Sur le serveur alpha, ouvrez un terminal en tant que l’utilisateur toto. 

3.  Envoyez un mail à l’utilisateur titi. 

4.  Ouvrez un autre terminal en tant que l’utilisateur titi. 

© ENI Editions - All rights reserved - Samuel CASAL - 3-


5.  Vérifiez vos messages. 

Résumé des commandes et résultat à l’écran

Ajout de l’utilisateur titi sur alpha : 

alpha:~# adduser titi


Ajout de l’utilisateur « titi »...
Ajout du nouveau groupe « titi » (1002)...
Ajout du nouvel utilisateur « titi » (1002) avec le groupe « titi »...
Création du répertoire personnel « /home/titi »...
Copie des fichiers depuis « /etc/skel »...
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l’utilisateur titi
Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée
Nom complet []: titi
N° de bureau []:
Téléphone professionnel []:
Téléphone personnel []:
Autre []:
Ces informations sont-elles correctes ? [O/n]
alpha:~#

Envoi d’un mail par l’utilisateur toto : 

toto@alpha:~$ whoami
toto
toto@alpha:~$
toto@alpha:~$ mail titi
Subject: Salut
Juste pour voir si ca marche.

.
Cc:
toto@alpha:~$

Vérification de la réception du mail par l’utilisateur titi : 

toto@alpha:~$ whoami
toto
toto@alpha:~$ su - titi
Mot de passe :
titi@alpha:~$ whoami
titi
titi@alpha:~$ mail
Mail version 8.1.2 01/15/2001. Type ? for help.
"/var/mail/titi": 1 message 1 new
>N 1 toto@pas.net Thu Aug 12 15:17 15/428 Salut
& 1
Message 1:
From toto@pas.net Thu Aug 12 15:17:30 2010
X-Original-To: titi
To: titi@pas.net
Subject: Salut
Date: Thu, 12 Aug 2010 15:17:30 +0200 (CEST)
From: toto@pas.net (toto)

Juste pour voir si ca marche.

& q
Saved 1 message in /home/titi/mbox
titi@alpha:~$

f. Passage de postfix au format maildir 

- 4- © ENI Editions - All rights reserved - Samuel CASAL


Fichier et commandes utiles

● /etc/postfix/main.cf 

● vi 

Manipulations

1.  Dans votre fichier de configuration, déclarez l’usage du format maildir. 

2.  Redémarrez le service. 

Résumé des commandes et résultat à l’écran

Fichier main.cf modifié : 

myorigin = pas.net
mydestination = pas.net
mynetwork = 192.168.200.0/24

home_mailbox = Maildir/

Redémarrage du service : 

alpha:/etc/postfix# /etc/init.d/postfix restart


Stopping Postfix Mail Transport Agent: postfix.
Starting Postfix Mail Transport Agent: postfix.
alpha:/etc/postfix#
alpha:/etc/postfix# tail -1 /var/log/syslog
Aug 12 15:49:43 alpha postfix/master[5101]: daemon started --
version 2.5.5, configuration /etc/postfix
alpha:/etc/postfix#

2. Gestion des retraits 

a. Installation d’un serveur Courier­IMAP sur le serveur alpha 

Installez un serveur Courier­IMAP sur alpha en tapant la commande suivante : 

alpha:~# apt-get install courier-imap


Lecture des listes de paquets... Fait
Construction de l’arbre des dépendances
Lecture des informations d’état... Fait
Les paquets supplémentaires suivants seront installés :
courier-authdaemon courier-authlib courier-authlib-userdb courier-base
expect tcl8.4
(...)

Acceptez tous les choix par défaut lors de l’exécution de l’assistant d’installation. 

b. Envoi d’un message à l’utilisateur toto 

L’envoi de ce message nous servira à vérifier la bonne configuration du serveur IMAP. 

Commandes utiles

● mail 

● su 

© ENI Editions - All rights reserved - Samuel CASAL - 5-


Manipulations

1.  Sur le serveur alpha, ouvrez un terminal en tant que l’utilisateur titi. 

2.  Envoyez un mail en lignes de commandes à l’utilisateur toto. 

Résumé des commandes et résultat à l’écran

Envoi du mail en lignes de commandes : 

alpha:~# su - titi
titi@alpha:~$ whoami
titi
titi@alpha:~$ mail toto
Subject: Salut toto
Ca marche avec le client de messagerie ?
.
Cc:
titi@alpha:~$

c. Gestion du courrier depuis le poste de travail 

Afin  de  tester  le  fonctionnement  du  serveur  imap,  vous  allez  configurer  un  client  de  messagerie  sur  la  station  de 
travail. 

La  suite  logicielle  Evolution  est  le  client  de  messagerie  par  défaut  mais  vous  pouvez  utiliser  n’importe  quel  client 
imap. 

Commandes utiles

● Utilisation de l’interface graphique. 

Manipulations

1.  Sur la station de travail, lancez le logiciel Evolution à partir du menu 
Application/Bureautique. 

2.  Utilisez tous les paramètres par défaut, à l’exception de l’identité de l’utilisateur (toto), 
le serveur IMAP (adresse IP ou nom DNS du serveur alpha), et le serveur SMTP (adresse 
IP ou nom DNS du serveur alpha). 

3.  Vérifiez qu’un message apparaît bien dans la fenêtre d’évolution. 

Résumé des commandes et résultat à l’écran

Configuration du logiciel évolution : 

- 6- © ENI Editions - All rights reserved - Samuel CASAL


Gestion de l’identité 

© ENI Editions - All rights reserved - Samuel CASAL - 7-


Configuration du serveur IMAP 

- 8- © ENI Editions - All rights reserved - Samuel CASAL


Configuration du serveur SMTP 

Envoi d’un mail depuis le compte titi : 

alpha:~# su - titi
titi@alpha:~$ mail toto
Subject: test 2
bla
.
Cc:
titi@alpha:~$

Visualisation des messages sur Evolution : 

© ENI Editions - All rights reserved - Samuel CASAL - 9-


 

Notez  que  bien  que  le  mail  ait  été  envoyé  à «  toto  », il  apparaît  comme  émanant  de  «  toto@pas.net  ». C’est  le 
résultat de la bonne configuration de postfix (paramètre myorigin). 

- 10 - © ENI Editions - All rights reserved - Samuel CASAL


Pré­requis et objectifs 

1. Pré­requis 

Les connaissances acquises lors de la certification LPI niveau 1, notamment : 
 
Connaissances de base sur l’adressage IP.
Connaissances de base sur le routage IP.  
Édition de fichiers texte. 
Connaissances de fichier /etc/services. 
Connaissances de base du démon inetd.  

2. Objectifs 

À la fin de ce chapitre, vous serez en mesure de : 
 
Activer le routage sur un serveur Linux.
Ajouter et retirer des routes statiques.  
Configurer du filtrage par les iptables. 
Configurer du NAT par les iptables. 
Configurer un pare­feu Linux à partir des iptables. 
Afficher la configuration d’un pare­feu existant. 
Modifier la configuration d’un pare­feu existant. 
Connaître les principaux organismes de veille sécuritaire. 
Connaître les techniques d’analyse des IPS.  
Connaître l’IDS Snort. 
Connaître la suite logicielle de sécurité OpenVAS. 

© ENI Editions - All rights reserved - Samuel CASAL - 1-


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 - Samuel CASAL - 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 - Samuel CASAL


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 - Samuel CASAL - 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 - Samuel CASAL


-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
alpha:~#

© ENI Editions - All rights reserved - Samuel CASAL - 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éfin