Posts on Nicolas Guilloux

Ma stack Network

Tue, 17 Feb 2026 00:00:00 +0000

Je pense que le réseau est la pierre angulaire de tout Homelab qui se respecte. Pas besoin de choses overkill juste pour héberger quelques services, mais dès lors que l’IOT s’invite à la fête, il vaut mieux avoir quelque chose de solide.

Je suis parti sur Unifi, car je ne suis pas un pro du réseau et je voulais quelque chose qui fonctionne bien, qui permette un contrôle fin de mon réseau tout en me prenant par la main pour sa configuration. En plus, la partie Camera me tentait bien !

Hardware

Unifi Dream Machine SE

Ou UDM pour les intimes. C’est le centre névralgique du réseau. C’est une passerelle tout-en-un au format rack 1U qui fait office de routeur, de pare-feu, de switch PoE et même de NVR (enregistreur vidéo réseau) pour les caméras Unifi Protect.

Côté performances, on parle d’un routage avec la stack de sécurité qui supporte un débit de ~5 Gbps pour ma configuration. Autant dire que même en activant toutes les protections réseau, ça ne bronche pas.

Ce qui m’a particulièrement séduit, c’est la connectique :

8 ports LAN 1 GbE RJ45 dont 6 ports PoE 15W et 2 ports PoE+ 30W (130W au total) — parfait pour alimenter des access points et caméras sans câbles d’alimentation supplémentaires
2 ports LAN 10G SFP+ — pour les liaisons rapides avec ma Freebox pro et un switch principal

Le tout est géré via l’interface UniFi OS qui centralise la gestion du réseau, des caméras, du contrôle d’accès… C’est propre, c’est intuitif, et ça donne accès à l’ensemble de la suite applicative Unifi (Network, Protect et Connect).

Au départ, j’ai choisi ce matos car il permettait effectivement d’avoir suffisamment de ports en PoE+ pour mettre deux points d’accès et assez d’autres ports pour mes besoins. Je prévoyais aussi l’arrivée de la fibre, ainsi qu’éventuellement rajouter du matos sur le port SFP. Ce qui n’a pas manqué…

USW Pro Max 16 PoE

Quand on commence à brancher des équipements un peu partout, les 8 ports du UDM SE ne suffisent plus. C’est là que ce switch entre en jeu. Le USW Pro Max 16 PoE est un switch managé au format rack 1U qui vient compléter l’infrastructure avec 16 ports supplémentaires et surtout du PoE++ pour les équipements les plus gourmands. Là, je devrais être bulletproof pour le futur.

Côté connectique, c’est bien fourni :

12 ports 1 GbE RJ45 avec PoE+ (30W par port) — pour les access points, caméras et autres équipements classiques
4 ports 2.5 GbE RJ45 avec PoE++ (60W par port) — pour les équipements nécessitant plus de bande passante ou de puissance, comme des access points WiFi 7
2 ports 10G SFP+ — pour les uplinks vers le UDM SE ou d’autres switches

Le petit plus sympa, c’est l’Etherlighting : chaque port s’illumine pour indiquer son état (vitesse de liaison, VLAN natif…). C’est gadget, mais en pratique c’est super utile pour diagnostiquer un problème de câblage d’un coup d’œil dans le rack. Je suis pas très RGB d’habitude, mais je dois avouer que ça fait son petit effet !

Autres

Pour la partie réseau filaire, j’ai quelques petits USW Flex Mini ça et là pour de l’appoint. Par exemple, mon meuble télévision n’a pas besoin de hautes vitesses, donc pour connecter l’Apple TV, la Switch et d’autres appareils, c’est suffisant.

Pour la partie réseau sans fil, j’ai plusieurs points d’accès. Je suis obligé d’en avoir au moins 3 ou 4 pour avoir une couverture acceptable dans ma maison à cause de ses énormes murs en terre de 60cm d’épaisseur. Aucun WiFi ne saurait traverser ça sereinement ! Comme la maison a été bâtie autour de ces murs en terre, j’ai donc 3 zones à couvrir en intérieur, une large zone en extérieur.

La Configuration Générale

