Vous êtes sur la page 1sur 63

Administration de rseaux

Marc Baudoin

1
Introduction
administration rseau, de mme que ladministration systme dailleurs, est
une discipline qui ne senseigne pas. Ceci peut paratre paradoxal puisque ce
document est le support dun cours dadministration rseau, justement. Relativisons
les choses, si ladministration rseau ne senseigne pas, en revanche, elle sapprend et
le but de ce cours est de donner aux lves un minimum dlments leur permettant
par la suite dorienter leur apprentissage dans la bonne direction.
Pourquoi ladministration rseau ne senseigne-t-elle donc pas ? Tout dabord,
parce cest un domaine bien trop vaste et qui volue trop rapidement pour que
quiconque puisse le dominer de la tte et des paules. De plus, le nombre de
matriels et de logiciels est trop important pour quon puisse en faire une tude
srieuse. De toute faon, chaque entreprise a fait ses choix dans ce domaine et les
jeunes ingnieurs auront gnralement sy plier.
Ce cours ne se veut donc pas exhaustif. En particulier, nous naborderons pas du
tout la configuration des quipements actifs (routeurs, commutateurs, etc.). Celle-ci
ncessiterait un cours entier elle seule et obligerait faire un choix partial pour tel
ou tel constructeur.
En revanche, dans ce cours, nous essaierons de dgager des principes gnraux
sur la bonne faon dadministrer un rseau. Le champ dapplication tant plutt
tendu, nous nous limiterons quelques technologies fondamentales, applicables
aux rseaux IP sur Ethernet :

les rseaux virtuels (VLAN), sans lesquels on ne peut construire de nos jours un
rseau moderne et souple ;
Simple Network Management Protocol (SNMP), le protocole dadministration
rseau par excellence, que nous tudierons en dtail et dont nous discuterons
les avantages et les inconvnients ;
les annuaires, en particulier le Domain Name System (DNS), Dynamic Host
Configuration Protocol (DHCP) et Lightweight Directory Access Protocol
(LDAP) ;
la messagerie, avec ltude des logiciels sendmail et Postfix.
Par ailleurs, le langage de programmation Perl, outil indispensable tout administrateur rseau, sera rapidement voqu, son tude pouvant reprsenter elle
seule lobjet dun cours entier.
3

Chapitre 1. Introduction
Mais, tout dabord, il convient de poser les bases sans lesquelles tout travail
srieux est impossible.

2
Les fondements
Nous allons tudier dans ce chapitre quelques principes fondamentaux que tout
administrateur rseau doit constamment avoir lesprit.

2.1

Les doigts de pied en ventail

Le but dun rseau informatique est dassurer le transport des donnes de


manire automatique. Tout lart de ladministrateur est de faire en sorte que le rseau
puisse fonctionner de manire autonome, de faon minimiser les interventions
manuelles. Par exemple, lutilisation de protocoles de routage dynamique, tels que
RIP ou OSPF, permet de pallier aux dfaillances dun petit nombre dquipements
actifs pour peu que des chemins alternatifs existent. Lutilisation de DHCP permet
de simplifier la configuration des ordinateurs et offre plus de souplesse pour modifier
le plan dadressage IP. Il faut absolument prendre en considration tout ce qui permet
de simplifier le travail de ladministrateur rseau.
Dans le mme ordre dides, de nombreux services rseau permettent soit
lutilisation simultane de plusieurs serveurs soit la mise en place dun serveur de
secours, voire de plusieurs, prenant automatiquement la place du serveur principal
en cas dincident sur ce dernier. Il est essentiel de profiter de ces possibilits afin
damliorer la disponibilit du rseau et de diminuer les interventions durgence.
cet effet, il est prfrable de placer le serveur de secours dans un autre local, voire
dans un autre btiment que celui qui hberge le serveur principal. Si cela nest pas
possible, il faut au moins le relier une alimentation lectrique et un quipement
actif du rseau diffrents de ceux du serveur principal.
Par ailleurs, il convient nanmoins de rester prudent face ce qui peut simplifier
la vie de ladministrateur rseau. Un systme qui fonctionne correctement lorsquil
sagit de grer quelques dizaines de machines ou de connexions peut se rvler inadapt pour un nombre plus important. Malheureusement, seules lexprimentation
(quitte en payer les pots casss) et lexprience dautres administrateurs rseau (qui
ne cote pas cher et permet souvent dviter les cueils) permettent den avoir le
cur net.
Enfin, on aura beau avoir tous les systmes redondants du monde, il est nanmoins ncessaire deffectuer une surveillance rapproche de son rseau afin dtre
au courant des incidents et de pouvoir ragir en consquence. Parmi les logiciels
5

Chapitre 2. Les fondements


de surveillance, on peut citer Nagios 1 qui, outre sa gratuit, a lavantage dtre
particulirement polyvalent.

2.2

Le matriel

2.2.1

Mfiance face aux fournisseurs

Cest bien connu, les fournisseurs sont l pour vous faire acheter leurs matriels.
Ils sont en revanche beaucoup plus discrets lorsquil sagit de rsoudre les problmes
que leur utilisation pourrait entraner. Le souci le plus commun survient lors de
la mise jour des logiciels (en particulier les systmes dexploitation des matriels
actifs) vers une version plus rcente. Certains constructeurs poussent mme le vice
jusqu sortir des versions mineures de leurs logiciels chaque semaine. Dans ces
conditions, il est bien videmment impossible deffectuer des mises jour aussi
frquemment.
La dmarche la plus sage consiste bloquer son parc sur une version particulire
des logiciels, dont on aura constat la stabilit, et de ne les mettre jour que
pour de bonnes raisons (cela peut tre la disponibilit de nouvelles fonctionnalits,
lamlioration des performances, la correction dun problme de scurit, etc.).

2.2.2

La maintenance

Les quipements tombent en panne un jour ou lautre, cest dans lordre des
choses.
En consquence, tous les matriels doivent disposer dune maintenance permettant de faire remplacer les pices dfectueuses. Il existe diffrents dlais de
remplacement, plus ou moins rapides, et cest chacun de dfinir ce qui convient
le mieux son rseau, en fonction de ses contraintes de fonctionnement et de ses
moyens financiers, les dlais de remplacement les plus courts tant videmment les
plus coteux.
Une option intressante, pour les parcs dune taille suffisante et suffisamment
homognes, est de disposer dun quipement supplmentaire de chaque type et de
souscrire la maintenance la plus lente possible lorsque ceci est rentable. Il est trs
improbable davoir deux pannes en mme temps donc, en cas de dfaillance, cest
lquipement supplmentaire (ou lun de ses composants) qui remplacera dans un
dlai trs court lquipement dfaillant. Celui-ci sera alors remplac au titre de la
maintenance par un quipement qui deviendra le nouvel quipement de secours.

2.2.3

La valorisation des vieux quipements

Il existe des entreprises spcialises dans la vente et lachat dquipement informatique doccasion, dont le matriel rseau. Lors de la rforme danciens appareils,
1.

http://www.nagios.org/

2.3. Un peu dadministration systme


il peut tre intressant denvisager leur revente lune de ces entreprises, certains
matriels pouvant avoir une valeur rsiduelle non ngligeable.

2.3

Un peu dadministration systme

Ladministration rseau est rarement totalement dcouple de ladministration


systme, pour la simple raison que le bon fonctionnement dun rseau repose
gnralement sur un certain nombre de serveurs. Il nest donc pas inutile de rappeler
un certain nombre de rgles lmentaires dadministration systme.
Un serveur fiable a toujours au moins deux disques. Lun utilis uniquement
pour le systme (donc, grosso modo, contenant /, /usr, /var et du swap), lautre
contenant les comptes des utilisateurs (/home) et surtout les logiciels recompils
(/usr/local) ainsi que les fichiers de configuration de ces logiciels (par exemple
/opt), de manire sparer les fichiers rsultant dinstallation de logiciels, qui
sont dans /usr/local, et les fichiers gnrs par des humains, qui sont dans /toto.
De cette faon, en cas de problme matriel sur le serveur, il est trs simple de
dplacer le second disque sur une machine installe de la mme faon (donc avec un
premier disque identique). Une autre approche est de placer /usr/local et /toto
sur un serveur NFS mais on prfre gnralement les disques locaux pour viter les
dpendances entre machines.
Un serveur est rarement administr par une seule personne. Il est donc ncessaire
de grer laccs concurrent aux fichiers modifiables par les administrateurs. Une
faon lgante de faire est dutiliser RCS (voir lannexe A).

2.4

La scurit est essentielle

Lorsquon parle de scurit, cela recouvre un domaine trs vaste, comprenant


entre autres le contrle daccs, lintgrit, la confidentialit et la disponibilit.
Parmi ces aspect, la disponibilit a t traite au paragraphe 2.1, lintgrit est
assure en partie par les sommes de contrle de TCP et dUDP (rien ninterdisant
un intrus plac sur le chemin dun paquet de modifier les paquets et de recalculer
les sommes de contrle en consquence), la confidentialit est assure par IPsec ou
par des dispositifs de chiffrement spcifiques.
Le contrle daccs, quant lui, doit tre impos sur tous les quipements
actifs et les serveurs, afin que seules les personnes autorises y aient accs. Il est en
effet particulirement dsagrable de voir son travail ruin par un intrus qui aurait
modifi, voire effac, la configuration de ses quipements. Pour sen prvenir, outre
un contrle daccs adquat, il est prfrable de conserver en sret les configurations
de tous les quipements, afin de pouvoir les restaurer rapidement en cas de problme.
En particulier, de nombreux quipements actifs acceptent soit dtre configur en
direct (par lintermdiaire dune connexion rseau ou dune connexion sur port
srie) soit de tlcharger leur configuration, gnralement par TFTP. Cette dernire
7

Chapitre 2. Les fondements


approche est privilgier puisquelle permet de conserver la trace de la configuration
sur le serveur TFTP.

2.5

Les fichiers de configuration

Dailleurs, quasiment tous les quipements actifs acceptent de tlcharger leur


configuration, en totalit ou par morceaux, depuis un serveur (gnralement par
TFTP). Les mauvais administrateurs rseau senorgueillissent de pouvoir gnrer
la main de nombreux fichiers de configuration plus complexes les uns que les autres,
au risque dy introduire des erreurs de syntaxe ou, plus grave, davoir grer la
redondance des informations entre plusieurs fichiers.
En revanche, ladministrateur rseau fut et qui de plus applique le principe des
doigts de pied en ventail adopte plutt un autre principe lorsque cela est possible
(attention, ce nest pas toujours le cas). Il met au point un certain nombre de programmes qui permettent, partir dinformations lmentaires et non redondantes,
de gnrer les diffrents fichiers de configuration qui en dcoulent.
Prenons un exemple concret tir dune situation relle. Le DNS, comme vous
ne le savez peut-tre pas encore (dans ce cas, vous pouvez vous rfrer au paragraphe
5.1) permet de connatre ladresse IP associe un nom de machine et vice versa.
Pour cela, le serveur a besoin de deux fichiers de configuration, lun contenant, pour
chaque nom, ladresse IP correspondante, et lautre contenant, pour chaque adresse
IP, le nom correspondant. Ceci est une vision un peu simplifie de ce que permet de
faire le DNS mais elle couvre son utilisation habituelle. Il est videmment idiot de
grer ces deux fichiers la main (sauf lorsquon na quune dizaine de machines y
enregistrer), puisquils contiennent somme toute les mmes informations. De plus,
leur format est adapt leur interprtation par un logiciel mais pas vraiment leur
rdaction manuelle. Il est plus simple de ne grer quun seul fichier, contenant par
exemple des lignes de la forme :
nom_de_machine

adresse_IP

et de gnrer partir de celui-ci les deux fichiers de configuration du DNS au moyen


