Nixos on Nicolas Guilloux

Certification locale

Thu, 21 Jul 2022 00:00:00 +0000

La certification locale est très utile majoritairement pour du développement local. Il s’agit de fournir un certificat pour chaque domaine hébergé sur la machine, et que la fameuse page vous disant que le site est dangereux disparaisse.

Comment fonctionne un certificat

Tout d’abord, un certificat sert à garantir l’authenticité d’un site par l’intermédiaire d’une autorité de confiance abrégée CA pour Certification Authority. Je vais faire un exemple.

Je souhaite certifier que le site blog.nicolasguilloux.eu est à moi auprès d’un CA (par exemple Let’s Encrypt). Il va alors se passer plusieurs choses successivement :

Je crée un couple de clé privée et clé publique.
Je demande au CA de me donner un challenge pour qu’il vérifie que je contrôle bien l’adresse en question
Généralement, c’est un texte que l’on doit fournir à une URL précise (par exemple mettre le texte ed98 dans l’URL https://blog.nicolasguilloux.eu/8303) et de le signer avec ma clé privée.
Le CA vérifie alors que le challenge est OK en déchiffrant le contenu de ladite page avec la clé publique qu’on lui fournit.
Le CA enregistre alors cette clé publique et la fournit à qui veut vérifier la certification du site blog.nicolasguilloux.eu

Ainsi, une personne lambda qui accède au site demande la clé publique au CA et vérifie le certificat fourni par le site avec chaque requête HTTPS avec celle-ci pour vérifier que je suis bien le propriétaire du site.

Pour plus d’information, vous pouvez consulter la documentation de Let’s Encrypt. L’image précédente est d’ailleurs tirée de cette page.

Notre certification custom

Quand on demande une page https sans fournir de certificat, notre navigateur nous met en garde que ce n’est pas sécurisé, car il ne peut pas vérifier la source des informations données. On va donc y remédier en créant un certificat par nous même, et en disant au système que l’autorité de confiance que nous avons créée est justement de confiance.

On remarque qu’on ne s’occupera pas de la partie challenge, qui est uniquement là pour que le CA nous croit notre légitimité. Ici, on est légitime, on détient le système. Et le CA, c’est nous, on fait ce qu’on veut !

On va créer une dérivation qui va générer les certificats grâce à la liste des domaines qu’on lui aura fournis ainsi que l’éventuelle autorité de certification qu’on lui aura donné.

{ stdenv
, mkcert
, domains ? [ "local" "*.local" ]
, authority ? null
}:

let
 domainsToString = builtins.concatStringsSep " " (
 builtins.map (domain: "\"${domain}\"") domains
 );
in
stdenv.mkDerivation rec {
 name = "local-certificates";
 dontUnpack = true;

 installPhase = ''
 # Create the directories
 mkdir -p $out/ssl/authority;
 '' +
 if authority != null then
 "cp ${authority} $out/ssl/authority/rootCA.pem"
 else
 ""
 + ''
 # Generate the certificates
 CAROOT="$out/ssl/authority" \
 ${mkcert}/bin/mkcert \
 -cert-file $out/ssl/local-cert.pem \
 -key-file $out/ssl/local-key.pem \
 ${domainsToString}
 '';
}

L’intégration dans le système

Regardons maintenant son intégration dans la configuration générale de NixOS.

{ config, lib, pkgs, ... }:

let
 localCerts = pkgs.callPackage ./local-certs.nix {
 domains = config.networking.hosts."127.0.0.1";
 # authority = ./rootCA.pem;
 };
in
{
 # Add certificates systemwide
 security.pki.certificateFiles = [
 (localCerts + "/ssl/authority/rootCA.pem")
 ];

 # Add local certificates
 services.traefik.dynamicConfigOptions.tls = {
 certificates = [
 {
 certFile = "${localCerts}/ssl/local-cert.pem";
 keyFile = "${localCerts}/ssl/local-key.pem";
 }
 ];

 stores.default.defaultCertificate = {
 certFile = "${localCerts}/ssl/local-cert.pem";
 keyFile = "${localCerts}/ssl/local-key.pem";
 };
 };
}

On peut déjà constater que je build la dérivation précédemment mentionnée afin de pouvoir l’exploiter ensuite. Comme domaine, je donne tous ceux qui renvoient vers mon localhost. Je brasse large, mais c’est plus simple ainsi.

On remarque aussi que j’ai commenté le authority. Si vous avez déjà créé l’autorité, vous pouvez l’utiliser sinon une sera créée pour vous. Cependant, cela peut poser problème si vous ne redémarrez pas entièrement votre système. En effet, si par exemple vous lancez Chrome, celui-ci récupèrera les autorités de votre système lors du démarrage. Ainsi, si les certificats locaux sont reconstruits, l’autorité aussi et Chrome n’aura pas la nouvelle autorité tout juste créée, du moins jusqu’à son prochain redémarrage.

On remarque donc qu’on ajoute le rootCA.pem dans les autorités du système. Ainsi, le système croira tous les certificats émis par cette autorité, c’est-à-dire la nôtre.

En prime, j’ai ajouté une configuration pour dire à Traefik d’associer le certificat généré par défaut. C’est un exemple et certaines personnes pourraient vouloir l’implémenter autrement.

Et voilà !

Vous avez dorénavant une certification locale qui se régénère dès que vous ajoutez un site dans vos hosts.

Reverse Proxy sur NixOS

Fri, 01 Jul 2022 00:00:00 +0000

J’ai jonglé entre 3 proxies récemment afin de pouvoir facilement rediriger des requêtes vers les services appropriés, que ce soit en utilisant Docker ou en utilisant des services exposant des ports.

Let’s get started

J’ai expérimenté les proxies suivants dans l’ordre chronologique. Je vais passer en revue pourquoi je les ai utilisés, et pourquoi je les ai aussi abandonnés.
Il n’y en a pas nécessairement de meilleurs que d’autres, c’est juste que chacun trouve chaussure à son pied !

J’avais aussi utilisé une configuration qui permettait de facilement jongler entre les différents services en adaptant le module sans pour autant rajouter de configuration. C’est d’ailleurs l’un des gros avantages de NixOS : pouvoir dissocier la configuration de l’implémentation. Vous pouvez voir le code ici.

Pour des raisons de facilité, on va utiliser l’exemple d’un site web qui serait à l’adresse blog.nicolasguilloux.eu et qui serait disponible en local sur le port 8080. Bien entendu, on souhaite que le site soit en https.

Nginx

C’est le premier proxy que j’ai utilisé, car c’est le serveur web que j’utilisais et qui permettait de facilement mettre en place cette fonctionnalité. C’est aussi le serveur web majoritairement utilisé.

La première chose à faire est de configurer le Acme challenge ainsi que 4 optimisations recommandées pour Nginx. Le premier servira bien entendu à générer automatiquement le certificat HTTPS pour notre site.

# ACME Challenge
security.acme.acceptTerms = true;
security.acme.defaults.email = "nicolas.guilloux@proton.me";

# Use recommended settings
services.nginx.recommendedGzipSettings = lib.mkDefault true;
services.nginx.recommendedOptimisation = lib.mkDefault true;
services.nginx.recommendedProxySettings = lib.mkDefault true;
services.nginx.recommendedTlsSettings = lib.mkDefault true;

Ensuite, il nous faut dire à Nginx de rediriger le traffic entrant de blog.nicolasguilloux.eu vers le port 8080. Pour ce faire, nous allons déclarer une virtual host, lui donner quelques configurations relatives au SSL et au proxy, mais surtout lui dire de rediriger tout le traffic vers la bonne adresse. La configuration parle d’elle-même :

services.nginx.virtualHosts."blog.nicolasguilloux.eu" = {
 forceSSL = true;
 enableACME = true;
 extraConfig = "proxy_buffering off";

 locations."/" = {
 proxyPass = "http://127.0.0.1:8080";
 proxyWebsockets = true;
 extraConfig =
 # required when the target is also TLS server with multiple hosts
 "proxy_ssl_server_name on;" +
 # required when the server wants to use HTTP Authentication
 "proxy_pass_header Authorization;";
 };
};

Nginx était bien mais nécessitait que le service en question expose un port pour être accessible. Comme je travaille beaucoup avec des images Docker, l’utiliser était devenu de plus en plus fastidieux car je devais réfléchir à quel port j’exposais. Si par exemple j’avais deux sites exposés sur le port 80, je devais choisir de les exposer, l’un sur le port 8080 et l’autre sur le port 8081.
Bref, rapidement j’ai trouvé que l’attribution arbitraire d’un port pour éviter les conflits n’était pas pérenne dans le temps.

Caddy Proxy

Celui-ci est légèrement différent. À la base, Caddy est un serveur Web qui fournit beaucoup de fonctionnalité et se veut facile d’accès. Pour notre utilisation, c’est une image docker qui a pour principe de se servir des labels associés à un container Docker pour le router.

Regardons comment "installer" le service the nix way :

On va devoir déclarer un container qui utilisera le port 80 et 443 pour respectivement le http et https.
On doit donner un petit nom au network Docker. Tout container appartenant à ce network sera analysé par caddy-proxy pour trouver éventuellement des labels le concernant.
On l’ajoute bien entendu à ce dit network.
On lui donne accès à notre socket Docker, pour qu’il puisse analyser les différents containers.
On lui donne un espace pour stocker ses données.

Une dernière configuration doit être ajoutée pour créer le network Docker avant de lancer le container pour éviter une erreur.

Voici donc la configuration correspondante :

let
 dockerNetwork = "caddy-proxy";
in
{
 virtualisation.oci-containers.containers.caddy-proxy = {
 autoStart = true;
 image = "lucaslorentz/caddy-docker-proxy:ci-alpine";
 ports = [ "80:80" "443:443" ];
 environment = { CADDY_INGRESS_NETWORKS = "${dockerNetwork} };
 extraOptions = [ "--network=${dockerNetwork} ];
 volumes = [
 "/var/run/docker.sock:/var/run/docker.sock"
 "/var/lib/caddy-proxy:/data"
 ];
 };

 systemd.services.docker-caddy-proxy.preStart = lib.mkAfter ''
 ${pkgs.docker}/bin/docker network create -d bridge ${dockerNetwork} || true
 '';
}

Et voilà, ça fonctionne. On pourra noter une amélioration à apporter : le support de Podman. Pour l’instant, c’est hardcodé pour Docker à cause de preStart ainsi que du socket.

Si on regarde maintenant pour instancier un service qui passerait par ce proxy, on se retrouverait avec une configuration de ce genre :

let
 dockerNetwork = "caddy-proxy";
in
{
 virtualisation.oci-containers.containers.whoami = {
 autoStart = true;
 image = "jwilder/whoami";
 extraOptions = [
 "--network=${dockerNetwork}"
 "--label=caddy=whoami.example.com"
 "--label=caddy.reverse_proxy={{upstreams 8000}}"
 ];
 };
}

J’ai abandonné cette implémentation particulière d’un proxy car étant très pratique pour du développement local avec Docker, elle ne permet pas de facilement placer un service natif derrière celui-ci. De plus, je n’ai pas exploré la possibilité du SSL car je n’envisageais pas cette solution sur mon serveur.

Traefik

Ce qu’il me fallait, c’est le meilleur des deux mondes : placer des services natifs et des services dockerisés derrière un proxy. Si en plus je pouvais avoir une interface graphique pour debugger, ça serait parfait.

Traefik m’a alors été conseillé par un ami, et rempli totalement son rôle. On peut lui dire manuellement de forward tel host sur tel adresse et port, tout comme on peut bénéficier d’une configuration avec des labels via le Docker provider.

Voyons quelques prérequis qui expliquent la configuration :

Traefik doit avoir accès à Docker
On veut son Dashboard pour pouvoir facilement débugger
On doit configurer au moins deux points d’entrées : un pour le http et l’autre pour le https. Le http dans cet exemple redirigera vers le https.
On doit configurer la génération des certificats
On souhaite par défaut que le dashboard soit accessible via https://traefik.local

Avec tout ça en tête, on obtient alors la configuration par défaut suivante :

{ config, lib, pkgs, ... }:

let
 localCertificationDirectory = config.security.localCertification.directory;
in
{
 # Enable Traefik
 services.traefik.enable = true;

 # Let Traefik interact with Docker
 services.traefik.group = "docker";

 services.traefik.staticConfigOptions = {
 api.dashboard = true;
 api.insecure = false;

 # Enable logs
 log.filePath = "/var/log/traefik/traefik.log";
 accessLog.filePath = "/var/log/traefik/accessLog.log";

 # Enable Docker provider
 providers.docker = {
 endpoint = "unix:///run/docker.sock";
 watch = true;
 exposedByDefault = false;
 };

 # Configure entrypoints, i.e the ports
 entryPoints = {
 websecure.address = ":443";
 web = {
 address = ":80";
 http.redirections.entryPoint = {
 to = "websecure";
 scheme = "https";
 };
 };
 };

 # Configure certification
 certificatesResolvers.acme-challenge.acme = {
 email = "nicolas.guilloux@proton.me";
 storage = "/var/lib/traefik/acme.json";
 httpChallenge.entryPoint = "web";
 };
 };

 # Dashboard
 services.traefik.dynamicConfigOptions.http.routers.dashboard = {
 rule = lib.mkDefault "Host(`traefik.local`)";
 service = "api@internal";
 entryPoints = [ "websecure" ];
 tls = lib.mkDefault true;
 # Add certification
 # tls.certResolver = "acme-challenge";
 };

 # Add Dashboard to hosts
 networking.hosts."127.0.0.1" =
 if config.services.traefik.dynamicConfigOptions.http.routers.dashboard.rule == "Host(`traefik.local`)" then
 [ "traefik.local" ]
 else
 [ ];
}

À partir de là, on a un Traefik qui dispose d’un dashboard et qui surveille Docker, quel que soit le network.

Note	Si jamais vous voulez manipuler des headers, il faut passer par des middlewares.

Regardons déjà la déclaration d’un container pour qu’il soit câblé sur Traefik. L’attribution des labels est plutôt évidentes.

virtualisation.oci-containers.containers.whoami = {
 autoStart = true;
 image = "jwilder/whoami";
 extraOptions = [
 "--label=traefik.enable=true"
 "--label=traefik.http.routers.whoami.entrypoints=websecure"
 "--label=traefik.http.routers.whoami.rule=Host(`whoami.example.com`)"
 "--label=traefik.http.routers.whoami.tls=true"
 "--label=traefik.http.services.whoami.loadbalancer.server.port=8000"
 # Add certification
 # "--label=traefik.http.routers.whoami.tls.certresolver=acme-challenge"
 ];
};

Pour ajouter notre fameux blog, c’est-à-dire un service natif, on peut le faire de la manière suivante :

services.traefik.dynamicConfigOptions.http.services."blog.nicolasguilloux.eu" = {
 loadBalancer.servers = [
 { url = "http://127.0.0.1:8080"; }
 ];
};

Traefik est pour moi la solution qui me convient le mieux, car elle réunit le meilleur des deux précédents proxy, tout en proposant davantage. Le dashboard est très pratique pour surveiller le routing, et je pourrais explorer d’autres fonctionnalités à l’avenir comme le routing TCP/UDP.

Aller plus loin

Il y a plusieurs fonctionnalités que j’ai ou vais explorer avec Traefik :

Faire de la certification en local
Faire du routing TCP/UDP
Implémenter du monitoring
Implémenter + de sécurité (Crowdsec ?)

Le Bridge Signal pour Matrix

Thu, 08 Apr 2021 00:00:00 +0000

Matrix est un protocole de messagerie instantanée. La suite de ce ticket considère que vous connaissez les bases et notamment le glossaire. Je vous conseille fortement d’aller lire le tutoriel précédent : Matrix sur NixOS

Signal Messenger

Le bridge Signal supporte les conversations de groupe et les messages directs. Toutefois, toute conversation chiffrée ne sera pas supportée.
La petite particularité sur ce bridge est que Signal ne dispose pas d’une API. Ainsi, il va falloir utiliser une image Docker qui va simuler un accès Web à Signal.

Voici la configuration que je préconise :

{ config, lib, ... }:

let
 bridgeFolder = "/var/lib/mautrix-signal";

 toListIfExists = path:
 if (lib.pathExists path) then
 [ path ]
 else
 [];
in {
 # Signal daemon
 virtualisation.oci-containers.containers.signald = {
 image = "docker.io/finn/signald";
 volumes = [ "${bridgeFolder}/signald:/signald" ];
 extraOptions = [ "--network=host" ];
 };

 # Signal bridge
 virtualisation.oci-containers.containers.mautrix-signal = {
 image = "dock.mau.dev/tulir/mautrix-signal";
 extraOptions = [ "--network=host" ];
 dependsOn = [ "signald" ];
 volumes = [
 "${bridgeFolder}/data:/data"
 "${bridgeFolder}/signald:/signald"
 ];
 };

 # Add configuration to Matrix server
 services.matrix-synapse.app_service_config_files = toListIfExists "${bridgeFolder}/data/registration.yaml";
}

Si on résume, toutes les données sont stockées dans /var/lib/mautrix-signal. On ajoute les images Docker qui permettent de lancer le bridge.

L’image signald est le daemon pour pouvoir simuler une interface Web auprès de notre application Signal. C’est nécessaire pour pouvoir récupérer les messages en toute sécurité vu que Signal ne dispose pas d’API.
C’est aussi pour cela qu’on doit partager le volume où sont stockées toutes les informations (comme les avatars) entre le daemon et le bridge.

On va dès maintenant configurer ce dernier en éditant en tant que root le fichier /var/lib/mautrix-signal/data/config.yaml… Enfin faite votre nixos-rebuild switch pour lancer le bridge.

On va changer différentes clés dans le fichier, je vais lister ce les clés qui ont changé :

homeserver:
 address: http://localhost:8008
 domain: server_name
 verify_ssl: false

signal:
 socket_path: /signald/signald.sock
 outgoing_attachment_dir: /signald/attachments
 avatar_dir: /signald/avatars
 data_dir: /signald/data

bridge:
 permissions:
 "*": user
 "@pseudo:server_name": admin

homeserver.address : Votre serveur Matrix, pas besoin de passer par internet, il est disponible en local
homeserver.domain : C’est le server_name, vous devriez maintenant savoir ce que c’est :)
homeserver.verify_ssl : Comme on est dans une boucle locale, pas besoin de vérifier le SSL
signal.socket-path : Socket pour dialoguer avec le daemon
signal.outgoing_attachment_dir : Répertoire du daemon où sont mis les pièces jointes
signal.avatar_dir : Répertoire du daemon où sont mis les avatars
signal.data_dir : Répertoire du daemon où sont mis les autres données utiles aux bridges
bridge.permissions : Ce sont les permissions. Pour ma part, j’ai mis "*": user pour que tous les utilisateurs puissent utiliser le bridge, et enfin "@pseudo:server_name": admin pour que votre utilisateur puisse l’administrer

Une fois ça fait, pensez à redémarrer votre image docker docker restart mautrix-signal et faites ensuite un petit nixos-rebuild switch. Normalement, matrix-synapse se redémarrera car le fichier registration.yaml existera.

Vous pouvez maintenant constater que vous pouvez parler au bot dans votre client Matrix en ouvrant une conversation avec @signalbot:server_name.
Celui-ci devrait accepter votre invitation. Vous pouvez alors lui demander de l’aide comme il le propose.

A partir d’ici vous avez plusieurs choix, car vous pouvez :

Créer un compte de zéro en utilisant la commande register +33xxxxxxxxx. Si vous n’avez pas signal sur votre téléphone, cela permettra de tout recevoir sur Matrix directement.
Lier votre compte déjà existant, relié à votre téléphone, et forward tous les messages à Matrix en tapant link et en scannant le QR Code.

Une fois connecté, attendez un peu et vous allez recevoir plein d’invitations :) Bien joué, tout devrait fonctionner !

Le Bridge Telegram pour Matrix

Mon, 05 Apr 2021 00:00:00 +0000

Telegram Messenger

Le bridge de Telegram supporte quasiment toutes les fonctionnalités. La configuration est quasiment la même que pour Mautrix Facebook hormis un léger changement au niveau de la configuration d’une API.
Je n’ai volontairement pas suivi la configuration proposée par NixOS car je n’ai jamais réussi à la faire fonctionner, et je souhaite avoir une installation cohérente. Comme NixOS ne propose pas de module pour Mautrix Facebook, Mautrix Telegram et Mautrix Signal, je préfère les configurer de la même manière.

Voici la configuration que je préconise :

{ config, lib, ... }:

let
 bridgeFolder = "/var/lib/mautrix-telegram";

 toListIfExists = path:
 if (lib.pathExists path) then
 [ path ]
 else
 [];
in {
 # Telegram bridge
 virtualisation.oci-containers.containers.mautrix-telegram = {
 image = "dock.mau.dev/tulir/mautrix-telegram";
 extraOptions = [ "--network=host" ];
 volumes = [ "${bridgeFolder}/data:/data" ];
 };

 # Add configuration to Matrix server
 services.matrix-synapse.app_service_config_files = toListIfExists "${bridgeFolder}/data/registration.yaml";
}

Si on résume, toutes les données sont stockées dans /var/lib/mautrix-telegram. On ajoute l’image docker qui permet de lancer le bridge.

On va dès maintenant le configurer en éditant en tant que root le fichier /var/lib/mautrix-telegram/data/config.yaml… Enfin faite votre nixos-rebuild switch pour lancer le bridge.

Dans un premier temps, il faut faire une application sur le site de Telegram pour récupérer un ID et un hash qui serviront au bridge pour interagir avec l’API. Pour ce faire, allez sur cette page d’aide de Telegram et suivez les instructions pour récupérer le api_id et le api_hash.

On va changer différentes clés dans le fichier, je vais lister ce les clés qui ont changé :

homeserver:
 address: http://localhost:8008
 domain: server_name
 verify_ssl: false

telegram:
 api_id: #ApiId#
 api_hash: #ApiHash#

bridge:
 permissions:
 "*": user
 "@pseudo:server_name": admin

homeserver.address : Votre serveur Matrix, pas besoin de passer par internet, il est disponible en local
homeserver.domain : C’est le server_name, vous devriez maintenant savoir ce que c’est :)
homeserver.verify_ssl : Comme on est dans une boucle locale, pas besoin de vérifier le SSL
telegram.api_id : ID fourni par Telegram sur le site
telegram.api_hash : Hash fourni par Telegram sur le site
bridge.permissions : Ce sont les permissions. Pour ma part, j’ai mis "*": user pour que tous les utilisateurs puissent utiliser le bridge, et enfin "@pseudo:server_name": admin pour que votre utilisateur puisse l’administrer