Ça, c’est le nerf de la guerre. C’est là qu’on peaufine tout et que mon attrait pour la bidouille prend tout son sens. C’est sympa de monter un rack, mais c’est encore plus satisfaisant de le paramétrer !

Internet

J’ai une fibre Free Pro de 8 Gbps symétrique. Toutefois, je n’utiliserai jamais plus de 5 Gbps car les couches de sécurité de mon UDM limitent le débit en analysant les paquets. C’est un bottleneck que je trouve acceptable pour mon utilisation.

Je suis obligé d’utiliser la Freebox Pro car brancher la fibre directement dans le port fibre de la UDM ne fonctionne pas. Probablement une authentification propriétaire, dans tous les cas le support ne m’a pas aidé à me passer de leur box. Un câble SFP+ relie donc mon UDM à ma Freebox Pro.

J’ai en plus un modem 4G de backup si jamais la connexion principale est down.

Enfin, j’ai un client ProtonVPN pour router une partie du trafic dans un tunnel chiffré. Je l’utilise principalement pour anonymiser certaines connexions.

VLAN

Tout s’axe autour des VLAN qui sont des réseaux virtuels sur lesquels les appareils se connectent.
Généralement, on utilise les VLAN pour cloisonner le réseau en fonction des appareils. Voici les miens :

Main : Correspond au par défaut, sans restriction. Je ne suis pas sûr que ce soit une très bonne pratique de le garder comme tel. Il sert aux appareils réseaux de Unifi.
Devices : Tous les appareils comme les téléphones, ordinateurs et les invités. Par défaut, le réseau est cloisonné et les appareils ne peuvent parler à aucun autre appareil sur le réseau.
Servers : Le nom est plutôt explicite. Généralement ce sont des appareils qui sont statiques et ne sont pas voués à être offline.
Virtual Machines : Les machines virtuelles utilisent ce réseau qui par défaut est isolé.
IoT : Tous les appareils IoT. Par défaut, les appareils ne devraient pas avoir accès à internet, et ont tous accès à ma centrale domotique.

Note	Un dernier VLAN nommé NoT est présent actuellement mais voué à disparaître. Les appareils IoT ont actuellement accès à internet, et les NoT non. À terme, je vais refuser l’accès à tous par défaut, puis autoriser certains domaines au cas par cas. Le VLAN IoT actuel est donc trop laxiste.

WiFi

En vrai c’est plutôt anecdotique. Il y a deux réseaux à savoir un commun qui envoie dans le VLAN Devices, et un autre, caché, dédié aux appareils IoT, qui envoie dans le VLAN IoT.

Je réserve le 2.4GHz pour les appareils legacy, et le 5GHz pour les appareils qui le supportent.

Firewall

Disons-le, c’est la partie sécurité la plus importante. C’est ici qu’on autorise ou non un paquet à faire son petit bonhomme de chemin sur notre réseau, à un appareil de contacter un autre.

Les Objets

Les règles "objets" servent à viser un réseau ou un appareil spécifique et lui donner des règles simples, prioritaires par rapport aux autres règles. Le contrôle que l’on peut avoir sur la configuration est assez limité ici, donc je ne l’utilise que pour des règles simples.

Une règle visant le réseau Devices qui route certains domaines sur la partie VPN.
L’objet réseau HomeAssistant qui a le droit de contacter tout le VLAN IoT.
Certains appareils ont 100% de leur trafic routé vers le VPN.

Les Zones

Un bon schéma vaut mieux qu’un long discours, voici un screenshot du mapping des VLAN sur mon réseau :

Je vais maintenant trier les règles par zone source. Concrètement, c’est surtout trois zones qui sont importantes : IoT, Devices et Servers. La partie Virtual Machines est au cas par cas et souvent éphémère.

Pour le tableau suivant, on parle des privilèges qu’ont les appareils IoT sur le réseau. Comme ces appareils sont très variés et sont sur une zone volontairement restrictive, il y a beaucoup de règles précises.

