KrISS feed 8.7 - A simple and smart (or stupid) feed reader. By Tontof
  • Monday 10 December 2018 - 09:00

    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.

  • Wednesday 12 December 2018 - 09:00

    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

    [SauvegardeBorg]
    Documents_Dossier_A = /Backup/Documents/Dossier_A/
    Documents_Dossier_B = /Backup/Documents/Dossier_B/
    Documents_Dossier_C = /Backup/Documents/Dossier_C/
    #!/usr/bin/python
    # -*-coding:Utf-8 -*
    import configparser
    import sys
    import os.path
    import datetime

    #===========================================================
    # SCRIPT DE VALIDATION DES DIFFERENTES SAUVEGARDES
    #==========================================================

    #"------------------------------------------------------------
    # Initialisation des chemins
    # On a un fichier avec
    # * en clef : la sauvegarde à valider
    # * en valeur : le chemin dans lequel on vérifie la sauvegarde
    # via le check de borg list avec une sauvegarde borg à la date du jour
    config = configparser.ConfigParser()
    config.optionxform = str
    config.read('./Config.ini')
    configsauvegardeBorg = config['SauvegardeBorg']

    def fctCheckBorg():
    print("==========================================")
    print(" CHECK DES SAUVEGARDES BORG")
    print("==========================================")

    from datetime import datetime
    # Lecture de tous les éléments de BorgBackupPath
    for key,value in config.items('SauvegardeBorg'):
    try:
    borgCommand="borg list "+ value
    sortie = os.popen(borgCommand).read()
    tabBorgList = sortie.split("\n")
    number=len(tabBorgList) -2
    # La ligne est de la forme
    # Documents_2018-10-31-10:10:10 Wed, 2018-10-31 10:10:10 [b576a0703b7144be76afd2e2]
    # On coupe pour trouver la date
    lastBackupDate = tabBorgList[number].split(",")[1].split("[")[0].split(" ")[1]
    # Conversion du String en Date
    lastBackupDateToDate = datetime.strptime(lastBackupDate,'%Y-%M-%d')
    # Récupération de la date du jour au bon format
    now=datetime.strptime(datetime.now().strftime('%Y-%M-%d'),'%Y-%M-%d')
    # Calcul du delta
    delta = now - lastBackupDateToDate
    if (delta.days == 0):
    print(key, ": statut OK. Nombre de jours depuis la dernière sauvegarde : ", str(delta.days))
    else:
    print(key, ": statut KO. Nombre de jours depuis la dernière sauvegarde :", str(delta.days))
    except Exception as e:
    print("Erreur rencontree : ")
    print(str(e))
    continue
    print("\n")
    return 0;

    Exemple de résultat d'exécution

    Le script se lance via

    python3 BorgChecker.py

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

    Documents_Dossier_A : statut OK. Nombre de jours depuis la dernière sauvegarde : 0.
    Documents_Dossier_B : statut OK. Nombre de jours depuis la dernière sauvegarde : 0.

    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).

    Documents_Dossier_C : statut KO. Nombre de jours depuis la dernière sauvegarde : 3.

    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 ;)

  • Wednesday 12 December 2018 - 09:00

    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).

  • Tuesday 18 December 2018 - 09:00

    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.

    #!/bin/bash
    apt-get update
    listUpgrades=`apt list --upgradable |grep upgradable |cut -d/ -f1`
    execUpgrades="DEBIAN_FRONTEND=noninteractive apt-get --yes --assume-yes -o DPkg::options::=\"--force-confdef\" -o DPkg::options::=\"--force-confold\" --only-upgrade install "$listUpgrades
    eval $execUpgrades

    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.

  • Wednesday 02 January 2019 - 09:00

    Comme je le disais dans un billet écrit il y a quelques années et que je re-mentionne en chaque début d'année, je ne suis pas pour la tradition des voeux de nouvel an. Mais le début d'une nouvelle année c'est toutefois l'occasion de faire un bilan de l'année passée et de se projeter dans l'année à venir. Le changement d'année ne change pas grand-chose au quotidien, et pourtant, cette année, certaines choses sont différentes. D'où le besoin pour moi de rédiger ce billet.

    L'année 2018 et l'importance de pouvoir se projeter dans l'avenir

    L'année 2018 a été une année compliquée, un résumé avait été fait à la fin de l'été dans le billet Retour après deux mois de silence, je ne reviens pas dessus. En septembre et octobre, j'ai eu du temps pour parler, pour comprendre (cf mon billet De l'importance d'être aidé) et ai appris que, pour éviter d'être débordé et de ne pas pouvoir s'en sortir, il fallait apprendre à prendre du recul et surtout arriver à se projeter dans l'avenir. D'où le présent billet.

    Se projeter dans l'avenir, c'est facile à dire, mais difficile à faire. Le lifehacking a été poussé à l'extrême chez moi (Lifehacking et vacances) et abandonné (Tout intellectualiser). Abandonné ? J'en ai gardé les todo et des bonnes méthodes d'organisation. Mais je ne suis plus ma vie au quart d'heure, au pomodoro prêt. Et je dois donc retrouver une nouvelle façon de faire pour me projeter dans l'avenir.

    Fin d'année 2018

    La fin d'année s'est terminée sur une semaine de congés durant laquelle je n'ai pas fait grand chose. J'ai pris conscience de la fatigue cumulée durant ces derniers mois. J'aurai pu faire plein de projets et avancer plein de choses, chargeant mes journées de nombreuses tâches. J'ai fait le choix et j'ai pris le temps de réfléchir, de me poser. Et de penser à l'année à venir. J'ai pris du temps pour méditer, me vider l'esprit. Passer du temps en famille, à vivre l'instant présent, tout simplement.

    Et pourtant je me suis rendu compte que je n'ai pas totalement réussi à me déconnecter, à décrocher, à faire autre chose. Mon cerveau a beaucoup de mal à penser à autre chose, à faire une pause. Il est sans cesse en réflexion. J'ai encore beaucoup de travail à faire sur ce sujet pour pouvoir vivre mieux et plus sereinement. Et l'année 2019 va m'amener à relativiser, à apprendre à revoir mes priorités, à faire abstraction de certaines choses...

    L'année 2019

    L'année 2019 sera une année placée sous le signe du changement pour moi. Tout d'abord parce que ce sera l'année de mes 40 ans. Pour l'instant, je n'ai pas grand-chose de prévu pour fêter cette étape symbolique. Je ne suis pas quelqu'un qui accorde beaucoup d'importance aux anniversaires, aux fêtes et ce sont toujours des moments compliqués pour savoir quoi offrir à quelqu'un ou quoi répondre à la question "tu voudrais qu'on t'offre quoi".

    Le plus important pour moi cette année, c'est surtout que des événements personnels ont fait, font et feront que j'ai de nouveau eu à me remettre en question et à revoir les perspectives et priorités, et que j'aurai à réorganiser ma vie de façon assez conséquente et durable. Certain.e.s d'entre vous savent, d'autres devineront le message subliminal, les autres le découvriront le moment venu....

    Le blog abordera si tout va bien et je l'espère une nouvelle thématique axée autour d'un nouveau retour d'expérience ! Si j'y arrive, ce sera le signe que je sais encore trouver du temps pour moi, pour ma bulle personnelle, pour mon jardin secret (pas si secret que ça vu qu'il est exposé à la vue de tou.te.s sur Internet). A suivre, le début de mes nouvelles aventures à la fin du printemps...

    En attendant, comme d'habitude, des billets techniques autour du logiciel libre, des billets de réflexions personnelles et autres, car mon blog restera dans la continuité.

  • Monday 07 January 2019 - 09:00

    Après mon billet Borg Checker, petit script Python sans prétention, voici un autre billet d'un petit outil simple mais effiace, là encore en deux étapes.

    Les besoins

    Nous avons un Rsync qui se fait dans le sens "Machine distance" en source, "Machine locale" en cible, le tout à travers SSH, lancé avec sudo - pour avoir les droits root et donc aller où on veut et s'affranchir des problèmes de permission.

    Nous aimerions valider que les commandes rsync exécutées sont valables /se sont bien déroulées / ne sont pas tombées en erreur. Sachant que nous avons un script shell global qui lance plusieurs scripts shells différents qui eux-même lancent plusieurs commandes Rsync au sein du même script.

    SSH

    Les connexions SSH se font depuis la machine Backup en tant que client du serveur SSH qui est sur la machine à sauvegarder.

    La connexion se fait via une connexion par clef (la clef publique de la machine de sauvegarde, Backup, a été ajoutée sur la machine à sauvegarder.

    Rsync avec Sudo à travers SSH

    Pour pouvoir copier les fichiers en rsync avec sudo, sans avoir à saisir de mot de passe, il faut faire un sudo visudo ce qui va permettre d'éditer le fichier /etc/sudoers et d'autoriser le lancement de la commande sudo rsync sans avoir à saisir de mot de passe pour l'utilisateur désigné, ici Genma.

    sudo visudo

    On ajoute en bas de fichier la ligne

    genma ALL= NOPASSWD:/usr/bin/rsync

    Astuce pour enregister / quitter dans le cas où l'éditeur par défaut est VI :

    :wq!

    La sauvegarde via Rsync

    Exemple de script lançant des commandes Rsync la nuit via une tâche Cron. On écrit des traces / des logs dans un fichier en local. Ce fichier de log permettra de valider l'exécution des commandes (cf section ultérieure dans le fichier).

    #!/bin/bash

    LOG=/Backup/Machine_distante_A/Sauvegarde_rsync_ssh_`date +%Y-%m-%d`.log

    # Fonction qui permet d'écrire des logs dans le fichier de log
    # Le texte en paramètre de la fonction sera écrit à la suite de la date et heure
    Inlog()
    {
    echo `date +'%Y-%m-%d %H:%M:%S'`": $1" >> $LOG
    }

    # La variable "$?" contient le code de retour de la dernière opération.
    # Ici c'est le code d'execution de la commande "rsync".
    # "0" - la commande "rsync" s'executé correctement,
    # Autre valeur en cas échéant, c'est que l'on a donc une erreur
    check_rsync()
    {
    result_rsync=$(echo $?)
    # La variable "result_rsync" recupere la valeur de "$?"
    # Si "result_rsync" <>"0" alors il avait une erreur lors d'execution de la commande "rsync" et le script s'arrête
    if [ "$result_rsync" == "0" ]; then
    Inlog "$1 Rsync OK"
    else
    Inlog "$1 Rsync KO"
    fi
    }

    Inlog "Début Rsync Machine_distante_A /var_www sur Serveur_Sauvegarde"
    rsync -avz --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress --ignore-existing genma@IP_Machine_Distante:/var/www /Backup/Machine_distante_A/var/www/
    # Pour appeler la fonction de check du retour de la commande Rsync
    check_rsync "Rsync Machine_distante_A /var_www sur Serveur_Sauvegarde"
    Inlog "Fin Rsync Machine_distante_A /var_www sur Serveur_Sauvegarde"

    Inlog "Début Rsync Machine_distante_A /data/sql sur Serveur_Sauvegarde"
    rsync -avz --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress --ignore-existing genma@IP_Machine_Distante:/Backup/mysql/ /Backup/Machine_distante_A/data/sql/
    # Pour appeler la fonction de check du retour de la commande Rsync
    check_rsync "Rsync Machine_distante_A /data/sql sur Serveur_Sauvegarde"
    Inlog "Fin Rsync Machine_distante_A /data/sql sur Serveur_Sauvegarde"

    Un peu de Python

    Un peu comme on avait plusieurs commandes Borg lancées et qu'on vérifiait que chacune d'elles était correctes (cf Borg Checker, petit script Python sans prétention), on vérifiera que les différents scripts et les différentes commandes Rsync se sont déroulées sans soucis.

    Le besoin est donc de savoir quelles sont les Rsync qui ont posés soucis pour ensuite traiter manuellement ces erreurs / cas particuliers.

    Pour ce faire, la machine de sauvegarde lance un script Python (via une tâche cron à une heure bien postérieure à celles du déroulement des sauvegardes).

    Dans ce script Python, on vérifie la présence du fichier de log à la date du jour : cela valide qu'au moins la commande Cron a bien lancé le script Shell contenant les commandes rsync. Le nom du fichier de log est standardisé (cf script Shell ci-dessus) et se trouve dns un dossier. Le fichier est récupéré via la dernière commande de rsync dans un dossier local du serveur.

    Le fichier de log étant présent, on parcourt le fichier de logs à la recherche d'une ligne KO et on affiche la dite ligne si besoin. Cf le script Shell et sa fonction check_rsync() qui teste le retour de la commande rsync.

    **Fichier Config.ini** : contient les chemins vers les fichiers de logs de chaque machine sauvegardée.

    Un script de sauvegarde Shell contenant des commandes rsync génère un fichier de log par exécution, fichier de log ayant dans son nom la date du jour.

    [FichiersLogsRsyncSsh]
    Machine_distante_A = /Backup/Machine_distante_A/
    Machine_distante_B = /Backup/Machine_distante_B/

    **Fichier CheckRsyncSSH.py**

    #!/usr/bin/python
    # -*-coding:Utf-8 -*
    import configparser
    import sys
    import os.path
    import datetime

    # Initialisation des chemins
    # On a un fichier avec
    # * en clef : la sauvegarde à valider
    # * en valeur : le chemin dans lequel on vérifie la présence d'un fichier de log
    config = configparser.ConfigParser()
    config.optionxform = str
    config.read('./Config.ini')
    configRsync = config['FichiersLogsRsyncSsh']

    # Code de la fonction
    def fctFichierLogRsynsSSH():
    print(" ")
    print(--------------------------------------------")
    print(" CHECK DES RSYNC QUOTIDIENS")
    print(" via un check de présence des fichiers logs")
    print("-------------------------------------------")

    now = datetime.datetime.now().strftime('%Y-%m-%d')

    # Vérification qu'on a bien un fichier de log à la date du jour
    for key,value in config.items('FichiersLogsRsyncSsh'):
    fichierAtrouver = key + "_" + now + ".log"
    found = 0;
    for fileName in os.listdir(value):
    if (fichierAtrouver == fileName):
    found = 1;
    break;
    if (found == 0):
    print(key + ': statut ' + '\x1b[6;31m' + 'KO' + '\x1b[0m' + ' Fichier absent : ' + fichierAtrouver + "!!!")
    if(found == 1):
    print(key + ': statut ' + '\x1b[6;32m' + 'OK' + '\x1b[0m' ' Fichier trouvé : ' + fichierAtrouver);

    # Vérification du contenu du fichier
    chemin = value + fichierAtrouver
    f = open(chemin,'r')
    lignes = f.readlines()
    f.close()
    ligneKO = 0;
    for ligne in lignes:
    # est ce que la ligne contient un KO
    # KO inscrit car le rsync a renvoyé une erreur (cf script Shell)
    # si oui, la ligne est KO
    if "KO" in ligne:
    # On s'arrête au 1er KO, vu qu'on ira voir le fichier en détail du coup
    ligneKO = 1;
    break
    if (ligneKO == 0):
    print(key + ': statut ' + '\x1b[6;32m' + 'OK' + '\x1b[0m' + ' Tous les Rsync sont OK.')
    if (ligneKO == 1):
    print(key + ': statut ' + '\x1b[6;31m' + 'KO' + '\x1b[0m' ' Au moins un rsync contient un KO !!!')
    print("La ligne concernée par un KO est : " +ligne)
    ligneKO = 0;
    found = 0;
    print (" ")
    return 0;

    # Appel de la fonction principal
    fctFichierLogRsynsSSH()

    Pour le lancer le script :

    python3 CheckRsyncSSH.py

    Quel résultat ?

    Si on lance le script manuellement, la sortie est donc sur la ligne de commande.

    On aura donc un OK en vert ou un KO en rouge qui apparait dans le terminal ce qui permet de facilement distinguer / voir les lignes à analyser. Le Nom du fichier (et par conséquence de la sauvegarde) en échec apparaît. Il faut alors analyser ensuite plus finement en allant relancer le script global ou la commande rsync incriminée, en regardant les logs dans le terminal...

  • Wednesday 09 January 2019 - 09:00

    Présentation de Vorta

    Vorta est une interface graphique / un client du logiciel de sauvegarde Borg pour les postes de travail sous macOS X et différentes distributions GNU/Linux. Le but est donc d'intégrer BorgBackup à votre environnement de bureau

    Dit autrement, Vorta est à Borg ce que GRsync est à Rsync : une interface graphique complète pour lancer graphiquement une sauvegarde avec Borg.

    Le prérequis à son usage et bien évidemment d'avoir compris comment Borg marchait, pour savoir quels champs remplir et le pourquoi de tel ou tel option dans cette interface graphique. Le présent billet n'est ni un tutoriel sur Borg, ni un tutoriel sur Vorta. Je me contente de faire un retour d'expérience sur Vorta.

    Le projet est disponible sur Github : https://github.com/borgbase/vorta

    Dans la documentation il est indiqué qu'un simple

    pip3 install vorta


    suffit à l'installer.

    Sur mon Ubuntu 18.04, j'ai rencontré des erreurs et il semble que les prérequis à l'installation soit de faire :


    pip3 install PyQt5
    pip3 install keyring==12.0.0 --force-reinstall

    C'est donc encore en beta, la peinture n'est pas fraîche...

    Quelques astuces

    Pour le lancer, il faut le faire via la commande

    vorta --foreground

    car sinon aucun interface graphique n'apparaît à l'écran.

    Quelques tests que j'ai fait

    Par défaut, Vorta ne marche pas sur un répertoire Borg existant pour lequel on n'a pas de phrase de passe (pas de chiffrement de la sauvegarde) : le chiffrement est donc obligatoire en utilisant Vorta.

    La création d'un nouveau dépôt depuis l'interface et les sauvegardes dans ce dernier marchent.

    J'ai fait une comparaison de l'espace pris pour une même sauvegarde (de /home) avec une commande Borg manuelle versus une sauvegarde faite avec Vorta et on arrive à la même taille. Ce qui est parfaitement logique car on aura alors les mêmes options... Vorta n'est donc bien qu'une interface graphique à Borg.

    Quelques captures d'écran ?

    Une version en français ?

    Comme indiqué dans l'issue ici https://github.com/borgbase/vorta/issues/99, les administrateurs systèmes ont la nécessité de parler anglais et cela ne pose pas de soucis que l'interface du logiciel soit en anglais. Par contre un logiciel conçu comme étant une interface graphique à Borg pour un usage bureautique a pour cible un plus large publique non forcément anglophone.

    Pour l'instant, l'interface graphique est en anglais avec des chaînes de caractères codées en dur, mais comme l'interface graphique est en QT, elle doit pouvoir facilement être internationalisée et internationalisable. Je me suis proposé pour faire la version française (traduction des chaînes de caractères), vu que c'est du logiciel libre.

  • Tuesday 15 January 2019 - 09:00

    Il y a quelques années, j'avais écrit un billet sur la commande Shred
    Shred - effacer définitivement un fichier.

    Mais cette commande ne permet que d'effacer des données de type ficher sur un disque dur mécanique. Pour aller plus loin, il existe un outil plus complet, secure-delete qui s'installe facilement

    sudo apt-get install secure-delete

    Et qui une fois installé apporte les commandes suivantes dans la ligne de commande (un terminal shell) :

    - srm : Cette commande est utilisée pour supprimer des fichiers et des répertoires de votre disque dur. Un équivalent de Shred
    - smem : un outil qui nettoie en toute sécurité la mémoire de l'ordinateur (RAM), qui peut contenir l'état des programmes en cours d'exécution ainsi que des données de programme sensibles, même après la mise hors tension de l'ordinateur. (pour contrer les attaques de type Cold boot).
    - sfill : Efface toutes les données de l'espace libre sur votre disque. Pour s'assurer qu'il n'y a plus de fichiers récupérables sur le disque / la partition via des outils comme Photorec / TestDisk
    - sswap : Efface toutes les données de la partition de swap.

    On retrouvera toutes ces commandes sur un tutoriel en anglais Permanently Delete Files on Linux with Secure-Delete

    A noter que le shred ne marche que pour des disques durs mécaniques (à plateau), les SSD étant à base de cellules, à part réduire prématurément la durée de vie du disque, l'effacement via écrire et écrire à différents endroits / différentes cellules et non effacer toujours le même espace comme c'est le cas d'un disque dur à l'ancienne. La solution pour les SSD est le chiffrement intégral du disque avec protection par phrase de passe pour protéger les données (qui sont vue comme du blob aléatoire si on ne déchiffre pas).

    Et pour faire l'inverse, à savoir retrouver des données sur un disque dur, on pourra utiliser des outils comme TestDisk/Photorec ou
    une distribution Linux spécialisée dans le forensic, Deft (analyse post-mortem, un peu ce que fait l'expert judiciaire Zythom)

  • Thursday 17 January 2019 - 09:00

    Quand on regarde des anime, il y a des sons qui marquent. J'ai regardé beaucoup d'anime durant mon enfance / adolescence (génération Club Dorothée) et durant ma vie d'adulte. Je regarde de nouveau une série sur Netflix (ce sera le sujet d'un prochain billet). Et je retrouve des sons d'ambiance qui me sont familiers. Pour ne citer que lui, le son de cloche des écoles que l'on entend dans tous les anime dans lesquels les protagonistes - les héros sont des écoliers, collégiens ou lycées...

    Autre, son, le son du soir est une série de trois tonalités, une basse, une haute, puis la première basse répétée, que l'on entend souvent dans un type de scène particulier : c'est la fin de journée, le soleil est couchant, les héros marchent le long d'une route, sur un chemin, le long d'une rivière...

    Je me suis demandé ce qu'était ce son si familier. Et j'ai posé la question à mon moteur de recherche préféré. Et comme je m'y attendais, Internet oblige, quelqu'un d'autre y avait pensé avant moi - s'était posé la question !!!

    "Le son du soir" est une série de trois tonalités, une basse, une haute, puis la première basse répétée. Le son semble être produit par un enregistreur standard du genre que l'on pourrait retrouver en la possession d'un personnage à l'école primaire. "Le son du soir" se produit le plus souvent pendant une accalmie en action ou en conversation, généralement au coucher du soleil et en été. https://www.reddit.com/r/anime/comments/p4tfv/anime_mysteries_the_evening_sound/

    Ce son, c'est notes, ce sont celles du vendeur de tofu qui tire sa charette dans les rues tranquilles des quartiers de Tokyo, cf cette vidéo sur Youtube
    Tofu vendor on streets of Tokyo.

    Voilà, comme ça vous aussi vous saurez ! ;)

  • Tuesday 22 January 2019 - 09:00

    Présentation de Grenode

    Grenode est un opérateur Internet créé en 2008. Cette structure est issue de la volonté de participer à la décentralisation de l'Internet dans la région grenobloise. Son objectif actuel est de mutualiser l'accès à Internet pour ses membres. Grenode est membre de Gitoyen, de Rézopole ainsi que correspondant de la FFDN.

    Différents tutoriels sont en lignes

    Parmi lesquels je retiendrai :
    - Orchestration de configuration avec Ansible
    - Les sauvegardes avec les outils backupninja et duplicity.
    - Backups avec borg en 2ème partie du tutoriel
    - Configuration / Utilisation d'etckeeper

    N'hésitez pas à fouiller sur le site pour avoir d'autres tutoriels.
    Et merci aux membres de Grenode pour leur partage de connaissance !