LINUX Preparation A La Certification LPI PDF

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 LPIC2 examens LPI 201 et LPI
202
Les examens LPI 201 et LPI 202 sont les deux examens qui permettent d’obtenir la certification LPIC2 "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 ciaprès :
● Une définition des objectifs à atteindre : permet d’exposer précisément les compétences données par le
chapitre une fois celuici 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, audelà 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.

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

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 savoirfaire. 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 sousjacents, 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
seraitce 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 sousré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

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

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/getubuntu/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.

■ Choisissez le fichier iso du système Debian.
■ Répétez l’opération pour les autres fichiers images.
3. Installation du serveur alpha
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 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
■ 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’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 popularitycontest, 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 consolesetup, 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

optiques de la machine virtuelle.
4. Installation du serveur beta
■ 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 Supports/Attributs, déroulez le menu Lecteur optique et choisissez le cdrom virtuel CentOS.
Validez.

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

5. Installation de la station de travail
■ 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 Supports/Attributs, déroulez le menu Lecteur optique et choisissez le cdrom virtuel Ubuntu.
Validez.
■ Dans l’écran Install, sélectionnez Français dans le panneau de gauche et cliquez sur Installer Ubuntu.

■ 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.
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 Disque virtuel, emplacement et taille, donnez un nom facilement identifiable à votre fichier de

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

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.

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

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

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 cidessus pour les commandes mkfs et fsck sont universelles et doivent fonctionner.
Toutefois, il faut savoir que ces commandes appellent en réalité des sousprogrammes (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
vérifier.
La différence entre le format ext2 et ext3 est la présence ou non d’un journal des transactions. La commande
tune2fs permet d’ajouter un journal à un filesystem ext2, et donc de le convertir en ext3.
Affichage des paramètres d’un filesystem en ext3

Notez que la mention has_journal figure dans la section Filesystem features, ce qui indique un filesystem de type ext3.
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
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

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èscoup 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 cidessus, device représente le fichier spécial en mode bloc qui représente le périphérique
hébergeant le filesystem sur lequel on intervient. Par exemple /dev/sda3.
2. Gestion du swap
a. Pourquoi le swap et en quelle quantité?
Le swap ou mémoire virtuelle est un espace de stockage exploité pour palier à un manque de mémoire physique sur
le système. Quand la mémoire physique vient à manquer pour les applications, une partie des informations stockées
en mémoire et n’ayant pas fait l’objet d’une utilisation récente est déplacée sur l’espace de swap, libérant ainsi de
l’espace pour les applications qui ont un besoin immédiat de mémoire. Si des applications ont besoin des
informations qui ont été basculées sur l’espace de swap, le mécanisme de swap est à nouveau engagé pour libérer
encore de l’espace en mémoire physique, espace dans lequel les données swappées à nouveau nécessaires seront
restituées pour exploitation par les applications.
Il ne faut pas se tromper sur l’utilisation qui doit être faite du swap. En fonctionnement ordinaire, un serveur ou une
station se travail Linux ne devrait pas avoir à swapper. La grande époque du swap était celle où la mémoire coûtait
si cher qu’il fallait trouver pour l’équipement d’un serveur un compromis entre le coût d’un système et les
performances qu’il pouvait offrir. Aujourd’hui, les coûts relativement bas de la mémoire font qu’un système ne devrait
avoir à swapper qu’en cas de surconsommation accidentelle de mémoire. Le swap est donc en quelque sorte une
mémoire de secours qui évite de planter un serveur en attendant la mise en adéquation entre les besoins en
mémoire et les ressources disponibles.
La quantité de swap est souvent sujette à caution et selon les auteurs, les sources et les époques. Il est difficile au
moment de l’installation non automatique d’un système de faire un choix serein. Un consensus semble se déterminer
autour de valeurs comprises entre une et deux fois la quantité de RAM. De toute façon, les installations par défaut

des distributions proposent généralement la création d’un espace de swap automatiquement. Pour une installation
sur mesure, les valeurs courantes (une à deux fois la RAM) sont parfaitement acceptables, et dans le doute, l’espace
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é sousdimensionné à
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
Désignations possibles des espaces de stockage pour la commande swapon

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

/dev/sda3 partition 10112908 2024
-1

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.

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

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, positionnezvous 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"
0:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
0:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
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 ringbuffer du
noyau.
Utilisation de dmesg pour identifier les disques durs
Il est vivement recommandé de filtrer la sortie de la commande dmesg, celleci étant par nature assez bavarde.
alpha:~# dmesg | grep [sh]d

[ 0.000000] Kernel command line: root=/dev/hda1 ro quiet
[ 3.136965] hda: VBOX HARDDISK, ATA DISK drive
[ 3.822425] hda: host max PIO4 wanted PIO255(auto-tune)
selected PIO4
[ 3.822677] hda: UDMA/33 mode selected
[ 4.575784] hdc: VBOX CD-ROM, ATAPI CD/DVD-ROM drive

[ 5.275977] hdc: host max PIO4 wanted PIO255(auto-tune)
selected PIO4
[ 5.275977] hdc: UDMA/33 mode selected
[ 7.203721] hda: max request size: 128KiB
[ 7.203728] hda: 16777216 sectors (8589 MB) w/256KiB Cache,
CHS=16644/16/63
[ 7.204020] hda: cache flushes supported
[ 7.204020] hda: hda1 hda2 < hda5 >
[ 7.234912] hdc: ATAPI 32X DVD-ROM drive, 128kB Cache
[ 7.257272] Driver ’sd’ needs updating - please use bus_type methods
[ 7.257525] sd 0:0:0:0: [sda] 4194304 512-byte hardware sectors
(2147 MB)
[ 7.257620] sd 0:0:0:0: [sda] Write Protect is off
[ 7.257627] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7.257769] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn’t support DPO or FUA
(...)
Récupération d’informations sur un périphérique par la commande udevadm
Le service udev peut aussi nous fournir des informations précieuses par le biais de sa commande d’administration
udevadm.
alpha:~# udevadm info --query=all --name=/dev/hda

P: /block/hda
N: hda
S: block/3:0
S: disk/by-id/ata-VBOX_HARDDISK_VBf92d3e4d-7faf607b
S: disk/by-path/pci-0000:00:01.1-ide-0:0
E: ID_TYPE=disk
E: ID_MODEL=VBOX_HARDDISK
E: ID_SERIAL=VBf92d3e4d-7faf607b
E: ID_REVISION=1.0
E: ID_BUS=ata
E: ID_PATH=pci-0000:00:01.1-ide-0:0
Surveillance d’événements par la commande udevmonitor (ou udevadm monitor)
On peut surveiller quasiment en temps réel les événements système.
toto@ubuntu:~$ udevmonitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1276268963.339194] change
/devices/pci0000:00/0000:00:14.1/host4/target4:0:0/4:0:0:0 (scsi)
KERNEL[1276268963.339804] change
/devices/pci0000:00/0000:00:14.1/host4/target4:0:0/4:0:0:0/block/sr0 (block)
(...)
Visualisation des paramètres de périphériques avec lsdev
La commande lsdev permet de récupérer des informations sur les périphériques reconnus, notamment les valeurs DMA,
IRQ et I/O. Ces valeurs sont lues dans les fichiers /proc/interrupts, /proc/ioports, et /proc/dma.
toto@ubuntu:~$ lsdev
Device DMA IRQ I/O Ports
------------------------------------------------
0000:00:01.1 0170-0177 01f0-01f7 0376-0376 03f6-03f6
d000-d00f
0000:00:03.0 d020-d03f
0000:00:04.0 d040-d05f
0000:00:05.0 d100-d1ff d200-d23f
82801AA-ICH 5
ACPI 4000-4003 4004-4005 4008-400b 4020-4021

ata_piix 14 15 0170-0177 01f0-01f7 0376-0376 03f6-03f6
d000-d00f
cascade 4 2
eth0 10
floppy 2 6 03f2-03f2 03f4-03f5 03f7-03f7
vga+ 03c0-03df
toto@ubuntu:~$
Récupération d’informations du répertoire /dev/disk
Enfin, on trouve sous le répertoire /dev/disk les éléments de stockage apparaissant selon la façon dont ils sont reconnus
et identifiés par le système.
root@serveur:/dev/disk$ ls
by-id by-label by-path by-uuid
root@serveur:/dev/disk$ cd by-uuid
root@serveur:/dev/disk/buy-uuid$ ls
52200c0b-aee8-4ae0-9492-1f488051e4a3 B0F82CDCF82CA318
b0891c0e-1812-4d23-b77d-b861f7fd2713 ee7890fb-c312-406f-b100-669c97ee8d07
root@serveur:/dev/disk/by-uuid$ file *
52200c0b-aee8-4ae0-9492-1f488051e4a3: symbolic link to `../../sda2’
b0891c0e-1812-4d23-b77d-b861f7fd2713: symbolic link to `../../sdb1’
B0F82CDCF82CA318: symbolic link to `../../sda1’
ee7890fb-c312-406f-b100-669c97ee8d07: symbolic link to `../../sda3’
root@serveur:/dev/disk/by-uuid$
c. Gestion des performances avec hdparm
La commande hdparm permet de consulter et configurer de nombreux paramètres du disque dur, certains d’ailleurs
dangereux pour le disque.
Visualisation des paramètres fonctionnels avec hdparm
alpha:~# hdparm /dev/hda

/dev/hda:
multcount = 0 (off)
IO_support = 0 (default)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16644/16/63, sectors = 16777216, start = 0
Si le matériel le supporte, les paramètres fonctionnels du disque peuvent être modifiés avec l’option appropriée
suivie d’un paramètre numérique, en général 0 ou 1. Les options les plus courantes sont c (activation ou
désactivation de l’accès 32 bits au disque) et d (activation ou désactivation de l’accès DMA). Une option demandée
sans valeur numérique associée entraine l’affichage de la valeur courante.
Consultation de l’accès 32 bits
alpha:~# hdparm -c /dev/hda

/dev/hda:
IO_support = 0 (default)
Consultation puis suppression de la lecture anticipée
alpha:~# hdparm -a /dev/hda

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

readahead = 0 (off)
Visualisation, activation et désactivation de l’accès DMA
alpha:~# hdparm -d /dev/hda

/dev/hda:
using_dma = 0 (off)
alpha:~# hdparm -d 1 /dev/hda
/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.

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.

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 copyout. 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 copyin. Indique qu’on est en mode d’extraction ou de consultation
d’archive. Exclusif de l’option o.

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.

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

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

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

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

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

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

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.

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, ellemê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

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.

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

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

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

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

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

LV Name /dev/vg1/clicclac
VG Name vg1
LV UUID xyakf0-2zMf-B3qG-S9gT-KTqw-ZJI3-W06GWi
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

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

LV Name /dev/vg1/clicclac
VG Name vg1
LV UUID xyakf0-2zMf-B3qG-S9gT-KTqw-ZJI3-W06GWi
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
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#

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 estil nécessaire de créer un filesystem pour exploiter un espace de stockage sur disque ?
2 Combien d’espace disque les filesystems virtuels ou pseudofilesystems peuventils 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 estil difficile de vérifier la cohérence du filesystem racine monté sur / ?
6 En quoi la commande lsdev estelle dépendante de pseudofilesystems ?
7 Pourquoi les options de compression de la commande tar devraientelles ê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écessitetelle 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 estil 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 pseudofilesystems peuventils 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 estil 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
ellesmê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 estelle dépendante de pseudofilesystems ?
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 pseudofilesystems sont
riches en informations utiles.
7 Pourquoi les options de compression de la commande tar devraientelles être réservées aux sauvegardes sur

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

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

alpha:~# swapon -s
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

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.
Activation de l’espace de swap :
alpha:~# swapon /swap

alpha:~#
Vérification par deux commandes différentes :
alpha:~# swapon -s
/swap file 524280 0 -2
/swap file 524280 0 -2
alpha:~#
c. Référencement dans fstab
Commandes utiles

● 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.
Fichier /etc/fstab modifié :

#
# <file system> <mount point> <type> <options> <dump> <pass>
/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 :

/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

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

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

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

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
LV Name /dev/volgrp/documentation
VG Name volgrp
LV UUID xIYS6m-mq88-13br-wbp7-sp5B-iN2b-wA1GEk
LV Status available
# open 0
LV Size 1,00 GB
Current LE 256
Segments 1
Allocation inherit
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 modifiezle plutôt en un filesystem ext3.
3. Affectezlui le label « documentation ».
4. Vérifiez.
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

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é

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

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

#
# <file system> <mount point> <type> <options> <dump> <pass>
/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

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
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é sousdimensionné. 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é.
Vérification de la taille du volume logique :
alpha:/dev# lvdisplay /dev/volgrp/documentation

VG Name volgrp
LV Status available
# open 1
LV Size 1,00 GB
Current LE 256
Segments 1
Allocation inherit
Block device 253:0
Vérification de la taille du filesystem monté :
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#
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
VG Name volgrp
LV Status available
# open 1
LV Size 3,00 GB
Current LE 768
Segments 1
Allocation inherit
Block device 253:0
alpha:/dev#
Vérification de la taille du filesystem monté :

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

Manipulations
1. Démontez le filesystem.
2. Vérifiez son intégrité.
3. Redimensionnezle avec la commande resize2fs.
4. Montezle et vérifiez la nouvelle taille.
Démontage du filesystem et vérification de son intégrité :

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
3,0G 34M 2,8G 2% /documentation
alpha:/dev#

1. Prérequis

Affichage des processus et de leurs identifiants.
Édition de fichiers.
2. Objectifs

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.

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’estce 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.

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

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èreplan. 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
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
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.

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

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

[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 updaterc.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/rc2.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

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.

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

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

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 livecd par exemple.
3. Réinstallation de GRUB
a. Réinstallation simple depuis un système actif
La commande grubinstall 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 grubinstall
grub-install --root-directory=rep_noyau disque_cible
grubinstall : 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

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 livecd et de réaliser la réinstallation de GRUB depuis ce livecd. La
distribution choisie pour le livecd 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 livecd 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 ».

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.

Validation des acquis : questions/réponses
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 estelle 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 fautil
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 estelle maintenue pour que le gestionnaire de démarrage GRUB retrouve toujours sa
configuration dans le même fichier ?

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

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.

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

● 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).
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#
alpha:/etc/rc0.d# cd ../rc1.d
alpha:/etc/rc1.d#
alpha:/etc/rc2.d#
Création du lien de démarrage en niveau 3 :
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/rc5.d#
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é.

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.
Vérification du niveau en cours :
alpha:~# runlevel
N 2
alpha:~#
Vérification de la nonexé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

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
● updaterc.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).
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/rc3.d/S95surveillemem
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

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 ringbuffer 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.
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):

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.

[~]# shutdown -h now
b. Création de la machine virtuelle clone
Créez une nouvelle machine virtuelle appelée clone. Affectezlui le disque clonehd que vous aurez auparavant
retiré de la machine virtuelle alpha, et conservez toutes les valeurs par défaut.
Mettezla 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émarrezla. 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.
[~]# 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.

1. Prérequis

Connaissances générales réseaux et modèle OSI.
Connaissances sommaire du démon syslog.
2. Objectifs

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 WiFi.
Capturer des trames sur le réseau.
Configurer un serveur DHCP basique.
Configurer une réservation DHCP.
Exploiter un client DHCP.

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 cidessous, 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.
sousinterface Nom arbitraire de la sousinterface. Chaîne de caractères quelconque.
adresse_ip Adresse IP à affecter à la machine.
masque Valeur du masque de sousré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

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 sousréseau associé à la route ajoutée.
Un serveur Linux utilisé en tant que routeur supporte aussi les principaux protocoles de routage. Le logiciel

historique routed supporte uniquement le protocole de routage RIP, alors que la suite logicielle plus moderne
quagga permet d’exploiter la quasitotalité 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/networkscripts.
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.

adresse_ip Adresse IP à affecter à l’interface.
masque Masque de sousré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 euxmê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/networkscripts
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/networkscripts. Ces fichiers ont tous le préfixe ifcfg suivi
du nom de l’interface à configurer.
Format du fichier ifcfginterface pour une adresse IP statique
DEVICE=interface
BOOTPROTO=none
ONBOOT=yes
IPADDR=adresse_ip
NETMASK=masque
GATEWAY=ip_passerelle
Format du fichier ifcfginterface 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 sousré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.

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

00:00:00:01:02:06 192.168.199.36
alpha:~# arp -f
alpha:~# arp -n
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 WiFi
Les distributions et les bureaux graphiques fournissent des utilitaires graphiques pour l’administration des réseaux
WiFi dont l’utilisation est intuitive. Nous allons donc voir ici comment configurer pas à pas une connexion WiFi en
lignes de commandes. Les principaux outils seront ifconfig, iwconfig, et iwlist.
a. Détermination de l’interface WiFi

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 WiFi 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 WiFi avec iwconfig
Toutes les interfaces renvoyant une référence à 802.11 sont des interfaces WiFi. 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 WiFi, 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 WPATKIP. Le deuxième provient d’un point d’accès dont l’adresse MAC est CA:9D:2E:E6:B7:56, émettant
aussi en 802.11g, avec le ssid hotspot et sans aucune sécurité.
toto@ubuntu:~$ sudo iwlist eth1 scan

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

c. Connexion à un réseau non sécurisé
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 WiFi gérée par le système, et nom_ssid le nom du réseau WiFi (Service

Set Identifier) auquel on souhaite se connecter.

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

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

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.

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 sousjacents.
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 clientserveur ou de la gestion du réseau par le système ellemê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.

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...
(Device Prepare) started...
(Device Configure) scheduled...
(Device Prepare) complete.
(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.
(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. Motsclés principaux : host, port, src, dest.

Exemple d’utilisation de tcpdump
L’exemple cidessous 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 multiplateforme 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.

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

Configuration automatique avec DHCP
1. Le protocole DHCP
DHCP (Dynamic Host Configuration Protocol) est un protocole clientserveur 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 nonrecevoir 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

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
defaultleasetime 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.
logfacility 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.

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 sousréseau. En cas de
conflit entre options (la même option est déclarée dans la configuration générale et dans la section subnet), c’est
l’option du subnet qui prévaut.
Déclaration de subnet dans le fichier dhcpd.conf
subnet reseau netmask masque {

range debut fin;
option routers routeur;
dhcpd.conf : déclaration de subnet
reseau L’adresse de réseau dans lequel se trouveront les adresses à attribuer.
masque Masque associé au réseau géré.
debut Définition de la plage des adresses qui seront proposées aux clients. La première
adresse de la plage.
fin Définition de la plage des adresses qui seront proposées aux clients. La dernière
adresse de la plage.
routeur La passerelle par défaut associée aux adresses proposées.
d. Paramètres spécifiques à une machine
Il est possible d’affecter spécifiquement à une machine des options particulières. Cette machine fera alors l’objet
d’une déclaration particulière avec la directive host, un peu comme on configurerait un subnet à une seule adresse.
On pourra utiliser cette méthode pour affecter spécifiquement à un hôte du réseau une adresse IP fixe pour une
machine qui, bien que client DHCP, devrait systématiquement utiliser la même adresse. On peut par exemple
imaginer une imprimante réseau dont l’interface de configuration peu confortable encourage à la laisser en
configuration dynamique, et pour laquelle la réservation dhcp garantirait l’attribution de l’adresse voulue.
Réservation d’adresse dans dhcpd.conf
host machine {
hardware ethernet adresse-mac;
fixed-address adresse_ip;
option routers routeur;
option domain-name suffixe;
option domain-name-servers serveur_dns;
}
dhcpd.conf : configuration d’hôte
machine Déclaration de paramètres pour un hôte. Si l’identification par adresse mac est

utilisée, le nom machine est sans importance.
adressemac 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/dhcp3server.
f. Visualisation des baux dhcp
Le serveur DHCP conserve une information sur chacun des baux alloués dans un fichier dhcpd.leases se trouvant
dans le répertoire /var/lib/dhcp/.
Ce fichier est accessible à la consultation mais ne devrait pas être modifié.
Exemple de fichier dhcpd.leases
Notez les horaires de renouvellement et d’expiration du bail DHCP.
lease {
interface "eth0";
fixed-address 192.168.1.51;
option subnet-mask 255.255.255.0;
option routers 192.168.1.254;
option dhcp-lease-time 864000;
option dhcp-message-type 5;
option domain-name-servers 194.2.0.20,194.2.0.50;
option dhcp-server-identifier 192.168.1.1;
renew 6 2010/07/10 14:55:34;
rebind 3 2010/07/14 14:33:58;
expire 4 2010/07/15 20:33:58;
}
3. Configuration du client
La commande dhclient permet aux stations clientes d’effectuer les requêtes DHCP. Si la commande n’est pas lancée
manuellement par un administrateur, elle est appelée par les scripts d’initialisation réseau. Si la station client ne
possède pas d’adresse IP, elle effectue toutes les étapes de la procédure de requête DHCP. Dans le cas contraire,
elle demande au serveur un renouvellement de bail. dhclient peut également être utilisée pour libérer une adresse
affectée précédemment par un serveur DHCP.
Exemple d’utilisation de dhclient pour requérir une adresse
Notez les étapes de l’affectation d’adresse DHCPDISCOVER, DHCPOFFER, DHCPREQUEST et DHCPACK.
root@serveur# dhclient eth1

Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth1/00:22:68:98:8a:da
Sending on LPF/eth1/00:22:68:98:8a:da
Sending on Socket/fallback
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPOFFER of 172.18.142.243 from 172.18.142.225

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

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.

Validation des acquis
clavier.
1. Questions
1 Quelle commande permet de lier une adresse IP secondaire à une interface ?
2 Si une machine a deux interfaces réseau, fautil configurer une deuxième passerelle par défaut ?
3 Quel intérêt y atil à 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 sontils résolus ?
5 La commande ifconfig renvoietelle des informations sur une connexion WiFi ?
6 Pourquoi estil 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 peuton trouver le nom du fichier en
question et l’utilisateur qui l’a ouvert ?
8 Pour quel usage la bibliothèque logicielle libpcap s’estelle 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 faitelle 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 sousré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, fautil 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 atil à 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 sontils 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 renvoietelle des informations sur une connexion WiFi ?
Pas vraiment. La commande ifconfig donnera des informations sur toutes les interfaces présentes sur un système, y
compris les interfaces WiFi. 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 WiFi, et même de la configurer.
6 Pourquoi estil 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

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 peuton 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’estelle 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 faitelle 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.

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.
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:~#

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

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

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.
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 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)
toto@station:~$ ifconfig eth0

eth0 Link encap:Ethernet HWaddr 00:22:25:d7:97:e6
adr inet6: fe80::222:15ff:fed7:97e6/64 Scope:Lien
Packets reçus:301626 erreurs:0 :0 overruns:0 frame:0
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 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.

Directives utiles
● fixedaddress
● 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;
}
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.

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
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
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
Octets reçus:24613918 (24.6 MB) Octets transmis:482889 (482.8 KB)
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

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

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.

1. Prérequis

Connaître la structure du fichier /etc/passwd.
Connaître l’existence et le principe du fichier hosts.
2. Objectifs

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.

É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

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.

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

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.

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 cidessous, 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 motsclé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.

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
gdmautologin 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 sousfichier commonauth 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 gdmautologin 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

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

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.

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

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étaannuaires 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"

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

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
# 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=*)

-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

# filter: telephoneNumber=*
# requesting: ALL
#
# tata, paris, pas.net

dn: cn=tata,ou=paris,dc=pas,dc=net
objectClass: person
cn: tata
sn: tata
# tutu, paris, pas.net

dn: cn=tutu,ou=paris,dc=pas,dc=net
objectClass: person
cn: tutu
sn: tutu
# 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

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

-h 172.17.7.20 -s sub -b dc=pas,dc=net cn=tata
# extended LDIF
#
# LDAPv3
# filter: cn=tata
# requesting: ALL
#
# tata, paris, pas.net

dn: cn=tata,ou=paris,dc=pas,dc=net
objectClass: person
cn: tata
sn: tata
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


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 à miparcours est la
bienvenue.
root@station:/etc$ getent passwd titi

titi:*:1101:1101:titi:/home/titi/bin/bash
root@station:/etc$
2. Configuration PAM

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

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 atil un paramètre dns dans le fichier /etc/nsswitch.conf ?
3 En quoi l’arrivée de PAM atelle 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 passetil 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) estelle 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 Existetil 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, conserveton 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 atil 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 atelle 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

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 passetil 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étaannuaires) 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) estelle 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 Existetil 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, conserveton 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.

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 remplacezle 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.
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"
Affectation du mot de passe administrateur dans le fichier /etc/openldap/slapd.conf