Nom	Zone Src	Src	Zone Dest	Dest	Description
AirPlay → AirPlay	IoT	AirPlay Devices	IoT	AirPlay Devices	Permet aux appareils supportant AirPlay à échanger
HomeKit Bridge → Camera	IoT	Apple TV	IoT	Camera	Permet à l’Apple TV de se connecter directement aux caméras
IoT → HomeAssistant	IoT	*	Servers	HomeAssistant	Permet à tous les appareils IoT de dialoguer librement avec HomeAssistant
IoT → NTP	IoT	*	External	Domaines spécifiques	Permet à tous les appareils de contacter des serveurs NTP pour l’heure
TV → Multimedia Server	IoT	Télévisions	Servers	NAS	Permet à mes télévisions d’accéder aux services du NAS

Nom

Zone Src

Src

Zone Dest

Dest

Description

AirPlay → AirPlay

IoT

AirPlay Devices

IoT

AirPlay Devices

Permet aux appareils supportant AirPlay à échanger

HomeKit Bridge → Camera

IoT

Apple TV

IoT

Camera

Permet à l’Apple TV de se connecter directement aux caméras

IoT → HomeAssistant

IoT

Servers

HomeAssistant

Permet à tous les appareils IoT de dialoguer librement avec HomeAssistant

IoT → NTP

IoT

External

Domaines spécifiques

Permet à tous les appareils de contacter des serveurs NTP pour l’heure

TV → Multimedia Server

IoT

Télévisions

Servers

NAS

Permet à mes télévisions d’accéder aux services du NAS

Les appareils de la zone Devices doivent supporter le moins de friction possible malgré une zone très restrictive. En effet, on ne souhaiterait pas que quelqu’un râle car il n’arrive pas à utiliser le AirPlay alors que c’est censé marcher, et accuser à raison mes "bidouilles" qui sont inutiles selon eux. Aussi, de la même manière, on expose petit à petit des droits sélectionnés avec soin.

Nom	Zone Src	Src	Zone Dest	Dest	Description
Devices → HomeAssistant	Devices	*	Servers	HomeAssistant	Permet à tous les appareils de contacter les services de HomeAssistant
Devices → Printer	Devices	*	IoT	Imprimantes	Permet à tous les appareils d’imprimer/scanner
Devices → HomeLab HTTP(S)	Devices	*	Servers	HomeLab	Permet à tous les appareils d’accéder aux services Web de mon HomeLab
Devices → AirPlay	Devices	*	IoT	AirPlay	Permet à tous les appareils d’accéder aux services AirPlay
Nover Devices → IoT	Devices	Nover Devices	IoT	*	Activé à l’occasion de maintenance
Nover Devices → Server	Devices	Nover Devices	Servers	*	Activé à l’occasion de maintenance
Nover Devices → VM	Devices	Nover Devices	Virtual Machines	*	Activé à l’occasion de maintenance

Nom

Zone Src

Src

Zone Dest

Dest

Description

Devices → HomeAssistant

Devices

Servers

HomeAssistant

Permet à tous les appareils de contacter les services de HomeAssistant

Devices → Printer

Devices

IoT

Imprimantes

Permet à tous les appareils d’imprimer/scanner

Devices → HomeLab HTTP(S)

Devices

Servers

HomeLab

Permet à tous les appareils d’accéder aux services Web de mon HomeLab

Devices → AirPlay

Devices

IoT

AirPlay

Permet à tous les appareils d’accéder aux services AirPlay

Nover Devices → IoT

Devices

Nover Devices

IoT

Activé à l’occasion de maintenance

Nover Devices → Server

Devices

Nover Devices

Servers

Activé à l’occasion de maintenance

Nover Devices → VM

Devices

Nover Devices

Virtual Machines

Activé à l’occasion de maintenance

Conclusion

Ce réseau comprend quelques subtilités que j’ai passées sous silence pour ne pas rendre plus verbeux un article déjà long. De plus, souvent ces "subtilités" sont dues à une mauvaise abstraction et pourraient être résolues par un meilleur regroupement des appareils ou des règles plus générales.

Je trouve ma configuration plutôt robuste, même si j’y retourne occasionnellement pour peaufiner certaines choses. Par exemple, j’ai eu à utiliser le logiciel AudioRelay entre une VM et mon ordinateur, qui se trouvent sur 2 VLAN différents. Cela a donné lieu à des configurations spécifiques, mais qui n’ont pas grand intérêt à détailler ici.

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é.

Mirint V2

