L'Agenda du Libre

On nous demande souvent comment participer financièrement, c’est maintenant possible via notre compte Liberapay.

Cette plate-forme permet de faire des dons récurrents «aux personnes dont vous appréciez le travail». Vous trouverez un peu plus de détails sur cette page.

Ce n’est pas parfait, puisque même si Liberapay est open source, le traitement des paiements est effectué via Paypal.

Nous venons d’ajouter un nouveau service, Nitter, disponible depuis l’adresse nitter.allella.fr.
Mais nitter, c’est quoi?

Nitter est une alternative libre au frontal (“site web”) de Twitter. Nitter vous propose de suivre vos comptes Twitter préférés sans le pistage ni la publicité de Twitter, en optimisant ainsi la vitesse de navigation. Il vous est ainsi possible de profiter de l’expérience de Twitter en passant par notre serveur, sans vous connecter directement à Twitter.

Dans le futur, le service devrait évoluer avec la gestion de compte, ce qui vous permettra d’avoir une timeline comme Twitter mais toujours sans compte Twitter.

Chez Allella, le service est déployé dans un container Docker.

Code source du projet: https://github.com/zedeus/nitter

Image Docker: https://hub.docker.com/r/zedeus/nitter

Si vous souhaitez participer à l’entretien du service, vous pouvez contribuer de manière libre et consciente, hum… c’est à dire?

Vous désirez contribuer financièrement, mais vous n’avez aucune idée de la somme à verser? Pour vous aiguiller un peu, il y a 2 éléments principaux à prendre en considération:

• les frais fixes
• le temps passé

Les frais fixes

• Location du serveur: 38,39€ TTC / mois
• Le nom de domaine allella.fr: 0,70€ / mois
• Alimentation électrique du serveur de sauvegarde: 1 euro / mois

Le temps passé

Entre la veille, l’application des mises à jour des services, l’alimentation du site web ainsi que les tests & diverses améliorations – nous y passons en moyenne 2h chacun par semaine, soit un total à nous deux d’une bonne quinzaine d’heures par mois.

Nous retrouvant pleinement dans les valeurs promues par le collectif CHATONS, nous avons décider d’ouvrir un peu plus nos services et de candidater à la prochaine portée, onzième du nom.

CHATONS est le Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires. Ce collectif vise à rassembler des structures proposant des services en ligne libres, éthiques et décentralisés afin de permettre aux utilisateur⋅ices de trouver rapidement des alternatives respectueuses de leurs données et de leur vie privée aux services proposés par les GAFAM (Google, Apple, Facebook, Amazon, Microsoft). CHATONS est un collectif initié par l’association Framasoft en 2016 suite au succès de sa campagne Dégooglisons Internet.

Même si notre candidature n’est pas retenue, elle a au moins le mérite de nous amener à tendre vers des services de meilleure qualité. Nous pensions initialement bien faire les choses, mais force est de constater qu’à la lecture des différents points de cette liste de conformité nous pouvions faire encore mieux. En rentrant dans le cadre défini par cette charte, nous nous assurons de proposer des services fiables, sécurisés, ouverts, neutres & transparents.

La candidature est lancée, à suivre …

Quand on met à disposition des services sur un serveur, une des autres étapes importantes c’est la sauvegarde; souvent un point oublié mais qu’on regrette le jour d’un crash serveur!

Chez Allella, chaque service est sauvegardé localement puis poussé toutes les nuits vers un serveur de stockage externe hébergé directement chez Julien (merci la fibre!). Nous n’avons pas cependant des terras de stockage, la rétention est donc assez faible (1j concernant le service de stockage des fichierss, 60j pour la sauvegardes des emails, des configurations serveur ou encore des sites hébergés).

Le serveur est un mini-pc basse consommation afin de limiter l’impact de la sauvegarde sur la planète. Petite particularité pour externaliser la sauvegarde, nous nous servons d’un bon vieux Wake-on-LAN afin de “réveiller” le serveur chez Julien. Celui-ci s’éteint une fois la sauvegarde synchronisée (~15min).

L’ensemble des scripts de sauvegarde utilisés sont disponibles en public sur notre forge.

Parce que c’est toujours mieux de pouvoir adapter l’apparence d’un service selon son identité graphique, on regarde ici comment procéder sur une instance Gitea Dockerisée. Pour ceux qui souhaiteraient en faire de même sur une instance classique, cette documentation devrait suffire.