[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
Vérification :
[root@beta openldap]# grep rootpw slapd.conf

# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
rootpw {SSHA}/qNLfdcQeazSkiX6O4rKm8kL/E73iFyu
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 ]
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

réponse de l’annuaire (même si à ce stade l’annuaire n’a pas de contenu).
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...
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
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
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"

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: person
uid: titi
cn: titi
sn: titi
uidNumber: 602
gidNumber: 1000
homeDirectory: /home/titi
userPassword: password
[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"
f. Interrogation d’un annuaire peuplé
Commandes utiles
● ldapsearch

Manipulations
1. Depuis le serveur beta, faites une requête visant à obtenir la totalité des données de
l’annuaire.
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
# requesting: ALL
#
# pas.net
dn: dc=pas,dc=net
objectClass: domain
dc: pas
# toto, pas.net
objectClass: top
objectClass: person
uid: toto
cn: toto
sn: toto
givenName: toto
uidNumber: 601
gidNumber: 1000
homeDirectory: /home/toto
userPassword:: cGFzc3dvcmQ=
(...)
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.

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
# extended LDIF
#
# LDAPv3
# requesting: ALL
#
# pas.net
dn: dc=pas,dc=net
objectClass: domain
dc: pas
# toto, pas.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

# extended LDIF
#
# LDAPv3
# 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

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
● /etc/ldap.conf
● /etc/nsswitch.conf
● getent
Manipulations
1. Dans le fichier nsswitch.conf, ajoutez le motclé 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.
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 postinstallation et la configuration doit déjà
être fonctionnelle. La distribution Ubuntu étant un peu avantgardiste, nous allons remettre les paramètres pam
aux valeurs standard attendues par la certification LPI.
● /etc/pam.d/commonaccount

● /etc/pam.d/commonauth
Manipulations
1. Dans le fichier /etc/pam.d/commonauth, constatez la présence d’une ligne pour le
module pam_unix et déclarezla comme étant sufficient.
2. Dans le fichier /etc/pam.d/commonauth, constatez la présence d’une ligne pour le
module pam_ldap (ou ajoutezla) et déclarezla comme étant sufficient.
3. Dans le fichier /etc/pam.d/commonaccount, constatez la présence d’une ligne pour le
module pam_unix et déclarezla comme étant sufficient.
4. Dans le fichier /etc/pam.d/commonaccount, constatez la présence d’une ligne pour le
module pam_ldap (ou ajoutezla) et déclarezla 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/commonsession 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/commonauth :
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/commonaccount :
account sufficient pam_unix.so

account sufficient pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so
Fichier /etc/pam.d/commonsession :
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.

1. Prérequis

Montage de filesystems.
2. Objectifs

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.

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

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

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

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

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 euxmê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
[section2]
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

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.

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

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.

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

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 sousprogramme. 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 sousprogramme smbmount pour réaliser le montage, mais à partir d’une
syntaxe quasistandard 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.

Partage de fichiers avec FTP
1. Le protocole FTP
a. Historique
FTP : File Transfer Protocol est un protocole clientserveur 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 parefeu ne va pas sans poser de problème dans la mesure
où il est vu par le parefeu 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 platesformes. 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

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 PureFTPd
PureFTPd 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 pureftpd avec l’option anonymousonly.
c. Options de fonctionnement
Pureftpd 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 cidessous
présente certaines des options les plus courantes.
pureftpd : 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

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.

clavier.
1. Questions
1 Comment les clients en lignes de commande accèdentils aux données d’un partage, qu’il soit de type NFS ou
Samba ?
2 Estil 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 estelle 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 Estil 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 Peuton synchroniser les mots de passe Unix avec les mots de passe SAMBA ?
10 Pourquoi le mode actif s’estil progressivement raréfié au profit du mode passif sur les clients FTP ?
2. Réponses
1 Comment les clients en lignes de commande accèdentils 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 Estil 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 estelle 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, nfkkernelserver 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 Estil 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 ?

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 Peuton 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’estil 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 parefeu 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 parefeu.

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 « fourretout » 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.
Paramètres explicites :
alpha:/etc/samba# testparm
Load smb config files from /etc/samba/smb.conf
[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

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

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
● 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.
Création du répertoire :
alpha:/home/toto# mkdir /public

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

Section de partage dans smb.conf :
[public]
path = /public
writeable = yes
browseable = yes
directory mask = 0777
Validité de la syntaxe :
alpha:/public# testparm
Processing section "[public]"
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.
Sur la station de travail Ubuntu, installez la couche applicative NFS par la commande suivante :

sudo apt-get install nfs-common
Les services NFS doivent déjà être installés sur le serveur beta.
b. Configuration du partage
● /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.
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]#

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/.
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 pureftpd par la commande suivante :
apt-get install pure-ftpd
b. Configuration et lancement du service
Commandes utiles
● adduser
● chmod
● passwd
● pureftpd

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

4. Essayez de voir le contenu du répertoire.
5. Envoyez votre fichier vers le serveur.
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:~$

1. Prérequis

Savoir éditer des fichiers texte.
Avoir des connaissances générales IP.
2. Objectifs

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.

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.
nomdemachine <> 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 « sousbases » (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 sousarborescences des tld.

Dans l’exemple cidessus, la zone france contient les souszones rhone, nord et idf. Mais on peut aussi dire que la
zone « . » contient les souszones 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.

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 : donnemoi 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 : donnemoi 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èdestu 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.

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 INADDR.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 « .inaddr.arpa ».
Résolutions dans la zone 1.168.192.inaddr.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.inaddr.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 cidessous 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

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

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
Cidessous 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 "sousfichier" de configuration. Évite d’avoir un fichier
named.conf trop grand pour être administré confortablement.
options Conteneur pour certains motsclé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.

Exemple de fichier named.conf sur une distribution Debian :
Notez la déclaration des zones par défaut, ainsi que l’appel de deux sousfichiers 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";
};
type master;
};
type master;
};
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 luimê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.

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

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é cidessous. 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’entê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 email 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

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 « .inaddr.arpa ». Par exemple, la zone inverse pour le réseau 192.168.99.0 sera :
99.168.192.inaddr.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’entête
nomzoneinv Nom normalisé de la zone inverse : subnetinversé.inaddr.arpa. Où subnetinversé
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.

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.
valeurrésolue Ce à quoi on fait correspondre le nom. Dans le cas d’un enregistrement de type A,
une adresse IP.
adressehô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

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

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
b. nslookup
nslookup est l’outil le plus populaire pour l’interrogation des serveurs DNS. Il est présent sur la grande majorité des
platesformes 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.

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

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.

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

Sécurisation du DNS
1. Limitation des clients
Il est possible de limiter les requêtes autorisées. La directive allowquery 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éseauxautorisé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.

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.

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’emails. 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 : dnsseckeygen. Il a de nombreux usages, mais nous le verrons ici dans le
cadre d’une exploitation TSIG.
Syntaxe dnsseckeygen pour utilisation dans le cadre de TSIG
dnssec-keygen -a HMAC-MD5 -b taillecle -n nametype nomsecret
dnsseckeygen : variables et paramètres
a HMACMD5 a définit la méthode de cryptage. HMACMD5 est la seule valeur supportée pour
TSIG.
b taillecle b définit la valeur de la clé employée. Pour HMACMD5, 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 dnsseckeygen

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

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

clavier.
1. Questions
1 Pourquoi existetil 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élioretil le fonctionnement global d’un réseau ?
4 Comment installer le composant resolver DNS sur un système Linux standard ?
5 Peuton se passer de la directive include dans le fichier named.conf ?
6 Comment un serveur DNS local au sein d’une entreprise peutil tirer parti du cache d’un serveur plus sollicité
comme celui de son fournisseur d’accès par exemple ?
7 Comment peuton 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 estil indispensable d’avoir une communication possible entre le
serveur délégant et le serveur délégué ?
2. Réponses
1 Pourquoi existetil 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élioretil 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 Peuton 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 peutil 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 luimê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 peuton 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

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 estil 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 soustraiter 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.

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

query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
alpha:~#
c. Configuration des clients
● /etc/resolv.conf
● vi
Manipulations
1. Modifiez la configuration du serveur alpha afin qu’il s’interroge luimê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.
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.

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

// 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; };
};
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.inaddr.arpa. Ces fichiers
devront déclarer A comme serveur maître pour ces zones. L’adresse mail du contact administratif sera
root@pas.net.
● 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.
Fichier /etc/bind/pas.net :
$TTL 86400
pas.net. IN SOA alpha.pas.net. root.pas.net. (
1
604800
86400
2419200
86400 )

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.
● 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.
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";
};
alpha:/etc/bind# /etc/init.d/bind9 restart

Stopping domain name service...: bind9.
Starting domain name service...: bind9.
alpha:/etc/bind#

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.
● 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 serveura 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.
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.inaddr.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

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 serveura.pas.net.
4. Demandez le nom correspondant à l’adresse 192.168.200.102.
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.
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:
;beta.pas.net. IN A
;; ANSWER SECTION:
beta.pas.net. 86400 IN A 192.168.200.102

pas.net. 86400 IN NS alpha.pas.net.
;; ADDITIONAL SECTION:
alpha.pas.net. 86400 IN A 192.168.200.101

;; SERVER: 192.168.200.101#53(192.168.200.101)
;; WHEN: Fri Jul 16 16:06:25 2010
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.
● 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.inaddr.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.
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/

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]#
[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.
● 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.

Fichier de zone directe modifié :
$TTL 86400
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
pas.net. IN NS beta.pas.net.
beta.pas.net. IN A 192.168.200.102
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# 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:
;client.pas.net. IN A
;; ANSWER SECTION:
client.pas.net. 86400 IN A 192.168.200.199

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

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 16 17:31:37 2010
[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
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)
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]#

1. Prérequis

Édition de fichiers texte.
2. Objectifs

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.

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/WindowsApacheMySQLPHP), 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

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

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

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

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
alpha:~#
On constate la présence d’un processus exécuté par root, et de trois autres par le compte de service wwwdata. 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.

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ûtil 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.

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.

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 validuser Directive imposant un fonctionnement spécifique avec son paramètre validuser 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 validuser 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

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

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

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=*
# extended LDIF
#
# LDAPv3
# base <dc=annu,dc=fr> with scope subtree
# requesting: ALL
#
# annu.fr
dn: dc=annu,dc=fr
objectClass: domain

dc: annu
(...)
# toto, users.annu.fr
dn: uid=toto,ou=users,dc=annu,dc=fr
objectClass: top
objectClass: person
(...)
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
Require valid-user
AuthUserFile /etc/httpd/mdp
</Directory>

...
Contenu du fichier /var/www/prot/.htaccess utilisé pour configurer une authentification depuis le répertoire des données
html :
authType basic
Require valid-user
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.

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 caslà, 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.

Génération du certificat autosigné
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 autosigné 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 cidessus 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

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ù certificatca 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.

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 parefeu pour cette fonction car le proxy « comprend » ce qui est
demandé (une URL), alors que le parefeu 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

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

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 sousrépertoires de premier niveau maximum du répertoire de cache.
Valeur par défaut : 16.
rep_niveau_2 Nombre de sousré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.DE.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.

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.

clavier.
1. Questions
1 Quel est l’intérêt du fonctionnement modulaire d’Apache ?
2 Comment peuton 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 saitil 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 peuton 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 fonctionnetil en rupture de flux ?
10 Dans un serveur proxy squid, estil 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 ?
Audelà 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 peuton 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 saitil 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

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 fonctionnetil 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, estil 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.

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.
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
8
604800
86400
2419200
86400 )
pas.net. IN NS alpha.pas.net
beta.pas.net. IN A 192.168.200.102
alfa IN CNAME alpha
public IN CNAME beta
prive IN CNAME beta
Rechargement des données de zone :

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

● ServerRoot
● User
● Group
● ErrorLog
● Listen
● DocumentRoot
● LoadModule
● DirectoryIndex
● ServerName
Manipulations
1. Créez un compte utilisateur apacheuser.
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
apacheuser.
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.
Création du compte de service :
[root@beta conf]# useradd apache-user

[root@beta conf]#

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

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.
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
LoadModule dir_module modules/mod_dir.so
directoryIndex index.html
<VirtualHost *:80>
ServerName public.pas.net
</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 autosigné. Les clés générées doivent être de 1024 bits et le nom
associé au certificat sera impérativement prive.pas.net.
[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.

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é.
Fichier httpd.conf modifié :
(...)

<VirtualHost *:80>
ServerName public.pas.net
</VirtualHost>
<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.

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.
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
Require valid-user
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.

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

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

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

1. Prérequis

Savoir configurer un client de messagerie.
2. Objectifs

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 courrierpop et courrierimap.
Connaître le MDA Dovecot.

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.

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.

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

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 cidessus, 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.

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.

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.

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

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 sousrépertoires : tmp, new et cur. Les messages sont

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’entête seulement, B
pour le corps du message.
condition Expression régulière permettant d’isoler les mails correspondant à la règle.
action Que faire du message sélectionné.

Exemples de règle dans le fichier ~/.procmailrc
Dans l’exemple cidessous, la recherche s’effectue sur l’entê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 sousré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.

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 courrierpop, 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 entê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 horsligne.
2. Serveurs CourierIMAP et CourierPOP
Les serveurs courierpop et courierimap 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 courierpop et courierimap 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.

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 CourierPOP ou de CourierIMAP, 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
Jusquelà 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 clientserveur 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 clientserveur 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

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

clavier.
1. Questions
1 Dans le fonctionnement d’un serveur de messagerie de type MTA, qu’appelleton généralement un alias ?
2 Postfix supporte un paramètre relayhost. Dans quelle circonstance son usage peutil devenir obligatoire ?
3 Estil 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 saitil qu’il doit le traiter personnellement et non le
relayer ?
5 Peuton 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 indiqueton qu’on a
terminé la rédaction du message ?
7 Comment peuton 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), disposetil d’une alternative à l’envoi d’un message en SMTP ?
9 Quelle différence y atil entre le contenu du fichier /etc/issue et du fichier /etc/motd ?
10 Estil possible de valider une authentification auprès des serveurs courier (CourierPOP et CourierIMAP) sans
avoir à configurer un client de messagerie ?
2. Réponses
1 Dans le fonctionnement d’un serveur de messagerie de type MTA, qu’appelleton 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 peutil 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 Estil 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 saitil 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 Peuton 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 indiqueton 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 peuton automatiser un traitement sur les messages entrants sur un MTA ?

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), disposetil 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 atil 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 Estil possible de valider une authentification auprès des serveurs courier (CourierPOP et CourierIMAP) 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érifieton que les bibliothèques d’authentification courier sont présentes et correctement configurées.

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 vousmê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é.
Fichier de configuration /etc/postfix/main.cf :
myorigin = pas.net
mydestination = pas.net
mynetwork = 192.168.200.0/24

Vérification des paramètres effectifs :
alpha:/etc/postfix# postconf -n
config_directory = /etc/postfix
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
● /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.
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

● 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.
Fichier /etc/bind/db.pas.net modifié sur alpha:
$TTL 86400
15
604800
86400
2419200
86400 )
pas.net. IN NS beta.pas.net.
beta.pas.net. IN A 192.168.200.102
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#
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.

5. Vérifiez vos messages.
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

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.
Fichier main.cf modifié :
myorigin = 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 CourierIMAP sur le serveur alpha
Installez un serveur CourierIMAP 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

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.
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.
Configuration du logiciel évolution :

Gestion de l’identité

Configuration du serveur IMAP

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 :

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

1. Prérequis

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

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 parefeu Linux à partir des iptables.
Afficher la configuration d’un parefeu existant.
Modifier la configuration d’un parefeu 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.

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

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
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 sousré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 quasitotalité 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
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

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
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 cidessous exposent les concepts fondamentaux des iptables, afin de les utiliser
plus tard dans des configurations de parefeu.
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
estelle sousentendue 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.

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)

Chain OUTPUT (policy ACCEPT)

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

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
alpha:~#

Administration d’un parefeu avec les iptables
1. Politiques
a. Principe des politiques de parefeu
Un parefeu peut fonctionner selon deux modes distinct : « tout ce qui n’est pas autorisé est interdit », ou « tout ce
qui n’est pas interdit est autorisé ». Pour définir le comportement par défaut, les iptables permettent de définir pour
chaque chaîne une action par défaut.
Définition de la politique par défaut des iptables
iptables -P chaine action
Où chaine représente le type de trafic (INPUT, OUTPUT et FORWARD), et action le comportement souhaité (DROP ou
ACCEPT).
Exemple de définition de politique
Dans cet exemple, on interdit à tout trafic de sortir de l’hôte en appliquant une politique de rejet des paquets sortants.
root@test:~$ ping -c 1 192.168.0.10

64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=0.880 ms
--- 192.168.0.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.880/0.880/0.880/0.000 ms
root@test:~$ iptables -P OUTPUT DROP
root@test:~$ ping -c 1 192.168.0.10
ping: sendmsg: Operation not permitted
--- 192.168.0.10 ping statistics ---
root@test:~$
b. Configuration d’une politique de base
Si l’hôte à configurer est appelé à devenir un parefeu, il est probable que tout trafic soit interdit par défaut. Cette
configuration courante consiste à définir sur les trois chaînes INPUT, OUTPUT et FORWARD une politique de non
traitement des paquets.
Configuration d’une politique restrictive
iptables -P INPUT DROP

iptables -P OUTPUT DROP
iptables -P FORWARD DROP
2. Filtrage de paquets
a. Politique et règles
Après avoir configuré une politique qui décrit le comportement de base du parefeu, il faut créer des règles
spécifiques aux éléments de trafics que l’on souhaite laisser passer ou interdire. La philosophie du parefeu est : on
définit le comportement général avec les politiques, et on gère au cas par cas les comportements spécifiques avec
des règles.
b. Création de règle

Pour chaque élément de trafic devant être autorisé ou interdit, il faudra créer une règle spécifique.
Syntaxe création d’une règle de gestion de trafic
iptables -A chaine -s ip_source -d ip_dest -p protocole --dport port -j action
iptables : création de règle
A chaine On ajoute une règle dans la chaîne chaine (INPUT, OUTPUT ou FORWARD).
s ip_source Facultatif : l’adresse IP source d’où proviennent les paquets soumis à la règle. Si
l’adresse est une adresse de réseau, préciser le masque.
d ip_dest Facultatif : l’adresse IP de destination vers laquelle vont les paquets soumis à la
règle. Si l’adresse est une adresse de réseau, préciser le masque.
p protocole Indique le protocole utilisé dans le paquet soumis à la règle. Valeurs courantes :
udp, tcp, icmp.
dport port Facultatif : indique le port de destination du paquet soumis à la règle.
j action Indique comment traiter le paquet soumis à la règle. (ACCEPT ou DROP).
Autorisation des ping sortant et entrant
Chaque type de flux doit faire l’objet d’une règle iptable.
alpha:~# iptables -A OUTPUT -p icmp -j ACCEPT

alpha:~# iptables -A INPUT -p icmp -j ACCEPT
alpha:~#
Autorisation du trafic http traversant en provenance d’un réseau
alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p tcp -dport 80 -j ACCEPT

alpha:~#
Une configuration erronée sur un parefeu peut avoir des conséquences dramatiques. Il est recommandé
pour vérifier sa bonne configuration d’utiliser un scanner de ports depuis une machine distante. La
commande nmap F suivie de l’adresse IP de la machine protégée permet de vérifier très rapidement (Fastmode)
que les ports sont bien bloqués ou ouverts.
c. Gestion des règles
Les règles sont appliquées dans leur ordre de création et le système leur applique automatiquement un numéro
d’ordre.
Affichage des numéros de règles effectives
iptables -L chaine --line-numbers -n
Où chaine représente la chaîne de traitement (INPUT, OUTPUT ou FORWARD). Le paramètre n n’est pas obligatoire,
mais accélère fortement l’affichage en dispensant la commande de tenter de résoudre les adresses en noms.
Suppression d’une règle
iptables -D chaine numéro
Où numéro représente le numéro de la ligne obtenu avec la commande précédente et où chaine représente la chaîne

de traitement (INPUT, OUTPUT ou FORWARD).
Insertion d’une règle
iptables -I chaine numéro conditions -j action
Où conditions représente les critères de sélection du paquet soumis à la règle (adresses IP, ports et protocoles).
Exemple de gestion de règles
La gestion dynamique des règles est tellement pénible que l’usage établi veut plutôt que l’on exploite un fichier de script
comprenant toutes les règles, et qu’on le recharge complètement après modification.
alpha:~# iptables -L FORWARD --line-numbers -n

Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT tcp -- 192.168.1.0/24 0.0.0.0/0 tcp dpt:23
2 ACCEPT udp -- 192.168.1.0/24 0.0.0.0/0 udp dpt:53
alpha:~# iptables -D FORWARD 1
alpha:~# iptables -I FORWARD 1 -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
alpha:~#
d. Gestion des flux retours
Dans la plupart des applications réseau, un hôte envoie un paquet à destination d’un autre qui lui répond. On a donc
une communication à double sens. Or, dans la configuration d’un parefeu, on visualise bien les flux aller : par
exemple, depuis un navigateur vers un serveur web sur le port 80, mais moins bien les réponses des serveurs qui se
font sur un port aléatoire à l’initiative du client supérieur à 1024.
Dans les premiers âges des parefeu, la solution consistait à autoriser tout trafic entrant dont le port était supérieur
à 1024. Les parefeu avaient alors davantage vocation à empêcher les gens de sortir plutôt que d’éviter les
intrusions dans le réseau.
Depuis quelques années, les parefeu dits « stateful » (à état) sont capables d’autoriser dynamiquement les flux
retours du moment qu’ils sont la réponse à un flux en sortie explicitement autorisé.
Autorisation implicite des flux retours
iptables -A chaine -m state --state ESTABLISHED,RELATED -j ACCEPT
L’option m state permet de réaliser un filtre en fonction de l’état du paquet traité. Les états acceptés : ESTABLISHED
et RELATED représentent respectivement des paquets en réponse à un flux aller autorisé, et des paquets issus
d’une nouvelle connexion, mais à l’initiative d’une connexion établie et autorisée (par exemple le trafic de données
ftp relatif à un trafic de commandes ftp).
Exemple de configuration complète d’un parefeu
On configure ici un parefeu qui ne laisse rien passer, à l’exception des réponses aux trafics établis, ainsi que les protocoles
nécessaires à la navigation internet (http, https et dns).
alpha:~# iptables -P INPUT DROP