Wed, 10 Mar 2021 00:00:00 +0000

J’ai décidé de revoir mon miroir intelligent pour plusieurs raisons :

J’ai domotisé ma maison, et avoir un affichage des différents capteurs serait vraiment un plus
La page web affichée était faite à la main, alors que des solutions bien plus jolies existent comme MagicMirror
Le miroir était beaucoup trop épais, il sortait du mur d’une 10aine de centimètres
Il était moche
Il était beaucoup trop lourd, impossible de l’installer sur un mur sans mettre 1 ou 2 chevilles
L’écran mettait trop de temps à s’allumer, c’est dommage pour quelque chose qui doit donner des informations de manière spontanée de prendre 10 secondes à les afficher
Autre chose qui en découle, mais on pouvait laisser l’écran allumé, mais il consommait beaucoup trop

Pour toutes ces raisons, j’ai décidé de le démonter pour en faire une nouvelle version.

Matériel

Ecran

Je ne garderais pas l’écran car c’est la principale raison pour laquelle le miroir n’était pas satisfaisant. Comme c’est une ancienne télévision, tout était prévu pour avoir de l’espace derrière l’écran et que celle-ci soit posée sur un meuble. On peut le voir notamment avec les ports HDMI qui sont à la perpendiculaire de la dalle, son épaisseur et son poids.

J’ai réussi à récupérer un écran LCD d’un ordinateur portable et j’ai commandé une carte d’acquisition pour le modèle de l’écran de ~13€ qui fera l’interface entre la sortie HDMI du Rapsberry Pi et la dalle LCD. Le principal intérêt de récupérer un écran comme celui-ci est qu’il a été prévu pour ne pas consommer car étant à l’origine dans un appareil mobile, que son poids et son épaisseur sont vraiment faibles et que cela permet de déporter la dite carte où on peut pour économiser encore une fois de l’espace et réduire l’épaisseur du miroir.

L’autre intérêt est le temps pour s’allumer. Il est quasi immédiat, c’est ainsi que sont utilisés les écrans d’ordinateurs portables. Vous verrez rarement un ordinateur mettre 10 secondes à s’allumer lorsque vous le sortez de veille, ou alors c’est votre OS qui prend son temps et non l’écran.

Et enfin la sécurité : je suis toujours plus à l’aise quand je ne travaille pas avec des tensions mortelles. Aussi, l’écran LCD et sa carte sont alimentés en 12V, ce qui permettra de sortir l’alimentation hors du miroir. Il faudra néanmoins prévoir un abaisseur de tension pour alimenter le Raspberry Pi en 5V.

Raspberry Pi

Parlons du Raspberry Pi. Il s’avère que je pensais avoir un Raspberry Pi 2, mais en fait c’est le premier modèle. Il est donc extrêmement lent, il n’a clairement pas les reins pour produire un affichage rapide qui pourrait avoir des animations fluides. Aussi, il faudra que je change ce composant, il n’est pas approprié. Pour le moment, je n’ai rien d’autre sous la main, et donc je l’utilise comme navigateur avec MagicMirror hébergé à un autre endroit. Dans la suite, je ferais comme si MagicMirror était hébergé sur le Raspberry Pi

Le Raspberry Pi va héberger le logiciel qui va nous permettre de facilement intégrer différents modules pour avoir l’affichage le plus complet possible : MagicMirror. C’est un logiciel spécialement conçu ce qu’on veut faire. Vous pouvez rajouter des plugins pour avoir toute sorte d’information sur l’écran. Comme tout côté logiciel a été fait, on ne va pas beaucoup aborder la configuration de MagicMirror hormis le fait d’avoir une installation fonctionnelle.

Lola

Sun, 18 Mar 2018 00:00:00 +0000

Lola est une extension firefox qui permet de styliser votre nouvel onglet. C’est ma première approche vers les extensions des navigateurs.

Elle est fortement inspirée de l’extension "Momentum" mais ajoute des fonctionnalités qui me plaisent : * La météo * Les raccourcis en bas à gauche sous forme d’icones * Des notifications en bas à droite

Extension Firefox - Github

Mirint

Mon, 10 Jul 2017 00:00:00 +0000

