Jean-Paul Coulon
Linux - Administration Système & Réseau V1.20
Administration Système et Réseau LINUX
Page 1/58
Jean-Paul Coulon
Linux - Administration Système & Réseau V1.20
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
Linux - Administration Système & Réseau V1.20
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
Linux - Administration Système & Réseau V1.20
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
Linux - Administration Système & Réseau V1.20
MODULE 14 : La configuration réseau.
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
Linux - Administration Système & Réseau V1.20
MODULE 14 : La configuration réseau.
(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
Linux - Administration Système & Réseau V1.20
MODULE 14 : La configuration réseau. •
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
Linux - Administration Système & Réseau V1.20
MODULE 14 : La configuration réseau.
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
Linux - Administration Système & Réseau V1.20
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP).
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.
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
Linux - Administration Système & Réseau V1.20
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP).
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
Linux - Administration Système & Réseau V1.20
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP).
# 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
Linux - Administration Système & Réseau V1.20
MODULE 16 : Le filtrage IP par iptables.
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
Linux - Administration Système & Réseau V1.20
MODULE 16 : Le filtrage IP par iptables.
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
Linux - Administration Système & Réseau V1.20
MODULE 16 : Le filtrage IP par iptables.
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
Linux - Administration Système & Réseau V1.20
MODULE 16 : Le filtrage IP par iptables.
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
Linux - Administration Système & Réseau V1.20
MODULE 16 : Le filtrage IP par iptables.
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
Linux - Administration Système & Réseau V1.20
MODULE 17 : La centralisation des services réseaux par xinetd.
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
Linux - Administration Système & Réseau V1.20
MODULE 17 : La centralisation des services réseaux par xinetd.
: [ : spawn &] 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
Linux - Administration Système & Réseau V1.20
MODULE 17 : La centralisation des services réseaux par xinetd.
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
Linux - Administration Système & Réseau V1.20
MODULE 18 : L'impression.
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
Linux - Administration Système & Réseau V1.20
MODULE 18 : L'impression.
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
Linux - Administration Système & Réseau V1.20
MODULE 18 : L'impression.
4 Remarques. L'interface graphique printtool est disponible également sur RedHat pour le paramétrage d'imprimantes.
Page 22/58
Jean-Paul Coulon
Linux - Administration Système & Réseau V1.20
MODULE 19 : Le partage de fichier par NFS.
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
Linux - Administration Système & Réseau V1.20
MODULE 19 : Le partage de fichier par NFS. 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
Linux - Administration Système & Réseau V1.20
MODULE 19 : Le partage de fichier par NFS.
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 ;
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
Linux - Administration Système & Réseau V1.20
MODULE 20 : Administration et authentification centralisées par NIS.
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
Linux - Administration Système & Réseau V1.20
MODULE 20 : Administration et authentification centralisées par NIS.
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
Linux - Administration Système & Réseau V1.20
MODULE 20 : Administration et authentification centralisées par NIS. 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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
(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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP. 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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP. 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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP. 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
Linux - Administration Système & Réseau V1.20
MODULE 21: L'annuaire LDAP.
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
Linux - Administration Système & Réseau V1.20
MODULE 22 : Le système graphique Xwindow.
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
Linux - Administration Système & Réseau V1.20
MODULE 22 : Le système graphique Xwindow.
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
Linux - Administration Système & Réseau V1.20
MODULE 22 : Le système graphique Xwindow.
publiques/privées pour augmenter la sécurité.
Page 41/58
Jean-Paul Coulon
Linux - Administration Système & Réseau V1.20
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation.
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
Linux - Administration Système & Réseau V1.20
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation.
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
Linux - Administration Système & Réseau V1.20
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation.
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
Linux - Administration Système & Réseau V1.20
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation.
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
≈ part. prim. 4 part. log. 8
≈ part. prim. 4 part. log. 64
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
Linux - Administration Système & Réseau V1.20
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation. 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
Linux - Administration Système & Réseau V1.20
MODULE 24 : La personnalisation d'un noyau système.
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
Linux - Administration Système & Réseau V1.20
MODULE 24 : La personnalisation d'un noyau système. 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
Linux - Administration Système & Réseau V1.20
MODULE 24 : La personnalisation d'un noyau système.
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
Linux - Administration Système & Réseau V1.20
MODULE 25 : Les niveaux de démarrage systemV.
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
Linux - Administration Système & Réseau V1.20
MODULE 25 : Les niveaux de démarrage systemV.
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 ; :::
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, # 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 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 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
Linux - Administration Système & Réseau V1.20
MODULE 25 : Les niveaux de démarrage systemV. 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 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 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
Linux - Administration Système & Réseau V1.20
MODULE 25 : Les niveaux de démarrage systemV.
/
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
Linux - Administration Système & Réseau V1.20
MODULE 25 : Les niveaux de démarrage systemV. 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
Linux - Administration Système & Réseau V1.20
MODULE 26 : La journalisation système (issue du système BSD).
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
Linux - Administration Système & Réseau V1.20
MODULE 26 : La journalisation système (issue du système BSD).
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
Linux - Administration Système & Réseau V1.20
MODULE 26 : La journalisation système (issue du système BSD).
(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
Linux - Administration Système & Réseau V1.20
Notes personnelles.
Notes personnelles.
Page 58/58
