-
Données
-
PostgreSQL · Redis · restic hors nœud
+
+
+
Sa propre confiance
+
Ses certificats, ses noms de domaine
-
-
Collaboration
-
Nextcloud · Collabora
-
-
-
Observation
-
Prometheus · Loki · Grafana · Icinga
-
-
-
Web et forge
-
nginx · pare-feu applicatif CRS · Forgejo
+
+
+
Une vigie
+
Qui surveille tout, et prévient
-
Aujourd’hui, un écosystème de référence compte 13 machines virtuelles , nées du même gabarit Debian 13 durci : nftables, auditd, AppArmor, fail2ban, SSH par clé seulement.
Set-OPS · Rencontres Linux du Québec 2026
05
-
Ce qu’un écosystème contient. L’identité d’abord : OpenLDAP est la source de vérité, Keycloak fait l’authentification unique, et oauth2-proxy protège les applications qui ne parlent pas OIDC. Une autorité de certification interne, step-ca, délivre les certificats par ACME. PowerDNS pour les noms, avec DNSSEC. Postfix, Dovecot et rspamd pour le courriel — la pile mature, pas la plus jeune. PostgreSQL pour les données, sauvegardées par restic hors du nœud. Nextcloud et Collabora pour travailler ensemble. Prometheus, Loki, Grafana et Icinga pour voir ce qui se passe. Chaque machine part du même gabarit durci. Un écosystème de référence compte treize VM.
+
Concrètement, qu’est-ce qu’une organisation reçoit ? Une identité par personne, avec un seul mot de passe pour tous ses services : c’est OpenLDAP et Keycloak. Son courriel, à son nom de domaine : Postfix, Dovecot, rspamd. Ses fichiers et ses documents, qu’on modifie à plusieurs : Nextcloud et Collabora. Ses sites web, publiés derrière un pare-feu applicatif. Sa propre confiance : sa propre autorité de certification et ses propres serveurs de noms. Et une vigie, Icinga, Prometheus, Grafana, qui surveille tout et prévient. Tout ça, sous son toit, sur ses serveurs ou chez un hébergeur de confiance.
diff --git a/promo/rlq-2026-10-24/slides/etat.html b/promo/rlq-2026-10-24/slides/etat.html
deleted file mode 100644
index 4868923..0000000
--- a/promo/rlq-2026-10-24/slides/etat.html
+++ /dev/null
@@ -1,41 +0,0 @@
-
-
-
03 · L’état traverse la reconstruction
-
Le code reconstruit, la sauvegarde restitue.
-
-
-
1 · Instantané
-
« avant-raser », pris par chaque détenteur d’état
-
-
-
2 · Raser
-
toutes les VM de l’écosystème
-
-
-
3 · Reconstruire
-
cloner, armer le serveur d’exploitation, déployer
-
-
-
4 · Restaurer
-
depuis restic, hors du nœud, chaque service à sa naissance
-
-
-
5 · Comparer
-
les témoins, clé par clé, avant et après
-
-
-
-
Ce qui revient
-
Autorité de certification · annuaire · bases PostgreSQL · fichiers Nextcloud · boîtes de courriel · historique de supervision · métriques · journaux
-
-
-
Le principe
-
L’infrastructure se reconstruit par le code ; on sauvegarde la donnée , pas la VM. Un service qui naît demande au dépôt si une incarnation précédente l’attend.
-
-
Set-OPS · Rencontres Linux du Québec 2026
-13
-Comment l’état traverse une reconstruction. Avant de raser, chaque machine qui détient de l’état prend un instantané nommé « avant-raser », dans un dépôt restic hors du nœud. On rase. On clone les VM, on arme le serveur d’exploitation de l’écosystème, on déploie. Chaque service, en naissant, demande au dépôt de sauvegarde si une incarnation précédente l’attend, et se restaure. Puis on compare des témoins, clé par clé : les empreintes avant et après doivent être identiques. Le principe est simple : l’infrastructure se reconstruit par le code, donc on ne sauvegarde pas des VM, on sauvegarde la donnée. Un détail qui a son importance : si le dépôt est illisible, le service refuse de naître neuf, parce que conclure « rien à restaurer » faute de joindre le dépôt effacerait ce qui attend ailleurs.
-
diff --git a/promo/rlq-2026-10-24/slides/filtrage.html b/promo/rlq-2026-10-24/slides/filtrage.html
deleted file mode 100644
index e6777ae..0000000
--- a/promo/rlq-2026-10-24/slides/filtrage.html
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
-
02 · Le réseau
-
Un flux déclaré, trois pare-feu cohérents.
-
-
-
-
Internet
-
ce qui vient de l’extérieur
-
-
-
Frontière OPNsense
-
nord-sud ; un refus se journalise
-
-
-
SDN EVPN
-
une zone par écosystème, passerelles anycast
-
-
-
Pare-feu Proxmox
-
est-ouest, par VM, refus par défaut
-
-
-
nftables
-
sur chaque hôte, devant le service
-
-
-
-
-
-
-
-
-
Les trois cadres verts sortent du même fichier. Un flux pair: externe devient la politique de bordure ; le registre des flux, généré, sert d’audit et dit le chiffrement de chacun.
-Set-OPS · Rencontres Linux du Québec 2026
-09
-Le réseau, de l’Internet jusqu’au service. La frontière OPNsense tient la bordure nord-sud ; chaque écosystème a sa zone EVPN dans le SDN de Proxmox, avec des passerelles anycast ; le pare-feu de Proxmox filtre l’est-ouest, VM par VM, avec un refus par défaut ; et nftables protège chaque hôte. Les trois pare-feu — en vert — ne sont pas écrits à la main : ils sont dérivés des flux que les rôles déclarent. Un flux dont le pair est « externe » devient une règle de la frontière, posée par son API. Et le registre des flux est généré : c’est la matrice d’audit, qui dit pour chaque flux s’il est chiffré.
-
diff --git a/promo/rlq-2026-10-24/slides/fonctionnement.html b/promo/rlq-2026-10-24/slides/fonctionnement.html
new file mode 100644
index 0000000..0914c4e
--- /dev/null
+++ b/promo/rlq-2026-10-24/slides/fonctionnement.html
@@ -0,0 +1,26 @@
+
+
+
Comment ça marche
+
En une image.
+
+
+
Un plan
+
Quelques fichiers texte qui disent ce dont l’organisation a besoin.
+
+
+
+
Le moteur
+
Déduit tout le reste : adresses, pare-feu, certificats, ordre d’installation.
+
+
+
+
Un écosystème
+
Vivant, sur des serveurs Linux, prêt à servir.
+
+
On modifie le plan, jamais les machines à la main.
+Set-OPS · Rencontres Linux du Québec 2026
+06
+Comment ça marche, en une image. À gauche, un plan : quelques fichiers texte où l’on écrit ce dont l’organisation a besoin. Au milieu, le moteur : il en déduit tout le reste — les adresses de chaque machine, les règles de chaque pare-feu, les certificats, l’ordre dans lequel installer les services. À droite, un écosystème vivant, sur des serveurs Linux. La règle d’or : on modifie le plan, jamais les machines à la main. C’est ce qui permet de tout reconstruire, et de transmettre l’ensemble à quelqu’un d’autre. Pour ceux qui veulent les détails : l’inventaire Ansible est généré, et un seul nombre par organisation suffit à dériver tout son adressage ; j’en parle volontiers après.
+
diff --git a/promo/rlq-2026-10-24/slides/lecons.html b/promo/rlq-2026-10-24/slides/lecons.html
deleted file mode 100644
index 900d0bd..0000000
--- a/promo/rlq-2026-10-24/slides/lecons.html
+++ /dev/null
@@ -1,35 +0,0 @@
-
-
-
04 · Pour vos propres machines
-
Six choses bonnes à savoir.
-
-
-
Un connect() TCP ne prouve rien
-
Un pare-feu peut accepter la poignée de main sans relayer la suite. Seule la livraison compte.
-
-
-
Une sonde trop courte fabrique une panne
-
L’API de Proxmox, sans authentification, répond en 3 s par prudence ; un délai de 2 s y voit une panne.
-
-
-
nginx reload ne déplace pas une écoute
-
Une nouvelle adresse listen demande un restart. Comparer ss à la configuration.
-
-
-
Renouveler un certificat ne suffit pas
-
Le fichier est neuf ; le service sert l’ancien tant qu’on ne le recharge pas.
-
-
-
Ansible veut un tube
-
Une sortie non bloquante donne un échec silencieux. Remède : < /dev/null 2>&1 | cat
-
-
-
OPNsense : le groupe passe d’abord
-
Les règles du groupe wireguard s’appliquent avant celles d’une interface WireGuard assignée.
-
-
Set-OPS · Rencontres Linux du Québec 2026
-17
-Pour une salle d’administrateurs Linux, voici ce qui vous servira peut-être demain matin. Un : un connect TCP réussi ne prouve rien ; un pare-feu peut accepter la poignée de main sans relayer le trafic. Seule la livraison compte, et la destination en est le seul juge. Deux : l’API de Proxmox, quand on l’interroge sans authentification, met un peu plus de trois secondes à répondre, par protection contre la force brute ; une sonde avec un délai de deux secondes y voit une panne qui n’existe pas. Trois : nginx reload n’applique pas un changement d’adresse d’écoute ; il faut un restart, et comparer ss à la configuration. Quatre : un certificat renouvelé sur disque reste servi périmé tant qu’on ne recharge pas le service. Cinq : Ansible lancé avec une sortie non bloquante échoue en silence ; on le fait passer dans un tube. Six : dans OPNsense, les règles du groupe wireguard passent avant celles d’une interface WireGuard assignée.
-
diff --git a/promo/rlq-2026-10-24/slides/libre.html b/promo/rlq-2026-10-24/slides/libre.html
index 3f19c52..5ccd3dc 100644
--- a/promo/rlq-2026-10-24/slides/libre.html
+++ b/promo/rlq-2026-10-24/slides/libre.html
@@ -1,28 +1,27 @@
-
+
-
04 · Le reprendre
-
Libre, et fait pour être repris.
+
Nous rejoindre
+
Il y a une place pour vous.
-
-
AGPLv3 ou ultérieure
-
Le moteur est libre. Le modèle d’affaires : libre + services, héberger et accompagner.
+
+
+
+
Une organisation
+
OBNL, coopérative, PME : reprenez vos outils numériques.
-
-
Sans IA pour l’exploiter
-
Un administrateur reprend l’écosystème avec la documentation, make et la console.
+
+
+
Un hébergeur
+
Vous avez du matériel : devenez un site de la fédération.
-
-
Une remise en deux temps
-
L’identité au jour de la livraison, puis les clés des machines à une échéance écrite.
+
+
+
Un contributeur
+
Le code est libre, sous AGPLv3 : lisez-le, essayez-le.
-
-
Essayer avec le modèle public
-
make instance-creer NOM=OPS-MonOrg MODELE=socle
-
Le code : [adresse publique du dépôt] · Contact : chezlepro.ca/contact
-
+
Le code : [adresse publique du dépôt] · Nous écrire : chezlepro.ca/contact
Set-OPS · Rencontres Linux du Québec 2026
-
19
-
Le projet est libre, sous AGPLv3 ou ultérieure. Le modèle d’affaires est simple : le logiciel est libre, et on vend des services — héberger, accompagner, former. L’outil est conçu pour qu’un administrateur le reprenne sans IA, avec la documentation, make et la console. Et un écosystème se remet à son organisation en deux temps : l’identité le jour de la livraison, puis les clés des machines à une échéance convenue, une fois les nouveaux accès vérifiés. Pour essayer : le dépôt public fournit un modèle générique, socle, et la commande instance-creer en fait un écosystème à vous. Je serai heureux d’en parler après la présentation.
+
14
+
Et vous, dans tout ça ? Il y a une place pour vous. Si vous êtes une organisation — un OBNL, une coopérative, une PME — et que vous voulez reprendre vos outils numériques, parlons-en. Si vous avez du matériel et l’envie d’héberger, vous pouvez devenir un site de la fédération. Et si vous aimez le code, il est libre, sous AGPLv3 : lisez-le, essayez-le avec le modèle public, proposez des améliorations. Le moteur est conçu pour être repris par quelqu’un d’autre que nous : c’est sa raison d’être.
diff --git a/promo/rlq-2026-10-24/slides/plan.html b/promo/rlq-2026-10-24/slides/plan.html
deleted file mode 100644
index da7c30d..0000000
--- a/promo/rlq-2026-10-24/slides/plan.html
+++ /dev/null
@@ -1,44 +0,0 @@
-
-
-
02 · Du plan aux machines
-
On édite le plan, jamais l’inventaire.
-
-
-
plan/*.yml
-
Serveurs, applications, bases, domaines, nomenclature : ce qu’on écrit.
-
-
-
-
make instancier
-
Dérive VMID, IP, VLAN, noms et groupes ; montre l’écart avant d’écrire.
-
-
-
-
hosts.yml
-
L’inventaire Ansible, généré. Personne ne l’édite à la main.
-
-
-
-
make deployer
-
Couche par couche, dans l’ordre d’un graphe de 43 groupes, sans cycle.
-
-
-
-
Un groupe, un playbook
-
Chaque groupe applique ses rôles ; le socle et le durcissement passent en premier.
-
-
-
Lire avant d’écrire
-
Les cibles -plan comparent le réel au plan sans rien changer ; -appliquer réconcilie, sur confirmation.
-
-
-
Un modèle pour démarrer
-
Le modèle public socle : PKI, DNS interne, edge TLS, magasin de courriel.
-
-
Set-OPS · Rencontres Linux du Québec 2026
-06
-La règle d’or : on édite le plan, jamais l’inventaire. Le plan, ce sont quelques fichiers YAML : les serveurs, les applications, les bases, les domaines, la nomenclature. make instancier en dérive tout le reste, et montre l’écart sémantique avant d’écrire quoi que ce soit. L’inventaire Ansible est généré. Puis make deployer applique, couche par couche, dans l’ordre d’un graphe de 43 groupes qu’on vérifie sans cycle. Toutes les commandes qui touchent au réel suivent la même convention : une cible -plan qui lit et compare, une cible -appliquer qui réconcilie, et seulement avec CONFIRMER=true. Pour démarrer, le dépôt public fournit un modèle générique, socle.
-
diff --git a/promo/rlq-2026-10-24/slides/preuves.html b/promo/rlq-2026-10-24/slides/preuves.html
index 5944417..2091ca1 100644
--- a/promo/rlq-2026-10-24/slides/preuves.html
+++ b/promo/rlq-2026-10-24/slides/preuves.html
@@ -1,25 +1,20 @@
-
+
-
03 · Comment on sait
-
Prouver le dépôt, mesurer le système.
+
Une culture de la preuve
+
On ne croit pas. On vérifie.
-
-
make verifier · make prouver
-
Les preuves statiques
-
Lisent le dépôt seul, sans réseau : plan, rôles, flux, documentation, ordre de déploiement. 95 preuves, un rapport daté et rejouable.
+
+
+
95
+
vérifications automatiques, rejouées à chaque changement du moteur.
-
-
make SUJET-plan
-
Les devis
-
Lisent le système en marche, par les API de Proxmox et d’OPNsense et sur les VM, et le comparent au plan. Ils n’écrivent rien.
+
+
Le réel
+
comparé au plan, sans rien modifier, avant toute intervention.
-
-
Chaque garde a son témoin : on casse exprès, elle doit le voir.
-
Et chaque sonde a son contrôle : avant de conclure, on vérifie d’où l’instrument mesure.
-
+
Chaque garde est mise à l’épreuve : on casse exprès, elle doit le voir.
Set-OPS · Rencontres Linux du Québec 2026
-
16
-
Comment sait-on que tout ça tient ? Deux familles d’outils, qu’on ne confond pas. Les preuves statiques lisent le dépôt seul, sans réseau : la cohérence du plan, des rôles, des flux, de la documentation. Il y en a 95 ; elles produisent un rapport daté qu’on peut rejouer. Les devis, eux, lisent le système en marche et le comparent au plan, sans rien écrire. La discipline qui compte le plus : chaque garde a un témoin. On casse exprès — une adresse faussée, un nom retiré — et la garde doit le voir. Une garde qui ne mord jamais ne prouve rien. Même chose pour les sondes : avant d’accuser une machine, on vérifie d’où l’instrument mesure.
+
12
+
Une culture qui traverse tout le projet : on ne croit pas, on vérifie. Quatre-vingt-quinze vérifications automatiques relisent le moteur à chaque changement : la cohérence du plan, des services, de la documentation. D’autres outils comparent le système en marche au plan, sans rien modifier, avant qu’on intervienne. Et chaque garde est elle-même mise à l’épreuve : on casse quelque chose exprès, et on s’assure qu’elle le voit. Une vérification qui ne voit jamais rien ne prouve rien.
diff --git a/promo/rlq-2026-10-24/slides/probleme.html b/promo/rlq-2026-10-24/slides/probleme.html
index 5e41912..f1814fc 100644
--- a/promo/rlq-2026-10-24/slides/probleme.html
+++ b/promo/rlq-2026-10-24/slides/probleme.html
@@ -1,6 +1,6 @@
-
01 · Pourquoi
+
Pourquoi
Une petite organisation loue aujourd’hui
diff --git a/promo/rlq-2026-10-24/slides/reconstructions.html b/promo/rlq-2026-10-24/slides/reconstructions.html
index 59ec8c1..d666014 100644
--- a/promo/rlq-2026-10-24/slides/reconstructions.html
+++ b/promo/rlq-2026-10-24/slides/reconstructions.html
@@ -1,19 +1,9 @@
-
-
-
03 · Raser pour prouver
-
On rase, on reconstruit, on recommence.
-
-Date Ce que la reconstruction a prouvé Durée 13 août Une flotte remontée d’un trait : 43 groupes, 0 échec 37 min 2 sept. Un écosystème rasé et refait depuis zéro ; recette à 0 échec — 10 sept. Reconstruction de confirmation, 0 échec 34 min 1er oct. L’état revient : autorité, annuaire, bases, fichiers, courriel 41 puis 40 min 4 oct. Les deux écosystèmes avant une release étiquetée et signée 42 min chacun 9 oct. Sans PyPI, Galaxy ni app store ; supervision, métriques et journaux compris 43 min, d’une traite
-Une commande : make reconstruire-locataire . Des épreuves datées sur des VM réelles, pas un délai de reprise garanti.
-Set-OPS · Rencontres Linux du Québec 2026 · journal des changements du dépôt
-12
-La meilleure preuve qu’un plan décrit vraiment un écosystème, c’est de tout raser et de tout reconstruire depuis le plan. On le fait régulièrement. Le 13 août, une flotte complète remontée d’un trait. Le 2 septembre, un écosystème rasé et refait depuis zéro. Depuis le 30 septembre, la reconstruction remet aussi l’état : l’autorité de certification, l’annuaire, les bases, les fichiers, le courriel. Le 4 octobre, les deux écosystèmes reconstruits avant d’étiqueter une release. Et le 9 octobre, les deux sur le même commit, sans rien demander à PyPI, à Ansible Galaxy ni à l’app store de Nextcloud : le site fournit tout. Quarante-trois minutes pour Chezlepro, d’une traite. Je précise : ce sont des épreuves datées, pas une promesse de délai de reprise.
+
+La preuve par l’épreuve
+43 minutes
+pour raser une organisation entière et la reconstruire depuis son plan, intacte.
+Comptes, courriel, fichiers, bases de données, historique : identiques avant et après. Chezlepro, le 9 octobre 2026, d’une traite. Nous le refaisons régulièrement depuis août.
+Set-OPS · Rencontres Linux du Québec 2026
+09
+Voici la preuve qui compte le plus pour nous. Quarante-trois minutes : c’est le temps qu’il a fallu, le 9 octobre, pour raser entièrement l’écosystème de Chezlepro — treize machines — et le reconstruire depuis son plan, d’une seule commande. Et pas seulement les machines : les comptes, le courriel, les fichiers, les bases de données, l’historique de la supervision reviennent, identiques avant et après ; on le vérifie, empreinte par empreinte. Nous le faisons régulièrement depuis août : c’est notre façon de prouver que le plan décrit vraiment l’organisation. Une précision honnête : ce sont des épreuves datées, pas une promesse de délai de reprise.
diff --git a/promo/rlq-2026-10-24/slides/reste.html b/promo/rlq-2026-10-24/slides/reste.html
index 99da44e..f609f13 100644
--- a/promo/rlq-2026-10-24/slides/reste.html
+++ b/promo/rlq-2026-10-24/slides/reste.html
@@ -1,27 +1,27 @@
-
+
-
04 · La suite
-
Les prochaines étapes.
+
La suite
+
Les prochaines étapes.
-
-
La délégation DNS
-
Enregistrer la colle des deux serveurs de noms chez les registraires, puis déléguer les domaines.
+
+
+
Nos domaines, chez nous
+
Nos noms de domaine servis par nos propres serveurs de noms.
-
-
Le web public
-
Des certificats Let’s Encrypt sur le frontal web, derrière son pare-feu applicatif.
+
+
Des sites web publics
+
Ouverts au monde, chiffrés, protégés.
-
-
La reprise entre sites
-
Des sauvegardes croisées : chaque membre garde une copie de l’autre.
+
+
Une copie chez l’autre
+
Chaque membre garde une sauvegarde de l’autre.
-
-
D’autres membres
-
Accueillir d’autres membres de l’Alliance, chacun avec son site, monté par le même moteur.
+
+
D’autres membres
+
Accueillir d’autres organisations dans l’Alliance.
Set-OPS · Rencontres Linux du Québec 2026
-
18
-
La suite. D’abord la délégation DNS : enregistrer chez les registraires la colle de nos deux serveurs de noms, puis leur déléguer nos domaines. Ensuite le web public : poser les certificats Let’s Encrypt sur le frontal web, qui a déjà son pare-feu applicatif. Puis la reprise entre les membres : des sauvegardes croisées, pour que chacun garde une copie de l’autre. Et accueillir d’autres membres de l’Alliance Boréale, chacun avec son site, monté par le même moteur.
+
13
+
La suite. D’abord, nos domaines chez nous : nos deux serveurs de noms sont prêts, il reste à les déclarer chez les registraires. Ensuite, des sites web publics, chiffrés et protégés. Puis une copie chez l’autre : chaque membre gardera une sauvegarde de l’autre, sur l’autre site. Et surtout, accueillir d’autres organisations dans l’Alliance Boréale, chacune avec son écosystème, et pourquoi pas son site, monté par le même moteur.
diff --git a/promo/rlq-2026-10-24/slides/secondsite.html b/promo/rlq-2026-10-24/slides/secondsite.html
index e95ab8e..692c7eb 100644
--- a/promo/rlq-2026-10-24/slides/secondsite.html
+++ b/promo/rlq-2026-10-24/slides/secondsite.html
@@ -1,38 +1,25 @@
-
+
-
03 · TechnoLibre · 13 et 14 octobre
-
Le site de TechnoLibre, construit depuis zéro.
+
La fédération, concrètement
+
Deux sites, deux membres, un filet commun.
-
-
Internet
-
visiteurs, résolveurs, registraires
+
+
+
Site de Chezlepro
+
Héberge les écosystèmes des deux membres.
-
-
Relais (VPS)
-
3 adresses fixes louées, routées en /32
+
-
-
Frontière OPNsense
-
sans adresse fixe, elle initie le tunnel
+
+
Site de TechnoLibre
+
Assure la reprise des deux membres.
-
-
Proxmox · 9 VM
-
clonées en 30 secondes chacune
-
-
-
WireGuard
-
-
-
Site de Chezlepro
-
l’autre frontière
-
-
-
Lien entre les sites, WireGuard : réplication du DNS public, administration à distance.
-
Aucune traduction d’adresse : l’adresse du client arrive intacte. Deux serveurs de noms publics, un par site, servent les zones signées DNSSEC.
-
-
Set-OPS · Rencontres Linux du Québec 2026 · sur le matériel de TechnoLibre, la reprise des deux membres
-
15
-
Le 13 et le 14 octobre, nous avons construit le site de TechnoLibre, sur le matériel que TechnoLibre a fourni : une frontière OPNsense, un nœud Proxmox, un stockage ZFS en miroir pour les sauvegardes. C’est la fédération rendue concrète : ce site assure la reprise des deux membres. Le défi : ce site n’a qu’une adresse dynamique. La solution est un relais : trois adresses fixes louées sur un VPS, qui répond à l’ARP pour elles et les route en /32 dans un tunnel WireGuard que la frontière du site initie. Aucune traduction d’adresse : l’adresse du client arrive intacte jusqu’au service. Un second tunnel relie les deux sites : il réplique le DNS public et sert à administrer le site distant. Depuis le 14 octobre, chacune de nos zones publiques est servie par deux serveurs de noms, un par site, signés DNSSEC. Les neuf VM du site sont nées du gabarit en une trentaine de secondes chacune.
+
Construit depuis zéro par le moteur les 13 et 14 octobre, sur le matériel de TechnoLibre. Il sert déjà nos domaines publics ; il gardera bientôt une copie de chacun.
+
Set-OPS · Rencontres Linux du Québec 2026
+
11
+
Voici la fédération, concrètement. Deux sites, un par membre. Celui de Chezlepro héberge aujourd’hui les écosystèmes des deux organisations. Celui de TechnoLibre a été construit depuis zéro par le moteur, le 13 et le 14 octobre, sur le matériel que TechnoLibre a fourni. Les deux sont reliés par un lien chiffré. Le site de TechnoLibre sert déjà nos domaines publics : chacune de nos zones a désormais deux serveurs de noms, un sur chaque site. Prochaine étape : les sauvegardes croisées, pour que chaque site garde une copie de l’autre. C’est exactement l’idée de l’Alliance Boréale : mettre en commun ce qui gagne à l’être, sans que personne perde la maîtrise de ce qui est à lui. Un détail pour les curieux : ce site n’a pas d’adresse fixe ; un petit serveur loué lui prête trois adresses publiques par un tunnel WireGuard.
diff --git a/promo/rlq-2026-10-24/slides/setops.html b/promo/rlq-2026-10-24/slides/setops.html
index 9e203e3..3e4e521 100644
--- a/promo/rlq-2026-10-24/slides/setops.html
+++ b/promo/rlq-2026-10-24/slides/setops.html
@@ -1,34 +1,23 @@
-
+
-
01 · Ce que c’est
-
Un moteur qui transforme un plan
+
Notre réponse
+
Vous décrivez votre organisation.
-
-
-
Le moteur
-
Rôles Ansible, playbooks, scripts Python de dérivation, preuves. Un seul dépôt, générique.
+
+
+
Libre
+
Tout le logiciel est libre, de bout en bout. Le moteur aussi.
-
-
L’écosystème
-
Un dépôt par organisation : son plan, son inventaire généré, sa voûte chiffrée.
+
+
Reconstructible
+
Tout est écrit : on peut tout raser et tout retrouver.
-
-
Le site
-
Un dépôt par hébergeur : grappe Proxmox, réseau, frontière OPNsense.
-
-
-
L’exploitation
-
La documentation, make et une console web. Aucune IA requise.
-
-
-
-
Logiciel libre, exclusivement.
-
Ni Docker, ni Podman : des services natifs, des paquets Debian et systemd, sur des VM Debian 13 clonées d’un gabarit durci.
-
Licence AGPLv3 ou ultérieure
+
+
Transmissible
+
Un administrateur le reprend sans nous, et sans IA.
Set-OPS · Rencontres Linux du Québec 2026
04
-
Set-OPS est un moteur : des rôles Ansible et des scripts Python qui lisent un plan déclaratif et en dérivent tout le reste. Le moteur est générique ; chaque écosystème réel vit dans son propre dépôt, avec sa voûte. L’hébergeur, lui, a son dépôt de site : la grappe Proxmox, le réseau, la frontière OPNsense. Deux principes fondateurs : tout est en logiciel libre, et pas de conteneurs — des services natifs, comme un administrateur Debian les installerait à la main. Et l’outil doit s’exploiter sans IA : la documentation, make et la console suffisent. Je le dis franchement : le mainteneur, lui, se fait assister par une IA pour écrire le moteur ; l’exploitant n’en a pas besoin.
+
Notre réponse tient en une phrase : vous décrivez votre organisation, Set-OPS la construit. On écrit dans quelques fichiers ce dont l’organisation a besoin — ses services, ses machines, ses domaines — et le moteur fait le reste. Trois engagements. Libre : tout le logiciel l’est, le moteur aussi, sous licence AGPL. Reconstructible : comme tout est écrit, on peut tout raser et tout retrouver ; je vous montrerai que ce n’est pas une figure de style. Transmissible : un administrateur peut reprendre l’écosystème sans nous, avec la documentation et quelques commandes, sans IA. Pour les curieux : c’est du Ansible et du Python, sur Proxmox et Debian, sans conteneurs.
diff --git a/promo/rlq-2026-10-24/slides/site.html b/promo/rlq-2026-10-24/slides/site.html
index 8b6f532..22ad0a5 100644
--- a/promo/rlq-2026-10-24/slides/site.html
+++ b/promo/rlq-2026-10-24/slides/site.html
@@ -1,31 +1,21 @@
-
+
-
02 · Héberger sans posséder
-
Un site héberge, une organisation possède.
+
Héberger sans posséder
+
L’hébergeur prête l’abri.
-
-
Le site · l’hébergeur
-
Grappe Proxmox, SDN, stockage, frontière OPNsense.
-
Crée et détruit les machines, avec sa propre voûte.
-
Prête trois services à un écosystème jeune : les paquets, la forge du moteur, la résolution de noms.
+
+
+
L’hébergeur
+
Fournit le matériel, le réseau et la porte d’entrée. Crée les machines.
-
-
fiche du site
-
-
-
-
face réseau
-
-
-
L’écosystème · l’organisation
-
Son plan, sa voûte, son annuaire, son autorité, ses journaux.
-
Configure ses services par son propre serveur d’exploitation.
-
Peut partir : plan, données, voûte et domaines s’emportent.
+
+
+
L’organisation
+
Possède son plan, ses données, ses comptes et ses clés.
-
Même entreprise ne veut pas dire même pouvoir : une voûte par dépôt, une clé par voûte, et chaque serveur d’exploitation ne lit que son propre dépôt.
+
Elle peut partir quand elle veut, avec son plan, ses données et ses domaines.
Set-OPS · Rencontres Linux du Québec 2026
-
10
-
Deux classes d’écosystème, un contrat entre elles. Le site, c’est l’hébergeur : le matériel, le réseau, la frontière ; il crée les machines. L’écosystème, c’est l’organisation : son plan, sa voûte, son identité, ses journaux ; il configure ses propres services. Le site publie une fiche — son résolveur, son cache de paquets, sa forge, les adresses publiques qu’il attribue — que le moteur dépose chez chaque locataire. Le locataire publie sa face réseau, que le site lit pour poser ses règles. Le site prête trois services à un écosystème jeune, jusqu’à ce qu’il ait les siens : on appelle ça la filiation, puis l’émancipation. Et une organisation peut partir avec son plan, ses données, sa voûte et ses domaines. Même quand une seule entreprise tient les deux rôles, les clés restent séparées.
+
07
+
Une idée qui nous tient à cœur : héberger, ce n’est pas posséder. L’hébergeur prête l’abri : le matériel, le réseau, la porte d’entrée ; c’est lui qui crée les machines. L’organisation garde les clés : son plan, ses données, ses comptes, ses secrets, chiffrés avec sa propre clé. Les deux rôles restent séparés, même quand la même entreprise les tient. Et surtout, l’organisation peut partir quand elle veut, avec son plan, ses données et ses domaines, vers un autre hébergeur qui fait tourner le même moteur. C’est l’inverse de l’enfermement.
diff --git a/promo/rlq-2026-10-24/slides/zeroconfiance.html b/promo/rlq-2026-10-24/slides/zeroconfiance.html
index 7cddc98..8464f00 100644
--- a/promo/rlq-2026-10-24/slides/zeroconfiance.html
+++ b/promo/rlq-2026-10-24/slides/zeroconfiance.html
@@ -1,28 +1,23 @@
-
+
-
03 · Zéro confiance, est-ouest
-
Le trafic interne est chiffré aussi.
+
La sécurité par défaut
+
Chiffré, même à l’intérieur.
-
-
PostgreSQL : TLS obligatoire
-
hostssl seulement dans pg_hba ; les clients vérifient le serveur en verify-full .
+
+
+
+
Bases de données, métriques et journaux : chiffrés entre machines, chaque partie vérifiant l’autre.
-
-
Métriques et journaux en HTTPS
-
Mesuré le 12 octobre : 15 écoutes sur 15 en TLS dans chaque écosystème, 11 sur 11 au site.
+
+
+
Rien ne sort vers Internet sans une raison écrite dans le plan.
-
-
Aucune sortie sans déclaration
-
Depuis le 10 octobre, aucune machine ne sort vers Internet sans un rôle qui le dise. Le site sert les paquets.
-
-
-
Un pare-feu devant chaque VM
-
Le pare-feu de Proxmox est actif, VM par VM, refus par défaut, depuis le 28 septembre.
+
+
+
Un pare-feu devant chaque machine, qui refuse tout ce qui n’est pas prévu.
-
Chaque flux déclare son chiffrement ; le registre des flux, généré, en fait la synthèse.
Set-OPS · Rencontres Linux du Québec 2026
-
14
-
Une directive du 12 octobre : tout transit est chiffré, l’interne comme l’externe. PostgreSQL n’accepte plus que des connexions TLS, et ses clients vérifient l’identité du serveur. Les métriques et les journaux passent en HTTPS vérifié par l’autorité de certification de l’écosystème : mesuré le 12 octobre, toutes les écoutes concernées sont en TLS. Deuxième chantier : plus aucune machine ne sort vers Internet sans qu’un rôle le déclare ; les paquets Debian, les roues Python, les collections Ansible et les applications Nextcloud viennent du site. Et le pare-feu de Proxmox filtre devant chaque VM. Chaque flux déclare s’il est chiffré, et le registre des flux, généré, en fait la synthèse.
+
10
+
La sécurité, par défaut. On a l’habitude de chiffrer ce qui sort vers Internet ; ici, on chiffre aussi ce qui circule à l’intérieur. Les échanges entre machines — la base de données, les métriques, les journaux — sont chiffrés, et chaque partie vérifie l’identité de l’autre avec l’autorité de certification de l’organisation. Rien ne sort vers Internet sans qu’une raison soit écrite dans le plan : même les paquets viennent du site d’hébergement. Et chaque machine a son pare-feu, qui refuse tout ce qui n’est pas prévu. Comme tout cela découle du plan, les règles ne se contredisent pas d’une couche à l’autre.