dun programme maison. Non seulement cette mthode est plus simple et plus
rapide (principe des doigts de pied en ventail) mais elle permet galement davoir des
fichiers de configuration exempts derreurs de syntaxe (pour peu que le programme
maison soit bien conu). Le programme maison peut galement en profiter pour
redmarrer le serveur DNS aprs avoir gnr les fichiers de configuration, ce qui
vite une manipulation supplmentaire.
Mais on peut aller plus loin. De nos jours, on ne configure plus les paramtres
rseau des ordinateurs (adresse IP, masque de sous-rseau, routeur par dfaut...)
manuellement, on utilise DHCP en attribuant chaque machine soit une adresse
prise au hasard dans un ensemble donn soit une adresse fixe choisie en fonction de
ladresse Ethernet de la machine (cette dernire mthode est dailleurs prfrable car
8

2.6. Perl
elle permet de suivre les incidents plus facilement). Pour cela, le serveur DHCP a
besoin dun fichier de configuration contenant un certain nombre dinformations
dont, pour chaque machine, son adresse Ethernet et son adresse IP ou son nom
(dans ce cas, le serveur DHCP utilise le DNS pour faire la conversion). En tendant
le format du fichier unique utilis pour le DNS quelque chose du genre :
nom_de_machine

adresse_IP

adresse_Ethernet

on peut continuer utiliser ce fichier pour le DNS (il suffit dignorer le dernier
champ) et galement pour gnrer le fichier de configuration du serveur DHCP
laide dun deuxime programme maison.
Jarrterai cet exemple ici, mais on peut encore ltendre la configuration des
commutateurs.

2.6

Perl

Nous venons de voir que ladministrateur rseau fut est celui qui se simplifie la
vie en mettant au point de petits programmes lui permettant de gnrer des fichiers
de configuration complexes partir de fichiers beaucoup plus simples. Ceci peut,
bien entendu, tre ralis au moyen de nimporte quel langage de programmation
mais lun deux se rvle particulirement adapt ce type de travail, il sagit de Perl.
Perl, galement trs utilis en administration systme, est incontournable ds
quil est question danalyser et de gnrer des fichiers au format texte parce que les
outils le permettant sont intelligemment inclus dans le langage lui-mme. Sorte de
mlange de nombreux autres langages, reprenant chacun ce quil sait bien faire,
Perl dispose de plus dune immense bibliothque de modules permettant de raliser
trs simplement peu prs tout ce quoi lon peut penser.
Ici nest malheureusement pas la place pour un cours dtaill sur Perl. Une
prsentation trs rapide est fournie dans le cours B1-3.

3
Les rseaux virtuels (VLAN)
3.1

Historique

es premiers rseaux Ethernet (on se situe donc en couche 2) taient conus

L base de cbles coaxiaux raccords entre eux et connects aux ordinateurs, si

bien que tout signal lectrique mis par lun deux tait reu par tous les autres.
Lensemble des machines ainsi relies entre elles sappellait un domaine de collision
(puisque ces machines partageaient le mme mdium physique).
Dans le cas de grands rseaux locaux, il tait impossible davoir un seul domaine
de collision (pour des raisons dloignement gographique, de longueur de cbles,
de temps de propagation ou cause du nombre trop important dordinateurs) et il
fallait donc concevoir des domaines de collision de taille raisonnable, relis entre eux
par des routeurs. Des ponts Ethernet nauraient pas suffi car ils augmentent le temps
de propagation des signaux lectriques, do la ncessit de remonter en couche 3.
Chacun de ces domaines de collision tait galement appel segment Ethernet.
chaque segment Ethernet correspondait donc un sous-rseau IP. Au bout
du compte, on aboutissait un dcoupage logique calqu trs exactement sur le
dcoupage physique du rseau. Cela imposait une proximit gographique des
machines si lon voulait quelles appartiennent au mme segment Ethernet, ce qui
nest pas ncessairement pratique. Par ailleurs, ceci limitait grandement la mobilit
des ordinateurs.
Aprs larrive des premiers commutateurs, de nouvelles possibilits sont apparues. Compte tenu de llectronique interne des commutateurs, plus complexe que
celles des rpteurs, il devenait possible de disposer de plusieurs segments Ethernet
au sein dun mme commutateurs (ce qui tait dailleurs dj possible moindre
chelle dans les rpteurs segmentables). Mais, en ajoutant quelques en-ttes supplmentaires aux trames Ethernet, il devenait possible dtendre la taille de ces
segments Ethernet lensemble dun rseau de commutateurs interconnects. Les
rseaux virtuels (virtual LAN, VLAN) taient ns.

3.2

Principe

Un VLAN est lquivalement moderne des segments Ethernet de lancien


temps. Tous les ordinateurs faisant partie dun mme VLAN sont capables de
11

Chapitre 3. Les rseaux virtuels (VLAN)


communiquer entre eux directement sans avoir passer par un routeur. On ne
parle plus de domaine de collision, tant donn quil ny a pas de collisions avec des
commutateurs, mais de domaine de diffusion, puisquune trame de diffusion mise
par un ordinateur sera reue par toutes les machines faisant partie du mme VLAN.
Un VLAN peut tre local un commutateur ou stendre un ensemble de
commutateurs relis entre eux. On a donc la possibilit dorganiser la structure
logique de son rseau sans avoir se soucier de sa structure physique, ce qui apporte
une souplesse fort apprciable.
Dans le cas o une trame Ethernet doit tre transporte dun commutateur un
autre, il est ncessaire dy rajouter quelques informations (en particulier le VLAN
auquel elle appartient). Cest le but du standard IEEE 802.1Q.

3.3

Le standard IEEE 802.1Q

Approuv le 8 dcembre 1998, le standard 802.1Q du comit 802 1 de lIEEE


(Institute of Electrical and Electronics Engineers) est aujourdhui le standard de fait
pour lidentification des trames faisant partie dun rseau virtuel.
Il a succd ISL (Inter-Switch Link), protocole propritaire dvelopp par Cisco
(et galement repris par quelques autres constructeurs).
Le principe gnral est de rajouter dans chaque trame Ethernet destine tre
transmise dun commutateur un autre quelques en-ttes supplmentaires contenant
en particulier lidentifiant du rseau virtuel auquel elle appartient (VID, VLAN
Identifier), qui est un numro sur 12 bits, de 0 4094 (4095 est rserv et, en pratique,
0 et 1 sont inutiliss).
Ltude dtaille des 211 pages du standard 802.1Q 2 ne prsente que peu dintrt
et nous allons donc nous concentrer sur son utilisation pratique.

3.4

En pratique

Les constructeurs de commutateurs imposent en gnral des limitations quant


au nombre de rseaux virtuels que leurs matriels peuvent grer. Les plus petits
modles ne savent souvent en grer que quelques dizaines alors que les chssis offrent
un ventail plus large. Il convient donc dy prendre garde lors de la dfinition des
VLAN de son rseau et du choix de son matriel.
Il faut galement prendre en compte les possibilits offertes par les commutateurs
des diffrents constructeurs. Les plus simples ne permettent de placer un port (et
donc les ordinateurs qui y sont connects) que dans un seul VLAN de manire
statique, les plus volus permettent de choisir le VLAN de manire dynamique en
fonction de divers paramtres (adresse Ethernet, protocole, etc.).
1.
2.

http://www.ieee802.org/
http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf

12

3.4. En pratique
Mais il faut avant tout dterminer comment dcouper son rseau et selon quels
critres. Il ny a videmment pas de rgle gnrale mais lusage le plus rpandu est
de calquer lorganisation du rseau sur lorganisation administrative de lentreprise.

13

4
Simple Network Management Protocol (SNMP)
NMP permet ladministrateur rseau, depuis un poste de contrle central,

S dobtenir et de modifier divers lments de configuration dquipements actifs

et de logiciels.
SNMP est un paradoxe dans le monde de ladministration rseau. Conu comme
un protocole cens unifier et simplifier la gestion des matriels et des logiciels (ce
qui est un but absolument louable), il na pas encore russi simposer auprs des
administrateurs pour des raisons parfaitement valables :
SNMP nest pas si simple que a (lisez donc les spcifications des diffrentes
versions de ce protocole pour en avoir le cur net) ;
sa mise en uvre (autrement que pour de petits besoins ponctuels) ncessite
des investissements gigantesques en logiciels dadministration ;
sa scurit laisse dsirer (cest un comble pour un protocole ddi ladministration) bien que la situation se soit bien amliore avec SNMPv3.
En fait, lutilisation systmatique de SNMP est difficile justifier lorsquon nadministre pas un gigantesque rseau compos de matriels et de logiciels htrognes
et quon na pas quelques centaines de milliers deuros y consacrer.
Cependant, dans certains cas, SNMP peut tout de mme savrer fort utile si
lon sait lutiliser bon escient.
Ce chapitre ne se veut pas exhaustif, le lecteur dsirant approfondir son tude
de SNMP pourra se reporter aux URL suivantes :
http://www.snmplink.org/
http://www.faqs.org/faqs/by-newsgroup/comp/comp.protocols.snmp.html

4.1

Historique

Trois versions successives de SNMP se sont succdes :


SNMPv1, en 1990, dcrit dans les RFC 1155 1157 ;
SNMPv2, en 1996, dcrit dans les RFC 1901 1908 ;
SNMPv3, en 1999, dcrit dans les RFC 2571 2575.
Bien que SNMPv3 soit maintenant assez ancien, rares sont les matriels qui sont
capables de le grer. Nous nous concentrerons donc sur SNMPv2.
15

Chapitre 4. Simple Network Management Protocol (SNMP)

4.2

Scurit

Le protocole permettant la gestion des quipements actifs du rseau devrait


logiquement tre le plus scuris de tous les protocoles avec, en particulier, un
contrle daccs et une confidentialit irrprochables.
Tous les documents dcrivant SNMP (avant la version 3) se contentaient, au
paragraphe Security Considerations, dun commentaire laconique :
Security issues are not discussed in this memo.
Et, en effet, le contrle daccs tait approximatif et la confidentialit inexistante.
SNMPv3, quant lui, accorde enfin une large part de sa spcification au contrle
daccs, la confidentialit tant naturellement laisse IPsec.

4.3

Principes

4.3.1

Les agents

Chaque quipement ou logiciel pouvant tre interrog par SNMP comporte un


serveur appel agent. Celui-ci coute sur le port UDP 161.

4.3.2

Les MIB

Les paramtres pouvant tre examins ou modifis par lagent sont dfinis
dans une MIB (Management Information Base), qui est un document dcrivant ces
diffrents paramtres, leur type (nombre entier, chane de caractres...), sils sont
modifiables ou non (dans labsolu, indpendamment des droits daccs), etc.
La MIB la plus utilise est certainement la MIB-II, dcrite dans le RFC 1213, qui
dfinit un ensemble cohrents de paramtres communs tous les quiments. Cest
cette MIB que nous tudierons par la suite.
Chaque lment dune MIB est dfini par un nom et un numro (comme dhabitude, on retrouve cette dualit, les noms tant plus faciles manipuler pour nous,
pauvres humains, et les nombres plus faciles manipuler par les ordinateurs). Ainsi,
dans la MIB-II, lobjet sysContact, indiquant le nom de la personne responsable
dun quipement, est dfini ainsi :
sysContact OBJECT-TYPE
SYNTAX

DisplayString (SIZE (0..255))

ACCESS

read-write

STATUS

mandatory

DESCRIPTION
"The textual identification of the contact person
for this managed node, together with information
on how to contact this person."
::= { system 4 }

16

4.3. Principes
indique le type de lobjet selon la syntaxe ASN.1 (Abstract Syntax Notation
One).

SYNTAX

ACCESS

indique le mode daccs lobjet. Les valeurs suivantes sont possibles :


read-only
read-write
write-only
not-accessible

indique si lobjet doit obligatoirement tre prsent dans toute implmentation de la MIB ou pas. Les valeurs suivantes sont possibles :
mandatory
optional
obsolete

