il y a 1 an

Debian : les fichiers de configuration essentiels à connaître

Dans l’univers Debian, une quantité impressionnante de décisions administratives finit tôt ou tard sous forme de texte.

Nom de la machine, montages de disques, utilisateurs, DNS, SSH, paramètres du noyau, services, tâches planifiées, dépôts APT, serveur web : derrière beaucoup de ces mécanismes se trouve un fichier de configuration que l’administrateur peut lire, sauvegarder, comparer et, avec suffisamment de créativité, rendre parfaitement inutilisable.

Le répertoire le plus célèbre est évidemment :

/etc

Mais comprendre Debian moderne demande une nuance importante :

/etc contient principalement la configuration locale administrable de la machine. Cela ne signifie pas que tous les paramètres du système vivent exclusivement dans /etc.

Des valeurs par défaut peuvent être fournies sous /usr, des états persistants vivent sous /var/lib, des données temporaires sous /run, et certains logiciels construisent leur configuration à partir de plusieurs couches.

Le véritable talent du sysadmin n’est donc pas de connaître par cœur quatre cents fichiers.

C’est de savoir :

quel composant possède le fichier ;
qui le génère ;
quelle couche a priorité ;
comment vérifier la syntaxe ;
comment appliquer le changement ;
et surtout comment revenir en arrière lorsque la documentation disait « simplement ».

/etc : le territoire de la configuration locale

Dans la logique traditionnelle Unix, /etc contient principalement les fichiers de configuration spécifiques à la machine.

On y trouve par exemple :

/etc/hostname
/etc/hosts
/etc/fstab
/etc/passwd
/etc/ssh/
/etc/systemd/
/etc/network/
/etc/samba/
/etc/apache2/
/etc/apt/

Mais tous ces fichiers ne doivent pas nécessairement être modifiés directement.

Certains sont administrés par :

un outil spécialisé ;
un gestionnaire réseau ;
un gestionnaire de paquets ;
un mécanisme de génération ;
ou un service systemd.

La première question avant :

nano /etc/truc.conf

devrait donc être :

« Qui contrôle réellement ce fichier ? »

Ce qui évite la situation classique où l’administrateur modifie avec soin douze lignes avant qu’un service ne les remplace automatiquement avec une remarquable absence de remords.

Une règle générale : ne modifiez pas avant d’avoir regardé

Avant toute modification importante :

sudo cp /etc/fichier.conf /etc/fichier.conf.bak

Mais une sauvegarde seule ne remplace pas la compréhension.

Commencez également par regarder :

ls -l /etc/fichier.conf
file /etc/fichier.conf
readlink -f /etc/fichier.conf

Vous découvrirez parfois que le « fichier » que vous alliez modifier est en réalité :

un lien symbolique ;
un fichier généré ;
une configuration incluse par une autre ;
ou un fichier qui n’est même plus lu par le service.

/etc/hostname : le nom statique de la machine

Le fichier :

/etc/hostname

définit normalement le nom d’hôte statique du système.

Il contient généralement une seule étiquette DNS courte, par exemple :

srv-fichiers

Il est généralement préférable d’éviter d’y écrire directement un FQDN comme :

srv-fichiers.example.com

et de conserver :

srv-fichiers

comme hostname statique.

Pour consulter la situation :

hostnamectl

Pour modifier proprement le hostname :

sudo hostnamectl hostname srv-fichiers

Le fichier /etc/hostname sera alors géré en conséquence.

Hostname court et FQDN ne sont pas exactement la même chose

Le hostname local peut être :

srv-fichiers

tandis que le nom DNS complet est :

srv-fichiers.example.com

Le FQDN dépend du système de résolution de noms : DNS, /etc/hosts ou autres mécanismes configurés.

Pour examiner :

hostname
hostname --fqdn

les deux commandes ne posent donc pas exactement la même question.

/etc/hosts : la petite base de noms locale

Le fichier :

/etc/hosts

associe localement des adresses IP et des noms.

Exemple :

127.0.0.1       localhost
127.0.1.1       srv-fichiers.example.com srv-fichiers

192.168.10.20   nas.example.com nas

Son format général est :

adresse_IP nom_canonique alias1 alias2

Il est utile pour :

les noms locaux ;
certains tests ;
le démarrage d’une infrastructure sans DNS complet ;
des associations volontairement statiques.

/etc/hosts passe-t-il forcément avant DNS ?

Pas nécessairement.

L’ordre réel des sources de résolution est déterminé notamment par :

/etc/nsswitch.conf

Une ligne peut par exemple contenir :

hosts: files dns

Dans ce cas :

les fichiers locaux sont interrogés ;
puis DNS si nécessaire.

Mais une configuration utilisant systemd-resolved ou d’autres modules NSS peut être plus sophistiquée.

/etc/hosts fournit une source locale. /etc/nsswitch.conf détermine comment cette source s’intègre aux autres mécanismes de résolution.

/etc/nsswitch.conf : qui devons-nous interroger ?

Le Name Service Switch permet de choisir les sources utilisées pour différentes bases d’informations.

On rencontre notamment :

passwd:
group:
shadow:
hosts:
networks:
services:

Une configuration simplifiée pourrait ressembler à :

passwd: files systemd
group:  files systemd
shadow: files systemd
hosts:  files dns

Le système peut aussi intégrer :

LDAP ;
SSSD ;
systemd-resolved ;
mDNS ;
NIS sur quelques sites ayant refusé plusieurs décennies d’évolution.

Pour tester le mécanisme NSS plutôt que d’interroger directement DNS :

getent hosts serveur.example.com

Pour un utilisateur :

getent passwd alice

C’est souvent préférable à :

grep alice /etc/passwd

car Alice peut parfaitement provenir d’un annuaire distant et ne pas exister dans le fichier local.

/etc/resolv.conf : le fichier que tout le monde veut gérer

Traditionnellement :

/etc/resolv.conf

décrit certains paramètres du résolveur DNS.

Un fichier classique pourrait contenir :

nameserver 192.168.10.10
nameserver 192.168.10.11
search example.com

Mais sur une Debian moderne, il ne faut pas immédiatement en conclure :

« Je veux changer le DNS, donc j’édite resolv.conf. »

Commencez par :

ls -l /etc/resolv.conf

Vous pourriez découvrir qu’il s’agit d’un lien symbolique.

Qui peut gérer resolv.conf ?