Contexte

Nous prenons ici à titre d’exemple un container Docker Gitea dont le mappage des ports et le volume à utiliser pour la persistance des données sont définis, est lancé comme suit:

Création et éditions des fichiers de surcharge

Il est nécessaire de créer 2 arborescences afin d’y stocker les modifications CSS d’une part, et de template d’autre part.

Surcharge CSS

1. On ajoute nos règles CSS dans public/css/custom.css:

1. On inclut la nouvelle CSS dans le template de header templates/custom/header.tmpl:

Surchage de template

Prenons l’exemple de la page d’accueil:

1. Récupération du template de la distribution Gitea de base dans templates/home.tmpl:

1. Modification du template:

Afin de mieux comprendre l’organisation des fichiers de template de Gitea, c’est par ici.

Redémarrage du container

Un redémarrage est nécessaire pour la prise en compte des modifications apportées:

Je n’avais pas eu pris le temps de mettre en place les configurations nécessaires permettant aux différents clients de messagerie (bureau / mobile) de récupérer automatiquement l’adresse du serveur, les ports, les protocoles, …

Ca marche comment?

Lorsqu’on souhaite lire ses emails ailleurs que sur son navigateur Internet, on ouvre son client de messagerie préféré et on suit les différentes étapes; il y a alors 2 solutions, soit le client arrive à “récupérer” la configuration liée au domaine de messagerie, soit vous êtes obligé de le faire manuellement ..

L’idée est bien de se faciliter la vie:) Mais comme tout n’est pas simple, chaque client utilise un des mécanismes suivants:

• une base de données ISPB gérée par Mozilla;
• deux fichiers de configuration mis à disposition en HTTPs;
• des entrées DNS sur la zone du domaine;
• la devinette, le client essaye de combiner smtp ou imap avec le nom de domaine de votre messagerie;

On met quoi en place?

Du coup pour pouvoir répondre aux demandes de tous les clients de messagerie, on va commencer par rajouter les entrées DNS suivantes:

On met à disposition aussi les fichiers de configuration en se basant sur cette proposition. On clone le repo dans un répertoire local sur le serveur, on adapte les fichiers pour sa configuration et on inclut ce bloc pour chaque domaine.

Et voilà, une fois l’adresse ajoutée, Thunderbird trouve tout seul sa configuration:

Quand on met à disposition des services sur un serveur, une des étapes importantes c’est la sécurité; ça passe par plusieurs points:

• un serveur stable et à jour: on a fait le choix d’utiliser un système d’exploitation Linux, en l’occurrence Debian Buster (10), en appliquant régulièrement les mises-à-jour proposées
• un système anti-ddos: OVH fait le taff pour nous:)
• un système anti-bruteforce: fail2ban est notre ami pour plusieurs services internes (SSH, postfix, …)
• une réflexion sur chaque service interne: installation depuis un paquet Debian, via Docker ou via les sources? exposition sur Internet? communications internes sécurisées?
• de la veille régulière

On utilise aussi des outils externes qui fonctionnent comme des mini-audits comme par exemple Observatory de Mozilla.

«Tout est design», ou encore «L’art est ce qui rend la vie plus intéressante que l’art». Deux maximes souvent prononcées par notre ami Cdrc Lchrz que nous souhaitons grandement remercier pour la création du logotype d’Allella.

La description du projet autour d’une bière en terrasse en compagnie de cet adepte du «nécessaire et suffisant», et quelques secondes plus tard…le logo était né!

Dans la jungle des outils de gestion de blog, nous avons opté pour Jekyll. C’est un générateur de site web statique. L’intérêt d’un tel outil est multiple:

• c’est léger: pas de base données à gérer;
• c’est sécurisé: pas de base données à gérer, on ne fait que lire et renvoyer des documents texte;
• c’est simple / logique / écologique: pourquoi regénérer une page à chaque fois que celle-ci est consultée si son contenu reste inchangé?
• la documentation est aux petits oignons, et même sans connaître ni Ruby ni le langage de templating Liquid, la prise en main est très rapide.

Mise à jour du site

Pour le moment, le contenu généré grâce à la commande de build disponible est ensuite poussé sur notre serveur web avec un bon vieux scp -r.

Un jour bientôt nous ferons de l’intégration continue avec notre dépôt GitLab Gitea, l’occasion de faire un nouveau billet!