alpha:~# iptables -P OUTPUT DROP
alpha:~# iptables -P FORWARD DROP
alpha:~# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p tcp --dport 80 -j ACCEPT
alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p tcp --dport 443 -j ACCEPT
alpha:~# iptables -A FORWARD -s 192.168.1.0/24 -p udp --dport 53 -j ACCEPT
Dans cet exemple, on configure un parefeu qui ne laisse rien passer, à l’exception des réponses aux trafics établis,
ainsi que les protocoles nécessaires à la navigation internet (http, https et dns).
L’application fail2ban permet en cas de tentatives de connexion infructueuses à des applications ou au
système luimême de créer dynamiquement une règle qui bloquera toute communication de la part de
l’attaquant. La connaissance de sa configuration détaillée n’est pas exigée pour la certification LPI.
3. Gestion du NAT
a. Rappel sur le principe du NAT
Le NAT consiste à réécrire l’entête IP d’un paquet qui passe d’un réseau public vers un réseau privé et inversement.
Les adresses IP publiques étant non routables sur l’internet, un paquet qui proviendrait d’une adresse privée ne
pourrait pas trouver de route retour, parce qu’aucun routeur n’accepterait de le renvoyer chez lui. De toute façon, les
réseaux privés étant démultipliés à l’infini (il existe des millions de réseaux 192.168.1.0), il ne serait pas possible de
maintenir dans les tables de routage des routeurs d’internet une route cohérente vers le réseau d’origine.
La solution consiste donc pour sortir d’un réseau privé à remplacer l’adresse IP de l’expéditeur privé par l’adresse IP
publique (unique sur internet) du routeur réalisant le NAT. La traçabilité des translations (remplacement des
adresses IP privées) se fait par rapport au port expéditeur utilisé : pour chaque translation réalisée, le routeur garde
en mémoire le port expéditeur employé. Le paquet retour arrivant sur l’adresse publique du routeur et sur le port
employé par l’expéditeur, l’adresse originelle du client est facilement retrouvée par le routeur NAT.
b. Diagnostic de la configuration NAT d’un routeur
Le NAT est géré dans une table spécifique appelée NAT. Toute configuration touchant au NAT se fera avec la
commande iptables en précisant qu’on travaille sur la table NAT. Les chaînes traitées dans la table NAT sont
PREROUTING, POSTROUTING et OUTPUT, représentant le trafic à modifier avant le routage, après, ou directement
en sortie de la machine.
Affichages de la configuration NAT

iptables -t nat -L
iptables -t nat -S
c. Connexion d’un réseau privé à un réseau public
Dans cette configuration qui est aussi la plus courante, l’adresse IP d’expéditeur des hôtes du réseau privé est
remplacée par l’adresse publique du routeur NAT.
Configuration du NAT
iptables -t nat -A POSTROUTING -o carte-ext -j action-nat
Nat avec iptables : options et paramètres
t nat La règle concerne la table de NAT.
A POSTROUTING On ajoute une règle à la chaîne POSTROUTING, pour un traitement après routage.
o carteext Désigne la carte réseau par laquelle les paquets sortent du parefeu.
j actionnat Désigne le mode d’action du NAT, supporte deux options : SNAT si l’adresse publique
est fixe, et MASQUERADE si l’adresse publique est dynamique.
Exemple de configuration du NAT
alpha:~# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

alpha:~#
Dans cet exemple, eth1 est l’interface connectée au réseau public.
4. Scripts de configuration des règles de filtrage
a. Red Hat et les iptables
Les systèmes Red Hat et leurs dérivés proposent un service iptables qui permet d’appliquer une configuration de
filtrage ou de NAT automatiquement. Le démarrage du service applique la configuration, et son arrêt annule tout
filtrage. Ce fonctionnement est extrêmement pratique et permet de gérer un parefeu RedHat de façon très
confortable.
b. Création de service personnalisé de parefeu avec les iptables
On constate assez vite que la création de règles de filtrage et de NAT avec les iptables a quelque chose de
fastidieux. Par conséquent, après avoir déterminé les règles dont on a besoin, on aura tout intérêt à les placer dans
un script.
Exemple de script de configuration de parefeu
Ce type de script dispense d’avoir à gérer les règles une par une en cas de modification de la configuration. Il est beaucoup
plus facile d’insérer une ligne dans le script que de décaler la numérotation des règles en mémoire. Toutefois, il faut
annuler toute règle avant chaque application du script.
#!/bin/bash
# nom du fichier : /etc/parefeu_on
# Politique de base
# NAT avec eth0 en interne et eth1 en sortie - adresse IP publique fixe

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 81.2.3.4
# gestion des paquets retours
iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# trafic autorisé en sortie
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 53 -j ACCEPT
Bien entendu, il ne faudra pas oublier de le rendre exécutable.
Il sera également utile de créer un script d’annulation de toute règle de filtrage. Il peut en effet être utile d’autoriser
plus ou moins provisoirement tout trafic, pour une mise à jour du parefeu ou un usage applicatif ponctuel.
Exemple de script d’annulation de filtrage
#!/bin/bash
# nom du fichier : parefeu_off
# Effacement des règles
iptables -F
# Politique permissive
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
Enfin, on peut créer un script de gestion de service normalisé.
Exemple de script de service de parefeu
Ce script est naturellement à placer dans le répertoire /etc/init.d.
#!/bin/bash
# nom du fichier : parefeu
case $1 in
start)
/etc/parefeu_on
;;
stop)
/etc/parefeu_off
;;
status)
iptables -L
;;
*)
echo "Syntaxe : /etc/init.d/parefeu start|stop|status
;;
esac

Détection des intrusions et des vulnérabilités
1. Les systèmes IDS
a. Les limitations des parefeu
Les parefeu dans leur fonctionnement historique filtrent les paquets sur les valeurs contenues dans les entêtes de
couche réseau ou transport, et donc sur les adresses IP ou les ports utilisés. Pour contourner la protection apportée
par les parefeu, de nombreuses applications utilisent des ports courants (tcp 80 notamment) pour faire passer leur
propre trafic applicatif. Les parefeu, souvent configurés pour laisser passer les flux sur ces ports courants, n’y voient
que du feu.
Pour assurer un meilleur contrôle, il faut utiliser un équipement plus élaboré, capable de regarder et d’analyser le
trafic applicatif, directement et sans se faire tromper par l’annonce d’un port erroné. Ces équipements sont appelés
« sondes » en français parce que sondant l’intérieur des paquets, ou encore IDS (Intrusion Detection System).
b. Techniques d’analyse
Pour identifier les trafics malicieux, les IDS disposent de trois techniques : la détection d’anomalies, l’analyse de
protocoles et l’analyse de signatures.
La détection d’anomalies a pour objet de détecter un comportement anormal, comme par exemple un volume ICMP
démesuré, qui indiquerait que l’on est la cible ou l’émetteur d’une attaque par dénis de service.
L’analyse de protocole ne cherche pas à repérer une action réellement malicieuse, mais plutôt un trafic applicatif qui
ne respecterait pas à la lettre les règles de fonctionnement des protocoles employés. C’est un peu l’histoire du
braqueur de banque qui se fait arrêter bêtement parce que ses pneus sont lisses.
Enfin, l’analyse de signatures permet d’identifier des attaques ou comportements malsains déjà référencés. C’est la
technique la plus efficace et qui n’est pas sujette à erreur, puisqu’on ne gère que des attaques ou intrusions ayant
déjà eu lieu chez un tiers, et donc dûment identifiées.
c. Sources d’information
Les techniques d’analyse, qu’il s’agisse d’analyse de signatures, de protocoles ou de détections d’anomalies
s’appuient sur des informations qui évoluent avec le temps. Il est évident que l’analyse de signature ne peut
s’appliquer que si l’IDS connaît la signature de l’attaque en cours. De plus, la nature des menaces peut évoluer. Par
exemple, un hôte qui aurait envoyé de gros volumes de trafics SMTP dans les années 80 indiquerait qu’un serveur de
messagerie fonctionne bien. La même situation aujourd’hui pourrait montrer que l’hôte en question est infecté par
un cheval de Troie et qu’il envoie de gros volumes de SPAM.
Les IDS doivent impérativement récupérer à intervalle régulier les mises à jour de leurs techniques d’analyse ainsi
que les bases de signatures. Les éditeurs d’IDS doivent systématiquement maintenir leurs bases d’informations à
jour, et les administrateurs des IDS doivent tout aussi régulièrement télécharger ces bases.
De nombreux organismes, associations et entreprises permettent de se tenir au courant des évolutions en matière
de techniques d’intrusion et de nuisance. Il est recommandé de connaître l’existence des principaux, et dans le cadre
d’une administration réseau avec prise en compte de la sécurité, d’assurer une veille technologique sur ces
domaines.
Principaux organismes de veille et de recherche
Bugtraq Liste de diffusion dédiée à l’annonce des vulnérabilités, leur exploitation et leur
correction.
CERT Computer Emergency Response Team. Cette organisation étudie les vulnérabilités,
effectue de la recherche sur les évolutions en terme de réseaux et de sécurité, et
propose des services liés à la sécurité.
CIAC Computer Incident Advisory Capability. Organisme de veille et de recherche géré par le
U.S. Department Of Energy.
2. SNORT

a. Les composants
Snort est le plus connu des IDS libre. Il analyse tout trafic et apporte un complément de sécurité appréciable, voire
indispensable sur un réseau. Snort est composé d’un moteur d’analyse, et d’un ensemble de règles.
Snort est composé d’un service et de fichiers de configuration généralement situés sous /etc/snort. Le fichier de
configuration principal est snort.conf. Les règles appliquées sont situées dans un sousrépertoire rules.
Snort dispose également d’une commande oinkmaster de mise à jour des règles qui trouve sa configuration dans un
fichier oinkmaster.conf.
b. Gestion des sources d’information
SNORT exploite des fichiers de règles qui doivent être téléchargés sur le site web de l’éditeur.
Déclaration d’un fichier de règles dans oinkmaster.conf
url = http://www.snort.org/snort-rules/fichier_règles
Où fichier_règles représente le fichier des règles au format tar.gz. Il est nécessaire d’être abonné auprès de l’éditeur
mais d’autres sites web proposent des fichiers de mise à jour gratuits. Naturellement, la qualité du suivi dépend des
gestionnaires de ces fichiers de règles.
Après toute modification du fichier de définition des signatures, et par la suite à intervalle régulier par une
planification cron, il faut demander à snort de télécharger ses nouvelles règles. Cette opération se réalise avec la
commande oinkmaster.
Chargement des règles
oinkmaster -o rep_règles
Où rep_règles représente le répertoire qui contient les règles de fonctionnement de snort, souvent /etc/snort/rules.
Les fichiers de règles doivent être appelés dans le fichier snort.conf par le paramètre include, ce qui est le cas avec
les paramètres par défaut et les signatures de l’éditeur.
c. Gestion des alertes
Quand Snort détecte un trafic malicieux, il laisse une trace dans un fichier journal via syslog, et envoie une copie du
paquet dans un fichier au format tcpdump (format libpcap, visible avec wireshark par exemple). Il a aussi la
possibilité d’envoyer les informations vers une base de données (Oracle, MySQL, et PostGreSQL sont entre autres
supportés).
Exemple de déclaration d’utilisation de syslog dans snort.conf
Cette déclaration indique que les éléments doivent être envoyés vers un serveur syslog dont l’adresse IP est ip_serveur,
sous la catégorie « alerte ».
output alert_syslog: host=ip_serveur, LOG_ALERT
3. OpenVAS
OpenVAS pour Open Vulnerability Assessment scanner est une variante libre du scanner de vulnérabilités Nessus. Il est
recommandé de connaître son existence dans le cadre de la certification LPI.
a. Le serveur OpenVAS
Le serveur est le cœ ur de la suite applicative OpenVAS, il scanne et analyse les hôtes du réseau à la recherche de
vulnérabilités connues (NVT : Network Vulnerability Tests).
b. Les clients OpenVAS

Les clients OpenVAS sont des éléments logiciels en ligne de commande ou avec une interface graphique qui assurent
l’analyse des hôtes du réseau à la recherche de vulnérabilités pour renvoyer les résultats au serveur.
c. Récupération des vulnérabilités
OpenVas propose une source publique de vulnérabilités connues sous le nom OpenVas NVT Feed. Il permet aux
serveurs de se tenir au courant des dernières vulnérabilités connues, et contient plus de 15000 NVT (Network
Vulnerability Tests).

clavier.
1. Questions
1 Un serveur Linux estil naturellement capable de router des paquets IP ?
2 La commande sysctl permet de modifier le contenu de certains fichiers du pseudo filesystem /proc. Comment le
paramètre qu’on lui fournit estil construit ?
3 Un système ne possédant qu’une seule carte réseau disposetil d’une table de routage ?
4 Si on demande l’affichage des iptables avec la commande iptables L, quelle table iptables est affichée ?
5 Avec les iptables, comment peuton appliquer une configuration particulière au trafic à destination d’un système
différente de la configuration appliquée au trafic routé par le même système ?
6 Dans le cadre des iptables, que se passetil si aucune des règles configurées pour une chaîne n’est satisfaite ?
7 En quoi le NAT apportetil une protection rudimentaire aux réseaux privés ?
8 La création manuelle de règles iptables est fastidieuse, et on ne peut pas toujours prévoir qui on voudra filtrer.
Comment automatiser la création de règles pour bloquer les importuns ?
9 Que sont Bugtraq et CERT ?
10 En quoi OpenVAS estil bien adapté à la protection de parcs informatiques ?
2. Réponses
1 Un serveur Linux estil naturellement capable de router des paquets IP ?
Oui, mais cette fonction est toujours désactivée par défaut. On peut l’activer en modifiant le contenu du
fichier /proc/sys/net/ipv4/ip_forward (valeur 1).
2 La commande sysctl permet de modifier le contenu de certains fichiers du pseudo filesystem /proc. Comment le
paramètre qu’on lui fournit estil construit ?
En précisant le fichier de la sousarborescence de /proc/sys qu’on souhaite modifier. À ceci près que le séparateur
hiérarchique n’est plus le slash mais le point. Le fichier /etc/sysctl.conf est lu à chaque démarrage par la commande
sysctl pour une application permanente de ces paramètres.
3 Un système ne possédant qu’une seule carte réseau disposetil d’une table de routage ?
Oui, bien sûr. Tout système IP dispose de sa table de routage. Si le système n’est pas un routeur évident (connecté à
plusieurs réseaux), il doit néanmoins être capable de router les paquets vers leurs réseaux de destination. Au
minimum, la table de routage contient une référence au réseau local, et la définition de la route par défaut (passerelle
par défaut).
4 Si on demande l’affichage des iptables avec la commande iptables L, quelle table iptables est affichée ?
La table filter. Cela tombe bien, c’est souvent celle que l’on souhaite observer. Ce comportement est toutefois
trompeur, de nombreux administrateurs vont même jusqu’à ignorer l’existence de la table nat qui peut être affichée
par la commande iptables t nat L.
5 Avec les iptables, comment peuton appliquer une configuration particulière au trafic à destination d’un système
différente de la configuration appliquée au trafic routé par le même système ?
Il faut pour cela gérer des règles différentes selon les chaînes à configurer. La chaîne INPUT référence le trafic à
destination du système luimême, alors que la chaîne FORWARD traite le trafic routé au travers du système.
6 Dans le cadre des iptables, que se passetil si aucune des règles configurées pour une chaîne n’est satisfaite ?
C’est la règle par défaut qui est appliquée. Les règles par défaut sont décrites dans les politiques iptables (policies),
définies avec le paramètre P. Il existe une policy par chaîne.
7 En quoi le NAT apportetil une protection rudimentaire aux réseaux privés ?
Dans le cadre d’un fonctionnement en NAT, les adresses des machines privées sur le réseau ne dépassent pas le
routeur NAT (elles sont systématiquement remplacées par son adresse publique), cela assure donc une certaine
discrétion au réseau privé. De plus, un attaquant qui voudrait de l’extérieur pénétrer un réseau privé ne saurait pas
trouver le chemin vers ce réseau, les adresses privées étant nonroutables sur internet.

8 La création manuelle de règles iptables est fastidieuse, et on ne peut pas toujours prévoir qui on voudra filtrer.
Comment automatiser la création de règles pour bloquer les importuns ?
Le logiciel fail2ban a pour objet de créer des règles dynamiquement, par exemple pour créer une règle qui interdirait
tout trafic pour un utilisateur distant qui aurait eu trois échecs successifs pour une ouverture de session SSH.
9 Que sont Bugtraq et CERT ?
Des organismes de recherche et de veille sécuritaire. Ils publient les annonces et données techniques des
vulnérabilités découvertes.
10 En quoi OpenVAS estil bien adapté à la protection de parcs informatiques ?
Son architecture clientserveur permet de centraliser sa configuration et son administration sur un serveur, et les
composants clients sur toutes les machines du parc à protéger.

Travaux pratiques
Internet est un monde sans pitié. Soucieux de protéger vos serveurs et aussi de respecter les bons usages en terme
de sécurité, vous décidez de créer un réseau privé strictement isolé et au trafic applicatif protégé par un parefeu.
1. Restructuration du réseau local
a. Ajout d’une interface réseau sur le serveur beta
Commandes utiles
● Manipulations liées au logiciel de virtualisation
● ifconfig
● lspci
● shutdown
Manipulations
1. Arrêtez le serveur beta avec une commande appropriée.
2. Depuis l’interface de gestion VirtualBox OSE, sélectionnez le serveur beta, puis dans
l’onglet Détails, cliquez sur Réseau.
3. Dans l’onglet Carte 2, cliquez sur Activer la carte réseau. Déroulez ensuite Mode
d’accès réseau, choisissez Réseau interne et renseignez le champ Nom avec le nom
intnet qui représentera un réseau local privé, accessible aux seules machines virtuelles
connectées à ce réseau privé.
4. Démarrez le serveur beta.

5. Vérifiez avec les commandes appropriées qu’une nouvelle interface est reconnue par le
système.
Arrêt du système :
[root@beta ~]# shutdown -h now

