Installation – Page 3

dotfiles, git et GNU stow

En septembre 2016, j’avais commencé à écrire l’introduction de cet article. J’expliquais donc que je venais de réinstaller le système d’exploitation de mon ordinateur portable, pour passer de Debian 8 à Arch Linux. À ce moment-là, c’était donc posé la question de la synchronisation de la configuration de l’environnement entre machines. Par configuration de l’environnement, je désigne ici les fichiers de configuration des différents logiciels que j’utilise, plus généralement appelés « dotfiles », car commençant par un point, ou étant stocké dans le dossier .config du répertoire utilisateur.

Pour gérer mes configurations entre machines, j’ai donc utilisé le duo Git et GNU stow depuis lors. Git bien sûr pour la synchronisation entre machines et l’historisation, et GNU stow, pour le déploiement des fichiers à leur emplacement dédié.

Fonctionnement

Par défaut, stow créé un lien symbolique dans le répertoire parent de celui à partir duquel on exécute la commande, pour tous les fichiers concernés par la commande. Ma configuration part du principe que mon dépôt git dotfiles est stocké à la racine de mon répertoire utilisateur, à savoir donc ~/dotfiles, et que toutes les commandes stow sont exécutées depuis ce dossier. L’installation de la configuration s’effectue alors en appelant la commande stow avec pour paramètre le nom du logiciel dont on souhaite déployer la configuration. Au niveau de la structure, mon dépôt git se présente donc sous la forme d’une liste de répertoire contenant chacun le chemin vers la configuration du logiciel concerné, c’est-à-dire :

soit directement le fichier si celui-ci est stocké directement à la racine du répertoire utilisateur: c’est le cas par exemple du fichier .gitconfig.
soit dans une arborescence de répertoire correspondant à son emplacement: par exemple pour i3, la configuration est stockée dans ~/.config/i3, j’ai donc dans mon dépôt un dossier i3 contenant l’arborescence .config/i3.

Voici un extrait de mon dépôt en image pour expliciter la situation.

Ainsi, pour déployer le fichier de configuration de Git, j’exécute la commande suivante, depuis mon dossier dotfiles:

stow git

Ce qui aura pour effet de créer un lien symbolique .gitconfig vers le fichier .gitconfig de mon dépôt git. Si on souhaite modifier le répertoire de destination, on peut utiliser l’option -t. Dans l’image ci-dessus, pour déployer la configuration ansible, j’utiliserai alors:

stow -t / ansible

A noter que stow effectue la création du lien symbolique à la condition que le fichier n’existe pas. Si un fichier de configuration par défaut existe déjà, il sera nécessaire de le supprimer d’abord avant de pouvoir procéder à l’exécution de la commande stow.

Dernier point, si je souhaite re-déployer la configuration git, j’utiliserai alors l’option -R, soit la commande :

stow -R git

Conclusion

Le duo git + GNU stow est plutôt efficace pour ce qui est de la gestion des fichiers de configuration, les fameux fichiers dotfiles, et pour la synchronisation entre machines. Je m’en étais également servi pour stocker et déployer facilement certains fichiers de configuration sur mes serveurs, avant de commencer à automatiser avec ansible. Si je rédige aujourd’hui, cet article sur le sujet, c’est pour garder une trace d’une méthode robuste qui m’a été utile pendant plus de deux ans. Néanmoins, la structure actuelle du dépôt git ne me convient plus autant qu’avant et je souhaiterais passer à une organisation plus proche, ou même identique à l’arborescence présente sur le disque. J’étudie donc les autres solutions de gestion des dotfiles, et m’intéresse en particulier à rcm; mais ceci est une autre histoire, pour un autre article.

RSSHub

Ayant testé un moment la plateforme Instagram et souhaitant être en mesure de suivre les publications d’une sélection de comptes publiques directement dans mes flux RSS, je me suis tourné, après quelques recherches, vers une solution open source plus que prometteuse, à savoir RSSHub.

On peut constater rapidement en parcourant le github du projet que les principaux contributeurs sont d’origines asiatiques, comme l’attestent les caractères. Cela ne nuit en rien au projet, puisque la documentation en langue de Shakespeare est plutôt complète, si ce n’est pour la lecture des commentaires présents dans le code, ou des issues sur Github.

