Comme lecteur de flux RSS, j'utilise Tiny Tiny RSS (tt-rss). Je l'héberge sur ce serveur, à côté de ce shaarli. (Avant tt-rss, j'ai utilisé KrISS feed.)

Qu'est-ce qui justifie de le virer ?

• Il y a quelques mois, j'ai transformé mon Wordpress en site statique puisque je ne l'utilise plus. Désormais, le seul utilisateur du SGBD MariaDB est tt-rss. Ce n'est pas optimal (service supplémentaire à maintenir, pour environ aucun intérêt).
  
  
• Il y a treize ans, j'ai choisi un agrégateur RSS de type web, car, d'une part, je voulais y accéder depuis n'importe où, et, d'autre part, je ne voulais rien manquer, y compris des tweets (via RSS-Bridge), donc il fallait récupérer très fréquemment les flux, même quand j'étais AFK. Depuis plus d'un an et demi, je me désintoxique des journaux, des flux RSS, et des listes de discussion (ça fait un bien fou !). Du coup, je n'ai plus ces besoins, cette temporalité. Je tends à lire mes RSS, comme mes courriels, durant des créneaux dédiés, donc je peux très bien utiliser un client lourd.
  
  
• Quand j'ai débuté cette réflexion, le développeur de tt-rss avait déclaré ne plus maintenir son logiciel. Le risque de sécurité était minime puisque mon serveur web autorise l'accès à mon instance tt-rss uniquement à des adresses IP précises, mais ça signifie aussi qu'il faudrait envisager de migrer à terme (dysfonctionnement, sécurité mine de rien, etc.). Aujourd'hui, l'un des contributeurs principaux assure la continuité du développement, donc ce point n'est plus un problème.

Fonctionnalités désirées du remplaçant :

• Client lourd GNU/Linux (= un logiciel dédié, pas un site web) ;
  
  
• Licence libre ;
  
  
• Empaqueté dans Debian stable ;
  
  
• Marquer un article pour y revenir plus tard et empêcher sa purge par l'écoulement du temps ;
  
  
• Recherche globale et par flux ;
  
  
• Purge auto des vieux articles ;
  
  
• Annoter un article ;
  
  
• Gérer au mieux les emmerdes usuelles des flux RSS : encodage des caractères, gestion des erreurs (HTTP 404, insertion de HTML en plein milieu, etc.), maintenir l'état « lu » d'un article modifié, gestion d'un attribut « guid » sous forme d'URL erronée, etc. J'évalue ce critère à la cool puisque même ttrss échoue sur la plupart de ces éléments, qui, de surcroît, ne sont pas forcément visibles immédiatement.

Pour identifier un remplaçant, j'ai utilisé les inventaires de Wikipedia FR et de Wikipedia EN. Je n'ai pas retenu les logiciels audio / dédiés aux podcasts.

Akregator et Alligator : très nombreuses dépendances à KDE alors que j'utilise MATE, donc je ne les ai même pas installé.

Liferea : l'affichage en trois volets, qui ne peut être changé, ne me convient pas. Recherche globale uniquement. Pas d'annotation.

Newsboat : extrêmement rustique (lecteur en ligne de commande). Aucune mise en forme CSS, et les liens hypertextes rangés à la fin d'un article. Pas de marquage ni d'annotation.

Une extension Firefox (fut un temps, j'utilisais NewsFox) : absence de pérennité (ça va péter au premier changement un peu majeur de Firefox). Embolie du profil. Les premières extensions triées par popularité ne sont pas sous licence libres ou ne proposent pas les fonctionnalités désirées.

Thunderbird : je l'utilise déjà pour mes courriels et je veux dissocier RSS et courriels (= ne pas m'interrompre dans l'une ou l'autre de ces activités distinctes).

RSS Guard : mon coup de cœur ❤️. Icône dans la zone de notification + minimisation. Recherche par flux et globale. Marquage (empêche-t-elle la purge d'un article obsolète ?). Pas d'annotation. Des filtres JavaScript permettant de réparer les merdes habituelles dans les flux (encodage, URL, etc.). Adblock (⚠️ plus à partir de la version 5). Blocage par type de contenus. Ce logiciel m'a beaucoup plu, je le recommande.

RSS Guard est si parfait qu'il m'a rappelé l'inconvénient majeur d'un client lourd : il s'agit d'un navigateur web entier, donc il faut gérer la problématique du flicage. Or, j'ai la flemme, d'autant que le bloqueur disparaît dans les versions récentes.

Du coup, j'ai commencé à me souvenir de l'avantage d'un lecteur RSS de type web : c'est mon uBlock Origin standard qui veille sur mon tt-rss.

Sur mon poste de travail, j'ai déjà un serveur web pour des tests, mon gestionnaire des choses à faire, Vikunja, et l'inventaire de mon matos informatique, GLPI. Ce dernier utilise PHP et MariaDB, et je n'en pas l'intention de le virer, même à moyen/long terme.

Dès lors, héberger mon tt-rss sur mon poste de travail paraît opportun : aucun changement de lecteur RSS, mais je peux virer un SGBD inutile sur un serveur de production.

Reste un dernier souci. J'utilise le suspend-to-ram, l'un des modes de mise en veille prolongée. Je recours à un VPN OpenVPN pour avoir un accès à Internet via un FAI associatif et à un serveur DNS récursif local Unbound pour éviter la censure et pratiquer la validation DNSSEC.

À la sortie de veille, OpenVPN met parfois du temps à détecter que la connexion est hors service. Pareillement, Unbound prend parfois son temps pour détecter le retour de la connectivité à Internet via le VPN.

Conséquence : si le butineur de tt-rss passe dans l'intervalle, et c'est systématiquement le cas, l'ensemble des flux RSS sont en erreur. C'est fâcheux pour les flux que je récupère uniquement toutes les heures ou toutes les quatre heures (afin d'éviter un bannissement par IP).

J'ai pensé à redémarrer tout ce monde dans un script /lib/systemd/system-sleep/. Documentation ici.

L'ennui, c'est que NetworkManager (NM) va aussi redémarrer la connexion filaire, et donc interrompre le VPN, et donc générer le problème. C'est donc à NM de redémarrer OpenVPN, Unbound, et tt-rss. Mon script /etc/NetworkManager/dispatcher.d/restartovpnubndttrss pour ce faire :

#!/bin/bash

IFACE="$1"
EVENT="$2"

if [[ "$IFACE" == "enp0s25" ]]; then
  if [[ "$EVENT" == "up" ]]; then
    systemctl restart openvpn-client@<CENSURE>.service

    sleep 5

    systemctl restart unbound.service

    sleep 5

    systemctl restart ttrss.service
  fi
fi