( ... Arrêt du système ... )
Vérification de l’interface :
[root@beta ~]# lspci

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics
Adapter
00:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 40)
00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service
00:05.0 Multimedia audio controller: Intel Corporation 82801AA AC’97 Audio Controller
(rev 01)
00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
00:08.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 40)
[root@beta ~]#
[root@beta ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:E4:07:62
adr inet6: fe80::a00:27ff:fee4:762/64 Scope:Lien
RX bytes:0 (0.0 b) TX bytes:6713 (6.5 KiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:E4:6D:E5

adr inet6: fe80::a00:27ff:fee4:6de5/64 Scope:Lien
lo Link encap:Boucle locale

inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX bytes:5485700 (5.2 MiB) TX bytes:5485700 (5.2 MiB)
[root@beta ~]#
b. Adresses IP du serveur beta
● /etc/sysconfig/networkscripts/ifcfgethx
● ifconfig

● ifup
● route
● vi
Manipulations
1. Trouvez le fichier de configuration de l’interface eth1.
2. Éditezle et renseignez les paramètres IP suivants : 192.168.199.1 255.255.255.0.
3. Activez l’interface eth1.
4. Vérifiez que votre configuration a bien été prise en compte par le système.
5. Vérifiez que l’adresse de l’interface eth0 est conservée et que la passerelle par défaut
n’a pas été modifiée (ce qui aurait pu arriver si vous aviez malencontreusement
renseigné une passerelle par défaut dans le fichier ifcfgeth1).
Fichier /etc/sysconfig/networkscript/ifcfgeth1 modifié :
# Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]

DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
HWADDR=08:00:27:e4:6d:e5
IPADDR=192.168.199.1
NETMASK=255.255.255.0
TYPE=Ethernet
Activation de l’interface eth1 :
[root@beta network-scripts]# ifup eth1

[root@beta network-scripts]#
Vérification de la configuration pour eth1 :
[root@beta network-scripts]# ifconfig eth1

adr inet6: fe80::a00:27ff:fee4:6de5/64 Scope:Lien
Vérification de la configuration la passerelle par défaut et pour l’interface eth0 :
[root@beta network-scripts]# ifconfig eth0

adr inet6: fe80::a00:27ff:fee4:762/64 Scope:Lien
RX bytes:1042 (1.0 KiB) TX bytes:6713 (6.5 KiB)
[root@beta network-scripts]# route -n

192.168.199.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 192.168.200.254 0.0.0.0 UG 0 0 0 eth0
c. Gestion du client en réseau privé
Commandes utiles
● Commandes graphiques de gestion de réseau de la distribution Ubuntu
● ifconfig
● ping
Manipulations
1. Dans les menus Virtualbox de la station cliente, développez Périphériques puis cliquez
sur Cartes réseau.
2. Dans l’onglet Carte 1, déroulez Mode d’accès réseau, et choisissez Réseau interne et
sélectionnez votre réseau interne intnet.
3. Dans la station de travail Ubuntu, développez le menu Système, puis Préférences, et
choisissez Connexions réseau.
4. Dans la fenêtre Connexions réseau, modifiez la connexion Fixe eth0 créée
précédemment.
5. Dans l’onglet Paramètres IPv4, modifiez l’adresse IP en 192.168.199.50
255.255.255.0. Utilisez la passerelle par défaut 192.168.199.1 (serveur beta), et utilisez
provisoirement le serveur DNS de votre fournisseur d’accès.
6. Vérifiez en lignes de commandes la validité de votre configuration par un ping sur
l’adresse privée du serveur beta (si nécessaire, réactivez la configuration Fixe eth0 en
cliquant dessus depuis la barre de menu supérieure icône réseau en haut à droite).
Vérification de la connectivité :
toto@ubuntu:~$ ifconfig eth0

adr inet6: fe80::a00:27ff:fe7b:c879/64 Scope:Lien
Octets reçus:12348291 (12.3 MB) Octets transmis:9378271 (9.3 MB)
toto@ubuntu:~$ ping 192.168.199.1

^C
--- 192.168.199.1 ping statistics ---

toto@ubuntu:~$
d. Gestion du serveur alpha en réseau privé
● Fichier /etc/network/interfaces
● ifconfig
● ifup
● ifdown
● ping
Manipulations
1. Dans les menus Virtualbox du serveur beta, développez Périphériques puis cliquez sur
Cartes réseau.
2. Dans l’onglet Carte 1, déroulez Mode d’accès réseau, choisissez Réseau interne et
sélectionnez votre réseau interne intnet.
3. Dans le fichier de condition réseau, modifiez l’adresse IP de l’interface eth0 en
192.168.199.10 255.255.255.0. Utilisez la passerelle par défaut 192.168.199.1 (serveur
beta) et utilisez provisoirement le serveur DNS de votre fournisseur d’accès.
4. Rechargez la configuration de l’interface eth0.
l’adresse privée du serveur beta.
Fichier /etc/network/interfaces modifiés :
# 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.199.10
netmask 255.255.255.0
gateway 192.168.199.1
alpha:/etc/network#
Vérification de la connectivité :
alpha:/etc/network# ifdown eth0

alpha:/etc/network# ifup eth0
alpha:/etc/network# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:9c:6e:9f

adr inet6: fe80::a00:27ff:fe9c:6e9f/64 Scope:Lien
RX bytes:714 (714.0 B) TX bytes:22494 (21.9 KiB)
alpha:/etc/network# ping 192.168.199.1

^C
--- 192.168.199.1 ping statistics ---
alpha:/etc/network#
2. Configuration d’un routeur et parefeu sur le serveur B
Vous êtes maintenant rassuré : votre réseau privé est désormais bien protégé derrière le serveur B. D’autant plus
protégé que ce serveur non configuré ne laisse passer aucun trafic. Souhaitant tout de même pouvoir travailler un
peu, vous décidez de gérer la connectivité entre le réseau privé et internet.
a. Configuration du NAT
● /etc/sysctl.conf
● /proc/sys/net/ipv4/ip_forward
● cat
● iptables
● ping
● sysctl
Manipulations
1. Sans utiliser la commande echo, activez le routage sur le serveur beta.
2. Depuis la station de travail, faites un ping sur l’interface publique du serveur beta.
3. Vérifiez que le routage a bien été pris en compte en consultant le fichier approprié dans
le filesystem /proc.
4. Faites en sorte que le routage soit activé systématiquement à chaque démarrage du
serveur beta.
5. Vérifiez que le serveur beta ne fait pas de NAT : depuis la station de travail, faites un

ping sur une adresse du réseau public (la passerelle internet par exemple).
6. Configurez le NAT sur le serveur beta.
7. Depuis la station de travail, faites un ping sur une adresse du réseau public (la
passerelle internet par exemple).

Configuration du routage sur le serveur beta :
[root@beta ~]# cat /proc/sys/net/ipv4/ip_forward

0
[root@beta ~]# sysctl net.ipv4.ip_forward=1
[root@beta ~]# cat /proc/sys/net/ipv4/ip_forward
1
[root@beta ~]#
Fichier /etc/sysctl.conf modifié :
# Controls IP packet forwarding

(...)
Configuration du NAT sur le serveur beta :
[root@beta ~]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[root@beta ~]#
Vérification depuis la station de travail :

^C
--- 192.168.200.254 ping statistics ---
toto@ubuntu:~$
La navigation internet doit également être possible (il peut être nécessaire de désactiver l’utilisation d’un serveur
proxy).
b. Politique de filtrage sévère
Le réseau local est désormais capable de naviguer librement sur internet. Toutefois, à ce stade de la configuration,
n’importe quel protocole applicatif peut circuler librement, et cela ne correspond pas à vos objectifs. Vous décidez de
sévir.
Commandes utiles
● iptables
● ping
Manipulations
1. Déclarez une politique de rejet pour tout trafic entrant dans le serveur beta.
2. Déclarez une politique de rejet pour tout trafic sortant du serveur beta.
3. Déclarez une politique de rejet pour tout trafic traversant le serveur beta.
4. Vérifiez la configuration active.
5. Constatez que tout trafic est désormais impossible.
Application des politiques :

[root@beta ~]# iptables -P INPUT DROP
[root@beta ~]# iptables -P OUTPUT DROP
[root@beta ~]# iptables -P FORWARD DROP
[root@beta ~]#
[root@beta ~]# iptables -L
Chain INPUT (policy DROP)

Chain OUTPUT (policy DROP)

[root@beta ~]#
Essai de ping depuis la station de travail :

^C
--- 192.168.200.254 ping statistics ---
toto@ubuntu:~$
c. Autorisation du trafic utile
Soucieux de revenir à un juste équilibre, vous décidez d’autoriser les protocoles http, https et dns.
Commandes utiles
● iptables
Manipulations
1. Autorisez le trafic retour pour toute communication déjà établie sur la chaîne FORWARD.
2. Autorisez le trafic vers toute adresse (adresse publique sur internet) pour le protocole
http (TCP 80).
https (TCP 443).
dns clientserveur (UDP 53).
5. Vérifiez depuis la station cliente que la navigation internet est désormais possible
(n’oubliez pas de reconfigurer le navigateur pour qu’il se connecte directement à
internet sans passer par un serveur proxy).
6. Vérifiez depuis la station cliente que les pings ne passent pas (à aucun moment on a
autorisé leur circulation, et la politique de base interdit tout trafic non explicitement
autorisé).
Configuration des règles iptables :
[root@beta ~]# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

[root@beta ~]# iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
[root@beta ~]# iptables -A FORWARD -p tcp --dport 443 -j ACCEPT
[root@beta ~]# iptables -A FORWARD -p udp --dport 53 -j ACCEPT
[root@beta ~]#

d. Gestion sous forme de service
Pour pouvoir gérer confortablement votre filtrage de trafic, vous décidez de créer un service qui sera lancé
automatiquement au démarrage du système.
Commandes utiles
● chmod
● ln
● vi
Manipulations
1. Créez un fichier de script /opt/scripts/pf0.sh qui annule toute forme de filtrage et
rétablit une politique permissive.
2. Créez un fichier de script /opt/scripts/pf1.sh qui contient votre politique et vos règles
de filtrage. Positionnez des droits restrictifs sur ce fichier pour éviter les indiscrétions.
3. Créez un script de gestion de service normalisé parefeu.
4. Créez un lien S10parefeu dans le répertoire correspondant à votre niveau d’exécution
par défaut. Ce lien provoquera le lancement du service à chaque démarrage du
système.
5. N’oubliez pas que ces fichiers doivent être exécutables.
Fichier de script exécutable /opt/scripts/pf0.sh :
#!/bin/bash
iptables -F
Fichier de script exécutable /opt/scripts/pf1.sh :
#!/bin/bash
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -j ACCEPT

iptables -A FORWARD -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -j ACCEPT
Fichier exécutable de gestion de service /etc/init.d/parefeu :
#!/bin/bash
case $1 in
start)
/opt/scripts/pf1.sh
;;
stop)
/opt/scripts/pf0.sh
;;
status)
iptables -L
;;
esac

Modification des droits sur les fichiers de scripts :
[root@beta scripts]# chmod 700 *

[root@beta scripts]# ls -l
total 8
-rwx------ 1 root root 102 sep 2 18:22 pf0.sh
-rwx------ 1 root root 298 sep 2 18:22 pf1.sh
[root@beta scripts]# chmod +x /etc/init.d/parefeu
[root@beta scripts]#
Création d’un lien symbolique pour le niveau d’exécution en cours :
[root@beta init.d]# runlevel

N 3
[root@beta init.d]# cd /etc/rc3.d
[root@beta rc3.d]# ln -s ../init.d/parefeu S10parefeu
[root@beta rc3.d]#

1. Prérequis

Fonctionnement général du serveur X.
2. Objectifs

Gérer les authentifications SSH.
Connaître le fonctionnement des agents SSH.
Ouvrir des sessions distantes avec SSH.
Copier des fichiers avec scp.
Établir des tunnels applicatifs avec SSH.
Renvoyer des sessions X11 avec SSH.
Connaître les modes de fonctionnement OpenVPN.
Gérer les authentifications OpenVPN par secret partagé.
Établir un tunnel OpenVPN.

OpenSSH
1. Utilisations de OpenSSH
Les sessions interactives sur les systèmes Unix ont d’abord été conduites par des terminaux passifs, qui se bornaient
à gérer les entrées et sorties, connectées à une unité centrale par un port série. Les frappes au clavier étaient
envoyées brutes à l’unité centrale, et l’unité centrale envoyaient en retour des ordres d’affichage à l’écran. Les
ordinateurs étant alors hors de prix, le coût relativement modeste des terminaux passifs permettait de mutualiser
l’utilisation d’un ordinateur.
Avec la généralisation des réseaux IP et la démocratisation des ordinateurs personnels, l’administration distante des
systèmes Unix s’est faite ensuite par le protocole telnet. Le principe est rigoureusement le même qu’avec les
terminaux passifs, si ce n’est que les frappes au clavier et ordres d’affichage sont envoyés dans des paquets telnet
transportés par IP. Le problème est que la gestion de la sécurité avec le protocole telnet est largement insuffisante :
une authentification est réalisée en texte clair, et aucune confidentialité n’est apportée aux échanges entre le client et
le serveur.
Le protocole SSH vise à apporter des services d’authentification et de confidentialité à des échanges entre clients et
serveur pour le transport sécurisé de données. Il est dans la plupart des cas simples utilisé en tant que « telnet
sécurisé » mais il est aussi capable d’assurer le transport sécurisé d’autres protocoles applicatifs. L’implémentation
open source du protocole SSH est « OpenSSH », créé et maintenu par les membres du projet OpenBSD.
2. Gestion des authentifications
a. Authentification par mot de passe
L’utilisation la plus simple du client SSH, qui consiste à ouvrir une session shell distante de façon sécurisée sur
réseau IP, exploite un mode d’authentification simple, à savoir utiliser un compte local sur le serveur et demander au
client de s’authentifier avec le nom et le mot de passe de ce compte présent sur le serveur. Le mot de passe est
alors vérifié et l’authentification est validée. Toutefois, cette phase d’authentification par mot de passe sert
uniquement à vérifier la validité du client. Lequel client peut à son tour avoir des doutes sur l’identité et la légitimité
du serveur : en clair, suisje bien en train de parler à mon serveur, ou à un faux serveur qui exploiterait les
commandes tapées pour récupérer des informations sur mes systèmes ? Pour éviter tout risque d’usurpation du
serveur, le client réalise une vérification de l’identité du serveur à la première connexion. En fait, une empreinte
numérique du serveur est réalisée, et après validation de cette empreinte par le client, elle est conservée dans un
fichier appelé known_hosts, présent dans un répertoire caché .ssh dans le répertoire personnel de l’utilisateur.
Exemple de fichier known_hosts
Le fichier known_hosts présente une (très longue) ligne par serveur connu.
beta:~# cat .ssh/known_hosts

|1|LPx02U8nHnkSb0czyqVrdXPcW04=|jS0/QdS0HydzPZj8QXxHXC4j6EM= ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAv+kXth0/RSAroNfqeV+IkEMetdWRWYBvbNOqUDDSL/fLylBip9le40xfTe1j
FXuYqAWR+mQMo8Pg37/PUWeetlBCvG4F486UbqUn2Ol5B/1GZqzG7nvbOLcp7CDr6vmqgrk2QZvUZcohWc4L9S6z
zvk3EmQ1AMa+BKo4m+FCG9E1mK4bFtvchVqL1amzGg1jd2QuTzMGNibTdrEi9gSr2TrJ5Se9AhNQkIzZPvrqvVAD
itiggcYNetxaNkPKfW8DdClq+qOVVAQuWnZiO63Mp/0+b+JEutFgNsX8mkt9nx34Yws7s3BnIuT7oU+shxnuy/vj
5But4uUry5tFaTxXCw==
beta:~#
b. Authentification par clés
Une méthode sans doute plus fiable pour authentifier les connexions SSH consiste à utiliser des clés
d’authentification stockées localement sur le disque de l’utilisateur. L’authentification par clés ne dispense pas
obligatoirement de la saisie d’un mot de passe, mais garantie à l’utilisateur que la machine distante est bien celle
avec laquelle on veut travailler et non pas une usurpatrice.
Création de la paire de clés sur le client
Pour que le serveur puisse être formellement identifié, il doit disposer de la clé publique du client. Cette clé lui
permettra de crypter des données déchiffrables par le seul client propriétaire de la clé privée correspondante. Il
convient donc dans un premier temps de générer cette clé publique sur le client. Comme il s’agit de cryptographie
asymétrique, la génération d’une clé publique est obligatoirement simultanée à celle de la clé privée correspondante.

La commande sshkeygen permet de créer ces clés publiques et privées.
Génération d’un couple de clés
ssh-keygen -t algorithme
Où algorithme représente l’algorithme employé pour la génération des clés du client. Il peut s’agir de RSA (version 1
ou 2 de SSH) ou DSA (version 2 de SSH). RSA et DSA sont deux algorithmes de cryptage asymétriques souvent
utilisés pour l’authentification. Si l’algorithme n’est pas précisé, la valeur par défaut RSA est employée.
Génération d’un couple de clés avec les valeurs par défaut
On génère ici un couple de clés avec l’algorithme par défaut (RSA) pour l’utilisateur tata. La représentation graphique
(randomart) de la clé n’est pas systématique et dépend de la version de la commande.
tata@stotion:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tata/.ssh/id_rsa):
Created directory ’/home/tata/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tata/.ssh/id_rsa.
Your public key has been saved in /home/tata/.ssh/id_rsa.pub.
The key fingerprint is:
f3:5c:f1:34:6c:1b:a6:4c:5b:c4:6d:30:48:01:76:f4 tata@stotion
The key’s randomart image is:
+--[ RSA 2048]----+
| o+=++o |
| . ..+..o|
| o E. |
| o X + |
| S = o |
| + . |
| o |
| |
| |
+-----------------+
tata@stotion:~$
La commande sshkeygen provoque la création de deux fichiers, par défaut dans un répertoire .ssh situé
directement dans le répertoire personnel de l’utilisateur. Ces deux fichiers sont par défaut id_rsa pour la clé privée
et id_rsa.pub pour la clé publique correspondante. Même si ça n’est pas obligatoire, il est vivement recommandé de
protéger la clé privée par un mot de passe qui sera demandé lors de sa création.
Contenus de fichiers de clés privées et publiques
On observe le contenu des fichiers de clés privées et publiques. Notez que les droits par défaut sont limités sur le fichier de
clé privée, et ouverts sur le fichier de clé publique.
tata@stotion:~/.ssh$ ls -l
total 8
-rw------- 1 tata tata 1743 2010-09-03 09:38 id_rsa
-rw-r--r-- 1 tata tata 394 2010-09-03 09:38 id_rsa.pub
tata@stotion:~/.ssh$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs0jrYKKQKiS4f/cCQMhOcc2WTMmGrbXXv3oyz67KUwkm4JumEU1
YkOaNi+WM4nVbkzC7rkUnlXQMxu/EpZLoraNySMHZjUgYiWiRuM4pI0z/atPfjVlwPtGzfUKlqSsP4NCark/9G0
WlMgEXlgpEdeJDmMBRuj98PJjOI/cRGRTgR6JEoevFWMPTDRpoBix3YizVY+dA+unJQPaNKWhoDnCZg7xWi+ZRg
T2Q1PcbqYKt4xLio+Eei0dvlgu5r5hSvymOdWbXwykywoloIxnzIPiUe7CAxm+KCBA23LQw73pREd1cglS6Gd23
b5Byv/oI6etqs4WOmcJa40Ymvtfbjw== tata@stotion
tata@stotion:~/.ssh$ cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B08C4C3C4B021A76
TzO6ofHOv8sVRDoPj+o7dXfPuXDJaOmQSGhDkWUTC9iGHYnGdHgsig5EKWEez0Zj
YucF9doTpLCv9UsRac6WHRjlQb7AUjk9phEjrKYW4gAfoXNcFY5IiC7fca9i8NQk
YCj4mtzmbJAFc0W9Ax8g0UzZ8bwElIacI28pAdSvVqVHQ6omnVBoWhXhgWTUZaKp

2XbY5gJ7miKW3Y9IPZ3JLukB3j4rTZ0bu8j/UedyXuogpZgYF2vW0GfvtBbfP31F
(...)
RZfBnf+3+KxTvnAtJsMSZc4Glg+9Gch9V+mjU2SfW+T+bUnYLB/6Mpo1aq/akj3r
0G6w12SgjqiOuuXnsCdU8Ox1olCqiHFrk0DyPmwoxcSQygpm2r7FIwL4MPxbELJO
zfk+0wJOmsUANJzeBKd4LXmZykYsAOmf3zZNlS+iU/ZhCBqFmn3/5w==
-----END RSA PRIVATE KEY-----
tata@stotion:~/.ssh$
À chaque connexion, le serveur regarde dans le répertoire local de l’utilisateur essayant de se connecter si un
répertoire .ssh/authorized_keys existe, et s’il contient la clé publique du client. Si c’est le cas, l’authentification du
serveur peut être réalisée par le client. Le client devra donc copier son fichier de clé publique dans le répertoire
~/.ssh.authorized_keys du serveur par le moyen de son choix. (clé usb, copie réseau).
c. L’agent SSH
Pour les administrateurs ayant fréquemment besoin d’accéder à plusieurs machines par SSH, un « agent SSH », lancé
par la commande sshagent, permet de conserver en mémoire les clés privées utilisées pour les authentifications.
Les clés privées sont transmises une fois pour toutes à l’agent par la commande sshadd. Si un mot de passe de
protection de la clé est nécessaire, il est demandé à cette occasion. Les clés sont ensuite disponibles sans
intervention directe de l’utilisateur pour toute authentification.
La commande sshadd consulte le répertoire .ssh dans le répertoire personnel de l’utilisateur et recherche
d’éventuelles clés privées dans les fichiers id_rsa, id_dsa, et identity. Les clés stockées par l’agent SSH peuvent
être consultées par la commande sshadd l.
Lancement de l’agent par la commande sshagent
L’agent alimente des variables lors de son fonctionnement qui permettent de le gérer plus facilement.
tata@stotion:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-sRuvox4519/agent.4519; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4520; export SSH_AGENT_PID;
echo Agent pid 4520;
tata@stotion:~$
sshagent : variables courantes
SSH_AGENT_PID Le pid de l’agent en cours d’exécution.
SSH_AUTH_SOCK Le socket créé par le processus.
Prise en compte de clés par l’agent SSH
La commande sshadd sans argument permet la prise en compte des clés par l’agent SSH qui doit naturellement avoir été
lancé auparavant.
tata@stotion:~$ ssh-add
Enter passphrase for /home/tata/.ssh/id_rsa:
Identity added: /home/tata/.ssh/id_rsa (/home/tata/.ssh/id_rsa)
tata@stotion:~$
Visualisation des clés privées stockées par le sshagent
La commande sshadd l permet de vérifier que les clés ont bien été prises en compte par l’agent.
tata@stotion:~$ ssh-add -l
2048 f3:5c:f1:34:6c:1b:a6:4c:5b:c4:6d:30:48:01:76:f4 tata@stotion (RSA)
2048 f3:5c:f1:34:6c:1b:a6:4c:5b:c4:6d:30:48:01:76:f4 /home/tata/.ssh/id_rsa (RSA)
tata@stotion:~$
L’agent SSH est avant tout une solution de gestion de clés et n’est pas destiné à créer les clés SSH. L’agent
SSH ne peut travailler que sur des clés déjà créées par la commande sshkeygen.

3. Confidentialité des communications
a. Session interactive avec SSH
La session interactive est ouverte depuis un client vers un serveur avec un compte utilisateur présent sur le serveur.
Ouverture de session interactive avec SSH
ssh utilisateur@adresse_serveur
Session interactive avec SSH : option et paramètres
utilisateur Le compte utilisateur présent sur le serveur avec lequel on se connecte.
adresse_serveur L’adresse IP du serveur auquel on se connecte.
Exemple d’ouverture de session interactive avec SSH
alpha:~# hostname ; whoami

alpha
root
alpha:~# ssh toto@192.168.0.11
toto@192.168.0.11’s password:
toto@beta:~$ hostname ; whoami

beta
toto
toto@beta:~$
b. Copie de fichiers avec SSH
La commande scp s’appuie sur le démon SSH et permet de copier des fichiers de façon sécurisée avec les services
d’authentification et de confidentialité offerts par SSH. La copie peut se faire du client vers le serveur ou depuis le
serveur vers le client.
Copie de fichier du client vers le serveur avec scp
scp fichier_local utilisateur@adresse_serveur:fichier_distant
Copie de fichier depuis le serveur vers le client avec scp
scp utilisateur@adresse_serveur:fichier_distant fichier_local
Copie de fichiers avec scp : options et paramètres
fichier_local Chemin relatif ou absolu du fichier local devant être copié.
fichier_distant Chemin absolu du fichier distant devant être copié.
utilisateur Compte utilisateur existant sur le serveur utilisé pour la copie.
adresse_serveur Adresse IP du serveur hébergeant le service SSH.
c. Utilisation d’applications dans des tunnels SSH

La création d’un tunnel SSH permet de sécuriser une communication clientserveur pour un protocole à priori peu
sécurisé. On établit depuis le poste client un tunnel SSH vers le serveur, et tout le trafic entre ces deux machines est
sécurisé. Le serveur génère alors un autre trafic non sécurisé vers la machine cible du trafic. Les connexions des
clients qui souhaitent emprunter le tunnel se font en fait vers le client SSH.
Création d’un tunnel applicatif SSH
ssh -L port:cible_trafic:port_cible utilisateur@serveur
Tunnel SSH : options et paramètres
L Renvoie un port local vers un serveur SSH (établissement de tunnel).
port Le port local à renvoyer.
cible_trafic Adresse IP ou nom de la machine cible du trafic.
port_cible Port vers lequel renvoyer le trafic sur la machine cible.
utilisateur Compte utilisateur sur le serveur utilisé pour l’établissement du tunnel.
serveur Adresse IP ou nom du serveur extrémité du tunnel.
Dans ce fonctionnement, un tunnel est établi entre un client et un serveur. Sur le client, le trafic à destination du port
local est renvoyé au travers du tunnel SSH vers la machine cible sur le port cible.
d. Renvoi de sessions X11 via SSH
Le serveur X ne prévoyant nativement pas de sécurité forte pour ses échanges clientsserveurs, un usage courant
de SSH consiste à faire circuler dans un tunnel SSH des applications graphiques. Il faut pour cela autoriser le serveur
SSH à relayer ce type de trafic, puis d’utiliser un client compatible avec ce mode de fonctionnement.
L’autorisation du renvoi de sessions X via SSH se fait en modifiant le fichier de configuration du serveur
SSH /etc/ssh/sshd_config.
Autorisation du renvoi des connexions X dans sshd_config.conf
X11Forwarding yes
Connexion depuis un client SSH

ssh -X utilisateur@serveur
Où utilisateur représente le compte utilisé pour la connexion, et serveur l’adresse IP ou le nom du serveur auquel on
se connecte. Les applications graphiques peuvent alors être lancées depuis la session SSH cliente.