Le miroir intelligent est une petite interface qui devrait, le matin et le soir (ou à vrai dire, à chaque fois que vous allez dans la salle de bain), vous donner des informations pertinentes.

Le but est de se dispenser de vérifier son Smartphone en affichant les choses à faire dans la journée, la météo et quelques news. Et dans un soucis d’ergonomie, pas besoin d’un bouton pour l’activer : un capteur de proximité se chargera de le réveiller quand vous le regardez.

Pour l’instant, le projet n’en est qu’à un stade de prototype non fini. Il n’est toutefois pas abandonné. Après l’achèvement des premières fonctionnalités, le travail suivant sera d’implémenter une reconnaissance vocale.

Matériel

Mirint regroupe différents appareils "recyclés" : ils ne servaient plus, donc je me suis servi.

Ecran de télévision LCD
Raspberry Pi 2 et son alimentation
Câble HDMI
Un coffret
Un film miroir sans tain
Une plaque de plexiglas
Du fil et de quoi souder

La première étape a été de dépioter le téléviseur. Afin que le miroir soit le plus fin possible, il faut enlever toute la partie protection plastique pour ne garder que la dalle et les circuits du téléviseur qui se divisent souvent en deux parties : un circuit d’alimentation où on relit l’appareil au secteur et un circuit d’entrées/sorties où vous branchez HDMI etc.

Il est important de ne pas toucher le circuit d’alimentation quand le système est sous tension ! Il y a risque d’électrisation voire électrocution !

Le Raspberry Pi est relié donc en HDMI au téléviseur. On pourrait auto-alimenter le RPi grâce au port USB du téléviseur, mais il sera tributaire de sa puissance. De plus, si le téléviseur est éteint, il y a de grandes chances que sur la plupart des téléviseurs, le port USB soit désactivé. On opte donc pour une alimentation séparée.

Le coffret a été raboté afin de pouvoir placer le téléviseur sur ses rebords et donc avoir la dalle sur le même plan horizontal que les bords du coffret. Il faudra aussi faire en sorte que ces mêmes bords ainsi que ceux du téléviseur soient noirs (peinture ou scotch noir).

La plaque de plexiglas a été découpée avec les dimensions extérieures du coffret afin qu’elle couvre toute la surface.

Le film miroir a été collé sur la surface qui sera vers l’intérieur du coffret afin d’éviter toute dégradation et rentrée de lumière. Pour le mettre en place :

Bien laver le plexiglas,
Mettre de l’eau savonneuse sur la surface à coller,
Enlever le film protecteur du revêtement miroir,
Placer le film progressivement sur la surface en raclant avec une carte afin de chasser les bulles d’air
Une fois placé et bien séché, couper l’excédent de film

Pour ma part, j’ai percé puis fraisé le plexiglas pour le visser sur le coffret.

Par ailleurs, on veut pouvoir allumer le téléviseur sans appuyer physiquement sur le bouton "Allumer" car ça contraint à démonter le miroir à chaque fois. Ainsi, on regarde la tension appliquée aux bornes de ce bouton poussoir. Généralement, il y a 4 pattes, on peut vérifier avec deux bornes en diagonale.

Une fois trouvé (pour ma part 3,3V), on soude deux fils : un qui ira à la masse du Raspberry Pi et l’autre à un de ses nombreux GPIO, j’ai choisi le n°7. Pour voir la partie logicielle, rendez vous un peu plus bas au paragraphe "Contrôle du téléviseur".

Logiciel

La partie logicielle est obsolète, puisque maintenant il y a MagicMirror qui propose de faire tout ce que j’ai pu proposer.

Dans un premier temps, veillez à bien configurer votre téléviseur pour s’allumer lorsque qu’on le branche et de choisir la source HDMI par défaut. Vous pouvez aussi configurer la profondeur du noir : plus il sera profond plus le rendu sera de qualité.

De plus, vous pouvez configurer le téléviseur pour ne pas s’éteindre. Une amélioration sera à prévoir pour économiser de l’énergie.

Venons au Raspberry qui sera le cerveau de notre miroir. J’ai choisi de faire l’affichage en HTML sur un serveur Web qui sera pour ma part plus facile à maintenir. Toutefois, avant de parler du coeur du projet, il faut configurer notre Raspberry. Je me suis basé sur l’OS Raspbian Jessie Lite. Je pars du principe que les périphériques branchés fonctionnent correctement (comme la carte WiFi de votre RPi).