Une fois ça fait, pensez à redémarrer votre image docker docker restart mautrix-telegram et faites ensuite un petit nixos-rebuild switch. Normalement, matrix-synapse se redémarrera car le fichier registration.yaml existera.

Vous pouvez maintenant constater que vous pouvez parler au bot dans votre client Matrix en ouvrant une conversation avec @telegrambot:server_name.
Celui-ci devrait accepter votre invitation. Vous pouvez alors lui demander de l’aide comme il le propose. Pour lier votre compte, faites !tg login et suivez les instructions.

Une fois connecté, attendez un peu et vous allez recevoir plein d’invitations :) Bien joué, tout devrait fonctionner !

Le Bridge Facebook pour Matrix

Mon, 29 Mar 2021 00:00:00 +0000

Facebook Messenger

Bon, qu’on se le dise, j’aimerai bien partir de Facebook mais beaucoup de personnes ne veulent pas par simplicité. Même si ça m’embête pour des raisons évidentes, je dois rester dessus car j’ai vraiment des personnes que j’aime beaucoup qui refusent de passer sur d’autres plateformes.
C’est d’ailleurs un intérêt de ce bridge : je vais désinstaller toutes les applications Facebook, ma seule interaction sera via Matrix.

Dans un premier temps, on va préparer notre base de données afin d’y stocker les données utiles au bridge. Pour le moment, celui-ci ne supporte que PostgreSQL. Ca tombe bien, on a déjà une BDD disponible via le serveur Synapse. Aussi, on va pouvoir facilement créer un user et une base.