OpenVPN
OpenVPN est une solution logicielle open source de création de tunnels sécurisés (VPN). Contrairement aux VPN usuels,
elle ne s’appuie pas sur IPSEC mais sur SSL. Elle assure des services d’authentification, de confidentialité et de contrôle
d’intégrité.
1. Les modes de fonctionnement OpenVPN
La certification LPI n’exige pas une connaissance approfondie d’OpenVPN, mais il faut néanmoins connaître l’essentiel
de ses modes fonctionnels.
a. Authentification
Les extrémités de tunnel, c’estàdire les deux machines assurant le cryptage des flux sortants et le décryptage des
flux entrants, doivent être mutuellement authentifiées. Il ne faut pas qu’il y ait de doute sur l’authenticité du
correspondant. OpenVPN supporte plusieurs modes d’authentification, mais les deux plus courants sont
l’authentification par clé partagée, et l’authentification par certificats numérique X509. La première solution est
infiniment plus simple à mettre en œ uvre mais passe pour être moins sécurisée. La seconde, si elle est
recommandée, est toutefois beaucoup plus difficile à déployer si on n’a pas une connaissance intime des
infrastructures à clés publiques qui permettent de générer les certificats. Il est souvent préférable d’avoir une
solution à clé partagée qui fonctionne correctement plutôt qu’une infrastructure à clé publique bancale mal maitrisée
et donc difficile à maintenir.
b. Confidentialité
La confidentialité des communications est assurée par la bibliothèque OpenSSL. Le cryptage des échanges est
assuré par l’algorithme Blowfish par défaut, mais les algorithmes symétriques courants sont utilisables (AES
notamment).
c. Fonctionnement réseau
Le mode de fonctionnement le plus simple et le plus facile à appréhender est le mode pointàpoint dans lequel les
deux protagonistes du vpn sont ceux qui doivent communiquer ensemble de façon sécurisée : ils sont à les fois les
extrémités de tunnel et les extrémités de trafic. Il est aussi possible de relier deux réseaux entre eux en mode site
àsite. Deux serveurs OpenVPN assurent alors la mise en place du tunnel, mais les extrémités de trafic sont les deux
réseaux reliés. Les serveurs OpenVPN assurent alors un rôle de routage entre les réseaux. Enfin, il est possible de
faire du VPN d’accès distant dans lequel une machine est reliée à un réseau.
OpenVPN peut fonctionner en mode bridgé, dans ce cas il mettra en connexion deux réseaux distants, un peu comme
si on avait ajouté un câble entre les switches des deux réseaux à relier, fûtil un câble de 200 km. Ce mode de
fonctionnement peut être considéré comme anecdotique, et le mode routé est de loin le plus utilisé.
Les paquets cryptés sont transportés par UDP par défaut mais l’utilisation de TCP est possible.
2. Création d’un tunnel pointàpoint
a. Gestion de l’authentification
La méthode d’authentification par clé partagée suppose la présence d’un fichier de clé au format reconnu par
OpenVPN. Ce fichier doit être présent sur le serveur et le client, et donc copié par un moyen sécurisé. (clé usb, scp)
Le fichier peut être généré directement par la commande openvpn.
Génération du fichier de clé secrète
openvpn --genkey --secret fichier_cle
Où fichier_cle représente le fichier contenant la clé secrète.
Exemple de génération de clé

On génère ici un fichier de clé secrète qui permettra l’authentification entre les machines aux extrémités du tunnel.
alpha:/etc/openvpn# openvpn --genkey --secret secret.key

alpha:/etc/openvpn# cat secret.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
ae11344ce37de44dcce059ecf9fa573f
a2694d5531bc7ed144a12a099c4ef8ce
(... )
1d37552cd4f29ff6b719588056a60777
579cc2aff71bf339f5293bf08f2ce4df
-----END OpenVPN Static key V1-----
alpha:/etc/openvpn#
b. Fichiers de configuration
Les fichiers de configuration se trouvent par défaut dans un répertoire /etc/openvpn. Si l’usage veut que les fichiers
portent les noms client.conf et serveur.conf, n’importe quel fichier avec l’extension .conf fera l’affaire.
Format du fichier de configuration OpenVPN
remote serveur
dev tun
ifconfig IP_locale IP_distante
secret fichier_cle
route réseau_distant masque
Fichier de configuration OpenVPN : directives courantes
remote serveur Sur le client uniquement. serveur indique le nom ou l’adresse
ip du serveur auquel connecter le VPN.
dev tun Crée une d’encapsulation de type tunnel (par opposition à
l’encapsulation ethernet bridgée).
ifconfig IP_locale IP_distante Établit les adresses locales et distantes des extrémités de
trafic. Ces adresses seront visibles sous forme d’interface
virtuelle dans la configuration réseau de l’hôte.
secret fichier_cle Indique le fichier contenant la clé partagée, identique sur les
deux machines.
route réseau_distant masque Paramètre client : indique l’adresse du réseau privé derrière le

serveur pour que le trafic à destination de ce réseau soit
correctement routé par le VPN.
Exemple de fichiers de configuration OpenVPN
Fichier de configuration côté serveur.
alpha:/etc/openvpn# cat server.conf

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret secret.key
Fichier de configuration côté client.
beta:/etc/openvpn# cat client.conf

remote alpha

dev tun
ifconfig 10.8.0.2 10.8.0.1
secret secret.key
route 192.168.1.0 255.255.255.0
c. Mise en œuvre du tunnel vpn
Une fois les fichiers créés sur le serveur et le client, il suffit de démarrer de part et d’autre le service par son script de
démarrage.
La validation de fonctionnement peut se faire par un ping entre les deux adresses de tunnel. Une capture de trames
permettra aussi d’observer un trafic entre les deux machines sur le port UDP/1194 par défaut.
Exemple de test d’un tunnel pointàpoint
On lance le service par son script normalisé, on vérifie la présence d’une interface virtuelle, et on contrôle le
fonctionnement du tunnel par un trafic quelconque.
beta:~# ifconfig tun0

tun0: erreur lors de la recherche d’infos sur l’interface: Périphérique non trouvé
beta:~# /etc/init.d/openvpn start
Starting virtual private network daemon: client.
beta:~# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.2 P-t-P:10.8.0.1 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
beta:~# ping 10.8.0.1


clavier.
1. Questions
1 Les concepts de sécurité principaux sont l’authentification, la confidentialité, et le contrôle d’intégrité. Le service
telnet est décrié pour son manque de sécurité, mais disposaitil toutefois de mécanismes de sécurité ?
2 Comment un client SSH conservetil une trace des serveurs auxquels il a déjà été connecté ?
3 La commande sshkeygen estelle mieux adaptée à la création de clés publiques ou privées ?
4 Quel moyen permet de conserver en mémoire les clés privées utilisées pour les authentifications et permettre
ainsi une utilisation plus confortable ?
5 Sur quel service s’appuie la commande scp sur la machine distante pour copier des fichiers de façon sécurisée ?
6 Comment appelleton le fonctionnement dans lequel un trafic applicatif est transporté par SSH, et est donc
protégé par les fonctions natives de sécurité de ce protocole ?
7 Estil possible de renvoyer des sessions d’affichage X11 dans un tunnel SSH ?
8 Quelle différence faiton entre un tunnel vpn siteàsite et un tunnel vpn pointàpoint ?
9 OpenVPN peutil connecter deux machines distantes sans assurer de routage entre les deux machines ?
10 Comment un utilisateur peutil visualiser qu’un tunnel OpenVPN est a priori monté sur sa machine ?
2. Réponses
1 Les concepts de sécurité principaux sont l’authentification, la confidentialité, et le contrôle d’intégrité. Le service
telnet est décrié pour son manque de sécurité, mais disposaitil toutefois de mécanismes de sécurité ?
Oui, celui qu’on estimait suffisant à l’époque de création du protocole. Telnet ne propose pas de contrôle d’intégrité
sérieux, ni de cryptage des données qui assurerait la confidentialité des échanges. En revanche, le protocole telnet
supporte une authentification par mot de passe. La défaillance de cette authentification est due à la transmission en
clair de ce mot de passe qui rend son interception relativement aisée.
2 Comment un client SSH conservetil une trace des serveurs auxquels il a déjà été connecté ?
Les clients conservent une trace de chaque connexion établie auprès de serveurs SSH en conservant une empreinte
numérique des serveurs dans un fichier known_hosts, situé dans un répertoire caché .ssh du répertoire personnel de
l’utilisateur. Il est important qu’il n’y ait pas de doute sur la validité du serveur : les cryptages utilisés par SSH
permettent de se mettre à l’abri de toutes les tentatives d’observation conduites avec des moyens raisonnables, mais
il est relativement facile d’usurper l’identité d’un serveur en prenant son nom et son adresse IP par exemple.
L’utilisateur taperait alors en toute confiance des commandes qui seraient récupérées par l’adversaire.
3 La commande sshkeygen estelle mieux adaptée à la création de clés publiques ou privées ?
La création des clés publiques et privées est nécessairement conjointe. Toute commande qui crée l’une doit
obligatoirement créer l’autre en même temps. Il arrive que le manuel ou les documentations mettent en avant une
opération plutôt qu’une autre, mais il est certain que le couple de clés est créé en même temps. Il est impossible en
possédant une clé publique de déterminer la clé privée correspondante et inversement.
4 Quel moyen permet de conserver en mémoire les clés privées utilisées pour les authentifications et permettre
ainsi une utilisation plus confortable ?
La commande sshagent permet ce stockage confortable des clés privées. Les clés privées (et publiques) sont
initialement créées par la commande sshkeygen, fournies à l’agent par la commande sshadd, lequel agent est chargé
par la commande sshagent. L’agent SSH est un programme résident dont les programmes requérant une
authentification seront les clients.
5 Sur quel service s’appuie la commande scp sur la machine distante pour copier des fichiers de façon sécurisée ?
La commande scp ne nécessite pas d’autre service sur la machine distante que le service SSH, également utilisé pour
les sessions distantes.
6 Comment appelleton le fonctionnement dans lequel un trafic applicatif est transporté par SSH, et est donc
protégé par les fonctions natives de sécurité de ce protocole ?
On parle de tunnel SSH. L’application n’est pas modifiée par ce fonctionnement, seul son transport est affecté.

7 Estil possible de renvoyer des sessions d’affichage X11 dans un tunnel SSH ?
Oui, mais il faut pour cela autoriser ce fonctionnement en renseignant la directive X11Forwarding à yes dans le fichier
de configuration sshd_config du serveur SSH.
8 Quelle différence faiton entre un tunnel vpn siteàsite et un tunnel vpn pointàpoint ?
Un tunnel pointàpoint relie deux machines entre elles de façon sécurisée. Toutes les fonctions de sécurité afférentes
au tunnel sont assurées (authentification, confidentialité, intégrité), mais entre ces deux machines seulement. Dans
un fonctionnement en mode siteàsite, les mêmes fonctions sont appliquées au tunnel, mais tous les hôtes des deux
réseaux connectés peuvent communiquer entre eux par l’intermédiaire du tunnel.
9 OpenVPN peutil connecter deux machines distantes sans assurer de routage entre les deux machines ?
Oui, c’est l’utilisation du mode bridgé dans lequel le tunnel relie directement les deux machines qui se trouvent alors
dans le même sousréseau. Cet usage est plutôt rare.
10 Comment un utilisateur peutil visualiser qu’un tunnel OpenVPN est a priori monté sur sa machine ?
En consultant la configuration réseau avec la commande ifconfig. Une interface virtuelle généralement appelée tun0
doit s’afficher avec l’adresse IP attachée à cette interface. La présence de cette interface virtuelle ne présage pas du
bon fonctionnement du tunnel, mais est nécessaire à son fonctionnement.

Travaux pratiques
De nouveaux besoins se font jour. Il est nécessaire d’accéder à un serveur intranet situé sur le serveur alpha depuis
l’extérieur. Vous hésitez entre deux solutions et décidez de les essayer toutes les deux.
Ces exercices supposent que le réseau de test a été réorganisé comme prévu dans les travaux pratiques du chapitre
Protection des réseaux.
1. Gestion du réseau de test
a. Repositionnement de la station de travail
Vous aurez besoin pour réaliser vos essais d’une station cliente située sur le réseau public. Il est possible d’utiliser
une nouvelle machine, mais le plus simple est de déplacer provisoirement la station Ubuntu sur le réseau public.
1. Dans les menus Virtualbox de la station cliente, développez Périphériques puis cliquez
sur Cartes réseau.
2. Dans l’onglet Carte 1, déroulez Mode d’accès réseau, et choisissez Accès par pont.
3. Dans la station de travail Ubuntu, développez le menu Système, puis Préférences, et
choisissez Connexions réseau.
4. Dans la fenêtre Connexions réseau, modifiez la connexion Fixe eth0 créée
précédemment.
5. Dans l’onglet Paramètres IPv4, modifiez l’adresse IP en 192.168.200.50
255.255.255.0. (ou une adresse située dans le plan d’adressage de votre réseau
public). Modifiez également la passerelle par défaut.
l’adresse publique du serveur beta (192.168.200.102 dans notre plan d’adressage). Si
nécessaire, réactivez la configuration Fixe eth0 en cliquant dessus depuis la barre de
menu supérieure icône réseau en haut à droite.
b. Arrêt du parefeu
Commandes utiles

● Scripts personnalisés de gestion du parefeu
● iptables
Manipulations
1. Afin de mener à bien vos essais sans interférence du parefeu, désactivezle sur le
serveur beta. Utilisez pour cela les scripts créés au chapitre précédent.
2. En cas de besoin seulement. Si vous ne disposez pas des scripts personnalisés, tapez
les commandes suivantes :
iptables -F
1. Vérifiez que tout filtrage est désormais annulé.
Résultat à l’écran
Utilisation des scripts personnalisés :
[root@beta ~]# service parefeu stop

[root@beta ~]# service parefeu status


[root@beta ~]#
Annulation manuelle du filtrage (si nécessaire) :
[root@beta ~]# iptables -F

[root@beta ~]# iptables -P INPUT ACCEPT
[root@beta ~]# iptables -P OUTPUT ACCEPT
[root@beta ~]# iptables -P FORWARD ACCEPT
[root@beta ~]# iptables -L


[root@beta ~]#
c. Installation de l’intranet
Installez si nécessaire un serveur Apache sur le serveur alpha avec la commande suivante :
apt-get install apache2
2. Création d’un tunnel SSH entre la station de travail et le serveur beta
Dans ce mode de fonctionnement, un tunnel SSH est établi entre le client et le serveur beta. Tout le trafic en réseau
public est donc protégé. Une fois ce tunnel établi, le client s’adresse à un de ses ports local, et le trafic est redirigé

vers une machine cible, audelà du tunnel.
a. Gestion de l’authentification
Puisque le tunnel est établi entre la station cliente publique et le serveur beta, il faut résoudre la question de
l’authentification entre ces deux machines. Soucieux d’offrir la solution la plus sécurisée, vous optez pour
l’authentification par clés SSH.
Commandes utiles
● mkdir
● scp
● sshkeygen
Manipulations
1. Sur la station cliente, créez la paire de clés nécessaire à l’authentification en utilisant
l’algorithme dsa. Acceptez les chemins et noms de fichiers par défaut. Protégez votre clé
privée par une phrase de passe (passphrase) de votre choix.
2. Sur le serveur beta, créez la structure de répertoires appropriée pour le stockage de la
clé publique de l’utilisateur qui établit le tunnel. Le fichier de clé publique doit se trouver
dans un répertoire .ssh/authorized_keys du répertoire personnel de l’utilisateur se
connectant.
3. Copiez la clé publique générée vers le répertoire approprié sur le serveur.
Génération des clés clientes sur la station de travail :
toto@ubuntu:~/temp$ ssh-keygen -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/toto/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/toto/.ssh/id_dsa.
Your public key has been saved in /home/toto/.ssh/id_dsa.pub.
The key fingerprint is:
fd:55:bf:50:a5:53:0e:21:92:0b:84:13:1c:96:63:6c toto@ubuntu
The key’s randomart image is:
+--[ DSA 1024]----+
| o+*. ... o.o|
| .E . .. . =.|
| o o . . o.o|
| .. .o.|
| S . .. .|
| . .. .|
| . . |
| |
| |
+-----------------+
toto@ubuntu:~/temp$
Création des répertoires nécessaires sur le serveur beta :
[toto@beta ~]$ hostname

beta
[toto@beta ~]$ id
uid=500(toto) gid=500(toto) groupes=500(toto)
[toto@beta ~]$ mkdir -p .ssh/authorized_keys
[toto@beta ~]$
Copie de la clé publique depuis la station sur le serveur :

toto@ubuntu:~/.ssh$ whoami
toto
toto@ubuntu:~/.ssh$ hostname
ubuntu
toto@ubuntu:~/.ssh$ ls
id_dsa id_dsa.pub known_hosts
toto@ubuntu:~/.ssh$ scp id_dsa.pub toto@192.168.200.102:/home/toto/.ssh/authorized_keys
id_dsa.pub 100% 597 0.6KB/s 00:00
toto@ubuntu:~/.ssh$
b. Création du tunnel
Commandes utiles
● ssh
Manipulations
1. Depuis la station de travail publique, établissez un tunnel vers le serveur beta
redirigeant le port local 1234 vers le serveur interne alpha sur le port 80. L’utilisateur
propriétaire du tunnel sera toto.
Établissement du tunnel :
toto@ubuntu:~$ ssh -L 1234:192.168.199.10:80 toto@192.168.200.102

Last login: Mon Aug 16 13:39:04 2010 from 192.168.200.50
[toto@beta ~]$
c. Validation
Commandes utiles
● navigateur web
● netstat
Manipulations
1. Depuis la station cliente sur le navigateur, ouvrez une session web vers ellemême
(localhost) sur le port 1234. La page web par défaut du serveur alpha doit s’afficher.
Les données n’ont pas été transmises en clair entre la station et le serveur beta.
2. Sur le serveur beta, constatez qu’une session SSH existe bien entre le client et le
serveur beta, et qu’une session http existe bien entre le serveur beta et le serveur
alpha.
3. Sur le serveur alpha, constatez qu’une session http est bien ouverte par le serveur beta
(extrémité du tunnel).
Vérification des sessions tcp sur le serveur beta :
[root@beta ~]# netstat -n | head -5

Connexions Internet actives (sans serveurs)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.199.1:34210 192.168.199.10:80 ESTABLISHED

tcp 0 0 192.168.200.102:22 192.168.200.50:46647 ESTABLISHED
Sockets du domaine UNIX actives(sans serveurs)
[root@beta ~]#
Vérification des sessions tcp sur le serveur alpha :
alpha:/var/www# netstat -n | head -5

Connexions Internet actives (sans serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat
tcp6 0 0 192.168.199.10:80 192.168.199.1:45678 TIME_WAIT
Sockets du domaine UNIX actives(sans serveurs)
Proto RefCnt Flags Type State I-Node Chemin
alpha:/var/www#
3. Création d’un tunnel VPN entre la station de travail et le serveur beta
a. Installation des binaires
Installez OpenVPN sur le client Ubuntu avec la commande suivante :
sudo apt-get install openvpn
OpenVPN ne fait pas partie des paquetages standard de la distribution CentOS. La solution proposée ici est
d’ajouter le paquetage ETEL, un projet libre qui vise à fournir aux distributions Fedora et Centos des logiciels à
vocation professionnels non inclus par défaut dans ces distributions. Une solution plus simple consisterait à réaliser
les tests sur des distributions Debian ou Ubuntu exclusivement.
1. Depuis le serveur beta, téléchargez la version en cours du paquetage ETEL à l’adresse
suivante : http://download.fedora.redhat.com/pub/epel/5/i386/repoview/epel
release.html.
2. Installez le paquetage epel téléchargé avec la commande suivante :
rpm -i epel-release-x-y.rpm
3. Installez enfin openvpn avec la commande suivante :
yum install openvpn
b. Gestion de l’authentification
Commandes utiles
● openvpn
● scp
Manipulations
1. Sur le client, générez une clé exploitable par OpenVPN. Stockez cette clé dans un fichier
cle.sec.
2. Copiez le fichier contenant la clé sur le serveur beta.
Génération de la clé sur le client :
toto@ubuntu:~$ openvpn --genkey --secret cle.sec

toto@ubuntu:~$ cat cle.sec
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
5e1daf78432b5217c1be08b151630622
2f3df08093262bd5e8e12dfddb180f9b
1bb06c684d842bacbe9b67bb3fe76830
3e23899306d15f33451028e8e1a7d78a
d6850f6cfe666d710e5a840e00fc3d18
d1328b3474a23441353983a697ff04c5
45a8457f2e085883e4565df8a920a655
a98ee7252e9f9e8b0377a2988a261d4c
38d0e02407ed26003fab943f8dde4399
67d053533c807bede026c0be5efe2fe7
987103e4d864ca4799be62a52b2cb47c
2d1c0e76c468a3b8d69c4662debfbb0d
ea722255a0158451b5d21187d54258d1
9ff4cdbdc8f8dd4553b96a303c866f1d
2b360353c78797110ab8c06fd96e58d3
8b283865278e1629fb2054f67e4f52e9
-----END OpenVPN Static key V1-----
toto@ubuntu:~$
Copie de la clé sur le serveur :
toto@ubuntu:~$ scp cle.sec toto@192.168.200.102:/home/toto/cle.sec

cle.sec 100% 636 0.6KB/s 00:00
toto@ubuntu:~$
c. Configuration du client
Commandes et directives utiles
● dev
● ifconfig
● remote
● route
● secret
● vi
Manipulations
1. Sur la station cliente, créez un fichier de configuration /etc/openvpn/client.conf.
2. Dans le fichier de configuration, indiquez que le serveur distant est beta.
3. Indiquez que vous souhaitez travailler en mode tunnel.
4. Indiquez que votre adresse locale (côté client) sera 10.9.9.2.
5. Indiquez que l’adresse distante (côté serveur) sera 10.9.9.1.
6. Indiquez quel est le fichier de clé secrète à employer.
7. Indiquez que le client doit avoir accès au réseau privé.

Fichier /etc/openvpn/client.conf sur la station cliente :
remote 192.168.200.102
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret /home/toto/cle.sec
route 192.168.199.0 255.255.255.0
d. Configuration du serveur
Commandes utiles
● ifconfig
● vi
Directives utiles
● dev
● route
● secret
Manipulations
1. Sur le serveur beta, créez un fichier de configuration /etc/openvpn/serveur.conf.
2. Dans le fichier de configuration, indiquez que vous souhaitez travailler en mode tunnel.
3. Indiquez que votre adresse locale (côté client) sera 10.9.9.2.
4. Indiquez que l’adresse distante (côté serveur) sera 10.9.9.1.
5. Indiquez quel est le fichier de clé secrète à employer.
6. Indiquez que le client doit avoir accès au réseau privé.
Fichier /etc/openvpn/serveur.conf sur le serveur :
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret /home/toto/cle.sec
e. Validation
Commandes utiles
● Navigateur internet
● ping
Manipulations
1. Démarrez le service openvpn sur le serveur beta.

2. Démarrez le service openvpn sur la station cliente.
3. Visualisez les adresses ip virtuelles ajoutées aux deux machines.
4. Validez la connexion avec un ping.
5. Depuis un navigateur sur la station de travail, connectezvous en http sur l’adresse IP
du serveur alpha. Vérifiez que la page web s’affiche bien.
Démarrage du service sur le serveur beta :
[root@beta openvpn]# service openvpn start

Démarrage de openvpn : [ OK ]
[root@beta openvpn]# ifconfig
(...)
(...)
inet adr:127.0.0.1 Masque:255.0.0.0
(...)
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@beta openvpn]#
Démarrage du service sur la station cliente :
toto@ubuntu:/etc/openvpn$ sudo /etc/init.d/openvpn start

