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.

Nextcloud est un logiciel qui permet de partager des photos et des fichiers, mais aussi de gérer un calendrier et des contacts, et même de communiquer en visioconférence.

C'est un logiciel libre accessible depuis un navigateur, et depuis un téléphone ou un ordinateur via des applications dédiées.

Nextcloud sur Ezvan.fr

J'ai configuré une instance de Nextcloud accessible sur Ezvan.fr. Pour s'y connecter depuis l'application il suffit de renseigner l'adresse https://www.ezvan.fr/nextcloud.

Photos de famille

J'ai transféré l'album photo de famille qui était auparavant sur Dropbox vers Nextcloud. Cela permet à chacun d'ajouter des photos à l'album facilement depuis le navigateur ou l'application.

Comment s'en servir ?

Commence par te connecter ! Puis télécharge l'application pour synchroniser des photos depuis ton ordinateur.

Pour plus d'info tu peux consulter la documentation (en anglais) ou ce wiki en Français qui décrivent son utilisation.

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 !

J'ai configuré une solution de gestion de calendrier et contacts sur Ezvan.fr afin de ne pas avoir à exposer ces informations à Google. J'ai utilisé pour cela le logiciel Davical qui permet de stocker un calendrier à l'aide du format CalDAV. J'ai choisi cette solution car c'est le protocole que j'ai trouvé le mieux supporté, en effet je peux l'utiliser avec mon client de messagerie Thunderbird, sous Android avec des applications supplémentaires et même avec un Iphone. Ce logiciel permet aussi de stocker des contacts au format CardDAV.

Il est possible d'accéder au calendrier dans son navigateur en allant à la page agenda.

Pour l'utiliser sur mon téléphone Android, j'utilise l'application CalDAV-Sync. Il suffit de configurer cal.ezvan.fr comme serveur, et utiliser mes identifiants de courriel et le tour est joué !

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 …