sudo -u postgres psql
CREATE ROLE "mautrixfacebook" WITH LOGIN PASSWORD 'VotreMotDePasseUnique';
CREATE DATABASE "mautrixfacebook" WITH OWNER "mautrixfacebook" TEMPLATE template0 LC_COLLATE = "C" LC_CTYPE = "C";
\q

Une fois fait, on va pouvoir préparer notre module qui va démarrer l’image docker du bridge. On va aussi câbler ce bridge à notre instance Matrix.

{ config, lib, ... }:

let
 bridgeFolder = "/var/lib/mautrix-facebook";

 toListIfExists = path:
 if (lib.pathExists path) then
 [ path ]
 else
 [];
in {
 # Facebook bridge
 virtualisation.oci-containers.containers.mautrix-facebook = {
 image = "dock.mau.dev/tulir/mautrix-facebook";
 extraOptions = [ "--network=host" ];
 volumes = [ "${bridgeFolder}/data:/data" ];
 };

 # Add configuration to Matrix server
 services.matrix-synapse.app_service_config_files = toListIfExists "${bridgeFolder}/data/registration.yaml";
}

Si on résume, toutes les données sont stockées dans /var/lib/mautrix-facebook. On ajoute l’image docker qui permet de lancer le bridge.
La partie où on relie notre bridge à notre serveur est commentée pour le moment car le fichier en question sera généré par le bridge, et donc n’existe pas avant d’avoir bien parametré le bridge.

