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.

[ArchLinux] Partage Samba

J’ai installé, il y a de cela plusieurs mois, un serveur miniDLNA sur l’une de mes machines équipée d’Arch Linux pour pouvoir partager facilement du contenu multimédia sur le réseau local. Jusqu’à présent, j’effectuais le transfert de fichier vers cette machine en branchant directement un disque dur sur la machine, en m’y connectant en SSH, en montant le disque puis en copiant les données à coup de commande cp. J’ai également effectué quelques transferts en montant un répertoire distant de la machine sur ma machine principale via sshfs. Ces deux solutions fonctionnent plutôt bien. Je me tourne aujourd’hui vers la mise en place d’un partage Samba, afin d’être en mesure de déposer facilement des fichiers depuis Windows également. Voici donc les quelques étapes nécessaires à la mise en place d’un répertoire accessible en lecture écriture sans restriction.

# Installation de Samba
sudo pacman -S samba
# Mise en place du fichier de configuration par défaut
cp /etc/samba/smb.conf.default /etc/samba/smb.conf
# Edition de la configuration
sudo nano /etc/samba/smb.conf

Pour le partage d’un répertoire, j’ajoute les lignes suivantes dans le fichier configuration :

[Media]
 path = /vers/le/répertoire
 public = no
 writable = yes
 printable = no

Avec cette configuration, le répertoire est bien disponible en lecture écriture et visible sous Windows. Pour configurer plus précisément l’ensemble, il faudra regarder les autres options disponibles. Dans mon cas, cette configuration me permet de faire ce que j’espérais. Suite de l’installation :

# Démarrage des services
sudo systemctl start smbd.service
sudo systemctl start nmbd.service
# Mise en place du service au démarrage
sudo systemctl enable smbd.service
sudo systemctl enable nmbd.service
# Ajout du user système dans Samba
# A vérifier si nécessaire
sudo smbpasswd -a <user>
# Vérifier la syntaxe de la configuration
testparm -s

En cas de modification de la configuration, ne pas oublier de redémarrer le service :

sudo systemctl restart smbd.service

 

Informations issues de l’excellent wiki Arch Linux pour la page concernant Samba.

Création simple avec Inkscape : Bannière

Voilà ce matin l’envie de faire une bannière propre pour Unicoda m’est venue. Et tant qu’à faire autant vous faire profiter de quelques trucs et astuces, c’est par là :

Si besoin, téléchargez Inkscape.

Ce que vous pouvez réaliser en 5 minutes

Logo Unicoda

  1. Ouvrez Inkscape, puis allez dans « Propriétés du document… »
    Propriétés
  2. Dans les propriétés du document, modifiez les paramètres de taille, ici pour les bannières WordPress de 2016 la taille est de 1200x280px (pixels)
    PropriétésDuDocument
  3. Vous pouvez en bas de l’onglet sélectionner un fond uni pour éviter d’avoir à créer un rectangle de la couleur désirée en fond. Pour cela cliquez sur le bandeau de la couleur de fond qui ouvrira le panel à gauche « Couleur de fond »
    CouleursFond
  4. Maintenant il vous faut ajouter votre texte, pour cela cliquez sur cette icône « A » puis paramétrez comme bon vous semble
    Ecrire
  5. Si le panel de paramétrage qui devrait se trouver sur la droite de la zone de dessin n’est pas ouvert vous pouvez l’ouvrir en cliquant sur le bouton « T » qui se trouve dans la barre latérale de droite
    Ouvrir les panels
  6. Pour redimensionner le texte facilement cliquez en mode sélection (F1) ou l’icône pointeur de souris au haut de la barre latérale de gauche, puis pour garder les bons rapports hauteur / largueur maintenez la touche contrôle et déplacer une des flèches se trouvant dans les coins de la sélection
    Redimensionnement
  7. Dans le panel de droite se trouve le bouton « Aligner et distribuer des objets » qui vous permet d’ouvrir l’onglet suivant. Cet onglet permettra d’aligner le texte « relativement à : » sélectionnez ici « Page » puis centrez le texte selon l’axe vertical et horizontal. Voilà votre texte est centré il ne vous reste plus qu’à enregistrer en svg et exporter en png « Fichier -> Exporter une image png… »
    Aligner
  8. Voilà c’est fini pour aujourd’hui ! J’espère que l’explication est assez détaillée.

Modifications de l’infrastructure de services

Qu’est-ce qui se cache derrière ce titre pas forcément pertinent ? Un point sur l’évolution des composants logiciels que j’utilise pour me passer des GAFAM (Google Apple FaceBook Amazon Microsoft). Quelques changements ont en effet eu lieu depuis mon précédent article.

Au revoir Owncloud… J’ai pris la décision d’abandonner Owncloud lors de la mise à jour vers la version 8.1.0. En quelques mots, à chaque mise à jour du logiciel, je me retrouvais à devoir réactiver plusieurs modules, supprimer des fichiers sur le disque ou finir une mise à jour via la ligne de commande. La dernière maj a mis en lumière des problèmes dans la gestion des clefs de chiffrements des fichiers, résultats: une majorité des fichiers est illisible. N’ayant pas de document à récupérer absolument, je ne me suis pas attardé sur les éventuelles procédures de récupération après un premier essai infructueux. Ce dernier problème achève donc de me convaincre d’aller regarder les autres solutions disponibles en matière de gestion de fichiers en ligne.

Je me tourne finalement vers Seafile. L’installation est bien documentée et ne pose pas de problème particulier. Dans les points positifs, je note la présence d’un client Android et d’une version serveur pour Raspberry Pi. Les fonctionnalités et l’interface de la version « Community » peuvent sembler austère, mais les éléments principals d’une telle solution sont présents et fonctionnent bien. A noter qu’il est possible de demander un passage en version pro gratuit si on se limite à 3 utilisateurs; à réfléchir. Seafile supporte également le chiffrement des fichiers, mais celui-ci s’effectue via le client; c’est un point que je dois encore tester.

Le passage de Owncloud à Seafile pour la gestion des fichiers a également posé la question du remplacement des autres modules Owncloud liés à la gestion des contacts, calendriers, flux rss et favoris. Pour moi, le rôle principal d’Owncloud réside dans la gestion de fichiers en ligne, les autres modules permettant d’enrichir la plateforme et de lui ajouter des fonctionnalités annexes. Je suis donc parti à la recherche de logiciels spécifiques permettant chacun de répondre aux besoins identifiés. Finalement, j’obtiens le découpage suivant:

  • Seafile: Pour la gestion et le partage de fichiers.
  • Selfoss: Pour la gestion des flux rss. Dispose d’une application Android dédiée.
  • Baïkal: Pour la gestion des contacts et du calendrier. (Interface web en construction dans la v2)
  • Shaarli: Pour sauvegarder simplement des urls depuis n’importe quel support.

Voilà pour la nouvelle forme de mon nuage de service. L’étape suivante concerne l’auto-hébergement progressif d’une partie des services, amenant avec elle son lot de défis.