Administration Système et Réseau LINUX - e

Transcription

Jean-Paul Coulon
V1.26
Linux - Administration Système & Réseau
Administration Système et Réseau
LINUX
Page 1/65
Jean-Paul Coulon
V1.26
Table des matières
MODULE 12 : La planification des tâches.......................................................................................................6
1 Introduction..................................................................................................................................................................6
2 Les tâches régulières....................................................................................................................................................6
3 Les tâches ponctuelles..................................................................................................................................................6
4 Exemples......................................................................................................................................................................6
5 La table cron système...................................................................................................................................................7
6 Implémentation Fedora à partir de la version Core 11.................................................................................................7
7 Notes personnelles.......................................................................................................................................................8
MODULE 13 : La journalisation système (issue du système BSD).................................................................9
1 Introduction.................................................................................................................................................................9
2 Principes de la journalisation, log et daemon.............................................................................................................9
3 Installation et mise en service.....................................................................................................................................9
3.1 La distribution linux Fedora...............................................................................................................................9
3.2 Syslog.................................................................................................................................................................9
3.3 Syslog et réseau..................................................................................................................................................9
4 La configuration principale.......................................................................................................................................10
4.1 Le fichier syslog.conf utilise sa propre syntaxe...............................................................................................10
4.2 La hiérarchie en place et la personnalisation...................................................................................................10
5 Exemple avec la journalisation du daemon xinetd....................................................................................................10
6 Notes.........................................................................................................................................................................11
MODULE 14 : La configuration réseau........................................................................................................12
1 Généralités et arrêt/marche de l'accès réseau............................................................................................................12
1.1 Généralités........................................................................................................................................................12
1.2 L'arrêt/marche de l'accès réseau.......................................................................................................................12
2 Configuration des paramètres réseaux......................................................................................................................12
2.1 Installation de la carte réseau...........................................................................................................................12
2.2 Les interfaces....................................................................................................................................................13
2.3 La table de routage système.............................................................................................................................13
3 Fichiers de configuration et scripts...........................................................................................................................14
3.1 Généralités........................................................................................................................................................14
3.2 Les paramètres globaux....................................................................................................................................14
3.3 Les paramètres par interface.............................................................................................................................14
3.4 Validation des paramètres réseaux...................................................................................................................15
3.5 Spécificités Fedora...........................................................................................................................................15
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP)......................................................16
1 Généralités................................................................................................................................................................16
2 La configuration du client.........................................................................................................................................16
2.1 Le service dhcp.................................................................................................................................................16
2.2 Les fichiers paramètres.....................................................................................................................................16
3 La configuration du serveur......................................................................................................................................17
3.1 Les modes de distribution d'adresses................................................................................................................17
3.2 Le fichier /etc/dhcp/dhcpd.conf........................................................................................................................17
MODULE 16 : Le filtrage IP par iptables......................................................................................................19
1 Généralités................................................................................................................................................................19
2 Les buts du filtrage IP...............................................................................................................................................19
3 Historique des versions.............................................................................................................................................19
4 Les pré-requis systèmes............................................................................................................................................19
5 Le principe du filtrage iptables à l'aide de la table filter..........................................................................................19
6 Algorithme du filtrage..............................................................................................................................................20
7 Utilisation d'iptables.................................................................................................................................................20
7.1 Manipulation des chaînes.................................................................................................................................20
7.2 Manipulation des règles....................................................................................................................................21
8 Commandes systèmes...............................................................................................................................................21
8.1 Gestion des modules du noyau.........................................................................................................................21
8.2 Mise en service du forwarding.........................................................................................................................21
8.3 Sauvegarde des règles......................................................................................................................................21
Page 2/65
Jean-Paul Coulon
V1.26
9 Exemples de règles...................................................................................................................................................21
MODULE 17 : La centralisation des services réseaux par xinetd..................................................................24
1.1 Généralités.............................................................................................................................................................24
2 Le contrôle d'accès aux services et le tcp-wrapper...................................................................................................24
2.1 Généralités........................................................................................................................................................24
2.2 Les listes de contrôles hosts.deny et hosts.allow.............................................................................................24
3 Le super-daemon xinetd............................................................................................................................................25
3.1 Généralités........................................................................................................................................................25
3.2 Configuration du daemon xinetd......................................................................................................................25
3.3 Liaison et ré-acheminement de port.................................................................................................................26
MODULE 18 : L'impression..........................................................................................................................27
1 Les principaux serveurs d'impression.......................................................................................................................27
1.1 Généralités........................................................................................................................................................27
1.2 Installation........................................................................................................................................................27
2 Le daemon LPD........................................................................................................................................................27
2.1 paramétrage......................................................................................................................................................27
3 Le daemon CUPS......................................................................................................................................................27
4 Remarques.................................................................................................................................................................29
MODULE 19 : Le partage de fichier par NFS................................................................................................30
1 Généralités................................................................................................................................................................30
2 RPC et portIP............................................................................................................................................................30
3 Paramétrage d'un serveur NFS..................................................................................................................................31
3.1 Structure du fichier /etc/exports (Extrait de la page de man exports)..............................................................31
3.2 Lancement de rcpbind et de NFS.....................................................................................................................31
4 paramétrage du client NFS........................................................................................................................................32
5 Montage au démarrage et optimisation.....................................................................................................................32
5.1 Montage au démarrage.....................................................................................................................................32
5.2 Montage optimisé ou automontage...................................................................................................................32
MODULE 20 : Administration et authentification centralisées par NIS........................................................33
1 Généralités................................................................................................................................................................33
2 Principe du client-serveur NIS..................................................................................................................................33
3 Paramétrage du serveur NIS......................................................................................................................................33
3.1 Les pré-requis...................................................................................................................................................33
3.2 Le domaine.......................................................................................................................................................33
3.3 Déclaration des hosts autorisés.........................................................................................................................34
3.4 Choix des fichiers d'administration à gérer par le serveur NIS.......................................................................34
4 paramétrage du client NIS........................................................................................................................................34
4.1 Les pré-requis...................................................................................................................................................34
4.2 Le domaine.......................................................................................................................................................35
4.3 Configuration du client NIS.............................................................................................................................35
4.4 Organisation hiérarchique de l'administration.................................................................................................35
5 Tests et expérimentation...........................................................................................................................................35
MODULE 21: L'annuaire LDAP....................................................................................................................36
1 Généralités................................................................................................................................................................36
1.1 Définition..........................................................................................................................................................36
1.2 Historique, du fichier local à l'annuaire...........................................................................................................36
1.3 Annuaire et SGBD............................................................................................................................................36
1.4 Le protocole LDAP..........................................................................................................................................36
2 Le modèle d'information...........................................................................................................................................37
2.1 Terminologie....................................................................................................................................................37
2.2 Le schéma d'annuaire (Directory Schema).......................................................................................................37
2.4 Les classes d'objets...........................................................................................................................................38
2.5 Le format d'échange de données LDIF.............................................................................................................39
3 Le modèle de désignation.........................................................................................................................................40
3.1 L'arbre DIT (Directory Information Tree)........................................................................................................40
3.2 L'accès aux entrées...........................................................................................................................................40
4 Le modèle fonctionnel..............................................................................................................................................40
5 Le modèle de sécurité...............................................................................................................................................41
6 Installation sur linux (fedora core 6).........................................................................................................................41
6.1 Client................................................................................................................................................................41
Page 3/65
Jean-Paul Coulon
V1.26
6.2 serveur..............................................................................................................................................................41
6.3 Autres...............................................................................................................................................................42
7 Création de l'annuaire...............................................................................................................................................42
7.1 Création de l'arborescence................................................................................................................................42
Les fichiers ldif correspondants sont respectivement; societe.ldif, branche.ldif, users.ldif :.................................43
Leur insertion dans l'annuaire est réalisées par les commandes :...........................................................................44
7.2 Paramétrage......................................................................................................................................................44
8 Utilisation de l'annuaire............................................................................................................................................45
9 Exemple d'installation/implémentation sur CentOS.................................................................................................45
MODULE 22 : Le système graphique Xwindow...........................................................................................47
1 Généralités................................................................................................................................................................47
2 Concept client/serveur Xwindow..............................................................................................................................47
3 Fonctionnalités et spécificités...................................................................................................................................47
3.1 Le clavier..........................................................................................................................................................47
3.2 L'écran..............................................................................................................................................................47
4 Le Display Manager..................................................................................................................................................48
5 Le Window Manager................................................................................................................................................48
6 Sécurité et contrôle d'accès.......................................................................................................................................48
6.1 Les listes de machines......................................................................................................................................48
6.2 Le magic-cookie...............................................................................................................................................48
6.3 Sécurisation par clés de codage........................................................................................................................48
MODULE 23 : L'installation d'un ou plusieurs systèmes d'exploitation........................................................49
1 Structure physique d'un disque.................................................................................................................................49
1.1 Généralités........................................................................................................................................................49
1.2 Taille d'un disque.............................................................................................................................................49
1.3 Calcul de la taille d'une partition......................................................................................................................50
2 Structure logique d'un disque....................................................................................................................................50
2.1 MBR MasterBootRecord et BR BootRecord...................................................................................................50
2.2 Démarrage, MBR et BR...................................................................................................................................51
2.3 Partitions primaires et étendues........................................................................................................................51
2.4 Le Linux-Loader LILO et la commande ''lilo''.................................................................................................52
2.5 Création d'une disquette d'amorce....................................................................................................................53
2.6 Création d'une disquette d'amorce avec un chargeur LILO..............................................................................53
MODULE 24: L'archive tar, les installations rpm et yum..............................................................................54
1 Définition d’une archive............................................................................................................................................54
2 Les installations.........................................................................................................................................................54
3 La commande tar........................................................................................................................................................54
4 La base de données RPM...........................................................................................................................................55
5 Les commandes d’interrogation de la base RPM.......................................................................................................55
Les commandes d’interrogation les plus courantes sur la base rpm.......................................................................55
Les commandes d’interrogation les plus courantes sur un fichier de l’arborescence.............................................56
Les commandes d’interrogation les plus courantes sur fichier de type package non-installé (pas pris en compte
par le bd)..................................................................................................................................................................56
6 Les installations par le gestionnaire d'archives YUM...............................................................................................56
7 Paramétrage de YUM et des site-dépôts....................................................................................................................57
MODULE 25 : La personnalisation d'un noyau système................................................................................58
1 Le noyau (kernel)......................................................................................................................................................58
1.1 Généralités........................................................................................................................................................58
1.2 Fonctions..........................................................................................................................................................58
2 La compilation..........................................................................................................................................................58
2.1 Les buts recherchés..........................................................................................................................................58
2.2 Choix des composantes de la compilation.......................................................................................................59
2.3 La compilation..................................................................................................................................................59
2.4 Phase de test et d'installation............................................................................................................................60
3 Mise à jour d'un noyau par un « patch »...................................................................................................................60
MODULE 26 : Les niveaux de démarrage systemV......................................................................................61
1 Principe de démarrage de Linux (système V)...........................................................................................................61
2 Les niveaux de démarrage (run-level)......................................................................................................................61
2.1 Généralités........................................................................................................................................................61
2.2 Description de /etc/inittab................................................................................................................................62
Page 4/65
Jean-Paul Coulon
V1.26
3 Le processus d'initialisation init................................................................................................................................63
3.1 Organisation et hiérarchie................................................................................................................................63
3.2 Gestion des scripts d'arrêt/démarrage par niveau.............................................................................................64
3.3 Les outils de gestion des scripts.......................................................................................................................65
Page 5/65
Jean-Paul Coulon
V1.26
MODULE 12 : La planification des tâches.
1 Introduction.
Pour assurer la cohérence du système il est nécessaire de réaliser un certain nombre de tâches différées et
périodiques. On dispose des services cron pour les tâches régulières et de at pour les tâches
2 Les tâches régulières.
Le démon crond lit toutes les minutes le contenu des fichiers du répertoire /var/spool/cron pour connaître les
processus à exécuter. Chaque utilisateur possède son propre fichier cron qui doit porter son nom. Les fichiers
/etc/cron.allow et /etc/cron.deny permettent d’indiquer la liste des personnes autorisées à employer le service
cron. Le fichier cron contient les informations suivantes :
<mn> <h> <jours> <mois> <jour de la semaine de 0-6> <commande(s) à exécuter>
Remarque:
Le caractère * désigne le « quel que soit », la virgule sépare plusieurs valeurs, le tiret (-) définit un intervalle et
le slash ( / ) une fréquence. Pour manipuler les fichiers cron, il faut utiliser la commande crontab. L’utilitaire
graphique kcron permet plus aisément de configurer les fichiers cron. La commande anacron permet de démarrer
des services qui n’ont pas pu être exécutés à la date prévue (surcharge système, arrêt système …).
3 Les tâches ponctuelles.
•
Le démon atd lit le contenu des fichiers de /var/spool/at/ pour exécuter des tâches ponctuelles.
•
La commande at [-f <script>] <date> ou at now [ -f <script> ] + <mn ou h ou jours > permet de créer les
fichiers du même répertoire.
•
Les fichiers /etc/at.allow et /etc/at.deny permettent d’indiquer la liste des personnes autorisées à utiliser
le service.
4 Exemples.
EX1
Pour exécuter ''prog toutes les minutes''
$ crontab -e (édition vi d'un fichier temporaire féré par cron)
* * * * * prog
$crontab -l (pour lister les taches plannifiées par l'utilisateur).
EX2
Idem toutes les 2 minutes pendant les 10 premières minutes de chaque heure, chaque jour du mois,
chaque mois et que le lundi.
0,2,4,6,8,10 * * * 1 prog
ou bien
0-10/2 * * * 1 prog
Autres exemples dans la section5 du man de crontab.
Page 6/65
Jean-Paul Coulon
V1.26
EX3 tâche ponctuelle
$at 16:10
at> ls -l > /dev/pts/2 (envoi le resultat de la commande ls sur la 2eme fenetre
graphique).
Cntrl+D
$at -l (pour listes les taches ponctuelles).
5 La table cron système.
Le système gère sa propre table cron (/etc/contab) :
01 * * * * root run-parts /etc/cron.hourly (toutes les Nheures et 1minute)
02 4 * * * root run-parts /etc/cron.daily (tous les jours à 4h02)
22 4 * * 0 root run-parts /etc/cron.weekly (tous les dimanches à 4H22)
42 4 1 * * root run-parts /etc/cron.monthly (tous les premiers du mois à 4h42)
pour lancer les exécutables présents dans les répertoires /etc/cron.hourly .../daily .../weekly ..../monthly.
6 Implémentation Fedora à partir de la version Core 11.
depuis FEDORA CORE 11 /etc/crontab est vide!
La commande anacron complète crond pour éviter certains conflits observés. Anacron était chargé a l'origine
de relancer les taches non-éxécutées dans le cas par exemple d'une machine éteinte a l'heure prévue pour une
tache cron.
Sur FC11, cron lance anacron qui se charge de toutes les tâches, en retard ou non.
Notes:
•
•
•
run-parts dir ->éxécution de tout ce qui se trouve dans dir
/etc/crontab est vide et doit le rester
/etc/anacrontab (le delay correspond au temps laissé entre deux tâches):
Exemple /etc/anacrontab
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job-identifier command
1
5
cron.daily
nice run-parts /etc/cron.daily
7
25
cron.weekly
nice run-parts /etc/cron.weekly
@monthly 45 cron.monthly
nice run-parts /etc/cron.monthly
/etc/cron.d/0hourly:
01 * * * * root run-parts /etc/cron.hourly
/etc/cron.hourly/0anacron
(selon test, exécute seulement si date courante differente de date de référence anacron) :
Page 7/65
Jean-Paul Coulon
V1.26
#!/bin/bash
day=`cat /var/spool/anacron/cron.daily`
if [ `date +%Y%m%d` = "$day" ]; then
exit 0;
fi
# in case anacron is already running,
# there will be log (daemon won't be running twice).
if test -x /usr/bin/on_ac_power; then
/usr/bin/on_ac_power &> /dev/null
if test $? -eq 1; then
exit 0
fi
fi
/usr/sbin/anacron -s
ps: les tâches plus fréquentes que l'heure doivent être mises dans /etc/cron.d; 2 solutions possibles:
1)
cat /tmp/create-file.sh
#!/bin/bash
touch /tmp/file-$(date +%H:%M)
+
cat /etc/cron.d/create-file
* * * * * root /tmp/create-file.sh
2)
cat /etc/cron.d/create-via-dir-minutely
* * * * * root run-parts /etc/cron.minutely
+
mkdir /etc/cron.minutely/ ; mv /tmp/create-file.sh /etc/cron.minutely/
(la différence se voit dans le log)
7 Notes personnelles
Page 8/65
Jean-Paul Coulon
V1.26
MODULE 13 : 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 9/65
Jean-Paul Coulon
V1.26
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 10/65
Jean-Paul Coulon
V1.26
(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 11/65
syslogd
(daemon)
...
usr
Jean-Paul Coulon
V1.26
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
(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 :
Page 12/65
Jean-Paul Coulon
V1.26
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 :
•
L'adresse de destination du paquet va être comparée à chaque route exprimée dans la table de
Page 13/65
Jean-Paul Coulon
V1.26
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 Ref
U
0
0
U
0
0
UG 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 Présentation du paramétrage réseau de la famille RedHat.
Applet graphique gnome, barre de menu supéprieure à
droite.
(chargé également de la recherche WIFI)
Scripts systèmes de paramétrage réseau
(prise en compte de l'environnement et des périhériques
existants)
Commandes de base unix
(commandes dites dynamiques; prises en compte
immédiates mais éphémères)
NetworkManager
ifup, ifdown...
domainname, hostname,
route, ifconfig, dhclient...
Noyau linux
(kernel)
Page 14/65
Fichiers paramètres lus par les scripts:
- /etc/sysconfig/network
- /etc/sysconfig/network-scripts/ifcfg-eth0
Jean-Paul Coulon
V1.26
3.2 Les paramètres globaux à la machine (hors spécificités par interface).
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
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 15/65
Jean-Paul Coulon
V1.26
MODULE 15 : L'allocation dynamique des paramètres réseaux (DHCP).
1 Généralités.
Le protocole DHCP DynamicHostConfigurationProtocol a pour fonction d'attribuer dynamiquement à une
machine cliente ses paramètres IP, et de manière facultative lui fournir le nom d'un fichier à charger en
mémoire pour exécution. Cette dernière fonction étant rendue possible par l'implémentation du protocole
BOOTP qui utilisera la plupart du temps TFTP pour aller chercher par réseau un noyau ou toute autre
application de démarrage (ex outil de déploiement d'image disque). DHCP utilise le protocole réseau UDP dit
non-connecté qui travaille en mode datagramme.
Les requêtes de ce client sont expédiées en mode diffusion sans savoir à quel serveur elles sont adressées. Le
premier serveur DHCP actif répondra ou non, en conformité à son paramétrage.
2 La configuration du client.
2.1 Le service dhcp.
Le client est un daemon dhclient installé avec le package rpm suivant pour une version RedHat :
[root@zephyr root]# rpm -qil dhclient
Name
: dhclient
Relocations: (not relocatable)
Version : 3.0.4
Vendor: Red Hat, Inc.
Release : 21.fc6
Build Date: lun 11 sep 2006 19:11:59 CEST
Install Date: jeu 07 déc 2006 10:02:57 CET
Build Host: hs20-bc1-7.build.redhat.com
Group
: System Environment/Base
Source RPM: dhcp-3.0.4-21.fc6.src.rpm
Size
: 535643
License: distributable
Signature : DSA/SHA1, mer 04 oct 2006 03:13:47 CEST, Key ID b44269d04f2a6fd2
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL
: http://isc.org/products/DHCP/
Summary : Fournit le démon client ISC DHCP dhclient et dhclient-script .
Description :
DHCP (Dynamic Host Configuration Protocol) est un protocole permettant à des périphériques individuels sur un
réseau IP d'obtenir leurs propres informations de configuration de réseau (adresse IP, masque de sous-ré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), il
Page 16/65
Jean-Paul Coulon
V1.26
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/dhcp/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 leasetime 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 17/65
Jean-Paul Coulon
V1.26
# 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 18/65
Jean-Paul Coulon
V1.26
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 19/65
Jean-Paul Coulon
V1.26
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 horsfiltrage 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 20/65
Jean-Paul Coulon
V1.26
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
On créé une nouvelle règle pour la chaîne INPUT qui détruit les paquets d'adresse source locale
pour le protocole icmp.
Page 21/65
Jean-Paul Coulon
V1.26
# 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 22/65
Jean-Paul Coulon
V1.26
Entrée d'un
paquet.
( fig. 2 )
Décision de
routage
INPUT
Emission du paquet.
FORWARD
block
Processus locaux
Page 23/65
OUTPUT
Jean-Paul Coulon
V1.26
MODULE 17 : La centralisation des services réseaux par xinetd.
1.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
réponses
in.telnetd
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
Page 24/65
Jean-Paul Coulon
V1.26
troisième facultatif, le séparateur de champs est le caractère '':''.
<liste_démons> : <liste_clients>[ : spawn <commande_shell> &]
liste_démons:
liste de deamon(s) séparé(s) par un espace.
liste_clients:
adresse(s) IP, noms IP, adresse de domaine (192.168.20. ou 196.20.12.0/24 ou
196.20.12.*, ou 196.20.12.3? pour signifier de 196.20.12.30-39).
commande_shell:
n'importe quel exécutable disponible sur la ligne de commande, appelée par la
commande spawn et lancer en background (&).
Exemple d'une règle du fichier hosts.deny concernant le daemon in.telnetd :
in.telnetd: 196.20.12. : spawn (/bin/echo $(date) %u >> /var/log/tcpWrapper-telnet) &
A chaque refus de connection par telnet sera stockés, dans un fichier de journalisation, la date courante et
le nom de login.
3 Le super-daemon xinetd.
3.1 Généralités.
Xinetd est qualifié de super-daemon car il va permettre le contrôle de daemons de services réseaux. Il va
remplir les fonctions suivantes :
-arrêt/marche des daemons déclenchés par les requêtes clientes adressées aux services gérés.
-contrôle des demandes en liaison avec le tcpWrapper.
-prise d'information et journalisation supplémentaire à tcpWrapper.
-personnalisation de connection par gestion des nombres d'instances de services en cours.
-ré-acheminement de port entre le client et le daemon géré.
3.2 Configuration du daemon xinetd.
Le daemon xinetd est mis en fonction par son script systemV respectif se trouvant dans
/etc/init.d. Ses paramètres se trouvent dans le fichier /etc/xinetd.conf qui lui-même inclut
les fichiers se trouvant dans son répertoire respectif ; /etc/xinetd.d. Ce répertoire contient un fichier
de paramètres par service géré.
Ex de fichier /etc/xinetd.d/wu-ftpd chargé de la gestion du service ftp distribué par l'Université
de Washington (wu-ftp) :
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
#
normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait
= no
user
= root
server
= /usr/sbin/in.ftpd
server_args
= -l -a
log_on_success
+= DURATION
nice
= 10
}
Note: un manuel est dédié à xinetd.conf qui explicite toutes les options possibles. Les plus sensibles à
Page 25/65
Jean-Paul Coulon
V1.26
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 26/65
Jean-Paul Coulon
V1.26
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 27/65
Jean-Paul Coulon
V1.26
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 28/65
Jean-Paul Coulon
V1.26
4 Remarques.
L'interface graphique printtool est disponible également sur RedHat pour le paramétrage d'imprimantes.
Page 29/65
Jean-Paul Coulon
V1.26
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 30/65
Jean-Paul Coulon
V1.26
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) #export pour host1 en mode lect./ecrit.
/home/coulon host1 (rw) #export pour host1 en lect. par défaut et lect./ecrit. pour tous les autres.
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 31/65
Jean-Paul Coulon
V1.26
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: la version 4 affecte par défaut l'utilisateur nobody aux fichiers/dossiers montés sur le client. Il faut
modifier le fichier /etc/idmapd.conf en dé-validant ces paramètres par des commentaires.
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/auto.master.
Ce fichier contient une entrée par ligne à deux champs ; <point de montage>
<type de map>
Généralement, on utilise une map représenté par un fichier nommé auto.xxx (xxx représentant le point de
montage en question).
exemple: on désire monter le répertoire /home exporté par le serveur PC1 à chaque requête faite sur le
répertoire /home local.
/etc/auto.master :
/etc/auto.home :
/home/
*
auto.home
Page 32/65
-fstype=nfs,hard,intr PC1:/home/&
Jean-Paul Coulon
V1.26
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).
Page 33/65
Jean-Paul Coulon
V1.26
3.2 Le domaine.
Il faut renseigner le fichier des paramètres réseaux globaux qui est /etc/sysconfig/network pour
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 [ facultatifs ].
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 34/65
Jean-Paul Coulon
V1.26
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 35/65
Jean-Paul Coulon
V1.26
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.
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).
Page 36/65
Jean-Paul Coulon
V1.26
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)
o
Nom de l'organisation
ObjectClass
Classe d'objets
ou
Unité organisationnelle (branche de l'organisation)
Page 37/65
Jean-Paul Coulon
V1.26
Attribut
Description
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 38/65
Jean-Paul Coulon
V1.26
(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 39/65
Jean-Paul Coulon
V1.26
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 :
Attribut Description
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 40/65
Jean-Paul Coulon
V1.26
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 41/65
Jean-Paul Coulon
V1.26
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 42/65
cn=paul
Jean-Paul Coulon
V1.26
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 43/65
Jean-Paul Coulon
V1.26
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 44/65
Jean-Paul Coulon
V1.26
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 Exemple d'installation/implémentation sur CentOS.
9.1 Journalisation.
9.1.1 Préciser au log système de prendre en charge l'annuaire ldap.
/etc/rsyslog.conf: (ligne 60): ajouter local3.*
/var/log/ldap.log
9.1.2 Préciser au script de démarrage de ldap qu'il travaille avec la journalisation système rsyslog.
/etc/init.d/slapd: (ligne 197): ajouter en fin de ligne du start daemon: -l LOCAL3
9.1.3 Re-démarrer les deux daemons concernés.
/etc/init.d/rsyslog restart ; /etc/init.d/slapd restart
9.2 Serveur.
9.2.1 Dé-valider la configuration au format ldif pour celle au format texte.
mv /etc/openldap/slapd.d /etc/openldap/slapd.d.NOT-USED
9.2.2 Reprendre la configuration de type texte.
cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/slapd.conf
Page 45/65
Jean-Paul Coulon
V1.26
9.2.3 Faire paramétrage « classique » client/serveur voir §7.2
9.2.4 migrer les fichiers POSIX en fichiers ldif
▪
aller dans /usr/share/migrationtools
▪
modifier le point d'entrée de l'annaire (suffix) du fichier migrate_common.ph
▪
créer un fichier base.ldif à partir du script migrate_base.pl
▪
insérer le fichier base.ldif dans l'annaire
▪
idem pour tous les fichiers retenus à insérer dans l'annuaire.
9.2.5 Paramétrer l'authentification via LDAP
▪
modification du fichier /etc/nsswitch.conf voir §7.2
▪
paramétrage du fichier /etc/nslcd.conf + démarrage du daemon respectif
Une nouvelle conception est également utilisée. Elle s'appelle SSSD (System Security
Services Daemon) et tente à remplacer nss et pam.
9.2.6 notes personnelles
Page 46/65
Jean-Paul Coulon
V1.26
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 47/65
h
Jean-Paul Coulon
V1.26
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 menussouris 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
publiques/privées pour augmenter la sécurité.
Page 48/65
Jean-Paul Coulon
V1.26
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 ». On
Page 49/65
Jean-Paul Coulon
V1.26
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 50/65
Jean-Paul Coulon
V1.26
MBR
(512o)
BR
446 Déroulement de la
octets procédure de boot.
Code pour amorçage à
partir de cette partition
512 octets
64
Table
octets descriptive des
4 partitions
primaires.
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 grub, 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
Linux
-->les BR sont écrits par défaut.
-->les BR sont à écrire en fin d'installation par la commande grub-install.
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.
part. prim. 1
part. prim. 1
part. prim. 1
part. prim. 2
part. prim. 3
part. étendue part. log. 5
≈ part. prim. 4 ...
...
Page 51/65
Jean-Paul Coulon
V1.26
part. prim. 1
part. prim. 1
part. prim. 3
part. prim. 1
part. log. 5
...
part. log. 5
part. log. 6
part. log. 64
≈ part. prim. 4 part. log. 7
≈ part. prim. 4 part. log. 8
La partition étendue, servant de contenant aux partitions logiques, elle gère dans son BootRecord la table 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
utilisation d'un périphérique ramdisk pendant le démarrage.
read-only
Page 52/65
Jean-Paul Coulon
V1.26
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 53/65
Jean-Paul Coulon
V1.26
MODULE 24: L'archive tar, les installations rpm et yum.
1 Définition d’une archive.
Une archive est un fichier compressé ou non contenant plusieurs autres fichiers. Cette simplification d’une
arborescence multi-fichiers en un seul permet de faciliter l'administration d'un système, et d’optimiser les
transferts réseaux. Lorsque l’on dispose d’une distribution de logiciel par archive, on est à peu près certain
d'avoir tous les fichiers nécessaires à son bon fonctionnement.
2 Les installations.
1.1 Via les fichiers sources.
C'est l'installation la plus sommaire, elle permet un contrôle complet de personnalisation ou
d'optimisation (tuning). Une installation par compilation peut se résumer aux opérations suivantes:
- se procurer les fichiers sources (en langage de programmation) par téléchargement
- les placer par exemple dans /tmp
- construire les binaires exécutables grâce à un compilateur comme gcc
- placer les résultats de compilation dans les répertoires bin dédiés aux exécutables
Très souvent, la distribution de fichiers sources sont au format d'archive tar, ce type d'archive,
couramment utilisé sur unix, sert également à packager les fichiers textes et autres.
1.2 Via les fichiers binaires.
Selon ces principes, l'installation par fichiers binaires se passe de la phase de compilation pour faire une
simple recopie des exécutables en bonne place. L'opération est donc plus simple et plus rapide mais
comporte des lourdeurs non-négligeables.
En effet, elle nécessite des compilations aux préalables de types génériques; peu optimisées car
compatibles pour des familles complètes de micro-processeurs et configurées de la façon la plus
standard. De plus il est impératif que tous les outils et librairies nécessaires au fonctionnement soient
déjà en places; c'est ce que l'on appelle les dépendances.
C'est le mécanisme des installations binaires qui est utilisé par la famille RedHat (RedHat, Fedora,
CentOS).
PackageKit (daemon) --> YUM --> RPM
3 La commande tar.
C’est le format standard d'archivage Unix. Tar est l'abréviation de tape-archiver, outil servant à l'origine aux
sauvegardes sur bandes magnétiques.
Attention, c'est à l'utilisateur de gérer les suffixes d'archives, le commande file donnera le type d'un fichier
même sur une erreur de suffixe.
Ex1 créer l'archive xinetd.tar du répertoire /etc/xinetd.d
tar -cvf xinetd.tar /etc/xinetd.d
Ex2 idem avec compression gzip.
tar -cvzf xinetd.tar.gz /etc/xinetd.d
Page 54/65
Jean-Paul Coulon
V1.26
Ex3 idem avec compression bzip2.
tar -cvjf xinetd.tar.bz2 /etc/xinetd.d
Ex4 listing du contenu de l'archive xinetd.tar
tar -tvf xinetd.tar
Ex5 installation ou extraction de l'archive xinetd.tar dans le répertoire courant.
tar -xvf xinetd.tar
Ex6 pour copier le contenu d'un répertoire dans un autre.
cd fromdir; tar cf - . | (cd todir; tar xpf -)
2 Les compresseurs gzip et bzip2.
gzip compresse un fichier ou une arborescence (-r) fichier/fichier sans créer d'archive. bzip2 compresse un ou
plusieurs fichiers exprimés sur la ligne de commande. bzip2 ne travaille pas en mode récursif.
3 Les distributions linux.
Il existe plusieurs types d'archives selon les distributions de linux. RedHat propose ses packages rpm
(RedhatPackageManager) et debian ses archives deb.
Chaque distributeur va utiliser ses propres packages pour réaliser son installation tout en étant compatible avec
les autres versions de linux. On peut installer des packages deb sur RedHat et des packages rpm sur debian.
4 La base de données RPM.
RPM est un système de gestion de base de données d'archives nommé RedhatPackageManager. Les
options de la commande rpm sont regroupées en 5 parties:
- query(-q)
- verify(-v)
- signature(vérification d'intégrité et d'origine d'un package)
- database (init et rebuild)
- install/upgrade/erase (-i, -u -e).
5 Les commandes d’interrogation de la base RPM.
Elle peuvent être exécutées sur trois cibles différentes :
- sur la base-rpm qui contient l'inventaire de tout ce qui est installé sur le système.
- sur tout fichier présent sur le système (par ex. pour connaître son package d'installation).
- sur tout fichier de type package-rpm (par ex. pour l’installation d'un nouveau package).
Les commandes d’interrogation les plus courantes sur la base rpm.
Ex1 obtenir la liste complète des packages installés.
#rpm -qa
Ex2 connaître les packages installés contenant le motif cc.
#rpm -qa | grep cc
Ex3 obtenir les informations disponibles dans la bd-rpm sur le package gcc.
#rpm -qi gcc-2.96-110 ou rpm -qi gcc
Ex4 idem avec la liste des fichiers installés par le package gcc.
#rpm -qil gcc
Page 55/65
Jean-Paul Coulon
V1.26
Les commandes d’interrogation les plus courantes sur un fichier de l’arborescence.
#rpm -qif /etc/passwd
Name
: setup
Relocations: (not relocateable)
Version : 2.5.12
Vendor: Red Hat, Inc.
Release : 1
Build Date: mer 03 avr 2002 19:15:15 CEST
Install date: lun 16 déc 2002 14:24:41 CET
Build Host: stripples.devel.redhat.com
Group
: System Environment/Base
Source RPM: setup-2.5.12-1.src.rpm
Size
: 34340
License: public domain
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary : A set of system configuration and setup files.
Description :
The setup package contains a set of important system configuration and
setup files, such as passwd, group, and profile.
Les commandes d’interrogation les plus courantes sur fichier de type package non-installé (pas pris en
compte par le bd).
Ex1 obtenir des informations sur un package téléchargé dans /tmp.
rpm -qip /tmp/lzo-1.08-1.i386.rpm
Les commandes d’installation les plus courantes.
Ex1 demande d’installation du package lzo
rpm -ivh /tmp/lzo-1.08-1.i386.rpm
(i install, v verbose, hash pour sablier hachuré)
Ex2 idem mais avec option u comme upgrade en cas de package déjà installé.
rpm -uvh /tmp/lzo-1.08-1.i386.rpm i
6 Les installations par le gestionnaire d'archives YUM.
YUM permet l'installation des packages rpm en respectant les dépendances et la version de la
distribution. Il utilise des site-dépôts de références ainsi que des serveurs miroirs.
Ex1 pour connaitre les archives disponibles traitant du protocole dhcp.
#yum search dhcp
...
dhclient-2-4-1
dhcpd-2.3.1
dhcp-tools-3.1
...
note: les caractères de type générique comme '*' ne sont pas nécessaires.
Ex2 pour lister tous les packages disponibles pour la distribution.
#yum list
note: le troisième champs de réponse correspond à l'état d'installation du package :
fedora -> package disponible
installed
-> package déjà installé
updates
-> package de mise à jour disponible
@updates -> package déja mis à jour
note: un nom de package peut être passé en paramètre pour connaître uniquement l'état d'installation.
Page 56/65
Jean-Paul Coulon
V1.26
Ex3 pour installer un client dhcp.
#yum install dhclient-2-4-1
Ex4 pour enlever le package rpm correspondant au client dhcp
#yum remove dhclient-2-4-1
Ex5 pour nettoyer les caches
7 Paramétrage de YUM et des site-dépôts.
Pour Fedora, la configuration se fait par le fichier /etc/yum.conf qui lui-même indique le répertoire
/etc/yum.repos.d/ où chaque fichier comprend un paramétrage spécifique par domaine (distribution
standard, mise à jour, version-beta...)
Exemple de fichier /etc/yum.repos.d/fedora.repo
[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
Page 57/65
Jean-Paul Coulon
V1.26
MODULE 25 : 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 58/65
Jean-Paul Coulon
V1.26
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;
-mode texte à menu
-mode graphique xwindow
#make config
#make menuconfig
#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)
ou bien
Page 59/65
Jean-Paul Coulon
V1.26
#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 60/65
Jean-Paul Coulon
V1.26
MODULE 26 : 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 61/65
Jean-Paul Coulon
V1.26
6 Redémarrage.
notes:
On peut utiliser init par la ligne de commandes en lui donnant un argument compris entre 0 et 6.
Au démarrage et à partir de « l'invite lilo », on peut passer une option de 1 à 5 qui sera prise en compte dès que le process
« init » existera ( ex. LILO: linux 3).
La commande runlevel permet de connaître à tout moment le niveaux de démarrages courant et précédent.
L'équivalent avec Grub se fait par l'édition des trois lignes de commandes disponibles au démarrage.
Exemple pour démarrer en single-user, éditer la ligne chargeant le « kernel » et ajouter en fin de ligne un espace suivi du mot
« single », puis demander le démarrage par la lettre b (boot).
2.2 Description de /etc/inittab.
Sa syntaxe est la suivante ; <id>:<niveau(x)>:<action>:<programme>
<id>
<niveau(x)>
<action>
<programme>
identificateur de ligne (il doit être unique).
le(s) niveau(x) concernés.
contexte d'interprétation de la ligne.
programme ou script à exécuter dans le contexte précisé par le champ précédent.
Un exemple de fichier /etc/inittab :
#
# inittab
This file describes how the INIT process should set up
#
the system in a certain run-level.
#
# Author:
Miquel van Smoorenburg, <[email protected]>
#
Modified for RHS Linux by Marc Ewing and Donnie Barnes
#
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
Commentaires (commençant par #) donnant un résumé de chaque run-level.
id:5:initdefault:
initdefault est le paramètre lu à chaque démarrage et déterminant le runlevel du prochain démarrage.
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
script lancé après la reconnaissance du hard (2ème champ vide car la notion de niveau n'est pas encore définie)
l0:0:wait:/etc/rc.d/rc 0
rc est le script qui va démarrer/arrêter les services relatifs au niveau passé en argument. wait précise qu'il faut attendre la fin
de ce process avant de continuer l'initialisation
# Things to run in every runlevel.
Page 62/65
Jean-Paul Coulon
V1.26
ud::once:/sbin/update
opération d'écriture des buffer-disks sur les disques faite à chaque entrée dans un runlevel. (2eme champ vide = all level)
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
simulation du cntrl-alt-delete de windows
# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have power installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
pf, lance le shutdown différé de 2mn (-f sans fsck, -h halt). pr, arrête le shutdown si l'onduleur est à nouveau en service.
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
mise en place des 6 consôles textes obtenues par cntrl+alt+f1...f6
# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon
respawn ~= restart proc after wait not, pour relancer le process dès qu'il est terminé.
ATTENTION! L'implémentation sous CentOS est différente, celle ci est décrite en en-tête du fichier inittab,
elle indique que ce fichier est réparti en plusieurs, stockés dans le répertoire /etc/init
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 63/65
Jean-Paul Coulon
V1.26
/
sbin
...
init
rc
rc.sysinit
home
etc
init.d
rc.d
rc.local
init.d
rc0.d
httpd
...
nfs
(fig. 2)
tmp
...
var
rc...
rc5.d
rc6.d
K20nfs
S58httpd
...
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
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
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
Page 64/65
Jean-Paul Coulon
V1.26
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
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
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
root
root
root
root
root
14 déc 16
15 déc 16
17 déc 16
17 déc 16
15 déc 16
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 K74ntpd -> ../init.d/ntpd
2002 K75netfs -> ../init.d/netfs
2002 K86nfslock -> ../init.d/nfslock
2002 K87portmap -> ../init.d/portmap
2002 K95kudzu -> ../init.d/kudzu
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 65/65

Administration Système et Réseau LINUX - e

Transcription

Documents pareils

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

LinuxCambresis : Forum Linux du vendredi 13 avril

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

Administrateur Systèmes Linux

DCEmu sous Linux - MetaGames-EU

Initier les utilisateurs des systèm

Serveur de fichiers NFS

Jeuxlinux - Le site des jeux pour linux

Design process Plus belle la ville