STATUS

DESCRIPTION

est un texte destin ladministrateur et qui dcrit lobjet.

La dernire ligne de la dfinition attribue lobjet sysContact le numro 4 dans


le groupe system. En effet, les MIB sont hirarchises la manire des rpertoires
dans un systme de fichiers. Le nom complet de cet objet au sein de la MIB-II est
donc system.sysContact (le point est utilis comme sparateur) ou bien system.4
ou bien 1.sysContact (system a pour numro 1) ou, encore moins lisible, 1.4.
La MIB-II fait elle-mme partie dune hirarchie plus large :
.iso.org.dod.internet.mgmt
.1.3.6.1.2

La racine de la hirarchie na pas de nom et est dsigne simplement par un


point.
iso (1) dsigne lInternational Organization for Standardization.
org (3) a t cr par lISO lintention de divers organismes.
dod (6) a t attribu au ministre de la Dfense des tats-Unis (Department of
Defense).
internet (1) regroupe tout ce qui touche lInternet.
mgmt (2), enfin, est utilis pour les standards de lIAB.
Sous .iso.org.dod.internet.mgmt, la MIB-II a pour nom mib-2 et pour numro
1, de telle sorte que lobjet sysContact a pour nom absolu :
.iso.org.dod.internet.mgmt.mib-2.system.sysContact
.1.3.6.1.2.1.1.4

En pratique, cet objet est dun type discret (ce nest pas un tableau et il ne
contient donc quune valeur) donc on lui ajoute un .0 final, ce qui donne comme
nom absolu :
17

Chapitre 4. Simple Network Management Protocol (SNMP)

.iso.org.dod.internet.mgmt.mib-2.system.sysContact.0
.1.3.6.1.2.1.1.4.0

Les objets pouvant contenir plusieurs valeurs se voient ajouter leur nom un .1
pour la premire valeur, .2 pour la deuxime et ainsi de suite.
Somme toute, SNMP est simple !

4.3.3

Les oprations

Sans rentrer dans le dtail du protocole et des formats de paquets, il est nanmoins intressant de savoir un minimum comment fonctionne le dialogue entre un
agent SNMP et un logiciel dadministration.
Il existe grosso modo quatre types de messages :
Get permet de rcuprer un objet bien prcis.
Get next renvoie lobjet suivant (dans lordre lexicographique) celui pass en paramtre. Ceci est particulirement utile pour passer en revue toute une MIB.
Set permet de modifier la valeur dun objet.
Trap permet un agent denvoyer un signal au logiciel dadministration et ce de
son propre chef. Les trois types de messages prcdents taient envoys par le
logiciel dadministration lagent, celui-ci fonctionne en sens inverse. Il est
trs utile pour effectuer une surveillance passive du rseau, les quipements se
plaignant si ncessaire.

4.3.4

Les communauts

Dans SNMPv2, le contrle daccs est fait en fournissant dans chaque message
un mot de passe appel communaut. Il existe gnralement deux communauts,
lune utilise pour les accs en lecture (cest par dfaut la chane de caractres public),
lautre utilise pour les accs en criture (cest par dfaut la chane de caractres
private). Il est videmment essentiel de modifier ces valeurs et de les tenir secrtes.

4.4

net-snmp

La plupart des quipements rseau intgrent un agent SNMP. Certains logiciels


galement, de mme que les systmes dexploitation commerciaux. Les UNIX
libres, quant eux, utilisent la suite logicielle net-snmp. Celle-ci regroupe un agent,
divers outils dinterrogation ainsi quune bibliothque de fonctions C permettant
de construire des agents SNMP ou dintgrer des capacits dinterrogation dans
dautres logiciels.
Nous tudierons dans ce paragraphe lagent net-snmp ainsi que les outils quil
fournit.
18

4.4. net-snmp

4.4.1

Rcupration des sources

Les sources sont disponibles lURL :


http://net-snmp.sourceforge.net/

4.4.2

Compilation

Une fois larchive dcomprime, la compilation seffectue de manire classique :


% ./configure
creating cache ./config.cache
[...]
creating config.h
% make
[...]

4.4.3

Installation

Aprs avoir pris lidentit du super-utilisateur :


# make install

Ceci installe :
un ensemble de programmes dans /usr/local/bin ;
des bibliothques dans /usr/local/lib afin de pouvoir communiquer par
SNMP depuis des programmes en C ;
les fichiers den-tte correspondants dans /usr/local/include/ucd-snmp ;
divers fichiers dans /usr/local/share/snmp (fichiers de configuration, MIB) ;
des pages de manuel dans /usr/local/man.

4.4.4

Configuration

Lagent SNMP se configure au moyen du fichier /usr/local/share/snmp/snmpd.


Bien que non indispensable (lagent fonctionne fort bien sans ce fichier), il
est prfrable dy dfinir au minimum les paramtres demplacement et de contact,
ainsi que les droits daccs (cest--dire les communauts ou des droits daccs plus
complexes) :
conf.

syslocation

ENSTA - salle verte

syscontact

Sraphin Lampion <seraphin@lampion.org>

rocommunity

public

rwcommunity

private

19

Chapitre 4. Simple Network Management Protocol (SNMP)


Nous ne dtaillerons pas ici la configuration de droits daccs plus fins. Nanmoins, dans des situations relles, il est indispensable dtudier en dtail la documentation des agents SNMP afin de limiter au strict ncessaires les possibilits
daccs.

4.4.5

Lancement de lagent SNMP

Lagent SNMP se lance sous lidentit du super-utilisateur. Compte tenu des


diffrentes actions quil peut tre amen accomplir, il nest pas envisageable den
restreindre les privilges.
Les options les plus utiles sont :
-V pour journaliser (dans le fichier
reus et mis par lagent ;

/var/log/snmpd.log

par dfaut) les messages

-d pour journaliser galement le contenu des datagrammes (cette option est rarement utilise, sauf dans des buts pdagogiques) ;
-A pour journaliser la suite du fichier existant et ne pas en craser lancien
contenu ;
-L pour journaliser lcran plutt que dans un fichier (utile uniquement pendant
la mise au point du fichier de configuration) ;
-f pour que lagent ne se mette pas en arrire-plan (utile uniquement pendant la
mise au point du fichier de configuration).
En pratique, lagent se lance ainsi dans une configuration de production :

# /usr/local/sbin/snmpd -V -A

Lors de la phase de mise au point, il se lance plutt ainsi :

# /usr/local/sbin/snmpd -V -L -f

4.4.6
4.4.6.1

Interrogation dagents SNMP


Parcours dune MIB

Loutil snmpwalk permet de parcourir une MIB (la MIB-II par dfaut) au moyen
de lopration get next. Il suffit de lui indiquer le nom de la machine et la communaut permettant dy accder en lecture :
20

4.5. MRTG

% snmpwalk -v 2c -c public localhost


SNMPv2-MIB::sysDescr.0 = STRING: NetBSD
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.7
SNMPv2-MIB::sysUpTime.0 = Timeticks: (155481919) 17 days, 23:53:39.19
SNMPv2-MIB::sysContact.0 = STRING: Marc Baudoin <babafou@babafou.eu.org>
SNMPv2-MIB::sysName.0 = STRING: babafou.babafou.eu.org
SNMPv2-MIB::sysLocation.0 = STRING: maison
[...]

4.4.6.2

Lecture dun objet

Loutil snmpget permet de rcuprer la valeur dun objet bien prcis (par dfaut
dans la MIB-II) :
% snmpget -v 2c -c public localhost sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: Sraphin Lampion <seraphin@lampion.org>

4.4.6.3

Modification dun objet

Loutil snmpset permet de modifier la valeur dun objet bien prcis (par dfaut
dans la MIB-II) :
% snmpset -v 2c -c private localhost system.sysContact.0 s toto
SNMPv2-MIB::sysContact.0 = STRING: toto

4.5

MRTG

Voici un cas pratique, trs simple et nanmoins fort utile dutilisation de SNMP.
MRTG est un logiciel permettant dinterroger divers types dappareils (routeurs,
commutateurs, ordinateurs) et de reprsenter sous forme graphique le trafic rseau
sur chacune de leurs interfaces. Vous pouvez en voir quelques exemples lURL
suivante :
http://netadm.pasteur.fr/mrtg/

Les graphiques sont raliss en interrogeant les quipements intervalle rgulier


(par dfaut, toutes les cinq minutes) par SNMP.

4.5.1

Rcupration des sources

Les sources sont disponibles lURL :

21

Chapitre 4. Simple Network Management Protocol (SNMP)


http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/

4.5.2

Compilation

Une fois larchive dcomprime, la compilation seffectue de manire classique :


% ./configure
creating cache ./config.cache
[...]
creating config.h
% make
[...]

4.5.3

Installation

Aprs avoir pris lidentit du super-utilisateur :


# make install

Ceci installe :
divers programmes dans /usr/local/mrtg-2/bin ;
de la documentation dans /usr/local/mrtg-2/doc ;
des fichiers additionnels dans /usr/local/mrtg-2/lib ;
des pages de manuel dans /usr/local/mrtg-2/man.
MRTG fonctionne galement fort bien sans quil y ait besoin de linstaller.

4.5.4

Configuration

MRTG se configure au moyen dun fichier qui peut tre gnr automatiquement
grce au programme cfgmaker fourni avec MRTG :
% cfgmaker public@quipement > mrtg.cfg

On peut surveiller ainsi plusieurs quipements diffrents, il suffit de concatner


leurs fichiers de configuration en un seul fichier qui servira de configuration globale
MRTG.
Quelques paramtres peuvent tre rajouts en tte du fichier de configuration
global :
WorkDir: /machin/bidule/mrtg
Language: french
RunAsDaemon: Yes
Options[_]: growright, bits

22

4.5. MRTG
Le paramtre WorkDir indique le chemin daccs du rpertoire dans lequel
MRTG va gnrer ses fichiers HTML et ses images.
Le paramtre Language demande MRTG de parler franais.
Le paramtre RunAsDaemon indique MRTG quil va fonctionner en tche de
fond (plutt que dtre lanc par cron).
Les deux valeurs du paramtre Options demandent MRTG respectivement
dafficher un axe des abscisses orient de gauche droite (il fait linverse par
dfaut) et dindiquer des valeurs de trafic en bits par seconde (il compte en
octets par seconde par dfaut).

4.5.5

Lancement

MRTG se lance en tche de fond en lui indiquant le nom de son fichier de


configuration :
% mrtg mrtg.cfg

Dans une configuration de production, il conviendra de lancer MRTG sous


lidentit dun utilisateur non privilgi puisquil ne ncessite pas les privilges du
super-utilisateur :
# su mrtg -c mrtg mrtg.cfg

23

5
Les annuaires
n dsigne sous le terme gnrique annuaire tout service permettant dobtenir

O des informations partir dune base, centrale ou rpartie (de mme que

lannuaire tlphonique permet dobtenir le numro de tlphone partir du nom


de quelquun).
Les annuaires sont rarement indispensables mais ils apportent un confort non
ngligeable soit aux utilisateurs (cest le cas du DNS) soit ladministrateur rseau
(cest le cas de DHCP).
Les annuaires peuvent gnralement tre grs soit par plusieurs serveurs simultanment soit par un serveur principal et par un ou plusieurs serveurs secondaires qui
en prennent le relais en cas de dfaillance. tant donn limportance que prennent
les annuaires ds quon commence les utiliser, il est indispensable de profiter de
ces capacits de redondance.

5.1

Domain Name System (DNS)

Le DNS est lannuaire le plus ancien et certainement le plus utilis. En effet,