On va dès maintenant le configurer en éditant en tant que root le fichier /var/lib/mautrix-facebook/data/config.yaml… Enfin faite votre nixos-rebuild switch pour lancer le bridge.

On va changer différentes clés dans le fichier, je vais lister les clés qui ont changé :

homeserver:
 address: http://localhost:8008
 domain: server_name
 verify_ssl: false

appservice:
 database: postgres://mautrixfacebook:VotreMotDePasseUnique@127.0.0.1/mautrixfacebook

bridge:
 permissions:
 "*": user
 "@pseudo:server_name": admin

homeserver.address : Votre serveur Matrix, pas besoin de passer par internet, il est disponible en local
homeserver.domain : C’est le server_name, vous devriez maintenant savoir ce que c’est :)
homeserver.verify_ssl : Comme on est dans une boucle locale, pas besoin de vérifier le SSL
appservice.database : Lien vers *votre base de données. Pensez à changer le mot de passe pour celui que vous avez utilisé au dessus.
bridge.permissions : Ce sont les permissions. Pour ma part, j’ai mis "*": user pour que tous les utilisateurs puissent utiliser le bridge, et enfin "@pseudo:server_name": admin pour que votre utilisateur puisse l’administrer

Une fois ça fait, pensez à redémarrer votre image docker docker restart mautrix-facebook et faites ensuite un petit nixos-rebuild switch. Normalement, matrix-synapse se redémarrera car le fichier registration.yaml existera.