* Starting virtual private network daemon(s)...
* Autostarting VPN ’client’ [ OK ]
toto@ubuntu:/etc/openvpn$ ifconfig
(...)
inet adr:127.0.0.1 Masque:255.0.0.0
(...)
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
toto@ubuntu:/etc/openvpn$
Vérification depuis le client :
toto@ubuntu:/etc/openvpn$ ping -c 1 192.168.200.102

--- 192.168.200.102 ping statistics ---

toto@ubuntu:/etc/openvpn$ ping -c 1 192.168.199.10

--- 192.168.199.10 ping statistics ---

toto@ubuntu:/etc/openvpn$
Notez qu’avec le tunnel OpenVPN, on obtient des interfaces virtuelles sur lesquelles peuvent s’appuyer
n’importe quelles applications. Avec le tunnel SSH, on est étroitement lié à l’application associée au tunnel.

1. Prérequis

Connaître les formats de compression gzip et bzip2.
Connaître le format d’archivage cpio.
2. Objectifs

Connaître le principe d’une application compilée.
Gérer les bibliothèques applicatives.
Réaliser une compilation GNU classique.
Installer et désinstaller des sources compilées.
Gérer des modules de noyau.
Patcher une application.
Préparer la compilation d’un noyau (tous paramètres par défaut).
Compiler un noyau.
Intégrer un nouveau noyau dans un système existant.

Compilation des applications
1. Généralités
a. Principe de la compilation
Les programmes utilisés en informatique en général appartiennent à deux familles : les programmes interprétés et
les programmes compilés. Un programme interprété est écrit dans un langage de programmation (basic, perl, shell,
etc.), et doit pour son exécution être lu par un programme spécifique appelé interpréteur. À chacune de ses
exécutions, l’interpréteur doit reparcourir le code du programme. Un programme compilé est écrit avec un langage de
programmation (Pascal, C, C++, etc.), et est ensuite passé au travers d’un compilateur. Le compilateur est un
programme exécutable qui lit le code du programme à compiler (appelé code source), et qui génère lors de cette
opération un autre programme exécutable, binaire, qui pourra s’exécuter indépendamment du compilateur. La
plupart des programmes utilisés en environnement Linux sont de type compilé, et le noyau Linux en est un exemple
particulier.
b. Quand fautil compiler ?
Les applicatifs sont la plupart du temps fournis sous forme de paquetage déjà compilé, et prêts à l’emploi. Dans ces
conditions, la compilation est une opération qui revient au créateur du paquetage, et l’utilisateur n’a pas à s’en
préoccuper. Le succès de distributions comme Ubuntu vient en partie du très grand nombre de paquetages présents
et disponibles à la demande.
Il arrive toutefois qu’on doive compiler soimême une application. Par exemple parce qu’on souhaite avoir une
version de logiciel récente qui n’est pas disponible sous forme de paquetage, ou bien que le paquetage n’existe pas
dans notre distribution. Par ailleurs, la compilation peut être personnalisée par des options, et le créateur d’un
paquetage a forcément fait pour son paquet des choix arbitraires quant à ces options de compilation. Dans ces
conditions, on peut souhaiter compiler soimême son application et obtenir ainsi un fonctionnement spécifique.
c. Rappels sur les utilitaires de décompression
Les sources de programmes utilisées lors de la compilation d’applications sont presque toujours fournies sous forme
d’archives compressées. Il faut donc se souvenir des syntaxes permettant de gérer les archives au format tar
compressé, de loin le plus courant.
Décompression d’une archive au format tar compressé en gzip
tar xzf archive.tgz
Décompression d’une archive au format tar compressé en bzip2
tar xjf archive.tar.bzip2
L’extension des fichiers est strictement conventionnelle et peut varier.
2. Procédure de compilation GNU
Dans la plupart des situations, la compilation est une opération qui échoie au développeur : le développeur écrit son
programme, le compile, et livre le code exécutable prêt à l’emploi. Les compétences nécessaires à la compilation sont
donc généralement ignorées du grand public. Le monde open source change un peu la donne où les codes sources de
tous les programmes sont par définition disponibles et où il arrive que fréquemment que l’utilisateur final doive
compiler luimême son application. Une procédure de compilation standard a donc été définie, afin qu’un utilisateur non
averti soit capable de réaliser cette opération.
a. Récupération des sources
Le code source d’une application open source est par définition toujours disponible, en général sur un site web
attaché au projet de développement de l’application. Le site web sourceforge.net accueille en particulier de
nombreux projets de développement.

Une fois les sources téléchargées, il suffit de les extraire de leur archive et de se placer dans le répertoire ainsi
extrait. Toutes les opérations relatives à la compilation se réaliseront depuis la racine de ce répertoire.
b. Configuration de la compilation
La compilation suppose un certain nombre de prérequis : la présence du compilateur, l’éventuelle présence de
bibliothèques nécessaires à la compilation du programme, et surtout un fichier de réponses qui sera lu par le
compilateur pendant la compilation. Dans le cadre de la procédure standard de compilation GNU, un script nommé
configure doit se trouver dans le répertoire racine des sources, et ce script est précisément chargé de réaliser ces
trois opérations. Ce script a été écrit par le développeur du programme et est livré avec les sources.
Lors de son exécution, éventuellement avec des options de compilation, ce script va vérifier l’environnement et
renvoyer un message d’erreur en cas de défaut de l’environnement de compilation (compilateur et bibliothèques
nécessaires). Si tout va bien, ce script finit par la génération de fichiers de réponses (un par sousrépertoire présent
dans le répertoire des sources) nommés Makefile. Ces fichiers de réponses sont euxmêmes créés à partir des
options passées au script de configuration et d’un fichier modèle Makefile.in. Si l’observation du contenu de ces
fichiers peut répondre à une curiosité bien légitime, elle n’est absolument pas nécessaire pour la suite des
opérations.
Exécution du script configure sans option
On lance le script de configuration depuis le répertoire racine des sources. On constate à la fin du traitement la mention «
creating Makefile » qui est le but ultime de l’exécution du script.
[root@beta rdesktop-1.6.0]# ./configure

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
(...)
checking for setmntent... yes
checking build system type... i686-redhat-linux-gnu
checking host system type... i686-redhat-linux-gnu
configure: creating ./config.status
config.status: creating Makefile
[root@beta rdesktop-1.6.0]#
Gestion des défaillances par le script de configuration
Le script de configuration détecte ici l’absence de bibliothèques nécessaires. On est ici particulièrement chanceux avec un
conseil précis de la part du script, ce qui est loin d’être le cas général.

checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
(...)
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for X... no
ERROR: Could not find X Window System headers/libraries.

Probably you need to install the libx11-dev package.
To specify paths manually, use the options --x-includes and --x-libraries.
c. Personnalisation des programmes compilés
Le développeur peut prévoir lors de la rédaction de son script de configuration des options de compilation. Le fichier
Makefile sera alors généré en fonction des options ajoutées lors du lancement du script configure. La liste des
options est disponible en tapant la commande ./configure help.

Exécution du script configure avec options
On exécute d’abord le script configure avec l’option help pour prendre connaissance des options disponibles, puis avec la
ou les options choisies.
[root@beta rdesktop-1.6.0]# ./configure --help

`configure’ configures rdesktop 1.6.0 to adapt to many kinds of systems.
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as

VAR=VALUE. See below for descriptions of some of the useful variables.
Defaults for the options are specified in brackets.
Configuration:
-h, --help display this help and exit
--help=short display options specific to this package
--help=recursive display the short help of all the included packages
-V, --version display version information and exit
-q, --quiet, --silent do not print `checking...’ messages
--cache-file=FILE cache test results in FILE [disabled]
-C, --config-cache alias for `--cache-file=config.cache’
-n, --no-create do not create output files
--srcdir=DIR find the sources in DIR [configure dir or `..’]
(...)
[root@beta rdesktop-1.6.0]# ./configure --with-ipv6
(...)
d. Compilation
La compilation se réalise simplement par la commande make, exécutée sans paramètre ni option depuis le répertoire
racine des sources où se trouvent les fichiers Makefile et Makefile.in. Cette opération est assez longue et aboutit si
tout se passe bien à la génération des fichiers binaires compilés. Il est à noter qu’à cette étape, ces fichiers se
trouvent exclusivement dans l’arborescence des sources.
Compilation mal préparée
On tente ici de réaliser une compilation par la commande make sans avoir auparavant configuré la compilation.
[root@beta rdesktop-1.6.0]# make

make: *** Pas de cibles spécifiées et aucun makefile n’a été trouvé. Arrêt.
Compilation sans encombre
La commande de compilation make a trouvé ses fichier de réponse.

(...)
gcc -g -O2 -Wall -I/usr/include -DPACKAGE_NAME=\"rdesktop\"
-DPACKAGE_TARNAME=\"rdesktop\" -DPACKAGE_VERSION=\"1.6.0\"
-DPACKAGE_STRING=\"rdesktop\ 1.6.0\" -DPACKAGE_BUGREPORT=\"\"
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DL_ENDIAN=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_LOCALE_H=1 -DHAVE_LANGINFO_H=1 -Dssldir=\"/usr\"
-DEGD_SOCKET=\"/var/run/egd-pool\" -DWITH_RDPSND=1 -DRDPSND_OSS=1

-DHAVE_DIRENT_H=1 -DHAVE_DIRFD=1 -DHAVE_DECL_DIRFD=1 -DHAVE_ICONV_H=1
-DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_SYS_VFS_H=1 -DHAVE_SYS_STATVFS_H=1
-DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_MOUNT_H=1
-DSTAT_STATVFS=1 -DHAVE_STRUCT_STATVFS_F_NAMEMAX=1 -DHAVE_STRUCT_STATFS_F_NAMELEN=1
-DHAVE_MNTENT_H=1 -DHAVE_SETMNTENT=1
-DKEYMAP_PATH=\"/usr/local/share/rdesktop/keymaps/\" -o rdesktop
rdesktop.o xwin.o xkeymap.o ewmhints.o xclip.o cliprdr.o rdpsnd.o
rdpsnd_dsp.o rdpsnd_oss.o tcp.o iso.o mcs.o secure.o licence.o
rdp.o orders.o bitmap.o cache.o rdp5.o channels.o rdpdr.o serial.o
printer.o disk.o parallel.o printercache.o mppc.o pstcache.o lspci.o
seamless.o ssl.o -L/usr/lib -lcrypto -lX11
e. Les cibles de la commande make
La commande make permet de réaliser la compilation proprement dite, mais la même commande appelée avec
certains arguments permet de réaliser des actions diverses autour de la compilation. On appelle ces arguments des
cibles. Toutes les cibles ne sont pas toujours disponibles, et leur présence dépend des objectifs du développeur. Les
cibles d’installation des binaires ou de nettoyage simple des sources sont néanmoins toujours disponibles.
f. Installation des binaires
Depuis le répertoire des sources, il faut ensuite taper la commande make install pour provoquer l’installation des
fichiers binaires compilés dans leurs répertoires de destination au sein de l’arborescence du système de fichiers
Linux. L’installation peut aussi provoquer la copie des fichiers de manuel ou de configuration.
Installation automatique de tous les éléments compilés
La commande make exécutée avec la cible install copie les fichiers binaires compilés ainsi que tout élément prévu par le
développeur. Les droits d’écriture sur les répertoires cibles sont nécessaires.
[root@beta rdesktop-1.6.0]# make install

mkdir -p /usr/local/bin
/usr/bin/install -c rdesktop /usr/local/bin
/usr/bin/install:
(...)
g. Nettoyage des sources
La commande make clean exécutée depuis le répertoire racine des sources nettoie l’arborescence de tout élément
déjà compilé et permet de relancer une autre compilation à partir des mêmes sources et du même environnement.
La commande make mrproper permet comme son nom l’indique un nettoyage complet de tout élément généré
localement, des fichiers compilés aux fichiers de configuration (Makefile) générés auparavant.
Nettoyage simple des sources
La commande make exécutée avec la cible clean efface tous les éléments générés par la compilation mais laisse les fichiers
de configuration en place.
[root@beta rdesktop-1.6.0]# ls Makefile

Makefile
[root@beta rdesktop-1.6.0]# make clean
rm -f *.o *~ vnc/*.o vnc/*~ rdesktop rdp2vnc
[root@beta rdesktop-1.6.0]# ls Makefile
Makefile
h. Désinstallation d’un programme
La commande make uninstall exécutée depuis le répertoire racine des sources nettoie le système de tous les

fichiers installés par la commande make install.
Récapitulatif de la procédure de compilation standard GNU
cd rep_sources
./configure
make
make install
Où rep_sources représente le répertoire des sources, obtenu par extraction de l’archive tar compressée.
3. Environnement des applications
a. Les bibliothèques
Une bibliothèque (library en anglais) est un ensemble d’éléments préprogrammés utilisable par les développeurs. Ils
peuvent ainsi gagner du temps par la réutilisation de fonctions courantes et s’affranchir de la réécriture de fonctions
triviales. L’usage de bibliothèques en environnement graphique permet aussi de donner une unité aux programmes
avec des éléments d’interfaces cohérents.
La bibliothèque libstdc++ est presque toujours disponible sur les systèmes Linux car exploitée par de nombreux
programmes, et les applications graphiques exploitent fréquemment les bibliothèques gtk ou qt. Il existe des
centaines de bibliothèques actives utilisées en environnement Linux. Elles sont normalement situées dans le
répertoire /usr/lib.
La plupart des programmes sont compilés de façon dynamique (par opposition à statique). C’estàdire qu’ils
reposent sur les mêmes bibliothèques que celles employées par le développeur, mais qui sont présentes localement
sur le système. Les applications doivent donc impérativement disposer des bonnes bibliothèques au moment de leur
exécution.
On peut vérifier quelles sont les bibliothèques nécessaires à un exécutable par la commande ldd.
Visualisation des bibliothèques utilisées par un exécutable
On observe pour chaque bibliothèque le fichier correspondant présent sur le disque.
alpha:~# ldd /bin/ls

linux-gate.so.1 => (0xb775b000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7744000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb772b000)
libacl.so.1 => /lib/libacl.so.1 (0xb7723000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb75c8000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb75af000)
/lib/ld-linux.so.2 (0xb775c000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb75ab000)
libattr.so.1 => /lib/libattr.so.1 (0xb75a6000)
alpha:~#
La commande ldconfig permet de créer les liens entre les applications et les bibliothèques présentes sur le système.
Elle regarde dans son fichier de configuration /etc/ld.so.conf quels sont les chemins à analyser lors de la recherche
de bibliothèques. Un fichier /etc/ld.so.cache contenant la liste des bibliothèques est alors généré.
Prise en compte des bibliothèques locales
ldconfig
Affichage des bibliothèques exploitables
ldconfig -p
Création du fichier de cache avec ldconfig
On efface ici le cache pour vérifier que le fichier est bien créé par la commande.
root@beta:~$ rm /etc/ld.so.cache

root@beta:~$ ls /etc/ld.so.cache
ls: ne peut accéder /etc/ld.so.cache: Aucun fichier ou dossier de ce type
root@beta:~$ ldconfig
root@beta:~$ ls /etc/ld.so.cache
/etc/ld.so.cache
root@beta:~$
Visualisation des bibliothèques
On constate que la commande ldconfig p s’appuie sur le fichier de cache qu’elle a auparavant généré.
[root@beta ~]# ldconfig -p

776 libs found in cache `/etc/ld.so.cache’
libz.so.1 (libc6) => /usr/lib/libz.so.1
libz.so (libc6) => /usr/lib/libz.so
libxslt.so.1 (libc6) => /usr/lib/libxslt.so.1
libxslt.so (libc6) => /usr/lib/libxslt.so
libxml2.so.2 (libc6) => /usr/lib/libxml2.so.2
libxml2.so (libc6) => /usr/lib/libxml2.so
libxmlsec1.so.1 (libc6) => /usr/lib/libxmlsec1.so.1
libxmlsec1.so (libc6) => /usr/lib/libxmlsec1.so
libxklavier.so.11 (libc6) => /usr/lib/libxklavier.so.11
(...)
[root@beta ~]#
Il est aussi possible pour un usage ponctuel de renseigner un chemin de bibliothèques dans une variable système
LD_LIBRARY_PATH.
Déclaration de chemins de bibliothèques
LD_LIBRARY_PATH=chemin1:chemin2:...:cheminn
export LD_LIBRARY_PATH
Où les cheminx représentent le chemin absolu du répertoire contenant les directives.
b. Visualisation des appels systèmes
Il est possible de tester le fonctionnement des applications en visualisant les appels systèmes réalisés par
l’application lors de son exécution. La commande strace appliquée à un programme intercepte les appels systèmes
réalisés par un processus ainsi que les signaux reçus par ce processus. Cette commande, utile aux développeurs,
est d’un usage délicat pour les nonspécialistes. La commande ltrace, similaire se cantonne aux chargements de
bibliothèque et ignore les appels systèmes.
Exemple d’utilisation de la commande strace
On constate l’appel de diverses bibliothèques lors de l’exécution de la commande echo.
[root@beta ~]# strace echo bonjour

execve("/bin/echo", ["echo", "bonjour"], [/* 35 vars */]) = 0
brk(0) = 0x9d71000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=60638, ...}) = 0
mmap2(NULL, 60638, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fe8000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\317\270\0004\
0\0\0"..., 512) = 512
(...)
brk(0) = 0x9d71000
brk(0x9d92000) = 0x9d92000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=56464512, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7de6000
close(3) = 0

fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7ff6000
write(1, "bonjour\n", 8bonjour
) = 8
close(1) = 0
munmap(0xb7ff6000, 4096) = 0
exit_group(0) = ?
[root@beta ~]#

Compilation du noyau
Du point de vue de la compilation, le noyau est presque une application comme les autres, avec un code source, une
procédure de compilation et une procédure d’installation.
1. Les composants du noyau
Le noyau Linux est responsable de la gestion du matériel. La notion de pilote de périphérique n’existe pas directement
en environnement Linux puisque les éléments permettant de communiquer correctement avec un périphérique sont
compris dans le code du noyau. On se rend assez vite compte du confort de cette situation : le noyau récent compris
dans une distribution Linux permet de gérer directement l’ensemble des périphériques d’un système sans avoir à
installer des pilotes supplémentaires. En contrepartie, le code du noyau pour gérer l’ensemble des périphériques
existant a tendance à devenir de plus en plus imposant, et son chargement intégral entraînerait une consommation de
mémoire démesurée. Pour cette raison, le noyau a une structure modulaire, et seuls les modules nécessaires au
fonctionnement du système sont chargés en mémoire.
a. Le cœur de noyau
Ce que l’on peut appeler le « cœ ur de noyau » est la partie irréductible du noyau, celle qui sera intégralement
chargée en mémoire. Elle ne contient en principe que des éléments dont on est sûr qu’ils seront nécessaires à
l’utilisation. Le cœ ur de noyau est un fichier se trouvant dans le répertoire /boot et dont la taille est de quelques
MégaOctets.
b. Les modules
L’importance des modules de noyau
Les modules ont un rôle primordial car beaucoup de fonctions essentielles sont gérées sous forme de modules. Si un
noyau ne dispose pas des modules nécessaires au fonctionnement du système, les fonctions afférentes ne seront
tout simplement pas disponibles.
Tentative de chargement d’une ressource non supportée
Cet exemple est réalisé sur un système dont le noyau ne supporte pas le format de filesystem ext3.
light:/mnt# mount /dev/hda3 partition

mount: unknown filesystem type ’ext3’
light:/mnt#
Les modules sont des fichiers portant l’extension .ko qui sont chargés en mémoire en fonction des besoins. Des
commandes sont disponibles pour consulter la liste des modules chargés, en retirer de la mémoire ou en charger de
nouveaux.
Les noyaux de versions anciennes (2.4 notamment) exploitent des fichiers de modules portant l’extension
« .o ».
Manipulations ponctuelles des modules
Affichage des modules chargés en mémoire
lsmod
Affichage des modules disponibles sur le système
modprobe -l
Les fichiers correspondants à ces modules se trouvent conventionnellement dans un répertoire /lib/modules et
dans une sousarborescence du nom noyau courant, tel que renvoyé par la commande uname r.
Retrait d’un module chargé en mémoire

rmmod nom_module
ou
modprobe -r nom_module
Où nom_module représente le nom du module présent en mémoire tel qu’il a été affiché par la commande lsmod. Les
deux commandes rmmod et modprobe r ont le même résultat.
Chargement d’un module en mémoire
insmod fichier_module
ou
modprobe nom_module
Où nom_module représente le nom du module tel qu’il serait affiché par la commande lsmod, alors que fichier_module
représente le nom du fichier de module présent sur le disque. En fait, le nom du module est obtenu en retirant
l’extension .ko au nom du fichier.
Chargement d’un module
Le chargement manuel du module qui manquait précédemment rend possible le montage de la partition ext3.
light:/mnt# insmod /lib/modules/2.6.26-2-686/kernel/fs/ext3/ext3.ko

light:/mnt# mount /dev/hda3 partition
light:/mnt# mount
/dev/hda1 on / type ext2 (rw,errors=remount-ro)
(...)
/dev/hda3 on /mnt/partition type ext3 (rw)
light:/mnt#
Chargement forcé d’un module
Les modules sont en principe chargés au démarrage en fonction de la détection du matériel présent. Il est toutefois
possible de forcer le chargement d’un module en alimentant un fichier de configuration des modules. Tout module
mentionné dans un fichier /etc/modules sera chargé inconditionnellement au démarrage.
Configuration des modules
Le fichier /etc/modules.conf permet de configurer certains modules et notamment de définir des associations
forcées entre périphérique et modules.
Exemple de fichier /etc/modules.conf
# Association forcée du pilote tg3 avec la carte réseau

alias eth0 tg3
À titre de vérification ou pour voir si les associations entre le matériel et les modules se sont bien réalisées, il est
possible d’afficher des informations sur les modules chargés avec la commande modinfo.
Visualisation des informations liées à un module
On voit notamment le fichier .ko contenant le code du module, quelques informations d’environnement et les alias gérés
dynamiquement par le système pour les matériels liés à ce module.
root@serveur:/boot$ modinfo r8169

filename: /lib/modules/2.6.32-24-generic/kernel/drivers/net/r8169.ko
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
srcversion: D37E06388C6313C1D062CC3
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*

alias: pci:v00001186d00004300sv*sd*bc*sc*i*
depends: mii
vermagic: 2.6.32-24-generic SMP mod_unload modversions
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
root@serveur:/boot$
c. Autour du noyau
Nous savons maintenant que le noyau est constitué d’une entité insécable, et de modules chargés en mémoire à la
demande. Lors de la phase de démarrage, le gestionnaire de démarrage charge le noyau, et les modules
correspondants à la configuration matérielle du système sont également chargés. Pour accélérer la phase de
détection du matériel et le chargement des modules associés, la plupart des systèmes modernes exploitent un
ramdisk (disque virtuel dont le support physique est la mémoire) contenant l’ensemble des modules. Ce ramdisk est
généré après la compilation du noyau, et est appelé directement par le gestionnaire de démarrage.
d. Gestion des versions du noyau
Le noyau porte un numéro de version de type A.B.C, par exemple 2.6.15. « A » donne la version principale du noyau,
actuellement, et pour sans doute encore quelques temps, la version 2. « B » représente la version courante du
noyau. Cette valeur est systématiquement paire sur les versions de noyaux stables et impaire sur les versions en
développement. Enfin, « C » est incrémenté en fonction des évolutions mineures de noyau, essentiellement les
corrections de bogues et les prises en charge de nouveaux matériels.
La commande uname r permet d’afficher la version du noyau en cours d’exécution.
Affichage de la version du noyau courant
toto@serveur:~$ uname -r
2.6.32-24-generic
toto@serveur:~$
2. Procédure de compilation et d’exploitation
La procédure de compilation doit toujours être consultée dans le fichier README présent avec les sources du noyau.
Les éléments spécifiques du noyau sont documentés dans un répertoire Documentation fourni avec les sources. Le
fichier README ne documente que la procédure de compilation.
Le code source du noyau est téléchargeable librement depuis le site « http://www.kernel.org ». Les principales
versions y sont disponibles. Les liens « Full source » permettent de télécharger le code source complet du noyau.
Le noyau étant livré sous forme d’une archive tar.bz2, il faut d’abord la décompresser. Comme pour toute compilation
d’application, la majeure partie du travail se passera dans le répertoire issu de l’extraction de l’archive.
Si on travaille sur les sources de noyau copiées lors de l’installation du système, le répertoire de travail devrait
être /usr/src/linux. La documentation se trouvera alors naturellement dans /usr/src/linux/Documentation. En cas de
travail sur des sources nouvelles, un répertoire neutre est recommandé.
b. Génération du fichier de réponse
La compilation s’effectue en fonction des informations données dans un fichier .config qui se trouve dans la racine du
répertoire des sources. Ce fichier indique pour chaque élément du noyau s’il doit être présent dans le cœ ur de
noyau, présent sous forme de module, ou absent du noyau compilé.
Selon le système employé, plusieurs moyens sont à notre disposition pour générer ce fichier de réponse.

Génération du fichier de réponses : commandes possibles
make config Pose la question à l’utilisateur pour chacun des modules.
make menuconfig Présente une interface texte améliorée.
make xconfig Présente une interface graphique.
make gconfig Présente une interface graphique.
make defconfig Génère un fichier de réponse en s’appuyant sur toutes les valeurs de compilation par
défaut.
make oldconfig Génère un fichier de réponse en s’appuyant sur un fichier .config déjà utilisé pour
une version plus ancienne du noyau.
Si la compilation du noyau ne présente pas de difficulté particulière, le renseignement du fichier de réponse requiert
une compétence étendue et la connaissance précise du matériel.
Exemple de création du fichier de réponses
La compilation précise du noyau nécessite une connaissance de toutes les technologies matérielles gérées par ce noyau.
[root@beta linux-2.6.34.4]# make config

HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/basic/hash
HOSTCC scripts/kconfig/conf.o
(...)
PentiumPro memory ordering errata workaround (X86_PPRO_FENCE) [Y/n/?] y
HPET Timer Support (HPET_TIMER) [Y/n/?] y
Maximum number of CPUs (NR_CPUS) [8] (NEW) 8
SMT (Hyperthreading) scheduler support (SCHED_SMT) [Y/n/?] y
Multi-core scheduler support (SCHED_MC) [Y/n/?] y
Preemption Model
1. No Forced Preemption (Server) (PREEMPT_NONE)
> 2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY)
3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT)
choice[1-3]: 2
Reroute for broken boot IRQs (X86_REROUTE_FOR_BROKEN_BOOT_IRQS) [N/y/?] (NEW) n
Machine Check / overheating reporting (X86_MCE) [Y/n/?] n
Toshiba Laptop support (TOSHIBA) [M/n/y/?] n
Dell laptop support (I8K) [M/n/y/?] m
Enable X86 board specific fixups for reboot (X86_REBOOTFIXUPS) [N/y/?]n
(...)
CRC-CCITT functions (CRC_CCITT) [M/y/?] m
CRC16 functions (CRC16) [M/y/?] m
CRC calculation for the T10 Data Integrity Field (CRC_T10DIF) [N/m/y/?] (NEW) m
CRC ITU-T V.41 functions (CRC_ITU_T) [M/y/?] m
CRC32 functions (CRC32) [Y/?] y
CRC7 functions (CRC7) [N/m/y/?] (NEW) n
CRC32c (Castagnoli, et al) Cyclic Redundancy-Check (LIBCRC32C) [Y/m/?] y
#
# configuration written to .config
#
[root@beta linux-2.6.34.4]#
Premières lignes du fichier de configuration
[root@beta linux-2.6.34.4]# head -15 .config

