Etckeeper

Versionner /etc avec Git pour reprendre le contrôle de votre configuration système

Introduction

Tout administrateur système a connu ce moment de panique : une mise à jour échoue mystérieusement, un service refuse de démarrer après une modification, ou pire, on découvre qu’un fichier dans /etc a été altéré sans savoir quand, par qui, ni pourquoi. Le répertoire /etc est le cœur de la configuration d’un système Unix/Linux, et pourtant, il est traditionnellement géré sans aucun mécanisme d’historique fiable.

Etckeeper apporte une réponse élégante à ce problème : il place /etc sous contrôle de version (Git, Mercurial, Bazaar ou Darcs) et l’intègre intelligemment avec le gestionnaire de paquets de votre distribution. Chaque modification — qu’elle vienne d’une commande apt install, d’un vim /etc/ssh/sshd_config, ou d’un script de configuration — peut ainsi être tracée, comparée, et annulée si nécessaire.

Cet article explore en profondeur le fonctionnement d’etckeeper, son installation, sa configuration avancée, ses interactions avec le système, ainsi que ses limites et bonnes pratiques.

1. Pourquoi versionner /etc ?

Le problème fondamental

Le répertoire /etc contient typiquement entre 1 000 et 3 000 fichiers sur un serveur en production. Ces fichiers sont modifiés par :

Les paquets installés via le gestionnaire (apt, dnf, pacman, zypper)
Les outils de gestion de configuration (Ansible, Puppet, Chef, Salt)
Les administrateurs humains via leur éditeur favori
Les services eux-mêmes (certains daemons réécrivent leurs fichiers)
Les scripts d’installation ad-hoc

Sans versioning, répondre à des questions aussi basiques que « qu’est-ce qui a changé hier soir dans /etc/nginx/ ? » devient un exercice d’archéologie numérique.

Les bénéfices concrets

Mettre /etc sous Git apporte plusieurs avantages immédiats :

Traçabilité : chaque modification est horodatée et accompagnée d’un message de commit
Réversibilité : un git revert ou git checkout permet de revenir à un état antérieur
Auditabilité : git log et git blame répondent au « qui a changé quoi, et quand »
Diagnostic : git diff entre deux dates permet de corréler un incident à un changement
Sauvegarde déportée : en poussant le dépôt vers un serveur distant, la configuration devient récupérable même après un sinistre

2. Architecture et fonctionnement interne

Le principe général

Etckeeper n’est pas un nouveau système de versioning : c’est une couche de glue entre /etc, un VCS (par défaut Git), et le gestionnaire de paquets. Le dépôt Git est créé directement dans /etc/.git, ce qui signifie que /etc est lui-même le répertoire de travail.

Les composants clés sont :

/etc/
├── .git/                          # Dépôt Git interne
├── .etckeeper                     # Script de restauration des permissions
├── .gitignore                     # Fichiers à exclure du suivi
└── etckeeper/
    ├── etckeeper.conf             # Configuration principale
    ├── pre-commit.d/              # Hooks pré-commit
    ├── post-install.d/            # Hooks post-installation paquet
    └── ...

Les hooks du gestionnaire de paquets

L’intégration avec le gestionnaire de paquets est le véritable apport d’etckeeper. Sur Debian/Ubuntu, etckeeper installe des hooks dans :

/etc/apt/apt.conf.d/05etckeeper : déclenche un commit automatique avant et après chaque opération apt

Sur Fedora/RHEL, il s’intègre via les plugins DNF/YUM. Sur Arch Linux, via les hooks pacman dans /etc/pacman.d/hooks/.

Le flux typique lors d’un apt install nginx est le suivant :

Pré-installation : etckeeper vérifie si des modifications non commitées existent dans /etc et les commit avec un message du type « committing changes in /etc made by user »
Installation du paquet : apt déploie les fichiers de configuration de nginx
Post-installation : etckeeper commit les changements avec un message du type « committing changes in /etc after apt run »

Le problème des permissions et propriétaires

Git ne préserve nativement que le bit exécutable. Or, dans /etc, des fichiers comme /etc/shadow (mode 0640, propriétaire root:shadow) ou /etc/sudoers (mode 0440) ont des permissions critiques pour la sécurité.

Etckeeper résout ce problème via un fichier .etckeeper auto-généré, qui contient une liste de commandes maybe chown et maybe chmod reproduisant les métadonnées exactes de chaque fichier. Ce fichier est commité avec le reste, et le script etckeeper init peut le rejouer pour restaurer les permissions correctes après un checkout.

Exemple d’extrait de .etckeeper :

maybe chmod 0640 'shadow'
maybe chgrp 42 'shadow'
maybe chmod 0440 'sudoers'
maybe chmod 0700 'ssh/ssh_host_ed25519_key'

3. Installation et initialisation

Installation selon la distribution

Sur Debian et Ubuntu :