Vous pouvez maintenant constater que vous pouvez parler au bot dans votre client Matrix en ouvrant une conversation avec @facebookbot:server_name.
Celui-ci devrait accepter votre invitation. Vous pouvez alors lui demander de l’aide comme il le propose. Pour lier votre compte, faites login <email> avec l’email de votre compte Facebook bien entendu ! Suivez ce qu’il vous dit, il va vous demander votre mot de passe et potentiellement votre code de double authentification.

Une fois connecté, attendez un peu et vous allez recevoir plein d’invitations :) Bien joué, tout devrait fonctionner !

Matrix sur NixOS

Fri, 26 Mar 2021 00:00:00 +0000

Comme beaucoup de personnes, j’ai beaucoup de messageries qui ont su évoluer (ou pas) dans le temps. Et chacune de ces messageries apporte ses avantages et ses inconvénients, et la plupart des gens ne veulent pas toutes les avoir. Et j’en fais partie !

Aussi, j’ai toujours reluqué Matrix de loin. Les seules fois où j’avais abordé ce standard, j’ai été très déçu à cause de la lenteur de celui-ci et aussi le fait que ce soit extrêmement intimidant au niveau sécurité.

Finalement, j’ai décidé de me lancer en entendant parler de Beeper qui permettait de centraliser plein de protocoles au même endroit. J’ai été déçu de voir que c’était très payant pour une utilisation domestique. Et j’ai remarqué par mon don incroyable de lecture de la seule et unique page disponible que Beeper était une application basée sur Matrix et la notion de bridges. Donc, en théorie, on peut faire la même chose sans payer.