#

# Automatically generated make config: don’t edit
# Linux kernel version: 2.6.34.4
# Mon Aug 16 16:57:44 2010
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
Taille indicative du fichier de configuration
[root@beta linux-2.6.34.4]# wc -l .config

3641 .config
La configuration des modules pour une version de noyau installée doit se trouver dans un fichier configversion dans
le répertoire /boot.
Visualisation des fichiers de configuration des noyaux
root@serveur:/boot$ ls config*
config-2.6.27-11-generic config-2.6.32-21-generic config-2.6.32-24-generic
config-2.6.28-16-generic config-2.6.32-22-generic
config-2.6.31-21-generic config-2.6.32-23-generic
root@serveur:/boot$ cat config-2.6.32-24-generic
#
# Automatically generated make config: don’t edit
# Linux kernel version: 2.6.32-24-generic
# Thu Aug 19 01:38:31 2010
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
(...)
root@serveur:/boot$
c. Compilation du noyau et des modules
La compilation se réalise le plus simplement du monde en tapant la commande make depuis le répertoire racine des
sources. La durée de l’opération dépend de la puissance de la machine sur laquelle elle est réalisée, mais une bonne
heure est souvent nécessaire. Pour un noyau en version 2.6, la commande make provoque la compilation du noyau
et des modules.
Compilation du noyau et des modules
C’est parti pour une heure ou deux...
[root@beta linux-2.6.34.4]# make

scripts/kconfig/conf -s arch/x86/Kconfig
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/generated/utsrelease.h

UPD include/generated/utsrelease.h
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/x86/kernel/asm-offsets.s
(...)
CC arch/x86/kernel/cpu/cpufreq/speedstep-lib.o
CC arch/x86/kernel/cpu/cpufreq/speedstep-smi.o
LD arch/x86/kernel/cpu/cpufreq/built-in.o
CC [M] arch/x86/kernel/cpu/cpufreq/powernow-k8.o
CC [M] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.o
CC [M] arch/x86/kernel/cpu/cpufreq/speedstep-centrino.o
CC [M] arch/x86/kernel/cpu/cpufreq/p4-clockmod.o
CC arch/x86/kernel/cpu/mcheck/mce.o
CC arch/x86/kernel/cpu/mcheck/mce-severity.o
CC arch/x86/kernel/cpu/mcheck/mce_intel.o
(...)
L’exécution de la commande make provoque la compilation du noyau et de ses modules. Elle appelle aussi la
commande depmod qui génère le fichier modules.dep de dépendance des modules.
d. Installation des modules
Les modules sont installés par la commande spécifique make modules_install. Ils sont copiés dans un
répertoire /lib/modules, sous un répertoire correspondant à la version du noyau.
Visualisation des répertoires contenant les modules
Chaque version de noyau installé a son répertoire de modules correspondant.
root@serveur:~$ ls /lib/modules/
2.6.27-11-generic 2.6.28-16-generic 2.6.32-22-generic
root@serveur:~$
e. Installation du noyau
Le noyau horsmodules se trouve dans le répertoire des sources dans une arborescence arch/x86/boot pour les

versions 32 bits ou arch/ia64/boot pour les versions 64 bits sous le nom bzImage. Son installation dans le système
en production se fait en copiant simplement ce fichier dans le répertoire /boot. Le nom utilisé par défaut (bzImage)
est tout à fait exploitable, mais il est préférable de le renommer pour tenir compte de la version compilée.
Des compilations réalisées avec des versions anciennes de noyau peuvent générer un fichier zImage et non
bzImage. Le préfixe z ou bz indique le format de compression du fichier noyau (gzip pour z et bzip2 pour bz).
Un noyau nouvellement compilé doit toujours être installé en plus du noyau existant. Ne jamais remplacer un
noyau qui fonctionne par un nouveau noyau.
Installation du noyau
L’usage veut que le fichier de noyau ait un nom normalisé qui reflète sa version.
root@serveur# cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.15

root@serveur#
f. Création du ramdisk des modules
Il faut mettre à disposition du noyau un ramdisk contenant l’ensemble des modules compilés pour la nouvelle
version. Ce ramdisk nécessite un fichier image, qui peut être construit avec deux commandes différentes en fonction
de la génération du système employé. La commande historique est mkinitrd. Elle tend à disparaître au profit de
mkinitramfs.

Création d’un ramdisk avec la commande mkinitrd
mkinitrd nom_image version
Création d’un ramdisk avec la commande mkinitramfs
mkinitramfs -o nom_image version
Où nom_image représente le nom du fichier image de ramdisk à créer, et version le numéro de version du noyau. Ce
numéro correspond en fait au répertoire des modules situé dans /lib/modules.
Exemple de création d’un ramdisk
root@serveur:/boot$ mkinitrd /boot/initrd-2.6.28.img 2.6.28

root@serveur:/boot$ file initrd-2.6.28.img
initrd.img-2.6.32-24-generic: gzip compressed data, from Unix, last modified: Fri Aug 20 07:54:31 2010
root@serveur:/boot$
Le fichier ramdisk est en fait une archive cpio compressée au format gzip. Les commandes de création de ramdisk
génèrent directement leurs fichiers à ce format.
Un système récent ne devrait proposer que la commande mkinitramfs. Si toutefois mkinitrd était disponible
aussi, elle ne devrait pas être utilisée. mkinitrd s’appuie sur devfs et non udev, et ne supporte pas les
disques sata.
g. Configuration du gestionnaire de démarrage
Il ne suffit pas d’avoir compilé le noyau et de l’avoir placé au bon endroit, encore fautil que le gestionnaire de
démarrage soit configuré pour être capable de charger ce noyau. Il conviendra donc d’ajouter une entrée au
gestionnaire de démarrage en conséquence. Attention, il ne faut rien retirer à la configuration du gestionnaire de
démarrage : on ne touche pas à ce qui marche déjà. Il suffit d’ajouter une entrée dans le fichier de configuration du
gestionnaire en se basant au besoin sur les entrées déjà présentes.
Ajout d’une entrée au gestionnaire de démarrage
La préservation des entrées existantes permet de toujours pouvoir démarrer sur une configuration stable.
# noyau fonctionnel d’origine

title Debian GNU/Linux, kernel 2.6.26-2-686
root (hd0,0)
# noyau ajouté à tester

title ESSAI - modules statiques
root (hd0,0)
kernel /boot/vmlinuz-2.6.20 root=/dev/hda1 ro quiet
initrd /boot/initrd.img-2.6.20

Patch du noyau
1. Ajout de patch
Il est possible pour bénéficier d’un noyau récent de télécharger les sources complètes du noyau, de les compiler et de
les installer en tant que nouveau noyau. Une méthode alternative consiste à utiliser les sources de l’ancien noyau et
de les patcher avant de les recompiler.
Les patchs se téléchargent sur le site http://www.kernel.org et s’ajoutent aux sources nues du noyau. L’application
d’un patch se fait en général avec la commande patch et peut se faire spécifiquement avec un script livré avec le
noyau s’appelant patchkernel. Le script patchkernel se trouve dans un répertoire scripts des sources du noyau,
alors que la commande patch est livrée avec la distribution Linux.
Application d’un patch à des sources
patch -pn < fichier_patch
Application de patch : options et paramètres
pn Dépend de la conception du fichier de patchs. Remonte de n niveaux hiérarchiques
dans les chemins des fichiers exprimés.
fichier_patch Le fichier contenant les patchs à appliquer.
Un fichier de patch est en fait le résultat d’une commande diff appliquée à deux arborescences de sources différentes.
Le fichier résultant contiendra donc une référence à chacun des fichiers de l’arborescence qui doivent être modifiés. Si
le niveau hiérarchique des fichiers décrits dans le patch ne correspond pas à celui des sources à modifier, le paramètre
p permet de décaler cette hiérarchie.
Exemple d’application d’un patch
Les fichiers de patch sont extrêmement sensibles à la conformité des sources auxquelles ils sont appliqués. On n’obtiendra
un résultat satisfaisant que si on applique le bon patch aux bonnes sources.
[root@beta linux-2.6.34]# patch -p1 < patch-2.6.34.4

patching file Documentation/.gitignore
patching file Documentation/hwmon/ltc4245
patching file Documentation/kernel-parameters.txt
patching file Makefile
patching file arch/arm/Kconfig
patching file arch/arm/common/sa1111.c
patching file arch/arm/include/asm/atomic.h
patching file arch/arm/include/asm/tlbflush.h
patching file arch/arm/kernel/kprobes-decode.c
patching file arch/arm/kernel/perf_event.c
patching file arch/arm/mach-mx2/devices.c
patching file arch/arm/mach-omap2/board-rx51-peripherals.c
patching file arch/arm/mach-pxa/cm-x300.c
patching file arch/arm/mach-realview/Kconfig
patching file arch/arm/mach-realview/include/mach/barriers.h
patching file arch/arm/mm/cache-v7.S
patching file arch/arm/mm/copypage-feroceon.c
patching file arch/arm/mm/copypage-v4wb.c
patching file arch/arm/mm/copypage-v4wt.c
patching file arch/arm/mm/copypage-xsc3.c
(...)
[root@beta linux-2.6.34]#
2. Retrait de patchs
Le retrait d’un patch appliqué se fait avec la même commande et la même syntaxe, à laquelle on ajoute le

commutateur R.
Application d’un patch à des sources
patch -pn -R < fichier_patch
Application de patch : options et paramètres
pn Dépend de la conception du fichier de patchs. Remonte de n niveaux hiérarchiques
dans les chemins des fichiers exprimés.
R Retire le patch au lieu de l’appliquer.
fichier_patch Le fichier contenant les patchs à appliquer.
Exemple de suppression d’un patch
[root@beta linux-2.6.34]# patch -p1 -R < patch-2.6.34.4

patching file Documentation/.gitignore
patching file Documentation/hwmon/ltc4245
patching file Documentation/kernel-parameters.txt
patching file Makefile
patching file arch/arm/Kconfig
patching file arch/arm/common/sa1111.c
patching file arch/arm/include/asm/atomic.h
(...)

clavier.
1. Questions
1 En quoi un programme écrit dans un langage de programmation compilé estil généralement plus performant
qu’un programme écrit dans un langage interprété ?
2 À quoi sert le script configure généralement livré avec les sources de programmes opensource ?
3 Quelle est la différence entre les commandes make clean et make mrproper ?
4 Quand un programme est compilé de façon dynamique, de quels éléments estil dépendant dans son
environnement d’exécution ?
5 Comment la commande ldconfig connaîtelle les répertoires à analyser pour inventorier les bibliothèques d’un
système ?
6 Dans le cadre d’une compilation de noyau, quelle cible de la commande make permet de s’appuyer sur un
fichier .config résultant d’une compilation précédente ?
7 Pourquoi ne devriezvous pas installer un noyau en version 2.5.8 ?
8 En l’absence de configuration particulière, dans quelle circonstance un module de noyau présent sous forme de
fichier sur le système n’estil pas chargé au démarrage ?
9 Quelle est la nature d’un fichier de chargement de ramdisk utilisé au chargement du noyau pour la détection
des périphériques ?
10 Pourquoi la commande mkinitrd atelle disparu au profit de la commande mkinitramfs ?
2. Réponses
1 En quoi un programme écrit dans un langage de programmation compilé estil généralement plus performant
qu’un programme écrit dans un langage interprété ?
L’exécution d’un programme interprété nécessite l’usage d’un autre programme appelé interpréteur, qui pour chaque
action décrite dans le code du programme devra traduire cette action en une multitude d’instructions processeur. Dans
le cas d’un programme compilé, le code binaire du programme compilé contient directement des instructions
intelligibles par le processeur. Le traitement est donc beaucoup plus rapide. La contrepartie est que le code compilé est
intimement lié au jeu d’instructions d’un processeur, et est donc moins facilement portable.
2 À quoi sert le script configure généralement livré avec les sources de programmes opensource ?
À vérifier la validité de l’environnement de compilation, et à générer un fichier de réponse Makefile utilisé par le
compilateur. Il arrive que les sources soient livrées sans le script configure. C’est généralement que le développeur n’a
pas souhaité de personnalisation possible de son programme avant la compilation.
3 Quelle est la différence entre les commandes make clean et make mrproper ?
La commande make clean nettoie le répertoire des sources de tous les éléments résultants de la compilation. Une
nouvelle compilation peut donc être entreprise sur les mêmes bases. La commande make mrproper efface tout
élément autre que les sources, jusqu’aux éléments de configuration. Un peu comme si on avait tout effacé puis refait
l’extraction des sources à partir du fichier tar. Il est à noter que ces options ne sont pas toujours disponibles (mrproper
notamment).
4 Quand un programme est compilé de façon dynamique, de quels éléments estil dépendant dans son
environnement d’exécution ?
Des bibliothèques logicielles (libraries). Il est très rare aujourd’hui de trouver des exécutables compilés en statique.
L’espace disque est ainsi largement optimisé, mais l’exécutable est plus dépendant de son environnement.
5 Comment la commande ldconfig connaîtelle les répertoires à analyser pour inventorier les bibliothèques d’un
système ?
En consultant son fichier de configuration /etc/ld.so.conf. Ce fichier contient la liste des répertoires à analyser pour y
trouver des fichiers de bibliothèques.
6 Dans le cadre d’une compilation de noyau, quelle cible de la commande make permet de s’appuyer sur un
fichier .config résultant d’une compilation précédente ?
C’est la cible oldconfig. Seuls les éléments nouveaux non référencés dans l’ancien fichier .config feront l’objet d’une

question posée à l’utilisateur.
7 Pourquoi ne devriezvous pas installer un noyau en version 2.5.8 ?
Parce que la numérotation impaire du deuxième chiffre indique qu’il s’agit d’un noyau en développement. Les versions
de production sont passées directement de la version 2.4 à la version 2.6.
8 En l’absence de configuration particulière, dans quelle circonstance un module de noyau présent sous forme de
fichier sur le système n’estil pas chargé au démarrage ?
Si ce module n’est pas nécessaire. Soit parce qu’il gère un matériel absent du système, soit parce qu’il n’est appelé par
aucune fonction logicielle.
9 Quelle est la nature d’un fichier de chargement de ramdisk utilisé au chargement du noyau pour la détection
des périphériques ?
Il s’agit d’une archive cpio compressée au format gzip. En l’absence d’extension normalisée pour un fichier compressé,
il faut recourir à la commande file pour s’en rendre compte. Attention, si vous souhaitez voir son contenu, il faut
d’abord la renommer en un fichier portant la bonne extension (gz), puis réaliser son extraction avec la commande cpio.
10 Pourquoi la commande mkinitrd atelle disparu au profit de la commande mkinitramfs ?
Parce que la commande initrd ne s’appuie pas sur la gestion de fichier de périphériques modernes udev, mais sur devfs,
et elle ne sait pas gérer les disques durs sata, ce qui devient problématique sur les systèmes récents.

Travaux pratiques
1. Compilation d’une application
Vous regrettez l’absence de client RDP sur le serveur beta. Vous décidez donc de télécharger le code source du client
rdesktop et de le compiler.
a. Téléchargement des sources
Sur le serveur beta, rendezvous sur le site www.rdesktop.org et téléchargez les sources de la dernière version
disponible du logiciel (section Downloads, version la plus récente du logiciel).
Décompressez l’archive téléchargée dans le répertoire de votre choix.
b. Compilation des sources
Commandes utiles
● configure
● make
● tar
Manipulations
1. Dans le répertoire des sources, lancez le script de configuration de la compilation.
2. Lancez la compilation des sources.
Extraction et positionnement dans le répertoire des sources :
[root@beta rdp]# ls
rdesktop-1.6.0.tar.gz
[root@beta rdp]# tar xzf rdesktop-1.6.0.tar.gz
[root@beta rdp]# ls
rdesktop-1.6.0 rdesktop-1.6.0.tar.gz
[root@beta rdp]# cd rdesktop-1.6.0
Configuration de la compilation :

(...)
checking build system type... i686-redhat-linux-gnu
checking host system type... i686-redhat-linux-gnu
Compilation :

gcc -g -O2 -Wall -I/usr/include -I/usr/include/alsa
-DPACKAGE_NAME=\"rdesktop\" -DPACKAGE_TARNAME=\"rdesktop\"
-DPACKAGE_VERSION=\"1.6.0\" -DPACKAGE_STRING=\"rdesktop\ 1.6.0\"
-DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1

-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DL_ENDIAN=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_LOCALE_H=1 -DHAVE_LANGINFO_H=1 -Dssldir=\"/usr\"
-DEGD_SOCKET=\"/var/run/egd-pool\" -DWITH_RDPSND=1 -DRDPSND_OSS=1
-DRDPSND_ALSA=1 -DHAVE_DIRENT_H=1 -DHAVE_DIRFD=1 -DHAVE_DECL_DIRFD=1
-DHAVE_ICONV_H=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_SYS_VFS_H=1
-DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_MOUNT_H=1 -DSTAT_STATVFS=1 -DHAVE_STRUCT_STATVFS_F_NAMEMAX=1
-DHAVE_STRUCT_STATFS_F_NAMELEN=1 -D_FILE_OFFSET_BITS=64
-DHAVE_MNTENT_H=1 -DHAVE_SETMNTENT=1
-DKEYMAP_PATH=\"/usr/local/share/rdesktop/keymaps/\" -o rdesktop.o -c rdesktop.c
(...)
c. Installation des binaires
Commandes utiles
● make
Manipulations
1. Installez les éléments compilés sur le système.
Installation des éléments compilés :
[root@beta rdesktop-1.6.0]# make install