dans un rseau IP, chaque machine est repre par une adresse, qui est un nombre
sur 32 bits pour IPv4 et sur 128 bits pour IPv6. Autant les ordinateurs sont plutt
dous pour grer des nombres, autant nous autres humains le sommes bien moins
et il est plus facile pour nous de mmoriser des noms (faites donc lessai avec vos
amis, vous souvenez-vous plus facilement de leurs noms ou de leurs numros de
tlphone ?). Le DNS est un moyen dassocier un nom chaque adresse IP et vice
versa (ceci est une vision rductrice mais elle correspond lutilisation principale du
DNS).
Le DNS est dcrit dans les RFC 1033 1035 (datant de novembre 1987). De
nombreux autres RFC dcrivent des extensions au DNS.
Le DNS utilise les ports UDP et TCP 53.

5.1.1

Un peu dhistoire

Dans les temps anciens, lpoque o lInternet ntait compos que dune
poigne de machines sur des sites qui se comptaient sur les doigts des deux mains, on
disposait dj dun systme permettant dassocier des noms aux adresses IP. Il tait
25

Chapitre 5. Les annuaires


bas sur un fichier, trs semblable l/etc/hosts des systmes UNIX daujourdhui,
qui devait tre prsent lidentique sur toutes les machines de lInternet. Pour
illustrer ce retour aux sources, considrons le fichier suivant, dont nous utiliserons
les informations par la suite :
147.250.14.1

guinness

147.250.14.2

blanche

videmment, lajout dune nouvelle machine impliquait la recopie du nouveau fichier sur toutes les autres et ce systme a trs vite montr ses limites, do
linvention du DNS.

5.1.2

Principes de fonctionnement

Le DNS est une base de donnes rpartie. Par rapport au systme prcdent, on
ne dispose plus dun fichier unique de correspondances entre adresses IP et noms
mais de plusieurs et chaque site maintient les informations correspondant ses
machines et les met la disposition du reste de lInternet par un protocole appropri.
Pour savoir quel serveur interroger, le systme de nommage a t hirarchis. cet
effet, lInternet a t dcoup en domaines. Un domaine correspond un ensemble
de machines dpendant administrativement de la mme entit.
5.1.2.1

Le systme de nommage

Toute hirarchie commenant quelque part, la racine du DNS sappelle . .


Sous cette racine ont t crs des top-level domains (TLD) permettant deffectuer
un premier rangement des niveau infrieurs. Parmi les TLD, on retrouve :
des domaines fonctionnels crs lorigine par et pour les amricains, ce qui
explique leur vision un peu rduite des choses :
com pour les entreprises,
edu pour les universits,
gov pour les institutions gouvernementales,
int pour les organismes internationaux,
mil pour les organismes militaires (lInternet ayant t invent par les
militaires amricains),
net pour les fournisseurs daccs lInternet,
org pour les autres organisations ;
des domaines nationaux crs par la suite selon la norme ISO 3166-1 :
au pour lAustralie,
de pour lAllemagne,
fr pour la France,
etc.
26

5.1. Domain Name System (DNS)


Ces TLD ont des sous-domaines, comme par exemple ensta.fr quon devrait
dailleurs crire ensta.fr. (notez le point final) si lon voulait tre exact. On remarque donc que le point sert la fois dsigner le domaine racine et sparer les
diffrents composants des noms de domaine (un peu comme le / pour les chemins
daccs sous UNIX la diffrence que les chemins daccs se lisent de gauche droite
alors que les noms de domaine se lisent de droite gauche).
Lentit qui a obtenu la dlgation (cest--dire la gestion) dun domaine peut
alors crer loisir des noms de machines dans ce domaine et leur associer des adresses
IP (puisque cest tout de mme le but du DNS). Lorsquon a beaucoup de machines,
il peut savrer utile de crer des sous-domaines afin de permettre un nommage plus
propre en introduisant un ou plusieurs niveaux de hirarchie supplmentaires. Par
exemple, nous travaillerons par la suite avec le domaine tp.ensta.fr.
Le nom qualifi dune machine (en anglais, fully qualified domain name ou
FQDN), cest--dire son nom complet comprenant le domaine, par exemple guinness.tp.ensta.fr,
ne peux excder 255 caractres et chacun des composants (les parties entre deux
points successifs) ne peut excder 63 caractres, ce qui laisse tout de mme de la
marge. Un nom de machine ou un nom de domaine ne peut contenir que des lettres
(majuscules ou minuscules, aucune diffrence nest faire ce niveau), des chiffres ou
des tirets. Tout autre caractre est interdit.
Un point de vocabulaire : on distingue la zone ensta.fr du domaine ensta.fr.
La zone ensta.fr ne contient que les informations concernant les machines situes
directement sous ensta.fr (donc la machine guinness.tp.ensta.fr nen fait pas
partie puisquelle appartient un sous-domaine densta.fr), alors que le domaine
ensta.fr contient la zone ensta.fr, les zones correspondants aux sous-domaines
densta.fr et ainsi de suite.
5.1.2.2

Les serveurs

Chaque zone dispose dun ou de plusieurs serveurs DNS. Sil y en a plusieurs,


lun deux est dit matre et les autres sont ses esclaves (on parlait de primaire et de
secondaires dans lancienne terminologie du DNS). Le serveur matre est le vrai
dtenteur des informations de la zone, les esclaves se contentent de les recopier.
chaque modification des informations dune zone, le serveur matre avertit
ses esclaves pour quils puissent se mettre jour. Toute modification sur le matre se
rpercute donc trs rapidement sur ses esclaves. Lopration de mise jour sappelle
un transfert de zone.
Le serveur matre et ses esclaves font autorit sur les zones quils grent (cest-dire queux seuls dtiennent les tables de correspondance officielles pour ces zones).
5.1.2.3

La rsolution de nom

Si jai besoin de savoir ladresse IP associe une machine de la zone ensta.fr, je


vais madresser lun des serveurs qui font autorit pour cette zone. Mais quels sont
ces serveurs ? Comme la structure du DNS est hirarchique, il suffit de le demander
27

Chapitre 5. Les annuaires


lun des serveurs de la zone fr. Si je ne les connais pas non plus, je vais demander
leurs adresses lun des serveurs de la racine. Puisquil faut bien quune arborescence
commence quelque part, ces derniers sont connus (il y en a actuellement treize,
rpartis sur la plante) et permettent donc de toujours pouvoir descendre larbre du
DNS. Lensemble de ce processus sappelle la rsolution de nom.
Un processus qui a besoin de convertir un nom de machine en adresse IP
neffectue jamais la rsolution de nom lui-mme. Pour cela, il sadresse au serveur
DNS de son site, dont ladresse IP (pas le nom, pour des raisons videntes) figure
dans le fichier /etc/resolv.conf (ce fichier peut contenir plusieurs adresses de
serveurs de noms, ils sont alors interrogs dans lordre jusqu obtenir une rponse).
Cest le serveur DNS local qui va effectuer la rsolution de nom et en renvoyer le
rsultat au processus demandeur. En prime, le serveur DNS va conserver la rponse
dans un cache, afin dviter de refaire cette gymnastique sil reoit la mme requte
dans le futur.
Si plusieurs adresses IP diffrentes sont associes au mme nom de machine
(ce qui peut arriver, par exemple dans le cas de services redondants), un serveur
DNS donn renverra successivement la premire, puis la deuxime et ainsi de suite
jusqu la dernire, puis il reprendra du dbut. Ce mcanisme sappelle le tourniquet
(round-robin en anglais) et permet de faire une rpartition de charge naturelle entre
des machines diffrentes mais rpondant au mme nom (ce qui est donc transparent
pour lutilisateur).

5.1.3

Interrogation du DNS avec dig

Le DNS est gnralement interrog de manire transparente par divers programme mais il est galement possible de linterroger explicitement, pour tester un
serveur ou par simple curiosit. Les principaux programmes permettant ceci sont
dig, nslookup et host. Plus spartiate, dig est nanmoins plus prcis et les puristes le
prfrent aux autres, principalement parce quil renvoie des rsultats dans un format
directement exploitable par un serveur de noms.
Lanc sans argument, dig affiche la liste des serveurs de noms de la racine :
28

5.1. Domain Name System (DNS)

% dig
; <<>> DiG 9.1.3 <<>>
;; global options:

printcmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 641
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUESTION SECTION:
;.

IN

NS

;; ANSWER SECTION:
.

253982

IN

NS

I.ROOT-SERVERS.NET.

253982

IN

NS

J.ROOT-SERVERS.NET.

253982

IN

NS

K.ROOT-SERVERS.NET.

253982

IN

NS

L.ROOT-SERVERS.NET.

253982

IN

NS

M.ROOT-SERVERS.NET.

253982

IN

NS

A.ROOT-SERVERS.NET.

253982

IN

NS

B.ROOT-SERVERS.NET.

253982

IN

NS

C.ROOT-SERVERS.NET.

253982

IN

NS

D.ROOT-SERVERS.NET.

253982

IN

NS

E.ROOT-SERVERS.NET.

253982

IN

NS

F.ROOT-SERVERS.NET.

253982

IN

NS

G.ROOT-SERVERS.NET.

253982

IN

NS

H.ROOT-SERVERS.NET.

I.ROOT-SERVERS.NET.

474182

IN

192.36.148.17

J.ROOT-SERVERS.NET.

474182

IN

192.58.128.30

K.ROOT-SERVERS.NET.

474182

IN

193.0.14.129

L.ROOT-SERVERS.NET.

474182

IN

198.32.64.12

M.ROOT-SERVERS.NET.

474182

IN

202.12.27.33

A.ROOT-SERVERS.NET.

474182

IN

198.41.0.4

B.ROOT-SERVERS.NET.

474182

IN

128.9.0.107

C.ROOT-SERVERS.NET.

474182

IN

192.33.4.12

D.ROOT-SERVERS.NET.

474182

IN

128.8.10.90

E.ROOT-SERVERS.NET.

474182

IN

192.203.230.10

F.ROOT-SERVERS.NET.

474182

IN

192.5.5.241

G.ROOT-SERVERS.NET.

474182

IN

192.112.36.4

H.ROOT-SERVERS.NET.

474182

IN

128.63.2.53

;; ADDITIONAL SECTION:

;; Query time: 118 msec


;; SERVER: 147.250.1.1#53(147.250.1.1)
;; WHEN: Sun Jan
;; MSG SIZE

5 17:19:53 2003

rcvd: 436

On peut remarquer plusieurs choses :


29

Chapitre 5. Les annuaires


la rponse est au format des fichiers de configuration des serveurs de nom
(qui sera tudi dans le paragraphe 5.1.4), ce qui permet ventuellement de
rinjecter ces donnes sans autre traitement ;
en consquence, les lignes commenant par un point-virgule sont des commentaires (mais elles contiennent nanmoins des informations intressantes
pour le lecteur humain) ;
les noms qualifis sont tous termins par le point de la racine.
Demandons maintenant au DNS ladresse IP correspondant la machine
:

ensta.ensta.fr

% dig a ensta.ensta.fr.
; <<>> DiG 9.1.3 <<>> a ensta.ensta.fr.
;; global options:

printcmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45952
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;ensta.ensta.fr.

IN

;; ANSWER SECTION:
ensta.ensta.fr.

259200

IN

147.250.1.1

ensta.fr.

259200

IN

NS

ensta.ensta.fr.

ensta.fr.

259200

IN

NS

nis1.ensta.fr.

ensta.fr.

259200

IN

NS

nis2.ensta.fr.

ensta.ensta.fr.

259200

IN

147.250.1.1

nis1.ensta.fr.

259200

IN

147.250.1.21

nis2.ensta.fr.

259200

IN

147.250.1.22

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 63 msec


;; SERVER: 147.250.1.1#53(147.250.1.1)
;; WHEN: Sun Jan
;; MSG SIZE

5 17:17:31 2003

rcvd: 148

La rponse se trouve dans la partie ANSWER

SECTION.

Si maintenant, nous cherchons le nom qualifi correspondant ladresse 147.250.1.1 :


30

5.1. Domain Name System (DNS)

% dig -x 147.250.1.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45845
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;1.1.250.147.in-addr.arpa.