Qu’est-ce que Matrix

Matrix est un standard OpenSource pour construire une messagerie sécurisée en temps réel et décentralisée. Beaucoup de buzz words, on va expliquer tout ça.

C’est un standard, ce qui veut dire que Matrix n’est pas un logiciel mais simplement une liste de fonctionnalités à implémenter afin de supporter le protocole. C’est un peu comme si on parlait d’un mixeur, qui est la fonctionnalité, ce qui ne l’empêche pas d’avoir un nom donné par la marque ou par les utilisateurs. Le mixeur de mes parents s’appelle Bob.
Une messagerie sécurisée en temps réel, c’est assez simple à comprendre.
Pour le côté décentralisé, ça veut dire que un seul et unique serveur n’est pas souverain du réseau. Ainsi, installer un serveur chez vous permettra d’avoir accès au service sur votre réseau. Matrix implémente aussi un système pour faire dialoguer les serveurs entre eux, comme ça votre serveur ne reste pas dans son coin et pourra dialoguer avec le monde extérieur.

On a parlé plus haut des bridges, et ça c’est une des fonctionnalités de Matrix. Le principe est qu’on peut ajouter un genre de plugin qui joue le rôle d’interface avec quelque chose d’autre. Ouais c’est un peu abstrait, mais concrètement un bridge peut se charger en temps réel de relayer les messages d’une autre messagerie par exemple.

