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

Mettre à jour des certificats sur une machine Windows non connectée

Il y a plusieurs semaines, j’ai rencontré un problème original dans mon travail quotidien. Ayant à effectuer des modifications sur du code en .NET servant d’intermédiaire entre deux composants, j’avais besoin de connaître les données en entrée et en sortie d’une partie du programme. Petite subtilité, avec l’interconnexion des composants, il me semblait plus aisé d’utiliser le débogage à distance du code.

Premier problème, les outils de débogage déjà installés sur la machine ne sont pas compatibles avec ma version de Visual Studio. Je me rends donc sur la page des téléchargements pour Visual Studio afin de récupérer l’exécutable « Remote Tools for Visual Studio 2015 Update 3 ». Celui est dissimulé dans le tableau en milieu de page, après avoir déplié la catégorie « Tools for Visual Studio 2015 », on accède au téléchargement des « Outils de contrôle à distance de Visual Studio 2015 Update 3 ».

Transfert de l’exécutable sur la machine serveur concernée, exécution. Après quelques minutes d’attentes, une erreur apparaît, les certificats présents sur la machine ne permettent pas de vérifier et valider l’installation. Je vérifie les paramètres réseau du serveur, pas de chance, connexion au réseau local seulement, pas de possibilité de mettre à jour les certificats via internet.

Après quelques recherches, je tombe sur cette procédure de la documentation Microsoft, et pour une fois, celle-ci me semble plutôt complète. L’idée : récupérer les certificats de mon poste de développement et les importer sur la machine serveur. Voici la procédure que j’ai suivie (extrait de la doc).

Dans une console en mode administrateur :

Certutil -generateSSTFromWU WURoots.sst
start explorer.exe wuroots.sst

Le gestionnaire de certificats de la machine s’ouvre.

  • Dans le volet de navigation du gestionnaire, développer le chemin d’accès au fichier sous Certificats – Utilisateur actuel jusqu’à ce que Certificats s’affiche, puis cliquer sur Certificats.
  • Dans le volet d’informations, les certificats de confiance s’affichent. Maintenir la touche CTRL enfoncée et cliquer sur chacun des certificats à autoriser. Une fois la sélection des certificats à autoriser terminée, clic droit sur l’un des certificats sélectionnés, cliquer sur Toutes les tâches, puis sur Exporter.
  • Dans l’Assistant Exportation du certificat, cliquer sur Suivant.
  • Dans la page Format du fichier d’exportation, sélectionner Magasin de certificats sérialisés Microsoft (.SST), puis cliquer sur Suivant.
  • Dans la page Fichier à exporter, entrer un chemin d’accès au fichier et un nom approprié pour le fichier, par exemple C:\AllowedCerts.sst, puis cliquer sur Suivant. Cliquer sur Terminer. Cliquez sur OK après avoir été informé de la réussite de l’exportation.

Après avoir transféré notre fichier AllowedCerts.sst sur la machine cible, on peut s’intéresser à l’import des certificats.

Pour cela, il est nécessaire de se rendre dans le « Panneau de configuration » de la machine, puis « Option internet » et aller à l’onglet « Contenu » dans la fenêtre qui s’affiche. Enfin, cliquer sur le bouton « Certificats ».

Dans la fenêtre « Certificats » :

  • Cliquer sur le bouton « Importer ».
  • Choisir le fichier en modifiant la liste d’affichage par type de fichier vers .sst.
  • Choisir la sélection automatique du magasin de certificat selon le type de certificat.
  • Cliquer sur « Terminer ».
  • Valider (Oui) pour chaque certificat.

Pour finir, relancer l’installation des outils de contrôle à distance. Si les certificats de la première machine était bien à jour, l’installation devrait s’effectuer correctement. Il est toutefois dommage que le ou les certificats manquants à l’installeur ne soient pas clairement désignés, cela nous aurait permis de ne sélectionner que les certificats nécessaires et non d’intégrer sans distinction tous les certificats présents sur la machine source.

 

[Arch Linux] Miniature dans l’explorateur

J’utilise PCManFM comme explorateur de fichiers visuel. La semaine dernière, je me suis intéressé à l’affichage des miniatures dans l’explorateur, élément cosmétique manquant jusqu’à présent. Pour les images, c’est très simple, il suffit d’installer tumbler.

pacman -S tumbler

Du coup, j’en ai profiter pour ajouter la même chose pour les vidéos avec ffmpegthumbnailer.

pacman -S ffmpegthumbnailer

Ce n’est pas grand chose, mais ça apporte un peu de diversité dans l’affichage des dossiers d’images et de vidéos.

Source : Wiki ArchLinux