sudo apt install etckeeper

Sur Fedora, RHEL et dérivés :

sudo dnf install etckeeper

Sur Arch Linux :

sudo pacman -S etckeeper

L’installation déploie automatiquement les hooks du gestionnaire de paquets et le service systemd (ou cron) pour les commits périodiques.

Initialisation du dépôt

Si etckeeper n’a pas été initialisé automatiquement (cas rare), on procède manuellement :

sudo etckeeper init

Cette commande :

Crée /etc/.git (ou l’équivalent selon le VCS choisi)
Génère un .gitignore adapté excluant les fichiers volatils (*.dpkg-*, *.rpmnew, etc.)
Crée le fichier .etckeeper initial
Effectue le commit initial avec l’intégralité de /etc

À noter que ce premier commit peut être volumineux : plusieurs milliers de fichiers, parfois 50 à 100 Mo selon le système.

Configuration de l’identité Git

Comme Git refuse de commiter sans identité, il faut configurer un nom et un email globaux pour root, ou directement dans le dépôt :

sudo git -C /etc config user.email "admin@example.com"
sudo git -C /etc config user.name "Server Admin"

4. Configuration approfondie

Le fichier /etc/etckeeper/etckeeper.conf centralise les options. Voici les directives essentielles à comprendre.

Choix du VCS

VCS="git"

Git est le défaut, et reste le choix recommandé pour sa robustesse, sa rapidité et sa popularité. Les alternatives (hg, bzr, darcs) sont supportées mais peu utilisées en pratique.

Commits périodiques

AVOID_DAILY_AUTOCOMMITS=0
AVOID_COMMIT_BEFORE_INSTALL=0

Par défaut, etckeeper effectue un commit quotidien via un timer systemd (etckeeper.timer) ou une tâche cron. Cela capture les modifications manuelles qui n’auraient pas été commitées explicitement. Désactiver cette fonction (AVOID_DAILY_AUTOCOMMITS=1) est déconseillé sauf cas particulier.

Mode push automatique

PUSH_REMOTE=""

Définir un remote ici pousse automatiquement chaque commit. Par exemple, PUSH_REMOTE="origin" envoie chaque changement vers le serveur Git distant configuré.

Verbosité du gestionnaire de paquets

LOWLEVEL_PACKAGE_MANAGER=dpkg
HIGHLEVEL_PACKAGE_MANAGER=apt

Ces variables doivent correspondre à votre distribution. Elles permettent à etckeeper d’extraire la liste des paquets installés (stockée dans /etc/.etckeeper... attention à ne pas confondre avec le fichier de permissions) pour la versioner également.

5. Utilisation au quotidien

Commits manuels

Après une modification importante, il est recommandé de commiter explicitement avec un message descriptif :

sudo etckeeper commit "Ajout du vhost staging.example.com dans nginx"

Cette commande est un simple wrapper qui :

Régénère le fichier .etckeeper (permissions)
Met à jour la liste des paquets installés
Exécute git add -A et git commit avec le message fourni

Consulter l’historique

Etckeeper ne fournit pas de commandes propres pour lire l’historique : on utilise directement Git.

cd /etc
sudo git log --oneline -20
sudo git log -p ssh/sshd_config
sudo git diff HEAD~5 HEAD -- nginx/
sudo git blame hosts

Annuler un changement

Pour revenir à une version antérieure d’un fichier :

sudo git -C /etc checkout HEAD~1 -- ssh/sshd_config
sudo etckeeper commit "Restauration de la config SSH précédente"

Pour annuler complètement un commit fautif :

sudo git -C /etc revert <hash-du-commit>

Important : après tout checkout ou revert affectant des fichiers à permissions sensibles, exécuter sudo etckeeper init n’est pas nécessaire ; le hook post-checkout d’etckeeper relit .etckeeper automatiquement si configuré, mais il est prudent de vérifier manuellement les permissions des fichiers critiques.

Pousser vers un dépôt distant

Pour sauvegarder votre dépôt sur un serveur Git (GitLab privé, Gitea, ou un simple serveur SSH avec un dépôt bare) :

sudo git -C /etc remote add origin git@gitserver:configs/server01.git
sudo git -C /etc push -u origin master

Avertissement de sécurité : /etc contient des secrets (/etc/shadow, clés privées dans /etc/ssl/private/, mots de passe dans /etc/postfix/sasl_passwd, etc.). Ne jamais pousser ce dépôt vers un service public. Utiliser exclusivement un dépôt privé chiffré et avec accès restreint. Idéalement, exclure explicitement les fichiers les plus sensibles via /etc/.gitignore.d/.

6. Cas d’usage avancés

Détecter des modifications non autorisées

Combiné à une surveillance régulière, etckeeper peut servir de système d’alerte de bas niveau. Un script comme celui-ci, exécuté toutes les heures, signale toute modification non commitée :