Selon l’installation, les informations DNS peuvent être administrées par :

NetworkManager ;
systemd-resolved ;
un client DHCP ;
resolvconf ;
une configuration statique ;
un autre outil réseau.

Avec systemd-resolved, on peut rencontrer :

/etc/resolv.conf
→ /run/systemd/resolve/stub-resolv.conf

et :

nameserver 127.0.0.53

Ce :

127.0.0.53

n’est alors pas votre serveur DNS d’entreprise.

C’est le stub resolver local de systemd-resolved.

Examiner le DNS réel

Si systemd-resolved est utilisé :

resolvectl status

Avec NetworkManager :

nmcli device show

Vous obtenez alors les DNS réellement associés aux interfaces et connexions.

C’est nettement plus informatif que d’insulter resolv.conf parce qu’il refuse de conserver les deux lignes que vous venez d’ajouter pour la quatrième fois.

Configuration réseau : il n’existe pas un fichier universel

Debian peut utiliser plusieurs gestionnaires de réseau.

Les trois familles les plus fréquentes sont :

Gestionnaire	Configuration typique
ifupdown / ifupdown2	`/etc/network/interfaces` et `/etc/network/interfaces.d/`
NetworkManager	`/etc/NetworkManager/` et profils de connexion
systemd-networkd	`/etc/systemd/network/*.network`

La bonne méthode consiste à savoir quel outil possède l’interface.

Configurer la même carte avec trois gestionnaires différents transforme rapidement :

192.168.10.20/24

en débat institutionnel.

/etc/network/interfaces : le monde ifupdown

Si le système utilise ifupdown :

/etc/network/interfaces

reste parfaitement valide.

Exemple DHCP :

auto enp1s0
iface enp1s0 inet dhcp

Exemple statique :

auto enp1s0
iface enp1s0 inet static
    address 192.168.10.20/24
    gateway 192.168.10.1

La configuration peut également inclure :