Connexion au Wifi

Commençons par chercher le SSID de votre réseau (son petit nom en fait) en scannant ce que le RPi reçoit : sudo iwlist wlan0 scan. Cherchez le SSID de votre réseau et notez le dans un coin de votre tête.

On va maintenant modifier les paramètres des réseaux WiFi sudo nano /etc/wpa_supplicant/wpa_supplicant.conf puis rentrez les informations comme suit à la fin du fichier (ou dans le champ correspondant s’il existe déjà la variable) :

network={
 ssid="votre SSID"
 psk="votre mot de passe"
}

ATTENTION : Votre mot de passe est stocké en clair.

Ensuite, on valide nos changements en effectuant ce petit bout de code : sudo wpa_cli reconfigure

On aura besoin d’une interface graphique et de mettre à jour le bousin. On installe donc un serveur X et on met à jour le système (et un petit brin de ménage au cas ou) avec la ligne suivante :

sudo apt-get update
sudo apt-get --no-install-recommends install xserver-xorg xserver-xorg-video-fbdev xinit pciutils xinput xfonts-100dpi xfonts-75dpi xfonts-scalable x11-xserver-utils unclutter
sudo apt-get dist-upgrade
sudo apt-get autoremove

Paramétrage du Raspberry Pi

On va maintenant aller dans les configurations de base du RPi : sudo raspi-config. Cela vous amènera sur l’interface "graphique" suivante :

]

On configure comme ça nous plait en changeant le mot de passe et les options de localisation. On choisit ensuite le menu Interfacing Option pour activer le SSH afin de piloter le miroir à distance.

Enfin, on appuie 2 fois sur Tab pour sélectionner "Finish" et on accepte de redémarrer notre Raspberry Pi.

Rotation de l’écran

Une rotation de l’écran peut être souhaitable suivant le sens de votre miroir. Il nous faut alors modifier un fichier en suivant cette commande : sudo nano /boot/config.txt et on y ajoute la ligne display_rotate = 1

Voici les différentes options :

0 : Orientation normale
1 : 90 degrés
2 : 180 degrés
3 : 270 degrés

Configuration de l’interface graphique

D’abord, on ajoute un nouvel utilisateur pour se connecter avec lors des connexions SSH. On lance la commande sudo adduser NouvelUtilisateur. On répond gentillement à tout ce qu’il nous demande.

On souhaite maintenant charger juste un navigateur. Il faut donc choisir votre navigateur préféré, j’ai choisi Chromium. Pour l’installer : sudo apt-get install chromium-browser

Ensuite, pour lancer le navigateur en plein écran sur GitHub, il faut suivre la commande suivante :

startx /usr/bin/chromium-browser https://github.com/ --window-size=1080,1920 --start-fullscreen --kiosk --incognito -- -nocursor

Il faut prendre garde à l’orientation de l’écran et sa résolution. Pour ma part, je l’avais mis format portrait en full HD.

Pour l’ajouter au démarrage, édite un fichier par la commande nano ~/.bashrc sous l’utilisateur "pi" et ajoute la commande.

Il faudra maintenant arrêter l’écran de veille en éditant le fichier lightdm.conf par la commande suivant sudo nano /etc/lightdm/lightdm.conf et on ajoute xserver-command=X -s 0 dpms.

Pilotage à distance

Notre miroir n’a ni clavier, ni souris. Et rien n’est moins pratique que de contrôler le miroir par la pensée. On va donc se servir du protocole VNC qui va nous servir à piloter l’interface graphique à distance, comme avec le SSH (ils peuvent d’ailleurs être liés). Pour cela, on installe x11vnc : sudo apt-get install x11vnc. Ensuite, on peut lancer 1 session avec x11vnc -auth guess une fois startx lancé par SSH.

Contrôle du téléviseur

Cela découle directement du soudage du bouton. Dans un premier, on installe WiringPi en suivant les instructions de ce lien. Cela nous permettra d’utiliser facilement les GPIO ! Pour plus d’informations, je vous laisse checker le blog d’Idleman.