#!/bin/bash
cd /etc || exit 1
if ! git diff-index --quiet HEAD --; then
    echo "Modifications non commitées détectées dans /etc :"
    git status --short
    # Envoyer une alerte par mail ou via votre système de monitoring
fi

Ce n’est pas un substitut à un véritable HIDS comme AIDE ou Tripwire (qui surveillent les hashes et sont conçus pour résister à un attaquant), mais cela offre une visibilité rapide.

Intégration avec Ansible et autres outils de configuration

Lorsque vous utilisez Ansible pour déployer de la configuration, etckeeper capture automatiquement les modifications. Pour des commits plus descriptifs, vous pouvez ajouter à la fin de vos playbooks :

- name: Commit etckeeper avec contexte Ansible
  command: etckeeper commit "Ansible run {{ ansible_date_time.iso8601 }} - playbook {{ playbook_dir | basename }}"
  changed_when: false

Migrer ou restaurer un système depuis le dépôt

En cas de réinstallation ou de migration, le dépôt etckeeper permet de récupérer rapidement la configuration. La procédure consiste à :

Réinstaller le système de base et etckeeper
Sauvegarder le /etc neuf : mv /etc /etc.fresh
Cloner le dépôt : git clone git@gitserver:configs/server01.git /etc
Restaurer les permissions : cd /etc && bash .etckeeper
Réinstaller les paquets listés dans /etc/.etckeeper (Debian) ou équivalent

Cette procédure est délicate et doit être testée hors production avant tout besoin réel.

7. Limites et précautions

Ce qu’etckeeper n’est pas

Il est essentiel de comprendre qu’etckeeper ne remplace pas :

Un outil de gestion de configuration (Ansible, Puppet) : etckeeper enregistre les états, il ne les déploie pas
Une sauvegarde : versionner localement ne protège pas contre la perte du disque
Un IDS : un attaquant root peut réécrire l’historique Git
Un outil de conformité : il ne signe pas cryptographiquement les commits par défaut

Volume et performance

Sur certains systèmes très chargés en services (serveurs avec des centaines de paquets), le dépôt peut grossir rapidement. Quelques précautions :

Vérifier régulièrement la taille avec du -sh /etc/.git
Faire git gc --aggressive occasionnellement
Pour de très anciens dépôts, envisager un git filter-repo pour élaguer l’historique

Fichiers volumineux ou binaires

Certains paquets installent des fichiers binaires ou très volumineux dans /etc (rare mais existant : bases de certificats, fichiers de cache). Le .gitignore par défaut couvre les cas courants, mais une revue est utile :

sudo ls -lS /etc/.git/objects/pack/
sudo git -C /etc rev-list --objects --all | git -C /etc cat-file --batch-check='%(objecttype) %(objectsize) %(rest)' | sort -k2 -n -r | head -20

Fichiers à exclure absolument

Au-delà du .gitignore par défaut, certains fichiers méritent une exclusion explicite via un fichier dans /etc/.gitignore.d/ :

/etc/ssl/private/* (clés TLS privées)
/etc/ssh/ssh_host_*_key (sauf si vous voulez les sauvegarder de façon chiffrée)
Tout fichier contenant des mots de passe en clair non chiffrés

8. Alternatives et écosystème

Etckeeper n’est pas seul dans cet espace. Quelques alternatives à connaître :

Versionnement manuel de /etc avec Git : possible mais sans intégration au gestionnaire de paquets ni gestion des permissions ; on perd l’essentiel de la valeur
AIDE / Tripwire / Samhain : outils de détection d’intrusion par hash, complémentaires plutôt que concurrents
NixOS / Guix : systèmes où la configuration est nativement déclarative et versionnée ; etckeeper devient sans objet, mais le coût d’entrée est tout autre
Snapper / Timeshift : snapshots Btrfs/LVM du système entier, plus globaux mais moins granulaires que Git sur /etc

Dans la plupart des cas, etckeeper se combine très bien avec une solution de snapshots système et un outil de configuration management.

Conclusion

Etckeeper représente un investissement minimal — quelques minutes d’installation, une configuration quasi nulle — pour un bénéfice considérable : la visibilité totale sur l’évolution de la configuration d’un système Unix. Il transforme /etc d’une boîte noire en un objet versionné, auditable et restaurable, sans changer les habitudes des administrateurs ni interférer avec les outils existants.

Pour un serveur de production, son absence est aujourd’hui difficilement justifiable. Et même sur un poste de travail Linux personnel, le confort de pouvoir répondre « ah oui, j’avais modifié ce fichier la semaine dernière » à coup de git log change durablement la relation à son système.

La prochaine étape naturelle, une fois etckeeper en place, consiste à industrialiser : pousser les dépôts vers un serveur Git centralisé, agréger les historiques de plusieurs machines, et corréler les commits avec votre système de monitoring. Mais cela, c’est une autre histoire.