source /etc/network/interfaces.d/*

afin de répartir les interfaces dans plusieurs fichiers.

NetworkManager

Sur une installation Debian avec environnement graphique, NetworkManager est fréquent.

On le configure généralement avec :

nmcli

ou une interface graphique.

Ses profils persistants se trouvent typiquement sous :

/etc/NetworkManager/system-connections/

Ces fichiers peuvent contenir des secrets.

Leur protection n’est donc pas décorative.

Pour voir les connexions :

nmcli connection show

systemd-networkd

systemd-networkd utilise des fichiers comme :

/etc/systemd/network/20-wired.network

Exemple :

[Match]
Name=enp1s0

[Network]
Address=192.168.10.20/24
Gateway=192.168.10.1
DNS=192.168.10.10

Pour examiner l’état :

networkctl

ou :

networkctl status enp1s0

/etc/passwd : les comptes locaux

Le fichier :

/etc/passwd

contient les informations principales concernant les comptes locaux.

Une ligne ressemble à :

alice:x:1001:1001:Alice Dupont:/home/alice:/bin/bash

Les sept champs représentent :

nom de connexion ;
champ historique du mot de passe ;
UID ;
GID principal ;
champ GECOS / commentaire ;
répertoire personnel ;
shell.

Le :

indique normalement que les données d’authentification correspondantes se trouvent dans le fichier système Linux shadow, situé dans le répertoire /etc.

Le fichier shadow de /etc : des empreintes, pas le mot de passe

Le fichier shadow situé dans le répertoire /etc contient notamment les données relatives au mot de passe et à son vieillissement.

Une précision importante :

Le mot de passe n’y est normalement pas stocké sous une forme simplement déchiffrable. On conserve une empreinte cryptographique produite avec une fonction de dérivation adaptée.

Il est donc préférable de parler de :

hash de mot de passe

plutôt que de :

mot de passe chiffré

au sens d’un chiffrement réversible.

Le fichier doit être protégé contre les lectures par les utilisateurs ordinaires.

Pour afficher des informations de vieillissement :

sudo chage -l alice

N’éditez pas passwd et shadow avec nano pour le plaisir

Des outils spécialisés existent :

useradd
adduser
usermod
userdel
passwd
chage

Et lorsque l’édition directe est réellement nécessaire :

vipw

ou :

vipw -s

fournissent un environnement plus sûr.

Une faute de frappe dans le shell d’Alice est gênante.

Une faute de frappe dans la ligne de root possède davantage de potentiel éducatif.

Les fichiers group et gshadow de /etc

/etc/group décrit les groupes locaux.

Une ligne peut ressembler à :

sambadocs:x:1200:alice,bob

On retrouve :

nom du groupe ;
champ de mot de passe historique ;
GID ;
liste de membres supplémentaires.

Le fichier gshadow situé dans le répertoire /etc contient les informations protégées associées aux groupes.

Pour gérer les groupes :

groupadd
groupmod
groupdel
gpasswd
usermod -aG

restent généralement préférables à l’édition artisanale.

/etc/login.defs : des valeurs par défaut, pas toute l’authentification

Le fichier :

/etc/login.defs

fournit différentes valeurs utilisées notamment par les outils de gestion des comptes.

On peut y rencontrer :

plages UID/GID ;
comportements de création ;
certaines valeurs relatives aux mots de passe ;
paramètres historiques des outils shadow.

Mais il ne faut pas imaginer :

« Toute la politique de connexion Linux se trouve dans login.defs. »

L’authentification moderne passe largement par PAM.

/etc/pam.d : le panneau électrique de l’authentification

PAM — Pluggable Authentication Modules permet aux applications de déléguer plusieurs fonctions :

authentification ;
gestion des comptes ;
gestion des mots de passe ;
ouverture et fermeture de sessions.

La configuration locale se trouve principalement sous :

/etc/pam.d/

On peut y rencontrer :

/etc/pam.d/login
/etc/pam.d/su
/etc/pam.d/sudo
/etc/pam.d/sshd
/etc/pam.d/common-auth
/etc/pam.d/common-account
/etc/pam.d/common-password
/etc/pam.d/common-session

PAM mérite beaucoup de respect

Une ligne PAM incorrecte peut empêcher :

les connexions SSH ;
sudo ;
su ;
les connexions locales ;
ou plusieurs de ces mécanismes simultanément.

Autrement dit, PAM est parfaitement capable de vous laisser la machine en état de marche tout en vous expliquant que vous n’êtes plus invité.

Sous Debian, l’outil :

pam-auth-update

est utilisé pour administrer certains profils PAM communs.

/etc/security : politiques complémentaires

On rencontre notamment :

/etc/security/limits.conf
/etc/security/limits.d/
/etc/security/access.conf

selon les modules PAM utilisés.

Par exemple, limits.conf peut définir des limites de ressources appliquées à certaines sessions.

Mais ces paramètres n’agissent que lorsque le mécanisme chargé de les lire est réellement utilisé.

Un fichier de configuration ignoré reste techniquement très bien écrit.

Il n’en devient pas plus efficace.

/etc/sudoers : qui peut devenir qui ?

Le fichier :

/etc/sudoers

définit les politiques de sudo lorsque le plugin sudoers est utilisé.

Une règle simple pourrait ressembler à :

%admins ALL=(ALL:ALL) ALL

Mais :

n’éditez pas /etc/sudoers avec un éditeur ordinaire lorsque visudo peut effectuer des contrôles pour vous.

Utilisez :

sudo visudo

/etc/sudoers.d : mieux que de tout mettre dans un fichier

Le fichier principal Debian inclut généralement :

/etc/sudoers.d/

On peut donc créer par exemple :

/etc/sudoers.d/support

puis l’éditer avec :

sudo visudo -f /etc/sudoers.d/support

Pour contrôler l’ensemble :

sudo visudo -c

Attention aux noms de fichiers dans sudoers.d : certains noms contenant un point ou terminés par ~ peuvent être ignorés.

Le classique :

admins.conf

peut donc constituer exactement le genre de nom parfaitement logique pour un humain et parfaitement ignoré par le mécanisme d’inclusion.

/etc/fstab : les systèmes de fichiers persistants

/etc/fstab décrit les systèmes de fichiers que le système sait monter et diverses propriétés associées.

Une ligne typique :

UUID=1234-5678  /srv/data  ext4  defaults  0  2

Les champs sont :

source ;
point de montage ;
type de système de fichiers ;
options ;
champ historique utilisé par dump ;
ordre de vérification fsck.

Utilisez les UUID lorsque c’est approprié

Plutôt que :

/dev/sdb1

il est généralement préférable pour un montage persistant d’utiliser :

UUID=...

car le nom :

/dev/sdb

peut changer selon l’ordre de détection des périphériques.

Pour afficher les UUID :

lsblk -f

ou :

blkid

Une erreur fstab ne signifie pas toujours « plus aucun boot »

La gravité dépend :

du système de fichiers ;
de son importance ;
des options comme nofail ;
du gestionnaire d’init ;
du type de montage.

Une entrée incorrecte peut :

simplement faire échouer ce montage ;
ralentir le démarrage ;
faire basculer le système en mode d’urgence ;
ou empêcher un composant critique d’être disponible.

La formulation :

« Une virgule manquante et le serveur ne redémarrera jamais. »

est donc une excellente histoire à raconter aux stagiaires, mais pas une règle technique.

Valider fstab avant de redémarrer

Après modification :

sudo findmnt --verify --verbose

Puis, lorsque cela est approprié :

sudo mount -a

Sur un système systemd, après une modification de fstab :

sudo systemctl daemon-reload

est également recommandé afin que les unités de montage générées soient actualisées.

Redémarrer la machine uniquement pour découvrir une faute de syntaxe est une forme de test d’intégration particulièrement dramatique.

/etc/sysctl.conf et /etc/sysctl.d : paramètres du noyau

Les paramètres sysctl permettent de modifier différentes valeurs exposées par le noyau.

Exemples :

net.ipv4.ip_forward
vm.swappiness
kernel.dmesg_restrict

On peut lire une valeur :

sysctl net.ipv4.ip_forward

et en changer certaines temporairement :

sudo sysctl -w net.ipv4.ip_forward=1

Pour la configuration persistante, pensez sysctl.d

L’ancien fichier :

/etc/sysctl.conf

reste connu et utilisé dans différents environnements.

Mais les systèmes modernes utilisent également largement :

/etc/sysctl.d/*.conf

Par exemple :

/etc/sysctl.d/99-local.conf

contenant :

net.ipv4.ip_forward = 1

Pour charger les configurations :

sudo sysctl --system

Les répertoires peuvent inclure :

/usr/lib/sysctl.d/
/usr/local/lib/sysctl.d/
/run/sysctl.d/
/etc/sysctl.d/

avec des règles de priorité et d’ordre.

Une fois encore, Debian moderne aime les couches.

Parce qu’un seul fichier aurait beaucoup trop simplifié la question :

« Qui a changé cette valeur ? »

systemd : ne modifiez pas les unités fournisseur directement

Avec systemd, les unités provenant des paquets vivent normalement sous :

/usr/lib/systemd/system/

Par exemple :

/usr/lib/systemd/system/ssh.service

La configuration créée ou surchargée par l’administrateur appartient plutôt à :

/etc/systemd/system/

Évitez d’éditer directement le fichier sous /usr/lib/systemd/system : une mise à jour du paquet peut le remplacer.

Voir la configuration réellement utilisée par systemd

Pour un service :

systemctl cat ssh.service

Cette commande affiche :

le fichier principal ;
les éventuels drop-ins ;
leur provenance.

C’est beaucoup plus fiable que d’ouvrir un fichier au hasard puis de conclure :

« Pourtant la ligne est bien là. »

Créer une surcharge avec systemctl edit

Pour modifier quelques paramètres :

sudo systemctl edit ssh.service

systemd peut créer un drop-in ressemblant à :

/etc/systemd/system/ssh.service.d/override.conf

Par exemple :

[Service]
Restart=on-failure

Le fichier fourni par Debian reste intact.

La surcharge locale est clairement séparée.

daemon-reload n’est pas restart

Après avoir changé une définition d’unité :

sudo systemctl daemon-reload

demande à systemd de relire les fichiers d’unités.

Cela ne signifie pas automatiquement :

redémarrer le service

Si nécessaire :

sudo systemctl restart service

ou :

sudo systemctl reload service

selon les capacités du démon.

Valider une unité systemd

Pour certaines vérifications :

systemd-analyze verify /etc/systemd/system/monservice.service

Et pour comprendre l’état réel :

systemctl status monservice
journalctl -u monservice

/etc/default : des paramètres propres aux paquets

Le répertoire :

/etc/default/

contient historiquement différents fichiers utilisés par des scripts et paquets Debian.

Exemples possibles :

/etc/default/grub
/etc/default/keyboard
/etc/default/locale

Il ne s’agit pas d’un mécanisme universel où systemd irait automatiquement charger tous les fichiers.

Un fichier sous /etc/default n’a d’effet que si un programme ou un script est conçu pour le lire.

La présence du fichier ne suffit pas à invoquer son esprit.

/etc/init.d : l’héritage SysV toujours visible

Le répertoire :

/etc/init.d/

contient des scripts d’init de style SysV.

Debian utilise aujourd’hui systemd par défaut, mais conserve des mécanismes de compatibilité avec certains scripts traditionnels.

On peut donc encore rencontrer :

/etc/init.d/ssh
/etc/init.d/cron

sans que cela signifie que systemd a mystérieusement disparu pendant la nuit.

GRUB : modifiez la source, pas le fichier généré

Pour GRUB, un fichier important est :

/etc/default/grub

On y rencontre par exemple :

GRUB_TIMEOUT=5
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

Des scripts vivent également sous :

/etc/grub.d/

Après modification :

sudo update-grub

génère la configuration finale.

Évitez d’éditer directement grub.cfg

Le fichier :

/boot/grub/grub.cfg

est normalement généré.

Un commentaire visible en haut du fichier essaie d’ailleurs généralement de communiquer ce concept à l’administrateur.

L’éditer directement peut fonctionner.

Jusqu’au prochain :

update-grub

qui nettoiera votre travail avec toute la délicatesse d’un rouleau compresseur parfaitement conforme à sa documentation.

SSH : sshd_config côté serveur

La configuration principale du serveur OpenSSH se trouve à :

/etc/ssh/sshd_config

À ne pas confondre avec :

/etc/ssh/ssh_config

qui concerne principalement le client SSH.

Fichier	Rôle
`sshd_config`	Serveur SSH
`ssh_config`	Client SSH

Les drop-ins sshd_config.d

Debian utilise également :

/etc/ssh/sshd_config.d/*.conf

pour des fragments de configuration.

Point subtil : OpenSSH n’applique pas nécessairement une logique simple de type :

« la dernière valeur écrite gagne toujours ».

Pour de nombreux paramètres, la première valeur obtenue est conservée.

Les fragments inclus et leur ordre ont donc de l’importance.

Plutôt que de deviner, demandez à SSH ce qu’il comprend réellement.

Valider SSH avant de recharger

Après modification :

sudo sshd -t

Cette commande vérifie la syntaxe et la cohérence générale.

Pour afficher la configuration effective :

sudo sshd -T

Puis seulement :

sudo systemctl reload ssh

Sur une machine distante, gardez idéalement votre session SSH actuelle ouverte pendant le test.

Fermer volontairement votre seule session avant de vérifier que la nouvelle configuration accepte encore les connexions constitue une méthode très pure d’apprentissage par conséquence.

Les clés SSH

Les clés d’hôte du serveur se trouvent généralement sous :

/etc/ssh/ssh_host_*

Elles représentent l’identité cryptographique du serveur.

Ne les copiez pas aveuglément entre machines.

Deux serveurs présentant exactement la même identité SSH provoquent le même genre de malaise qu’une frontière découvrant deux personnes avec le même passeport et la même photo.

Le pare-feu Debian : pensez nftables

Les outils :

ufw
firewalld

peuvent être installés et utilisés.

Mais ils ne constituent pas des fichiers de configuration fondamentaux présents sur toute Debian.

Le framework moderne du noyau est :

nftables

et le paquet Debian fournit normalement :

/etc/nftables.conf

Un exemple minimal nftables

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0;
        policy drop;

        ct state established,related accept
        iifname "lo" accept

        tcp dport 22 accept
    }
}

Ce n’est qu’un exemple pédagogique.

Une politique réelle doit être adaptée à l’infrastructure, IPv6 compris.

Valider nftables avant de couper votre SSH

Pour vérifier la syntaxe sans appliquer :

sudo nft -c -f /etc/nftables.conf

Pour afficher les règles actuellement actives :

sudo nft list ruleset

Pour activer le chargement au démarrage lorsque le paquet est utilisé :

sudo systemctl enable --now nftables

Évitez de mélanger sans raison :

règles nft directes ;
UFW ;
firewalld ;
scripts iptables ;
et trois commandes copiées depuis Stack Overflow en 2014.

Lorsque cinq systèmes pensent tous gérer le pare-feu, le résultat possède rarement cinq fois plus de sécurité.

/etc/hosts.allow et /etc/hosts.deny : TCP Wrappers

Ces fichiers appartiennent au mécanisme historique :

TCP Wrappers / libwrap

On peut rencontrer :

/etc/hosts.allow
/etc/hosts.deny

avec des règles concernant les applications utilisant cette bibliothèque.

Exemple conceptuel :

sshd: 192.168.10.0/255.255.255.0

Mais attention :

Ces fichiers ne constituent pas un pare-feu général du système.

Ils n’agissent que sur les services qui utilisent effectivement TCP Wrappers.

Debian fournit encore cette infrastructure et certains paquets peuvent toujours l’utiliser, mais cela ne remplace pas :

nftables

pour le filtrage réseau général.

Les journaux : journald et éventuellement rsyslog

Sur une Debian utilisant systemd, systemd-journald collecte les journaux du système.

Pour les consulter :

journalctl

Pour un service :

journalctl -u ssh

Pour le boot actuel :

journalctl -b

Pour suivre les événements :

journalctl -f

Configuration de journald

La configuration locale peut utiliser :

/etc/systemd/journald.conf

et des drop-ins :

/etc/systemd/journald.conf.d/*.conf

Comme pour les autres composants systemd, les drop-ins locaux permettent d’éviter de recopier inutilement un gros fichier complet.

Rsyslog

Si le paquet rsyslog est installé et utilisé, sa configuration principale est :

/etc/rsyslog.conf

avec des fragments sous :

/etc/rsyslog.d/

Rsyslog peut notamment :

écrire dans des fichiers ;
filtrer les messages ;
transmettre les logs à distance ;
recevoir des journaux réseau.

Mais n’affirmez pas automatiquement :

« Debian utilise rsyslog. »

Commencez par vérifier :

systemctl status rsyslog

ou :

dpkg -l rsyslog

logrotate : éviter que /var/log mange le disque

Les configurations sont principalement :

/etc/logrotate.conf
/etc/logrotate.d/

Un fragment pourrait ressembler conceptuellement à :

/var/log/monservice/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
}

Pour vérifier une configuration sans effectuer réellement les rotations :

sudo logrotate -d /etc/logrotate.conf

Le mode debug permet de voir ce que logrotate ferait.

Très utile avant de découvrir que votre règle destinée à :

monservice.log

cible en réalité :

*.log

dans un répertoire légèrement plus stratégique.

cron : plusieurs lieux de configuration

Pour les tâches système, on rencontre :

/etc/crontab

ainsi que :

/etc/cron.d/

et les répertoires :

/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

/etc/crontab n’a pas le même format qu’un crontab utilisateur

Dans :

/etc/crontab

on précise également l’utilisateur :

minute heure jour mois semaine utilisateur commande

Exemple :

30 2 * * * root /usr/local/sbin/backup

Alors que :

crontab -e

édite le crontab de l’utilisateur courant et ne possède pas ce champ supplémentaire.

Les crontabs utilisateurs ne sont pas dans /etc

Ils sont gérés par le service cron et ne doivent pas être modifiés en allant directement bricoler ses fichiers internes.

Utilisez :

crontab -e
crontab -l

ou pour un autre utilisateur :

sudo crontab -u alice -e

systemd timers : autre mécanisme de planification

Debian moderne peut également planifier des actions avec :

*.timer

et :

*.service

Pour lister les timers :

systemctl list-timers

Ainsi, chercher uniquement dans :

/etc/crontab

pour comprendre toutes les tâches automatiques d’une machine moderne n’est plus suffisant.

APT : les dépôts sont aussi de la configuration

L’ancienne référence incontournable est :

/etc/apt/sources.list

Elle reste supportée.

Mais Debian moderne privilégie également largement les fichiers :

/etc/apt/sources.list.d/*.sources

au format Deb822.

Sur une Debian récente, vous pouvez par exemple rencontrer :

/etc/apt/sources.list.d/debian.sources

Exemple Deb822

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Ce format est plus structuré que l’ancienne ligne :

deb https://deb.debian.org/debian trixie main

Autres répertoires APT utiles

On rencontre notamment :

/etc/apt/apt.conf.d/
/etc/apt/preferences.d/
/etc/apt/keyrings/

Emplacement	Fonction
`apt.conf.d`	Fragments de configuration APT
`preferences.d`	Pinning et priorités
`keyrings`	Clés locales utilisées notamment pour des dépôts tiers

Ajouter un dépôt tiers n’est donc plus idéalement :

« Télécharge cette clé inconnue, mets-la dans une confiance globale et espère le meilleur. »

Apache : l’arborescence à la Debian

Avec Apache sous Debian :

/etc/apache2/

contient la configuration.

On rencontre notamment :

/etc/apache2/apache2.conf
/etc/apache2/ports.conf

/etc/apache2/sites-available/
/etc/apache2/sites-enabled/

/etc/apache2/mods-available/
/etc/apache2/mods-enabled/

/etc/apache2/conf-available/
/etc/apache2/conf-enabled/

available et enabled

Une configuration peut exister dans :

sites-available

sans être active.

Pour activer un site :

sudo a2ensite exemple.conf

Pour le désactiver :

sudo a2dissite exemple.conf

Le même principe existe pour les modules :

a2enmod
a2dismod

Toujours tester Apache avant le reload

sudo apache2ctl configtest

Si le résultat est :

Syntax OK

vous pouvez alors envisager :

sudo systemctl reload apache2

Le mot important est :

avant

La production n’est pas l’environnement de validation syntaxique le plus sympathique.

MariaDB et MySQL sous Debian

L’emplacement principal est généralement :

/etc/mysql/

Avec MariaDB, on rencontre notamment :

/etc/mysql/mariadb.conf.d/

et différents fichiers inclus.

Il vaut donc mieux éviter d’affirmer que la configuration Debian se trouve normalement dans :

/etc/mariadb/

comme emplacement générique.

Commencez par regarder :

find /etc/mysql -maxdepth 2 -type f -print

et la documentation du paquet installé.

Ne déplacez pas une base avec mv et de l’espoir

Les fichiers de configuration indiquent notamment :

ports ;
écoute réseau ;
paramètres de mémoire ;
journalisation ;
répertoires de données ;
options du moteur.

Une modification de :

datadir

implique souvent plus que :

mv /var/lib/mysql /nouvel/endroit

Permissions, profils de sécurité, unités systemd, systèmes de fichiers et sauvegardes peuvent également entrer dans la conversation.

MariaDB n’est pas rancunière.

Elle refuse simplement de démarrer avec une froideur très professionnelle.

PHP : une configuration par version et par SAPI

Sous Debian :

/etc/php/

contient typiquement des répertoires par version.

Par exemple :

/etc/php/8.4/

puis :

apache2/
cli/
fpm/
mods-available/

On peut donc avoir plusieurs :

php.ini

sur la même machine.

Par exemple :

/etc/php/8.4/cli/php.ini
/etc/php/8.4/fpm/php.ini
/etc/php/8.4/apache2/php.ini

Le php.ini que vous modifiez n’est peut-être pas celui utilisé

Pour la CLI :

php --ini

permet d’afficher les fichiers chargés.

Modifier :

/etc/php/8.4/cli/php.ini

puis rafraîchir une page web et constater que rien n’a changé est donc parfaitement normal si le site utilise PHP-FPM.

Le fichier était correct.

C’était simplement le mauvais univers PHP.

Samba

La configuration principale de Samba est généralement :

/etc/samba/smb.conf

Après modification :

sudo testparm

permet de vérifier la configuration.

Pour afficher une version interprétée plus concise :

sudo testparm -s

Puis une configuration peut être rechargée selon le contexte.

Encore une fois :

valider, puis appliquer.

L’ordre inverse est beaucoup plus mémorable mais moins recommandé.

La configuration du temps dépend aussi du service utilisé

On peut rencontrer :

/etc/systemd/timesyncd.conf

lorsque systemd-timesyncd est utilisé.

Ou :

/etc/chrony/chrony.conf

avec Chrony.

Avant d’éditer :

/etc/ntp.conf

par réflexe, vérifiez quel logiciel fournit réellement la synchronisation.

Par exemple :

timedatectl
systemctl status systemd-timesyncd
systemctl status chrony

Fuseau horaire et locale

La configuration de langue et de temps implique plusieurs éléments.

On peut notamment rencontrer :

/etc/default/locale
/etc/locale.gen
/etc/localtime

Pour examiner :

localectl
timedatectl

Pour reconfigurer les locales sous Debian :

sudo dpkg-reconfigure locales

Pour le fuseau horaire :

sudo dpkg-reconfigure tzdata

ou :

sudo timedatectl set-timezone Europe/Paris

/etc/environment : attention, ce n’est pas un script shell

On rencontre :

/etc/environment

pour certaines variables d’environnement globales.

Mais ce fichier n’est pas simplement un :

/etc/profile numéro 2

Il utilise un format plus simple selon les composants qui le lisent.

N’y mettez donc pas automatiquement :

if ...
for ...
$(commande)

en supposant que Bash viendra exécuter tout cela avec enthousiasme.

/etc/profile et /etc/bash.bashrc

Pour les shells, il faut distinguer plusieurs contextes.

On rencontre notamment :

/etc/profile
/etc/bash.bashrc

ainsi que les fichiers utilisateurs :

~/.profile
~/.bashrc
~/.bash_profile
~/.bash_login

Ils ne sont pas tous lus dans les mêmes circonstances.

.bashrc : Bash interactif

Le fichier :

~/.bashrc

est généralement utilisé pour les shells Bash interactifs non-login.

On y place souvent :

alias ;
fonctions ;
prompt ;
options interactives.

Exemple :

alias ll='ls -lah'

.profile : environnement de connexion

~/.profile peut être lu lors de certaines sessions de connexion.

Il est souvent utilisé pour :

variables d’environnement ;
modification de PATH ;
initialisation générale.

Mais Bash peut choisir d’abord :

~/.bash_profile

ou :

~/.bash_login

selon leur présence.

Écrire :

« .profile est toujours lancé au login. »

est donc encore une simplification qui fonctionne jusqu’au premier utilisateur possédant un .bash_profile.

/etc/skel : le modèle des nouveaux homes

Le répertoire :

/etc/skel/

contient les fichiers copiés lors de la création de certains nouveaux répertoires personnels.

On peut y trouver :

.bashrc
.profile
.bash_logout

Si vous voulez que chaque nouvel utilisateur obtienne automatiquement un fichier :

README-ENTREPRISE.txt

vous pouvez envisager :

/etc/skel/README-ENTREPRISE.txt

Cela n’ajoute évidemment pas rétroactivement le fichier chez les utilisateurs déjà existants.

/etc/skel est une maternité.

Pas un service de livraison à domicile.

Certificats d’autorités de confiance

Un autre emplacement important est :

/usr/local/share/ca-certificates/

pour ajouter localement certaines autorités au mécanisme Debian prévu à cet effet.

Après ajout d’un certificat approprié :

sudo update-ca-certificates

met à jour le magasin généré.

Le fichier résultant :

/etc/ssl/certs/ca-certificates.crt

est donc typiquement une sortie générée.

Encore un exemple montrant pourquoi modifier directement chaque fichier sous /etc n’est pas toujours la bonne méthode.

/etc/machine-id : important, mais pas une configuration ordinaire

Le fichier :

/etc/machine-id

contient un identifiant local utilisé par différents composants.

Il ne doit pas être traité comme :

hostname numéro 2

et encore moins copié aveuglément lors de la préparation de plusieurs clones ou images système.

Deux machines partageant des identifiants censés être uniques constituent généralement un excellent moyen d’obtenir des problèmes dont les symptômes semblent n’avoir aucun lien entre eux.

Le principe des drop-ins

Debian moderne et systemd utilisent très souvent une logique :

configuration fournisseur
+
surcharge administrateur

Par exemple :

/usr/lib/systemd/system/service.service
+
/etc/systemd/system/service.service.d/override.conf

ou :

/usr/lib/sysctl.d/50-default.conf
+
/etc/sysctl.d/99-local.conf

Cette architecture possède un grand avantage :

les mises à jour peuvent renouveler les valeurs fournies par Debian sans écraser systématiquement les choix locaux de l’administrateur.

Le fichier principal n’est pas toujours le meilleur endroit à modifier

Vous trouverez donc de plus en plus souvent :

programme.conf
programme.conf.d/

ou :

sites-available
sites-enabled

ou :

conf-available
conf-enabled

ou encore des fichiers fournis sous :

/usr/lib

et surchargés sous :

/etc

La question moderne n’est plus seulement :

« Quel est le fichier de configuration ? »

mais :

« Quelle est la chaîne de configuration effective ? »

Les commandes de validation sont vos meilleures amies

De nombreux services possèdent une commande permettant de vérifier la configuration avant de l’appliquer.

Composant	Validation utile
Sudo	`visudo -c`
OpenSSH	`sshd -t`
Apache	`apache2ctl configtest`
Samba	`testparm`
fstab	`findmnt --verify --verbose`
nftables	`nft -c -f /etc/nftables.conf`
systemd	`systemd-analyze verify ...`

La philosophie est simple :

faire détecter l’erreur par un parseur avant qu’un démon de production ne soit obligé de vous l’expliquer.

Reload ou restart ?

Après une modification, tous les services n’exigent pas un redémarrage complet.

Certains savent recharger leur configuration :

systemctl reload ssh
systemctl reload apache2

D’autres exigent un :

systemctl restart service

Pour voir les capacités d’une unité :

systemctl cat service

et la documentation du logiciel restent vos meilleures références.

Un reload préserve souvent les processus ou connexions selon le service.

Un restart ressemble davantage à :

« Tout le monde dehors, on refait l’entrée. »

Ne confondez pas configuration et état

C’est l’une des distinctions les plus importantes.

On peut avoir :

/etc/samba/
→ configuration Samba

et :

/var/lib/samba/
→ état persistant de Samba

Ou :

/etc/mysql/
→ configuration SQL

et :

/var/lib/mysql/
→ bases de données

Sauvegarder uniquement :

/etc

ne constitue donc pas une sauvegarde complète du serveur.

Vous récupérerez peut-être parfaitement la recette.

Il manquera simplement le gâteau.

/run : l’état volatil

Certains composants utilisent :

/run

pour :

sockets ;
PID ;
états runtime ;
données temporaires de services.

Ces données ne sont pas censées être sauvegardées comme configuration persistante.

Modifier un fichier sous :

/run

peut résoudre temporairement un problème.

Très temporairement.

Le redémarrage possède alors le mauvais goût de rappeler que /run porte assez bien son nom.

Comment savoir quel paquet possède un fichier ?

Sous Debian :

dpkg -S /chemin/fichier

Par exemple :

dpkg -S /etc/ssh/sshd_config

permet d’identifier le paquet concerné.

Pour voir les fichiers appartenant à un paquet :

dpkg -L openssh-server

C’est extrêmement utile avant de conclure qu’un fichier a été créé par :

« probablement l’ancien admin ».

L’ancien admin est souvent innocent.

Enfin, sur ce point précis.

Comparer une configuration avec celle du paquet

Debian traite certains fichiers sous /etc comme des conffiles.

Lors d’une mise à jour, si le fichier local a été modifié et que le paquet fournit également une nouvelle version, dpkg peut demander ce qu’il doit faire.

C’est pourquoi les mises à jour peuvent afficher des questions concernant :

la version actuellement installée
ou
la version fournie par le responsable du paquet

Répondre automatiquement :

« Toujours prendre la nouvelle. »

est une politique très efficace pour découvrir quelles personnalisations étaient réellement importantes.

Utiliser Git pour /etc ?

Versionner certaines configurations peut être extrêmement utile.

Un outil traditionnel sous Debian est :

etckeeper

Il permet notamment d’utiliser un système de contrôle de versions pour suivre les modifications sous /etc.

Mais attention :

/etc peut contenir des secrets.

Clés privées, mots de passe d’applications, informations Wi-Fi, tokens ou fichiers sensibles peuvent s’y trouver.

Pousser aveuglément l’intégralité de :

/etc

vers un dépôt GitHub public transforme rapidement :

« Infrastructure as Code »

en :

« Incident as a Service ».

Les permissions des fichiers de configuration comptent

Tous les fichiers sous /etc ne doivent pas être lisibles par tout le monde.

Pour comparer ces permissions, placez-vous dans /etc :

cd /etc
ls -l passwd
ls -l shadow

/etc/passwd doit être lisible par de nombreuses applications.

Le fichier shadow de ce même répertoire nécessite, lui, une protection bien plus stricte.

De même, des répertoires comme :

/etc/NetworkManager/system-connections/
/etc/ssh/

peuvent contenir des données sensibles.

Mettre :

chmod -R 777 /etc

pour résoudre un problème de permissions reste techniquement une action.

Simplement pas une action qu’il est recommandé d’associer à votre vrai nom.

Une méthode sûre avant toute modification

Identifiez le composant.
Lisez sa page de manuel.
Déterminez si le fichier est statique, généré ou inclus.
Regardez les éventuels répertoires .d.
Sauvegardez la configuration existante.
Faites une modification minimale.
Validez la syntaxe avec l’outil du service.
Rechargez plutôt que redémarrer lorsque cela suffit.
Consultez les journaux immédiatement.
Gardez une méthode de retour arrière.

Les pages de manuel : votre carte du donjon

Pour un fichier :

man 5 fstab
man 5 sudoers
man 5 sshd_config
man 5 interfaces
man 5 sysctl.d

Le chiffre :

désigne la section des formats de fichiers et conventions.

Pour une commande :

man 8 sshd
man 8 sysctl
man 8 visudo

Les pages de manuel ont un avantage appréciable sur un article trouvé au hasard :

elles ont de bonnes chances de correspondre à la version réellement installée sur votre machine.

Quelques fichiers essentiels à connaître

Fichier / répertoire	Fonction
`/etc/hostname`	Hostname statique
`/etc/hosts`	Associations locales IP ↔ noms
`/etc/resolv.conf`	Interface traditionnelle de configuration du résolveur, souvent générée
`/etc/nsswitch.conf`	Ordre et sources des recherches NSS
`/etc/network/interfaces`	Configuration avec ifupdown
`/etc/systemd/network/`	Configuration systemd-networkd
`/etc/NetworkManager/`	Configuration NetworkManager
`/etc/passwd`	Comptes locaux
Fichier `shadow` dans `/etc`	Données protégées relatives aux mots de passe
`/etc/group`	Groupes locaux
Fichier `gshadow` dans `/etc`	Données protégées des groupes
`/etc/pam.d/`	Politiques PAM
`/etc/sudoers`	Politique sudoers
`/etc/sudoers.d/`	Fragments sudoers
`/etc/fstab`	Montages persistants
`/etc/sysctl.d/`	Paramètres noyau persistants
`/etc/systemd/system/`	Unités et surcharges locales systemd
`/etc/default/`	Paramètres spécifiques à certains paquets
`/etc/ssh/`	Configuration SSH
`/etc/nftables.conf`	Règles nftables persistantes
`/etc/systemd/journald.conf*`	Configuration du journal systemd
`/etc/logrotate.conf`	Configuration générale logrotate
`/etc/logrotate.d/`	Règles de rotation par service
`/etc/crontab`	Planification cron système
`/etc/cron.d/`	Tâches cron système supplémentaires
`/etc/apt/`	Configuration et dépôts APT
`/etc/apache2/`	Configuration Apache
`/etc/mysql/`	Configuration MySQL / MariaDB sur Debian
`/etc/php/`	Configurations PHP par version et SAPI
`/etc/samba/smb.conf`	Configuration Samba
`/etc/skel/`	Modèle des nouveaux répertoires utilisateurs

Les fichiers qui demandent une prudence particulière

Configuration	Risque principal	Validation / outil recommandé
`/etc/sudoers`	Perdre sudo	`visudo`
`/etc/ssh/sshd_config*`	Perdre l’accès distant	`sshd -t`
`/etc/fstab`	Montage ou boot dégradé	`findmnt --verify`
`/etc/nftables.conf`	Bloquer le réseau	`nft -c -f`
`/etc/pam.d/`	Perdre les authentifications	Procédure PAM adaptée et session de secours
`/etc/network/*`	Perdre la connectivité	Outil correspondant au gestionnaire
`/etc/apache2/`	Serveur web indisponible	`apache2ctl configtest`
`/etc/samba/smb.conf`	Partages indisponibles	`testparm`

Le grand piège : éditer le mauvais fichier

Beaucoup d’erreurs modernes ne viennent plus d’une mauvaise ligne.

Elles viennent d’une ligne parfaitement correcte placée dans un fichier que personne ne lit.

Exemples :

modifier /etc/resolv.conf
alors que NetworkManager le régénère

modifier /usr/lib/systemd/system/service.service
au lieu de créer un override

modifier le php.ini de CLI
alors que le site utilise PHP-FPM

modifier /etc/network/interfaces
alors que NetworkManager contrôle la carte

modifier sshd_config
alors qu'un fragment sshd_config.d définit déjà le paramètre

C’est pourquoi la compétence essentielle n’est plus :

« Je sais utiliser nano. »

mais :

« Je sais déterminer la configuration effective. »

Quelques commandes pour retrouver la vérité

Commande	Question à laquelle elle répond
`readlink -f fichier`	Où mène réellement ce lien ?
`dpkg -S fichier`	Quel paquet possède ce fichier ?
`systemctl cat service`	Quels fichiers systemd sont réellement assemblés ?
`sshd -T`	Quelle configuration SSH effective est calculée ?
`testparm -s`	Comment Samba interprète-t-il smb.conf ?
`php --ini`	Quels fichiers PHP charge la CLI ?
`resolvectl status`	Quels DNS systemd-resolved connaît-il ?
`nmcli connection show`	Quels profils NetworkManager existent ?
`getent`	Que retourne réellement NSS ?
`nft list ruleset`	Quel pare-feu est actuellement chargé ?

La checklist avant de toucher à un serveur distant

Ayez une deuxième méthode d’accès lorsque le changement touche SSH, le réseau ou le pare-feu.
Gardez la session distante actuelle ouverte.
Sauvegardez le fichier.
Vérifiez que vous éditez la bonne couche.
Effectuez un seul changement logique à la fois.
Utilisez le validateur du logiciel.
Rechargez le service.
Testez depuis une nouvelle session.
Regardez les logs.
Documentez le changement.

Cette procédure semble excessivement prudente jusqu’au jour où vous modifiez simultanément :

IP
DNS
pare-feu
SSH

sur un serveur situé à 600 kilomètres.

À cet instant, la prudence prend soudainement l’apparence très séduisante d’une compétence professionnelle.

Les erreurs classiques

Éditer resolv.conf sans savoir qui le génère

Résultat :

la modification disparaît et vous commencez une relation personnelle avec ce fichier.

Modifier une unité dans /usr/lib/systemd/system

Résultat :

tout fonctionne jusqu’à une mise à jour.

Éditer sudoers sans visudo

Résultat potentiel :

sudo: parse error

suivi d’une période de réflexion sur les choix de carrière.

Redémarrer SSH sans sshd -t

Résultat potentiel :

le serveur fonctionne parfaitement.

Simplement sans vous.

Éditer le mauvais php.ini

Résultat :

php -i

confirme votre modification.

Le site web continue de l’ignorer avec sérénité.

Modifier fstab puis redémarrer directement

Résultat :

vous transformez une erreur vérifiable en ligne de commande en exercice de console de secours.

Utiliser chmod 777 pour résoudre un problème

Résultat :

le problème de permission disparaît parfois.

La politique de sécurité également.

Mettre tous les paramètres dans un seul fichier géant

Résultat :

cinq ans plus tard, personne ne sait :

ce qui vient de Debian ;
ce qui est local ;
ce qui appartient à une ancienne migration ;
ce qui peut être supprimé ;
et pourquoi une ligne est commentée avec :

# IMPORTANT NE PAS TOUCHER !!!

sans aucune autre explication.

Résumé : le grimoire du sysadmin

Besoin	Premier endroit à examiner
Nom de la machine	`/etc/hostname`
Résolution locale	`/etc/hosts`, `/etc/nsswitch.conf`
DNS	`/etc/resolv.conf` puis identifier son gestionnaire
Réseau	ifupdown, NetworkManager ou systemd-networkd
Utilisateurs	`/etc/passwd`, puis le fichier `shadow` du répertoire `/etc`
Groupes	`/etc/group`, puis le fichier `gshadow` du répertoire `/etc`
Authentification	`/etc/pam.d/`
Sudo	`/etc/sudoers`, `/etc/sudoers.d/`
Montages	`/etc/fstab`
Paramètres noyau	`/etc/sysctl.d/`
Services systemd	`/etc/systemd/system/` et unités fournisseur sous `/usr/lib/systemd/system/`
SSH serveur	`/etc/ssh/sshd_config*`
Pare-feu nftables	`/etc/nftables.conf`
Logs systemd	`/etc/systemd/journald.conf*`
Rotation des logs	`/etc/logrotate.conf`, `/etc/logrotate.d/`
Tâches cron	`/etc/crontab`, `/etc/cron.d/`
Dépôts APT	`/etc/apt/sources.list.d/*.sources`
Apache	`/etc/apache2/`
MariaDB	`/etc/mysql/`
PHP	`/etc/php/<version>/`
Samba	`/etc/samba/smb.conf`
Configuration utilisateur Bash	`~/.bashrc`, `~/.profile`
Modèle nouveaux utilisateurs	`/etc/skel/`

Conclusion : le pouvoir est dans le fichier, mais surtout dans la méthode

Les fichiers texte sont l’une des grandes forces de l’administration Linux.

Ils permettent de :

lire précisément une configuration ;
la sauvegarder ;
la comparer ;
la versionner ;
l’automatiser ;
la reproduire ;
et comprendre ce que le système est censé faire.

Mais Debian moderne ne se résume plus à :

tout est dans /etc
ouvre nano
change la ligne
redémarre

La réalité est plus intéressante :

configuration fournisseur
        +
configuration locale
        +
fragments .d
        +
configuration générée
        +
état runtime
        +
outil chargé d'interpréter l'ensemble

L’administrateur efficace apprend donc trois choses pour chaque service :

où se trouve sa configuration,
comment connaître sa configuration effective,
et comment la valider avant de l’appliquer.

Une bonne modification ressemble alors à :

sauvegarder
modifier
valider
recharger
tester
observer les logs

plutôt qu’à :

modifier
reboot
attendre
regretter

Et si un jour l’envie vous prend de lancer :

rm -rf /etc

« juste pour voir » :

le résultat est parfaitement documentable.

Simplement, il est rarement nécessaire de le reproduire personnellement.

Sous Debian, le fichier texte donne beaucoup de pouvoir.
La commande de validation évite qu’il devienne un testament.

Post Views: 10