Une fois installé, on peut commencer les festivités. On paramètre d’abord le GPIO pour être en mode "out" : gpio mode 7 out. Comme je l’ai dit précédemment, j’ai choisi le GPIO 7 (en suivant le schéma joint). On peut ensuite piloter le port en utilisant gpio write 7 bit en remplaçant "bit" par 1 pour du 3,3V ou 0 pour du 0V.

On peut voir que le bouton réagit par front descendant en s’amusant à changer ces valeurs (donc pour simuler le bouton appuyé, on place le GPIO à 0).

Ainsi, pour simuler l’appui du bouton, on utilise la ligne suivante :

gpio write 7 0 && sleep 1 && gpio write 7 1

Pour paramétrer le GPIO en mode out et à l’état 1 (repos du bouton), il nous faut éditer le fichier /home/pi/.bashrc et rajouter les lignes suivantes :

gpio mode 7 out
gpio write 7 1

Ainsi à chaque démarrage, on configure le GPIO 7 en mode Out et à l’état 1.

Cafetière à Induction Domotisée

Sun, 25 Jun 2017 00:00:00 +0000

La Cafetière à Induction Domotisée, aka CID, est une cafetière avec plus d’un atout dans sa poche.

Le but de ce projet était de faire du café rapidement, silencieusement avec la même qualité que les cafetières à dosette. En bref, combler les lacunes de ces dernières en ajoutant une partie domotique.

Le projet a été commencé par mes soins, puis poursuivi dans le cadre des projets de deuxième année de l’ENSEA avec Valentin Loire. Nous poursuivons jusqu’à ce jour le développement.

Voir sa page de présentation

Douglas

Wed, 01 Jan 2014 00:00:00 +0000

Douglas est une enceinte Bluetooth Low-Cost. Une batterie pour portable recyclée, à peu près 15€ de l’huile de coude et vous voilà avec un objet essentiel pour toute sortie entre amis. Pourquoi l’ourson ? Parce que c’est mignon, ça protège bien le matériel qu’il y a dedans et que c’est original.

Douglas est fonctionnel, mais toujours en développement. En effet, je souhaite y apporter quelques fonctionnalités comme la visualisation de la charge de la batterie, le réveil de l’enceinte sans besoin de bouton physique (hormis pour l’appairage).

Version 1

Douglas a surtout pour principe de ne pas couter cher en achetant le minimum possible. Ainsi, seuls les objets ayant un lien dans la liste suivante ont été achetés, le reste étant de la récupération.

Une batterie Li-Ion
Un amplificateur symétrique
Deux haut-parleurs 3W
Un circuit de charge pour batterie Li-Ion
Un module Bluetooth A2DP (le BK800L)
Des résistances de 10kΩ, des boutons poussoirs
Des fils, de l’étain et un fer à souder
Une plaquette pour souder

On en a en tout pour une 15aine d’euros, on s’en sort donc pas trop mal. Il reste maintenant à souder tous les composants ensemble afin que tout fonctionne correctement.

Les choses sérieuses arrivent et il faudra être bien concentré pour la suite des évènements. En effet, le module Bluetooth est un enfer à souder pour peu qu’on n’ait ni fil à wrapper, ni un fer à souder digne de ce nom… J’ai donc fait au possible. J’ai dénudé un fil multibrin pour découper des brins de longueur 3cm. J’ai ensuite soudé chaque brin sur les cosses du module. C’est fastidieux et ça a tendance à déconner. Le mieux aurait été de faire un PCB, mais quand on a pas le matériel, on se débrouille quand même !

Je n’ai pas utilisé toutes les pins mais seulement les suivantes : 1, 2, 4, 5, 6, 7, 12, 16, 17, 25, 26, 29, 32.

J’ai préféré relier toutes les masses (GND sur le schéma) à la masse pour éviter au maximum les interférences. Je ne sais pas si c’est utile, mais ça me rassure. De plus, je n’ai choisi que les pins qui m’intéressaient à savoir les boutons, le son et l’alimentation. On peut très bien utiliser les pins Rx/Tx pour renommer le module Bluetooth par exemple (et remplacer cet affreux nom “BK8000L”).