mkdir -p /usr/local/bin
/usr/bin/install -c rdesktop /usr/local/bin
strip /usr/local/bin/rdesktop
chmod 755 /usr/local/bin/rdesktop
mkdir -p /usr/local/share/rdesktop/keymaps/
cp keymaps/?? keymaps/??-?? /usr/local/share/rdesktop/keymaps/
cp keymaps/common /usr/local/share/rdesktop/keymaps/
cp keymaps/modifiers /usr/local/share/rdesktop/keymaps/
chmod 644 /usr/local/share/rdesktop/keymaps//*
mkdir -p /usr/local/share/man/man1
cp doc/rdesktop.1 /usr/local/share/man/man1
chmod 644 /usr/local/share/man/man1/rdesktop.1
Notez que les éléments installés ne se cantonnent pas aux éléments binaires compilés, mais comprennent aussi
d’autres fichiers comme les fichiers d’aide ou de configuration.
d. Nettoyage des sources
Commandes utiles
● make
Manipulations
1. Constatez qu’il existe bien un fichier exécutable rdesktop à la racine des sources.
2. Faites en sorte que le répertoire des sources soit débarrassé des résultats de la
compilation, tout en conservant les éléments de configuration afin qu’ils puissent être
réexploités pour une prochaine compilation.
3. Vérifiez que le fichier exécutable rdesktop a bien été supprimé.
4. Vérifiez que le fichier de réponse Makefile a bien été préservé à la racine des sources.

[root@beta rdesktop-1.6.0]# ls -l rdesktop

-rwxr-xr-x 1 root root 615042 aoû 16 22:13 rdesktop
[root@beta rdesktop-1.6.0]# make clean
rm -f *.o *~ vnc/*.o vnc/*~ rdesktop rdp2vnc
[root@beta rdesktop-1.6.0]# ls -l rdesktop
ls: rdesktop: Aucun fichier ou répertoire de ce type
[root@beta rdesktop-1.6.0]# ls -l Makefile
-rw-r--r-- 1 root root 5823 aoû 16 22:01 Makefile
2. Compilation et installation d’un module de noyau
Pour assurer un fonctionnement spécifique d’une carte réseau, un de vos développeurs a modifié le code source du
pilote de carte réseau tg3. Vous devez compiler le code source du pilote pour obtenir et installer un module de noyau.
Téléchargez sur le site des éditions ENI le fichier linux3.110g.tar.gz et réalisez son extraction.
b. Suppression du module existant
Commandes utiles
● lsmod
● rm
● rmmod
Manipulations
1. Vérifiez que le module tg3 n’est pas actuellement chargé en mémoire. Si c’était le cas,
déchargezle avec la commande appropriée.
2. Effacez le fichier /lib/modules/2.6.x/kernel/drivers/net/tg3.ko.
[root@beta ~]# lsmod | grep tg3

[root@beta ~]#
[root@beta ~]# rm /lib/modules/2.6.18-194.el5/kernel/drivers/net/tg3.ko
rm: détruire fichier régulier `/lib/modules/2.6.18-194.el5/kernel/drivers/net/tg3.ko’? y
[root@beta ~]#
c. Compilation des sources
Commandes utiles
● make
Manipulations
1. Positionnezvous dans le répertoire extrait et constatez l’absence de fichier configure.
Les développeurs n’ont pas souhaité qu’on puisse interagir avec la compilation et ont
déjà écrit les fichiers Makefile nécessaires à la compilation.

2. Compilez les sources du pilote.
Absence de script de configuration et fichier Makefile déjà présent :
[root@beta tg3-3.110g]# ls -l
total 1024
-rw-r--r-- 1 2397 305 350928 avr 13 23:19 ChangeLog
-rw-r--r-- 1 2397 305 15153 jan 9 2009 LICENSE
-rw-r--r-- 1 2397 305 3870 mai 13 01:16 Makefile
-rwxr--r-- 1 2397 305 6584 avr 13 18:56 makeflags.sh
-rw-r--r-- 1 2397 305 10921 jun 8 19:58 README.TXT
-rw-r--r-- 1 2397 305 3445 fév 5 2010 tg3.4
-rw-r--r-- 1 2397 305 424808 jun 9 00:45 tg3.c
-rw-r--r-- 1 2397 305 2253 mar 31 22:20 tg3_compat2.h
-rw-r--r-- 1 2397 305 35711 jun 4 20:08 tg3_compat.h
-rw-r--r-- 1 2397 305 43934 mar 31 22:26 tg3_firmware.h
-rw-r--r-- 1 2397 305 114378 jun 4 20:01 tg3.h
-rw-r--r-- 1 2397 305 4286 jun 4 01:45 tg3_vmware.c
-rw-r--r-- 1 2397 305 1354 jun 4 01:57 tg3_vmware.h
Compilation :
[root@beta tg3-3.110g]# make

sh makeflags.sh /lib/modules/2.6.18-194.el5/source > tg3_flags.h
make -C /lib/modules/2.6.18-194.el5/build SUBDIRS=/root/Desktop/reseau/tg3-3.110g modules
make[1]: entrant dans le répertoire « /usr/src/kernels/2.6.18-194.el5-i686 »
CC [M] /root/Desktop/reseau/tg3-3.110g/tg3.o
Building modules, stage 2.
MODPOST
CC /root/Desktop/reseau/tg3-3.110g/tg3.mod.o
LD [M] /root/Desktop/reseau/tg3-3.110g/tg3.ko
make[1]: quittant le répertoire « /usr/src/kernels/2.6.18-194.el5-i686 »
[root@beta tg3-3.110g]#
d. Chargement du module de noyau et installation du module
Commandes utiles
● insmode
● ls
● lsmode
Manipulations
1. Constatez la présence d’un fichier tg3.ko. C’est le module du noyau fraîchement
compilé.
2. Chargez ce module en mémoire avec la commande appropriée.
3. Installez ce module dans son emplacement approprié (prévu par le développeur).
Chargement du module en mémoire :
[root@beta tg3-3.110g]# ls -l tg3.ko

-rw-r--r-- 1 root root 630546 aoû 16 22:30 tg3.ko
[root@beta tg3-3.110g]# insmod tg3.ko
[root@beta tg3-3.110g]# lsmod | grep tg3
tg3 125832 0

Installation du module :
[root@beta tg3-3.110g]# make install

make -C /lib/modules/2.6.18-194.el5/build SUBDIRS=/root/Desktop/reseau/tg3-3.110g modules
make[1]: entrant dans le répertoire « /usr/src/kernels/2.6.18-194.el5-i686 »
MODPOST
make[1]: quittant le répertoire « /usr/src/kernels/2.6.18-194.el5-i686 »
gzip -c tg3.4 > tg3.4.gz
mkdir -p //lib/modules/2.6.18-194.el5/updates;
install -m 444 tg3.ko //lib/modules/2.6.18-194.el5/updates;
install -m 444 tg3.4.gz /usr/share/man/man4;\
3. Patcher une application
Un ami geek vous demande si vous pouvez modifier ses listes de courses de la semaine. Vous estimez à juste titre
que cela constituera une bonne façon de se familiariser avec la procédure d’application de patchs.
a. Récupération des sources et du fichier de patch
Téléchargez sur le site des éditions ENI le fichier courses.tar.gz et réalisez son extraction. Téléchargez également
le fichier modif_courses.
b. Application du patch
Commandes utiles
● cp
● patch
● tar
Manipulations
1. Le répertoire courses contient une arborescence avec les jours de la semaine et les
courses à réaliser chaque jour. Placez le fichier de patchs directement sous le répertoire
courses.
2. Affichez la liste de courses du lundi (fichier courses sous le répertoire lundi).
3. Le patch a été conçu depuis le répertoire parent des sources. Il n’est donc pas
applicable directement depuis le répertoire sources. Appliquez le patch en retirant un
niveau de répertoire.
4. Affichez la liste de courses du lundi.
Copie du patch :
toto@ubuntu:~$ ls
courses.tar.gz modif_courses
toto@ubuntu:~$ tar xzf courses.tar.gz
toto@ubuntu:~$ ls courses
lundi mardi mercredi
toto@ubuntu:~$ cp modif_courses courses
toto@ubuntu:~$

Courses du lundi :
toto@ubuntu:~/courses$ cat lundi/courses

beurre
fromage
pain
carottes
toto@ubuntu:~/courses$
Application du patch (sans décalage hiérarchique) :
toto@ubuntu:~/courses$ patch < modif_courses

patching file courses
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file courses.rej
Application du patch :
toto@ubuntu:~/courses$ patch -p1 < modif_courses

patching file lundi/courses
patching file mardi/courses
patching file mercredi/courses
Courses du lundi après application du patch :

beurre
fromage
pain
navets
c. Retrait du patch
N’aimant pas les navets et craignant d’être invité à dîner, vous décidez de retirer le patch.
Commandes utiles
● patch
Manipulations
1. Retirez le patch.
2. Affichez la liste de courses du lundi.
Retrait du patch :
toto@ubuntu:~/courses$ patch -p1 -R < modif_courses

patching file lundi/courses
patching file mardi/courses
patching file mercredi/courses

Courses du lundi après retrait du patch :

beurre
fromage
pain
carottes
4. Compilation et installation d’un nouveau noyau
Ne sachant comment occuper votre weekend, vous entreprenez de compiler un nouveau noyau pour votre serveur
alpha. Afin que la production puisse reprendre sans encombre le lundi suivant, vous prendrez le soin de ne supprimer
aucun noyau existant.
a. Installation des outils de compilation
Afin de disposer des outils de compilation sur le serveur alpha, tapez la commande suivante :
apt-get install gcc make
b. Téléchargement des sources d’un nouveau noyau
Commandes utiles
● tar
Manipulations
1. Allez sur le site www.kernel.org, et téléchargez les sources complètes du dernier noyau
stable (sous le lien Latest Stable Kernel).
2. Réalisez son extraction dans un répertoire de travail neutre.
toto@alpha:~/noyau$ ls
linux-2.6.35.2.tar.bz2
toto@alpha:~/noyau$ tar xjf linux-2.6.35.2.tar.bz2
toto@alpha:~/noyau$ ls
linux-2.6.35.2 linux-2.6.35.2.tar.bz2
toto@alpha:~/noyau$
c. Configuration et compilation du noyau
Commandes utiles
● make
Manipulations
1. Générez un fichier de configuration du noyau en utilisant toutes les valeurs par défaut
pour la compilation.
2. Vérifiez la présence d’un fichier .config dans le répertoire racine des sources.
3. Compilez le noyau.

Génération du fichier de configuration :
toto@alpha:~/noyau$ cd linux-2.6.35.2
toto@alpha:~/noyau/linux-2.6.35.2$ make defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/basic/hash
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/kxgettext.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on ’i386_defconfig’
#
# configuration written to .config
#
toto@alpha:~/noyau/linux-2.6.35.2$
Il arrive souvent que la définition de la cible defconfig ne soit pas la plus adéquate pour un usage courant. Une
méthode alternative consiste à utiliser la cible config (make config), et à s’endormir sur la touche entrée pour utiliser
toutes les valeurs par défaut).
Compilation du noyau :
toto@alpha:~/noyau/linux-2.6.35.2$ make
(...)
LD arch/x86/boot/setup.elf
OBJCOPY arch/x86/boot/setup.bin
OBJCOPY arch/x86/boot/vmlinux.bin
HOSTCC arch/x86/boot/tools/build
BUILD arch/x86/boot/bzImage
Root device is (3, 1)
Setup is 12060 bytes (padded to 12288 bytes).
System is 4249 kB
CRC d836c8
Kernel: arch/x86/boot/bzImage is ready (#1)
MODPOST 3 modules
CC arch/x86/kernel/test_nx.mod.o
LD [M] arch/x86/kernel/test_nx.ko
CC drivers/scsi/scsi_wait_scan.mod.o
LD [M] drivers/scsi/scsi_wait_scan.ko
CC net/netfilter/xt_mark.mod.o
LD [M] net/netfilter/xt_mark.ko
toto@alpha:~/noyau/linux-2.6.35.2$
d. Installation du nouveau noyau et de ses modules
Commandes utiles
● cp
● make
● su
Manipulations
1. Prenez si nécessaire l’identité et les privilèges du compte root.
2. Copiez le fichier de noyau dans son répertoire normalisé sous le nom vmlinuzversion.
Le nom du fichier n’a aucune importance, on essaye en général d’être cohérent avec les

noyaux existants et déjà présents dans la distribution.
3. Installez les modules de noyau dans leur emplacement normalisé en utilisant une seule
commande.
Installation du noyau :
toto@alpha:~/noyau/linux-2.6.35.2$ su
Mot de passe :
alpha:/home/toto/noyau/linux-2.6.35.2# cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.35
alpha:/home/toto/noyau/linux-2.6.35.2#
Installation des modules :
alpha:/home/toto/noyau/linux-2.6.35.2# make modules_install

INSTALL arch/x86/kernel/test_nx.ko
INSTALL drivers/scsi/scsi_wait_scan.ko
INSTALL net/netfilter/xt_mark.ko
DEPMOD 2.6.35.2
alpha:/home/toto/noyau/linux-2.6.35.2#
e. Génération du ramdisk de démarrage
Commandes utiles
● file
● mkinitramfs
Manipulations
1. Positionnezvous dans le répertoire /boot.
2. Générez un ramdisk correspondant à votre nouvelle version de noyau sous le nom
initrd.imgversion.
3. Si la version de votre noyau n’est pas reconnue par la commande, consultez le
répertoire /lib/modules.
4. Selon les versions, des avertissements peuvent apparaître.
5. Vérifiez la présence d’un nouveau fichier image dans le répertoire /boot et déterminez
sa nature.
Génération du fichier image :
alpha:/boot# cd /boot
alpha:/boot# mkinitramfs -o initrd.img-2.6.35 2.6.35
Cannot find /lib/modules/2.6.35
alpha:/boot# ls /lib/modules
2.6.26-2-686 2.6.35.2
alpha:/boot# mkinitramfs -o initrd.img-2.6.35 2.6.35.2
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
alpha:/boot#
Vérification :
alpha:/boot# file initrd.img-2.6.35

initrd.img-2.6.35: gzip compressed data, from Unix, last modified: Tue Aug 17 10:37:50 2010
alpha:/boot#

f. Configuration du gestionnaire de démarrage
● /boot/grub/menu.lst
● vi
Manipulations
1. Éditez le fichier de configuration du gestionnaire de démarrage grub.
2. Augmentez la valeur de timeout pour avoir plus de temps au prochain démarrage.
3. Vers la fin du fichier, trouvez la dernière section référençant un noyau ordinaire (non
single) et dupliquezla.
4. Modifiez le titre d’une façon qui fasse apparaître la qualité non validée de votre noyau.
5. Modifiez la valeur du paramètre kernel pour charger votre noyau.
6. Modifiez la valeur du paramètre initrd pour charger votre fichier image de modules.
7. Redémarrez votre serveur et choisissez votre noyau.
8. Ne vous laissez pas impressionner par des messages d’erreur, qu’ils soient bloquants
ou non. La compilation d’un noyau est une affaire de longue haleine et ne se réussit pas
forcément en une demijournée. Vous avez d’ailleurs eu la présence d’esprit de
préserver les noyaux existants au cas où un échec surviendrait !
Fichier /boot/grub/menu.lst modifié :
timeout 15
(...)
## ## End Default Options ##
title Debian GNU/Linux, kernel 2.6.26-2-686

root (hd0,0)
title Debian GNU/Linux, kernel 2.6.26-2-686 (single-user mode)

root (hd0,0)
kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/hda1 ro single
### END DEBIAN AUTOMAGIC KERNELS LIST

title ESSAI - Utiliser hors production - noyau 2.6.35
root (hd0,0)
kernel /boot/vmlinuz-2.6.35 root=/dev/hda1 ro quiet
initrd /boot/initrd.img-2.6.35

Tableau des objectifs
Pour les tps, les cases avec un (1) indiquent l’absence de travaux pratiques (sujet strictement théorique ne se prêtant
pas à un exercice). Les références entre parenthèses indiquent un traitement conjoint du sujet au sein d’un autre tp.
Enfin, les (2) indiquent des éléments traités de façon disséminées sur tous les chapitres et exercices (le
troubleshooting est traité sur l’ensemble des sujets).
Chapitre Travaux pratiques
Exam 201: Detailed Objectives
Topic 201: Linux Kernel
201.1 Kernel Components Compilations Compilation du (1)

noyau Les composants du
noyau
201.2 Compiling a kernel Compilations Compilation du Compilation et installation d’un

noyau Procédure de nouveau noyau
compilation et d’exploitation
201.3 Patching a kernel Compilations Patch du noyau Patcher une application

Ajout de patch
201.4 Customise, build and install Compilations Compilation du Compilation et installation d’un

a custom kernel and kernel noyau Procédure de module de noyau
modules compilation et d’exploitation
201.5 Manage/Query kernel and Compilations Compilation du Compilation et installation d’un

kernel modules at runtime noyau Les composants du module de noyau
noyau
Topic 202: System Startup
202.1 Customising system startup Démarrage du système Le Création d’un niveau

and boot processes processus init et les niveaux d’exécution sur mesure avec
d’exécution Configuration du applications spécifiques
processus init
202.2 System recovery Démarrage du système Réinstallation de GRUB après

Démarrage et chargement du corruption
noyau
Topic 203: Filesystem and Devices
203.1 Operating the Linux Gestion du stockage Gestion Création et exploitation d’un

filesystem et configuration des systèmes volume logique sur le disque
de fichier Montage des RAID 0
filesystems
203.2 Maintaining a Linux Gestion du stockage Gestion Extension du volume logique

filesystem et configuration des systèmes
de fichier Gestion des
systèmes de fichiers
203.3 Creating and configuring Gestion du stockage Création et exploitation d’un

filesystem options Sauvegardes Duplication et volume logique sur le disque
synchronisation de données RAID 0
203.4 udev Device Management Gestion du stockage Gestion (1)

et configuration des systèmes
de fichier Gestion des disques
durs

Topic 204: Advanced Storage Device Administration
204.1 Configuring RAID Gestion du stockage RAID Configuration d’un disque en

Configuration du RAID RAID 0
204.2 Adjusting Storage Device Gestion du stockage Gestion Configuration d’un disque en

Access et configuration des systèmes RAID 0
de fichier Gestion des disques
durs
204.3 Logical Volume Manager Gestion du stockage Logical Création et exploitation d’un

Volume Manager volume logique sur le disque
RAID 0, Extension du volume
logique
Topic 205: Networking Configuration
205.1 Basic networking Gestion du réseau local Configuration d’un serveur

configuration Configuration du réseau DHCP sur le serveur alpha
Configuration universelle du
réseau
205.2 Advanced Network Gestion du réseau local Configuration d’un serveur

Configuration and Troubleshooting Diagnostic réseau Outils de DHCP sur le serveur alpha
diagnostics en couche réseau
205.3 Troubleshooting network Gestion du réseau local Exploitation du service DHCP

issues Diagnostic réseau Outils de
diagnostics en couches
transport et application
205.4 Notify users on system Messagerie Remise locale des (1)

related issues messages Alternatives à la
messagerie
Topic 206:System Maintenance
206.1 Make and install programs Compilations Compilation des Compilation d’une application

from source applications Procédure de
compilation GNU
206.2 Backup operations Gestion du stockage Gestion du stockage

Sauvegardes Les utilitaires Exploitation d’un espace de
d’archivage swap sur fichier
Protection des réseaux
Configuration d’un routeur et
parefeu sur le serveur B
Compilation des applications et
du noyau Linux Compilation
d’une application Compilation
et installation d’un nouveau
noyau
Topic 207: Domain Name Server
207.1 Basic DNS server Résolution de noms DNS Configuration du serveur de

configuration Configuration de base du cache
serveur Serveur de cache
207.2 Create and maintain DNS Résolution de noms DNS Création de zones

zones Gestion de zones DNS personnalisées directes et
inverses
207.3 Securing a DNS server Résolution de noms DNS Création d’un serveur

Sécurisation du DNS secondaire

Exam 202: Detailed Objectives
Topic 208 Web Services
208.1 Implementing a web server Serveur web Apache Restriction de l’accès aux

Configuration de base d’un pages web
serveur Apache
208.2 Maintaining a web server Serveur web Apache Authentification locale

Configuration d’Apache avec
SSL
208.3 Implementing a proxy Serveur web Apache Serveur Authentification par annuaire

server proxy Configuration des hôtes LDAP
virtuels
Topic 209: File Sharing
209.1 SAMBA Server Configuration Partages de fichiers Partage Mise en place de partages

de données avec SAMBA SAMBA sur le serveur alpha
209.2 NFS Server Configuration Partages de fichiers Partage Mise en place de partages NFS

de données avec NFS sur le serveur beta
Topic 210 Network Client Management
210.1 DHCP configuration Gestion du réseau local Configuration d’un serveur

Configuration automatique avec DHCP sur le serveur alpha,
DHCP
Exploitation du service DHCP
210.2 PAM authentication Authentification des utilisateurs Authentification du poste de

PAM travail par l’annuaire LDAP
210.3 LDAP client usage Authentification des utilisateurs Création et alimentation d’un

LDAP Les outils clients LDAP annuaire LDAP sur le serveur
beta
Topic 211: EMail Services
211.1 Using email servers Messagerie Les MTA Gestion des envois
211.2 Managing Local EMail Messagerie Remise locale des Gestion des envois

Delivery messages
211.3 Managing Remote EMail Messagerie Remise distante Gestion des retraits

Delivery des messages
Topic 212: System Security
212.1 Configuring a router Protection des réseaux Configuration d’un routeur et

Routage et filtrage parefeu sur le serveur B
212.2 Securing FTP servers Partages de fichiers Partage Configuration d’un serveur FTP

de fichiers avec FTP sur le serveur alpha
212.3 Secure shell (SSH) Sécurisation du trafic OpenSSH Création d’un tunnel SSH entre

la station de travail et le
serveur beta
212.4 TCP Wrapper Gestion du réseau local (1)

Configuration du réseau
Autres commandes et fichiers de

gestion du réseau
212.5 Security tasks Protection des réseaux Configuration d’un routeur et

Administration d’un parefeu parefeu sur le serveur B
avec les iptables Filtrage de
paquets
Topic 213: Troubleshooting
213.1 Identifying boot stages and Démarrage du système Réinstallation de GRUB après

troubleshooting bootloaders Démarrage et chargement du corruption
noyau Utilisation de GRUB en
mode interactif, Réinstallation
de GRUB
213.2 General troubleshooting (2) (2)
213.3 Troubleshooting system (2) (2)

resources
213.4 Troubleshooting (2) (2)

environment configurations

LINUX Preparation A La Certification LPI PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LINUX Preparation A La Certification LPI PDF

Transféré par

Droits d'auteur :

Formats disponibles

LINUX

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

Les chapitres du livre :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mkfs -t type device

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

fsck -t type device

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

alpha:/dev# tune2fs -l /dev/hda1

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

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

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

toto@cuicui:~$ cat /proc/swaps

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

mount -t type_fs -o options device point_montage

type_fs Facultatif : type de filesystem à monter.

options Facultatif : options de montage.

umount -O options device point_montage

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

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

fs pointmontage type options dump fsck

Numéro de Champ Désignation

# /etc/fstab: static file system information.

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

LABEL=/ / ext3 defaults

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

repertoire fic_sec --option=valeur

pmv options device

/etc/init.d autofs restart

/etc/init.d autofs status

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

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

alpha:~# dmesg | grep [sh]d

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

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

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

alpha:~# hdparm /dev/hda

alpha:~# hdparm -c /dev/hda

alpha:~# hdparm -a /dev/hda

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

alpha:~# hdparm -d /dev/hda

badblocks -b taille_blocks -o fichier_sortie

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

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

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

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

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

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

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