J’ai commencé récemment à stocker et sauvegarder ma configuration OpenBSD dans des dépots git.

Pourquoi ?

J’ai eu cette idée, inspiré par etckeeper et je me suis dis que ca ferait une bien meilleure méthode de sauvegarde que ce que j’avais jusqu’à présent.

Par ailleurs, cela me permet de dupliquer une machine (enfin, sa configuration) de manière assez simple ou d’avoir accès à la configuration à diverses étapes de son évolution. Vous voulez retrouver pf.conf avant l’introduction de telle ou telle fonction ? No problem, on retrouve le commit qui va bien, et on regarde la/les version d’avant et/ou d’après.

Ceci pourrait se faire pour n’importe quel système Unix-like. Ce n’est pas limité à OpenBSD ou /etc et vous pouvez l’adapter à votre sauce, à votre logiciel de gestion de version favori ou votre distribution. Autre avantage notoire : c’est aussi bien adapté à un serveur (connecté en permanence) qu’à une machine de bureau ou portable.

NB : J’ai voulu essayer de voir à utiliser Got, mais je n’arrive à rien faire, contrairement aux objectifs annoncés du projet. Pourtant ca me plairait beaucoup hein, parce que pledge et les bonnes pratiques de code d’OpenBSD, tout ca tout ca… Mais non. Donc si quelqu’un veut le faire, il ou elle peut écrire son article et m’envoyer le lien, je me ferais un plaisir de placer le lien en commentaire et d’essayer la méthode elle-même.

J’ai écris cet article pour me rappeler de mes procédures ainsi que rappeler à tous de faire leures sauvegardes.

On sauvegarde quoi ?

Je ne sauvegarde que les fichiers que j’ai modifié. Mais ca fait quand même du monde.

J’inclus tous ces fichiers lors du commit d’initialisation.

hosts
hostname.*
myname
*.local
pf.conf
doas.conf

Mais contrairement à etckeeper, je ne vais pas sauvegarder l’entièreté de /etc. Je n’en vois pas l’intêret.

Sinon, j’inclus bien sûr tous les fichiers de configuration spécifiques à la machine, (les .local) ou que j’ai écris moi-même, ceux necessaires pour les paquetages, qu’ils soient fournis avec le logiciel ou que j’ai copié depuis internet ou ailleurs.

Ca comprends donc /etc/rc.conf.local, le fichier de configuration des démons spécifique à la machine, /etc/daily.local et les autres.

Pré-requis

Vous avez besoin d’un serveur git installé quelque part, sécurisé. Vous n’avez même pas besoin que ce serveur git tourne sous OpenBSD lui-même, le serveur ne servira que de dépot de sauvegarde. Vous pourriez presque utiliser des dépots github ou gitlab, sauf que c’est pas super secure là. Idealement le serveur n’hébèrge aucun dépot public puisque vous allez y mettre toute la configuration de votre réseau.

Vous pouvez, à contrario, rendre cette machine accessible sur votre réseau interne, peut-être y installer quelque chose comme Gitea pour pouvoir consulter cette même configuration plus facilement.

Le choix vous apartient.

Comment ça marche ?

On installe.

Je vais décrire ici le processus de mise en place de ce système sur une machine que l’on appelera “ex” (pour “exemple”). Cette machine vient tout juste d’être installée, elle est “vierge”. Ce sont les premières commandes passées après le premier reboot.

En premier lieu, il vous faut installer git. Puis génerer les clés ssh nécessaires à la connexion au serveur git.

(Ces commandes doivent être tapées comme root ou avec doas).

# pkg_add git
# ssh-kegen

Vous pouvez ensuite vous envoyer à vous-même la clé publique ssh (Je pouvais le faire vu que mon serveur de courrier se trouve dans mon réseau domestique. Ce sera peut-être different pour vous.)

# cat /root/.ssh/id_ed25519.pub|mail admin@domain

Sur votre machine de bureau

Vous pouvez alors lire sur votre ordinateur personel (de bureau ou portable) la clé publique que vous avez juste envoyée et l’inclure dans votre gestion d’accès.

J’utilise gitolite pour gérer mes dépots git plus facilement. Le reste de l’article se base dessus.