Place maintenant au montage sur la carte. On prend une petite carte qui acceptera tous les composants. On colle dans un premier temps la batterie sur le circuit. Ensuite, on soude un à un les composants comme le stipule le schéma suivant :

Assurez vous que les soudures soient bien faites afin de ne pas avoir de mauvaises surprises. De plus, prenez garde au soudage du module Bluetooth qui est extrêmement fastidieux compte tenu des petits espaces disponibles, d’où l’utilité des fils à wrapper.

Cela donne le résultat suivant. Vous avez théoriquement 4 fils non-reliés qui sont dédiés aux speakers. J’ai mis un fil supplémentaire qui est un câble USB directement soudé aux bornes du circuit de charge. J’ai donc un port femelle micro-USB ou un câble USB mâle sortant pour recharger facilement.

Pour les enceintes, il a fallu faire 2 caisses de résonnance adaptée aux haut-parleurs et aux dimensions de mon ourson. J’ai pris des tubes en carton trouvés par-ci par-là. A vous d’adapter comme vous le voulez ou pouvez afin d’avoir une bonne caisse de résonnance. Il n’y a pas de règle particulière si ce n’est que de bien fixer les HP pour éviter toute fuite d’air ou vibration.

Pour une prochaine version

Douglas v1 souffrait de quelques petits problèmes ergonomiques.

Quand quelqu’un le serrait dans ses bras (ce qui arrivait souvent), cela pouvait appuyer sur le bouton situé au niveau du ventre. Un appui long redémarre le module ce qui est frustrant lorsque de la musique est en route.
Les boutons pour changer de chanson n’étaient quasiment jamais utilisés.
Les boutons volumes seraient souhaitables mais pourraient ne pas être utilisés.
Changer le volume sur le module s’effectue localement. Or, on pourrait souhaiter qu’un changement de volume sur Douglas se transmette au Smartphone afin que le volume s’actualise sur ce dernier.
Le circuit de charge n’est pas facile d’accès.
La carte en elle même n’est pas prévue pour une longue durée de vie, vu les soudures.

Ce sont des petits problèmes qui n’en sont pas. Je pinaille, mais c’est suffisant pour se lancer dans une version 2 qui pourrait résoudre certains de ces problèmes !

De plus, j’aimerais bien passer pour la version 2 sur du 5W afin d’avoir plus de puissance.

Autre chose qui m’embête, c’est le nom du module Bluetooth. En effet, il diffuse le nom “BK8000L”. Ce serait super chouette de pouvoir le modifier en Douglas par exemple.

Un petit plus serait aussi de pouvoir rediriger le son vers une sortie jack. J’ai pensé à ça quand il y a une petite sono sans bluetooth, et qu’on souhaite quand même profiter du sans fil sans installation bancale.

De la même manière, pouvoir brancher un câble Jack dans Douglas pour bénéficier de ses haut-parleurs pourrait être sympathique. Dans le module ci-dessus du moins, les ports Aux_L et Aux_R (20 et 19) ne sont malheureusement pas déportés. Si nous voulons les utiliser, il faudra souder deux fils sur la carte ce qui peut s’avérer laborieux et dangereux pour la carte.

Enfin, je souhaiterai oublier les petites batteries Li-Ion si possible. En effet, dans une des enceintes que j’avais conçu, l’une d’elle avait gonflé et comme elles ne sont pas protégées, je ne suis pas rassuré.

Je préfère utiliser des batteries externes car elles sont généralement protégées par un boitier, et ont une bien plus grande capacité.

Yana

Thu, 24 Oct 2013 00:00:00 +0000

YANA est une interface domotique développée par Idleman. L’application Android permettait de dicter des ordres afin de déclencher les actions côté serveur. Elle servait donc d’interface portable pour contrôler l’installation.

A cause de mes études, j’ai dû mettre de côté le développement de l’application pour au final l’abandonner. En effet, le serveur a beaucoup évolué sans que je puisse poursuivre les mises à jour. Une autre personne a continué le développement et est donc en charge par la suite de maintenir.

Je remercie :

Valentin Carruesco pour le développement de YANA serveur.
Alexandre Roland pour la reprise du développement de YANA Android.