IN

PTR

;; ANSWER SECTION:
1.1.250.147.in-addr.arpa. 259200 IN

PTR

ensta.ensta.fr.

;; AUTHORITY SECTION:
250.147.in-addr.arpa.

259200

IN

NS

ensta.ensta.fr.

250.147.in-addr.arpa.

259200

IN

NS

nis1.ensta.fr.

250.147.in-addr.arpa.

259200

IN

NS

nis2.ensta.fr.

ensta.ensta.fr.

259200

IN

147.250.1.1

nis1.ensta.fr.

259200

IN

147.250.1.21

nis2.ensta.fr.

259200

IN

147.250.1.22

;; ADDITIONAL SECTION:

;; Query time: 14 msec


;; SERVER: 147.250.1.1#53(147.250.1.1)
;; WHEN: Sun Jan
;; MSG SIZE

5.1.4

5 17:18:22 2003

rcvd: 170

BIND

Le logiciel utilis sur quasiment tous les serveurs de noms du monde est Berkeley
Internet Name Domain (BIND), dvelopp par lInternet Software Consortium
(ISC).
BIND est livr en standard avec tous les systmes UNIX mais il sagit rarement
de la dernire version. Or il est important de toujours utiliser la dernire version de
BIND pour viter lexploitation de failles de scurit connues et pour profiter des
dernires fonctionnalits (BIND ayant normment volu ces dernires annes).
La dernire version de BIND est la 9.7.0, sortie le 16 fvrier 2010. De nombreux
serveurs DNS utilisent encore BIND 8 ou BIND 4 (il ny a pas eu de versions
intermdiaires entre BIND 4 et 8) mais seule la version 9 est activement dveloppe
par lISC.
5.1.4.1

Rcupration des sources

Pour installer BIND, lidal est de sen procurer les sources directement chez
lInternet Software Consortium. Elle sont disponibles lURL :
31

Chapitre 5. Les annuaires


ftp://ftp.isc.org/isc/bind9/

5.1.4.2

Compilation

Une fois larchive dcomprime, la compilation seffectue de manire classique :


% ./configure
creating cache ./config.cache
[...]
creating config.h
% make

5.1.4.3

Installation

Aprs avoir pris lidentit du super-utilisateur :


# make install

Ceci installe :
des excutables dans /usr/local/bin (dont dig) et
named, qui est le serveur de noms).
des fichiers den-tte dans /usr/local/include ;
des bibliothques dans /usr/local/lib ;
5.1.4.4

/usr/local/sbin