Il est important que vous adoptiez une convention de nommage. Cette convention peut d’ailleurs s’utiliser dans d’autres cadres, d’autant plus qu’il est fréquent d’avoir plusieurs clés, avec une par machine sur laquelle on a un compte.

Pour ma part, j’utilise $repertoire-$machine pour le nom des dépots. Et j’apelle les clés $utilisateur-$machine.

Donc, dans conf/gitolite.conf:

repo    etc-ex
    RW+     = stephane
    RW+     = root-ex

Vous devez maintenant créer un fichier root-ex.pub dans le repertoire keydir, enregistrer les modifications et envoyer le tout sur le serveur git.

git add conf/gitolite.conf
git add keydir/root-machine.pub
git commit -m "add machine XYZ"

Voila ! Vous avez maintenant votre dépot pret pour y stocker la configuration de votre machine “ex”.

Initialisation

On retourne sur la machine “ex”, initialise git dans /etc et enregistre tous les fichiers importants, notamment ceux de la liste précédente.

# cd /etc
# git init
# git add ....
# git commit -m "first commit"
# git remote add origin git@server:etc-ex.git
# git push origin master

Utilisation

À chaque modification d’un fichier de configuration, je vais l’ajouter à git, commenter la modification et pousser le tout sur le serveur.

cd /etc
nano ...
...
TRAVAILLER SUR DES TRUCS
...
doas git add file
doas git commit
doas git push origin master

Scripts

Maintenant que le système est installé et initialisé, il faut juste l’utiliser régulièrement. J’ai donc ajouté ces lignes à /etc/daily.local (qui est lui-même inclus dans git, souvenez-vous).

cd /etc
git add -u && git commit -m "update"
git push origin master

Ca va simplement mettre à jour tous les fichiers déjà présents dans git, créer un message de commit générique et envoyer le tout sur le serveur.

L’avantage c’est que si j’ai oublié de mettre à jour ou commenter mes modifications dans la configuration de la machine, alors ce script va au moins faire cette sauvegarde automatique.

Pour une machine de bureau, on essayera d’inclure ce script à d’autres moments, peut-être directement au démarrage ou lors du shutdown.

Dupliquer une machine

Pour dupliquer, en fait, litteralement cloner, une machine, vous devez d’abord donner l’accès au dépot que vous souhaitez cloner à la nouvelle machine (sur laquelle vous aller en fait recopier l’ensemble de la configuration provenant de la machine clonée).

Donc, juste après l’installation de la nouvelle machine, il faut d’abord que vous installiez git et géneriez une clé ssh pour root et vous l’envoyer à vous-même via mail. Puis inclure la clé dans le repertoire de clés de gitolite.

Mais cette fois ci, au lieu de créer un nouveau dépot git juste après, on va simplement donner l’acces en lecture au dépot git de la machine à cloner.

Si, par exemple, vous voulez copier (cloner) la configuration de votre super server “Einstein”, vous ajoutez la clé de la nouvelle machine en lecture du dépot d’einstein :

repo    etc-einstein
    RW+     = stephane
    R       = root-ex

On pousse ca. Hop, voila, vous pouvez maintenant récuperer cette configuration sur votre nouvelle machine.

Toutefois, vous ne pouvez pas importer directement cette configuration dans le nouveau /etc, puisqu’il n’est pas vide. Je vais simplement faire le clone dans /tmp puis copier dans /etc.

# cd /tmp
# git clone git@server:etc-einstein.git
# cd etc-einstein
# doas cp -a * /etc

Voila, ca devrait être bon. Il vous faut bien sûr éditer les fichiers pour correspondre à la configuration définitive que vous voulez donner à la machine, puisque l’idée de cloner la machine, c’était bien de partir d’une base initiale bien connue. Il vous faut maintenant les adresses ip définitives à donner, etc…

Et puis il faut donner un nom d’hôte à votre machine, puisque là, elle a pris le nom de la machine clonée. Bah oui !

Une fois que tout est bien en place, vous pouvez à nouveau créer un dépot git et commencer à y sauvegarder votre nouvelle machine. Il suffit de reprendre toutes les étapes de la phase initialisation décrite au dessus.

La génération et l’envoi de la clé ssh est inutile puisque vous l’avez déjà fait, mais pour le reste, c’est la même chose.