PROJET AUTOBLOG


Le blog de Genma

Site original : Le blog de Genma

⇐ retour index

Les tutoriaux de Grenode

jeudi 1 janvier 1970 à 01: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 !

Le son du soir dans les anime

jeudi 1 janvier 1970 à 01: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 ! ;)

Secure-delete

jeudi 1 janvier 1970 à 01: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)

Vorta, interface graphique à Borg

jeudi 1 janvier 1970 à 01: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.

Rsync Checker petit script Python sans prétention

jeudi 1 janvier 1970 à 01: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...