Installation du serveur

J’ai rassemblé tous mes efforts pour que tout fonctionne dans un dossier de mon installation NixOS. Il peut varier dans le temps, j’actualiserais le tutoriel et les liens vers ma configuration en fonction des updates.

Le serveur Synapse

Tout commence d’abord par installer Synapse qui est un serveur Matrix. Matrix étant un standard, Synapse est une implémentation de celui-ci. Si vous êtes déjà perdu, relisez le point précédent ;)

Ici, NixOS nous a bien facilité la tâche vu qu’une configuration est disponible, donc on peut aller très vite.

services.matrix-synapse = {
 enable = true;
 server_name = "matrix.nicolasguilloux.eu";
 registration_shared_secret = "UnSecretTemporaire";
 # enable_registration = true;

 listeners = [
 {
 port = 8008;
 bind_address = "::1";
 type = "http";
 tls = false;
 x_forwarded = true;
 resources = [
 {
 names = [ "client" "federation" ];
 compress = false;
 }
 ];
 }
 ];
};

# For the registration of a user
services.matrix-synapse.registration_shared_secret = "UnSecretTemporaire";
environment.systemPackages = [ pkgs.matrix-synapse ];

Il faut s’assurer que l’option server_name correspond bien à l’adresse finale du serveur. C’est important pour faire dialoguer le monde extérieur avec notre instance. Si jamais vous vous lancez dans l’installation et que cette adresse est fausse, il faudra tout recommencer.

