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.

Changer de shell par défaut

Une commande bien utile et comme toujours en provenance du Wiki Arch Linux, à savoir: chsh.

Pour lister les shells installés :

chsh -l

Pour changer de shell :

chsh -S chemin-complet-vers-le-shell

chemin-complet-vers-le-shell correspond à l’un des chemins renvoyés par la commande précédente.

 

Et pour ceux qui s’interrogent, je passe de bash à zsh, advienne que pourra !

Let’s Encrypt. Enfin!

Cela fait pratiquement une éternité dans le monde de l’informatique que l’initiative Let’s Encrypt a été lancé. Je dois dire que si l’idée me plaisait beaucoup, au moment où les premières annonces avaient été faites, j’ai longtemps répugné à m’y mettre. Jusqu’à présent, j’utilisais StartSSL pour établir mes différents certificats. Avec quelques limitations bien sûr, un certificat par sous-domaine, génération d’une demande de certificat sur le serveur, transfert des infos vers StartSSL, récupération du certificat, transfert des fichiers sur le serveur et redémarrage d’Apache. De nombreuses opérations manuelles donc, mais une fois la procédure en place, c’est relativement rapide et les certificats ainsi générés sont valables un an. Pas de nécessité donc de mettre en place des certificats Let’s Encrypt, même si j’ai suivi les expérimentations des uns et des autres avec intérêt, et gardé en marque-page certains articles sur le sujet.

Tout allait bien dans le meilleur des mondes, jusqu’à la sortie de Firefox 51. En effet, à partir de cette version, Firefox (et Chrome aussi) arrête de faire confiance aux certificats signés par StartSSL après la date du 21 octobre 2016. Il se trouve, que deux de mes sous-domaines étaient concernés. Je me suis donc (re)plongé dans la documentation de certbot, pour découvrir l’outil et effectuer mes premiers tests.

L’ensemble a plutôt bien évolué par rapport à ce dont je me souvenais. Après plusieurs relectures et quelques tests, j’ai abouti à une procédure qui me convient. J’effectue donc la première demande de certificat manuellement, en conservant pour le moment l’isolation des sous-domaines qui m’avait été imposées par StartSSL. Je conserve ainsi une certaine liberté si je décide de migrer un service d’un serveur vers un autre. Je suis également arrivé à la configuration commune suivante, que je déploie à l’emplacement attendu par certbot, à savoir /etc/letsencrypt/cli.ini :

# Certbot Config

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

# Register with the specified e-mail address
email = <e-mail>

# Use the standalone authenticator on port 80
authenticator = standalone
preferred-challenges = http-01

De cette manière, la demande d’un nouveau certificat pour un domaine reste concise, il n’est plus nécessaire de renseigner tous les paramètres du fichier de configuration et on obtient donc par exemple :

certbot-auto certonly -d www.unicoda.com

Une fois le certificat généré, les lignes suivantes sont nécessaires du côté d’Apache :

SSLCertificateFile /etc/letsencrypt/live/<domaine>/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<domaine>/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/<domaine>/chain.pem

Redémarrage d’Apache que l’on avait arrêté le temps d’effectuer la procédure de demande de certificat et ça y est le navigateur affiche un fabuleux « Vérifié par : Let’s Encrypt ».

Du côté du renouvellement, je vais passer par la crontab pour qu’une vérification quotidienne des certificats soit effectuées. Le programme certbot s’occupant d’arrêter puis de redémarrer Apache :

certbot-auto renew --quiet --pre-hook "service apache2 stop" --post-hook "service apache2 start"

En théorie, le renouvellement automatique est donc en place, et le moment venu, les anciens certificats devraient être remplacés par des nouveaux sans que cela ne bouleverse (trop) le fonctionnement du site. Comme nous ne sommes jamais à l’abri d’une erreur de configuration malgré les nombreuses vérifications effectuées, et que je ne pourrais en être sûr qu’une fois les nouveaux certificats en place, je vous donne rendez-vous aux alentours du 26 mai 2017, date d’expiration du premier certificat Let’s Encrypt pour www.unicoda.com. Normalement, l’opération devrait être transparente pour tous, et je me réveillerais donc un matin (beau de préférence) avec un certificat tout neuf, sans avoir rien eu à faire.

Il ne reste plus qu’à patienter.