Quelques astuces et commandes que je ne connaissais pas, que j'ai découverte et que je veux partager.

Automatiser la mise à jour apt en conservant les actuels fichiers de configuration

Issu du site bggofurther.com, dont je recopie le billet ici :
Lorsqu'une mise à jour est faite sur un serveur Debian/Ubuntu, si un paquet essaie de modifier un fichier de configuration, un choix manuel est requis. Si vous essayez d'automatiser le processus, vous souhaitez probablement éviter cette question and conserver la configuration actuelle par défaut.

Les différentes options vont forcer la mise à jour à conserver la configuration actuelle et ne pas l'écraser avec celle par défaut du package.

debsum

Debsum est un programme qui va comparer la signature des paquets installés (comparaison du MD5 checksum) avec une liste de référence qui se trouve dans les fichiers /var/lib/dpkg/info/*.md5sums.

Utile pour vérifier l'intégralité d'un binaire dans le cas d'une machine potentiellement compromise (voir par exemple à ce sujet
Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2

Il faut bien évidemment que les fichiers /var/lib/dpkg/info/*.md5sums n'est pas été compromis par un attaquant.

debsecan

Debscan permet de générer une liste des vulnérabilités présentes sur une machine (serveur ou machine personnel) avec les numéros de CVE correspondants.

Pour avoir un article détaillé sur ce programme, voir Debsecan, le paquet qui fait peur sur le Blog-libre de Cascador, il faut également lire les commentaires avec un commentaire de Raphael Hertzog (auteur du livre Debian Administrator's Handbook).

checkrestart

Outil qui se trouve dans le paquet debian-goodies. checkrestart permet de vérifier quels services utilisent des librairies mises à jour depuis le lancement du service, et qu'il faudrait donc redémarrer pour prendre en compte ces mises à jour.

Voir sur cet utilitaire CheckRestart, outil pratique de debian-goodies, et version Octopuce

Autre façon de savoir s'il faut redémarrer un serveur, la présence du fichier /var/run/reboot-required qui indique que la prise en compte de la mise à jour du noyau (par exemple) nécessite un redémarrage de la machine.

Nouveau billet de blog sur Borg comme outil de sauvegarde. Dans le présent billet, je voudrais développer un peu une procédure de sauvegarde que j'ai mise en place pour certains serveurs.

Sur une partition dédiée, un script créé une archive tar.gz à la date du jour pour les différents dossiers importants (/etc, /home, /var/www/). Un dump de la base de données est également fait et zippé en local. Ces archives ont une durée de rétention et de rotation sur 5 jours et permettent d'avoir rapidement les données accessibles si besoin depuis la machine.

Les dossiers importants (/etc, /home, /var/www) et les dumps de la base de donnée sont sauvegardés via un rsync à travers SSH sur un premier serveur de fichiers.

Suite à ça, un second script, lancé quotidiennement sur ce serveur de fichiers, effectue une sauvegarde via Borg de ces données (ensemble des fichiers synchronisés par rsync et dumps du jour) sur un espace disque situé sur un NAS / espace de stockage. Le script lançant la sauvegarde via Borg lance également la commande de purge qui permet d'avoir une conservation des données selon la règle suivante : conservation des données sur 7 jours (soit l'équivalent de 7 sauvegarde complète sur une semaine), conservation des données d'un jour de la semaine pendant 1 mois, conservation d'une sauvegarde du mois pendant 1 an.

Pourquoi ce schéma de sauvegarde ?

Les scripts rédigés se dupliquent facilement. Il suffit de créer un nouveau dossier racine pour un client, on duplique le script, le renomme, recherche et remplace dedans par le nouveau nom.

Le respect de la règle des 3-2-1

Pour rappel, voir mon billet Sauvegarde la règle des 3-2-1

On va même un peu plus loin car :
on a 4 exemplaires de la donnée : la donné initiale (1), la donnée dans l'archive .tar.gz (2), la donnée copiée sur le serveur via rsync (3) et la donnée dans la sauvegarde borg (4).
on a 3 systèmes de sauvegarde : tar.gz horodatée, rsync et borg
on a 3 supports différents : un disque rattaché directement à la machine, un premier serveur situé sur un réseau autre que la machine sauvegardée, un volume NAS (soit un deuxième serveur).

Prérequis :
Avoir déjà utilisé Borg
Connaître Python, ou a minima savoir lire du code

Rôle de ce bout de code

L'objectif est de savoir si les sauvegardes lancées la nuit, reposant sur un script Borg, se sont bien passées. Pour cela, nous partons du principe que si une commande borg c'est bien lancée, dans la liste des sauvegardes renvoyées par Borg, on aura une sauvegarde portant le bon nom (le nom incluant la date du jour). Le nom de chaque sauvegarde est donc l'élément discriminant et est de la forme Documents_AAAA-MM-DD-HH:MM:SS. Exemple Documents_2018-10-31-10:10:10

Le script répond à notre besoin, à savoir éviter de faire un "borg list" sur X répertoires et nous renvoyer un OK quand on a une sauvegarde avec la bonne date, KO si il n'y a pas de sauvegarde ayant la date du jour et il indique le nombre de jours entre la dernière sauvegarde et la date du jour.

Pourquoi en Python et pas en bash ?

J'avais commencé à former mon Pandawan au Shell et nous aurions pu faire un script équivalent en shell. Mais je voulais aussi le former à des notions de programmation objet, lui montrer que l'on pouvait faire aussi des choses en Python et dérouiller mon propre Python. D'où le choix de ce langage.

Attention, nous ne sommes pas des spécialistes Python, nous savons juste faire des bouts de scripts & codes que nous saurons relire et améliorer dans plusieurs mois. Le but n'était pas de faire un code optimisé ultra efficace mais de faire quelque chose de lisible et réutilisable et maintenable, compréhensible par la première personne qui sait lire un peu de code.

Le code

Exemple de résultat d'exécution

Le script se lance via

Résultat de l'exécution quand on a bien une sauvegarde qui s'est déroulée sur la nuit

Résultat de l'exécution quand on a bien une erreur (et le nombre de jours permet de détecter que le script ne tourne plus depuis X jours par exemple).

Ainsi on sait que pour le dossier A et B, on a bien une sauvegarde. Pour le dossier C, il y a eu une erreur (vu que l'on a un K0) et il faudra donc aller analyser pour en savoir plus (coupure de réseau, lock qui a empêché la bonne exécution de Borg...)

Conclusion

Le code source et l'ensemble de cet article sont en licence CC BY SA, faites en ce que vous voulez. Si ça peut vous être utile, tant mieux ;)

Borg est-il prêt pour faire des sauvegardes de la production ? En un mot, je répondrai oui. En plus détaillé, il y aura le présent billet de blog. Les personnes voulant plusieurs retours d'expériences et sachant lire l'anglais pourront se tourner vers de post Reddit Reddit - Is Borg backup suitable for the production ?

Le contexte

Borg est utilisable et utilisé en production par différentes personnes avec qui j'ai discuté. Dans mon cas, je l'utilise pour sauvegarder des fichiers de serveurs Linux (fichiers plats et binaires), et des dumps de base de données.

Quelques liens

La page la plus complète que l'on peut trouver en français sur le sujet de Borg est celle du wiki de Sebsauvage

Lors des JRES, Framasky, l'administrateur système qui gère les machines de Framasoft qui permettent au projet Degooglisons d'exister avait une conférence Quelle infrastructure pour dégoogliser Internet - JRES 2017 dans laquelle il parle, entre, des outils de sauvegarde et évoque Borg.

Une autre conférence est celle donnée par Maurice LIBES, Didier MALLARINO, Sauvegardes en mode dédupliquée avec Borg-Backup : retour d'expérience, le titre parle de lui-même.

Autre lien, en anglais sur les Sauvegardes de bases de données, Create daily database backups with Borg

Enfin, ayant créé des alias pour mes sauvegardes personnelles que je fais aussi avec Borg, suite au partage d'expérience de Djan Gicquel, je mets le lien vers son article Alias et fonctions pour Borgbackup (Djan Gicquel avait lui-même adopté Borg suite à mon article de présentation, la boucle est bouclée).

Un espace dédié par serveur

Borg permet de la déduplication et si un même fichier est présent sur plusieurs serveurs, il peut être tentant (utile) de profiter de cette déduplication en sauvegardant ces différents serveurs dans un même espace. Le fichier ne sera sauvegardé d'une fois, commun aux sauvegardes des différents serveurs et conservé tant qu'une sauvegarde de l'un des serveurs y fera référence.

Par contre, dans le cas d'un répo unique, il s'avère que
if you back them up into a single repo, you will have to frequently resync the chunks cache on each server and also you can't do backups in parallel to same repo.

ce que l'on peut traduire par le fait qu'il faudra régulièrement lancer la commande de resynchronisation du cache sur chaque serveur qui fait ses sauvegardes via Borg et il n'est pas possible de sauvegarder plusieurs serveurs en même temps sur le même répo.

Pour ne pas avoir ces contraintes j'ai donc fait le choix de faire une stratégie de sauvegarde avec un espace dédié par serveur (et avec des sous-répertoires pour avoir différents repo Borg pour les différents types de données des serveurs).

Sens des sauvegardes : Push vs Pull

Push Borg marche très bien vers SSH. Mais cela nécessite d'installer Borg sur chaque machine client pour envoyer les données à sauvegarder sur un espace de fichier sur un serveur dédié. A ce sujet, voir le billet de blog de Karolak sur monter un serveur de sauvegarde avec Borgbackup

Pull C'est la machine de stockage qui lance Borg et centralise les tâches Cron de sauvegarde. Il faut monter l'espace distant à sauvegarder via SSHFS et alors faire la sauvegarde.

Le choix de l'un ou de l'autre dépend de plusieurs choses dont un aspet sécuritaire.

Dans le cas du Push, chacune des machines à un accès SSH sur le serveur de Sauvegarde. La compromission de la machine sauvegardée permet par rebond d'accéder à la machine de sauvegarde. Dans le cas du Pull, le serveur de sauvegarde a lui accès à toutes les machines et la compromission de ce dernier permet par rebond d'accéder à toutes les machines sauvegardées...

Dans le cas du Push, le client ne peut avoir accès qu'en "append" sur le serveur de backup et le serveur de backup n'a pas accès sur la machine client.

Quelques remarques

Prenons le cas de la sauvegarde d'un site web que l'on sauvegarde avec Borg. La déduplication marche quand les fichiers restent inchangés. Pour les dumps de la base de données, si il y a eu le moindre changement dans la base, le dump est différent et il sera vu comme un nouveau fichier. On profitera toutefois de la compression de Borg permettant un gain de place pour la sauvegarde et du fait que Borg découpe le fichier en chunk, et que les parties communes du fichier dump ne seront pas dédupliquées.

Les limites

On ne peut sauvegarder que des fichiers statiques. Même si Borg est rapide, une sauvegarde avec Borg prend un certain temps et le fichier ne doit pas avoir été modifié durant le laps de temps que dure la sauvegarde, sinon cela peut rendre la sauvegarde de ce dernier inconsistante.

Il n'y a pour l'instant pas d'interface graphique pour la gestion des sauvegardes, même si un projet Borg Web a été initié et repris par une start-up (ce sera le sujet d'un autre billet de blog. J'ai testé le projet en développement BorgWeb sans réussir à le faire fonctionner).

Améliorations à prévoir

Dans les améliorations que je prévois dans mon usage de Borg, il y a celui d'utiliser Borgomatic pour la création des configuration de sauvegardes. Car actuellement, je passe par la copie d'un script de référence contenant les lignes de sauvegarde et de conservation (option prune) que j'adapte au cas par cas...

Il existe des scripts pour Nagios et pour Zabbix qui vérifie la présence des sauvegardes et alertes si celle-ci sont manquantes. Je n'ai pas encore utilisé le plugin Zabbix (https://github.com/theranger/zabbix-borg) et c'est prévu

De même Borg peut s'interfacer avec l'outil BackupNinja. Là encore, c'est dans ma todo d'étudier ça.

Présentation du film

Illang : The Wolf Brigade (hangeul : 인랑 ; RR : Inrang, littéralement « Loup-garou ») est un film de science-fiction sud-coréen coécrit et réalisé par Kim Jee-woon, sorti en 2018. Il s'agit de l'adaptation du film d'animation japonais Jin-Roh, la brigade des loups de Hiroyuki Okiura (人狼, 1999) et du manga Kerberos Panzer Cop (犬狼伝説) de Mamoru Oshii.

Après sept années de préparation, en 2029, la Corée du Sud et la Corée du Nord se préparent à se réunifier. Les habitants se manifestent contre cette idée et, de plus en plus nombreux, se montrent violents envers le gouvernement. Parmi cette foule se faufile un groupe terroriste anti-réunification appelé « Sect » qui sème la terreur en ville : c'est pourquoi les dirigeants et la police créent une nouvelle unité spéciale pour les arrêter…

La critique de Genma

Disponible sur Netflix depuis le 19 octobre 2018, c'est un peu par hasard que je suis tombé dessus. Je n'avais lu aucun critique, n'avait pas connaissance de l'existance de ce film et je me suis laissé tenté en me disant pourquoi pas.

J'avais vu Jin Roh le film à sa sortie au cinéma en novembre 1999, il y a presque 20 ans. Je l'avais ensuite acheté en DVD et revu deux ou trois fois, mais pas récemment. Je ne saurai donc dire les différences qu'il peut y avoir entre le film anime et ce film live.

Je n'avais pas d'attente particulière quand à ce film. Et j'ai été agréablement surpris. J'ai beaucoup aimé le respect du design de l'armure de la brigade spéciale, les Panzers. C'est tout sauf du Cosplay bien réalisé, on y croit. L'armure semble peser son poids, est massive et en métal. On entend les bruits des balles qui ricochent dessus... On a aussi les scènes auxquelles on est droit de s'attendre : le noir complet et les yeux rouges qui soudain apparaissent, la mise en place du masque qui fait passer de l'homme à une machine sans âme, ou plutôt à un loup...

J'ai beaucoup aimé la reprise des lieux emblématiques du film anime, avec une reproduction des égouts tels qu'ils étaient dans mon souvenir. Les décors sont donc bien choisis même si au final on n'aura que peu de lieux différents sur tout le film.

Niveau musique, certains thèmes, tel que "Grace", par Hajime Mizoguchi et Yoko Kanno, sont directement repris de la B.O. de Jin Roh que j'avais beaucoup aimé.

Les acteurs jouent bien et sont bien choisis. Et le héros principal n'exprime aucune émotion, ne laisse rien transparaître comme on s'y attend, selon le caractère du personnage. Adaptation oblige, vu que cela se passe en Corée, les noms des personnages sont changés et sont donc Coréens.

On a un côté modernité avec l'usage de drones pour quelques scènes afin de rappeler que l'on est dans le futur et que l'on a des technologies avancées, sans que cela soit ça de la fiction.

Comme le film anime Jin Roh, le scénario est un peu complexe à appréhender avec l'intrigue mêlant complot et trahison.

Le film se déroule lentement, même si on a quelques scènes d'actions : cascade en voiture sur un parking, quelques scènes de combat et les scènes mettant en œuvre les Panzers en armures.

J'ai fait le choix de le voir en Version Française et je trouve que cela passe plutôt bien, le doublage est bien fait et de qualité.

En conclusion, que vous n'ayez pas vu Jin Roh ou si au contraire vous l'avez vu et aimer, je ne peux que vous recommander de regarder Illang, qui n'est pas une pale une copie du film anime, mais bel et bien une œuvre qui le modernise sans le trahir, qui respecte l'œuvre originale sans la trahir.