(dont

Configuration

BIND se configure au moyen dun fichier principal et de plusieurs fichiers


auxiliaires. Le fichier principal sappelle par convention named.conf (bien quon
puisse utiliser un autre nom, je vous recommande de garder celui-ci) et se trouve par
dfaut dans le rpertoire /etc (on peut utiliser un autre rpertoire et nous allons
dailleurs le faire par la suite).
Par dfaut, BIND est conu pour fonctionner sous lidentit du super-utilisateur.
Un logiciel de cette complexit nest pas labri derreurs de conception et danciennes versions comportaient des failles permettant de prendre le contrle de
la machine hbergeant le serveur de noms. Comme BIND peut tout aussi bien
fonctionner sous lidentit dun utilisateur non privilgi (bien que trop peu dadministrateurs prennent la peine de le faire), nous allons donc utiliser cette possibilit.
De mme, BIND peut fonctionner dans un systme de fichiers restreint par
lappel systme chroot(). Nous utiliserons galement cette option de scurit.
Il faut maintenant choisir un rpertoire o placer les diffrents fichiers de
configuration. Cest galement dans ce rpertoire que sera confin le dmon named.
Prenons par exemple /opt/dns.
Le fichier named.conf, situ dans le prcdent rpertoire, contiendra :
32

5.1. Domain Name System (DNS)

options
{
directory "/" ;
} ;
# serveurs racine
zone "."
{
type hint ;
file "named.root" ;
} ;
# zones matres
zone "tp.ensta.fr"
{
type master ;
file "master/tp.ensta.fr" ;
} ;
zone "14.250.147.in-addr.arpa"
{
type master ;
file "master/14.250.147.in-addr.arpa" ;
} ;
# zones esclaves
zone "ensta.fr"
{
type slave ;
file "slave/ensta.fr" ;
masters
{
147.250.1.1 ;
} ;
} ;

Les commentaires sont introduits par un # initial (comme en Perl), un // initial


ou entours par /* et */ (comme en C++).
Le groupe options spcifie les options gnrales pour le serveur. Ici, on indique
33

Chapitre 5. Les annuaires


le rpertoire dans lequel les fichiers que lon indiquera par la suite seront placs.
Puisquon va mettre les fichiers dans /opt/dns et se restreindre ce rpertoire, cest
/ quon indique dans la directive directory.
son lancement, tout serveur DNS a besoin de connatre les serveurs de la
racine. Il faut donc les lui fournir dans le fichier named.root (disponible lURL ftp:
//ftp.internic.net/domain/named.root). Ces donnes lui serviront uniquement
contacter lun des serveurs de la racine pour y charger une zone jour (do le type
hint li cette zone).
Chaque zone pour laquelle le serveur est matre est du type master et est
contenue dans un fichier plac dans le rpertoire master (on aurait pu appeler
ce rpertoire tout autrement, voire ne pas mettre les fichiers dans un rpertoire
particulier, mais ceci permet de ranger les fichiers proprement et dtre cohrent
avec la dnomination utilise dans named.conf). Par souci de clart, chaque fichier
aura le mme nom que la zone quil contient (l encore, ce nest quune convention).
De mme, chaque zone pour laquelle le serveur est esclave est du type slave et
est contenue dans un fichier de mme nom que la zone et plac dans le rpertoire
slave. On indique de plus ladresse IP du serveur matre pour cette zone afin de ly
tlcharger.
Les fichiers des zones pour lesquelles le serveur est esclave tant automatiquement remplis par transfert de zone, nous nous intresserons par la suite aux fichiers
des zones pour lesquelles le serveur est matre.
tudions la zone matre tp.ensta.fr :
$TTL 1d
@

IN

SOA

ns.ensta.fr. hostmaster.ensta.fr. (
2001012800

; serial

; RFC 1537
8h

; refresh

2h

; retry

1w

; expiry

1h )

; negative caching

IN

NS

ns.ensta.fr.

localhost

IN

127.0.0.1

guinness

IN

147.250.14.1

blanche

IN

147.250.14.2

Les commentaires sont introduits par un ; et stendent jusqu la fin de la ligne.


Chaque fichier de zone commence par une directive $TTL qui indique la dure de
vie (time to live) des informations de cette zone lorsquelles seront dans le cache dun
34

5.1. Domain Name System (DNS)


autre serveur DNS. Pour notre zone, les informations resteront dans le cache des
autres serveurs pendant une journe (1d). Par la suite, toute demande de rsolution
de nom sera honore partir du cache, jusqu ce quune journe se soit coule,
auquel cas linformation en sera supprime.
Le reste du fichier de zone contient des dfinitions de resource records (RR).
Chaque RR tient habituellement sur une ligne de la forme :
nom_du_paramtre

IN

valeur(s)_du_paramtre

RR

Ici, IN indique que le RR est de la classe Internet. Il existe dautres classes mais,
en pratique, elles ne sont pas utilises.
Le premier RR du fichier est le SOA (start of authority), qui indique divers
paramtres de la zone.
La premire ligne indique :
le nom de la zone contenue dans le fichier ou @ pour utiliser le nom de zone
tel quindiqu dans named.conf ;
la classe Internet ;
le type du RR (ici SOA) ;
le nom du serveur matre pour cette zone ;
ladresse lectronique de la personne responsable de cette zone.
Dans cette adresse, le @ habituel est remplac par un point (ce qui implique que
la partie gauche de ladresse ne peut pas en contenir). Le RFC 2142 recommande
que cette adresse soit hostmaster.
Notez les points terminaux qui indiquent la racine du DNS ( partir de maintenant, faites attention ne pas les oublier, sauf dans certains cas qui seront dtaills
plus loin).
Suivent un ensemble de paramtres numriques, contenus entre parenthses (ce
qui permet de faire tenir le RR sur plusieurs lignes ; cette possibilit nest dailleurs
utilise que pour le SOA) :
Le numro de srie qui est un entier sur 32 bits devant tre augment chaque
modification de la zone. Par convention (et parce que a tient dans un entier
de 32 bits), on utilise un format AAAAMMJJNN contenant la date de la
dernire modification de la zone au format ISO 8601 (AAAA pour lanne,
MM pour le mois, JJ pour le jour) suivie dun numro dordre (NN valant 00
pour la premire modification du jour, 01 pour la deuxime, etc.). Une erreur
classique consiste modifier les donnes de la zone sans augmenter le numro
de srie.
La dure de rafrachissement qui tait utilise par les esclaves pour savoir quel
intervalle ils devaient interroger le matre pour savoir si une zone avait t
modifie. Maintenant, le matre avertit immdiatement ses esclaves de toute
modification donc ce paramtre nest plus utilis.
35

Chapitre 5. Les annuaires


La dure de nouvel essai qui est utilise par les esclaves pour savoir, aprs une
tentative choue de transfert de zone, au bout de combien de temps ils
peuvent la retenter.
La dure dexpiration qui est utilise par les esclaves pour savoir, sils ne peuvent
pas mettre jour leurs zones auprs du matre, au bout de combien de temps
ils doivent effacer leurs donnes.
Le TTL ngatif qui indique aux caches combien de temps ils doivent conserver les
rponses ngatives.
Le RFC 1537 explique le choix de ces valeurs (sauf pour la dernire, dont la
signification a chang rcemment).
On trouve ensuite les RR NS, qui indiquent quels sont les serveurs de nom pour
la zone. Aucune diffrence nest faite ici entre matre et esclaves mais lhabitude veut
quon fasse figurer le matre en premire position.
Notez que, dans ce RR, la premire colonne est laisse vide. Dans ce cas, sa
valeur est prise de la premire colonne du RR prcdent.
Viennent enfin les RR contenant les correspondances entre noms de machines
et adresses IP. Ici, il sagit dune zone directe donc les RR sont de type A. Notez que
lon na pas ajout le nom de la zone aux noms de machines et que lon na pas mis
de points terminaux. Dans ce cas, le nom de la zone est automatiquement rajout.
Un tel RR :

guinness.tp.ensta.fr

IN

147.250.14.1

se verrait donc transform en :

guinness.tp.ensta.fr.tp.ensta.fr.

IN

147.250.14.1

en raison de labsence du point terminal. Il convient donc dy tre attentif.


tudions maintenant la zone matre 14.250.147.in-addr.arpa. Il sagit dune
zone inverse (cest--dire contenant les correspondances entre adresses IP et noms
de machines) :
36

5.1. Domain Name System (DNS)

$TTL 1d
@

IN

SOA

ns.ensta.fr. hostmaster.ensta.fr. (
2001012800

; serial

; RFC 1537
8h

; refresh

2h

; retry

1w

; expiry

1h )

; negative caching

IN

NS

ns.ensta.fr.

IN

PTR

guinness.tp.ensta.fr.

IN

PTR

blanche.tp.ensta.fr.

Tout dabord, le nom de cette zone est particulirement trange. Le domaine


in-addr.arpa nest utilis que pour les zones inverses. Et comme la hirarchie des
domaines se lit de droite gauche, les adresses IP dans les zones inverses sont crites
dans ce sens, lenvers du sens normal de lecture.
Pour le reste, ce fichier de zone est trs semblable un fichier de zone directe, la diffrence quon utilise des RR de type PTR et quon ncrit en premire colonne que le dernier octet de ladresse IP (la suite tant complte par
14.250.147.in-addr.arpa en labsence du point final).
Une dlgation se fait tout simplement en indiquant dans la zone mre des RR
NS pour sa zone fille. Il faut galement indiquer ladresse IP des serveurs de noms
(problme duf et de poule). Ainsi, pour dlguer une zone b1-4.tp.ensta.fr, on
peut rajouter au fichier de la zone tp.ensta.fr :
b1-4

IN

NS

ns.b1-4

ns.b1-4

IN

147.250.14.51

5.1.4.5

Lancement

Pour pouvoir utiliser les ports UDP et TCP 53, le serveur de noms a besoin
dtre lanc sous lidentit du super-utilisateur.
Il est recommand dutiliser les options suivantes :
-t qui indique le rpertoire auquel restreindre le serveur ;
-c qui indique le nom du fichier de configuration relativement ce rpertoire ;
-u qui indique le nom de lutilisateur sous lidentit duquel tournera le serveur de
noms aprs son dmarrage.
Ainsi, le serveur de noms peut se lancer par la commande :
37

Chapitre 5. Les annuaires

# named -t /opt/dns -c /named.conf -u dns

5.1.5 Quelques liens

http://www.isc.org/services/public/F-root-server.html ou tout ce que


vous avez toujours voulu savoir sur un serveur de la racine sans avoir jamais
os le demander.
http://www.internic.net/ LInterNIC est lorganisme qui gre les zones
.com, .org et autres.
http://www.nic.fr/ LAFNIC est lorganisme qui gre la zone .fr.
http://www.eu.org/ EU.org, dlgation gratuite de domaines.
http://www.isc.org/software/bind/ Le site officiel de BIND.
http://www.esil.univ-mrs.fr/~lafirme/named/ Installer un serveur DNS
scuris.
http://www.acmebw.com/askmr.htm Ask Mr. DNS.

5.1.6 Quelques bizarreries


Les noms de domaine trs longs sont-ils utiles ?
http:
//www.llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk
http:
//www.fautvraimentetreconpouravoiruneadresseinternetaussilongue.com/
http://3.
141592653589793238462643383279502884197169399375105820974944592.com/

5.2

Lightweight Directory Access Protocol (LDAP)

LDAP est lannuaire qui monte en ce moment. Il est principalement utilis pour
centraliser les bases dauthentification ou les carnets dadresses lectroniques mais il
sagit dun annuaire gnraliste pouvant tre utilis pour presque nimporte quoi.
LDAP est dcrit dans le RFC 2251 et utilise le port TCP 389.

5.2.1

Principes

LDAP est ladaptation dans le monde IP de DAP (Directory Access Protocol), qui
permet daccder des annuaires X.500 dans le monde ISO. Cest ce qui explique la
structure particulires des bases LDAP et leur systme de nommage.
la diffrence des systmes de gestion de bases de donnes (SGBD), les bases
LDAP sont optimises pour la lecture. En consquence, elles peuvent aisment tre
rpliques pour assurer une meilleure disponibilit.
38

5.2. Lightweight Directory Access Protocol (LDAP)


Une base LDAP est compose dentres. Chaque entre regroupe un certain
nombre dattributs et a un DN (Distinguished Name) qui doit tre unique au sein de
lensemble de la base. Chacun des attributs a un type et une ou plusieurs valeurs.
Chaque entre a un attribut spcial indiquant la classe de lentre. Celle-ci
contrle quels attributs sont autoriss dans lentre. Ainsi il existe une classe organisation , une classe personne , etc.
Les entres sont dfinis dans un format de fichier spcial appel LDIF (LDAP
Data Interchange Format) et dcrit dans le RFC 2849.
Quelques exemples permettront dy voir plus clair.
dn: dc=ensta,dc=fr
objectclass: organization
o: ENSTA
postalAddress: 32, boulevard Victor

On dfinit ici un objet du type organization dfini par un DN utilisant le


domaine DNS de lorganisation au moyen dlments DC (Domain Component).
On indique galament le nom de lorganisation et son adresse postale.
La structure dun annuaire LDAP est hirarchique. Une fois lorganisation
dfinie, on peut dfinir diffrents services en son sein :
dn: ou=sports,dc=ensta,dc=fr
objectclass: organizationalUnit
ou: sports

En dessous de lentre prcdente, on dfinit donc le service sports , dont on


peut maintenant indiquer les membres :
dn: cn=Gerard Perbal,ou=sports,dc=ensta,dc=fr
objectclass: inetOrgPerson
cn: Gerard Perbal
sn: Perbal
uid: perbal
mail: perbal@ensta.fr

Les trois classes que nous venons de voir sont les plus frquemment utilises
(surtout la dernire) dans les annuaires LDAP, bien quil en existe de nombreuses
autres.
Les attributs possibles pour ces classes sont les suivants :
organization

(obligatoire)
39

Chapitre 5. Les annuaires

businessCategory
description
facsimileTelephoneNumber
location (l)
postalAddress
seeAlso
telephoneNumber

organizationalUnit

ou

(obligatoire)

businessCategory
description
facsimileTelephoneNumber
location (l)
postalAddress
seeAlso
telephoneNumber

inetOrgPerson

commonName (cn)
surname (sn)

(obligatoire)
(obligatoire)

businessCategory
carLicense
departmentNumber
description
employeeNumber
facsimileTelephone
Number
givenName
mail
manager
mobile
organizationalUnit (ou)
pager
postalAddress
roomNumber
secretary
seeAlso
telephoneNumber
title
labeledURI
uid

40

5.2. Lightweight Directory Access Protocol (LDAP)


La hirarchie prcdente est base sur le DNS, simplement parce que ceci assure
lunicit du nommage, mais on peut galement dfinir une hirarchie gographique :
dn: o=ENSTA,c=FR
objectclass: organization
o: ENSTA
postalAddress: 32, boulevard Victor

Dans cet exemple, c indique le code du pays et o le nom de lorganisme.


Ici se termine cette courte introduction LDAP mais vous trouverez ici de quoi
approfondir vos connaissances :
http:
//www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html

5.2.2

OpenLDAP

Le serveur LDAP le plus rpandu sous UNIX est OpenLDAP 1 , dont la dernire
version est la 2.4.21.
5.2.2.1

Rcupration des sources

Les sources sont disponibles lURL :


ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/

5.2.2.2

Compilation

Une fois larchive dcomprime, la compilation seffectue de manire classique :


% ./configure
creating cache ./config.cache
[...]
creating config.h
% make

5.2.2.3

Installation

Aprs avoir pris lidentit du super-utilisateur :


# make install

1.

http://www.openldap.org/

41

Chapitre 5. Les annuaires


5.2.2.4

Configuration

OpenLDAP est un logiciel bien trop complexe pour que sa configuration soit
dcrite en dtail ici. Dans le cadre de ce cours, vous pouvez vous reporter http:
//www.openldap.org/doc/admin/quickstart.html.
Pour la documentation complte dOpenLDAP (un peu lgre par endroits,
dailleurs), vous pouvez vous rfrer http://www.openldap.org/doc/admin/.
5.2.2.5

Tests

Outre le programme ldapsearch, fourni avec OpenLDAP mais dun usage peu
pratique, il est possible dinterroger une base LDAP avec le client graphique http:
//biot.com/gq/ ou avec le carnet dadresses du module de courrier lectronique de
Netscape.
5.2.2.6

Cas pratique

Vous trouverez lURL http://www.hsc.fr/ressources/breves/openldap.html


une utilisation typique de LDAP consistant centraliser une base dauthentification.

5.3

Autres annuaires

Network Information System (NIS), auparavant appel Yellow Pages (YP) est
un systme cr par Sun Microsystems et permettant le partage de divers bases
dinformations (notamment /etc/passwd et /etc/group) au sein dun ensemble de
machines sous UNIX. Il est aujourdhui en voie de disparition au profit de LDAP.

42

6
La messagerie

a messagerie est certainement lun des services rseau les plus utiliss. Il existe

L de nombreux systmes de messagerie propritaires mais aujourdhui la majorit

des messageries utilise le protocole SMTP (Simple Mail Transfer Protocol). Quelques
messageries dentreprise utilisent galement le protocole X.400 mais uniquement
en interne, la communication vers lextrieur se faisant par lintermdiaire dune
passerelle SMTP.
SMTP est dcrit dans le RFC 5321. Le format des courriers lectroniques est
dcrit dans le RFC 5322. SMTP utilise le port TCP 25.

6.1

SMTP

Le fonctionnement de SMTP est en fait trs simple. tudions une session type :
43

Chapitre 6. La messagerie

% echo test | mail -v -s test babafou@babafou.eu.org


babafou@babafou.eu.org... Connecting to ensta.ensta.fr.
via nullclient...
220 ensta.ensta.fr ESMTP The Internet gateway to ENSTA
(8.9.1/8.9.1) ready at Sun, 11 Feb 2001 14:51:38 +0100 (CET)
>>> EHLO olive13.ensta.fr
250-ensta.ensta.fr Hello IDENT:root@olive13.ensta.fr [147.250.9.23],
pleased to meet you
250-8BITMIME
250-SIZE
250-ONEX
250-ETRN
250-XUSR
250 HELP
>>> MAIL From:<baudoin@ensta.fr> SIZE=47
250 <baudoin@ensta.fr>... Sender ok
>>> RCPT To:<babafou@babafou.eu.org>
250 <babafou@babafou.eu.org>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 OAA21364 Message accepted for delivery
babafou@babafou.eu.org... Sent (OAA21364 Message accepted for delivery)
Closing connection to ensta.ensta.fr.
>>> QUIT
221 ensta.ensta.fr closing connection

Loption -v de la commande mail permet dafficher le dialogue entre la machine


expditrice et le serveur de messagerie (attention, il sagit du serveur de messagerie du
site expditeur, qui se chargera ensuite denvoyer le message au serveur de messagerie
du site destinataire). Les lignes prfixes par >>> sont envoyes du client au serveur
de messagerie, celles qui commencent par un nombre sont envoyes du serveur au
client, les quelques autres sont purement informatives.
ltablissement de la connexion, le serveur est le premier parler, affichant
quelques informations sur le logiciel quil utilise :
220 ensta.ensta.fr ESMTP The Internet gateway to ENSTA
(8.9.1/8.9.1) ready at Sun, 11 Feb 2001 14:51:38 +0100 (CET)

Le client se prsente ensuite en indiquant son nom qualif :


>>> EHLO olive13.ensta.fr

et le serveur lui rend la politesse en indiquant la liste des options quil connat :
44

6.1. SMTP

250-ensta.ensta.fr Hello IDENT:root@olive13.ensta.fr [147.250.9.23],


pleased to meet you
250-8BITMIME
250-SIZE
250-ONEX
250-ETRN
250-XUSR
250 HELP

Lenvoi du message proprement dit peut commencer, le client indique ladresse


lectronique de lexpditeur et la taille du message :
>>> MAIL From:<baudoin@ensta.fr> SIZE=47

Le message, tel que gnr par mail, est le suivant, vous pouvez recompter, il
contient bien 47 caractres :
To: babafou@babafou.eu.org
Subject: test
test

Le client indique ensuite ladresse lectronique du destinataire :


>>> RCPT To:<babafou@babafou.eu.org>

et envoie le message :
>>> DATA

Le message en question est celui indiqu plus haut, avec ses en-ttes et son
corps. Le serveur de messagerie rajoutera dailleurs dautres en-ttes pour aboutir au
message qui partira effectivement.
Les adresses lectroniques indiques par le client dans son dialogue avec le
serveur (par les commandes MAIL From et RCPT To) constituent ce quon appelle les
adresses denveloppe du message. Elles correspondent gnralement aux adresses
indiques en From, To et Cc de len-tte du message, sauf dans le cas dadresses en Bcc,
auxquel cas celles-ci napparaissent nulle part dans len-tte mais figurent bel et bien
dans lenveloppe.
45

Chapitre 6. La messagerie

6.2

Relation avec le DNS

Comment dterminer quel est le serveur de messagerie du site destinataire ? Le


RFC 2219 indique bien quil est cens sappeler mail.domaine mais cest loin dtre
le cas sur tous les sites. De plus, comment faire sil y a plusieurs serveurs ?
Le DNS dispose donc dun RR de type MX, qui indique quel est le serveur de
messagerie associ une zone :
ensta.fr.

IN

MX

10 ensta.ensta.fr.

Le serveur de messagerie pour la zone ensta.fr est donc la machine ensta.ensta.fr.


Le nom de cette machine est prcd dun entier naturel indiquant la priorit relative
du serveur. Cet entier est appel le poids du serveur. En effet, une zone peut disposer
de plusieurs serveurs de messagerie et il faut pouvoir connatre la priorit de chaque
serveur. Plus le poids est petit, plus le serveur est prioritaire. Ainsi, si le serveur de
poids le plus faible ne rpond pas, le courrier sera envoy au deuxime, sinon au
troisime et ainsi de suite. La valeur des poids na pas dimportance, seule en a leur
position relative dans lordre croissant.
pasteur.fr.

IN

MX

0 mail.pasteur.fr.

IN

MX

10 mail0.pasteur.fr.

Dans lexemple prcdent, le courrier sera tout dabord envoy au serveur

mail.pasteur.fr. Si celui-ci ne rpond pas, il sera alors envoy au serveur mail0.pasteur.fr.

6.3

Serveurs de messagerie

Il existe de nombreux serveurs de messagerie. Sous UNIX, les plus rpandus


sont :
sendmail 1
Postfix 2
et, dans une moindre mesure :
qmail 3
exim 4
Sendmail, le logiciel de messagerie historique (sa premire version remonte au
dbut des annes 1980), est encore utilis sur de trs nombreux serveurs de messagerie. Cependant, un systme de configuration complexe (mme sil est maintenant
masqu par des outils plus simples), une structure monolithique et une longue
histoire de problmes de scurit (dont le dernier remonte pourtant 1997) lui font
aujourdhui prfrer dautres logiciels, notamment Postfix.
1.
2.
3.
4.

http://www.sendmail.org/
http://www.postfix.org/
http://www.qmail.org/
http://www.exim.org/

46

6.4. sendmail

6.4

sendmail

La messagerie lectronique doit beaucoup sendmail, qui quipait il y a quelques


annes la quasi-totalit des serveurs de lInternet. Les administrateurs de messagerie
doivent galement beaucoup sendmail, qui leur a procur des nuits blanches en
grand nombre. En effet, sendmail est rput pour les nombreux problmes de
scurit dont il a t affect. Programme monolithique complexe fonctionnant
sous lidentit du super-utilisateur, sendmail a dailleurs t lun des vecteurs de
propagation du ver de lInternet en 1988. Il ne faut cependant pas tre mauvaise
langue car sendmail na pas eu de problme de scurit connu depuis 1997. En
revanche, il a conserv sa structure monolithique complexe et fonctionne toujours
sous lidentit du super-utilisateur, ce qui en fait un danger potentiel.
De nombreux UNIX fournissent sendmail en standard mais il sagit rarement de
la dernire version. Bien que les soucis de scurit semblent maintenant appartenir
au pass, il est cependant prudent dutiliser la version de sendmail la plus rcente. Il
sagit actuellement de la version 8.14.3, sortie le 3 mai 2008.

6.4.1

Rcupration des sources

Les sources de sendmail sont disponibles lURL :


ftp://ftp.sendmail.org/pub/sendmail/

6.4.2

Compilation

La compilation seffectue dans le rpertoire sendmail de la distribution source


au moyen de la commande :
% sh Build

6.4.3

Installation

Aprs avoir pris lidentit du super-utilisateur :


# sh Build install

6.4.4

Configuration

Tout administrateur rseau vous dira que la configuration de sendmail est un


cauchemar : cest vrai. Mais seulement quand on ne sait pas comment sy prendre
parce que, finalement, si on ne regarde pas tout ce quil y a au-dessous, ce nest
pas bien mchant. Le but de ce cours ntant pas de dtailler la configuration de
sendmail, nous allons survoler le clbre fichier sendmail.cf et voir comment le
gnrer plus simplement. Les curieux pourront se reporter louvrage sendmail [9]
de la bibliographie.
47

Chapitre 6. La messagerie
6.4.4.1

Le fichier sendmail.cf

Le fichier de configuration de sendmail sappelle sendmail.cf et se trouve dans


le rpertoire /etc/mail (les versions de sendmail antrieures la 8.10 utilisaient le
rpertoire /etc).
Comme dans beaucoup de fichiers de configuration, les commentaires sont
introduits par un dise et stendent jusqu la fin de la ligne.
Par la suite, nous allons prendre le fichier /etc/sendmail.cf des machines de
lENSTA comme exemple.
Le fichier sendmail.cf dbute gnralement par diverses dfinitions, comme
par exemple :
DHensta.ensta.fr

Ceci dfinit (cest ce quindique le D) une variable appele H et dont la valeur est
Cette variable a une signification particulire pour sendmail, elle
indique le nom du serveur de messagerie auquel envoyer tous les messages pour leur
expdition.
Le fichier continue par la dfinition de certaines options :
ensta.ensta.fr.

O EightBitMode=pass8

Au bout dun moment, on arrive aux rgles de rcriture. Sendmail dispose en


effet dun petit langage de programmation lui permettant de modifier (dans ce
cas, on dit rcrire) les adresses lectroniques. Lintrt des rgles de rcriture est
aujourdhui assez limit mais elles taient indispensables lpoque o le courrier
lectronique devait circuler sur des rseaux totalement diffrents, pas seulement sur
lInternet. Les rgles de rcriture servent maintenant principalement aiguiller
le courrier de manire statique (cest--dire sans utiliser les RR MX du DNS),
normaliser les adresses (supprimer les noms de machines en partie gauche pour
ny laisser que le nom de domaine), rejeter les messages provenant dexpditeurs
indsirables, etc.
Les rgles de rcritures sont regroupes en six grands ensembles numrots de
0 5. En effet, chaque ensemble de rgles de rcritures possde un numro (on peut
galement lui attribuer un nom dans les versions rcentes de sendmail). Lensemble
3 est introduit ainsi :
Scanonify=3

Le S en dbut de ligne sert introduire un ensemble de rgles de rcriture. Ici,


lensemble sappelle canonify et porte le numro 3. Si lon navait pas prcis =3,
comme ceci :
48

6.4. sendmail

Scanonify

sendmail aurait choisi un numro densemble non encore attribu.


On aurait galement pu indiquer directement :
S3

Viennent ensuite les rgles proprement dites, une par ligne, introduites par R :
R$-@$+

$1 $2

ceci est un commentaire

En regardant bien, on distingue trois colonnes, spares par des tabulations.


R$-@$+

|$1

$2

|ceci

est un commentaire

La premire colonne est compare la chane de caractres passe en entre de


la rgle. Si elle correspond, on la remplace par la deuxime colonne et on passe la
rgle suivante, sinon on passe directement la rgle suivante.
La chane de caractre passe la rgle est tout dabord dcoupe en morceaux,
aux endroits des @ et des points, qui ont une signification particulire dans les
adresses lectroniques. Puis celle-ci est compare la premire colonne. Dans la
comparaison, $- correspond exactement un lment, $+ un ou plusieurs lments
et $* zro ou plusieurs lments.
Ainsi, ladresse babafou@ensta.fr correspond $-@$+ (babafou correspond
$-, le @ se correspond lui-mme et ensta.fr correspond $+). En revanche,
babafou@ensta.fr ne correspond pas $-@$- puisquensta.fr contient deux lments.
Si la chane de caractre correspond donc la premire colonne, cette chane est
remplace par la deuxime colonne. Dans celle-ci, les $1, $2 et ainsi de suite servent
mmoriser les lments de la chane initiale qui ont correspondu la premire
colonne. Ainsi, dans notre exemple, $1 contiendrait babafou et $2 contiendrait
ensta.fr.
La troisime colonne est un commentaire.
On peut galement faire appel un autre ensemble de rgles de rcriture, un
peu comme on appellerait un sous-programme :
R$-@$+

$>51 $1 $2

ceci est toujours un commentaire

Ici, en cas de correspondance russie, on appelle lensemble 51 en lui passant les


deux parties de ladresse lectroniques spares par un espace.
Nous nirons pas plus loin dans ltude des rgles de rcriture, ceci reprsentant
dj bien trop de maux de tte pour aujourdhui.
49

Chapitre 6. La messagerie
6.4.4.2

Configuration de sendmail avec m4

Comme vous avez pu lentrevoir, les rgles de rcriture sont rserves une
certaine lite capable de comprendre le sendmail dans le texte. Presque plus personne
ne gre son serveur de messagerie en allant farfouiller directement dans le sendmail.
cf. Comme pour tous les fichiers de configuration, on prfre le faire gnrer
automatiquement partir dun fichier plus simple.
Pour cela, sendmail est fourni dorigine avec les bons outils, autant les utiliser.
Le rpertoire cf de la distribution contient dans ses sous-rpertoires divers
fichiers permettant de construire un sendmail.cf au moyen dun fichier matre
grce au prprocesseur m4. Divers exemples de fichiers matres se trouvent dans le
sous-rpertoire cf (donc cf/cf par rapport au sommet de la distribution).
Considrons le fichier sendmail.mc suivant :
include(../m4/cf.m4)
OSTYPE(linux)dnl
define(confSMTP_MAILER, smtp8)dnl
define(confPRIVACY_FLAGS, authwarnings,restrictqrun,restrictmailq,noetrn,noexpn)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
FEATURE(always_add_domain)dnl
FEATURE(allmasquerade)dnl
FEATURE(masquerade_entire_domain)dnl
FEATURE(relay_entire_domain)dnl
define(PROCMAIL_MAILER_PATH, /usr/local/bin/procmail)dnl
FEATURE(local_procmail)dnl
MASQUERADE_AS(ensta.fr)dnl
MASQUERADE_DOMAIN(ensta.fr)dnl
FEATURE(masquerade_envelope)dnl
MAILER(local)dnl
MAILER(smtp)dnl

Il sagit dun fichier permettant de gnrer un sendmail.cf fonctionnel pour une


configuration classique de serveur de messagerie. La gnration se fait en utilisant
m4 :
m4 sendmail.mc > sendmail.cf

Il serait difficile de dtailler ici le contenu de ce fichier, vous en trouverez une


description jour dans le fichier cf/README.

6.4.5

Lancement

Sendmail dispose de trop doptions pour toutes les citer ici. Il se lance gnralement par la squence suivante :
50

Chapitre 6. La messagerie

sendmail -bd -q30m

51

A
Revision Control System (RCS)

CS dsigne un ensemble doutils permettant de conserver lhistorique des mo-

R difications apportes un fichier. En ce sens, il est fort utile afin de suivre les
volutions dun fichier de configuration et de revenir, le cas chant une version
antrieure. RCS permet galement de grer laccs concurrent un fichier, dans le
cas dun travail en quipe.
RCS est fourni avec la plupart des systmes UNIX mais il est possible au besoin
den tlcharger les sources lURL ftp://ftp.gnu.org/pub/gnu/rcs/. La version
courante est la 5.7.

A.1

Principe de fonctionnement

RCS stocke la dernire version dun fichier, ainsi que chacune des modifications
permettant de gnrer les versions prcdentes dans un fichier appel fichier RCS. Le
nom de ce fichier est construit en ajoutant le suffixe ,v (oui, oui, avec une virgule,
pas un point) au nom du fichier grer. Nous utiliserons comme exemple le fichier
toto, dont le fichier RCS correspondant sappelle donc toto,v.
Par dfaut, le fichier RCS est stock dans le mme rpertoire que le fichier
principal. Ceci peut rapidement multiplier le nombre de fichiers dans ce rpertoire
et y noyer les fichiers importants. Cest pourquoi RCS stocke plutt ses fichiers
dans un sous-rpertoire RCS lorsquil existe. Il est donc recommand dutiliser cette
possibilit.

A.2

Premier enregistrement dun fichier

Afin de pouvoir grer un fichier avec RCS, il faut tout dabord crer le fichier
RCS (ce qui suppose que le fichier principal existe dj). Ceci se fait grce la
commande ci (check in) :
53

Annexe A. Revision Control System (RCS)

% ci -u toto
toto,v

<--

toto

enter description, terminated with single . or end of file:


NOTE: This is NOT the log message!
>> exemple RCS
>> .
initial revision: 1.1
done

La cration du fichier RCS saccompagne dun commentaire (qui, dans un cas


rel, sera certainement plus intelligent que celui de lexemple).
Loption -u indique ci quil doit conserver le fichier principal (qui aurait t
effac sans cela). En revanche, tout droit daccs en criture lui est supprim (il
faudra passer par une autre commande pour pouvoir modifier le fichier).

A.3

Modification dun fichier

Avant de pouvoir modifier un fichier, il faut utiliser la commande co (check out)


afin de lui rendre les droits en criture et dempcher toute modification simultane
par quelquun dautre (ce quindique loption -l) :
% co -l toto
toto,v

-->

toto

revision 1.1 (locked)


done

On peut alors modifier le fichier loisir. Toute autre tentative dutiliser co se


soldera par un chec, ce qui vite que plusieurs personnes modifient le mme fichier
au mme moment.
Une fois les modifications termines, on peut les enregistrer dans le fichier RCS
et librer laccs au fichier :
% ci -u toto
toto,v

<--

toto

new revision: 1.2; previous revision: 1.1


enter log message, terminated with single . or end of file:
>> description succinte de la modification
>> .
done

54

Annexe A. Revision Control System (RCS)

A.4

Travail en groupe

Comme la commande co permet dviter laccs simultan de plusieurs personnes au mme fichier, RCS se rvle fort utile lorsquon travaille en quipe sur un
ensemble de fichiers. cet effet, il faut que chacun ait accs en criture au rpertoire
RCS contenant les fichiers RCS. Pour cela, il suffit que les personnes en question
appartiennent au mme groupe UNIX, de mme que le rpertoire RCS.

A.5

Autres commandes RCS

La commande rlog permet dafficher les commentaires associs toutes les


versions dun fichier :

% rlog ethers
RCS file: RCS/ethers,v
Working file: ethers
head: 1.1240
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1240;

selected revisions: 1240

description:
Fichier de correspondance adresse Ethernet <-> nom de machine
---------------------------revision 1.1240
date: 2002/01/31 16:51:23;
> 00:c0:4f:b4:d3:06

author: masson;

state: Exp;

lines: +1 -0

cardamone.pmo.pasteur.fr

---------------------------revision 1.1239
date: 2002/01/31 15:58:36;

author: masson;

< 00:02:55:6b:60:44

odile.sig.pasteur.fr

> 00:02:55:2b:60:44

odile.sig.pasteur.fr

state: Exp;

lines: +1 -1

---------------------------[...]

La commande rcsdiff permet dafficher les diffrences entre deux versions dun
fichier (au mme format que la commande diff) :
55

Annexe A. Revision Control System (RCS)

% rcsdiff -r1.1238 -r1.1240 ethers


===================================================================
RCS file: RCS/ethers,v
retrieving revision 1.1238
retrieving revision 1.1240
diff -r1.1238 -r1.1240
2692a2693
> 00:c0:4f:b4:d3:06

cardamone.pmo.pasteur.fr

2923c2924
< 00:02:55:6b:60:44

odile.sig.pasteur.fr

--> 00:02:55:2b:60:44

odile.sig.pasteur.fr

56

Bibliographie
Rseaux informatiques
[1]

Olivier Bonaventure.
Computer Networking. Principles, Protocols and Practice.
Presses universitaires de Louvain, 2010.
url : http://inl.info.ucl.ac.be/cnp3.

Simple Network Management Protocol (SNMP)


[2]

Douglas Mauro et Kevin Schmidt.


Essential SNMP.
2e dition.
OReilly Media, 2005.
url : http://shop.oreilly.com/product/9780596008406.do.

[3]

Mark E. Miller.
Managing Internetworks with SNMP.
3e dition.
IDG Books Worldwide, 1999.

Les annuaires
[4]

Gerald Carter.
LDAP System Administration.
OReilly Media, 2003.
url : http://shop.oreilly.com/product/9781565924918.do.

[5]

Ralph Droms et Ted Lemon.


The DHCP Handbook.
Macmillan Technical Publishing, 1999.
url : http://www.dhcp-handbook.com/.

57

Bibliographie
[6]

Timothy A. Howes, Mark C. Smith et Gordon S. Good.


Understanding and Deploying LDAP Directory Services.
2e dition.
Addison-Wesley, 2003.
url : http://www.informit.com/store/product.aspx?isbn=9780672323164.

[7]

Cricket Liu et Paul Albitz.


DNS and BIND.
5e dition.
OReilly Media, 2006.
url : http://shop.oreilly.com/product/9780596100575.do.

[8]

Jan-Piet Mens.
Alternative DNS Servers. Choice and deployment, and optional SQL/LDAP
back-ends.
UIT Cambridge Ltd, 2009.
url : http://www.uit.co.uk/BK-ADNS/HomePage.
Ce livre est tlchargeable au format PDF : http://mens.de/:/altdnsbook.

La messagerie
[9]

Bryan Costales, George Jansen, Claus Amann et Gregory Neil Shapiro.


sendmail.
4e dition.
OReilly Media, 2007.
url : http://shop.oreilly.com/product/9780596510299.do.

[10]

Kyle D. Dent.
Postfix : The Definitive Guide.
OReilly Media, 2003.
url : http://shop.oreilly.com/product/9780596002121.do.

[11]

Philip Hazel.
Exim : The Mail Transfer Agent.
OReilly Media, 2001.
url : http://shop.oreilly.com/product/9780596000981.do.

[12]

John Levine.
qmail.
OReilly Media, 2004.
url : http://shop.oreilly.com/product/9781565926288.do.

58

Bibliographie

Revision Control System (RCS)


[13]

Don Bolinger et Tan Bronson.


Applying RCS and SCCS.
OReilly Media, 1995.
url : http://shop.oreilly.com/product/9781565921177.do.

59

Table des matires

Introduction

Les fondements
2.1 Les doigts de pied en ventail . . . . . . . . . . .
2.2 Le matriel . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Mfiance face aux fournisseurs . . . . .
2.2.2 La maintenance . . . . . . . . . . . . . . .
2.2.3 La valorisation des vieux quipements
2.3 Un peu dadministration systme . . . . . . . .
2.4 La scurit est essentielle . . . . . . . . . . . . . .
2.5 Les fichiers de configuration . . . . . . . . . . . .
2.6 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les rseaux virtuels (VLAN)


3.1 Historique . . . . . . . . . .
3.2 Principe . . . . . . . . . . . .
3.3 Le standard IEEE 802.1Q
3.4 En pratique . . . . . . . . . .

Simple Network Management Protocol (SNMP)


4.1 Historique . . . . . . . . . . . . . . . . . . . . . . .
4.2 Scurit . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Principes . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Les agents . . . . . . . . . . . . . . . . . .
4.3.2 Les MIB . . . . . . . . . . . . . . . . . . . .
4.3.3 Les oprations . . . . . . . . . . . . . . . .
4.3.4 Les communauts . . . . . . . . . . . . .
4.4 net-snmp . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Rcupration des sources . . . . . . . . .
4.4.2 Compilation . . . . . . . . . . . . . . . . .
4.4.3 Installation . . . . . . . . . . . . . . . . . .
4.4.4 Configuration . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

61

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

5
5
6
6
6
6
7
7
8
9

.
.
.
.

11
11
11
12
12

.
.
.
.
.
.
.
.
.
.
.
.

15
15
16
16
16
16
18
18
18
19
19
19
19

Table des matires


4.4.5
4.4.6

4.5

Lancement de lagent SNMP . . .


Interrogation dagents SNMP . . .
4.4.6.1 Parcours dune MIB . .
4.4.6.2 Lecture dun objet . . .
4.4.6.3 Modification dun objet
MRTG . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Rcupration des sources . . . . . .
4.5.2 Compilation . . . . . . . . . . . . . .
4.5.3 Installation . . . . . . . . . . . . . . .
4.5.4 Configuration . . . . . . . . . . . . .
4.5.5 Lancement . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

20
20
20
21
21
21
21
22
22
22
23

Les annuaires
5.1 Domain Name System (DNS) . . . . . . . . . . . .
5.1.1 Un peu dhistoire . . . . . . . . . . . . . . . .
5.1.2 Principes de fonctionnement . . . . . . . .
5.1.2.1 Le systme de nommage . . . .
5.1.2.2 Les serveurs . . . . . . . . . . . . .
5.1.2.3 La rsolution de nom . . . . . .
5.1.3 Interrogation du DNS avec dig . . . . . .
5.1.4 BIND . . . . . . . . . . . . . . . . . . . . . . .
5.1.4.1 Rcupration des sources . . . .
5.1.4.2 Compilation . . . . . . . . . . . .
5.1.4.3 Installation . . . . . . . . . . . . .
5.1.4.4 Configuration . . . . . . . . . . .
5.1.4.5 Lancement . . . . . . . . . . . . .
5.1.5 Quelques liens . . . . . . . . . . . . . . . . .
5.1.6 Quelques bizarreries . . . . . . . . . . . . .
5.2 Lightweight Directory Access Protocol (LDAP) .
5.2.1 Principes . . . . . . . . . . . . . . . . . . . . .
5.2.2 OpenLDAP . . . . . . . . . . . . . . . . . . .
5.2.2.1 Rcupration des sources . . . .
5.2.2.2 Compilation . . . . . . . . . . . .
5.2.2.3 Installation . . . . . . . . . . . . .
5.2.2.4 Configuration . . . . . . . . . . .
5.2.2.5 Tests . . . . . . . . . . . . . . . . .
5.2.2.6 Cas pratique . . . . . . . . . . . .
5.3 Autres annuaires . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

25
25
25
26
26
27
27
28
31
31
32
32
32
37
38
38
38
38
41
41
41
41
42
42
42
42

La messagerie
6.1 SMTP . . . . . . . . . . .
6.2 Relation avec le DNS .
6.3 Serveurs de messagerie
6.4 sendmail . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

43
43
46
46
47

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

62

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

Table des matires


6.4.1
6.4.2
6.4.3
6.4.4
6.4.5

Rcupration des sources . . . . . . . . . . . . .


Compilation . . . . . . . . . . . . . . . . . . . . .
Installation . . . . . . . . . . . . . . . . . . . . . .
Configuration . . . . . . . . . . . . . . . . . . . .
6.4.4.1 Le fichier sendmail.cf . . . . . . . .
6.4.4.2 Configuration de sendmail avec m4
Lancement . . . . . . . . . . . . . . . . . . . . . .

A Revision Control System (RCS)


A.1 Principe de fonctionnement . . . . . .
A.2 Premier enregistrement dun fichier .
A.3 Modification dun fichier . . . . . . . .
A.4 Travail en groupe . . . . . . . . . . . . .
A.5 Autres commandes RCS . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

Bibliographie
Rseaux informatiques . . . . . . . . . . . . . . . . .
Simple Network Management Protocol (SNMP)
Les annuaires . . . . . . . . . . . . . . . . . . . . . . .
La messagerie . . . . . . . . . . . . . . . . . . . . . . .
Revision Control System (RCS) . . . . . . . . . . .
Table des matires

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

47
47
47
47
48
50
50

.
.
.
.
.

53
53
53
54
55
55

.
.
.
.
.

57
57
57
57
58
59
61

63

Vous aimerez peut-être aussi