Embed Size (px)
Citation preview
ADMINISTRATION DES SERVICES RESEAUX PARTIE 2 : DHCP, DNS, NIS, LDAP, AD
2012
Noureddine GRASSA
Chapitre 1 Démarrage ................................................................................... 4 I-Introduction ...................................................................................................................... 4
II- Obtention d’une adresse ............................................................................................. 4
III- Obtention d’un nom de domaine .............................................................................. 5
IV- Choix d’un nom de machine ..................................................................................... 5
V- Planning du routage ..................................................................................................... 6
VI- Définition d’un masque de sous-réseaux ................................................................. 6
VII- Specification de l’adresse de diffusion ................................................................... 7
VIII- Feuilles de planning ................................................................................................ 7
Chapitre 2 Configuration de I’ interface ..................................................... 8 I-Introduction ...................................................................................................................... 8
II-La commande ifconfig .................................................................................................... 8
III-Vérification de l’interface avec ifconfig ................................................................... 10
IV-Autres options de ifconfig .......................................................................................... 11
V-TCP/IP sur une ligne série .......................................................................................... 12
V-1-. Les protocoles séries........................................................................................... 12
V-2- choix d’un protocole série .................................................................................. 13
Chapitre 3 Configuration du routage ..................................................... 14 I-Introduction .................................................................................................................... 14
II-Les différentes configurations de routage ................................................................. 14
III- La table de routage minimale .................................................................................. 14
IV-Construction d’une table de routage statique ......................................................... 16
V-Les différents protocoles de routage .......................................................................... 18
V-1-Protocole de routage intérieur ............................................................................. 18
V-2-Protocole de routage extérieur ............................................................................. 18
V-4-Choix d’un protocole de routage ......................................................................... 19
Chapitre 4 Configuration du DNS.............................................................. 20 I-Introduction .................................................................................................................... 20
II-BIND .............................................................................................................................. 20
III-Configuration du resolver .......................................................................................... 21
III-1-Configuration par défaut .................................................................................... 21
III-2-Fichier de configuration resolv.conf ................................................................... 22
IV-Configuration de named ............................................................................................. 22
IV-1-Le fichier named.boot ........................................................................................... 22
IV-2-Le fichier d’initialisation cache root.cache ........................................................ 24
IV-3-Le fichier named.local .......................................................................................... 24
IV-4-Le fichier de domaine renversé named.rev ........................................................ 25
IV-5-Le fichier named.host ........................................................................................... 26
V-Utilisation de nslookup ................................................................................................. 27
Chapitre 5 Applications ............................................................................... 29 I-Introduction .................................................................................................................... 29
II- La famille des commandes ‘r’ ..................................................................................... 30
II-1- Le fichier IetcIhosts.equiv .................................................................................... 31
II-2- Les fichiers .rhosts ................................................................................................ 31
III-Applications de base : ................................................................................................. 32
III-1-telnet, ftp ............................................................................................................... 32
III-2-Le mail : courrier électronique ........................................................................... 35
III-2-a-Sendmail le demon SMTP ................................................................................ 36
III-2-b-Sendmail le pourvoyeur d’alias ....................................................................... 36
III-2-c-Sendmail le centre de tri ................................................................................... 37
III-2-d-Au rayon farces et attrapes : sendmail ........................................................... 38
III-3-NIS : Network Information Service ................................................................... 39
III-3-a-Mise en place de NIS ........................................................................................ 40
III-3-b-Le fichier /etc/netgroup .................................................................................... 40
III-4-NFS: Network File System .................................................................................. 41
III-4-a-Les demons NFS : mise en place d’NFS ......................................................... 42
III-4-b-Coté serveur ... .................................................................................................. 42
III-4-c-Coté client ... ...................................................................................................... 43
III-5-Mise en place d’un serveur FTP anonyme ........................................................ 44
Chapitre 1 Démarrage
I-Introduction :
Avant d’entreprendre la configuration d’une machine on doit avoir certaines informations.
Au minimum chaque machine doit avoir une adresse IP unique ainsi qu’un nom. On doit aussi
avoir fait son sur certaines options avant de procéder a la configuration.
• default gateway address : si le système communique avec des machines qui ne sont
pas sur
le réseau local, une adresse de passerelle par défaut est
nécessaire.
• routing protocol : chaque machine doit connaitre le protocole de routage utilisé sur le
réseau.
• name server address : pour convertir les noms de machines en adresse IP, chaque
machine doit connaItre les adresses des serveurs DNS.
• domain name : une machine utilisant le service DNS doit connaître
correctement son nom de domaine.
• subnet mask : pour que la communication soit propre, chaque machine d’un réseau
doit utiliser le même masque de sous-réseau.
• broadcast address : pour éviter les problèmes de diffusion, les adresses de diffusion de
chaque machine sur un réseau doivent être identiques.
II- Obtention d’une adresse
Chaque interface doit avoir une adresse IP unique sur un réseau TCP/IP. Si la machine est sur
un réseau connecté a Internet, son adresse doit être unique (sur tout le réseau Internet). Pour un
réseau non connecté, cette adresse doit être unique a l’échelle du réseau local. A cause de cela
les administrateurs de réseaux non connectés a Internet choisissent souvent des adresses sans
consulter le NIC (Network Information Center). Cependant, cela n’est pas recommandé. Si à
l’avenir le réseau local a besoin de se connecter à Internet, l’administrateur n’aura pas besoin
dans ce cas de changer toutes les adresses et de reconfigurer chaque machine du réseau.
Une demande d’adresse réseau peut se faire de deux manières :
• soit par courrier postal : envoyez votre demande au NIC a l’adresse suivante :
DDN Network Information Center
14200 Park Meadow Drive
Suite 200
Chantilly, VA 22021
• soit par e-mail : adressez votre mail à [email protected]
Le NIC vous attribuera un numéro de réseau gratuitement. Supposons par exemple que l’on
vous a attribué le numéro 128.66. L’administrateur peut alors utiliser librement les deux
derniers octets pour adresser ses machines a l’exception de deux adresses réservées (tous les
bits a 0 et tous les bits a 1).
III- Obtention d’un nom de domaine
Un nom de domaine est obtenu comme pour l’adresse IP après avoir fait une demande auprès
du NIC. Les demandes sont a envoyer aux mêmes adresses que celles du paragraphe
précédent. Même si le réseau n’est pas connecté a Internet, il est quand même conseillé de faire
appel au NIC. Il y a deux raisons a cela. La première est celle donnée au paragraphe précédent :
on ne connaît pas l’avenir et on voudra peut étre un jour connecter le réseau a Internet. La
deuxième est plus immédiate : de nombreux réseaux non connectés a Internet ont des
passerelles e-mail jusqu’a Internet et quelques uns de ces réseaux permettent a des machines
sur Internet de vous adresser du mail avec un nom de domaine du style Internet. Ainsi
UUNET et Bitnet offrent ce service.
Quand on demande un nom de domaine Internet, on devrait aussi demander un domaine in-
addr.arpa. C’est ce qu’on appelle le domaine renversé. Ce domaine convertit les adresses IP en
nom. C’est le processus normal de conversion à l’ envers ! Supposons que votre réseau est
128.66. Son nom de domaine renversé est 66.128.in-addr.arpa.
IV- Choix d’un nom de machine
Une fois le nom de domaine obtenu, l’administrateur est libre de choisir le nom de la machine
à l’intérieur de ce domaine. Il faut s’assurer que le nom de la machine est unique a travers le
domaine ou sous-domaine, de la même manière que l’adresse IP est unique a travers le
réseau ou sous-réseau.
Le choix d’un nom de machine peut s’avérer délicat. Voici quelques suggestions pour
choisir :
• utiliser des noms courts, facile a épeler et a mémoriser.
• utiliser des noms de thème, de personnages connus...
• éviter d’utiliser des noms personnels, de projets ou venant du jargon technique.
V- Planning du routage
Si des machines d’un réseau communiquent avec des machines d’un autre réseau, on a besoin
de passerelles entre ces réseaux. Une route a travers des passerelles doit alors être définie. Il
y a deux manières de le réaliser :
• table de routage statique : elle est construite par l’administrateur système. Leurs
mises a jour sont faites manuellement. Elles sont utilisées quand le nombre de
passerelles est limité.
• table de routage dynamique : elle est construite par les protocoles de routage. Les
protocoles échangent des informations qu’ils utilisent pour la mise à jour des tables.
Elles sont utilisées quand il y a beaucoup de passerelles sur le réseau ou quand on peut
atteindre la même destination en empruntant plusieurs chemins.
En général, les réseaux utilisent les deux types de table simultanément : les tables de routages
statiques sont plus appropriées pour les machines tandis que les passerelles font appels aux
protocoles de routage et aux tables de routages dynamiques.
L’administrateur réseau décide du type de routage utilisé ainsi que du choix de la passerelle
par défaut de chaque machine.
Les protocoles de routages EGP et BGP demandent que les passerelles aient un «autonomous
système number». Si votre réseau est connecté a un autre réseau qui utilise EGP ou BGP, il faut
alors faire la demande de ces numéros auprès du NIC.
VI- Définition d’un masque de sous-réseaux
Les raisons pour lesquelles on divise un réseau en sous-réseau sont d’ordre topologique ou
d’ordre organisationnel.
Les raisons d’ordre topologiques sont :
• limitation en distance : un réseau local sur Ethernet épais est limité en
distance a un tronçon de 500m. On peut relier les
câbles grâce a des routeurs IP pour augmenter la
distance. A chaque câble est associe un sous-
réseau.
• connexions de réseaux de supports différents : cela consiste par exemple,
a relier de l’Ethernet avec du Token Ring en
utilisant un routeur IP. On définir alors deux sous-
réseaux.
• filtrage du trafic : les trames ne sortent du sous-réseau local que
si elles sont destinées a un autre sous-réseau. Ce
dernier n’est donc pas encombré par des trames qui
ne lui sont pas destinées. Ce filtrage est réalisé
dans les passerelles entre sous-réseaux.
Les raisons d’ordre organisationnel sont :
• simplification de l’administration du réseau : on délègue le travail
d’administration au niveau de chaque sous-réseau.
• isolation du trafic : pour des problèmes de sécurité, un département peut
souhaiter que ses trames ne circulent pas sur tout
le réseau. La subdivision du réseau en sous-
réseaux apporte un début de solution.
VII- Specification de l’adresse de diffusion
C’est une adresse ou tous les bits de la partie adresse de la machine sont mis a 1. L’adresse de
diffusion sur le réseau 192.33.174.0 est par exemple 192.33.174.255. L’adresse de diffusion
est mise en place en utilisant la commande ifconfi.
VIII- Feuilles de planning
Apres avoir regroupé les différentes informations nécessaires au réseau, l’administrateur
réseau distribue à chaque administrateur système de chaque machine les informations dont il
dispose. L’administrateur système des terminaux X connectés à ensisun recevra par exemple
la feuille suivante pour chaque terminal :
Hostname : txsunO1
IP adress : 192.33.174.7O
Subnet mask : FF.FF.FF.EO
Default gateway : 192.33.174.65 (ensisun)
Broadcast address : 192.33.174.95
Domain Name : imag.fr
Primary Name Server : 192.33.74.34
Secondary Name Server : O.O.O.O Routing Protocol :
Chapitre 2 Configuration de I’ interface
I-Introduction
Une des forces du protocole TCP/IP est d’être indépendant du support physique. Cet avantage
augmente en fait la charge de travail de l’administrateur car il doit alors indiquer au protocole
TCP/IP quelles interfaces il utiliser et pour chaque interface, il doit donner ses
caractéristiques. Contrairement aux adresses Ethernet qui sont implémentées en hard,
l’administrateur système attribue p chaque interface réseau une adresse IP, un masque de sous
réseau et une adresse de diffusion.
II-La commande ifconfig
Cette commande permet d’installer ou de vérifier les attributs associés à chaque interface.
L’exemple suivant est celui de la configuration de l’interface leO de ensisun et de sa
vérification ensuite :
% ifconfig leO 192.33.174.34 netmask ffffffeO broadcast 192.33.174.63
% ifconfig leO
leO: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> inet 192.33.174.34 netmask ffffffeO broadcast 192.33.174.63
oi :
• leO est le nom de l’interface d’ensisun que l’on configure.
• 192.33.174.34 est l’adresse IP de cette interface.
• ffffffeO est le masque de sous réseau. On utilise un masque car le réseau net-
ensimagO1
d’adresse 192.33.174 est divisé en sous-réseaux. La subdivision est faite sur 3 bits
(eO).
• 192.33.174.63 est l’adresse de diffusion, i.e tous les bits de la partie adresse de la machine
sont a 1.
L’administrateur réseau fournit les valeurs des adresses, du masque de sous-réseau et l’adresse
de diffusion. Ces valeurs sont directement tirées de la feuille de planning. Par contre, le nom
de l’interface, qui est le premier argument de chaque ligne de commande ifconfi, est tiré de la
documentation système.
Il existe une commande, netstat, dont une des fonctions est d’indiquer quelles sont les
interfaces disponibles sur le système. La commande netstat -ain fournit en sortie les champs
suivant pour chaque interface :
• Name : Nom de l’interface. * indique que l’interface n’est pas disponible, i.e que
l’interface n’est pas «UP».
• Mtu : Maximum Transmission Unit montre la plus grande longueur de trame
transmise par l’interface sans qu’il y ait de fragmentation.
• Net/Dest : Indique le réseau ou la machine auxquels l’interface a accès.
• Address : adresse IP de l’interface
• Ipkts : Input Packets indique le nombre de trames reçues par l’interface.
• Ierrs : Input Errors indique le nombre de trames avec erreurs reçues par l’interface.
• Opkts : Output Packets indique le nombre de trames émises par l’interface.
• Oerrs : Output Errors indique le nombre de trames avec erreurs émises par l’interface.
• Coffis : Collisions indique le nombre de collisions détectées par l’interface.
• Queue : Indique le nombre de trames en file d’attente d’émission de l’interface
Le résultat de la commande netstat -amn sur la machine ensisun est le suivant :
%netstat -ain
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis
Queue le0 1500 192.33.174.32 192.33.174.34 1242702 1 985946 0
10284 0 le1* 1500 none none 0 0 0 0 0 0
ne0 1500 192.33.174.64 192.33.174.65 1009315 131 985120 0 419
0 lo0 1536 127.0.0.0 127.0.0.1 178672 0 178672 0 0 0
oi : • L’interface loO est l’interface de «loopback», que tous les systèmes possèdent.
• L’interface leO est configurée pour Ethernet
• Pour information, l’interface stdO (DDN Standard X25), que l’on ne trouve pas ici,
est configurée pour Milnet.
III-Vérification de l’interface avec ifconfig
Un script d’installation UNIX permet de configurer le réseau à la place de l’administrateur.
Cependant, cette configuration peut ne pas convenir. On peut vérifier les caractéristiques
d’une interface grâce a mfconfi.
% ifconfig lo0
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000
% ifconfig le0
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 192.33.174.34 netmask ffffffe0 broadcast 192.33.174.63
% ifconfig ne0
ne0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 192.33.174.65 netmask ffffffe0 broadcast 192.33.174.95
oi,
La première ligne indique le nom et les flags qui caractérisent l’interface. Les flags
sont décrits par un nombre dont les bits sont traduits en un ensemble de noms.
Ainsi 63 correspond a :
• UP : l’interface est disponible.
• BROADCAST : l’interface traite le diffusion, i.e elle est connectée a un
réseau qui traite la diffusion comme Ethernet.
• NOTRAILERS : l’interface ne traite pas l’encapsulation.
• RUNNING : l’interface est utilisée
La seconde ligne affichant des informations attachées a TCP/IP, i.e adresse IP,
masque de sous- réseau et adresse de diffusion.
La commande ifconfig est normalement exécutée au moment du boot par un fichier de
startup. Sur les systèmes BSD UNIX, les commandes ifconfig sont normalement placées
dans les fichiers /etc/ rc.boot et /etc/rc.local. Le script de IetcIrc.boot est exécuté à la
procédure de startup alors que le rc.local est exécuté a la fin. Editez le fichier /etc/rc.boot
pour lire les lignes suivantes :
ifconfig leO 192.33.174.34 netmask 255.255.255.224 broadcast 192.33.174.63 -
trailers up
ifconfig neO 192.33.174.65 netmask 255.255.255.224 broadcast 192.33.174.95 -
trailers up
ifconfig loO 127.O.O.1 up
IV-Autres options de ifconfig
On a utilisé ifconfig pour installer l’adresse IP de l’interface, son masque de sous-réseau et
son adresse de diffusion. Ce sont certainement les fonctions les plus importantes de ifconfig
mais il existe d’autres fonctions aussi qui sont :
• activer et desactiver l’interface :
up active l’interface et down la désactive. Pour reconfigurer une interface, il faut
d’abord la désactiver. Par exemple, pour changer l’adresse IP de le0 :
• ARP et trailer1 :
L’option trailer autorise l’encapsulation des datagrammes IP, -trailer l’inhibe. La
plupart des systèmes autorisent l’encapsulation par défaut.
L’option arp autorise le protocole ARP (Address Resolution Protocol), -arp
l’inhibe. Ce protocole traduit les adresses IP en adresses Ethernet. A de rares
exceptions près, ce protocole est toujours autorisé.
• Metric :
le protocole de routage RIP (Routing Information Protocol) choisit une route en
fonction de son coGt. Ce coGt est déterminé par une mesure associe a la route. Plus
ce nombre est petit, plus le coGt est faible. Quand il construit sa table de routage,
RIP privilégie les routes de faibles coGts. Par défaut, la mesure d’une route entre
une interface et un réseau qui lui est directement attaché est 0. Pour augmenter par
exemple le coGt d’une interface a 3, afin que RIP privilégie les routes de valeur
0,1 ou 2 on écrit :
On utilise cette option seulement s’il existe une autre route qui conduit à la même
% ifconfig leO down
% ifconfig leO 192.33.174.5O up
% ifconfig leO 192.33.174.34 metric 3
destination et qu’on désire l’utiliser comme route principale.
V-TCP/IP sur une ligne série
TCP/IP traite une grande variété de réseaux physiques. Le support physique peut être du câble
Ethernet comme dans notre réseau local, des fibres optiques (dans notre cas seulement
entre les bâtiments) ou bien des lignes téléphoniques comme dans les WAN. Presque toutes
les communications se font via des interfaces séries. Une interface série envoie les données
en un flot de bits sur un simple câble. Ce type d’interface correspond a presque toutes les
interfaces de communications. Y compris Ethernet, mais on emploie habituellement ce terme
pour une interface connectée au réseau téléphonique via un modem. Une ligne téléphonique
est souvent appelée une ligne série.
V-1-. Les protocoles séries
Le premier protocole réseau sur ligne série a avoir été crée est le SLIP (Serial Line IP). Ce
protocole permet aux machines isolées de se connecter au réseau téléphonique, via TCP/IP.
SLIP envoie les datagram a travers une ligne série comme une série d’octets et utilise des
caractères spéciaux pour indiquer quand une série d’octets doit être regroupée pour former
un datagram.
SLIP définit deux caractères spéciaux :
• le caractère END : marque la fin d’un datagram. Quand SLIP reçoit un
caractère END, il sait qu’un datagram complet peut être envoyé a IP.
• le caractère ESC : permet de différencier les caractères de contrôle. Mais SLIP
a quelques inconvénients :
• SLIP n’est pas un standard Internet.
• SLIP ne définit pas d’information de contrôle qui pourraient contrôler
dynamiquement les caractéristiques de la connexion. Par conséquent, SLIP doit
supposer certaines caractéristiques. Donc, a cause de cette limitation, SLIP est
seulement utilise quand les deux machines connaissent mutuellement leurs
adresses.
• SLIP ne corrige pas les effets du bruit des lignes téléphone. Le protocole ne fait
pas de correction d’erreurs ni de compression de données.
Pour beaucoup d’applications sur des machines isolées, ces problèmes ne sont pas importants.
Cependant dans un environnement dynamique comme celui des WAN, ces problèmes rendent
le protocole inadéquat pour connecter les routeurs.
Pour répondre a cette faiblesse, PPP (Point to Point Protocole) a été développé comme un
standard Internet. C’est un protocole a trois couches :
• Data Link layer Protocol : assure un envoi fiable des données sur n’importe
quel type de ligne série.
• Link Control Protocol : fournit les informations de contrôle sur la ligne série.
Cette couche est utilisée pour établir la connexion, négocier les paramètres de
configuration, vérifier la qualité de liaison et clore la connexion.
• Network Control Protocol : Cette couche fournit les informations de
configuration et de contrôle nécessaires a LCP. PPP est destine a faire transiter
les données pour une grande variété de protocoles réseau. Cette couche permet
a PPP de faire cela.
Par conséquent, PPP est plus robuste que SLIP mais il est aussi plus difficile à implémenter
et n’est pas disponible aussi facilement que SLIP. Cependant, ses avantages en font le
protocole de ligne série du futur.
V-2- choix d’un protocole série
Le choix ne doit pas porter sur le meilleur protocole dans l’absolu mais plutôt sur le protocole
le plus adapte à une situation spécifique. Si vous avez un réseau étendu, vous utiliserez plutôt
PPP.
PPP est préfère car c’est un standard Internet. Il offre donc plus de compatibilité entre les
systèmes. PPP est aussi plus robuste que SLIP. Ces caractéristiques en font un bon protocole
pour la connexion de routeurs sur une ligne série. Cependant, comme SLIP a été le premier
protocole série pour IP largement diffusé, et comme il est simple à implémenter, SLIP est
disponible sur plus de matériels que PPP.
SLIP et PPP sont deux protocoles complètement différents et par conséquent incompatibles. Si
votre serveur a seulement SLIP, la machine distante ou vous vous connectez doit aussi avoir
SLIP. A cause de son installation plus ancienne, SLIP continuera à être largement utilisé dans
le futur.
Donc, quel protocole utiliser ? Les deux ! PPP est le protocole du futur. Cependant il faut
continuer à utiliser SLIP car c’est souvent le seul protocole série utilisable sur certains types
de matériels.
Utilisez PPP quand vous le pouvez et SLIP quand vous le devez !
Chapitre 3 Configuration du routage
I-Introduction
Internet repose sur le principe du routage. Sans le routage, le trafic serait limité à un seul
câble physique. Le routage permet à votre machine d’atteindre une autre machine qui n’est
pas sur le même réseau local que le votre. La communication peut très bien traverser une
succession de réseaux intermédiaires afin de s’établir entre les deux machines.
En tant qu’administrateur système, on doit s’assurer que le routage du système est bien
configuré. C’est le propos de ce chapitre.
II-Les différentes configurations de routage
Les trois configurations de routage les plus courantes sont :
• routage minimal : s’applique aux réseaux complètement isolés des autres
réseaux. Une table de routage minimale est construite par ifconfig une fois
l’interface réseau configurée. Si votre réseau n’a pas d’accès a d’autres réseaux
TCP/IP et si vous n’utilisez pas de sous-réseaux, il se peut que ce soit la seule
table utilisée.
• routage statique : un réseau avec un nombre limité de passerelles peut se
configurer avec un routage statique. Une table de routage statique est construite
manuellement par l’administrateur système qui utilise la commande route. Ces
tables sont à utiliser seulement quand les routes ne sont pas modifiées, vu
qu’elles ne s’auto-adaptent pas aux changements de réseaux. Quand une
machine éloignée ne peut être atteinte qu’avec une seule route, le routage statique
est la meilleure solution.
• routage dynamique : un réseau ou une même destination peut être atteinte par
plusieurs routes devrait utiliser le routage dynamique. Une table de routage est
construite a partir des informations échangées par les protocoles de routage. Ces
protocoles de routage ont pour but de mettre à jour les tables de routage et de
choisir quelle est la meilleure route vers une destination.
Les routes sont construites à coup d’ifconfig, dans un script écrit par
l’administrateur ou, dynamiquement par les protocoles de routage.
III- La table de routage minimale
Une fois la configuration de l’interface réalisée, la commande netstat -nr permet de connaItre
la table de routage construite par ifconfig, .Imaginons ensisun sur un réseau local coupé du
monde.
% netstat -nr
Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 5 2017 lo0 192.33.174.64 192.33.174.65 U 52 1273321 ne0 192.33.174.32 192.33.174.34 U 133 887308 le0
La signification des Flags est la suivante :
• U indique l’état de la route ( U si up)
• G indique si la route se dirige vers une passerelle (G si gateway). Dans le cas
d’une table de routage minimale, le flag G n’apparait pas car toutes les routes
sont directes à travers les interfaces locales, sans utiliser de passerelles
extérieures.
• H indique que la route se dirige vers une machine (H si host). L’adresse
destination est une adresse de machine et non pas une adresse de réseau.
L’adresse de loopback est 127.0.0.0. L’adresse destination (127.0.0.1) est
l’adresse de la machine locale. Cette route particulière se retrouve dans chaque
table de routage.
La plupart des routes sont des routes vers des réseaux et non pas des routes vers des machines.
C’est pour réduire la taille des tables. En effet une organisation peut avoir un seul réseau mais
des centaines de machines sur ce réseau. Une table de routage avec une route pour chaque
machine aurait une taille énorme et est donc inconcevable.
La colonne refcnt donne le nombre courant d’utilisateurs actifs par route. Les protocoles en
mode connecté comptent pour une seule route durant la connexion alors que les protocoles en
mode déconnecté obtiennent chaque fois une route pour les données envoyées vers la même
destination.
La colonne use indique le nombre de paquets envoyés par route. La colonne interface
indique l’interface utilisée pour la route.
Pour vérifier la table de routage d’ensisun et ainsi le bon fonctionnement du routage, on peut
faire un ping sur la machine ensibm ou ensibull.
% ping -s ensibm
PING ensibm: 56 data bytes
64 bytes from ensibm (192.33.174.36): icmp_seq=0. time=3. ms
64 bytes from ensibm (192.33.174.36): icmp_seq=1. time=4. ms
64 bytes from ensibm (192.33.174.36): icmp_seq=2. time=4. ms
64 bytes from ensibm (192.33.174.36): icmp_seq=3. time=6. ms
^C
----ensibm PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms)
min/avg/max = 3/4/6
% ping -s ensibull
PING ensibull: 56 data bytes
64 bytes from ensibull (192.33.174.35): icmp_seq=0. time=4. ms
64 bytes from ensibull (192.33.174.35): icmp_seq=1. time=15. ms
64 bytes from ensibull (192.33.174.35): icmp_seq=2. time=81. ms
^C
----ensibull PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms)
min/avg/max = 4/33/81
ping utilise le protocole ICMP pour forcer la machine destinatrice a renvoyer un écho vers la
machine locale. Si les paquets circulent entre les deux machines, cela veut dire que le
routage est bon.
Si on fait un ping sur une machine qui n’est pas sur le réseau local, les résultats sont
différents.
% ping 26.40.0.17
sendto: Network is unreachable Ici, le message «sendto: Network is unreachable» montre que ensisun avec sa table de
routage minimale ne sait pas envoyer des données au réseau ou se trouve la machine
26.40.0.17.
Ce test montre que la table de routage crée par ifconfig permet seulement la communication
sur des machines sur le réseau local.
IV-Construction d’une table de routage statique
Comme nous l’avons vu, la table de routage minimale ne marche qu’avec les machines
directement connectées sur le réseau local. Grace a la commande route, on rajoute des routes à
travers des passerelles externes jusqu’à des machines distantes.
% route -n add 152.77.0.0 192.33.174.62
1 add net 152.77.0.0: gateway
192.33.174.62
• Le premier argument après route est soit add pour rajouter, soit del pour effacer
une route.
• L’argument suivant 152.77.0.0 est l’adresse destination qui est l’adresse atteinte par
cette route. Si le mot-clé default est utilisé, route crée une route par défaut. La route
par défaut est utilisée quand il n’y a pas de routes spécifiques a une destination
donnée.
• L’argument suivant est l’adresse de la passerelle. Cette adresse doit être celle d’une
passerelle directement connectée au réseau.
• Le dernier argument est la mesure de routage ( routing metric). Route utilise cette
mesure pour décider s’il s’agit d’une route a travers une interface locale ou bien à
travers une passerelle externe. Si cette mesure vaut 0, la route est supposée passer par
une interface locale et le flag G n’est pas mis en place. Si c’est supérieur a 0, le flag G
est mis en place car la route est supposée passer par une passerelle externe.
La table de routage statique d’ensisun après avoir ajouter différentes routes est la suivante :
% netstat -nr
Routing tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 5 2017 lo0 192.33.174.160 192.33.174.33 UG 0 0 le0 192.33.174.128 192.33.174.33 UG 21 13874 le0 129.88.0.0 192.33.174.62 UG 17 438296 le0 default 192.33.174.62 UG 0 161657 le0 192.33.174.96 192.33.174.35 UG 4 3509 le0 192.33.174.64 192.33.174.65 U 52 1273321 ne0 192.33.174.32 192.33.174.34 U 133 887308 le0 152.77.0.0 192.33.174.62 UG 0 0 le0 192.33.175.0 192.33.174.36 UG 0 28450 le0
Pour comprendre les différentes destinations de la table de routage, il suffit de se reporter au
fichier /etc/networks :
129.88.0.0 est le réseau net-imag
192.33.175.0 est le réseau net-ensimag23
Les autres réseaux 192.33.174.xxx sont les sous-réseaux du réseau net-ensimag01. Ce sont les
réseaux : net-ensipc, net-ensuntx, net-ensibmtx, net-ensibultx,... Rapellons que ensisun est
directement connecté sur net-ensuntx (192.33.174.64) et sur net_ensimag (192.33.174.32)
V-Les différents protocoles de routage
Tous les protocoles de routage assurent les mêmes fonctions de base : ils déterminent la
meilleure route pour chaque destination et échangent les informations de routages entre les
différents systèmes du réseau. Par contre, leur manière de procéder est différente.
V-1-Protocole de routage intérieur
Un protocole intérieur est utilisé sur un réseau indépendant. Ces réseaux indépendants sont
aussi appelés système autonome en terminologie TCP/IP. Au sein d’un système autonome,
l’information de routage est échangée en utilisant un protocole intérieur.
Routing Information Protocole (RIP) est le plus utilisé des protocoles intérieurs car il est
inclus dans UNIX. RIP sélectionne la route dont la longueur est la plus faible comme étant la
meilleure route. La longueur d’une route pour RIP est le nombre de passerelles que les
données doivent franchir pour atteindre leur destination. RIP suppose que la meilleure route
est celle qui utilise le moins de passerelles.
La plus grande longueur pour RIP est de 15. Au dessus de 15, RIP suppose que la
destination n’est pas joignable. En supposant que la meilleure route est la plus courte, RIP ne
prend donc pas en compte les problèmes de congestion.
Inclus dans UNIX, RIP tourne grace au routing daemon, routed. Le routing daemon
construit les tables de routages avec les informations de mise à jour RIP. Les systèmes
configurés pour traiter RIP échangent périodiquement ou sur demande ces informations de
mise à jour.
D’autres protocoles ont été développés pour pallier à cette limitation de congestion.
Hello est un protocole qui utilise le délai pour décider de la meilleure route. Le délai est le
temps que met un paquet pour aller de la source à la destination et revenir ensuite a la source.
Hello n’est pas largement utilisé. On le trouve peu en dehors de NSFNET.
V-2-Protocole de routage extérieur
Les protocoles de routage extérieur sont utilisés pour échanger des informations entre
système autonomes. Les informations de routage qui passent entre des systèmes autonomes
sont appelées reachability information. Ces informations indiquent quels réseaux peuvent
être atteints à travers un système autonome spécifique.
Exterior Gateway Protocol (EGP) est le plus utilisé des protocoles extérieurs. Une
passerelle qui utilise EGP annonce qu’elle peut atteindre les réseaux qui font partie de son
système autonome.
Contrairement aux protocoles intérieurs, EGP n’essaie pas de choisir la meilleure route. EGP
met a jour les informations de distance mais n’évalue pas ces informations. Ces informations
de distance ne sont pas directement comparables parce que chaque système autonome utilise
des critères différents pour évaluer ces valeurs.
Une structure de routage qui dépend d’un groupe de passerelles centralisées ne peut pas
convenir à un accroissement rapide d’Internet. C’est une des raisons pour lesquelles Internet
tend vers une architecture distribuée ou un processus de routage tourne sur chaque système
autonome.
Un autre protocole, Border Gateway Protocole (BGP) commence à remplacer EGP.
Comme EGP, BGP échangent des informations entre systèmes autonomes mais BGP peut
fournir plus d’informations pour chaque route et peut utiliser ces informations pour
sélectionner la meilleure route.
Une remarque importante à se rappeler est que la plupart des systèmes ne font pas tourner de
protocoles extérieurs. Ces protocoles ne sont utiles que pour des systèmes autonomes qui
échangent des informations avec d’autres systèmes autonomes. La plupart des machines
appartenant à un système autonome font tourner RIP. Seules les passerelles reliant deux
systèmes autonomes font tourner un protocole extérieur.
EGP tourne soit comme processus séparé (egpup), soit comme partie du Gateway Routing
Daemon (gated). Il est préférable d’utiliser gated. On utilise encore egpup car il est encore
utilisé sur certains sites. gated est un seul logiciel qui combine a la fois RIP, Hello, BGP et
EGP. Les avantages de gated sont :
• sur les systèmes qui utilisent plus d’un protocole de routage, gated combine les
informations des différents protocoles et en tire la meilleure route.
• les routes apprises d’un protocole intérieur peuvent étre annoncées via un
protocole extérieur. Les informations entre systèmes autonomes s’adaptent aux
changements de routes intérieures.
• gated simplifie la configuration. Tout tient dans un seul fichier : /etc/gated.conf.
V-4-Choix d’un protocole de routage Bien qu’il y ait beaucoup de protocoles existant, en choisir un est relativement facile. Pour des
réseaux locaux, RIP est le plus courant. OSPF n’est pas encore largement disponible et Hello
n’a jamais été largement utilisé.
Pour un protocole extérieur, on a rarement le choix du protocole. Deux systèmes autonomes qui
échangent des informations doivent utiliser le même protocole. Si l’autre système autonome
fonctionne déjà, il faut alors utiliser le même protocole. Ce choix est souvent EGP même si
BGP se diffuse de plus en plus.
Chapitre 4 Configuration du DNS
I-Introduction
Le service de nom DNS n’est pas vraiment indispensable pour la communication entre
machines. Comme son nom l’indique, c’est un service dont le but est de rendre le réseau plus
convivial. Le réseau fonctionne très bien avec les adresses IP mais l’utilisateur préfère
utiliser des noms.
II-BIND
Au sein d’UNIX, DNS est implémenté par le BIND (Berkeley Internet Name Domain). C’est
un programme qui repose sur une architecture client/serveur. La partie client du BIND est
appelée le revolver. Il génère les demandes qui sont envoyées au serveur. Le serveur DNS
répond alors aux requêtes du resolver. La partie serveur du BIND est un démon appelé named.
Ce chapitre couvre les trois opérations a faire sur le BIND :
• configuration du resolver
• configuration du serveur de nom named
• construction des fichiers de données du serveur de nom, appelés fichiers de zone
BIND peut être configuré de plusieurs manières. Ces différentes configurations sont :
• resolver-only systems : sur les systèmes UNIX, le resolver n’est pas un client
séparé mais plutôt une librairie. Certains systèmes utilisent seulement le resolver. Ils
sont faciles à configurer: il suffit d’initialiser le fichier /etc/resolv.conf. Ce type de
configuration n’est quand même pas très courant. Elle est utilisée quand il y a une
limitation technique qui empêche de faire tourner le serveur.
(Les trois autres configurations sont toutes pour le serveur named).
• catching-only : ce type de serveur ne gère pas de fichiers de données. Il détermine
les réponses aux requêtes a partir d’autres serveurs distants. Une fois qu’il connaît
la réponse, le serveur conserve l’information pour d’autres demandes futures de la
même information. Ce type de serveur n’est pas autoritaire, vu qu’il dépend d’autres
serveurs. Seul un fichier cache est nécessaire pour conserver les informations
temporairement. Ce type de configuration de serveur est sGrement la plus répandue et
la plus simple a mettre en place avec la configuration précédente.
• primary : le serveur de nom primaire est maItre sur tout le domaine qu’il gère. Il
connaît les informations concernant le domaine a partir d’un fichier local fait par
l’administrateur réseau. Ce fichier de zone contient les informations précises sur le
domaine ou le serveur est maître. La configuration de ce serveur demande un
ensemble de fichiers : le fichier de zone pour le domaine (named.hosts) et le domaine
à l’envers (named.rev), le fichier boot(named.boot), le fichier cache (named.ca) et le
fichier de loopback (named.local).
• secondary : un serveur secondaire transfère les informations d’un serveur primaire
chez lui. Le fichier de zone est ainsi transféré et est stocké dans un fichier local. Ce
type de serveur a une copie complète des informations du domaine; on le considère
par conséquent comme un serveur maître.
La configuration d’un serveur est une de celles ci-dessus mais peut aussi en regrouper
plusieurs. Cependant, tous les systèmes doivent faire tourner un resolver. Commençons a
regarder la configuration de la partie cliente du DNS.
III-Configuration du resolver
Il y a deux manières de procéder a la configuration de resolver : utilisation de la configuration
par défaut ou utilisation du fichier resolv.conf.
Le resolver n’est pas un processus distinct; c’est une librairie de routines. Si le fichier
resolv.conf existe, il est lu chaque fois qu’un processus utilisant le resolver commence. Ce
fichier n’est pas demandé par les systèmes qui font tourner named. Tous ces systèmes
peuvent utiliser la configuration par défaut.
III-1-Configuration par défaut
Pour connaître le domaine par défaut, le resolver utilise la configuration par défaut. Il utilise la
machine locale comme serveur de nom par défaut et tire le nom du domaine par défaut de la
sortie de la commande hostname.
Pour que la configuration par défaut fonctionne, il faut que la machine locale fasse tourner
named.
hostname est une commande UNIX qui permet de vérifier ou d’installer le nom de la
machine. Seul, le root peut en faire l’installation. Par contre, tout le monde peut en faire la
vérification :
% hostname ensisun.imag.fr
Si le fichier resolv.conf n’existe pas, le resolver enlève la première partie de l’affichage de
hostname, i.e ensisun et utilise le reste, i.e imag.fr comme nom de domaine. Cela marche
correctement si le nom de la machine est «fully qualified domain name FQDN». Si
hostname retourne simplement ensisun, un fichier resolv.conf avec le nom de domaine par
défaut est nécessaire.
III-2-Fichier de configuration resolv.conf
Si le système local ne fait pas tourner named ou si le nom du domaine ne peut pas être tiré de
hostname, on doit utiliser le fichier resolv.conf. La configuration avec ce fichier a quelques
avantages sur la configuration par défaut. La configuration est définie clairement et elle
permet de choisir un serveur de nom autre que celui par défaut au cas où ce dernier ne réponde
plus. Ce fichier a deux entrées :
• nameserver address : identifie le ou les serveuri(s) de nom par son adresse IP. Si
cette entrée n’existe pas dans le fichier, le serveur de nom est supposé être la
machine locale. Sur une machine configurée resolver-only, le fichier resolv.conf
contient des noms de serveurs mais qui ne sont jamais la machine locale.
• domain name : définit le nom du domaine par défaut, par exemple imag.fr.
IV-Configuration de named
Alors que la configuration du resolver nécessite au plus un fichier, plusieurs fichiers sont
nécessaires pour configurer named.
IV-1-Le fichier named.boot
Ce fichier indique les sources de l’information DNS. Ces sources sont soit des fichiers
locaux, soit des serveurs distants. Les entrées de ce fichier sont les suivantes :
• directory : définit un répertoire de référence des fichiers.
• primary : déclare que ce serveur est primaire dans la zone spécifiée.
• secondary : déclare que ce serveur est secondaire dans la zone spécifiée.
• cache : indique le fichier cache.
• forwaders : liste des serveurs ou les requêtes sont expédiées.
• slave : force le serveur a seulement utilisé des forwaders.
La façon dont on configure named.boot indique si on utilise le serveur comme primary
server, secondary server ou catching-only server.
• Configuration catching-only server
Le contenu du fichier named.boot ressemble à ce qui suit :
;
; a catching-only server configuration
;
directory /usr/local/domain
primary 0.0.127.IN-ADDR.ARPA
named.local cache root.cache Tous les fichiers sont relatifs au répertoire /usr/local/domain
L’entrée cache dit a named de maintenir un cache aux réponses du serveur de noms et de
l’initialiser avec le fichier root.cache . Ce nom est choisi par l’administrateur. Nous verrons
son contenu dans le paragraphe suivant. L’entrée primary définit le serveur local comme
serveur primaire de son propre domaine en loopback. Ce domaine est un in-addr.arpa domaine
qui donne comme adresse a la machine locale 127.0.0.1.
• Configuration primary et secondary server
Voici le début du fichier qui définit imag comme serveur primaire sur le domaine imag.fr :
; ; @(#)named.boot 1.3 (Berkeley) 86/01/30 IMAG JUIN 1990
; boot file for primary and secondary name server
;
directory /usr/spool/named sortlist 129.88.0.0 147.171.0.0 130.190.0.0
;
; type domain source file or host ; primary 0.0.127.in-addr.arpa rev.127.0.0 primary imag.fr. imag.fr.zone
La deuxième entrée dit que la machine imag est le serveur primaire pour le domaine imag.fr
et que les données pour ce domaine sont a lire dans le fichier imag.fr.zone.
Pour une configuration de serveurs secondaires, les entrées secondary n’indiquent plus des
fichiers locaux mais des serveurs distants comme source d’information sur les domaines. Les
entrées secondaires donnent le nom du domaine, l’adresse du serveur primaire pour de
domaine et l’adresse le nom du fichier local ou l’information reçue du serveur primaire doit
être stockée.
Voici ce fichier qui définit ensisun comme serveur secondaire:
directory /var/spool/named
sortlist 129.88.0.0 147.171.0.0 130.190.0.0
secondary imag.fr 129.88.32.1 imag.fr.bk
secondary 88.129.in-addr.arpa 129.88.32.1
129.88.bk cache . root.cache
forwarders
129.88.32.1 slave
IV-2-Le fichier d’initialisation cache root.cache
Une entrée dans chaque fichier named.boot indique quel est le fichier d’initialisation cache.
Chaque serveur a ce fichier.
Le fichier cache pour ensisun est : /var/spool/named/root.cache.
Il contient le nom et les adresses des serveurs root . Voici son contenu :
;
; Hints for root nameserver
s ; . 99999999 IN N
S
c.nyser.net. 99999999 IN N
S
kava.nisc.sri.com. 99999999 IN N
S
ns.nasa.gov. 99999999 IN N
S
aos.brl.mil. 99999999 IN N
S
ns.nic.ddn.mil. 99999999 IN N
S
terp.umd.edu. 99999999 IN N
S
nic.nordu.net. c.nyser.net. 99999999 IN A 192.33.4.12 kava.nisc.sri.com. 99999999 IN A 192.33.33.24 ns.nasa.gov. 99999999 IN A 192.52.195.10 99999999 IN A 128.102.16.10 aos.brl.mil. 99999999 IN A 192.5.25.82 ns.nic.ddn.mil. 99999999 IN A 192.112.36.4 terp.umd.edu. 99999999 IN A 128.8.10.90 nic.nordu.net. 99999999 IN A 192.36.148.17
99999999 est le ttl (time to live). ttl représente la durée en seconde pendant laquelle
l’information doit être conservée dans le cache. La valeur 99999999 - la plus grande possible
- indique que le serveur root n’est jamais enlevé du cache.
Une liste de serveur root est disponible par ftp anonyme a nic.ddn.mil dans le fichier netinfo/
root/root-servers.txt.
Si le réseau n’est pas connecté a Internet, il est inutile d’initialiser le cache avec les serveurs
root ci-dessus, vu que vous ne pourrez pas les atteindre. Initialisez votre cache avec des
entrées qui pointent sur le serveur de nom local.
IV-3-Le fichier named.local
Ce fichier est utilisé pour convertir l’adresse 127.0.0.1 (l’adresse loopback) en le nom
localhost. C’est le fichier zone du domaine renversé 0.0.127.in-addr.arpa. Ce fichier est
presque chaque fois identique sur tous les serveurs. Voici le contenu du fichier mis à
disposition à l’adresse de ftp ci-dessus :
;
; @(#)named.local 1.1 (Berkeley) 86/01/21
;
@ IN SOA ucbvax.Berkeley.EDU. kjd.ucbvax.Berkeley.EDU. (
1.2 ; Serial
3600 ; Refresh
300 ; Retry
3600000 ; Expire
14400 ) ; Minimum
IN NS ucbvax.Berkeley.EDU.
0 IN PTR loopback.ucbvax.Berkeley.EDU.
1 IN PTR localhost.
• L’entrée SOA (Start of authority) identifie ucbvax.Berkeley.EDU comme le
serveur initialisant cette zone, et l’adresse e-mail kjd.ucbvax.Berkeley.EDU est
l’adresse ou poser des questions sur la zone.
• L’entré NS contient le nom de la machine hôte.
• Les entrées PTR convertissent les adresses en nom de machine.
• Les fichiers named.boot, root.cache et named.local sont les seuls fichiers
nécessaires a la configuration des serveurs en catching-only et secondary. La
plupart des serveurs n’utiliseront que ces fichiers.
IV-4-Le fichier de domaine renversé named.rev
Ce fichier a la méme structure que named.local car son but est de traduire des adresses IP en
nom. Voici le contenu d’un fichier exemple cherché a Berkeley. :
;
; @(#)named.rev 1.1 (Berkeley) 86/02/05
;
@ IN SOA ucbvax.berkeley.edu kjd.ucbvax.berkeley.edu ( 1.2 ; Serial
10800 ; Refresh 3 hours 3600 ; Retry 1 hour 3600000 ; Expire 1000 hours 86400 ) ; Minimum 24 hours
IN NS ucbvax.Berkeley.EDU. 0.0 IN PTR Berkeley-net.Berkeley.EDU. IN A 255.255.255.0 0.130 IN PTR csdiv-net.Berkeley.EDU. 2.129 IN PTR monet.Berkeley.EDU. 2.140 IN PTR ucbarpa.Berkeley.EDU. 3.132 IN PTR cad.Berkeley.EDU. 4.0 IN PTR ucbarpa.Berkeley.EDU. 5.0 IN PTR cad.Berkeley.EDU. 6.0 IN PTR ernie.Berkeley.EDU. 6.130 IN PTR monet-cs.Berkeley.EDU. 7.0 IN PTR monet.Berkeley.EDU. 7.130 IN PTR kim.Berkeley.EDU. 9.0 IN PTR esvax.Berkeley.EDU. 10.0 IN PTR ucbvax.Berkeley.EDU. 11.0 IN PTR kim.Berkeley.EDU. 11.156 IN PTR esvax-156.Berkeley.EDU. 38.131 IN PTR monet.Berkeley.EDU.
• L’entrée SOA définit le domaine pour le fichier zone. On retrouve le méme SOA
sur tous les fichiers zone de ensisun.
• L’entrée NS définit le serveur de noms pour le domaine.
• Les entrées PTR traduisent des adresses en nom. Dans notre cas, les
enregistrements PTR fournissent les noms de 0.0, 130.0, 129.2,... sur le réseau
128.66.
IV-5-Le fichier named.host
Ce fichier contient la plupart des informations sur le domaine. Ce fichier convertit les noms en
adresse IP. Cela correspond aux enregistrements A. Ce fichier, comme named.rev est
seulement crée pour les serveurs primaires. Les autres serveurs tirent ces informations des
serveurs primaires. Voici le contenu d’un fichier exemple :
; Authoritative data for Berkeley.EDU (ORIGIN assumed
Berkeley.EDU)
;
@ IN SOA ucbvax.berkeley.edu kjd.ucbvax.berkeley.edu
(
1.1 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
IN MX ucbvax 10
IN NS monet
ucb-arpa IN A 10.0.0.78
IN A 128.32.0.4
IN HINFO VAX-11/780 UNIX
arpa IN CNAME
ucbarpa ucb-vax 9999IN
A 10.2.0.78
IN A 128.32.0.10 IN HINFO VAX-11/750 UNIX
ucbvax IN CNAME ucbvax monet IN A 128.32.0.7
IN HINFO VAX-11/750 UNIX ucbmonet IN CNAME monet kjd IN MB ucbarpa dunlap IN MR kjd group IN MINFO kjd kjd.Berkeley.EDU.
IN MG name1
IN MG name2
V-Utilisation de nslookup
nslookup est un outil de débogage fourni avec le BIND. Il permet de faire des requêtes
directement a un serveur de nom et de retrouver les informations connues du DNS. C’est très
utile pour savoir si un serveur fonctionne correctement et est correctement configuré.
Cette commande est expliquée plus en détail dans un chapitre suivant.
Voici la manipulation a faire pour les données d’un domaine a partir d’un serveur primaire:
% nslookup
Default Server: ensisun.imag.fr
Addresses: 192.33.174.34, 192.33.174.65
> server imag.imag.fr
Default Server: imag.imag.fr
Address: 129.88.32.1
> ls imag.fr > temp
[imag.imag.fr]
############################################################
######## Received 6251 records.
> view temp
[imag.imag.fr]
imag.fr. server = imag.imag.fr
imag 129.88.32.1
imag.fr. server = hal.imag.fr
hal 129.88.32.24
imag.fr. server = layon.inria.fr
imag.fr. server = mirsa.inria.fr
imag.fr. server = archi.imag.fr
archi 147.171.129.1
imag.fr. 129.88.32.1
saint—eynard
129.88.38.27 notos
147.171.149.30 maceudes
129.88.32.49
lys
147.171.150.51
durga
129.88.32.24 oahu
129.88.100.64 lion
129.88.33.32
ensitty1
192.33.174.40 ensitty2
192.33.174.41 ensitty3
192.33.174.42 ensitty4
192.33.174.43 ensitty5
192.33.174.44 gimli
129.88.33.21 athena
129.88.40.3 knuth1
192.33.172.51 knuth2
192.33.172.52
mac_archi—10
147.171.129.230 knuth3
192.33.172.53 mac_archi—
11 147.171.129.231 knuth4
192.33.172.54
meltemi 147.171.149.20
mac_archi—12
147.171.129.232 knuth5
192.33.172.55
aragorn 129.88.33.23
mac_archi—13
147.171.129.233 mare
129.88.100.18 mac_archi—
15 147.171.129.235
mac_archi—16
147.171.129.236
mac_archi—17
147.171.129.237
mac_archi—20
147.171.129.240
mac_archi—18
147.171.129.238 mac_b2—1
129.88.59.2
devoluy 129.88.38.14
mac_archi—21
147.171.129.241
mac_archi—19
147.171.129.239 mac_b2—2
129.88.59.3 mac_archi—22
147.171.129.242 mac_b2—3
129.88.59.4 mac_archi—23
147.171.129.243 mac_b2—4
129.88.59.5 mac_archi—24
147.171.129.244 mac_b2—5
129.88.59.6 aramis—
campus 129.88.31.254
... ( to be continued)
Chapitre 5 Applications
I-Introduction
Dans ce chapitre nous allons présenter les applications les plus courantes que l’on puisse trou-
ver au-dessus de TCP/IP. Nous évoquerons leurs installations, leurs utilisations, leurs fichiers
de configurations (utilisateur ou système) ainsi que certains ‘trucs & astuces’ intéressant.
II- La famille des commandes ‘r’
Pour les systèmes Unix, la famille des commandes ‘r’ comprend toutes les commandes utiles
pour travailler a partir d’un serveur local sur un ou des serveurs distants; pourvu que les deux
systèmes soient de type Unix (et que les deux machines puissent se joindre l’une l’autre!).
Ces commandes sont très pratiques car elles permettent de passer d’une machine a l’autre sans
avoir a donner son mot de passe a chaque fois ... !
Elles représentent aussi par conséquent un danger considérable sur le plan de la sécurité si l’on
ne sait pas les maîtriser.
Les trois commandes ‘remotes’ qui nous intéressent nécessitent la mise en place par
l’opérateur ou par l’utilisateur de fichiers de configurations donnant des droits d’accès,
nominatifs ou par machine. Ces commandes sont :
• riogin : ‘remote login’ permet de se connecter sur une machine distante
Unix.
• rcp : ‘remote copy’ permet de copier des fichiers d’une machine Unix
a une autre.
• rsh : ‘remote shell’ permet d’exécuter une commande sur une
machine distante.
Exemples (pour comprendre aidez-vous du man ...) :
imag{22} whoami
durand
imag{23} riogin -i dupond ensisun
Last login: Wed Jun 16 08:11:02 from ensisun
SunOS Release 4.1.2 (ENSIMAG_SNC) #2: Fri Nov 20 16:26:13 MET 1992
**************************************************************
********* You have mail.
Terminal recognized as vt100 (ANSI/VT100 Clone)
ensisun{10} whoami
dupond
ensisun{11} exit
Connection
closed.
imag{24} rsh -i dupond ensisun is -iag /etc/passwd
—rw—r——r—— 1 root staff 29592 Jun 15 15:02
/etc/passwd imag{25} rcp dupond@ensisun:/etc/passwd
pswd
imag{26} is -iag pswd
—rw—r————— 1 durand students 29592 Jun 16
14:26 pswd imag{27} wich rsh
/usr/ucb/rsh
imag{28} in -s /usr/ucb/rsh ensisun
imag{29} ensisun ‘echo “qui suis-je ? ... “‘whoami‘“@“$HOST‘
qui suis—je ? ... durand@ensisun
imag{30} ensisun -i dupond ‘echo “qui suis-je ? ... “‘whoami‘“@“$HOST‘
qui suis—je ? ... dupond@ensisun
II-1- Le fichier IetcIhosts.equiv
Pour l’administrateur le fichier important est /etc/hosts.equiv; ce dernier est composé de zéro
ou plusieurs lignes de la forme :
[+|-][nom_de_machine] [Nom_d‘utilisateur]
Ce qui donnerait par exemple dans le Ietc/hosts.equiv de la machine ensisun :
-ensibull => Autorise toute personne ayant un compte sur ensibull et un sur
ensisun sous le méme nom d’utilisateur, a accéder a ensisun depuis ensibull sans
password !
-ensibull dupond => Force l’utilisateur dupond@ensibull a donner son password
lorsque qu’il tente d’accéder a ensisun depuis ensibull (utile quand dupond@ensibull
et dupond@ensisun ne sont pas la méme personne).
+ durand => Brèche dans la sécurité : Autorise toute personne ayant un
compte sur une machine distante sous le nom durand a accéder a tous les comptes
utilisateur d’ensisun sans password ! (le compte root excepté)
+ ensibull durand => ATTENTION : il y a un blanc entre + et ensibull (faute
d’inattention?) => Brèche dans la sécurité : Autorise toute personne ayant un compte
sur une machine distante sous le nom ensibull ou le nom durand a accéder a tous les
comptes d’ensisun sans password ! (le compte root excepté)
II-2- Les fichiers .rhosts
Le .rhosts est un fichier utilisateur qui a la même syntaxe que le fichier /etc/hosts.equiv mais
qui ne donne accès qu’au compte de l’utilisateur qui l’a crée et placé dans la racine de sont
répertoire utilisateur (le fichier .rhosts ne peut pas prendre le pas sur le fichier
/etc/hosts.equiv).
Exemple :
ensisun{1O} pwd
/users/durand
ensisun{11} cat > .rhosts
ensibull dupond
^D
ensisun{12} chmod go-w .rhosts
...
ensibull{1O}
whoami dupond
ensibull{11} rlogin -l durand ensisun
Last login: Thu Jun 17 12:19:37 from imag
SunOS Release 4.1.2 (ENSIMAG_SNC) #2: Fri Nov 2O 16:26:13 MET 1992
******************************************************************
*****
ensisun{1O} ...
III-Applications de base :
III-1-telnet, ftp
La configuration du système ayant été réalisée (/etc/inetd.conf), il ne devrait, pas y avoir de
problème pour ce servir de ces deux utilitaires (sauf si leur usage a été volontairement
restreint).
• telnet permet de se connecter a une machine distante qu’elle que soit son
type, pour plus d’information utiliser le man.
• ftp permet de transférer des fichiers entre des machines, même si ce
sont des systèmes très différents (sous FTP faire help).
Pour ce qui est de FTP quelques informations complémentaires sont tout de même très utiles
pour le débutant. Tout d’abord, il existe des serveurs FTP anonymes, cela signifie que sur de
tels serveurs il est possible de se connecter sous le nom d’utilisateur anonymous en donnant sa
propre adresse en guise de password.
Le fait de donner votre adresse en tant que password n’est pas une contrainte stricte : il suffit
en général de taper un caractère @ dans la ligne pour que le serveur soit satisfait, cependant
nous vous conseillons de mettre votre véritable adresse dans votre propre intérêt : avoir accès
au serveurs FTP anonymes n’est pas un droit, c’est un privilège que l’on vous accorde, et il
est normal (et même souhaitable) que le responsable d’un serveur anonyme soit au courant du
public qu’il touche, de plus il peut arriver que l’on prenne un fichier dangereux (bug
désastreux, cheval de Troie, virus, ...) on ne peut alors être prévenu du problème qu’à
condition d’avoir donner son adresse !
Ensuite, il faut connaître quelques pièges d’FTP :
• Tout fichier qui n’est pas un fichier texte, ne doit être transféré qu’en mode
binaire (par exemple, un fichier *.ZIP pour les PC ou un *.hqx pour les MAC
...)
• A l’inverse, tout fichier texte doit être transféré en mode ASCII car les marques
de fin de ligne, de fin de fichier, et même le jeux de caractère, sont différent d’un
constructeur à l’autre ... FTP réalise la conversion pour vous !
• Enfin, bien que l’on puisse utiliser des pipes dans les commandes d’FTP, il
faut bien prendre garde de ne pas mettre de blanc entre le pipe et la commande
qui le suit pour que FTP puisse l’interpréter correctement.
De plus, il n’est pas inutile de savoir que l’on peut se procurer sur le réseau des variantes
d’FTP
qui sont plus pratiques d’emploi (essayer sur ftp.inria.fr dans /system/user le fichier
ncftp.tar.Z).
Quelques adresses :
pilot.njin.net => liste de serveurs anonymes : pub/ftp-
list/ftp.list ftp.inria.fr => Sources, Xll, TeX, GNU, Games, ...
tsx-11.mit.edu => Linux (un Unix domaine public pour PC), GNUs, ... nic.switch.ch => Programmes domaines public pour PC, archives, ...
Exemples :
imag{10} ftp pilot.njin.net
Connected to pilot.njin.net.
220 pilot.njin.net FTP server ready.
Name (pilot.njin.net:dupond):
anonymous
331 Guest login ok, send e-mail address as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> help
Commands may be abbreviated. Commands are:
! cr macdef proxy send $ delete mdelete sendport status account debug mdir put struct append dir mget pwd sunique ascii disconnect mkdir quit tenex bell form mls quote trace binary get mode recv type bye glob mput remotehelp user case hash nmap rename verbose cd help ntrans reset ? cdup lcd open rmdir close ls prompt runique ftp> help dir bin hash
prompt
mget dir list contents of remote directory
binary set binary transfer type
hash toggle printing ‘#‘ for each buffer transferred
prompt force interactive prompting on multiple commands
mget get multiple files
ftp> cd pub/ftp-list
250 CWD command
successful. ftp> dir ftp*
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
—rw—r——r—— 1 30750 21060 7701 Jan 3 1992 ftp.help
—rw—r——r—— 1 30750 21060 148620 Jan 3 1992 ftp.list
—rw—r——r—— 1 30750 21060 2762 Jan 3 1992 ftpmailservers
—rw—r——r—— 1 30750 21060 33890 Jan 3 1992 ftpserv.tar.uu
226 Transfer
complete. remote: ftp*
268 bytes received in 0.032 seconds (8.1 Kbytes/s)
ftp> prompt
Interactive mode off.
ftp> mget ftp.*
200 PORT command successful.
150 Opening ASCII mode data connection for ftp.help (7701 bytes).
226 Transfer complete.
local: ftp.help remote: ftp.help
7897 bytes received in 0.91 seconds (8.5 Kbytes/s)
200 PORT command successful.
150 Opening ASCII mode data connection for ftp.list (148620 bytes).
226 Transfer complete.
local: ftp.list remote: ftp.list
150683 bytes received in 11 seconds (13 Kbytes/s)
ftp> close
221 Goodbye.
ftp> open ftp.inria.fr
Connected to ftp.inria.fr.
220 ftp FTP server (Version 5.60) ready.
Name (ftp.inria.fr:dupond): anonymous
331 Guest login ok, send e—mail address as password.
Password:
230—
230— *************************************
230— * WELCOME to the INRIA FTP server *
230— *************************************
230—Please read the file README
230- it was last modified on Tue Jun 8 08:30:26 1993 - 9 days ago
230 Guest login ok, access restrictions apply. ftp>
bin
200 Type set to I.
ftp> hash
Hash mark printing on (8192 bytes/hash mark).
ftp> get network/ftp.servers.Z Iuncompress>tst
200 PORT command successful.
150 Opening BINARY mode data connection for ftp.servers.Z (47919 bytes).
##################################################################
#######
226 Transfer complete.
local: Iuncompress>tst remote: ftp.servers.Z
47919 bytes received in 3.3 seconds (14 Kbytes/s)
ftp> bye
221 Goodbye.
III-2-Le mail : courrier électronique
Une discussion détaillée du courrier électronique pourrait suffire à faire l’objet d’un livre
entier, c’est pourquoi nous nous contenterons ici de ne donner qu’un descriptif assez bref.
Lorsque vous envoyez un courrier par la commande mail, il se passe tout un enchainement
d’opérations, mais l’important est la commande sendmail qui est le centre nerveux du système
de courrier électronique. On peut distinguer trois tâches de sendmail :
• Recevoir le courrier électronique Internet : SMTP
• Permettre l’utilisation d’alias et listes de mailing
• Faire parvenir le courrier à destination en analysant l’adresse destinataire (ce
dernier point masque aussi le fait qu’il y a pas moins de trois programmes de
traitement du courrier électronique suivant qu’il s’agisse d’un courrier Internet,
d’un courrier entre systèmes UUCP, ou, d’un courrier local entre deux
utilisateurs d’une même machine !)
III-2-a-Sendmail le demon SMTP : Le démon sendmail, prend le courrier Internet qui arrive sur le port TCP 25 et le traite ...
Pour comprendre ce qu’il fait, regardons les lignes qui démarrent sendmail en tant que démon
lors du boot :
if [ -f /usr/lib/sendmail -a -f /etc/sendmail.cf ]; then
(cd /var/spool/mqueue; rm -f nf* lf*) /usr/lib/sendmail -bd -qlh ; echo -n ‘ sendmail‘
fi On voit d’abord le classique test d’existence des fichiers nécessaires, puis la ligne rm qui
est chargée d’éliminer tous les verrous qui auraient pu rester dans le répertoire
/var/spool/mqueue si la machine c’est crashé alors que des courriers étaient en cours de
traitement. Enfin on peu démarrer le démon avec les options :
-qintervale => précise la fréquence a la quelle on doit traiter la queue (1h
=> toute les heures; 15m => tout les quarts d’heure ...)
-bd => précise que sendmail doit fonctionner comme un démon, et
doit écouter le port 25 pour réceptionner les courriers arrivant.
III-2-b-Sendmail le pourvoyeur d’alias Les aliases que reconnaît sendmail sont définis dans /etc/aliases avec le format :
alias:recipient[,recipient]... ou owner-aliasname:address
Ces aliases peuvent servir trois causes :
• donner des surnoms aux utilisateurs (ou admettre des noms complets, avec
majuscule ...)
• faire suivre le courrier (cas des comptes déplacé ou supprimés)
• établir des listes de mailing
Exemple :
##
# Aliases can have any mix of upper and lower case on the left-hand side,
# but the right-hand side should be proper case (usually lower)
#
# >>>>>>>>>> The program “newaliases“ will need to be run after
# >> NOTE >> this file is updated for any changes to
# >>>>>>>>>> show through to sendmail.
#
# @(#)aliases 1.10 89/01/20 SMI
##
# Following alias is required by the mail protocol, RFC 822
# Set it to the address of a HUMAN who deals with this system’s mail problems.
Postmaster: root
# Alias for mailer daemon; returned messages from our MAILER-
DAEMON
# should be routed to our local Postmaster.
MAILER-DAEMON: postmaster
# Une alternative pour joindre le compte cathy :
cassagne: cathy
# Mailing-liste pour joindre les responsable ...
admin: cassagne, dupond, durand@ensibull,
smith@imag owner-admin: cathy
Il est noter que tout changement dans le fichier /etc/aliases ne sera pas pris en compte tant que
l’on n’aura pas exécuter la commande newaliases pour que sendmail remette a jours ses
données.
III-2-c-Sendmail le centre de tri Quand il faut déterminer la route que doit prendre un courrier, c’est encore sendmail qui est
mis a contribution. Il s’appui pour ce faire sur le fichier de configuration sendmail.cf. Ce
dernier a trois fonctions principales :
• Définir l’environnement de senmail.
• Donner des règles de réécriture des adresses dans une syntaxe appropriée au
programme qui recevra le courrier.
• Etablir les instructions a exécuter pour faire parvenir le courrier en fonction de
l’adresse.
La syntaxe de ce fichier étant fort complexe, (c’est un véritable langage) et très rébarbative
(chaque mot, variable de ce langage n’est constitué que d’une seule lettre!); on se contentera
d’indiquer comment ce procurer un fichier modèle, ainsi que des guides qui vous aiderons a
l’adapter a vos besoins.
Le fichier ftp.uu.net:mail/sendmail/sendmail-5.65.tar.Z contient tout ce dont vous aurez
besoin pour établir votre sendmail.cf, en particulier, vous y trouverez :
• tcpuucpproto.cf modèle pour les systèmes ayant un accès direct au réseaux
TCP et UUCP.
• tcpproto.cf modèle pour les systèmes n’ayant un accès direct qu’aux
réseaux TCP.
• uucpproto.cf modèle pour les systèmes n’ayant un accès direct qu’aux
réseaux UUCP.
• doc/07.sendmailop/ Sendmail Installation and Operation Guide ...
• doc/16.sendmail/ Sendmail: An Internetwork Mail Router ...
III-2-d-Au rayon farces et attrapes : sendmail En faisant un telnet sur le port 25 d’une machine, on peu rentrer en communication directe
avec sendmail (le démon) et de cette façon, lui faire croire qu’il a reçu un courrier SMTP. Le
point intéressant étant que l’on peut spécifier soit méme le nom de la personne a l’origine du
courrier !!!
exemple :
ensisun-> whoami
dupond
ensisun-> telnet ensibull 25
Trying 192.33.174.35 ...
Connected to ensibull.
Escape character is ’^]’.
220 ensibull.imag.fr Sendmail 5.61/5.17 ready at Sat, 26 Jun 93 10:19:47 GMT
help
214-Commands:
214- HELO MAIL RCPT DATA RSET
214- NOOP QUIT HELP VRFY EXPN
214-For more info use “HELP <topic>“.
214-To report bugs in the implementation contact [email protected]
214-or [email protected].
214-For local information contact postmaster at this site.
214 End of HELP info
MAIL FROM : le_grand_duduche
250 le_grand_duduche... Sender ok
RCPT TO: dupond@ensisun
250 dupond@ensisun... Recipient ok
DATA
354 Enter mail, end with “.“ on a line by itself
Salut, ma poule, tu sais qu’ta d’bosieux ?
.
250 Ok
quit
221 ensibull.imag.fr closing connection
Connection closed by foreign host.
...
ensisun~> mail
Mail version SMI 4.0 Wed Oct 23 10:38:28 PDT 1991 Type ? for
help. “/usr/spool/mail/dupond“: 1 messages 1 new 1 unread
N 1 [email protected] Sat Jun 26 10:23 13/465
& 1
Message 1:
From [email protected] Sat Jun 26 10:23:45 1993
Received: from ensibull.imag.fr by ensisun.imag.fr (4.1/5.17)
id AA13434; Sat, 26 Jun 93 10:23:45 +0200
Received: from ensisun by ensibull.imag.fr (5.61/5.17)
id AA19417; Sat, 26 Jun 93 10:20:41
GMT Date: Sat, 26 Jun 93 10:20:41
GMT
From: [email protected]
Message-Id:
Apparently-To: dupond@ensisun
Status: R
Salut, ma poule, tu sais qu’ta d’bosieux ?
& x Si cette technique permet sur des systèmes qui ne sont pas très stricts sur le plan de la sécurité,
de faire quelle bonne farces, nous vous conseillons de ne pas en abuser car vous pourriez en
arriver a vous méfier sans arrêt, et a ne plus savoir distinguer le vrai du faux ... (sans parler des
ennuis que vous pourriez vous attirer si l’on prend vos faux courriers au sérieux !).
III-3-NIS : Network Information Service
Le NIS est une base de données contenant des informations sur le réseau, elle assure une
distribution de l’information tout en gardant l’avantage de la simplicité de mise a jour des
informations d’un système centralisé. Les informations aux quelles NIS permet d’accéder,
sont groupées dans des sortes de tables distribuées sur le réseau (appelées ’NIS maps’), mais
leur contenu est en fait tiré de quelques fichiers Unix centralisés (dont certains ont déja été
décrits dans ce document) :
Tableau 9 : Fichiers Unix et NIS maps
Fichier maps descriptio
n /etc/ethers ethers.byad
dr
ethers.byna
me
Donne les adresses ethernet a partir des
adresses
IP (utilisé par RARP)
/etc/hosts hosts.byad
dr
hosts.byna
me
Donne les conversions d’
adresses IP de machine:
numérique <--> par nom Tableau 9 : Fichiers Unix et NIS maps
Fichier maps descriptio
n /etc/networks networks.byad
dr
networks.byna
me
Donne les conversions d’adresses IP de
réseaux :
numérique <--> par nom /etc/netmasks netmasks.byaddr Donne les subnet-masks des réseaux du
domaine /etc/protocols protocols.byad
dr
protocols.byna
me
Nom de protocole <--> port/protocole
/etc/services services.byname Services TCP/IP
/etc/aliases mail.byad
dr
mail.alias
es
Définit des alias pour joindre des
personnes ou des groupes de personnes
par mail. /etc/netgroup netgroup.byu
ser
netgroup.byh
ost
Définit des groupes d’utilisateur et des
groupes de machines.
III-3-a-Mise en place de NIS NIS a besoin de connaître le nom du domaine pour maintenir sa base de données car elle
réside dans un sous répertoire de /var/yp dont le nom dérive du nom du domaine : si le nom
du domaine est cheops.imag.fr le répertoire de la base NIS est /var/yp/cheops.imag.fr . Il faut
donc lui indiquer ce nom de domaine au démarrage ce qui est fait par la commande
domainname dans un des fichiers de boot.
NIS peut être utilisé comme alternative a DNS pour un réseau fermé non connecté a Internet,
mais pour tout ceux qui utilisent Internet il faut DNS, cependant NIS apporte des informations
qui ne sont pas accessibles par DNS de sorte qu’il est courant d’utiliser les deuxi. Pour ce faire
il est nécessaire de faire une petite modification au fichier /var/yp/Makefile : il faut enlever le
caractère # qui est au début de la ligne ’B=-b’ et en mettre un devant ’B=’.
Pour lancer le serveur et reconstruire les ’NIS maps’ il faut d’abord exécuter ‘ypinit -m‘,
démarrer le serveur par ‘ypserv‘, et enfin, démarrer le démon de transfert des maps par
‘ypxfrd‘ sur la machine serveur principal. Quand aux machines clientes, elles se contentent
de lancer ‘ypbind‘.
III-3-b-Le fichier /etc/netgroup Le fichier /etc/netgroup est un fichier qui n’est utilisé que par NIS et qui définit des groupes
de machines ou d’utilisateur. Sa syntaxe est la suivante :
nom_du_groupe membre [membre] . . .
oi membre est soit le nom d’un autre groupe soit la définition d’une entité suivant le format
: (nom_de_machine, nom_d’utilisateur, nom_de_domaine)
oi le nom de domaine est optionnel. Ce qui donne par exemple :
admin (ensisun, dupond, ) (ensibull, durand, )
On peut alors utiliser ces nom de groupes partout oi des noms de machine ou des noms
d’utilisateur sont requis, en particulier, dans les .rhosts ou le /etc/hosts.equiv il suffit de
précéder le nom de groupe d’un caractère @ pour que le système le comprennent comme un
nom de groupe et en extrait les noms d’utilisateur ou les noms de machine suivant ce qui est
requis
Vous avez pu noter que le nom de domaine a été omis dans les exemples, c’est en général le
cas, car on sort rarement du domaine dans ce genre de fichier. Une autre pratique courante
est de séparer les groupes de personnes et les groupes de machine pour simplifier
l’administration; ce qui donne par exemple :
admin (-, dupond, ) (-, durand, )
staff (-, smith, ) admin
enseignement (ensisun, -, ) (ensibull, -
, )
machines enseignement (imag, -, )
III-4-NFS: Network File System
NFS a pour but de faire partager a plusieurs machines leurs systèmes de mémoires de masse.
C’est une application transparente pour l’utilisateur, on peut très bien travailler sans être au
courant de l’existence de ce système cependant je pense qu’il est intéressant de savoir de quoi
il retourne ’pour la culture personnel’.
Les avantages d’NFS sont :
• Une réduction notable des besoins en espace disques : comme on peut avoir des
stations de travail sans disques qui travail sur les fichiers d’une autre machine =>
on peut faire en sorte que tout les fichiers (en particulier tout le système, les
applications) sont en un seul exemplaire.
• Permet aux utilisateurs d’avoir le même environnement, et d’accéder aux mêmes
fichiers qu’elle que soit le poste sur le quelle ils travaillent.
• Simplifie les tâche d’administration en centralisant les fichiers qui restent
pourtant accessible sur tout le réseau.
NFS est basé sur un système client I serveur, le client utilise les fichiers du serveur comme
s’ils faisaient partie des disques locaux. Lorsque que l’on s’attache une arborescence d’un
disque d’une autre machine, on dit que l’on monte un répertoire (’to mount a directory’ en
anglais). Alors que rendre accessible une arborescence aux autres machines se dit exporter
un répertoire.
III-4-a-Les demons NFS : mise en place d’NFS Les démons nécessaires a faire tourner NFS sont lancés dans les scripts de démarrage des
machines clientes et des machines serveurs :
Ce qui donne par exemple les portions de scripts :
# démarrage d’un client NFS
if [ -f /usr/etc/biod -a -f /usr/etc/rpc.statd -a -f /usr/etc//rpc.lockd ]; then
biod 8 ; echo -n ’ biod’
rpc.statd & echo -n ’ statd’
rpc.lockd & echo -n ’ lockd’# fi
# démarrage d’un serveur NFS
if [ -f /etc/exports ] ; then > /etc/xtab
exportfs -a
nfsd 8 & echo -n ’ nfsd’ rpc.mountd
fi On notera que dans ces scripts, on a testé l’existences des fichiers nécessaire avant de
démarrer les démons.
III-4-b-Coté serveur ... Le fichier /etc/exports contient les informations décrivant les répertoires à exporter, que la
commande ’exportfs -a’ utilise pour générer les informations nécessaires à mountd dans le
fichier /etc/ xtab .
nfsd [nservers] Le démon des serveurs NFS (le paramètre précise le nombre de
démon a démarrer, en général on met 8).
biod [nservers] Le démon des clients NFS (nservers a la méme signification).
rpc.lockd Le démon de verrouillage de fichiers tourne sur les clients
comme sur les serveurs.
rpc.statd Le démon de contrôle d’état, indispensable a rpc.lockd (en
particulier pour récupérer d’un crash).
rpc.mountd Le démon de mount (tourne du coté serveur) sont rôle est de
gérer les demandes de mount des clients.
La syntaxe de ce fichier est :
repertoire [-option][,option]...
oi option précise les droits d’accès.
Les options de bases sont (pour plus d’informations faire ’man exports’) :
Ro “Read Only“ tout client NFS peut lire mais aucun n’a le droit d’écrire dans le répertoire.
rw [=machine][:machine]...
“Read Write“ si un (ou plusieurs) nom de machine est précisé, seul les machines spécifiées
ont un accès en lecture I écriture les autres ont un accès en lecture. Si aucun nom de
machine n’est spécifié, tout client NFS a accès en lecture I écriture.
access=machine[:machine]
Précise quelles sont les machines ayant droit de monter le répertoire
(on utilise en général cette option en conjonction avec l’option ro)
Exemple :
/usr
/users
/users.nfs
/users.ext
/usr/local
/var/spool/mail
/var/spool/pcnfs
/export/exec/kvm/sun4c.sunos.4.l.2
/export/root/ensisunl -access=ensisunl,root=ensisunl
/export/swap/ensisunl -access=ensisunl,root=ensisunl
/export/root/ensisun2 -access=ensisun2,root=ensisun2
/export/swap/ensisun2 -access=ensisun2,root=ensisun2
/export/root/ensisun3 -access=ensisun3,root=ensisun3
/export/swap/ensisun3 -access=ensisun3,root=ensisun3
/export/root/ensisun4 -access=ensisun4,root=ensisun4
/export/swap/ensisun4 -access=ensisun4,root=ensisun4
III-4-c-Coté client ... Pour monter un répertoire exporté par un serveur NFS il suffit (sous root) de faire un
mount nom_de_serveur_NFS:nom_de_répertoire nom_de_répertoire_locale
Par exemple :
# mkdir nfsusers
# mount ensisun:/users nfsusers Cependant, si l’on veut que ces répertoires soient montés a chaque boot, il faut créer un
fichier
/etc/fstab qui sera utilisé par la commande ’mount -vat nfs’ dans un script de démarrage pour
remettre en place tous les répertoires requis.
Pour créer ce /etc/fstab, le plus simple est de monter les répertoires a la main en s’aidant
éventuellement de la commande ’showmount -e nom_de_serveur’ qui permet de lister les
répertoires exportés par un serveur NFS; puis, de générer le fichier par la commande :
# mount -p > /etc/fstab Ce qui donne par exemple :
ensuntx:/export/root/ensisun2 / nfs rw 0 0
ensuntx:/export/exec/sun4.sunos.4.l.2 /usr nfs rw 0 0
ensuntx:/export/exec/kvm/sun4c.sunos.4. .2/usr/kvm nfs rw 0 0
ensuntx:/users /users nfs rw 0 0
ensuntx:/users.ext /users.ext nfs rw 0 0
ensuntx:/var/spool/mail /var/spool/mail nfs rw 0 0
ensuntx:/export/share/sunos.4.1.2 /usr/share nfs rw 0 0
ensuntx:/usr/local /usr/local nfs rw 0 0
III-5-Mise en place d’un serveur FTP anonyme
La mise en place d’un serveur FTP anonyme en 5 étapes :
1 - Ajouter l’utilisateur ftp au /etc/passwd.
2 - Créer un répertoire racine du compte ftp, et en interdire l’accès en écriture.
3 - Y créer un sous répertoire bin appartenant au root; placer-y une copie de la commande is,
dont vous ne laisserez que le droit d’exécution, et enfin, enlevez le droit d’écriture au
répertoire bin.
4 - Créer un sous répertoire etc appartenant au root, y placer un fichier passwd et un fichier
group spécial, ne laisser que le droit de lecture pour ces deux fichiers, et enfin, interdire
l’écriture dans le répertoire.
5 - Créer pour finir un sous répertoire pub appartenant a ftp avec tous les droits d’accès
(mode
777). C’est dans ce dernier répertoire que les anonymes pourront déposer I prendre des
fichiers.
Voyons en détail un exemple de mise en pratique :
# mkdir
/usr/ftp
# cd /usr/ftp
# mkdir
bin
# mkdir
etc
# mkdir
pub
# cp /bin/ls bin
# chmod 111
bin/ls
# cat > etc/group
# attention : etc et non /etc !
anonymous:*:
15:
^
D
# cat >
etc/passwd
ftp:*:15:15:acces au ftp anonyme:/usr/ftp:
^
D
# chmod 444 etc/group
etc/passwd
# cat etc/group >> /etc/group
# attention : >> et non > !
# cat etc/passwd >> /etc/passwd
# chown ftp
pub
# chmod 777
pub
# chmod 555 bin
etc
# cd ..
# chown ftp
ftp
# chmod 555 ftp
C’est tout pour tous ceux qui utilisent un système différent du SunOS 4.x !
En effet, du fait de son fonctionnement, oi les par librairies sont chargées dynamiquement,
SunOS 4.x a besoin de quelques composants supplémentaires : “le multiloader“, les librairies C
partagées, et le fichier dev/zero. Ce qui ce fait par exemple par :
# cd /usr/ftp
# mkdir usr
# mkdir usr/lib
# cp /usr/lib/ld.so usr/lib
# cp /usr/lib/libc.so.* usr/lib
# chmod 555 usr/lib/libc.so.* usr/lib usr
# cd /usr/ftp
# mkdir dev
# cd dev
# mknod zero c 3 12
# cd ..
# chmod 555 dev
Maintenant, vous n’avez plus qu’a mettre en place les fichiers que vous voulez rendre
accessible par FTP anonyme dans le répertoire /usr/ftp/pub (si vous voulez éviter que vos
fichiers ne disparaissent, assurez vous qu’ils n’appartiennent pas a ftp et que leurs droits
d’accès sont fixés a 644).
Enfin, il faut être conscient qu’un serveur FTP représente quand même un risque potentiel
pour la sécurité, de sorte qu’il est a recommander de limiter le nombre de machine offrant un
tel service dans un même réseau, et de surtout de bien vérifier que l’installation est correcte.
