Victor – Page 33

Procédure de restauration de sauvegarde… Surprise !

Depuis plusieurs mois donc, mes services auto-hébergés sont sauvegardés quotidiennement de façon automatique et incrémentale. Je suis en théorie protégé contre la perte de mes données en cas de panne matérielle du support de stockage de mon serveur. Ça, c’est la théorie, il me restait en l’occurrence à valider le processus de sauvegarde en m’assurant de la façon de restaurer les données.

J’ai donc commencé ces derniers jours l’écriture d’un script ansible permettant de redéployer automatiquement l’ensemble de mes services sur un nouveau serveur si besoin. L’occasion rêvée de vérifier que la restauration de sauvegarde fonctionne correctement.

Après configuration de duplicity sur la nouvelle machine, je tente donc de restaurer un fichier pris au hasard:

duplicity restore --file-to-restore path/to/wallabag/vendor/jdorn/sql-formatter/LICENSE.txt -t now cf+hubic:// test/LICENSE-restored.txt

J’obtiens une erreur dès les premières tentatives : No backup chains found, et lis au détour d’une page web qu’il faut à priori effectuer un list-current-files au préalable. Il faudra que je vérifie cette information lors du test réel de mon script sur un système vierge. Je découvre donc que duplicity récupère dans un premier temps tous les fichiers manifest. La récupération des fichiers se poursuit, et c’est le drame :

Giving up after 1 attempts. NoSuchObject: Object 'duplicity-inc.20180212T113006Z.to.20180213T113007Z.manifest.gpg' doesn't exist (HTTP 404)

L’un des fichiers n’est pas renvoyé par hubiC. Il est néanmoins visible dans l’interface, mais impossible de le récupérer, la requête effectuée par l’interface web retourne elle aussi une mauvaise erreur 404. Ce problème de manifeste manquant concerne une chaîne secondaire, mais impacte malheureusement l’ensemble de la collection. Impossible de restaurer les données via duplicity…

Continuer la lecture de « Procédure de restauration de sauvegarde… Surprise ! »

Sauvegarde distante avec duplicity

Suite à la migration de la majorité de mon nuage de services vers mon réseau en passant à l’auto-hébergement, la question de la sauvegarde des données est devenue cruciale. Côté cahier des charges, les principaux critères retenus étaient les suivants :

Sauvegarde externe géographiquement
Automatique
Chiffrée

Après de nombreuses recherches, j’ai décidé d’utiliser duplicity pour réaliser la sauvegarde et le service hubiC d’OVH pour le stockage des données sauvegardées. Voici donc la procédure utilisée pour mettre en place une sauvegarde incrémentale quotidienne, avec sauvegarde complète à intervalle régulier.

Pour commencer, il convient d’installer les composants nécessaires:

sudo aptitude install duplicity python-pip python-dev gcc
sudo pip2 install pyrax

Ayant décidé d’envoyer les sauvegardes dans mon espace hubiC, et afin de permettre à duplicity de communiquer avec hubiC, il faut au préalable autoriser l’application dans l’interface web du service. On va donc créer une nouvelle application, renseigner un nom, duplicity par exemple, et un domaine de redirection valant http://localhost/. On note ensuite les paramètres « Client ID » et « Client secret » qui serviront pour paramétrer la connexion à hubiC sur la machine source.

Le paramétrage s’effectue dans le fichier ~/.hubic_credentials :

[hubic]
email = your_email
password = your_password
client_id = api_client_id
client_secret = api_secret_key
redirect_uri = http://localhost/

On limite ensuite les droits liés au fichier:

chown 600 ~/.hubic_credentials

A ce stade, on peut faire un premier test afin de valider la configuration, par exemple, sauvegarder le répertoire test dans le conteneur test qui sera accessible à l’adresse suivante: https://hubic.com/home/browser/#test.

duplicity test cf+hubic://test

Pour lister le contenu du répertoire distant, la commande dédiée est:

duplicity list-current-files cf+hubic://test

Continuer la lecture de « Sauvegarde distante avec duplicity »

[ArchLinux] Downgrade d’un package

Il est possible d’installer une ancienne version d’un package en utilisant le cache de pacman, si celui-ci n’a pas été nettoyé depuis la mise à jour précédente. Par exemple, pour revenir à la version 5.6.0-1 de npm, on utilisera la commande:

pacman -U /var/cache/pacman/pkg/npm-5.6.0-1-any.pkg.tar.xz

Et on attendra la correction du bug 19989 pour réinstaller une version 5.7.x.

Des Headers. En veux-tu ? En voilà !

J’ai commencé à me pencher sur HAProxy et à faire quelques tests, ce qui m’a conduit à m’intéresser aux entêtes de sécurité qu’un serveur Web peut renvoyer. Dans la même veine que SSL Labs, j’ai découvert securityheaders.io qui permet de faire rapidement le point sur les entêtes des réponses http d’un serveur pour une url donnée.

De mon côté, je me suis donc assuré de la présence des entêtes suivantes:

Referrer-Policy
Strict-Transport-Security
X-Content-Type-Options
X-Frame-Options
X-XSS-Protection

Configurées de la manière suivante :

http-response set-header Strict-Transport-Security "max-age=63072000;"
http-response set-header X-Content-Type-Options nosniff
http-response set-header Referrer-Policy no-referrer-when-downgrade
http-response set-header X-Frame-Options SAMEORIGIN
http-response set-header X-XSS-Protection 1;mode=block

Par ailleurs, j’en profite pour m’assurer que les informations concernant le serveur répondant à la requête ne soient pas renvoyées :

http-response del-header Server

Du coup, j’obtiens un petit A, étant donné que je n’ai pour l’instant pas intégré l’entête « Content-Security-Policy ».

Source: Securing haproxy and nginx via HTTP Headers.

Préparation du système pour le Pi

Reprise synthétique des informations de la documentation officielle pour l’installation de l’image d’un système d’exploitation pour le Raspberry Pi depuis GNU/Linux.

Première étape:

Télécharger Raspbian.
Vérifier le hash du zip récupéré.
Extraire le fichier image de l’archive ZIP.
Lister les supports de stockage connectés avec lsblk.
Brancher la carte SD/microSD.
Réexécuter lsblk.
Noter l’identifiant correspondant de la forme mmcblk0 ou sdX (X, lettre minuscule non accentuée).
Si d’éventuelles partitions sur la carte sont montées, les démonter: umount /dev/sdX1.

Place ensuite à l’installation:

dd bs=4M if=2018-03-13-raspbian-stretch.img of=/dev/sdX status=progress conv=fsync

Enfin, exécuter sync afin de s’assurer que l’on peut retirer la carte sans risque.

Pour ma part, j’ajoute une étape supplémentaire consistant à activer SSH par défaut. Pour cela, il suffit de monter la carte et de créer un fichier vide nommé ssh dans la partition boot: sudo touch ssh (point de montage visible dans lsblk. On peut démonter toutes les partitions de la carte ensuite). De cette manière, le Pi devient accessible en SSH avec les identifiants par défaut dès son premier démarrage et on peut ainsi exécuter directement un script Ansible pour le configurer automatiquement.