Le vieux certificat SSL fournit par Gandi pour www.ezvan.fr a expiré sans crier gare ! Je n’ai pas accès au compte qui gère le domaine, me voilà donc en train d’essayer de créer un certificat avec Let's Encrypt.
Let's Encrypt est une autorité de certification qui fournit des certificats SSL gratuits, donc plus aucune excuse pour ne pas utiliser SSL correctement !

La validation du certificat est faite automatiquement, à l’aide d’un outil nommé cerbot. Il génère un fichier “ACME challenge” qui doit être accessible via le domaine validé.

Dans mon cas j’utilise la commande suivante. Je spécifie le chemin d’installation de Drupal (qui fait tourner ce site) et demande à cerbot de configurer Apache pour utiliser le nouveau certificat.

% sudo certbot --authenticator webroot --installer apache --webroot -w /usr/share/drupal7 -d www.ezvan.fr

Malheureusement tout ne se passe pas comme prévu !

 - The following errors were reported by the server:   
 Domain: www.ezvan.fr   
 Type:   unauthorized   
 Detail: Invalid response from 
   http://www.ezvan.fr/.well-known/acme-challenge/UWXvHv0ueIHLLooJIcIfdD2OiuNipVF5TuSc0dXnXd0:   
   "      403 Forbidden      Forbidden"

Que se passe-t-il ? Drupal interdit l’accès direct aux fichiers placés dans son arborescence pour des raisons de sécurité. L’emplacement du fichier …

Depuis quelques jours la fonctionnalité de téléversement automatique de Nextcloud qui me permet d’envoyer automatiquement mes photos depuis mon téléphone Android échouait sans cesse avec une erreur:

Impossible de réaliser l’opération: le serveur n’est pas accessible

Cette erreur est un peu étrange car le reste de l’application fonctionne parfaitement. En fait elle est causée par un bogue dans la version 3.0.2 du client Android qui ne crée pas automatiquement de nouveau dossier pour le mois en cours quand vous choisissez de classer les photos par mois.

Pour résoudre temporairement ce problème il suffit de créer le dossier pour le mois en cours (nommé 03 pour mars) dans le répertoire d’envoi via l’interface web. Vous pouvez trouver plus d’information sur le problème dans le ticket Github correspondant.

Ce week-end j'ai configuré IPv6 sur mon infrastructure EC2 qui tourne sous Debian 9. J'ai suivi le guide fourni par AWS, mais j'ai rencontré quelques soucis, et ce guide n'a pas d'instructions pour Debian. Je vous conseille fortement de réaliser ces changements d'abord sur des instances de tests, car mes premiers essais ont rendus mes instances totalement injoignables, heureusement que ce n'étaient pas celles de prod !

Au début j'ai simplement configuré /etc/network/interfaces de la façon suivante afin d'utiliser dhcp pour IPv6:

% cat /etc/network/interfaces# 
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 dhcp

Mais après un redémarrage mon instance de test n'arrivait pas à configurer le réseau, et était donc injoignable et inutilisable. Après quelques tests, j'ai réalisé que le problème venait du cient DHCP installé, qui était dhcpcd. Apparemment le paquet installé sur mon système était une relique de Debian 7, car il n'est pas disponible pour les versions ultérieures ! Je l'ai donc remplacé par isc-dhcp-client.

% sudo apt install isc-dhcp-client isc-dhcp-common
% sudo apt remove dhcpcd

Après un redémarrage, tout fonctionne, mon instance obtient son adresse IPv6 !

Dans mon précédent billet j'avais pensé avoir réglé mon problème, le démon BOINC laissant toutes les ressources processeur libres en cas de besoin.

Pour cela j'avais configuré systemd pour allouer une priorité faible au cgroup contenant les processus de calculs BOINC:
sudo systemctl set-property boinc.service CPUWeight=1

Comme noté dans les commentaires, cet attribut n'est pas disponible dans les versions de systemd antérieures à 231, où il remplace l'attribut CPUShares.

L'équivalent pour ces versions est: systemctl set-property boinc.service CPUShares=2

Ce changement reflète une modification de l'interface cgroups du noyau, où l'attribut cpu.shares est remplacé par cpu.weight. Or cette modification n'a pas encore été intégrée dans la branche principale, ce qui conduit systemd à convertir la valeur de CPUWeight à son équivalent cpu.shares sur mon système.

Pourtant j'ai remarqué que la lecture de vidéos n'était pas fluide sur mon système. En renouvelant l'expérience précédemment décrite les résultats montraient que BOINC ne laissait pas libres toutes les ressources du processeur.

Après avoir lu quelque documentation comme la page de manuel de systemd sur la gestion des ressources et la documentation du noyau sur les cgroups, j'ai pu comprendre d'où venait le problème.

Les cgroups sont organisés …

Je me suis récemment remis à faire tourner BOINC sur ma machine. BOINC est un logiciel de calcul scentifique distributé. En utilisant BOINC je prête en quelque sorte la capacité de calcul de mon ordinateur à des projets de recherche scientifique.

Le principe de BOINC est de n'utiliser que les ressources libres de la machine. Il fait de la sorte en attribution une priorité minimale aux processus qui réalisent le calcul. Sous Linux c'est fait en attribuant la valeur nice maximale aux processus lancés par BOINC, qui est 19. Plus la valeur nice est élevée, moins le processus est prioritaire.

Cette valeur 19 correspond à une priorité idle, ce qui signifie qu'elle ne permet d'utiliser que le temps restant qui n'est réclamé par aucun processus plus prioritaire. Cela correspond en pratique à n'utiliser que les ressources laissées libres sur la machine.

Cette configuration a fonctionné pendant longtemps sous Linux. Or j'ai remarqué que sur mon système BOINC ne semblait pas laisser toutes les ressources libres, car certains de mes programmes étaient plus long à s’exécuter, et donc mon ordinateur avait l'air plus lent. J'ai donc voulu vérifier cela. Un moyen simple est d'essayer d'utiliser au maximum le processeur, et …