Table des matières
En tant qu’administrateur du système, il est sage que vous sachiez en gros comment le système Debian est démarré et configuré. Bien que les détails exacts figurent dans les fichiers sources des paquets installés et dans leurs documentations, c’est un peu pénible pour la plupart d’entre-nous.
Voici un aperçu succinct des points clé de l'initialisation du système Debian. Comme le système Debian évolue constamment, vous devriez vous référer à la dernière documentation.
Le manuel Debian Linux Kernel Handbook est la principale source d'informations sur le noyau Debian.
bootup
(7) décrit le processus de démarrage du système
basé sur systemd
(dernières versions de Debian).
boot
(7) décrit le processus de démarrage du système basé
sur UNIX System V version 4 (anciennes versions de Debian).
Le système informatique subit plusieurs phases de processus d’amorçage (« boot strap process ») depuis l’événement de mise sous tension jusqu’à ce qu’il offre à l’utilisateur un système d’exploitation (OS) pleinement fonctionnel.
Pour des raison de simplicité, je limiterai la discussion à une plateforme PC typique avec l’installation par défaut.
Le processus d’amorçage typique est comme une fusée à quatre étages. Chaque étage de la fusée passe le contrôle du système à l’étage suivant.
Bien entendu, elles peuvent être configurées de manière différente. Par exemple, si vous avez compilé votre propre noyau, vous pouvez sautez l’étape avec le système mini-Debian. Ne supposez donc pas que c’est le cas sur votre système avant de l’avoir vérifié vous-même.
L’ interface micrologicielle extensible unifiée UEFI définit un gestionnaire de démarrage dans le cadre de la spécification UEFI. Lorsqu'un ordinateur est démarré, le gestionnaire de démarrage est le 1er étage du processus d’amorçage qui vérifie la configuration de démarrage et, en fonction de ses réglages, exécute alors le chargeur de démarrage ou le noyau du système d'exploitation spécifié (généralement le chargeur de démarrage). La configuration de démarrage est définie par les variables stockées dans la mémoire RAM non volatile, y compris les variables qui indiquent le chemin des systèmes de fichiers vers les chargeurs de démarrage ou les noyaux de système d’exploitation.
Une partition système EFI (ESP) est une partition de périphérique de stockage de données qui est utilisée dans les ordinateurs adhérant à la spécification UEFI. Accédée par le micrologiciel UEFI quand un ordinateur est démarré, elle stocke les applications UEFI et les fichiers dont ces applications ont besoin pour fonctionner, y compris les chargeurs de démarrage du système d'exploitation. (Sur le système patrimonial de PC, BIOS stocké dans le MBR peut être utilisé à la place.)
Le chargeur de démarrage est le 2ème étage du processus de démarrage qui est lancé par l'UEFI. Il charge l'image du noyau du système et l'image initrd dans la mémoire et leur donne le contrôle. Cette image initrd est l'image du système de fichiers racine et sa prise en charge dépend du chargeur de démarrage utilisé.
Le système Debian utilise normalement le noyau Linux comme noyau système par défaut. L’image initrd pour le noyau Linux 5.x actuel est techniquement l’image initramfs (système de fichiers initial en RAM).
Il existe de nombreux chargeurs de démarrage et de nombreuses options de configuration disponibles.
Tableau 3.1. Liste des chargeurs initiaux
paquet | popularité | taille | initrd | chargeur initial | description |
---|---|---|---|---|---|
grub-efi-amd64 | I:339 | 184 | Pris en charge | GRUB UEFI | assez intelligent pour comprendre le partitionnement du disque et des systèmes de fichiers tels que vfat, ext4, …. (UEFI) |
grub-pc | V:21, I:634 | 557 | Pris en charge | GRUB 2 | assez intelligent pour comprendre le partitionnement du disque et des systèmes de fichiers tels que vfat, ext4, …. (BIOS) |
grub-rescue-pc | V:0, I:0 | 6625 | Pris en charge | GRUB 2 | images de secours amorçables de GRUB 2 (CD et disquettes) (versions PC/BIOS) |
syslinux | V:3, I:36 | 344 | Pris en charge | Isolinux | il comprend le système de fichiers ISO9660. C’est utilisé pour le CD d’amorçage. |
syslinux | V:3, I:36 | 344 | Pris en charge | Syslinux | il comprend le système de fichiers MSDOS (FAT). Il est utilisé par la disquette d’amorçage. |
loadlin | V:0, I:0 | 90 | Pris en charge | Loadlin | un nouveau système est démarré depuis le système FreeDOS/MSDOS. |
mbr | V:0, I:4 | 47 | Non pris en charge | MBR par Neil Turton | c’est un logiciel libre qui se substitue au MBR de MSDOS. Il ne comprend que les partitions sur disques. |
Avertissement | |
---|---|
Ne jouez pas avec les chargeurs de démarrage sans avoir un média de secours
amorçable (clé USB,CD ou disquette) créé à partir des images du paquet
|
Pour le système UEFI, GRUB2 lit d’abord la partition ESP et utilise l’UUID
spécifié pour search.fs_uuid
dans
« /boot/efi/EFI/debian/grub.cfg
» pour déterminer la
partition du fichier de configuration du menu GRUB2
« /boot/grub/grub.cfg
».
La partie principale du fichier de configuration du menu GRUB2 ressemble à ceci :
menuentry 'Debian GNU/Linux' ... { load_video insmod gzio insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1 echo 'Loading Linux 5.10.0-6-amd64 ...' linux /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-5.10.0-6-amd64 }
Pour cette partie de /boot/grub/grub.cfg
, cette entrée de
menu signifie ce qui suit.
Tableau 3.2. La signification de l'entrée de menu de la partie ci-dessus de
/boot/grub/grub.cfg
réglage | valeur |
---|---|
modules GRUB2 chargés | gzio , part_gpt ,
ext2 |
partition du système de fichiers racine utilisée | partition identifiée par
UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 |
chemin d'image du noyau dans le système de fichiers racine | /boot/vmlinuz-5.10.0-6-amd64 |
paramètre de démarrage du noyau utilisé | "root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet " |
chemin de l'image initrd dans le système de fichiers racine | /boot/initrd.img-5.10.0-6-amd64 |
Astuce | |
---|---|
Vous pouvez activer l'affichage des messages du journal de démarrage du
noyau en supprimant |
Astuce | |
---|---|
Vous pouvez personnaliser l’image de démarrage GRUB en définissant la
variable |
Consultez « info grub
» et
grub-install
(8).
Le système mini-Debian est le troisième étage du processus d’amorçage lancée par le chargeur d’amorçage. Il lance le noyau du système avec son système de fichiers racine en mémoire. C’est un étage préparatoire facultatif du processus de démarrage.
Note | |
---|---|
Le terme « système mini-Debian » est utilisé par l’auteur pour décrire dans ce document ce 3ème étage du processus de démarrage. On désigne souvent ce système par système initrd. Un système semblable en mémoire est utilisé par l’installateur Debian. |
Le script « /init
» est exécuté en tant que
premier programme sur le système de fichiers racine en mémoire. C’est un
script de l’interpréteur de commandes qui initialise le noyau dans l’espace
utilisateur et passe le contrôle au prochain étage. Ce système mini-Debian
offre au système d’amorçage une flexibilité comme l’ajout de modules du
noyau avant le processus de démarrage principal ou le montage du système de
fichiers racine en mode chiffré.
Le programme « /init
» est un programme de script
d’interpréteur si initramfs a été créé par
initramfs-tools
.
Vous pouvez interrompre cette partie du processus d’amorçage afin d’obtenir
l’invite de l’interpréteur de l’administrateur en indiquant
« break=init
» etc. comme paramètre de
démarrage du noyau. Consultez le script
« /init
» pour d’autres conditions
d’interruption. Cet environnement d’interpréteur de commandes est
suffisamment sophistiqué pour effectuer une bonne inspection du matériel de
votre machine.
Les commandes disponibles avec ce système mini-Debian sont des commandes
réduites et sont principalement fournies par un outil GNU appelé
busybox
(1).
Le programme « /init
» est un programme exécutable de
systemd
si initramfs a été créé par
dracut
.
Les commandes disponibles dans ce mini-système Debian forment un
environnement systemd
(1) réduit à l’essentiel.
Attention | |
---|---|
Vous devrez utiliser l’option « |
Le système Debian normal est le quatrième étage du processus d’amorçage, il est lancé par le système mini-Debian. Le noyau du système mini-Debian continue de tourner dans cet environnement. Le système de fichiers racine passe de celui en mémoire à celui, réel, lu sur le disque dur.
Le programme init est le premier à être exécuté,
assorti du PID=1, afin qu’il accomplisse son rôle de processus principal de
démarrage de plusieurs programmes. Le chemin par défaut du programme init
est « /usr/sbin/init
» mais il peut être
modifié en passant un paramètre de démarrage au noyau, comme suit :
« init=/chemin/vers/programme_init
».
« /usr/sbin/init
» est lié symboliquement à
« /lib/systemd/systemd
» depuis Debian 8 Jessie (publiée
en 2015).
Astuce | |
---|---|
Il est possible de vérifier le niveau d’exécution actuel de la commande init
du système avec la commande « |
Tableau 3.3. Liste d’utilitaires d’amorçage initial pour le système Debian :
paquet | popularité | taille | description |
---|---|---|---|
systemd
|
V:860, I:966 | 11168 | démon init (8) basé sur des événements pour la concurrence
(remplacement de sysvinit ) |
cloud-init
|
V:3, I:5 | 2870 | Systèmes d’initialisation pour les instances d’infrastructure de nuage |
systemd-sysv
|
V:832, I:964 | 80 | les pages de manuel et liens nécessaires à systemd pour
remplacer sysvinit |
init-system-helpers
|
V:699, I:974 | 130 | outils d'aide pour basculer entre sysvinit et
systemd |
initscripts
|
V:33, I:133 | 198 | scripts pour initialiser et arrêter le système |
sysvinit-core
|
V:4, I:5 | 361 | Utilitaires init (8) de type System-V |
sysv-rc
|
V:66, I:145 | 88 | Mécanisme de changement de niveau de fonctionnement de type System-V |
sysvinit-utils
|
V:897, I:999 | 102 | Utilitaires de type System-V (startpar (8),
bootlogd (8), …) |
lsb-base
|
V:634, I:675 | 12 | Linux Standard Base 3.2 fonctionnalité de script d’initialisation |
insserv
|
V:88, I:144 | 132 | outil pour organiser la séquence de démarrage en utilisant les dépendances du script LSB de init.d |
kexec-tools
|
V:1, I:6 | 316 | outil kexec pour le redémarrage par kexec (8) (redémarrage
à chaud) |
systemd-bootchart
|
V:0, I:0 | 131 | analyseur des performances du processus de démarrage |
mingetty
|
V:0, I:2 | 36 | getty (8) en mode console uniquement |
mgetty
|
V:0, I:0 | 315 | modem intelligent (« smart modem ») remplaçant de
getty (8) |
Astuce | |
---|---|
Vous trouverez des conseils actualisés pour accélérer le processus de démarrage sur Debian wiki:BootProcessSpeedup. |
Quand le système Debian démarre, /usr/sbin/init
lié
symboliquement avec /usr/lib/systemd
est démarré comme
processus de système init (PID=1
) propriété du
superutilisateur (UID=0
). Consulter
systemd
(1).
Le processus d'initialisation de systemd
génère des
processus en parallèle en se basant sur les fichiers de configuration des
unités (consulter systemd.unit
(5)) qui sont écrits dans
un style déclaratif au lieu du style procédural de type SysV.
Les processus engendrés sont placés dans des groupes de contrôle Linux individuels nommés d'après l'unité à laquelle ils appartiennent dans la hiérarchie privée de systemd (consulter cgroups et Section 4.7.5, « Caractéristiques de sécurité de Linux »).
Les unités pour le mode système sont chargés à partir du « Chemin de
recherche d’unités système » décrit dans
systemd.unit
(5). Les principales sont les suivantes par
ordre de priorité :
« /etc/systemd/system/*
» : unités du système créés par
l’administrateur ;
« /run/systemd/system/*
» : unités d’exécution ;
« /lib/systemd/system/*
» : unités du système installées
par le gestionnaire de paquets de la distribution.
Leurs interdépendances sont spécifiées par les directives
« Wants=
», « Requires=
»,
« Before=
», « After=
»,
... (consulter « MAPPING OF UNIT PROPERTIES TO THEIR INVERSES » dans
systemd.unit
(5)). Les contrôles de ressources sont
également définis (consulter
systemd.resource-control
(5)).
Le suffixe du fichier de configuration de l'unité encode leurs types comme :
*.service décrit le processus contrôlé et
supervisé par systemd
. Consulter
systemd.service
(5) ;
*.device décrit le périphérique exposé
dans sysfs
(5) en tant qu'arborescence de périphériques
udev
(7). Consulter systemd.device
(5) ;
*.mount décrit le point de montage du
système de fichiers contrôlé et supervisé par
systemd
. Consulter systemd.mount
(5) ;
*.automount décrit le point de montage
automatique du système de fichiers contrôlé et supervisé par
systemd
. Consulter
systemd.automount
(5) ;
*.swap décrit le périphérique ou le
fichier d'échange contrôlé et supervisé par
systemd
. Consulter systemd.swap
(5) ;
*.path décrit le chemin supervisé par
systemd
pour l'activation basée sur le chemin. Consulter
systemd.path
(5) ;
*.socket décrit le socket contrôlé et
supervisé par systemd
pour l’activation basée sur un
socket. Consulter systemd.socket
(5) ;
*.timer décrit la minuterie contrôlée et
supervisée par systemd
pour l’activation basée sur une
minuterie. Consulter systemd.timer
(5) ;
*.slice gère les ressources avec
cgroups
(7). Consulter
systemd.slice
(5) ;
*.scope est créé de manière
programmatique à l’aide des interfaces de bus de systemd
pour gérer un ensemble de processus système. Consulter
systemd.scope
(5) ;
*.target regroupe d'autres fichiers de
configuration d’unité pour créer le point de synchronisation au
démarrage. Consulter systemd.target
(5).
Au démarrage du système (c’est-à-dire init), le processus
systemd
tente de démarrer le
« /lib/systemd/system/default.target
(normalement lié
symboliquement lié à « graphical.target
»). Tout d’abord,
certaines unités cibles spéciales (consulter
systemd.special
(7)) telles que
« local-fs.target
», « swap.target
»
et « cryptsetup.target
» sont extraites pour monter les
systèmes de fichiers. Ensuite, d’autres unités cibles sont également
extraites par les dépendances de l’unité cible. Pour plus d’informations,
lisez bootup
(7).
systemd
offre des fonctionnalités de
rétrocompatibilité. Les scripts de démarrage de style SysV dans
« /etc/init.d/rc[0123456S].d/[KS]nom
»
sont toujours analysés et telinit
(8) est traduit en
demandes d’activation d’unité systemd.
Attention | |
---|---|
Les niveaux d’exécution émulés 2 à 4 sont tous liés symboliquement au même
« |
Quand un utilisateur se connecte sur un système Debian à l’aide de
gdm3
(8), sshd
(8), etc.,
/lib/systemd/system --user
est démarré comme processus de
gestionnaire de services de l’utilisateur, propriété de l’utilisateur
correspondant (consulter systemd
(1)).
Le gestionnaire systemd
de services de l’utilisateur
génère des processus en parallèle en se basant sur les fichiers de
configuration des unités (consulter systemd.unit
(5)) de
style déclaratif et [email protected]
(5)).
Les unités pour le mode utilisateur sont chargées à partir du « Chemin de
recherche d’unités de l’utilisateur » décrit dans
systemd.unit
(5). Les principales sont les suivantes par
ordre de priorité :
« ~/.config/systemd/user/*
» : unités de configuration de
l’utilisateur ;
« /etc/systemd/user/*
» : unités de l’utilisateur créés
par l’administrateur ;
« /run/systemd/user/*
» : unités d’exécution ;
« /lib/systemd/user/*
» : unités de l’utilisateur
installées par le gestionnaire de paquets de la distribution.
Elles sont gérées de la même façon que dans la Section 3.2.1, « Initialisation avec Systemd ».
Le message d’erreur du noyau affiché sur la console peut être configuré en définissant son seuil :
# dmesg -n3
Tableau 3.4. Liste des niveaux d’erreur du noyau
valeur du niveau d’erreur | nom du niveau d’erreur | signification |
---|---|---|
0 | KERN_EMERG | le système est inutilisable |
1 | KERN_ALERT | une action doit être entreprise immédiatement |
2 | KERN_CRIT | conditions critiques |
3 | KERN_ERR | conditions d’erreur |
4 | KERN_WARNING | conditions d’avertissement |
5 | KERN_NOTICE | condition normale mais significative |
6 | KERN_INFO | information |
7 | KERN_DEBUG | messages du niveau de débogage |
Sous systemd
, les messages du noyau et du système sont
consignés par le service de journal
systemd-journald.service
(alias
journald
) soit comme données binaires persistantes dans
« /var/log/journal
» ou comme données binaires volatiles
dans « /run/log/journal/
». Ces données binaires de
journal sont accessibles avec la commande
journalctl
(1). Par exemple, vous pouvez afficher le
journal du dernier démarrage avec :
$ journalctl -b
Tableau 3.5. Liste de bribes de commande utilisant journalctl
Opération | bribe de commande |
---|---|
Afficher le journal des services système et du noyau depuis le dernier démarrage | « journalctl -b --system » |
Afficher le journal des services de l'utilisateur actuel depuis le dernier démarrage | « journalctl -b --user » |
Afficher le journal des tâches de « $unit » depuis le
dernier démarrage |
« journalctl -b -u $unit » |
Afficher le journal des tâches de « $unit » (style
« tail -f ») depuis le dernier démarrage |
« journalctl -b -u $unit -f » |
Sous systemd
, l’utilitaire de journalisation du système
rsyslogd
(8) peut n’être pas installé. S’il est installé,
il modifie son comportement pour lire les données binaires volatiles du
journal (au lieu de la valeur par défaut avant systemd
« /dev/log
») et pour créer des données ASCII permanentes
traditionnelles de journal du système . Cela peut être personnalisé avec
« /etc/default/rsyslog
» et
« /etc/rsyslog.conf
» pour à la fois le fichier journal
et l’affichage à l’écran. Voir rsyslogd
(8) et
rsyslog.conf
(5). Voir aussi Section 9.3.2, « Analyseur de journaux ».
systemd
offre non seulement un système d’initialisation,
mais aussi des opérations génériques de gestion du système avec la commande
systemctl
(1).
Tableau 3.6. Liste de bribes de commande typiques utilisant journalctl
Opération | bribe de commande |
---|---|
Lister toutes les types d’unités disponibles | « systemctl list-units --type=aide » |
Lister toutes les unités cibles en mémoire | « systemctl list-units --type=target » |
Lister toutes les unités de service en mémoire | « systemctl list-units --type=service » |
Lister toutes les unités de périphérique en mémoire | « systemctl list-units --type=device » |
Lister toutes les unités de montage en mémoire | « systemctl list-units --type=mount » |
Lister toutes les unités de sockets en mémoire | « systemctl list-sockets » |
Lister toutes les unités de minuterie en mémoire | « systemctl list-timers » |
Démarrer « $unit » |
« systemctl start $unit » |
Stopper « $unit » |
« systemctl stop $unit » |
Recharger une configuration particulière à un service | « systemctl reload $unit » |
Arrêter et démarrer tous les « $unit » |
« systemctl restart $unit » |
Démarrer « $unit » et arrêter tous les autres |
« systemctl isolate $unit » |
Basculer vers « graphical » (système GUI) |
« systemctl isolate graphical » |
Basculer vers « multi-user » (système CLI) |
« systemctl isolate multi-user » |
Basculer vers « rescue » (système CLI
mono-utilisateur) |
« systemctl isolate rescue » |
Envoyer le signal kill à « $unit » |
« systemctl kill $unit » |
Vérifier si le service « $unit » est actif |
« systemctl is-active $unit » |
Vérifier si le service « $unit » est défaillant |
« systemctl is-failed $unit » |
Vérifier l’état de « $unit|$PID|périphérique » |
"systemctl status $unit|$PID|$device " |
Afficher les propriétés de « $unit|$job » |
« systemctl show $unit|$job » |
Réinitialiser « $unit » défaillant |
« systemctl reset-failed $unit » |
Lister les dépendances de tous les services d’unités | « systemctl list-dependencies --all » |
Lister les fichiers d’unités installés sur le système | « systemctl list-unit-files » |
Activer « $unit » (ajout de lien symbolique) |
« systemctl enable $unit » |
Désactiver « $unit » (suppression de lien
symbolique) |
« systemctl disable $unit » |
Démasquer « $unit » (suppression de lien
symbolique vers « /dev/null ») |
« systemctl unmask $unit » |
Masquer « $unit » (ajout de lien symbolique
vers « /dev/null ») |
« systemctl mask $unit » |
Obtenir le réglage de la cible par défaut | « systemctl get-default » |
Définir la cible par défaut à « graphical »
(système à interface graphique) |
« systemctl set-default graphical » |
Définir la cible par défaut à « multi-user »
(système en ligne de commande) |
« systemctl set-default multi-user » |
Afficher l’environnement de travail | « systemctl show-environment » |
Définir la « variable » d’environnement de
travail à « valeur » |
« systemctl set-environment variable=valeur » |
Rendre indéfini la « variable » d’environnement
de travail |
« systemctl unset-environment variable » |
Recharger tous les démons et fichiers d’unité | « systemctl daemon-reload » |
Arrêter le système | « systemctl poweroff » |
Arrêter et redémarrer le système | « systemctl reboot » |
Suspendre le système | « systemctl suspend » |
Hiberner le système | « systemctl hibernate » |
Ici, « $unit
» dans les exemples ci-dessus peut être un
nom d’unité unique (les suffixes tels que .service
et
.cible
sont facultatifs) ou, dans de nombreux cas, des
spécifications d’unité multiples (modèles génériques de type interpréteur
« *
», « ?
»,
« []
» en utilisant fnmatch
(3) qui
seront comparés aux noms principaux de toutes les unités actuellement en
mémoire).
Les commandes de modification d’état du système dans les exemples ci-dessus
sont classiquement précédées par la commande
« sudo
» pour obtenir les droits
d’administration nécessaires.
La sortie de « systemctl status
$unit|$PID|$device
» utilise des points de couleur
(« ● ») pour examiner l’état de l’unité d’un seul coup d’œil.
Un « ● » blanc indique un état « inactif » ou « désactivation ».
Un « ● » rouge indique un état « échec » ou « erreur ».
Un « ● » vert indique un état « actif », « rechargement » ou « activation ».
Voici une liste d’autres bribes de commandes de surveillance sous
systemd
. Veuillez lire les pages de manuel pertinentes, y
compris cgroups
(7).
Tableau 3.7. Liste d’autres bribes de commandes de surveillance sous
systemd
Opération | bribe de commande |
---|---|
Afficher la durée de toutes les étapes d’initialisation | « systemd-analyze time » |
Lister toutes les unités selon leurs temps d’initialisation | « systemd-analyze blame » |
Charger et détecter les erreurs dans le fichier
« $unit » |
« systemd-analyze verify $unit » |
Afficher des informations d’état d’exécution succinctes de l’utilisateur de la session de l’appelant | « loginctl user-status » |
Afficher des informations succinctes sur l'état d'exécution de la session de l'appelant | « loginctl user-status » |
Suivre le processus de démarrage selon les cgroups | « systemd-cgls » |
Suivre le processus de démarrage selon les cgroups | « ps xawf -eo pid,user,cgroup,args » |
Suivre le processus de démarrage selon les cgroups | Lire sysfs sous
"/sys/fs/cgroup/ " |
Le noyau gère le système nom_machine. L’unité centrale démarrée par
systemd-hostnamed.service
définit le nom de machine du
système au démarrage au nom stocké dans
« /etc/hostname
». Ce fichier doit contenir uniquement le nom de machine du système et non un
nom de domaine pleinement qualifié.
Pour afficher le nom de la machine utilisée, lancez la commande
hostname
(1) sans paramètre.
Les options de montage des systèmes ordinaires de fichiers de disque et en
réseau sont définies dans « /etc/fstab
». Consulter
fstab
(5) et Section 9.6.7, « Optimisation du système de fichiers à l’aide des options de montage ».
La configuration du système de fichiers chiffré est définie dans
« /etc/crypttab
». Consulter
crypttab
(5).
La configuration du RAID logiciel avec mdadm
(8) est
définie dans « /etc/mdadm/mdadm.conf
». Consulter
mdadm.conf
(5).
Avertissement | |
---|---|
Une fois tous les systèmes de fichiers montés, les fichiers temporaires se
trouvant dans « |
Les interfaces réseau sont ordinairement initialisées dans
« networking.service
» pour l’interface
lo
et
« NetworkManager.service
» pour les autres
interfaces sur les systèmes de bureau modernes de Debian sous
systemd
.
Voir Chapitre 5, Configuration du réseau pour savoir comment les configurer.
L’instance du système d’infonuagique peut être lancée comme un clone des
« Images officielles de Debian pour
l’infonuagique » ou des images similaires. Pour une telle instance
de système, les personnalités telles que le nom d’hôte, le système de
fichiers, le réseautage, la régionalisation, les clés SSH, les utilisateurs
et les groupes peuvent être configurées en utilisant des fonctionnalités
fournies par les paquets cloud-init
et
netplan.io
avec plusieurs sources de données telles que
les fichiers placés dans l’image originelle du système et des données
externes fournies lors de son amorçage. Ces paquets activent la
configuration déclarative du système utilisant des données YAML.
Pour plus de détails, consulter « L’infonuagique avec Debian et ses descendants », la « documentation de Cloud-init » et la Section 5.4, « Configuration moderne de réseau pour l’infonuagique ».
Avec l'installation par défaut, de nombreux services réseau (consulter Chapitre 6, Applications réseau) sont démarrés comme processus démon après
network.target
au démarrage par
systemd
. Le démon « sshd
»
ne fait pas exception. Changeons donc cela pour un démarrage sur demande de
« sshd
» comme exemple de personnalisation.
Tout d’abord, désactivons l’unité de service du système installée.
$ sudo systemctl stop sshd.service $ sudo systemctl mask sshd.service
Le système d’activation de socket à la demande des services Unix classiques
passait par le superserveur inetd
(ou
xinetd
). Sous systemd
, l’équivalent
peut être activé en ajoutant les fichiers de configuration d’unité *.socket et *.service.
sshd.socket
pour indiquer un socket sur lequel écouté
[Unit] Description=SSH Socket for Per-Connection Servers [Socket] ListenStream=22 Accept=yes [Install] WantedBy=sockets.target
[email protected]
comme fichier de service correspondant de
sshd.socket
[Unit] Description=SSH Per-Connection Server [Service] ExecStart=-/usr/sbin/sshd -i StandardInput=socket
Puis rechargez.
$ sudo systemctl daemon-reload
Le système udev fournit un mécanisme de
découverte et d’initialisation automatique du matériel (consulter
udev
(7)) depuis le noyau 2.6 de Linux. Lors de la
découverte de chaque périphérique par le noyau, le système udev lance un
processus utilisateur qui utilise les informations provenant du système de
fichiers sysfs (consulter Section 1.2.12, « procfs et sysfs »), charge les modules du noyau nécessaires pour
sa prise en charge en utilisant le programme modprobe
(8)
(consulter la Section 3.9, « Initialisation des modules du noyau ») et crée
les nœuds de périphérique en conséquence.
Astuce | |
---|---|
Si
« Les nœuds de périphériques n’ont pas besoin d’être statiques pour les règles
de montage se trouvant dans
« |
Comme le système udev est une cible quelque peu mouvante, je laisse les détails pour d’autres documentations et je ne donnerai ici qu’un minimum d’informations.
Avertissement | |
---|---|
N’essayez pas d’exécuter des programmes d’exécution longue tels qu’un script
de sauvegarde avec |
Le programme modprobe
(8) nous permet de configurer,
depuis un processus utilisateur, un noyau Linux en cours d’exécution en
ajoutant ou en supprimant des modules du noyau. Le système udev (consultez
Section 3.8, « Le système udev ») en automatise l’appel afin d’aider à
l’initialisation du module du noyau.
Il existe des modules non liés au matériel et des modules qui pilotent des
éléments matériels particuliers comme les suivants qui demandent à être
préchargés en les déclarant dans le fichier
« /etc/modules
» (consultez
modules
(5)).
les modules TUN/TAP fournissent un périphérique de réseau virtuel point-à-point (TUN) et un périphérique de réseau virtuel Ethernet (TAP) ;
les modules netfilter fournissent les
fonctions de pare-feu netfilter (iptables
(8), Section 5.7, « Infrastructure de netfilter ») ;
le module du pilote du temporisateur de chien de garde.
Les fichiers de configuration du programme modprobe
(8) se
trouvent dans le répertoire
« /etc/modprobes.d/
» comme c’est expliqué dans
modprobe.conf
(5). (Si vous souhaitez que certains modules
du noyau ne soient pas chargés automatiquement, vous pouvez les mettre en
liste noire dans le
fichier« /etc/modprobes.d/blacklist
».)
Le fichier
« /lib/modules/version/modules.dep
»
généré par le programme depmod
(8) décrit les dépendances
des modules utilisés par le programme modprobe
(8).
Note | |
---|---|
Si vous rencontrez des problèmes de chargement de modules lors du chargement
des modules au démarrage ou avec |
Le programme modinfo
(8) affiche des informations
concernant les modules du noyau.
Le programme lsmod
(8) formate de manière agréable le
contenu de « /proc/modules
», affichant quels
sont les modules du noyau actuellement chargés.
Astuce | |
---|---|
Vous pouvez identifier le matériel exact installé sur votre système. Consultez Section 9.5.3, « Identification du matériel ». Vous pouvez configurer le matériel au moment du démarrage pour activer les fonctionnalités désirées de ce matériel. Consultez Section 9.5.4, « Configuration matérielle ». Vous pouvez probablement ajouter la prise en charge d’un périphérique particulier en recompilant le noyau. Consultez Section 9.10, « Le noyau ». |