pass comme gestionnaire de mot de passe

Cela fait maintenant plusieurs années que j’utilise un gestionnaire de mot de passe pour retenir à ma place les informations d’accès aux différents services que j’utilise. J’avais jusqu’à présent choisi d’utiliser Keepass, en particulier pour ces fonctions de synchroniser via WebDAV et l’existence de ses nombreuses variantes qui permettent une utilisation sur GNU/Linux, Windows, Mac et Android sans trop de difficultés. Très récemment, j’ai décidé de changer de gestionnaire et de tester pass.

Quelques mots sur pass. Le programme de base prend la forme d’une simple ligne de commande. Chaque entrée consiste en un fichier dont la première ligne contient le mot de passe. On peut ensuite stocker diverses informations sur les lignes suivantes, comme url, username, clés d’API, etc. Tous les fichiers sont chiffrés par clé gpg. Lorsqu’on accède à l’un des fichiers de mot de passe, seul ce fichier sera déchiffré et non l’ensemble de la base comme c’est en général le cas avec les autres gestionnaires. La synchronisation est assurée par git, ce qui permet de bénéficier de l’historique du dépôt qui constituera notre base de référence de mot de passe.

Continuer la lecture de « pass comme gestionnaire de mot de passe »

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

Création d’un accès à l’API OVH

Afin de pouvoir générer un certificat wildcard via Let’s Encrypt pour un domaine géré par OVH, il est nécessaire de créer un accès à l’API OVH sur la page de création de token.

Les autorisations à accorder sont les suivantes:

GET /domain/zone/*
PUT /domain/zone/*
POST /domain/zone/*
DELETE /domain/zone/*

Une fois l’ensemble des informations renseignées et validées, la page nous génère les clés d’API que l’on prendra soin d’enregistrer dans son gestionnaire de mot de passe favori.

S’il doit être possible de lister les accès accordés et de les gérer quelque part dans les interfaces d’administration OVH, je n’ai pour l’instant pas trouvé une telle page (mais je n’ai pas non plus pris le temps d’aller à sa recherche).

Restauration d’un dossier à partir de la sauvegarde avec duplicity

Pour une raison obscure, ma dernière tentative de mise à jour de Nextcloud a échoué et laissé le contenu du dossier dans un état instable. J’ai donc récupéré la dernière version stable depuis la sauvegarde de la veille.

sudo pip install --upgrade b2
sudo duplicity restore --force --file-to-restore path/to/nextcloud -t now b2://[applicationKeyId]:[application key]@[B2 bucket name] /path/to/nextcloud

Carnet 3 – Câblage

La semaine dernière, je faisais un point rapide sur l’état du câblage de l’appartement que j’occupe, qui bien que devant à priori suivre les normes récentes en matière de connexion rj45, ne disposait que de connecteurs câblés à moitié, c’est-à-dire, pour un mode de fonctionnement que je qualifierais de « mode téléphone rj11 ».

Après avoir parcouru quelques sites expliquant les normes de câblage, l’alternance des fils à suivre et les différentes catégories de câbles existantes, je me suis donc attelé à modifier le câblage des six connecteurs présents dans l’appartement. J’aurais pu me limiter aux deux connecteurs nécessaires pour permettre la connexion de la box, mais j’ai préféré commencer par les autres connecteurs pour m’entraîner. Au final, rien de bien compliqué. Après avoir déterminé l’alternance des fils dans la norme IBCS, il ne reste plus qu’à démonter chaque prise et chaque boîtier, récupérer les brins qui composent le câbles, les séparer et les ordonner dans le connecteur dans le bon ordre. La plus grande difficulté rencontrée fut la récupération des brins non connectés à presque dix centimètres dans le mur au niveau de l’une des prises.

Dans l’idéal, il eût été préférable que les câbles en place dans les murs soient de « vrais » câbles modernes de catégorie 5e ou plus et suivant la norme EIA/TIA 568B. J’ai envisagé un instant de tirer un nouveau câble de catégorie 5e en remplacement du câble existant pour la liaison ONT <-> box, pour finalement décider de conserver l’existant, au moins dans un premier temps. Un changement de câble pouvant toujours être effectué par la suite, si je constate que le câble en place limite fortement le débit; ce qui ne semble pas être le cas (en tout cas, si limitation il y a, cela reste plus rapide que la connexion précédente par ADSL).

Une fois le recâblage des connecteurs effectués, je me suis tourné vers le remplacement de la livebox par mon propre routeur en suivant les informations publiées par d’autres utilisateurs. J’ai été agréablement surpris d’y arriver en l’espace d’une petite trentaine de minutes et j’en ai donc profité pour configurer un DNS dynamique et m’assurer de la continuité de l’accès à mes services auto-hébergés. Par la suite, j’ai testé l’établissement d’une connexion VPN vers mon LAN: le gain de débit de la connexion fibre est clairement perceptible.

Maintenant que la continuité de mon accès internet est garanti, je vais me concentrer sur la migration d’unicoda.com vers un nouveau serveur, ce qui me permettra de vérifier mon script de ré-installation à partir de la sauvegarde. J’essayerai également de documenter les modifications de configuration effectuées sur le routeur pour remplacer la livebox, pour ensuite retourner vers le sujet de la sauvegarde des données et effectuer quelques tests de la solution cloud archive d’ovh.