Ici, on n’utilise qu’un seul port : le 8008. C’est celui conseillé dans la documentation. Vous remarquerez qu’il n’y a pas de SSL, c’est parce que mon serveur sera exposé à travers un Reverse Proxy géré par Nginx. On va voir ça après.

L’option registration_shared_secret est là uniquement pour enregistrer votre utilisateur administrateur. Il faudra bien penser à l’enlever, car elle permet de créer des utilisateurs un peu comme on veut en utilisant le dit mot de passe.

Et enfin, pas besoin d’importer le paquet de Synapse dans ceux de système hormis pour l’inscription d’un nouvel utilisateur via un terminal.

La base de données

Il faudra aussi configurer une base de données PostgreSQL pour le serveur.

# Manually configure PostgreSQL
# ref: https://www.foxypossibilities.com/2018/02/04/running-matrix-synapse-on-nixos/
services.postgresql.enable = true;
services.postgresql.initialScript = pkgs.writeText "synapse-init.sql" ''
 CREATE ROLE "matrix-synapse" WITH LOGIN PASSWORD '${config.secrets.matrix.database}';
 CREATE DATABASE "matrix-synapse" WITH OWNER "matrix-synapse"
 TEMPLATE template0
 LC_COLLATE = "C"
 LC_CTYPE = "C";
'';

Ici, mon mot de passe est défini bien au chaud dans la config. Pensez à mettre votre mot de passe. Vous pouvez aussi faire cette étape à la mano en allant tater sudo -u postgres psql.

Création de notre admin

Avant d’exposer sur Internet, on va déjà créer notre utilisateur admin puis désactiver la possibilité de s’enregistrer en utilisant les lignes de commandes. Comme ça, on ferme une porte !

Ici, rappelez vous la registration_shared_secret mis plus haut et simplement tapez la commande suivante

register_new_matrix_user --shared-secret "UnSecretTemporaire" http://localhost:8008

On suit donc tout ce qu’il nous dit comme il faut en prenant soin de mettre votre utilisateur Admin.

Le Reverse Proxy

On va maintenant configurer notre Reverse Proxy pour qu’il puisse être accessible du monde extérieur. C’est important aussi pour pouvoir dialoguer avec les autres serveurs.

let
 listenPort = port: ssl: {
 addr = "0.0.0.0";
 port = port;
 ssl = ssl;
 };
in
{
 # Open port
 networking.firewall.allowedTCPPorts = [ 8448 ];

 # Reverse proxy
 services.nginx.virtualHosts."matrix.nicolasguilloux.eu" = {
 enableACME = true;
 forceSSL = true;

 listen = [
 (listenPort 80 false)
 (listenPort 443 true)
 (listenPort 8448 true)
 ];

 locations."/_matrix" = {
 proxyPass = "http://[::1]:8008";
 };
 };
}

Ici, on voit que nous redirigeons tout vers notre serveur Synapse. On peut aussi voir qu’on utilise le port 8448. Il est important car c’est ce port qui est utilisé par la fédération des serveurs Matrix. Ainsi, un serveur lambda ira questionner notre serveur via ce port uniquement.

Une fois tout installé, vous pouvez d’ailleurs tester votre serveur pour voir s’il est bien accessible par la fédération.

Si vous avez tout bien fait, normalement vous devez pouvoir vous connecter sur Element.io, modifier le serveur d’accueil (le fameux server_name) et vous connecter.
Vous remarquerez alors que votre pseudo est pseudo:server_name. Par exemple, pour ma part, c’est nover:matrix.nicolasguilloux.eu.

Les Bridges

Une fois votre serveur fonctionnel, vous pouvez jouir de toutes les fonctionnalités de Matrix de base. Vous pouvez donc rejoindre des salons et discuter avec des personnes mêmes si elles ne sont pas sur votre serveur grâce à la magie de la fédération.

On va maintenant pouvoir ajouter des bridges qui vont être les interfaces entre un autre protocole et celui de Matrix. En plus simple : ça va permettre d’envoyer des messages en utilisant Matrix vers des destinataires comme Signal ou encore Messenger.

Ici, je ne vais passer en revue que les bridges que j’ai implémenté sur mon serveur. On notera que la plupart ont été conçu par la même personne et donc ont le préfix mautrix. On peut donc constater qu’ils se configurent quasiment de la même manière.
Je vais aussi essayer de trier l’ordre des bridges ci-dessous en fonction de leur difficulté à installer. Ça permettra de monter progressivement en difficulté.