Administration Système et Réseau LINUX

Transcription

Jean-Paul Coulon
Linux - Administration Système & Réseau V1.20
Administration Système et Réseau
LINUX
Page 1/58
Jean-Paul Coulon
Table des matières
MODULE 14 : La configuration réseau..........................................................................................................5
1 Généralités et arrêt/marche de l'accès réseau...........................................................................................................5
1.1 Généralités.........................................................................................................................................................5
1.2 L'arrêt/marche de l'accès réseau.......................................................................................................................5
2 Configuration des paramètres réseaux......................................................................................................................5
2.1 Installation de la carte réseau...........................................................................................................................5
2.2 Les interfaces.....................................................................................................................................................6
2.3 La table de routage système..............................................................................................................................6
3 Fichiers de configuration et scripts...........................................................................................................................7
3.1 Généralités.........................................................................................................................................................7
3.2 Les paramètres globaux.....................................................................................................................................7
3.3 Les paramètres par interface.............................................................................................................................7
3.4 Validation des paramètres réseaux...................................................................................................................8
3.5 Spécificités Fedora............................................................................................................................................8
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP)......................................................9
1 Généralités..................................................................................................................................................................9
2 La configuration du client..........................................................................................................................................9
2.1 Le service dhcp..................................................................................................................................................9
2.2 Les fichiers paramètres.....................................................................................................................................9
3 La configuration du serveur.....................................................................................................................................10
3.1 Les modes de distribution d'adresses.............................................................................................................10
3.2 Le fichier /etc/dhcp/dhcpd.conf......................................................................................................................10
MODULE 16 : Le filtrage IP par iptables.....................................................................................................12
1 Généralités...............................................................................................................................................................12
2 Les buts du filtrage IP..............................................................................................................................................12
3 Historique des versions............................................................................................................................................12
4 Les pré-requis systèmes..........................................................................................................................................12
5 Le principe du filtrage iptables à l'aide de la table filter........................................................................................12
6 Algorithme du filtrage.............................................................................................................................................13
7 Utilisation d'iptables................................................................................................................................................13
7.1 Manipulation des chaînes................................................................................................................................13
7.2 Manipulation des règles..................................................................................................................................14
8 Commandes systèmes..............................................................................................................................................14
8.1 Gestion des modules du noyau.......................................................................................................................14
8.2 Mise en service du forwarding.......................................................................................................................14
8.3 Sauvegarde des règles.....................................................................................................................................14
9 Exemples de règles..................................................................................................................................................14
MODULE 17 : La centralisation des services réseaux par xinetd................................................................17
1 Généralités...............................................................................................................................................................17
2 Le contrôle d'accès aux services et le tcp-wrapper................................................................................................17
2.1 Généralités.......................................................................................................................................................17
2.2 Les listes de contrôles hosts.deny et hosts.allow..........................................................................................17
3 Le super-daemon xinetd..........................................................................................................................................18
3.1 Généralités.......................................................................................................................................................18
3.2 Configuration du daemon xinetd....................................................................................................................18
3.3 Liaison et ré-acheminement de port...............................................................................................................19
MODULE 18 : L'impression..........................................................................................................................20
1 Les principaux serveurs d'impression.....................................................................................................................20
1.1 Généralités.......................................................................................................................................................20
1.2 Installation.......................................................................................................................................................20
2 Le daemon LPD.......................................................................................................................................................20
2.1 paramétrage.....................................................................................................................................................20
3 Le daemon CUPS.....................................................................................................................................................20
4 Remarques................................................................................................................................................................22
MODULE 19 : Le partage de fichier par NFS...............................................................................................23
1 Généralités................................................................................................................................................................23
2 RPC et portIP...........................................................................................................................................................23
Page 2/58
Jean-Paul Coulon
3 Paramétrage d'un serveur NFS................................................................................................................................24
3.1 Structure du fichier /etc/exports (Extrait de la page de man exports). .........................................................24
3.2 Lancement de rcpbind et de NFS...................................................................................................................24
4 paramétrage du client NFS......................................................................................................................................25
5 Montage au démarrage et optimisation...................................................................................................................25
5.1 Montage au démarrage....................................................................................................................................25
5.2 Montage optimisé ou automontage.................................................................................................................25
MODULE 20 : Administration et authentification centralisées par NIS......................................................26
1 Généralités................................................................................................................................................................26
2 Principe du client-serveur NIS................................................................................................................................26
3 Paramétrage du serveur NIS....................................................................................................................................26
3.1 Les pré-requis..................................................................................................................................................26
3.2 Le domaine......................................................................................................................................................26
3.3 Déclaration des hosts autorisés.......................................................................................................................27
3.4 Choix des fichiers d'administration à gérer par le serveur NIS...................................................................27
4 paramétrage du client NIS.......................................................................................................................................27
4.1 Les pré-requis..................................................................................................................................................27
4.2 Le domaine......................................................................................................................................................28
4.3 Configuration du client NIS............................................................................................................................28
4.4 Organisation hiérarchique de l'administration...............................................................................................28
5 Tests et expérimentation..........................................................................................................................................28
MODULE 21: L'annuaire LDAP...................................................................................................................29
1 Généralités................................................................................................................................................................29
1.1 Définition.........................................................................................................................................................29
1.2 Historique, du fichier local à l'annuaire..........................................................................................................29
1.3 Annuaire et SGBD...........................................................................................................................................29
1.4 Le protocole LDAP.........................................................................................................................................29
2 Le modèle d'information..........................................................................................................................................30
2.1 Terminologie...................................................................................................................................................30
2.2 Le schéma d'annuaire (Directory Schema).....................................................................................................30
2.4 Les classes d'objets.........................................................................................................................................31
2.5 Le format d'échange de données LDIF...........................................................................................................32
3 Le modèle de désignation........................................................................................................................................33
3.1 L'arbre DIT (Directory Information Tree).....................................................................................................33
3.2 L'accès aux entrées..........................................................................................................................................33
4 Le modèle fonctionnel.............................................................................................................................................33
5 Le modèle de sécurité..............................................................................................................................................34
6 Installation sur linux (fedora core 6).......................................................................................................................34
6.1 Client...............................................................................................................................................................34
6.2 serveur.............................................................................................................................................................34
6.3 Autres...............................................................................................................................................................35
7 Création de l'annuaire..............................................................................................................................................35
7.1 Création de l'arborescence..............................................................................................................................35
Les fichiers ldif correspondants sont respectivement; societe.ldif, branche.ldif, users.ldif :.............................36
Leur insertion dans l'annuaire est réalisées par les commandes :........................................................................37
7.2 Paramétrage.....................................................................................................................................................37
8 Utilisation de l'annuaire...........................................................................................................................................38
9 Applications utilisant ldap.......................................................................................................................................38
MODULE 22 : Le système graphique Xwindow..........................................................................................39
1 Généralités................................................................................................................................................................39
2 Concept client/serveur Xwindow............................................................................................................................39
3 Fonctionnalités et spécificités.................................................................................................................................39
3.1 Le clavier.........................................................................................................................................................39
3.2 L'écran..............................................................................................................................................................39
4 Le Display Manager.................................................................................................................................................40
5 Le Window Manager...............................................................................................................................................40
6 Sécurité et contrôle d'accès.....................................................................................................................................40
6.1 Les listes de machines....................................................................................................................................40
6.2 Le magic-cookie..............................................................................................................................................40
6.3 Sécurisation par clés de codage......................................................................................................................40
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation.......................................................42
Page 3/58
Jean-Paul Coulon
1 Structure physique d'un disque...............................................................................................................................42
1.1 Généralités.......................................................................................................................................................42
1.2 Taille d'un disque............................................................................................................................................42
1.3 Calcul de la taille d'une partition....................................................................................................................43
2 Structure logique d'un disque..................................................................................................................................43
2.1 MBR MasterBootRecord et BR BootRecord.................................................................................................43
2.2 Démarrage, MBR et BR..................................................................................................................................44
2.3 Partitions primaires et étendues.....................................................................................................................44
2.4 Le Linux-Loader LILO et la commande ''lilo''..............................................................................................45
2.5 Création d'une disquette d'amorce..................................................................................................................46
2.6 Création d'une disquette d'amorce avec un chargeur LILO..........................................................................46
MODULE 24 : La personnalisation d'un noyau système...............................................................................47
1 Le noyau (kernel).....................................................................................................................................................47
1.1 Généralités.......................................................................................................................................................47
1.2 Fonctions.........................................................................................................................................................47
2 La compilation..........................................................................................................................................................47
2.1 Les buts recherchés........................................................................................................................................47
2.2 Choix des composantes de la compilation.....................................................................................................48
2.3 La compilation.................................................................................................................................................48
2.4 Phase de test et d'installation..........................................................................................................................49
3 Mise à jour d'un noyau par un « patch ».................................................................................................................49
MODULE 25 : Les niveaux de démarrage systemV.....................................................................................50
1 Principe de démarrage de Linux (système V)........................................................................................................50
2 Les niveaux de démarrage (run-level).....................................................................................................................50
2.1 Généralités.......................................................................................................................................................50
2.2 Description de /etc/inittab..............................................................................................................................51
3 Le processus d'initialisation init..............................................................................................................................52
3.1 Organisation et hiérarchie...............................................................................................................................52
3.2 Gestion des scripts d'arrêt/démarrage par niveau..........................................................................................53
3.3 Les outils de gestion des scripts.....................................................................................................................54
MODULE 26 : La journalisation système (issue du système BSD)..............................................................55
1 Introduction..............................................................................................................................................................55
2 Principes de la journalisation, log et daemon.........................................................................................................55
3 Installation et mise en service.................................................................................................................................55
3.1 La distribution linux Fedora...........................................................................................................................55
3.2 Syslog..............................................................................................................................................................55
3.3 Syslog et réseau...............................................................................................................................................55
4 La configuration principale......................................................................................................................................56
4.1 Le fichier syslog.conf utilise sa propre syntaxe............................................................................................56
4.2 La hiérarchie en place et la personnalisation.................................................................................................56
5 Exemple avec la journalisation du daemon xinetd.................................................................................................56
6 Notes.........................................................................................................................................................................57
Notes personnelles.........................................................................................................................................58
Page 4/58
Jean-Paul Coulon
MODULE 14 : La configuration réseau.
1 Généralités et arrêt/marche de l'accès réseau.
1.1 Généralités.
Du point de vue système, la mise en service réseau est une suite d'opérations qui vont permettre au
kernel de dialoguer avec l'extérieur. Ce dialogue ne pourra se faire que par l'intermédiaire de différents
matériels de types modems, cartes réseau, ports séries/parallèles ou tout autre qui sera identifié sous le
terme générique d'interface-réseau. Les plus courantes sont eth0, eth1..., ethN (pour les N cartes ethernet
installées sur la machine) et lo (pour l'interface loopback (boucle arrière) servant par exemple dans le cas
d'une communication client/serveur sur une même machine).
1.2 L'arrêt/marche de l'accès réseau.
L'appel du script de démarrage systèmeV network (voir module 24) avec l'un des arguments standardisés
du type start, stop, restart, status permet la mise en fonction, l'arrêt ou d'obtenir l'état du service réseau.
Note: Ce script a pour fonction de provoquer des arrêts/marches de la fonction réseau telle qu'elle a été
perçue au dernier démarrage. Les changements de paramètres réseaux ne seront donc pas pris en
compte.
2 Configuration des paramètres réseaux.
2.1 Installation de la carte réseau.
Toute carte installée physiquement dans un PC doit être reconnue par le système d'exploitation pour être
paramétrée ensuite. La commande lsdev nous informe sur les périphériques que perçoit le noyau.
[root@zephyr root]# lsdev
Device
DMA IRQ I/O Ports
-----------------------------------------------8139too
2000-20ff
acpi
9
ALI
1800-18ff
ALi
1800-18ff 1c00-1cff 2480-248f 8000-803f 8040-805f
cascade
4 2
dma
0080-008f
dma1
0000-001f
dma2
00c0-00df
eth0
11
fpu
00f0-00ff
ide0
14 01f0-01f7 03f6-03f6
ide1
15 0170-0177 0376-0376
keyboard
1 0060-006f
Mouse
12
PCI
0cf8-0cff 4000-40ff 4400-44ff
pic1
0020-003f
pic2
00a0-00bf
Realtek
2000-20ff
serial
02f8-02ff 03f8-03ff
timer
0 0040-005f
usb-ohci
10
vga+
03c0-03df
VIA
2400-247f
Dans le cas où le device eth0 est absent il faut alors vérifier :
- la présence d'un module correspondant à la carte comme par exemple :
/lib/modules/2.4.21/kernel/drivers/net/8139too.o
Page 5/58
Jean-Paul Coulon
(ceci attestant qu'un module a été compilé pour le noyau en service).
- que le fichier /etc/modules.conf possède bien une correspondance comme :
alias eth0 8139too
- que le module est bien chargé via la commande lsmod.
L'absence éventuelle du module oblige alors à faire une nouvelle compilation du noyau avec cette
option. (voir module compilation du noyau).
2.2 Les interfaces.
La commande ifconfig exécutée sans argument permet de consulter le paramétrage des interfaces
réseau déjà configurées. Accompagnée d'arguments, elle déclare de nouvelles interfaces qui auront :
un nom (eth0 pour carte ethernet 0, ppp0 pour ligne point-to-point 0...)
une adresse IP
une adresse de masque réseau
une adresse de diffusion
un indicateur marche/arrêt (up, down)
exemple de consultation :
root@zephyr tmp]# ifconfig
eth0
Lien encap:Ethernet HWaddr 00:00:E2:8D:20:1A
inet adr:82.225.146.47 Bcast:82.225.146.255 Masque:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17660 errors:0 dropped:0 overruns:0 frame:0
TX packets:14353 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
RX bytes:21358589 (20.3 Mb) TX bytes:1599038 (1.5 Mb)
Interruption:11 Adresse de base:0xd000
lo
Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:29 (29.0 b) TX bytes:29 (29.0 b)
exemple de paramétrage de la première interface ethernet :
#ifconfig eth0 down
#ifconfig eth0 192.168.3.45 netmask 255.255.255.0 broadcast 192.168.3.255 up
Si les paramètres désirés étaient les mêmes qu'auparavant, la commande aurait put être :
#ifconfig eth0 up
note: il est possible d'affecter plusieurs adresses IP à une même interface réseau. On parle alors d'IPaliasing, le nom de l'interface sera suffixée par ':x' où x sera un chiffre donnant l'ordre de l'alias (eth0:0,
eth0:1...eth0:N).
2.3 La table de routage système.
A chaque émission de paquets IP un aiguillage ou routage est opéré pour savoir quelle route nécessaire
emprunter pour arriver à destination.
Le routage peut se résumer aux opérations suivantes dans le cas simple d'une émission de paquet :
Page 6/58
Jean-Paul Coulon
•
L'adresse de destination du paquet va être comparée à chaque route exprimée dans la table de
routage système.
•
Dès qu'il y aura correspondance d'adresses le paquet sera expédié, dans la négative la route
suivante est envisagée.
•
Si aucune route ne correspond, une route par défaut est prise qui aiguille en général le paquet sur
le routeur le plus proche. Ce dernier aura peut-être une route correspondante, dans la négative il
passera le paquet à son routeur le plus proche.
La table de routage système est implantée dans le noyau et se consulte ou se modifie via la commande
route .
Ex de consultation:
[root@zephyr tmp]# route
Table de routage IP du noyau
Destination Passerelle
82.225.146.0 *
127.0.0.0
*
default
82.225.146.254
Genmask
255.255.255.0
255.0.0.0
0.0.0.0
Indic Metric
U
0
U
0
UG 0
Ref
0
0
0
Use Iface
0 eth0
0 lo
0 eth0
Ex :
Pour ajouter une route à tous les paquets IP d'adresse de destination 192.168.1.xxx via eth0.
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
Pour ajouter une route par défaut (dernière de la table) sur une passerelle d'adresse 192.168.1.1 via eth0.
# route add default gw 192.168.1.1 eth0
note: la commande route complétera, dans le mesure du possible, les arguments manquants lors d'une
adjonction de route. Pour lever toute ambiguïté une destruction de route se fera obligatoirement avec
tous les arguments de la route.
3 Fichiers de configuration et scripts.
3.1 Généralités.
Des fichier-paramètres du nom de chaque interface vont permettre de garder les paramètres réseau en
mémoire. Des scripts exécutés à chaque démarrage vont permettre le paramétrage automatique des
interfaces quand il y aura présence de fichier-paramètres dans le même répertoire :
/etc/sysconfig/network-scripts
3.2 Les paramètres globaux.
Il sont décrits dans le fichier /etc/sysconfig/network sous la forme de variables dont le nom est
exprimé en majuscule et initialisées selon les règles syntaxiques du shell. On y trouve par exemple :
[coulon@zephyr coulon]$ cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=zephyr
NISDOMAIN=iut
3.3 Les paramètres par interface.
Il existe un fichier de configuration par interface nommé ifcfg-XXX (XXX représentant le nom de
l'interface). Ces fichiers sont dans le répertoire /etc/sysconfig/network-scripts. On trouvera
Page 7/58
Jean-Paul Coulon
par exemple pour l'interface eth0 les variables ou paramètres suivants :
[coulon@zephyr coulon]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
#IPADDR=196.20.12.100
#NETMASK=255.255.255.0
#GATEWAY=192.168.1.254
3.4 Validation des paramètres réseaux.
Les contenus de ces fichiers seront pris en compte lors du démarrage via le script ifup se trouvant dans
/etc/sysconfig/network-scripts. L'administrateur devra également utiliser ce script pour
prendre en compte des nouveaux paramètres différents de celui du dernier démarrage. Le script ifdown
existe également pour l'opération inverse.
Ex d'une séquence de modification des paramètres réseau concernant les nomIP et addrIP.
Edition et modification du fichier /etc/sysconfig/network
#hostname xxxxx (changement de nomIP en ligne de commande)
Edition et modification du fichier /etc/sysconfig/network-scripts/ifcfg-eth0
#ifcfg eth0 stop (arrêt de paramètres mais interface encore visible par ifconfig ).
#ifup eth0
#ifconfig (pour vérification)
3.5 Spécificités Fedora.
Le paramétrage manuelle n'est rendu possible que si aucun programme externe ne gère les
configurations réseaux. Fedora utilise aujourd'hui les utilitaires suivants :
- NetworkManager
- le daemon dhcdbd (bus de messages inter-applicatif)
- le daemon dhclient (daemon client de gestion de bail avec un serveur dhcp)
Ces trois programmes sont à stopper afin qu'il n'y est aucun parasite dans un paramétrage manuel.
Page 8/58
Jean-Paul Coulon
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP).
1 Généralités.
Le protocole DHCP DynamicHostConfigurationProtocol a pour fonction d'attribuer dynamiquement à une
machine cliente ses paramètres IP, et de manière facultative lui fournir le nom d'un fichier à charger en
mémoire pour exécution. Cette dernière fonction étant rendue possible par l'implémentation du protocole
BOOTP qui utilisera la plupart du temps TFTP pour aller chercher par réseau un noyau ou toute autre
application de démarrage (ex outil de déploiement d'image disque). DHCP utilise le protocole réseau UDP
dit non-connecté qui travaille en mode datagramme.
Les requêtes de ce client sont expédiées en mode diffusion sans savoir à quel serveur elles sont adressées.
Le premier serveur DHCP actif répondra ou non, en conformité à son paramétrage.
2 La configuration du client.
2.1 Le service dhcp.
Le client est un daemon dhclient installé avec le package rpm suivant pour une version RedHat :
[root@zephyr root]# rpm -qil dhclient
Name
: dhclient
Relocations: (not relocatable)
Version : 3.0.4
Vendor: Red Hat, Inc.
Release : 21.fc6
Build Date: lun 11 sep 2006 19:11:59 CEST
Install Date: jeu 07 déc 2006 10:02:57 CET
Build Host: hs20-bc1-7.build.redhat.com
Group
: System Environment/Base
Source RPM: dhcp-3.0.4-21.fc6.src.rpm
Size
: 535643
License: distributable
Signature : DSA/SHA1, mer 04 oct 2006 03:13:47 CEST, Key ID b44269d04f2a6fd2
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL
: http://isc.org/products/DHCP/
Summary : Fournit le démon client ISC DHCP dhclient et dhclient-script .
Description :
DHCP (Dynamic Host Configuration Protocol) est un protocole permettant à des périphériques individuels sur
un réseau IP d'obtenir leurs propres informations de configuration de réseau (adresse IP, masque de sousréseau, adresse de diffusion, etc.) à partir d'un serveur DHCP. Le but général de DHCP est de faciliter
l'administration d'un grand réseau.
Installez un service DHCP (ou un agent relais) ainsi qu'un démon client DHCP sur vos clients si vous voulez
utiliser DHCP sur votre réseau. Le paquetage dhclient fournit les démons clients ISC DHCP.
/sbin/dhclient
/sbin/dhclient-script
/usr/share/doc/dhclient-3.0.4
/usr/share/doc/dhclient-3.0.4/dhclient.conf.sample
/usr/share/man/man5/dhclient-eval.5.gz
/usr/share/man/man5/dhclient-options.5.gz
/usr/share/man/man5/dhclient.conf.5.gz
/usr/share/man/man5/dhclient.leases.5.gz
/usr/share/man/man8/dhclient-script.8.gz
/usr/share/man/man8/dhclient.8.gz
/var/lib/dhclient
S'il est validé par l'administrateur, le protocole dhcp sera utilisé pour renseigner les paramètres IP des
interfaces réseau concernées au démarrage et le daemon n'a plus à intervenir ensuite dans le cas le plus
courant. Il est néanmoins possible de l'utiliser par la ligne de commande pour faire des tests ou bien le
relancer (voir man dhclient, /sbin/dhclient-script et /sbin/dhclient)
2.2 Les fichiers paramètres.
Ces fichiers sont dans le répertoire /etc/sysconfig/network-scripts (voir 3.3 du module14),
Page 9/58
Jean-Paul Coulon
il en existe un par interface réseau (la variable BOOTPROTO est à initialiser à dhcp).
3 La configuration du serveur.
La configuration est faite essentiellement dans le fichier /etc/dhcpd.conf.
Le fichier /etc/sysconfig/dhcpd peut contenir des options de démarrage du daemon via la variable
DHCPARGS. Le fichier /etc/dhcpd.leases doit exister, même vide, pour autoriser le lancement du
daemon via le script de démarrage SystemV.
Note: Le noyau doit avoir été compilé avec l'option multicast en ce qui concerne les interfaces réseau. A
vérifier avec la commande ifconfig.
3.1 Les modes de distribution d'adresses.
Le serveur dhcp a la possibilité selon sa configuration de travailler selon trois modes :
-dynamique; les adresses sont distribuées sur leur disponibilité. Un fichier de bail (lease) gère la
possibilité de fournir les adresses en fonction d'un intervalle déclaré par l'administrateur ainsi qu'un
temps imparti par défaut et un maximum. Ce délai dépasser un nouveau bail est déclaré s'il y a une
adresse libre.
-automatique; le principe est le même mais l'adresse est attribuée de façon permanente (la valeur de
lease-time réservée OxFFFFFFFF est utilisée).
-manuel; il s'agit de faire correspondre par une clé une requête cliente et le paramétrage du serveur. On
utilise le plus souvent l'adresseIP et l'adresseMAC(physique) de l'interface réseau du client.
3.2 Le fichier /etc/dhcp/dhcpd.conf.
Ce fichier n'étant pas toujours créer à l'installation via le package rpm, une copie peut être faite à partir
du fichier d'exemple comprenant le mot sample dans un sous-répertoire de /usr/share/doc où se
trouve les pages de man ainsi que les documentations déposées par les packages rpm.
On remarque dans l'exemple suivant les trois parties distinctes:
-les paramètres globaux
-la déclaration d'intervalle d'adresses
-la réservation pour l'host prof en distribution manuelle.
# Exemple de /etc/dhcp/dhcpd.conf
default-lease-time 86400; #24heures hors-demande autre par le client
max-lease-time 604800; #7 jours
option subnet-mask 255.255.255.0; # 5 paramètres attribués ...
option broadcast-address 192.168.1.255; # ...par défaut...
option routers 192.168.1.254; #...en l'absence de requêtes...
option domain-name-servers 192.168.1.1, 192.168.1.2; #...clientes...
option domain-name "mondomaine.org"; # ...précises.
# Exemple d'adressage par intervalle (ici de 192.168.1.10 à ....100 de et ...150 à ....200)
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}
Page 10/58
Jean-Paul Coulon
# Exemple d'adressage manuel pour l'hôte prof).
host prof {
hardware ethernet 00:00:88:88:aa:aa;
fixed-address 192.168.32.13;
}
Note de syntaxe: elle est du type langage C avec ; pour fin de ligne et accolades pour les blocs.
Page 11/58
Jean-Paul Coulon
MODULE 16 : Le filtrage IP par iptables.
1 Généralités.
Le filtrage de paquets est l'opération qui revient à observer les en-têtes IP passant devant une interface
réseau et de décider de leur sort (ou cible) qui peut être :
-un DROP (le paquet est considéré comme n'ayant jamais existé).
-un ACCEPT (le paquet est pris en compte).
-autres cibles plus ou moins complexes comme LOG, REJECT, RETURN, REDIRECT, SNAT, DNAT,
MASQUERADE...
2 Les buts du filtrage IP.
Le Contrôle.
Utilisé généralement en sortie. On décide d'autoriser ou non l'accès à certaines adresses ou sites à partir du
réseau filtré.
La sécurité.
Utilisé généralement en entrée. On décide d'autoriser ou non certaines adresses à utiliser certains ports ou
machines sur son réseau filtré.
Contrôle de normalité.
On veut détecter les anormalités émanant de son réseau filtré pour éviter un trafic ou des collisions trop
importantes.
3 Historique des versions.
1994
1998
1999
premier filtrage IP sur les noyau 1.1, c'est le portage de ipfw du système BSD Unix.
implémentation au noyau 2.2 du filtrage par chaînes avec ipchains.
le noyau 2.4 intègre iptables qui est toujours en vigueur.
4 Les pré-requis systèmes.
Le noyau doit être compilé avec l'option d'infrastructure netfilter composée de différents modules comme
celui d'iptables.
5 Le principe du filtrage iptables à l'aide de la table filter.
Le noyau contient par défaut trois listes de règles qui vont être lues séquentiellement et mises en
correspondance avec les paquets filtrés. Ces listes sont appelées des chaînes de firewall et portent les noms
INPUT, OUTPUT et FORWARD ( fig.1).
Page 12/58
Jean-Paul Coulon
Entrée d'un
paquet.
( fig. 1 )
Décision de
routage
Emission du
paquet.
FORWARD
OUTPUT
INPUT
Processus locaux
Chaque chaîne entourée d'un cercle est composée d'une suite de règles.
Quand un paquet se présente devant une chaîne son en-tête est examinée ce qui va déterminer sa cible qui sera
le plus simplement DROP ou ACCEPT.
Par sécurité une chaîne se termine par une règle par défaut ayant pour cible un DROP.
6 Algorithme du filtrage.
A la réception du paquet, le noyau décide par sa table de routage standard de la destination
hors-filtrage du paquet ;
•
soit le paquet est destiné à la machine filtrante et il est orienté vers la chaîne INPUT, puis
filtré pour être ciblé sur DROP ou ACCEPT.
•
soit le paquet est dirigé sur la chaîne de FORWARD. Cela implique que le routage ou
forwarding est autorisé sur cette machine. Le cas échéant, il passe les règles de la chaîne
FORWARD et suit sa cible correspondante. Dans le cas d'une cible ACCEPT, le paquet est
alors émis.
A l'émission du paquet émanant de la machine filtrante, il est envoyé à la chaîne OUTPUT
puis émis dans le cas d'une correspondance sur une règle ciblée en ACCEPT.
En plus de la table filter il existe les tables NAT et MANGLE. La première gère les
translations d'adresses et contient par défaut les chaînes prerouting, postrouting et output.
La deuxième permet le marquage de paquets entrant ou émis dans le but de faire des
traitements spécifiques sur ces paquets. Elle utilise ses chaînes input, output, prerouting,
postrouting et forward.
7 Utilisation d'iptables.
7.1 Manipulation des chaînes.
iptables -N
iptables -X
iptables -P
iptables -L
iptables -F
iptables -Z
Nouvelle chaîne.
Effacer une chaîne vide.
Changer la règle par défaut pour une chaîne de départ.
Lister les règles.
Détruire (flush)les règles d'une chaîne.
Mettre à zéro les compteurs de bits et de paquet d'une chaîne.
Page 13/58
Jean-Paul Coulon
7.2 Manipulation des règles.
iptables -A
iptables -I
iptables -R
iptables -D
Ajouter une nouvelle règle à la chaîne.
Insérer une nouvelle règle à une position dans la chaîne.
Remplacer une règle à une position dans la chaîne.
Supprimer une règle à une position dans la chaîne.
8 Commandes systèmes.
8.1 Gestion des modules du noyau.
Les modules sont des fonctionnalités supplémentaire au noyau qui ont été compilés à la demande de
l'utilisateur comme option modulaire. Ces modules sont normalement chargés automatiquement à la
demande des programmes nécessitant un service supplémentaire. Il est possible faire ces
(dé)chargements de façon manuelle.
insmod nom-de-module
lsmod
rmmod nom-de-module
modprobe -l
attache manuellement le module au noyau.
donne la liste des modules chargés.
désinstalle manuellement un module du noyau.
Liste tous les modules pouvant être chargés.
8.2 Mise en service du forwarding.
Le routage par forwardind est généralement désactivé par souci de sécurité, il faut alors le valider
dynamiquement.
echo 1 > /proc/sys/net/ipv4/ip_forward
ou bien statiquement et pris en compte après un redémarrage.
net.ipv4.ip_forward=1 (dans le fichier /etc/sysctl.conf).
8.3 Sauvegarde des règles.
L'administrateur doit gérer le stockage de ces règles au risque de les perdre sur un redémarrage. Les
commandes iptables-save, iptables-restore sont dédiées à cela.
L'usage des administrateurs est d'ajouter un script firewall dans /etc/init.d pour systématiser le
chargement des règles au démarrage de la machine.
9 Exemples de règles.
Ex1: On désire tester l'installation des modules iptables et son fonctionnement.
On teste le fonctionnement normal.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.076 ms
--- 127.0.0.1 ping statistics --1 packets transmitted, 1 received, 0% loss, time 0ms
Page 14/58
Jean-Paul Coulon
On créé une nouvelle règle pour la chaîne INPUT qui détruit les paquets d'adresse source
locale pour le protocole icmp.
# iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
On teste pour constater que le paquet est bien transmis et non reçu.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.076 ms
--- 127.0.0.1 ping statistics --1 packets transmitted, 0 received, 0% loss, time 0ms
Ex2: On désire partager à partir d'un LAN une machine à deux interfaces réseaux dont l'une
est connectée via un modem (ppp0) sur internet. On veut protéger le LAN des intrusions tout
en permettant un accès en sortie et en entrée quand il s'agit de la réponse d'une requête
émanant du LAN.
On va utiliser un module permettant le suivi de connection par ''états'' nommé conntrack.
#insmod ip_conntrack
#insmod ip_conntrack_ftp
On crée une nouvelle chaîne appelé block pour y mettre des règles qui seront respecter dans
les cas de l'INPUT et du FORWARD, cela évite de les écrire deux fois.
#iptables -N block
On crée une règle qui laissera les paquets passer uniquement dans le cas d'une liaison déjà
établie et dont les adresses dst et src sont en relation avec cette liaison.
#iptables -A block -m state –state ESTABLISHED,RELATED -j ACCEPT
On crée une règle qui laissera passer les paquets d'une nouvelle liaison uniquement si sa
demande provient de l'interface concernée par le LAN.
#iptables -A block -m state –state NEW -i ! ppp0 -j ACCEPT
On renvoie les paquets se présentant devant les chaînes INPUT et FORWARD sur la chaîne block.
#iptables -A INPUT -j block
#iptables -A FORWARD -j block
Le schéma de filtrage devient alors celui de la figure 2.
Page 15/58
Jean-Paul Coulon
Entrée d'un
paquet.
( fig. 2 )
Décision de
routage
INPUT
Emission du
paquet.
FORWARD
block
Processus locaux
Page 16/58
OUTPUT
Jean-Paul Coulon
MODULE 17 : La centralisation des services réseaux par xinetd.
1 Généralités.
Le daemon xinetd appelé également super-daemon va s'interposer entre les requêtes réseaux et les serveurs
concernés du type telnet, ftp, ssh, http...
Il va considérer la requête et pouvoir y réagir de plusieurs façons :
-autoriser ou interdire l'accès au serveur.
-lancer le serveur concerné et lui passer la requête.
-changer le port de la requête à l'insu du client.
-journaliser la communication.
Ex mode autonome ou « stand-alone ».
serveur ssh, ftp, telnet
commandes shell clientes:
ssh
ftp
telnet
adresse ip serveur + No de port
sshd
vsftpd
in.telnetd
réponses
Ex mode centralisé par xinetd.
serveur ssh, ftp, telnet
commandes shell clientes:
adresse ip serveur + No de port
ssh
ftp
telnet
xinetd
sshd
arrêt/marches des
« sous-daemons » par
xinetd
vsftpd
in.telnetd
2 Le contrôle d'accès aux services et le tcp-wrapper.
2.1 Généralités
Les fonctions du tcp-wrapper (regroupeur) sont intégrées dans la librairie libwrap.a qui est installée via
le package rpm tcp_wrappers-libs. L'analyse des requêtes se fera par le programme tcpd qui lira à chaque
appel les fichiers ou listes de contrôles hosts.allow et hosts.deny.
2.2 Les listes de contrôles hosts.deny et hosts.allow.
Ces deux listes de contrôles sont lues à chaque requête réseau. Le fichier hosts.allow est prioritaire
sur hosts.deny et sera consulté en second lieu, si deux règles sont contradictoires la dernière lue sera
prise en vigueur.
Leurs syntaxes est identiques, il y a une règle par ligne comportant deux champs obligatoires et un
troisième facultatif, le séparateur de champs est le caractère '':''.
Page 17/58
Jean-Paul Coulon
<liste_démons> : <liste_clients>[ : spawn <commande_shell> &]
liste_démons:
liste de deamon(s) séparé(s) par un espace.
liste_clients:
adresse(s) IP, noms IP, adresse de domaine (192.168.20. ou 196.20.12.0/24 ou
196.20.12.*, ou 196.20.12.3? pour signifier de 196.20.12.30-39).
commande_shell:
n'importe quel exécutable disponible sur la ligne de commande, appelée par la
commande spawn et lancer en background (&).
Exemple d'une règle du fichier hosts.deny concernant le daemon in.telnetd :
in.telnetd: 196.20.12. : spawn (/bin/echo $(date) %u >> /var/log/tcpWrapper-telnet)
&
A chaque refus de connection par telnet sera stockés, dans un fichier de journalisation, la date courante
et le nom de login.
3 Le super-daemon xinetd.
3.1 Généralités.
Xinetd est qualifié de super-daemon car il va permettre le contrôle de daemons de services réseaux. Il va
remplir les fonctions suivantes :
-arrêt/marche des daemons déclenchés par les requêtes clientes adressées aux services gérés.
-contrôle des demandes en liaison avec le tcpWrapper.
-prise d'information et journalisation supplémentaire à tcpWrapper.
-personnalisation de connection par gestion des nombres d'instances de services en cours.
-ré-acheminement de port entre le client et le daemon géré.
3.2 Configuration du daemon xinetd.
Le daemon xinetd est mis en fonction par son script systemV respectif se trouvant dans
/etc/init.d. Ses paramètres se trouvent dans le fichier /etc/xinetd.conf qui lui-même inclut
les fichiers se trouvant dans son répertoire respectif ; /etc/xinetd.d. Ce répertoire contient un
fichier de paramètres par service géré.
Ex de fichier /etc/xinetd.d/wu-ftpd chargé de la gestion du service ftp distribué par
l'Université de Washington (wu-ftp) :
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
#
normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait
= no
user
= root
server
= /usr/sbin/in.ftpd
server_args
= -l -a
log_on_success
+= DURATION
nice
= 10
}
Page 18/58
Jean-Paul Coulon
Note: un manuel est dédié à xinetd.conf qui explicite toutes les options possibles. Les plus sensibles à
l'installation seront disable (no pour valider le service) et server (le path absolu du daemon du service).
Le service xinetd doit être relancé pour prendre en compte les changements de paramètres.
3.3 Liaison et ré-acheminement de port.
La liaison permet de relier un service à une interface spécifiée et à nulle autre même en présence de
plusieurs adresses IP sur une machine. Un service ne sera disponible qu'a partir d'une seule adresse
spécifiée par l'option bind.
Le ré-acheminement redirige une requête cliente sur un port et/ou une adresse IP différente(s) de la
demande sans que cela soit visible à l'utilisateur. L'option redirect initialisée avec une adresse IP et un
numéro de port va traiter le ré-acheminement.
Ex assurant que le service telnet est lié uniquement à l'adresseIP externe 129.102.8.20. Toute demande
faites à cette adresse est ré-acheminée vers une deuxième interface réseau interne d'adresse 10.0.0.10
pouvant passer par un firewall. L'utilisateur ou le programme auront l'illusion de travailler directement
avec la machine 129.102.8.20.
service telnet
{
socket_type
= stream
wait
= yes
server
= /usr/sbin/in.telnetd
log_on_success
+= DURATION USERID
log_on_failure
+= USERID
bind
= 129.102.8.20
redirect = 10.0.0.10 2323
}
Page 19/58
Jean-Paul Coulon
MODULE 18 : L'impression.
1 Les principaux serveurs d'impression.
1.1 Généralités.
Le serveur d'impression le plus répandu sur Unix est lpd (LinePrinterDaemon) qui tend a être remplacé
par cups (CommonUnixPrintingSystrem-deamon) qui reprend les grands principes de son prédécesseur en
y ajoutant un confort d'administration dont une interface graphique de paramétrage.
Cups implémente un autre daemon nommé cups-lpd qui le rend compatible aux requêtes clientes de type
lpd.
Cups et lpd sont deux serveurs pouvant être paramétrés pour gérer l'impression sur la machine où ils sont
installés. On peut également rédiriger les impressions sur une autre machine appelée serveur
d'impression qui elle même possèdera l'un des deux daemons en service.
1.2 Installation.
Les deux produits sont disponibles au format rpm en ce qui concerne une installation RedHat ou Fedora.
Leurs contrôles et mises en fonction respecte les niveaux de démarrage du SystemV (voir module 24).
2 Le daemon LPD.
2.1 paramétrage.
Le daemon lpd utilise essentiellement le fichier /etc/printcap qui contient une ligne par imprimante
déclarée. On y trouve en autre le nom de l'imprimante ou ses alias, l'adresseIP, les noms des fichiers
logs, le filtre d'impression.
2.2 L'organisation dans l'arborescence Unix.
Chaque imprimante déclarée possède un répertoire de file d'attente respectif à son propre nom. On
trouvera par exemple les répertoires, /var/spool/lpd/lp1 et /var/spool/lpd/lp2 dans le
cas de 2 imprimantes déclarées sur un système.
2.3 Principe.
LPD scrute ses répertoires spooler en permanence dans le but de voir si un nouveau job d'impression y a
été placé par la commande lpr. Le cas échéant il utilise les paramètres issus d'/etc/printcap pour
savoir à quel périphérique passer le job une fois qu'il aura été traduit dans un langage compatible avec
l'imprimante. Il s'agit la plupart du temps de fichiers postscripts.
2.4 Les commandes d'impression.
lpr
$lpr -Plp1 /etc/passwd (pour imprimer le fichier /etc/passwd sur l'imprimante lp1).
lpq
$lpq (pour connaître l'état de la file d'attente par défaut, non spécifiée par l'option -P).
lprm
$lprm 3 (pour enlever le 3ème job en file d'attente).
lpstat
$lpstat -Plp1 (pour obtenir le status de l'imprimante nommée lp1).
3 Le daemon CUPS.
3.1 paramétrage.
Page 20/58
Jean-Paul Coulon
Les imprimantes sont paramétrables via l'interface graphique disponible par un client http comme
netscape. L'adresse URL est celle de la machine courante en y spécifiant l'utilisation du port 631.
(ex http://localhost:631).Les login et password de l'utilisateur root seront nécessaires.
3.2 L'organisation dans l'arborescence Unix.
Elle est basée sur la même ergonomie que lpd.
3.3 Principe.
Le daemon cups utilise les fichiers PPD (PostscriptPrinterDescription) propre à chaque type
d'imprimante ce qui permet d'en utiliser toutes les spécificités sans difficulté (recto-verso, format, type
de bacs de chargement...).
3.4 Les commandes.
Toutes les commandes lpr seront compatibles avec cups. La commande lpoption permet d'utiliser les
options de l'imprimante sans passer par l'interface graphique.
Page 21/58
Jean-Paul Coulon
4 Remarques.
L'interface graphique printtool est disponible également sur RedHat pour le paramétrage d'imprimantes.
Page 22/58
Jean-Paul Coulon
MODULE 19 : Le partage de fichier par NFS.
1 Généralités.
•
Fonctionalités.
Le service NFS NetworkFileSystem permet le partage de fichiers dans une structure client-serveur de
machines Unix ou Linux. Cela va permettre de faire des opérations de montage de FileSystem via un réseau
TCP/IP de la même manière qu'il est possible de le faire localement. Le résultat d'un montage NFS se
concrétisera donc par l'adjonction d'une arborescence externe rattachée à un point de montage de
l'arborescence locale. Après un tel montage, l'accès au fichiers locaux ou distants sera transparent.
L'administration des montages NFS est contrôlée du point de vue des adresses IP.
•
Historique.
Ce protocole développé par la société SUN vers 1980 est devenu rapidement un standard Unix. On utilise
aujourd'hui les versions 2 et 3 compatibles entre elles, la version 3 est utilisée par défaut lors d'une demande
de connection client-serveur.
•
Implémentation.
NFS est géré par plusieurs daemons communiquant avec le noyau. Ce dernier doit avoir été compilé avec
les options respectives ce qui est fait par défaut dans la plupart des cas. Les archives RPM concernant
rpcbind et NFS doivent également être présentes.
2 RPC et portIP.
•
RPC RemoteProcedureCall.
Les RPC sont un ensemble d'appels de procédures à distance permettant la transparence d'utilisation locale
ou distante comme NFS pour le montage de FS. Les RPC œuvrent au niveau de la couche session du
modèle OSI.
•
Map RPC/PortIP
Le service systemV rpcbind et daemon de même nom travaille à l'aide d'une carte de correspondance entre
les numéros de port IP (voir /etc/services) et les numéros de programmes RPC. rpcbind stocke, aux
lancements des processus utilisant les RPC, le numéro de programme RPC et le numéro de service IP qu'ils
utilisent. Ainsi, chaque requête émanant d'un client en possession d'un numéro de programme passe par
rpcbind qui lui indique son numéro de port IP à utiliser.
La carte d'rpcbind est à rafraîchissement dynamique à condition qu'il soit lancé avant les services RPC,
cette chronologie est impérative dans le cas d'NFS par exemple.
La commande rpcinfo permet de voir la carte de correspondance de rpcbind.
[root@zephyr root]# rpcinfo -p localhost
program no_version protocole no_port
100000
2 tcp
111 portmapper
100000
2 udp
111 portmapper
100011
1 udp
807 rquotad
100011
2 udp
807 rquotad
100011
1 tcp
810 rquotad
100011
2 tcp
810 rquotad
100005
1 udp 32768 mountd
100005
1 tcp 34322 mountd
100005
2 udp 32768 mountd
Page 23/58
Jean-Paul Coulon
100005
2 tcp 34322 mountd
100005
3 udp 32768 mountd
100005
3 tcp 34322 mountd
100003
2 udp 2049 nfs
100021
1 udp 32770 nlockmgr
100021
3 udp 32770 nlockmgr
3 Paramétrage d'un serveur NFS.
3.1 Structure du fichier /etc/exports (Extrait de la page de man exports).
Le fichier /etc/exports sert de liste de contrôle d'accès pour les systèmes de fichiers à exporter aux
clients NFS. Il est utilisé à la fois par le daemon de montage NFS mountd et par le daemon serveur
NFS nfsd.
Chaque ligne est composée de deux champs minimum. Le premier est le nom du répertoire exporté.
Tous les champs suivants représentent une liste de hosts séparés par un espace dont les options sont
exprimées entre parenthèses. Les lignes blanches sont ignorées, et un # indique un commentaire
s'étendant jusqu'à la fin de la ligne.
exemple de fichier /etc/exports :
# repertoire liste-machines (liste-options)
/home/user1 host1(ro) host2(rw)
/usr/src
host4(ro) host2(ro)
/var/www/html *.uvsq.fr (ro) host2 (rw)
/usr/share/doc (ro)
Attention, la syntaxe prévoit l'espace ou le tab comme séparateur de champs et l'* comme host
générique. Un host non-exprimé est remplacé l'*, un droit non-exprimé est remplacé par ReadOnly.
Cet exemple met en valeur l'ambiguïté des valeurs prises par défaut dans la 2eme ligne.
/home/coulon host1(rw)
/home/coulon host1 (rw)
autres.
#export pour host1 en mode lect./ecrit.
#export pour host1 en lect. par défaut et lect./ecrit. pour tous les
Toute modification du fichier /etc/exports devra être suivie de la commande de validation :
# exportfs -a
La vérification de ces paramètres peut être faites avec les commandes exportfs ou showmount. Ces
commandes nécessitent que le serveur NFS soit lancé. Dans la cas contraire, rpcbind signalera que ces
commandes font appels à des programmes qu'il n'a pas mis dans sa carte.
La question des pouvoirs de l'utilisateur root sur un FS distant monté est considérée par l'option
root_squash qui est prise par défaut. A l'inverse l'option no_root_squash est à stipuler et donne tous les
droits à l'utilisateur root sur le FS distant monté.
3.2 Lancement de rcpbind et de NFS.
Leur lancement se fait via les scripts de démarrage systemV standards.
# service rpcbind start
il lance le daemon rpcbind
# service nfs start
Page 24/58
Jean-Paul Coulon
il lance les daemons rpc.mountd, nfsd et rpc.rquotad.
rpcbind: correspondance numRPC/num_port_IP.
rpc.rquotad: quotas utilisateurs du serveur.
rpc.mountd: réception des demandes de montage et comparaisons avec les exports du serveur.
nfsd: dialogue entre le noyau et les requêtes dynamiques distantes.
4 paramétrage du client NFS.
Les étapes de mise en œuvre d'un client sont les suivantes :
-lancer rpcbind.
-prévoir un point de montage dans l'arborescence (dans /mnt ou autre).
-monter le répertoire distant (ex: # mount -t nfs serveur:/home/httpd/html /mnt/nfs ).
note: ajouter '' -o nfsvers=2 '' au mount à partir de fedora core 2.
5 Montage au démarrage et optimisation.
5.1 Montage au démarrage.
Le fichier /etc/fstab est prêt, au même titre que pour les FS locaux, à recevoir une ligne
correspondant à un FS distant. On ajoute alors « nomIP: » devant le répertoire à importer.
5.2 Montage optimisé ou automontage.
Le montage par /etc/fstab possède l'inconvénient d'occuper le réseau, le serveur, et le client même
lorsque le partage de fichiers n'est pas utilisé. L'automonteur va permettre des (dé)montages dynamiques
qui seront dictés par les requêtes d'accès aux fichiers et soulager ainsi cette charge inutile. Un
déplacement dans l'arborescence ou l'ouverture d'un fichier sont causes d'automontages dès qu'il s'agit
d'aller vers un FS distant monté.
On peut prendre comme exemple une machine démarrant en niveau 5 sans montage NFS tant qu'aucun
login n'a été effectué. Le login d'un utilisateur entraine un accès à son compte qui est alors monté à ce
moment précis.
Implémentation:
L'automounter se lance à partir du script /etc/init.d/autofs qui prend sa configuration dans le
fichier /etc/home.master.
Ce fichier contient une entrée par ligne à deux champs ;
<point de montage> <type de map>
Généralement, on utilise une map représenté par un fichier nommé auto.xxx (xxx représentant le point
de montage en question).
exemple: on désire monter le répertoire /home exporté par le serveur PC1 à chaque requête faite sur le
répertoire /home local.
/etc/auto.master :
/etc/auto.home :
/home/ auto.home
*
Page 25/58
-fstype=nfs,hard,intr PC1:/home/&
Jean-Paul Coulon
MODULE 20 : Administration et authentification centralisées par NIS.
1 Généralités.
•
Fonctionalités.
Le système NIS NetworkInformationSystem développé par SUN vers 1980 est le complément de NFS. Il
permet de centraliser les principaux fichiers d'administration utilisés généralement en local.
(/etc/hosts..passwd....group...shadow...).
•
Historique.
A sa création ce système portait le nom de YellowPages comme celui faisant référence au service des
renseignements des British-Telecom. Ces derniers étant les premiers dépositaires du nom, la justice tranchât
en leurs faveurs. A la la fin des années 80 les YellowPages informatiques avaient laissé la place au système
NIS dont la plupart des commandes continuent à être préfixées par les caractères yp.
•
Implémentation.
NIS est géré par plusieurs daemons communiquant avec le noyau. Ce dernier doit avoir été compilé avec les
options respectives ce que est fait par défaut dans la plupart des cas. Les archives RPM concernant rpcbind
et NIS doivent également être présentes.
2 Principe du client-serveur NIS.
Un serveur NIS dit primaire, possédant toutes les informations d'administration dans les fichiers standards du
répertoire /etc, transfère ces données dans des maps respectives à chaque fichier et les rend consultables par
le réseau. Ces maps sont organisées de la même façon qu'un système de base de données et garantissent
intégrité et disponibilité des données.
Par souci de fiabilité, il existe des serveurs secondaires possédant également toutes les données. Les requêtes
sont de type broadcast et rien n'assure à l'avance qu'une requête soit adressée au serveur principal ou à un autre.
Les serveurs secondaires sont des serveurs recevant des mises à jour régulières des maps mais qui n'ont pas la
structure principale dans /etc qui a servi à les créer. Les ajouts/retraits de données se font uniquement sur le
serveur principal.
Le client possède les outils nécessaires à la consultation des maps en envoyant une requête de type broadcast.
Pour ce faire, il doit auparavant se déclarer faisant partie d'un domaine identique à celui des serveurs. Ce
domaine n'est lié en rien au domaine IP.
3 Paramétrage du serveur NIS.
3.1 Les pré-requis.
Les packages rpcbind et ypserv doivent être installés au préalable. ypserv aura placé les daemons ypserv
et rpc.yppasswd dans /usr/bin et les scripts de démarrage respectifs dans /etc/init.d (ypserv,
yppasswd).
Le service rpcbind doit être lancé puis ensuite ypserv et yppasswd.
ypserv: serveur NIS.
rpc.yppasswd: daemon ayant en charge via la commande yppasswd, de passer au serveur un nouveau mot
de passe entré sur un client NIS. Il y aura déclenchement automatique de la reconstruction des maps
(update) ainsi qu'un envoi de mise à jour au serveur secondaire éventuel (push).
3.2 Le domaine.
Il faut renseigner le fichier des paramètres réseaux globaux qui est /etc/sysconfig/network pour
Page 26/58
Jean-Paul Coulon
y ajouter la ligne suivante:
NISDOMAIN=xxx (où xxx est une suite de caractères représentant le domaine associé au service NIS).
Ce paramètre sera pris en compte après redémarrage ou dynamiquement par la commande
nisdomainname.
La relance du serveur doit retourner le nom de domaine.
3.3 Déclaration des hosts autorisés.
Ils sont à définir dans le fichier /var/yp/securenets :
255.0.0.0 127.0.0.0
#pour le localhost au cas où la machine serait également cliente NIS.
255.255.255.0 192.168.1.0 # pour tout le domaine concerné.
3.4 Choix des fichiers d'administration à gérer par le serveur NIS.
Il s'agit de choisir les fichiers placés dans /etc/ que l'on désire divulguer et donc traduire en maps
NIS.
Notes sur makefile :
La traduction, au même titre qu'une compilation, va être exécutée via la commande standard make et son
fichier indispensable le Makefile ( /var/yp/Makefile). Les paramètres spécifiques à chaque
traduction/compilation/action sont rattachés à une suite de mots clés suivis de leurs actions respectives.
On utilisera la commande make ainsi :
#make all ≈ #make (faire tout ce qui est contenu dans le Makefile).
#make programme1 (se placer à l'endroit du Makefile à l'étiquette programme1 et faire les actions
associées).
Il s'agit dans notre cas de trouver le mot clé all et d'y valider les actions associées aux fichiers se
trouvant dans /etc/ et que l'on désire centraliser sur le serveur.
Il suffit ensuite de lancer l'une des deux commandes :
#make
ou
#make all
On trouvera alors deux maps par fichier d'administration choisi se trouvant dans le nouveau répertoire
/var/yp/xxx (xxx est le nom du domaine NIS déclaré).
Il faut valider ensuite les hosts correspondant aux clients dont vous désirer donner la consultation des
maps possibles. Changer le fichier /etc/ypserv.conf de la façon suivante :
# Host
: Map
#
192.168.2.
192.168.2
: Security : Passwd_mangle
: passwd.byname : port
: passwd.byuid : port
: yes
: yes
Ne pas oublier de relancer le serveur.
4 paramétrage du client NIS.
4.1 Les pré-requis.
Les packages rpcbind et ypbind doivent être installés au préalable.
Le service rpcbind doit être lancé puis ensuite ypbind.
Page 27/58
Jean-Paul Coulon
4.2 Le domaine.
idem au serveur.
4.3 Configuration du client NIS.
Elle s'effectue dans le fichier /etc/yp.conf où l'on ajoute les lignes suivantes :
domain xxx(son nom) server 192.168.0.1
ypserver xxx(son nom IP).
Ne pas oublier de relancer le client NIS.
4.4 Organisation hiérarchique de l'administration.
Elle est à paramètrer dans le fichier /etc/nsswitch.conf. (NameService Switch). L'ordre de
priorité se lit de la gauche vers la droite. Chaque requête va tenter d'être traitée dans l'ordre précisé et
s'arrêter dès au premier répondant à la demande.
ex de fichier /etc/nsswitch.conf (files représentent les fichiers locaux se trouvant dans /etc) :
passwd: files nis
group:
files nis
hosts:
files nis dns
Ne pas oublier de relancer le client NIS.
5 Tests et expérimentation.
Une relation client/serveur NIS doit pouvoir se tester avec les opérations suivantes :
-login à travers un réseau en l'absence du login sur la machine locale.
-changement de mot de passe via le réseau.
Les commandes utilitaires d'un client NIS sont :
ypwhich: pour connaître le serveur auquel le client est associé.
ypcat: consultation des maps.
ypmatch: équivalent du grep avec recherche sur les maps.
yppasswd: changement du mot de passe.
Page 28/58
Jean-Paul Coulon
MODULE 21: L'annuaire LDAP.
1 Généralités.
1.1 Définition.
LDAP signifie Lightweight Directory Access Protocol qui est une version allégée de DAP qui est le
protocole d'accès au service d'annuaire X500. LDAP a été conçu pour fournir un système
d'annuaire sur TCP/IP disponible en réseau interne ou externe.
1.2 Historique, du fichier local à l'annuaire.
1970. Gestion multi-utilisateurs et LAN par fichiers; /etc/hosts, /etc/passwd, /etc/group...
1980. Gestion centralisée par NIS et YellowPages.
1984. Gestion du nommage IP par DNS (annuaire à fonctionnalité dédiée).
1988. Annuaire X500 (système lourd et non adapté à TCP/IP).
1993. Annuaire LDAP (développé comme frontal à X500).
1995. LDAP est un annuaire à part entière et dédié à TCP/IP.
1.3 Annuaire et SGBD.
Bien que proche et dérivé d'un Système de Gestion de Bases de Données, un annuaire possède ses
propres caractéristiques :
-un schéma standardisé, extensif et non dédié à une problématique propre comme sur un SGBD.
-une conception optimisée pour son utilisation principale qui est la consultation (rapide en
lecture).
-une indépendance des objets entre eux.
-une ignorance des structures de stockage des objets.
-la possibilité d'objets distribués sur plusieurs annuaires.
-l'impossibilité d'objets répartis sur plusieurs annuaires.
Un annuaire est assimilable à un dépôt de données concernant les utilisateurs du réseau mais
pouvant être étendu à n'importe quels autres besoins comme la gestion de parc machines,
inventaires...
1.4 Le protocole LDAP.
Conçu à ses débuts comme frontal à X500, LDAP fournit un service de représentation des données
et un mode de communication entre client et serveur. Il utilise quatre modèles de référence :
-un modèle d'information, qui donne les type de données de l'annuaire.
-un modèle de désignation, qui organise l'arborescence et la nomenclature des objets.
-un modèle fonctionnel, qui permet l'accès et la consultation/modification/destruction des
données.
-un modèle de sécurité, qui gère l'authentification et le cryptage.
Le protocole gère également les communications entre client et serveur, les réplications de
données pour redondance et optimisation ainsi que les liens entre annuaires permettant un accès
direct distant.
Page 29/58
Jean-Paul Coulon
L'encodage des données de type LBER (Lightweight Basic Encoding Rules) est simplifié par
l'intermédiaire d'outils (scripts) et de fichiers texte de type LDIF (Lightweight Data Interchange
Format).
2 Le modèle d'information.
C'est le modèle décrivant les données gérées par un annuaire ldap où il est question de schéma, de
classes d'objets, d'entrées et d'attributs.
2.1 Terminologie.
LDAP permet la consultation de données appelées entrées(entry) pouvant avoir une représentation
concrète (personne, machine...) ou abstraite (adresse IP, numéro de téléphone...).
Ces entrées sont composées de plusieurs objets comprenant chacun des attributs.
Un attribut est une paire mot-réservé:valeur.
La terminologie d'objet, empruntée aux langages orientés objet, est en réalité une instenciation de
la classe d'objet concernée, constituée de ses attributs et de ses propres valeurs.
2.2 Le schéma d'annuaire (Directory Schema).
C'est l'ensemble de toutes les classes d'objets et d'attributs disponibles dans l'annuaire. C'est à
grace à lui que le serveur LDAP va garantir sa structure logique. Toute création de nouvelle entrée
sera composée d'une classe existante au schéma composée de ses attributs propres.
2.3 Les attributs d'entrée.
Il existe deux sortes d'attributs, ceux réservés au serveur (system attributes) et ceux réservés à
l'utilisateur (user attributes). Il est possible de créer des attributs mais il est plus simple d'utiliser
les existants qui sont déja nombreux.
Voici une liste d'attributs utilisateur extraite du site www.commentcamarche.net, ceux marqués en
gras sont très fréquemment rencontrés.
Attribut
Description
aliasedObjectName
DN de l'objet dont celui en cours est un alias
authorityRevocationList
Liste de certificats révoqués par l'autorité chargée de les réguler
businessCategory
Activité professionnelle d'une entreprise ou d'une personne
c
Code du pays en deux lettres (respectant le standard ISO 3166)
caCertificate
Certificat de l'autorité de régulation
certificateRevocationList
Liste des certificats révoqués par l'autorité de régulation
cn
Nom de l'objet (common name)
dc
Une des parties du NomIP d'un domaine internet (domain componet)
description
Description de l'objet
DistinguishedName ou dn
Nom distingué (utilisé par d'autres attributs par héritage)
facsimileTelephoneNumber
Numéro de fax
GivenName ou gn
Prénom de la personne
houseIdentifier
Identifiant d'un batiment
initials
Initiales d'une personne
internationalSDNNumber
Numéro ISDN
l
localité de l'objet (géographique)
member
Distinguished Name des membres
name
Nom (utilisé par d'autres attributs par héritage)
Page 30/58
Jean-Paul Coulon
Attribut
Description
o
Nom de l'organisation
ObjectClass
Classe d'objets
ou
Unité organisationnelle (branche de l'organisation)
owner
Nom du propriétaire de l'objet
postalAddress
Numéro de série de l'objetAdresse postale (sans le code postal)
postaCode
Code postal
postalOfficeBox
Boîte aux lettres (postale)
presentationAddress
Adresse réseau de la présentation de l'objet (généralement une URL de la présentation )
protocolInformation
Attribut complémentaire à presentationAddress pour définir le protocole à utiliser
registeredAddress
Adresse postale pour des envois de courriers recommandés et de colis
seeAlso
DN d'objets complémentaires
serialNumber
Numéro de série de l'objet
sn
Nom de famille de la personne (surname)
st
Etat ou région (state)
street
Nom de la rue et assimiilé (boulevard, ...)
telephoneNumber
Numéro de téléphone
telexNumber
Numéro de télex
title
Titre de la personne (différent de fonction)
uid
Identifiant unique de l'objet
userCertificate
Certificat de l'utilisateur
userPassword
Mot de passe de l'utilisateur
2.4 Les classes d'objets.
Les classes d'objets ldap définissent leurs propres structures et attributs. L'instanciation
correspond alors à la création d'une entrée à partir d'une classe dont les attributs sont complétés de
leurs valeurs.
La notion d'héritage existe également. Toute classe hérite directement de sa classe ascendante
qui est unique.
Une classe peut engendrer plusieurs « sous-classes », héritant chacune de leur parent.
Il existe trois types de classes objets:
-la classe abstraite, l'héritage seul est possible, non instanciable, la classe top qui est la plus haute
hiérarchiquement est abstraite.
-la classe structurelle, elle est instanciable, la création d'entrées est donc possible.
-la classe auxiliaire, non instanciable, elle donne la possibilité d'ajouter des attributs à une classe
structurelle.
Ci-dessous, une figure représentative de l'héritage de classe :
Page 31/58
Jean-Paul Coulon
(abstract)
top
(structural)
(auxiliary)
person
companyPerson
(structural)
(structural)
organizationalPerson
residentialPerson
La classe person hérite de la classe top, tous les attributs de top sont disponibles (instaciation possible car structural).
La classe companyPerson hérite de la classe top et complète la classe person (pas d'instanciation).
Les classes organizationalPerson et residentialPerson hérite de la classe person, tous les attributs de person sont disponibles.
Une classe d'objet est déclarée par :
-un nom unique
-un OID (ObjectIdentifier) unique, c'est une suite de chiffres séparés par des points.
-des attributs obligatoires (avec mot réservé MUST).
-des attributs facultatifs (avec mot réservé MAY).
-un type (structurel, auxiliaire ou abstrait).
2.5 Le format d'échange de données LDIF.
Le format LDIF permet de représenter les données LDAP sous format texte standardisé, il est
utilisé pour afficher ou modifier les données de la base. Les fichiers sont importés ou exportés par
l'intermédiaire d'outils de type applicatif ou script. Voici l'exemple d'un fichier LDIF exporté d'un
fichier /etc/hosts d'une machine linux :
dn: cn=localhost.localdomain,ou=Hosts,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
objectClass: top
objectClass: ipHost
objectClass: device
ipHostNumber: 127.0.0.1
cn: localhost.localdomain
cn: localhost
dn: cn=precision,ou=Hosts,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
objectClass: top
objectClass: ipHost
objectClass: device
ipHostNumber: 196.53.25.200
cn: precision
Page 32/58
Jean-Paul Coulon
3 Le modèle de désignation.
C'est le modèle décrivant le nommage des objets et leur classement hiérarchique sous la forme d'un
arbre.
3.1 L'arbre DIT (Directory Information Tree).
L'arborescence ldap est assimilable à celle d'unix aux spécificités près suivantes :
-sa racine unique est appelée root entry.
-chaque noeud de l'arbre représente une entrée appelée DSE (Directory Service Entry).
-l'arbre est décrit par une entrée appelée rootDSE (root Directory Specific Entry).
Chaque noeud ou entrée est unique mais correspond à une classe d'objet qui peut etre utilisée à
tout autre niveau de l'arbre.
Ex de DIT :
dc=iut-velizy,dc=uvsq,dc=fr
ou=apprenant
ou=enseignant
uid=12392
cn=dupond
3.2 L'accès aux entrées.
On accède à une entrée par son DN (Distinguished Name) qui est assimilable au path de l'arbre
unix. Il peut etre absolu ou relatif, on parle alors de RDN (Relative Distinguished Name).
Les principaux attributs utilisés pour exprimer un DN sont les suivants :
Attribu Description
t
dn
Nom distingué (utilisé par d'autres attributs par héritage)
dc
Une des parties du NomIP d'un domaine internet (domain componet)
ou
Unité organisationnelle (branche de l'organisation)
o
Nom de l'organisation
cn
Nom de l'objet (common name)
sn
Nom de famille de la personne (surname)
uid
Identifiant unique de l'objet
Accès par DN à l'entrée dupond -> dn: cn=dupond,ou=enseignant,dc=iut-velizy,dc=uvsq,dc=fr
Par RDN à partir de dc=iut-velizy,dc=uvsq,dc=fr -> rdn: cn=dupond,ou=enseignant
4 Le modèle fonctionnel.
C'est le modèle décrivant les modalités d'accès à un serveur ldap ainsi que les opérations de création,
modification et destruction.
Les opérations de base sont les suivantes :
Page 33/58
Jean-Paul Coulon
Opération
Description
search
Recherche sur critère
compare
Comparaison de 2 objets
add
Ajout d'entrée
modify
Modification du contenu d'une entrée
delete
Suppression d'un objet
rename
Modification du dn d'une entrée
bind
Connexion à un serveur
unbind
Deconnexion d'un serveur
abandon
Arret d'une opération
extended
Opération étendue (permet création d'opération autre que les 9 précédentes)
On utilise plus couramment des outils d'interface et de fichiers de LDIF qui feront appel aux
opérations de base (voir 2.5).
5 Le modèle de sécurité.
C'est le modèle décrivant les aspects d'authentification, de droits d'accès, et de sécurité réseau qui sont
déclinés ainsi par la norme ldap :
-authentification.
-signature électronique.
-cryptage.
-filtrage réseau.
-ACL d'accès aux données.
-journalisation
6 Installation sur linux (fedora core 6)
6.1 Client
Les packages nécessaires sont :
-openldap-2.3.27-4.i386.rpm (contient les librairies et documentations).
-openldap-clients-2.3.27-4.i386.rpm (contient les commandes d'accès de
recherche/modification/destruction de la base ldap).
Ils sont installables via la commande yum ; #yum install openldap openldap-clients
6.2 serveur
Les packages nécessaires sont :
-openldap-2.3.27-4.i386.rpm (contient les librairies et documentations).
-openldap-servers-2.3.27-4.i386.rpm (contient l'application ldap, le schéma de base de l'annuaire,
les scripts perl de migration pour transfert des fichiers /etc ou autres vers l'annuaire).
Ils sont installables via la commande yum ; #yum install openldap openldap-servers
Page 34/58
Jean-Paul Coulon
6.3 Autres.
De manière facultative, les scripts shell disponibles sur le site contribs.martymac.com permettent
les manipulations de la base concernant les comptes POSIX (utilisateurs, groupes, machines). Ils
sont également utilisés par samba-ldap et n'ont que les commandes standards openldap-client
comme dépendances.
Il est également possible de développer des petits scripts pour grouper certaines commandes
fastidieuses et difficiles à retrouver.
Exemple d'un script permettant d'extraire les entrées cn désirées dans un fichier ldif. On peut
ensuite facilement détruire celles d'origines par la commande ldapdelete et les regénérer via
ldapadd avec le fichier ldif en entrée standard.
#!/bin/bash
#extract entries from ldap to redirect to /tmp/ldif
#for example used to save by extract, to delete after (ldapdelete)
#and restore after modify of /tmp/ldif
usage="Usage: extract entry1 entry2...entryN (entry format must be \"cn=...\")"
base="dc=fc,dc=iut-velizy,dc=uvsq,dc=fr"
cat /dev/null >/tmp/ldif
for i in $*; do
if [ $(echo $i | grep -v cn= ) ]; then exec echo $usage;fi
done
for i in $*;do
typeset -i long=$(ldapsearch -x -D cn=jp,$base -w toto $i | wc -l )
tailer=$[ long - 7 ] ; header=$[ tailer - 6 ]
ldapsearch -x -D cn=jp,$base -w toto $i | tail -$tailer | head -$header >>
/tmp/ldif
done
cat /tmp/ldif
7 Création de l'annuaire.
7.1 Création de l'arborescence.
7.1.1 Utilisation des fichiers ldif.
Après avoir décidé de son arborescence, on peut la réaliser à travers des fichiers ldif :
dc=iut-velizy,dc=uvsq,dc=fr
ou=hosts
ou=people
cn=penelope
Page 35/58
cn=paul
Jean-Paul Coulon
Les fichiers ldif correspondants sont respectivement; societe.ldif, branche.ldif, users.ldif :
dn: dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
objectClass: dcObject
objectClass: organization
o: iut
dc: fc
dn: ou=Hosts,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
ou: Hosts
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
associatedDomain: uvsq.fr
dn: ou=People,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
ou: People
objectClass: top
objectClass: organizationalUnit
objectClass: domainRelatedObject
associatedDomain: uvsq.fr
dn: uid=paul,ou=People,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
uid: paul
cn: paul
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$sxySUJd8$7WIw/Xyi3i.HI6G2UBPDa.
ShadowLastChange: 13573
ShadowMax: 99999
ShadowWarning: 7
loginShell: /bin/bash
UidNumber: 10008
GidNumber: 10007
homeDirectory: /home/paul
dn: uid=penelope,ou=People,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
uid: penelope
cn: penelope
objectClass: account
objectClass: posixAccount
Page 36/58
Jean-Paul Coulon
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$sxySUJd8$7WIw/Xyi3isdfsdfHI6G2UBPDa.
ShadowLastChange: 13573
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 10009
gidNumber: 10007
homeDirectory: /home/penelope
Leur insertion dans l'annuaire est réalisées par les commandes :
#ldapadd -x -D "cn=jp,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" -w toto -f societe.ldif
#ldapadd -x -D "cn=jp,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" -w toto -f branche.ldif
#ldapadd -x -D "cn=jp,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" -w toto -f users.ldif
-x désactive l'authentification SASL
-D exprime le DN de l'utilisateur ayant le droit de faire l'insertion.
-w exprime le mot de passe (passwd).
-f exprime une entrée de type fichier.
7.2 Paramétrage.
La création de l'arborescence n'aurait put etre faite sans que le service ldap soit paramétré et
démarré comme l'indique cette procédure :
Serveur
fichier /etc/openldap/slapd.conf
database bdb
suffix “dc=fc,dc=iut-velizy,dc=uvsq,dc=fr”
rootdn “cn=jp,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr”
rootpw toto
…
access to *
by self write
by * read
(le suffixe de la base).
(l'administrateur de la base).
(le mot de passe de l'administrateur).
(les ACL exprimant les droits d'accès).
Le démarrage de l'annuaire se fait via les scripts systemV:
#service ldap start
Client
fichier /etc/openldap/ldap.conf (valider l'host et le suffixe de la base impérativement)
fichier /etc/nsswitch.conf (valider la consultation ldap après files )
Sur linux, le système PAM (Plug-In Authentification Module) partage sa librairie à toutes les
applications utilisant l'authentification. De nombreux paramètres sont présents à l'installation mais
il est parfois nécessaire de faire ces ajustements dans /etc/pam.conf ou dans /etc/pam.d.
Page 37/58
Jean-Paul Coulon
8 Utilisation de l'annuaire.
Exemples de commandes d'accès à l'annuaire :
cat /etc/passwd et getent passwd
permet de comparer les entrées disponibles en local et via l'annuaire
/usr/share/openldap/migration/migrate_passwd.pl /etc/passwd passwd.ldif
ldapadd -x -D "cn=jp,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" -w jp -f passwd.ldif
permet de migrer en une seule commande le fichier local /etc/passwd dans un fichier ldif puis d'en
insérer le contenu dans l'annuaire.
ldapsearch -x -b "dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" cn=raoul
permet une recherche anonyme sur le serveur local.
ldapsearch -h 193.51.29.201 -x -b "dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" cn=raoul
permet une recherche anonyme sur le serveur distant
ldapdelete -x -D "cn=jp,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr" -w toto
cn=maelzel,ou=Hosts,dc=fc,dc=iut-velizy,dc=uvsq,dc=fr
permet la destruction d'une entrée correspondant à une machine.
9 Applications utilisant ldap.
9.1 Authentification unix.
9.2 Gestion nis
9.3 Authentification apache.
Page 38/58
Jean-Paul Coulon
MODULE 22 : Le système graphique Xwindow.
1 Généralités.
Xwindow est le système graphique standard sur Unix. Il gère la communication des équipements écran,
clavier, souris qui représente peu d'information à transmettre. Cela rend la chose utilisable sur une machine
locale aussi bien que sur un réseau.
Xwindow est le résultat de projets élaborés par les sociétés Xerox, Apple et par l'institut du MIT durant les
années 80. Différentes versions ont vu le jour au cours de cette période pour ce stabiliser aujourd'hui à la
version 11 release 6, on parle alors de X11R6.
2 Concept client/serveur Xwindow.
Un system graphique Xwindow fonctionne sur une structure client/serveur même si les deux composantes
résident sur la même machine.
Le serveur a en charge la gestion du matériel clavier, souris, écran.
L'application cliente utilise le serveur X et réalise l'interface homme-machine à l'aide des librairies
Xwindow.
Serveur et application se servent du protocole Xwindow pour communiquer.
Note: Il est à noter que les notions de client et serveur sont inversées dans le cas d'Xwindow. Une station de
travail possédant un serveur X utilise des applications clientes distantes stockées par exemple sur un serveur
de fichiers.
3 Fonctionnalités et spécificités.
3.1 Le clavier.
Les séquences de touches suivantes sont perçues et interprétées par le serveurX :
-Cntrl, shift, meta + combinaisons avec clic droit et gauche de la souris.
Le copier/coller est obtenu, à la souris, par selection et clic-centre de la souris. Il est disponible entre
toute application puisque il est géré par le graphique.
3.2 L'écran.
Il est défini selon des classes d'objets dont le contenant principal est la RootWindow. La place des
fenêtres qui y seront contenues est exprimée sur un repère abscisses/ordonnées placé en haut à gauche
de l'écran. La géometrie des applications clientes est definie également selon ce repère.
fig.1
fig.2
Ex: xterm -geometry 100x10+250+450
y
y
x
x
xterm
w
Page 39/58
h
Jean-Paul Coulon
Le client et le serveur Xwindow pouvant se trouver sur une seule machine ou plusieurs, la variable
d'environnement DISPLAY va définir la machine recevant l'affichage.
Ex. pour un affichage local et initialisation en ligne de commande.
DISPLAY=localhost:0.0 ou
DISPLAY=:0.0
Le premier 0 exprime la première carte vidéo référencée sur la machine.
Le deuxième 0 exprime le premier port sur la carte vidéo.
Ex. pour un affichage distant et initialisation en ligne de commande.
DISPLAY=129.102.10.5:0.0
ou
DISPLAY=nomIP:0.0
Ex. pour lancer un xterm avec display distant en variable.
#xterm -display nomIP:0.0
4 Le Display Manager.
L'entrée sur un système commence toujours par une phase d'authentification, c'est le DisplayManager qui
va la réaliser dans le cas d'un système graphique Xwindow. Avant l'arrivée des micro-ordinateurs les
DisplayManager proposait également un choix de machine au moment de l'authentification d'où cette
appellation qui perdure aujourd'hui bien qu'ayant perdu son sens premier.
Il existe plusieurs DisplayManager que l'administrateur peut tester et installer selon ses besoins :
xdm, kdm, gdm...
5 Le Window Manager.
Comme l'indique son nom le WindowManager a en charge l'habillage des fenêtres mais également les
menus-souris et la notion de bureau.
C'est également à l'administrateur de faire des tests pour savoir celui qu'il doit installer parmis les plus
courants :
fvwm, twm, mwm, ou bien gnome et kde pour les plus sophistiqués.
6 Sécurité et contrôle d'accès.
6.1 Les listes de machines.
La commande xhost gère une liste de machines autorisées à exporter leur display sur la machine locale.
xhost xhost +
xhost + PC1
xhost - PC2
mise en fonction du contrôle par liste.
arrêt du contrôle par liste.
ajout du host PC1 à la liste des machines autorisées.
retrait du host PC2 de la liste des machines autorisées.
6.2 Le magic-cookie.
Il sert à valider ou non l'utilisateur demandeur du serveur X. Le cookie se trouve dans le
fichier .Xauthority placé dans le répertoire personnel de l'utilisateur. Il est connu par le serveur et
identifie à la connection l'utilisateur voulant utiliser le display de la machine. La reconnaissance repose
sur les droits unix du fichier contenant le cookie autorisé en lecture uniquement pour le propriétaire.
6.3 Sécurisation par clés de codage.
Il est possible d'utiliser ssh (SecureShell) pour transmettre le display et le cookie codés par clés
Page 40/58
Jean-Paul Coulon
publiques/privées pour augmenter la sécurité.
Page 41/58
Jean-Paul Coulon
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation.
1 Structure physique d'un disque.
1.1 Généralités.
Une disquette ou « floppy » (disque mou) est assimilable, du point de vue de sa forme, à un petit disque
audio de type vinyl sur le lequel on vient poser une tête de lecture. L'accès à une disquette est assez proche
de cela à la différence que deux têtes opèrent en simultané, chacune sur une face pour une opération de
lecture ou d'écriture.
(fig. 3)
Un disque-dur est basé sur le même principe mais sera composé de plusieurs disques ou plateaux.
(fig. 4)
Soit l'exemple de la figure 4 où 8 têtes de lecture solidarisées, maintenant une position fixe pendant une
rotation complète des disques, dessinent un « cylindre » (figure 5).
Chaque plateau est constitué de pistes concentriques elles mêmes composées de secteurs.
(fig. 5)
(fig. 6) Disque vu de dessus.
pistes (tracks)
secteurs
Le nombre d'octets par secteur est en général de 512 mais il peut également en être un multiple.
1.2 Taille d'un disque.
Il existe une norme industrielle appelée CHS représentant le nombre de « Cylinders, Heads, Sectors ».
Page 42/58
Jean-Paul Coulon
On résumera la taille d'un disque à la formule suivante :
Size of disk = CHS * sizeof sector
Ex:
On veut exprimer la taille d'un disque de 4092 cyl, 16 têtes possédant 63 secteurs par piste.
Taille en secteurs = 4092 * 16 * 63 = 4 124 736
Taille en octets = 4 124 736 * 512 = 2 111 864 832 ≈ 2,111 GigaOctets.
1.3 Calcul de la taille d'une partition.
Dans un souci d'administration et de maintenance les systèmes Unix sont toujours installés sur des
disque partitionnés (swap et root étant les deux partition minimum).
Le partitionnement est l'opération de découpage d'un disque en plusieurs parties. Chaque partie sera
délimitée par un cylindre de début et de fin qui fixeront sa taille.
On la calcule de la manière suivante pour un résultat en MegaOctets :
(fig. 6)
m – n 1 ∗NbH ∗NbS ∗512
20
2
m
n
2 Structure logique d'un disque.
2.1 MBR MasterBootRecord et BR BootRecord.
Un disque partionné en quatre s'est vu octroyer un MBR et trois BR de la façon suivante :
MBR
Partition 1
BR
Partition 2
BR
Partition 3
BR
Partition 4
Le MBR est le secteur d'amorce principal au disque et les BR des secteurs d'amorçes propres à chaque
partition.
Ils sont constitués de la façon suivante :
Page 43/58
Jean-Paul Coulon
MBR
(512o
)
BR
446 Déroulement de la
octets procédure de boot.
64 Table
octets descriptive des
4 partitions
primaires.
Code pour amorçage à
partir de cette
partition
512 octets
AA55
(validation BIOS)
AA55
2.2 Démarrage, MBR et BR.
Le « bios » lit au démarrage le secteur 0 du disque appelé MasterBootRecord et charge ce qui est présent
à cet emplacement. Le bios trouvera soit :
-le code d'amorce pour démarrage à partir de cette première partition.
-un chargeur d'amorce type « LILO » permettant un aiguillage sur différents OS et partitions.
-le numéro de la partition chargée du démarrage (noté par un « * » par les utilitaires disques).
Dans les deux derniers cas, la place du code d'amorce ne se trouve pas sur la première partition mais sur
celle considérée dans le BootRecord respectif à la partition.
L'appel du code d'amorce étant géré par le bios ou par un chargeur, ils doivent se trouver dans les
limites d'adressage du bios qui est limité au 1024 premiers cylindres. Ce code doit également résider sur
l'une des quatre partitions primaires que le bios reconnaît. On créé généralement une petite partition de
quelques méga-octets pouvant contenir plusieurs noyaux (≈ 20 Mo).
note:
dos/windows-->les BR sont écrits par défaut.
linux-->les BR sont à écrire en fin d'installation par la commande « lilo ».
2.3 Partitions primaires et étendues.
Le concept de partition étendue va permettre d'aller au delà des 4 partitions primaires. Elle n'abrite pas
réellement des données mais donne la possibilité de déclarer des partitions logiques (64 maxi) à l'intérieur
d'elle-même.
Cette partition étendue est considérée par le bios faisant partie des 4 partitions primaires. Elle est unique sur
un disque.
Ex. de partitionnement.
Page 44/58
Jean-Paul Coulon
part. prim. 1
part. prim. 1
part. prim. 2
part. prim. 2
part. prim. 3
part. prim. 1
part. log. 5
part. log. 5
...
part. log. 5
part. log. 6
...
part. étendue part. log. 6
part. étendue part. log. 7
part. étendue ...
≈ part. prim. 4 part. log. 7
La partition étendue, servant de contenant aux partitions logiques, elle gère dans son BootRecord la tables
des 64 partitions logiques possibles.
2.4 Le Linux-Loader LILO et la commande ''lilo''.
Il a en charge les tâches suivantes :
-aiguillage du choix d'OS.
-chargement du secteur d'amorce.
L'invite d'aiguillage, s'exécutera au chargement du lilo s'il est placé dans le BR d'une partition contenue
dans les 1024 premiers cylindres, et que cette partition est déclarée d'amorce par un utilitaire disque comme
« fdisk ». Si aucune partition n'est déclarée comme telle, le lilo doit se trouver impérativement dans le
MBR.
La commande « lilo », a exécuter sous login root, sert à (de)installer le chargeur à partir de la configuration
se trouvant dans le fichier « /etc/lilo.conf ». Il contient une section de parametres globaux situés en début de
fichier s'achevant par le paramètre « image » ou « other » qui déclare le début d'une section spécifique à un
démarrage.
ex de fichier « lilo.conf » :
prompt
force le message d'invite « lilo : », il n'y pas de valeur par défaut.
timeout=50
c'est la durée maxi d'attente à l'invite au delà de laquelle le démarrage commencera sans choix d'OS.
default=linux
c'est l'image prise par défaut en cas de « timeout »
boot=/dev/hda
l'installation du lilo est faite ici sur le MBR du disque
map=/boot/map
carte utilisé par le noyau
install=/boot/boot.b
copie de sauvegarde du BR
message=/boot/message
message graphique ou texte au moment de l'invite
lba32
uiliser l'adressage LinearBlockAddress32 pour aller au delà de 1024 cylindres
#image=/boot/vmlinuz-2.4.18-3
#image=/boot/vmlinux-2421.2
image=/boot/vmlinux-2421.4
le noyau en question
label=linux
initrd=/boot/initrd-2.4.18-3.img
Page 45/58
Jean-Paul Coulon
utilisation d'un périphérique ramdisk pendant le démarrage.
read-only
root=/dev/hda5
other=/dev/hda2
le 2eme OS ici windowsNT disponible sur la 2eme partition.
optional
label=NT
note:
l'emploi du « lba » utilise une conversion d'adresse qui permettra au lilo d'aller au delà des 1024
cylindres. Ceci a pour conséquence de modifier le nombre de têtes de lecture visibles par
l'utilitaire « fdisk ». Il est généralement égale à 255 et représente donc ainsi une valeur virtuelle.
2.5 Création d'une disquette d'amorce.
Cette pratique est simple et permet de pouvoir démarrer en système en cas de panne ou bien de tester un
nouveau noyau avant de l'installer définitivement. Trois phases sont nécessaires à cela :
-faire une recopie brute du noyau sur une disquette sans y avoir créer de FS.
#dd if=/boot/vmlinux-2421.4 of=/dev/fd0 bs=1k
1188+1 enregistrements lus.
1188+1 enregistrements écrits.
-indiquer que le périphérique racine est la 5ème partition de votre disque dur.
#rdev /dev/fd0 /dev/hda5
-déclarer la disquette bootable (-R), et le noyau en mode écriture/lecture (0).
#rdev -R /dev/fd0 0
2.6 Création d'une disquette d'amorce avec un chargeur LILO.
Dans le cas d'une machine multi-OS, il est préférable d'avoir une disquette contenant un loader et de
pouvoir profiter ainsi de tous les OS. Il faut d'abord connaître la version du noyau en cours.
#uname -r
2.4.21
On créé la disquette.
#mkbootdisk 2.4.21
On démarre sur le floppy avec l'option linux par défaut. Il faut ensuite modifier le fichier lilo.conf
du floppy pour y ajouter l'image windows le cas échéant.
Page 46/58
Jean-Paul Coulon
MODULE 24 : La personnalisation d'un noyau système.
1 Le noyau (kernel).
1.1 Généralités.
Le noyau linux est distribué selon les termes d'une licence OpenSource sur les sites miroirs de l'adresse
principale www.fr.kernel.org (version française). La version 2.6.0 décompressée est composée de
212Mo de codes source en langage C pour les différentes architectures disponibles.
La noyau lui-même représente 1,5 million de lignes de code. Ce développement a pu voir le jour grâce à
un groupe de travail reparti sur internet, organisé et centralisé par Linus Torvald.
Le noyau est un fichier nommé vmlinuz-XXX (XXX pour No de version), se trouvant dans
/boot. Sa taille est généralement comprise entre 300Ko et 1,4Mo, espace tenant sur une disquette.
Le No de version est composé d'un nombre à trois chiffres afin de donner les précisions suivantes :
No de version concernant les
améliorations et corrections.
No majeur (ne change qu'en cas de
restructuration globale du kernel).
vmlinux-2.6.0
No d'évolution, change à l'occasion d'ajout de
fonctionnalités(paire pour stable et impaire pour signifier en cours
de développement).
1.2 Fonctions.
On peut résumer les six tâches principales du noyau ainsi :
-reprise des infos du bios pour la gestion du hardware.
-création du premier processus pour le lancement ultérieur d' init.
-liaison entre le hardware et l'applicatif ou la ligne de commande.
-ordonnancement des processus.
-gestion des FileSystem.
-gestion des arrêts/marches.
2 La compilation.
2.1 Les buts recherchés.
On décide de compiler un nouveau noyau en générale pour l'une des raisons suivantes :
-optimisation de la taille du kernel ( se débarrasser des parties inutiles).
-optimisation du code pour un processeur. La composition livrée par défaut correspond à une famille de
processeurs où il peut manquer des instructions clés à un microprocesseur en particulier.
-ajout de matériel, nouvelle technologie ou ordinateur exotique sortant des cas génériques (portable).
Page 47/58
Jean-Paul Coulon
2.2 Choix des composantes de la compilation.
Ce choix va être orienté par adjonction ou retrait de matériel et service mais également dans le type
d'implémentation. En effet, les fonctionnalités du kernel sont dites modulaires ou bien directement
implémentées dans le noyau.
Les modules, du point de vue du fonctionnement, font parties intégrantes du noyau mais sont répartis
dans d'autres fichiers se trouvant dans /lib/modules. Ils sont chargés et déchargés dynamiquement
par les utilisateurs ou le système lors de requêtes ou bien d'inutilisation. On optimise ainsi la place
mémoire utilisée tout en conservant un fort potentiel de fonctionnalités disponibles à tout moment. Ce
principe de noyau possède tout de même l'inconvénient d'un temps de latence pris à chaque chargement.
Le paramétrage d'une configuration noyau est regroupé par thèmes et sous-chapitres comme sur la
figure 7.
(fig. 7)
Il existe 3 types de menus de configuration à lancer à partir d'un Makefile contenu dans
/usr/src/linux :
-mode texte standard;
#make config
-mode texte à menu
#make menuconfig
-mode graphique xwindow #make xconfig
La configuration se terminant par une commande « save » pour valider tous les paramètres.
2.3 La compilation.
La compilation se déroule en trois temps suivant les commandes :
#make dep ; make clean
(on crée les dépendances puis on vérifie l'absence de tous fichiers antérieures à la
compilation)
#make zImage
(création d'un nouveau noyau appelé /usr/src/linux/arch/i386/boot/zImage)
Page 48/58
Jean-Paul Coulon
ou bien
#make bzImage
(création d'un nouveau noyau compressé appelé /usr/src/linux/arch/i386/boot/zImage)
#make zdisk
(création du nouveau noyau directement sur le floppy)
#make modules
(création des modules choisis)
Ces trois lignes de commandes peuvent se réduire à une seule avec le caractère « ; ». Il est d'usage de
donner des noms de noyau correspondant à la version et à l'heure à laquelle il est compilé dans le cas de
plusieurs tests.
2.4 Phase de test et d'installation.
Une première méthode consiste à utiliser une disquette de test. On recopie le nouveau noyau dessus, on
redémarre puis on teste les nouvelles fonctionnalités.
La deuxième méthode passe par l'utilisation du chargeur « lilo ». Il s'agit de l'utiliser ainsi :
-copie du nouveau noyau à coté de l'ancien dans /boot. (le nom doit être différent).
-créer un nouveau paragraphe « image » à l'identique de celui que vous utilisez déjà. Changer le
nom de l'image par le nom du nouveau noyau ainsi que le nom du label. Installer la nouvelle
configuration du lilo.
-relancer votre système et tester le nouveau label du lilo.
L'installation réside ensuite simplement à pérenniser son test. Dans le premier cas on installe le noyau du
floppy dans le « lilo ». Dans le deuxième cas, on enlève l'image crée dans le « lilo » puis on refait le lien
symbolique se trouvant dans /boot pour qu'il pointe sur le nouveau noyau.
3 Mise à jour d'un noyau par un « patch ».
Il est possible de mettre à jour un noyau directement par un « patch » en suivant généralement ces trois
étapes.
# cp patch-2.2.1.gz /usr/src
# gzip -d patch-2.2.1.gz
# patch -p 1 -i patch-2.2.1
Page 49/58
Jean-Paul Coulon
MODULE 25 : Les niveaux de démarrage systemV.
1 Principe de démarrage de Linux (système V).
On considère ici un système linux installé sur une machine de type PC. Ce cas très fréquemment rencontré
ne représente pas de façon exhaustive le parc linux en service aujourd'hui.
Schématiquement les étapes du démarrage sont:
Mise sous tension.
ON
Inventaire hardware.
BIOS
Aiguillage d'OS si plusieurs OS résidants.
LILO
Chargement du noyau (kernel).
LOAD
Lancement du processus parent de tous.
INIT
(fig. 1)
lecture et exécution du fichier /etc/inittab
Lancement des
scripts
respectifs au
niveau
sélectionné
Utilisation
courante
jusqu'au
prochain
''shutdown''.
2 Les niveaux de démarrage (run-level).
2.1 Généralités.
Comme le montre la figure 1, le démarrage d'un système informatique se fait par le lancement
chronologique de programmes ou processus. Le tout premier et très petit, appelé bootstrap
(chausse-pied), qui est résidant dans l'électronique de la machine a en charge d'en appeler un autre
plus conséquent et ainsi de suite tout le long du démarrage. Cet « empilage » de programmes étant
chronologique et extensif, on peut dire que plus un démarrage occupera de temps, plus la machine aura de
fonctionnalités à son actif. Toutes ces fonctionnalités n'étant pas forcément nécessaires ou désirées à chaque
démarrage, on parlera de niveau de démarrage pour exprimer une partie ou la totalité de cet « empilage ».
Les run-levels sont paramétrés dans le fichier /etc/inittab,le process init va prendre la valeur
numérique de run-level déclarée par défaut parmi les suivantes :
0 Arrêt
1 Mono-utilisateur (root uniquement, on parle de single-user-mode).
2 Multi-utilisateurs sans NFS.
3 Multi-utilisateurs complet.
4 Réservé aux tests.
5 Multi-utilisateurs et environnement graphique.
Page 50/58
Jean-Paul Coulon
6 Redémarrage.
notes:
On peut utiliser init par la ligne de commandes en lui donnant un argument compris entre 0 et 6.
Au démarrage et à partir de « l'invite lilo », on peut passer une option de 1 à 5 qui sera prise en compte dès que le process
« init » existera ( ex. LILO: linux 3).
La commande runlevel permet de connaître à tout moment le niveaux de démarrages courant et précédent.
L'équivalent avec Grub se fait par l'édition des trois lignes de commandes disponibles au démarrage.
Exemple pour démarrer en single-user, éditer la ligne chargeant le « kernel » et ajouter en fin de ligne un espace suivi du
mot « single », puis demander le démarrage par la lettre b (boot).
2.2 Description de /etc/inittab.
Sa syntaxe est la suivante ; <id>:<niveau(x)>:<action>:<programme>
<id>
<niveau(x)>
<action>
<programme>
identificateur de ligne (il doit être unique).
le(s) niveau(x) concernés.
contexte d'interprétation de la ligne.
programme ou script à exécuter dans le contexte précisé par le champ précédent.
Un exemple de fichier /etc/inittab :
#
# inittab
This file describes how the INIT process should set up
#
the system in a certain run-level.
#
# Author:
Miquel van Smoorenburg, <[email protected]>
#
Modified for RHS Linux by Marc Ewing and Donnie Barnes
#
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
Commentaires (commençant par #) donnant un résumé de chaque run-level.
id:5:initdefault:
initdefault est le paramètre lu à chaque démarrage et déterminant le runlevel du prochain démarrage.
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
script lancé après la reconnaissance du hard (2ème champ vide car la notion de niveau n'est pas encore définie)
l0:0:wait:/etc/rc.d/rc 0
rc est le script qui va démarrer/arrêter les services relatifs au niveau passé en argument. wait précise qu'il faut attendre la
fin de ce process avant de continuer l'initialisation
# Things to run in every runlevel.
Page 51/58
Jean-Paul Coulon
ud::once:/sbin/update
opération d'écriture des buffer-disks sur les disques faite à chaque entrée dans un runlevel. (2eme champ vide = all level)
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
simulation du cntrl-alt-delete de windows
# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have power installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
pf, lance le shutdown différé de 2mn (-f sans fsck, -h halt). pr, arrête le shutdown si l'onduleur est à nouveau en service.
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
mise en place des 6 consôles textes obtenues par cntrl+alt+f1...f6
# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon
respawn ~= restart proc after wait not, pour relancer le process dès qu'il est terminé.
3 Le processus d'initialisation init.
3.1 Organisation et hiérarchie.
Le process init est issu d'un package rpm nommé SysVinit.
La totalité des acteurs du process /bin/init est placée dans /etc/rc.d. On y trouvera comme sur la
figure 2 :
-les trois fichiers, rc, rc.local, rc.sysinit.
-les répertoires initd, rc0.d, rc1d.....rc6.d.
Le process init va exécuter les tâches suivantes:
-exécution de rc.sysinit. Il y a lancement des scripts sans distinction de niveau et initialisation des
paramètres généraux. Les principaux sont ; premier path d'exécution, horloge système, nom de host,
mapping clavier, polices du système. Il y a ensuite ajout des premiers modules au noyau selon les
entrées/sorties présentes et validées.
-exécution de tous les scripts inhérents au niveau de démarrage via le script rc.
-exécution de /etc/rc.d/rc.local représentant la ''personnalisation'' du démarrage du système sur
lequel on se trouve (valable pour tous les niveaux).
Page 52/58
Jean-Paul Coulon
/
sbin
...
home
etc
init
rc
(fig. 2)
tmp
...
var
rc...
rc5.d
rc6.d
K20nfs
S58httpd
...
rc.d
rc.sysinit
rc.local
init.d
rc0.d
httpd
...
nfs
rc1.d
3.2 Gestion des scripts d'arrêt/démarrage par niveau.
Cette gestion est réalisée à l'exécution du script /etc/inittab (lancé par init) et plus précisément par
les sept lignes comprenant les identificateurs l0, l1,...l6. Ces lignes « appellent » le script rc suivi d'un
argument correspondant au runlevel. Le script rc va aller consulter le répertoire correspondant au runlevel
et exécuter tout les fichiers présent dans ce répertoire.
Les noms de ces fichiers vont déterminer l'action à faire (S pour Start et K pour Kill) et la chronologie à
respecter qui est interprétée numériquement de 00 à 99. Le script rc va exécuter, tous les scripts pointés par
un lien préfixé par un s (start) en entrée de niveau et ceux suffixés par un k (kill) en sortie de niveau.
En réalité, ces fichiers ne sont pas des scripts mais des liens symboliques pointant sur les scripts placés,
dans leur totalité et sans distinction, dans le répertoire /etc/init.d (voir figure 2).
Tout ajout/retrait d'un service s'effectuera par la création/destruction de liens dans le(s) répertoire(s) du ou
des niveaux de démarrage concernés.
Voici un exemple de liens trouvés dans /etc/rc.d/rc2.d :
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
15 déc 16 2002 K03rhnsd -> ../init.d/rhnsd
13 déc 16 2002 K05atd -> ../init.d/atd
15 sep 7 12:02 K15httpd -> ../init.d/httpd
13 déc 16 2002 K20nfs -> ../init.d/nfs
20 déc 16 2002 K44rawdevices -> ../init.d/rawdevices
15 déc 16 2002 K46radvd -> ../init.d/radvd
15 déc 16 2002 K50snmpd -> ../init.d/snmpd
19 déc 16 2002 K50snmptrapd -> ../init.d/snmptrapd
16 déc 16 2002 K50xinetd -> ../init.d/xinetd
16 déc 16 2002 K65identd -> ../init.d/identd
16 déc 16 2002 K72autofs -> ../init.d/autofs
14 déc 16 2002 K74ntpd -> ../init.d/ntpd
15 déc 16 2002 K75netfs -> ../init.d/netfs
17 déc 16 2002 K86nfslock -> ../init.d/nfslock
17 déc 16 2002 K87portmap -> ../init.d/portmap
15 déc 16 2002 K95kudzu -> ../init.d/kudzu
Page 53/58
Jean-Paul Coulon
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
1 root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
18 déc 16
18 déc 16
14 déc 16
17 déc 16
16 déc 16
18 déc 16
16 déc 16
16 déc 16
14 déc 16
13 déc 16
18 déc 16
13 déc 16
15 déc 16
13 déc 16
17 déc 16
14 déc 16
11 déc 16
2002 S08ipchains -> ../init.d/ipchains
2002 S08iptables -> ../init.d/iptables
2002 S09isdn -> ../init.d/isdn
2002 S10network -> ../init.d/network
2002 S12syslog -> ../init.d/syslog
2002 S17keytable -> ../init.d/keytable
2002 S20random -> ../init.d/random
2002 S24pcmcia -> ../init.d/pcmcia
2002 S26apmd -> ../init.d/apmd
2002 S60lpd -> ../init.d/lpd
2002 S80sendmail -> ../init.d/sendmail
2002 S85gpm -> ../init.d/gpm
2002 S90crond -> ../init.d/crond
2002 S90xfs -> ../init.d/xfs
2002 S95anacron -> ../init.d/anacron
2002 S98wine -> ../init.d/wine
2002 S99local -> ../rc.local
3.3 Les outils de gestion des scripts.
Il existe trois outils principaux trouvés sur RedHat.
-chkconfig (mode texte).
-serviceconf, system-config-services (graphique RedHat)
-ksysv (graphique multi-fenêtres, uniquement avec KDE).
Exemples de l'utilisation de chkconfig :
chkconfig --list
liste complète des services présents et de leurs états pour tous les niveaux de
démarage.
chkconfig --list httpd
liste les états du service httpd pour tous les niveaux de démarage.
chkconfig --add totod
ajout du service totod (état d'arrêt) pour tous les niveaux.
chkconfig --del totod
retrait du service totod pour tous les niveaux.
chkconfig --level 2 totod on
mise à l'état marche du service totod pour le niveau 2.
Les scripts ont dans leurs premières lignes de commentaires, des directives indiquant la gestion par l'outil
chkconfig ainsi que les niveaux et état par défaut.
Ex: Contenu dans les premières lignes du script de démarrage du daemon lpd (LinePrinterDaemon).
# chkconfig: 2345 60 60 (validé pour les niveaux 2345 S60 et K60)
Page 54/58
Jean-Paul Coulon
MODULE 26 : La journalisation système (issue du système BSD).
1 Introduction.
Les systèmes d'exploitation conserve un historique des évènement passés, ces traces archivées au fil
du temps peuvent ensuite servir au système, aux applications et aux utilisateurs. Elles permettent
souvent de comprendre un état présent dépendant d'évènements survenus dans un passé plus au moins
proche.
Ces fichiers de données appelés journaux, représentent une aide considérable au debug pour
l'administrateur ou le développeur.
Ces fichiers comparables à des carnets de bord utilisés dans la marine sont appelés log. Une deuxième
origine provient également de la marine utilisant autrefois des rondins (log en anglais) attachés à des
cordes permettant de déterminer la vitesse d'une embarcation.
2 Principes de la journalisation, log et daemon.
La journalisation consiste à écrire, dans un fichier appelé log ou journal, la totalité des évènements
survenue sur une certaine durée. Cette durée écoulée, on ouvre un nouveau journal et on archive
l'ancien et ainsi de suite.
La dimension de stockage pouvant devenir problématique à un certain moment, le système où
l'administrateur détruira les logs le plus anciens.
Tous les systèmes Unix possèdent un daemon de journalisation, le plus répandu est syslogd et provient
de la branche universitaire BSD (Berkeley System Development).
3 Installation et mise en service.
3.1 La distribution linux Fedora.
Elle utilise le package sysklogd pour installer deux daemons; klogd et syslogd chargés
respectivement des évènements noyau (kernel) et de tous les autres gravitant autour du système.
3.2 Syslog.
L'implémentation de syslog dans l'arborescence linux est classique.
•
daemon (binaire exécutable):
/sbin/syslogd
•
configuration principale (texte):
/etc/syslog.conf
•
options courantes à modifier (variables):
/etc/sysconfig/syslog
•
script de démarrage (bash) /etc/init.d/syslog
voir schéma en 3.3 Syslog et réseau.
Le daemon syslogd a la spécificité de pouvoir travailler également en réseau, une centralisation de
la journalisation peut alors se faire sur une seule machine recevant les évènements d'autres
connectées sur le même réseau.
Page 55/58
Jean-Paul Coulon
4 La configuration principale.
4.1 Le fichier syslog.conf utilise sa propre syntaxe.
•
1 seule règle par ligne
•
2 champs par ligne; le sélecteur, composé de deux variables nommées facility et priority, et
l'action représentant en général le fichier cible de journalisation.
Exemple: cron.warning
/var/log/cron.log
4.2 La hiérarchie en place et la personnalisation.
La variable facility décrit le type de programme demandant une journalisation, ceci permet un
traitement plus approprié des messages envoyés. Les thèmes sont déclinés de la façon suivante :
auth
authentification (quasi-obsolète)
authpriv
authentification-private (à utiliser de préférence)
cron
système de la programmation temporelle de tâches
daemon
daemons sans classification particulière
kernel
message du noyau
lpr
système d'impression
mail
système du courrier électronique
news
système des « nouvelles » (peu utilisé aujourd'hui)
syslog
message interne à syslog
user
message utilisateur
uucp
message de protocole unix-to-unix-copy
local0 à local7 réservés aux personnalisations locales
La variable priority décrit le degré de gravité du message allant du plus faible au plus fort :
debug
pour debug (à priori temporaire)
info
simple information
notice
condition normale
warning
alertes simples
err
erreurs produites
crit
niveau critique du système en question
emerg
le système n'est plus utilisable
*
caractère générique pour les sept « priority »
(chaque niveau de priorité englobe les niveaux de priorités inférieures)
5 Exemple avec la journalisation du daemon xinetd.
•
ajout d'xinetd au système de journalisation système
syslog.conf: ajouter
•
local4.*
/var/log/xinetd.log
prise en compte de la journalisation pour xinetd
xinetd.conf: ajouter
log-type = SYSLOG local4 info
Page 56/58
Jean-Paul Coulon
(nécessaire pour récupérer les messages d'xinetd et des sous-daemons traités par lui-même)
•
option de démarrage pour le script de démarrage d'xinetd
/etc/init.d/xinetd: trouver la ligne chargeant l'exécution et commençant par « daemon.... »
ajouter
•
-syslog
local4
prise en compte des modifications
/etc/init.d/syslog restart; /etc/init.d/xinetd restart
6 Notes.
•
La commande shell logger permet d'envoyer des messages au système de journalisation via la
ligne de commande.
•
La distribution Fedora Core 11 utilise l'extension du daemon syslogd nommé rsyslogd et son
fichier de configuration /etc/rsyslog.conf
•
Schéma d'arborescence.
/
etc
sysconfig
syslog
(options du daemon)
sbin
bin
init.d
syslog.conf
(configuration du
service)
syslog
(script d'arrêt/marche)
Page 57/58
syslogd
(daemon)
...
usr
Jean-Paul Coulon
Notes personnelles.
Notes personnelles.
Page 58/58

Administration Système et Réseau LINUX

Transcription

Documents pareils

TP2-Sécurité OS Linux - Faculté des Sciences Rabat

LinuxCambresis : Forum Linux du vendredi 13 avril

serveur intranet/extranet et sã›curitã› sous linux

Présentation Linux Présentateur : Claude Renaud 2 octobre et 15

Administrateur Systèmes Linux

DCEmu sous Linux - MetaGames-EU

Serveur de fichiers NFS

Initier les utilisateurs des systèm

Ingénieur Développeur linux player multimédia

Design process Plus belle la ville