J’ai donc fait le choix de tester cette solution, et pour une fois, plutôt que de l’héberger sur l’une de mes machines, j’ai choisi de suivre la solution GCP décrite dans la documentation du projet. Le but étant de savoir si mon utilisation reste dans le palier gratuit fournit par Google pour l’utilisation d’un App Engine, et surtout, de pouvoir tester facilement l’intégration avec FreshRSS. Enfin dernier point, cela me permet de ne pas me poser la question de l’hébergement d’une solution NodeJS, qui nécessiterait un peu de travail de configuration pour arriver à une situation satisfaisante dans mon infrastructure auto-hébergée.

Commençons par quelques notes concernant la gestion de profils au niveau de l’utilitaire gcloud. En premier lieu, création d’un profil rsshub.

gcloud config configurations create rsshub

Voir le détail de la configuration active.

gcloud config list

Lister toutes les configurations de comptes disponibles.

gcloud config configurations list

Et enfin, activer la configuration rsshub.

gcloud config configurations activate rsshub

Passons ensuite à la préparation du déploiement de l’application. Pour cela, je créé un fichier app.yaml à la racine du projet afin de décrire la façon de déployer le programme sur la GCP et le configurer.

# [START app_yaml]
runtime: nodejs10
basic_scaling:
   max_instances: 1
network:
   forwarded_ports:
       - 80:1200
       - 443:1200
# environment variables section, refer to Settings
env_variables:
   CACHE_EXPIRE: '300'
   HTTP_BASIC_AUTH_NAME: '<username>'
   HTTP_BASIC_AUTH_PASS: '<password>'
#[END app_yaml]

Pour terminer, déploiement de l’application dans App Engine.

gcloud app deploy

À ce stade, je dispose donc d’un RSSHub agissant comme proxy entre mon lecteur de flux RSS et Instagram. Celui-ci est hébergé sur le cloud Google et la faible utilisation ne semble pas dépasser les paliers gratuits, ce qui n’est pas plus mal. RSSHub permet également de générer des RSS pour des comptes Twitter ou encore, pour des résultats de recherche leboncoin; la liste est plutôt bien fournie et semble aller en augmentant.

RSSHub est donc un programme que je trouve particulièrement intéressant pour ne plus dépendre d’un compte ou d’une application téléphone pour consommer du contenu. C’est un véritable gain sur bien des aspects, pour Instagram en tout cas, je note: pas de publicité dans le flux (sauf contenu sponsorisé d’un compte), possibilité de supprimer l’application, donc pas de tentation de l’utiliser pour passer le temps ou en cas d’ennui, pas de pistage (ou en tout cas, moins aisé). Au final, retour à un système qui me convient et que je maîtrise, où l’information arrive quand je l’ai décidé et sans essayer de me rendre accro.

Carnet 4 – Migration

J’ai migré hier soir unicoda.com vers un nouveau VPS, toujours chez OVH, dans leur centre de données de Strasbourg. J’ai réalisé l’installation complète à partir d’un script ansible qui réinstalle le site à partir de la sauvegarde quotidienne stockée dans le cloud et reconfigure automatiquement le processus de sauvegarde.

L’ancien serveur va continuer de fonctionner encore quelques jours, le temps de s’assurer que la propagation des DNS aura eu lieu pour la plupart des lecteurs. La sauvegarde est désormais désactivée sur ce serveur.

Au passage, j’en ai profité pour récupérer une sauvegarde locale du site sur mon poste. On est jamais trop prudent. Il restera à vérifier dans quelques semaines que le renouvellement du certificat aura été effectué correctement de manière automatique. Il n’y a priori pas de raison que cela ne fonctionne pas, mais étant donné que j’utilise désormais le client acme.sh à la place de certbot pour demander un certificat wildcard, des vérifications s’imposent.

Au passage, un petit tour du côté de la page SSL Server Test du SSL Labs, me gratifie d’un joli A+, qui témoigne du chemin parcouru depuis la première mise en place du HTTPS sur ces pages (B- ou C au début).

Au moment où j’écris ces lignes, c’est-à-dire quelques heures après l’opération de migration, je n’ai détecté aucun problème de configuration ou de fonctionnement. Toutefois, lecteurs attentifs, n’hésitez pas à me signaler tous dysfonctionnements que vous auriez remarqué.

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 »

[Note de service] Migration en cours (Nouvel environnement)

Unicoda est en train de migrer vers un environnement tout neuf. Si vous voyez cette note, c’est que vos DNS sont à jour et dirige vers la nouvelle version.

Les quelques tests effectués via la 4G sont plutôt positifs. Cela semble fonctionner correctement. Pas d’erreur dans les logs du nouvel environnement et déjà quelques logs d’accès.

Le reste des vérifications demain.