August 24, 2026

Vincent Bernat

Une introduction interactive au Spanning Tree Protocol

Avertissement

Cet article contient des exemples interactifs. Pour les visualiser et interagir avec eux, vous devez quitter votre lecteur de flux.

Imaginez que vous louiez des bureaux pour un événement de trois jours. Vous installez à la hâte quelques commutateurs Ethernet et scotchez des câbles au sol pour connecter tout le monde. Malheureusement, Gaston, votre collègue le plus maladroit, trébuche sur un câble à chaque fois qu’il se lève pour aller chercher un café. Vous pourriez ajouter des câbles supplémentaires, mais vous provoqueriez alors une tempête de diffusion : des paquets Ethernet qui tournent en boucle et se multiplient jusqu’à saturation.

C’est là qu’intervient le spanning tree protocol (STP). STP bloque le trafic sur un sous-ensemble des câbles pour ne laisser qu’un arbre sans boucle. Quand Gaston récidive, STP reconstruit l’arbre en une seconde, ce qui laisse à Nono, votre unique renfort technique, le temps de rebrancher le câble¹. Jugez par vous-même : l’illustration ci-dessous fait tourner une véritable implémentation de STP dans votre navigateur !

:demo

A1 @0,0 prio=4096
A2 @0,1
A3 @0,2
A4 @0,3

B1 @1,0 prio=8192
B2 @1,1
B3 @1,2
B4 @1,3

C1 @2,0 prio=8192
C2 @2,1
C3 @2,2
C4 @2,3

A1 -- A2 hazard=0
A2 -- A3 hazard=0
A3 -- A4 hazard=0
B1 -- B2
B2 -- B3
B3 -- B4
C1 -- C2 hazard=0
C2 -- C3 hazard=0
C3 -- C4 hazard=0

A1 -- B1 cost=10
B1 -- C1 cost=10
A4 -- B4 cost=20
B4 -- C4 cost=20

Léo @-0.3,0.7 proto=none icon=👦🏻
Zoé @-0.3,1.3 proto=none icon=👧🏽
Eva @0.3,0.7  proto=none icon=👱🏻‍♀️
Luc @0.3,1.3  proto=none icon=👨🏾
A2 -- Léo hazard=0 A2:edge
A2 -- Zoé hazard=0 A2:edge
A2 -- Eva hazard=0 A2:edge
A2 -- Luc hazard=0 A2:edge

Max @-0.3,1.7 proto=none icon=👨🏽
Ana @-0.3,2.3 proto=none icon=👩🏾
Ida @0.3,1.7  proto=none icon=👵🏾
Léa @0.3,2.3  proto=none icon=👩🏼
A3 -- Max hazard=0 A3:edge
A3 -- Ana hazard=0 A3:edge
A3 -- Ida hazard=0 A3:edge
A3 -- Léa hazard=0 A3:edge

Tom @0.7,0.7 proto=none icon=👦🏼
Zac @0.7,1.3 proto=none icon=👨🏻
Sam @1.3,0.7  proto=none icon=🧑🏽
Noa @1.3,1.3  proto=none icon=👱🏼
B2 -- Tom hazard=0.2 B2:edge
B2 -- Zac hazard=0.2 B2:edge
B2 -- Sam hazard=0.2 B2:edge
B2 -- Noa hazard=0.2 B2:edge

Isa @0.7,1.7 proto=none icon=👩🏻
Cam @0.7,2.3 proto=none icon=🧑🏾‍🦱
Aya @1.3,1.7  proto=none icon=🧕🏽
Guy @1.3,2.3  proto=none icon=👴🏿
B3 -- Isa hazard=0.2 B3:edge
B3 -- Cam hazard=0.2 B3:edge
B3 -- Aya hazard=0.2 B3:edge
B3 -- Guy hazard=0.2 B3:edge

Awa @1.7,0.7 proto=none icon=👩🏿
Ève @1.7,1.3 proto=none icon=👧🏼
Aël @2.3,0.7  proto=none icon=🧓🏿
Ali @2.3,1.3  proto=none icon=🧔🏾
C2 -- Awa hazard=0 C2:edge
C2 -- Ève hazard=0 C2:edge
C2 -- Aël hazard=0 C2:edge
C2 -- Ali hazard=0 C2:edge

Gil @1.7,1.7 proto=none icon=👨🏼‍🦳
Lou @1.7,2.3 proto=none icon=🧑🏿
Lia @2.3,1.7  proto=none icon=👧🏻
Mia @2.3,2.3  proto=none icon=👩🏽‍🦰
C3 -- Gil hazard=0 C3:edge
C3 -- Lou hazard=0 C3:edge
C3 -- Lia hazard=0 C3:edge
C3 -- Mia hazard=0 C3:edge

Note

Cet article est aussi disponible en vidéo, en anglais avec des sous-titres en français, mais je vous conseille de continuer ici afin d’explorer les démonstrations interactives.

Les bases

Conçu dans les années 80, le spanning tree protocol a donné naissance à une déclinaison « rapide » (RSTP) et à une variante « compatible VLAN » (MSTP)². Tout ingénieur réseau sensé sait qu’il existe de meilleures solutions, comme BGP EVPN VXLAN. Pourtant, puisque n’importe quel commutateur le parle, le vénérable spanning tree protocol n’a pas dit son dernier mot.

Nous nous concentrons sur RSTP : il a remplacé le protocole d’origine en 2004. Pour éliminer les boucles réseau, RSTP met en œuvre une machine à états complexe. Des temporisateurs, les changements d’état des liens et les trames de contrôle qu’un pont reçoit de ses voisins commandent ses transitions. Ces trames Ethernet sont les Bridge Protocol Data Units (BPDU). Vous pouvez les voir à l’œuvre ci-dessous : appuyez sur le bouton « Start ».

:protocol rstp
:tx-hold 10

A1 @0,1
C11 @1,0 prio=4096 icon=🌳
C12 @1,2 prio=4096 icon=🌳
C21 @2,0 prio=4096 icon=🌳
C22 @2,2 prio=4096 icon=🌳
A2 @3,1

H1 @0,0.2 proto=none icon=💻
H2 @0,1.8 proto=none icon=🖨️
H3 @3,0.2 proto=none icon=📠
H4 @3,1.8 proto=none icon=📺

A1 -- C11
A1 -- C12
A2 -- C21
A2 -- C22
C11 -- C12
C11 -- C21
C11 -- C21
C11 -- C22
C12 -- C21
C12 -- C22
C21 -- C22
A1 -- H1 A1:edge
A1 -- H2 A1:edge
A2 -- H3 A2:edge
A2 -- H4 A2:edge

Au bout de quelques instants, la topologie converge vers un arbre : depuis la racine C11, il existe un chemin vers chaque pont³ et aucune boucle. En haut à droite, l’interface affiche une icône d’arbre 🌳 suivie du temps qu’il a fallu pour atteindre cet état. Coupez un lien et observez comment le protocole trouve en moins d’une seconde un autre chemin pour joindre C12. Vous pouvez arrêter la simulation, l’avancer pas à pas, la réinitialiser ou la ralentir avec le mode « escargot » 🐌. Ne vous inquiétez pas de toutes les informations affichées : je les explique plus loin.

Tous les exemples s’exécutent dans votre navigateur grâce à MSTPD, une implémentation libre de RSTP⁴ fonctionnant en espace utilisateur⁵.

Interlude historique

Radia Perlman, intronisée à l’Internet Hall of Fame en 2014, a résumé dans ce poème l’ancêtre de STP qu’elle a inventé chez DEC. Il a été repris plus tard dans un brevet américain :

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.
A tree which must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.

― Radia Perlman, Algorhyme.

Élection de la racine

Pour construire un arbre, RSTP commence par élire comme pont racine celui qui a l’identifiant de pont le plus faible. Cet identifiant combine la priorité et l’adresse MAC : 8192.6e:2b:10:a0:5f:29.

Dans l’exemple ci-dessous, S1 et S2 ont des priorités de 4 096 et 8 192 : S1 devient racine. S4 a une priorité de 12 288, tandis que S3 conserve la priorité par défaut de 32 768⁶ : S4 devient racine. S5 et S6 n’ont pas de priorité particulière : l’adresse MAC la plus faible l’emporte et S5 devient racine.

:protocol rstp

S1 @0,0 prio=4096
S2 @0,1 prio=8192
S1 -- S2

S3 @1,0
S4 @1,1 prio=12288
S3 -- S4

S5 @2,0
S6 @2,1
S5 -- S6

Au départ, chaque pont s’annonce comme racine⁷ :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    Root Identifier: 8192.02:00:00:01:00:01
    Bridge Identifier: 8192.02:00:00:01:00:01

Dès qu’un pont reçoit une BPDU annonçant une meilleure racine, il propage cette nouvelle information à ses voisins.

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    Root Identifier: 4096.02:00:00:00:00:00
    Bridge Identifier: 8192.02:00:00:00:00:01

Attribution des rôles aux ports

La deuxième étape consiste à attribuer un rôle à chaque port. RSTP définit cinq rôles, chacun représenté par une lettre :

racine (R, root),
désigné (D, designated),
alternatif (A, alternate),
désactivé (X, disabled),
de secours (B, backup)⁸.

Chaque pont qui n’est pas racine choisit comme port racine celui dont le chemin vers la racine a le coût le plus faible. Sauf si vous configurez une valeur spécifique, chaque pont déduit le coût d’un lien à partir de son débit : 20 000 pour 1 Gbit/s. En cas d’égalité, l’identifiant de port le plus faible l’emporte.

Chacun des ports restants devient un port désigné si la BPDU qu’il émet est « meilleure » que celle qu’il reçoit. Sinon, il devient un port alternatif. Plus tard, si le port racine tombe, le « meilleur » port alternatif devient le port racine. Les critères pour choisir la meilleure BPDU sont :

l’identifiant de pont racine le plus faible,
le coût cumulé jusqu’à la racine le plus faible,
l’identifiant de pont le plus faible,
l’identifiant de port le plus faible.

:protocol rstp

S1 @1,0  prio=4096 icon=🌳
S2 @0,1
S3 @2,1

S1 -- S2
S1 -- S3
S1 -- S3
S2 -- S3

Dans l’exemple ci-dessus, après convergence, S1 est la racine car sa priorité est de 4 096, alors que les autres ponts ont une priorité de 32 768. Tous ses ports sont des ports désignés puisque le coût cumulé jusqu’à la racine est nul.

Le port de S2 face à S1 devient un port racine car il présente le coût cumulé le plus faible vers la racine : 20 000 contre 40 000. S3 possède deux ports face à S1 et celui dont l’identifiant de port est le plus faible devient le port racine : 0x8000 contre 0x8001. L’autre candidat est un port alternatif car le port distant sur ce lien émet une meilleure BPDU, avec un coût cumulé nul. Sur le segment entre S2 et S3, c’est le port de S2 qui l’emporte : les deux ponts ont le même coût cumulé jusqu’à la racine (20 000), mais l’identifiant de pont de S2 est plus petit : 32768.02:00:00:00:00:01 contre 32768.02:00:00:00:00:02.

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 20000
    Bridge Identifier: 32768.02:00:00:00:00:01
    Port identifier: 0x8002

Si vous coupez le lien actif entre S1 et S3, S3 promeut le « meilleur » port alternatif en port racine. Si vous désactivez aussi le second lien, S3 retient le port alternatif restant comme port racine. En revanche, si vous désactivez le lien entre S1 et S2, S2 doit travailler un peu plus pour élire un nouveau port racine, car il ne dispose d’aucun port alternatif.

Sauf événement particulier, les ports désignés émettent une BPDU toutes les 2 secondes⁹. Si un pont ne reçoit plus de BPDU de son voisin pendant 3 périodes « hello » consécutives, il le considère comme mort et efface les informations associées au port.

Transition d’état des ports

Chaque port se trouve dans l’un des trois états suivants. Le schéma représente chaque état par une couleur de fond :

rejet (discarding, rouge),
apprentissage (learning, jaune),
transmission (forwarding, vert).

Un port racine passe automatiquement à l’état de transmission. Un port alternatif reste à l’état de rejet. Un port désigné dispose de deux moyens pour passer de l’état de rejet à l’état de transmission :

Si le port est un port d’extrémité (edge port), soit par configuration, soit parce que l’équipement distant ne parle aucune variante de STP, le pont suppose que cet équipement ne participe pas au protocole et ne peut donc pas créer de boucle. Dans ce cas, le port désigné passe immédiatement à l’état de transmission.
Sinon, il envoie une proposition à son voisin en aval. Si le pont distant estime que la BPDU reçue est « meilleure » que toutes celles mémorisées pour ses autres ports, il élit le port de réception comme port racine et démarre le processus de synchronisation : pour éviter une boucle, il fait passer à l’état de rejet tous les ports désignés qui ne sont ni des ports d’extrémité ni déjà synchronisés. Il renvoie ensuite un accord. À la réception de cet accord, le port désigné du pair passe à l’état de transmission¹⁰.

:protocol rstp

S1 @1,0 prio=4096 icon=🌳
S2 @1,1
S3 @0,2
S4 @2,2
S5 @0,3 prio=8192 icon=🪾
S6 @2,3
H1 @0,1.2   proto=none icon=🖨️
H2 @2,1.2   proto=none icon=📠
H3 @2.5,1.3 proto=none icon=📺
H4 @2.5,2.3 proto=none icon=💻

S1 -- S2
S2 -- S3
S2 -- S4
S3 -- S5
S4 -- S6
S4 -- S3
S5 -- S6

S3 -- H1 S3:edge
S4 -- H2 S4:edge
S4 -- H3 S4:edge
S6 -- H4 S6:edge

Dans la topologie ci-dessus, H1, H2, H3 et H4 sont des équipements terminaux qui ne participent pas au protocole. Nous configurons les ports auxquels ils sont raccordés comme des ports d’extrémité : ces ports passent donc immédiatement à l’état de transmission.

Utilisez le bouton « step » pour faire avancer la simulation. L’horloge passe à 1 seconde. Avancez encore d’un cran : S1 et S2 s’envoient mutuellement une proposition. Voici celle de S2 :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..0. .... = Forwarding: No
        ...0 .... = Learning: No
        .... 11.. = Port Role: Designated (3)
        .... ..1. = Proposal: Yes
        .... ...0 = Topology Change: No
    Root Identifier: 32768.02:00:00:00:00:01
    Root Path Cost: 0
    Bridge Identifier: 32768.02:00:00:00:00:01
    Port identifier: 0x8001

S1 ignore cette proposition : son propre identifiant de racine est plus faible. Quand S2 reçoit une proposition similaire de S1, il accepte S1 comme racine. Il élit également le port vers S1 comme port racine et démarre le processus de synchronisation. Ses deux ports désignés sont déjà à l’état de rejet : rien ne change de ce côté. Avancez encore d’un cran : S2 envoie deux BPDU à S1. Dans l’une d’elles, le bit d’accord vaut 1 et le bit de proposition vaut 0. Elle montre aussi que S2 a accepté S1 comme racine et que son port racine est désormais à l’état de transmission. À la réception de cette BPDU, S1 fait passer son propre port désigné à l’état de transmission. À partir de cet instant, le lien entre S1 et S2 achemine le trafic utilisateur.

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..1. .... = Forwarding: Yes
        ...1 .... = Learning: Yes
        .... 10.. = Port Role: Root (2)
        .... ..0. = Proposal: No
        .... ...1 = Topology Change: Yes
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 20000
    Bridge Identifier: 32768.02:00:00:00:00:01
    Port identifier: 0x8001

Voyons maintenant ce qui est arrivé à S5. Réinitialisez la simulation et avancez de deux pas. S5 échange des BPDU avec S3 et S6. Comme S5 possède un identifiant de racine plus faible que S3 et S6, il reste la racine, tandis que S3 et S6 acceptent la proposition et élisent leurs ports racines. S3 et S6 démarrent le processus de synchronisation. Le port de S6 vers H4 reste actif car il s’agit d’un port d’extrémité. Avancez d’un cran : S3 et S6 renvoient tous deux un accord à S5, qui fait passer ses deux ports désignés à l’état de transmission. Pourtant, le lien entre S5 et S3 continue de rejeter le trafic utilisateur ! Si vous regardez attentivement, le port de S3 vers S5 est maintenant un port désigné, et non un port racine. Lors de la même étape, S3 reçoit aussi une meilleure BPDU de S2, avec S1 comme racine. Il élit son port vers S2 comme port racine et rétrograde le port vers S5 en port désigné, qui reste à l’état de rejet.

À l’étape suivante, les choses se corsent un peu. S3 envoie une proposition à S5¹¹ :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x4f, Agreement, Port Role: Designated, Proposal, Topology Change
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..0. .... = Forwarding: No
        ...0 .... = Learning: No
        .... 11.. = Port Role: Designated (3)
        .... ..1. = Proposal: Yes
        .... ...1 = Topology Change: Yes
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 40000
    Bridge Identifier: 32768.02:00:00:00:00:02
    Port identifier: 0x8002

S5 élit S1 comme racine et le port vers S3 comme port racine. Il démarre son processus de synchronisation, mais le port désigné vers S6 ne passe pas à l’état de rejet. Pourquoi ? Ce port reste un port désigné et son voisin S6 avait déjà envoyé un accord sur ce lien : il conserve donc son statut de port synchronisé.

Revenons maintenant un pas en arrière pour observer ce qui arrive à S6. À cet instant, S6 croit que S5 est la racine. Avancez d’un cran : S4 envoie une nouvelle proposition à S6. S6 l’accepte, élit S1 comme racine et le port vers S4 comme port racine. Le rôle du port face à S5 change : de port racine, il devient port désigné. Comme son pair continue d’annoncer une BPDU inférieure sur le lien, ce port devient contesté (disputed) et passe à l’état de rejet. Le port racine passe à l’état de transmission et le lien devient immédiatement opérationnel, car le port désigné de S4 est déjà à l’état de transmission. Si nous avançons d’un cran, S5 et S6 échangent deux BPDU. Celle de S5 est meilleure grâce à son identifiant de pont plus faible. Le port de S5 reste un port désigné, tandis que S6 rétrograde le sien en port alternatif.

Reprenons une dernière fois depuis le début : coupez le lien entre S1 et S2, laissez tourner la simulation jusqu’à ce que la topologie soit stable, arrêtez-la, puis rétablissez le lien entre S1 et S2. Lors du premier pas, S1 et S2 échangent des propositions. S2 élit S1 comme racine à la place de S5, et le port vers S1 comme port racine. Il rétrograde son ancien port racine en port désigné et le place à l’état de rejet. L’autre port désigné reste synchronisé et conserve son état de transmission. À l’étape suivante, S2 envoie un accord à S1 et le lien entre eux commence à acheminer le trafic utilisateur. S2 envoie également une proposition à S3, mais pas à S4 : il lui envoie une BPDU ordinaire. S4 élit malgré tout S1 comme racine et le port vers S2 comme port racine. Il rétrograde son ancien port racine, celui vers S3, en port désigné, qui passe à l’état de rejet à cause du changement de port racine. L’autre port alternatif, celui vers S6, devient lui aussi un port désigné et reste à l’état de rejet. Le nouveau port racine passe à l’état de transmission. À l’étape suivante, le port de S4 vers S3 se stabilise comme port alternatif après avoir reçu une « meilleure » BPDU de S3.

RSTP est une gigantesque machine à états découpée en machines plus petites : Bridge Detection, Port Information, Port Protocol Migration, Port Role Selection, Port Role Transitions, Port Receive, Port State Transitions, Port Timers, Port Transmit et Topology Change. Certaines s’appliquent à l’ensemble du pont, d’autres à chaque port. Chaque pont exécute une instance ; le temps, les changements d’état opérationnel des ports et les BPDU reçues des autres instances en pilotent les transitions. Ce fonctionnement par événements rend RSTP plus efficace, mais aussi plus difficile à appréhender.

Locomotive à vapeur articulée Garratt de classe Msa des Western Australian Government Railways : élévation et plan

Notification de changement de topologie

Un pont maintient automatiquement une table d’adresses MAC : il associe chaque adresse MAC source au port qui l’a reçue en dernier. Pour commuter une trame Ethernet, il consulte cette table afin de choisir le bon port¹². Quand un lien tombe, un frigo connecté joignable par un port peut le devenir par un autre. Les ponts concernés doivent alors purger les adresses MAC apprises : elles ne sont peut-être plus valables.

Pour cela, RSTP met en œuvre des notifications de changement de topologie à l’aide d’un mécanisme d’inondation. Lorsqu’un port qui n’est pas un port d’extrémité passe à l’état de transmission, un pont génère des BPDU dont le bit topology change (TC) est activé. Il les envoie à tous ses ports désignés, à l’exception des ports d’extrémité, ainsi qu’à son port racine. Il purge également la table d’adresses MAC sur ces ports. Quand un pont reçoit une telle BPDU, il propage la notification sur ses ports désignés hors ports d’extrémité et sur son port racine, sauf celui par lequel elle est arrivée. Il purge lui aussi la table d’adresses MAC sur ces ports. Dans les exemples, les BPDU dont le bit TC vaut 1 sont entourées d’un cercle rouge.

:protocol rstp

S1 @1,0 prio=4096 icon=🌳
S2 @0,1
S3 @1,1
S4 @2,1
S5 @1,2
LPT @0.1,2 proto=none icon=🖨️

S1 -- S2
S1 -- S3
S1 -- S4
S2 -- S3
S2 -- S5
S4 -- S5
S5 -- LPT S5:edge

Lancez la simulation et attendez quelques secondes que la topologie se stabilise. Arrêtez la simulation et désactivez le lien entre S2 et S5. S5 élit le port face à S4 comme port racine, lequel passe immédiatement à l’état de transmission. Avancez d’un cran : S5 émet une BPDU avec le bit TC à 1 :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x79, Agreement, Forwarding, Learning, Port Role: Root, Topology Change
        0... .... = Topology Change Acknowledgment: No
        .1.. .... = Agreement: Yes
        ..1. .... = Forwarding: Yes
        ...1 .... = Learning: Yes
        .... 10.. = Port Role: Root (2)
        .... ..0. = Proposal: No
        .... ...1 = Topology Change: Yes
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 40000
    Bridge Identifier: 32768.02:00:00:00:00:04
    Port identifier: 0x8002

S4 reçoit cette BPDU. Il purge la table d’adresses MAC sur le port face à S1 : par exemple, LPT était auparavant joignable par ce port, mais il faut désormais passer par S5. Avancez d’un cran : S4 envoie à S1 une BPDU avec le bit TC à 1. À la réception de cette BPDU, S1 purge la table d’adresses MAC sur les ports face à S2 et S3. Avancez d’un cran : S1 envoie une notification à S2 et à S3. Avancez encore d’un cran : S2 envoie une notification à S3, tandis que S3 ne fait rien car son port vers S2 est un port alternatif. S3 ne purge aucune table d’adresses MAC : LPT reste joignable par son port vers S1.

Si vous avancez encore un peu, vous verrez que certaines BPDU périodiques conservent le bit TC à 1. Chaque port dispose d’un temporisateur égal au temporisateur « hello » plus une seconde¹³. Ce temporisateur démarre quand le port émet une notification. Jusqu’à son expiration, le port positionne le bit TC à 1 dans toutes les BPDU qu’il envoie. Vous pouvez aussi voir certaines BPDU périodiques sans le bit TC : elles proviennent d’un port qui n’a fait que recevoir une notification et qui n’a donc pas armé son temporisateur.

Sécurité

RSTP est sensible aux erreurs de configuration et peu résistant face aux acteurs malveillants. Un pont qui ne parle pas RSTP peut créer une boucle. Une personne malveillante peut s’insérer dans la topologie pour perturber le service, espionner le trafic ou le modifier.

Pour limiter ces problèmes, vous devez identifier les ports d’extrémité. Un port d’extrémité est raccordé à un équipement tel qu’un PC ou une imprimante. Ces équipements ne génèrent pas de BPDU et ne peuvent pas créer de boucle. RSTP propose deux options liées :

Quand elle est vraie, AdminEdge initialise un port comme port d’extrémité.
Quand elle est vraie, AutoEdge permet à un port de devenir un port d’extrémité s’il ne reçoit aucune BPDU pendant 3 secondes. Cette option est activée par défaut.

Si un port d’extrémité reçoit une BPDU, quelles que soient les valeurs de ces deux options, il redevient un port ordinaire.

R0 @1.5,1.5 prio=8192

# AutoEdge=true, AdminEdge=false, bridge
S1 @3,1.58
R0 -- S1

# AutoEdge=true, AdminEdge=false, end device
H1 @2.84,2.18 icon=🖨️ proto=none
R0 -- H1

# AutoEdge=true, AdminEdge=true, bridge
S2 @2.18,2.84
R0 -- S2 R0:edge

# AutoEdge=true, AdminEdge=true, end device
H2 @1.58,3 icon=💻 proto=none
R0 -- H2 R0:edge

# AutoEdge=false, AdminEdge=true, bridge
S3 @0.68,2.76
R0 -- S3 R0:edge R0:no-auto-edge

# AutoEdge=false, AdminEdge=true, end device
H3 @0.24,2.32 icon=📠 proto=none
R0 -- H3 R0:edge R0:no-auto-edge

# AutoEdge=false, AdminEdge=false, bridge
S4 @0,1.42
R0 -- S4 R0:no-auto-edge

# AutoEdge=false, AdminEdge=false, end device
H4 @0.16,0.82 icon=📺 proto=none
R0 -- H4 R0:no-auto-edge

# Network port, bridge
S5 @0.82,0.16
R0 -- S5 R0:network S5:network

# Network port, end device
H5 @1.42,0 icon=☕ proto=none
R0 -- H5 R0:network

# AdminEdge=true, bpdu-guard=true, bridge
S6 @2.32,0.24
R0 -- S6 R0:bpdu-guard R0:edge

# AdminEdge=true, bpdu-guard=true, end device
H6 @2.76,0.68 icon=💡 proto=none
R0 -- H6 R0:bpdu-guard R0:edge

Dans la topologie ci-dessus, S1, S2, S3, S4, S5 et S6 se comportent comme des ponts, tandis que H1, H2, H3, H4, H5 et H6 se comportent comme des équipements terminaux :

S1 et H1 sont sur un port sans configuration : AutoEdge est vraie, AdminEdge est fausse,
S2 et H2 sont sur un port où AdminEdge est vraie,
S3 et H3 sont sur un port où AutoEdge est fausse et AdminEdge est vraie,
S4 et H4 sont sur un port où AutoEdge est fausse.

Si vous lancez la topologie et attendez une vingtaine de secondes, les liens vers S1, S2, S3, S4, H1, H2, H3 et H4 finissent par acheminer le trafic utilisateur : aucune de ces options n’a d’importance.

Mais qu’en est-il des deux dernières paires ? S5 et H5 sont raccordés à un port de type network. Un tel port active une fonctionnalité propriétaire : le bridge assurance. Le port émet des BPDU quel que soit son rôle. S’il n’en reçoit aucune pendant 3 périodes « hello » consécutives, il passe à l’état de rejet. Sur le lien entre R0 et S5, vous pouvez voir des BPDU circuler dans les deux sens, contrairement aux autres liens, où seuls les ports désignés en émettent.

S6 et H6 sont raccordés à un port où AdminEdge est vraie et où le BPDU guard est activé. Il s’agit d’une autre fonctionnalité propriétaire, qui désactive un port s’il reçoit une BPDU.

En résumé, si vous attendez d’un port qu’il soit un port d’extrémité, positionnez AdminEdge à vrai et activez le BPDU guard. Sinon, déclarez-le comme port network.

Pourquoi RSTP aujourd’hui ?

Un cas d’usage solide pour RSTP aujourd’hui est le réseau d’administration hors bande (OOB) d’un centre de données, où quelques secondes d’indisponibilité sont tolérables. La configuration est minimale et vous pouvez utiliser des commutateurs bon marché, comme un Cisco 2960X¹⁴. Deux commutateurs jouent le rôle de ponts racines et plusieurs boucles raccordent les commutateurs présents dans chaque baie. Cette conception simple survit à une panne sur chaque boucle¹⁵.

:protocol rstp
:tx-hold 10

# Root bridges
R1 @0,1 prio=0
R2 @0,2 prio=4096
R1 -- R2 cost=200 R1:network R2:network
R1 -- R2 cost=200 R1:network R2:network

# First loop
C1  @1,0 icon=🗄️
C4  @2,0 icon=🗄️
C7  @3,0 icon=🗄️
C10 @4,0 icon=🗄️
C12 @5,0 icon=🗄️
C13 @5,3 icon=🗄️
C15 @4,3 icon=🗄️
C18 @3,3 icon=🗄️
C21 @2,3 icon=🗄️
C24 @1,3 icon=🗄️
R1  -- C1  R1:network C1:network
C1  -- C4  C1:network C4:network
C4  -- C7  C4:network C7:network
C7  -- C10 C7:network C10:network
C10 -- C12 C10:network C12:network
C12 -- C13 C12:network C13:network
C13 -- C15 C13:network C15:network
C15 -- C18 C15:network C18:network
C18 -- C21 C18:network C21:network
C21 -- C24 C21:network C24:network
C24 -- R2  C24:network R2:network

# Second loop
C2  @1,0.5 icon=🗄️
C5  @2,0.5 icon=🗄️
C8  @3,0.5 icon=🗄️
C11 @4,0.5 icon=🗄️
C14 @4,2.5 icon=🗄️
C17 @3,2.5 icon=🗄️
C20 @2,2.5 icon=🗄️
C23 @1,2.5 icon=🗄️
R1  -- C2  R1:network C2:network
C2  -- C5  C2:network C5:network
C5  -- C8  C5:network C8:network
C8  -- C11 C8:network C11:network
C11 -- C14 C11:network C14:network
C14 -- C17 C14:network C17:network
C17 -- C20 C17:network C20:network
C20 -- C23 C20:network C23:network
C23 -- R2  C23:network R2:network

# Third loop
C3  @1,1 icon=🗄️
C6  @2,1 icon=🗄️
C9  @3,1 icon=🗄️
C16 @3,2 icon=🗄️
C19 @2,2 icon=🗄️
C22 @1,2 icon=🗄️
R1  -- C3  R1:network C3:network
C3  -- C6  C3:network C6:network
C6  -- C9  C6:network C9:network
C9  -- C16 C9:network C16:network
C16 -- C19 C16:network C19:network
C19 -- C22 C19:network C22:network
C22 -- R2  C22:network R2:network

La convergence prend environ 6 secondes. Chaque boucle doit rester petite (environ 16 ponts) pour réduire la probabilité d’une double panne et éviter de partager trop de bande passante. Cette conception peut évoluer un peu sans devenir trop complexe : un VLAN par boucle ou un domaine de pont par boucle.

Quelle taille pour un réseau ?

L’âge maximal, dont la valeur par défaut est 20, détermine la distance maximale entre un nœud et la racine. La topologie ci-dessous est trop grande : les BPDU issues de R1 ne parviennent pas au-delà de S20¹⁶.

:protocol rstp
:tx-hold 10
:max-age 20

R1 @0,0 prio=4096 icon=🌳
R2 @0,5 prio=4096 icon=🪾

S1  @1,0
S2  @2,0
S3  @3,0
S4  @4,0
S5  @5,0
S6  @6,0

S7  @6,1
S8  @5,1
S9  @4,1
S10 @3,1
S11 @2,1
S12 @1,1

S13 @1,2
S14 @2,2
S15 @3,2
S16 @4,2
S17 @5,2
S18 @6,2

S19 @6,3
S20 @5,3
S21 @4,3
S22 @3,3
S23 @2,3
S24 @1,3

S25 @1,4
S26 @2,4
S27 @3,4
S28 @4,4
S29 @5,4
S30 @6,4

S31 @6,5
S32 @5,5
S33 @4,5
S34 @3,5
S35 @2,5
S36 @1,5

R1  -- S1
S1  -- S2
S2  -- S3
S3  -- S4
S4  -- S5
S5  -- S6
S6  -- S7
S7  -- S8
S8  -- S9
S9  -- S10
S10 -- S11
S11 -- S12
S12 -- S13
S13 -- S14
S14 -- S15
S15 -- S16
S16 -- S17
S17 -- S18
S18 -- S19
S19 -- S20
S20 -- S21
S21 -- S22
S22 -- S23
S23 -- S24
S24 -- S25
S25 -- S26
S26 -- S27
S27 -- S28
S28 -- S29
S29 -- S30
S30 -- S31
S31 -- S32
S32 -- S33
S33 -- S34
S34 -- S35
S35 -- S36
S36 -- R2
R1  -- R2 cost=200 down

Une fois la topologie stabilisée, une partie du réseau considère R1 comme racine et l’autre partie vote pour R2. À la frontière, S20 tente de démarrer une synchronisation avec S21 pour faire passer son port désigné à l’état de transmission. Sa BPDU ressemble à ceci :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x4e, Agreement, Port Role: Designated, Proposal
    Root Identifier: 4096.02:00:00:00:00:00
    Root Path Cost: 400000
    Bridge Identifier: 32768.02:00:00:00:00:15
    Port identifier: 0x8002
    Message Age: 20
    Max Age: 20

S21 la rejette car l’âge du message est égal à l’âge maximal. De son côté, la BPDU que S21 envoie à S20 ressemble à ceci :

Spanning Tree Protocol
    Protocol Identifier: Spanning Tree Protocol (0x0000)
    Protocol Version Identifier: Rapid Spanning Tree (2)
    BPDU Type: Rapid/Multiple Spanning Tree (0x02)
    BPDU flags: 0x7c, Agreement, Forwarding, Learning, Port Role: Designated
    Root Identifier: 4096.02:00:00:00:00:01
    Root Path Cost: 320000
    Bridge Identifier: 32768.02:00:00:00:00:16
    Port identifier: 0x8001
    Message Age: 16
    Max Age: 20

Cela ne suffit pas à changer le port racine de S20, car S20 dispose d’un identifiant de racine plus faible : 4096.02:00:00:00:00:00 contre 4096.02:00:00:00:00:01.

Réparer le lien entre R1 et R2 résout le problème. L’âge de message maximal transporté par un paquet est désormais de 18, en dessous de l’âge maximal configuré. Mais cela ne fonctionne que jusqu’à la rupture d’un autre lien. Une correction possible consiste à porter l’âge maximal à 40¹⁷.

RSTP est-il rapide ?

RSTP converge en général en quelques secondes au démarrage. Il répare souvent un arbre en moins d’une seconde. Même la topologie à 38 ponts converge en moins de 10 secondes¹⁸. Certaines topologies mettent un peu plus de temps à se rétablir quand la racine devient indisponible¹⁹.

:protocol rstp

R0 @1,0 prio=0
S1 @1,1 prio=4096
S2 @0,2 prio=8192
S3 @2,2

R0 -- S1
S1 -- S2
S2 -- S3
S3 -- S1

Dans la topologie ci-dessus, lancez la simulation, attendez la convergence, arrêtez-la, puis coupez le lien entre R0 et S1. La topologie est déjà optimale, mais RSTP peine à converger de nouveau.

D’abord, S1 perd son port racine. Il n’a plus aucune information sur R0 et se proclame racine. Il conserve ses ports vers S2 et S3 comme ports désignés à l’état de transmission. Avancez d’un cran : il envoie une BPDU à S2 et à S3 pour les informer du changement de racine. À sa réception, S2 accepte S1 comme racine, car il ne connaît pas de meilleure racine sur un autre port. Il élit le port vers S1 comme port racine. L’autre port reste un port désigné. Aucun des deux ports ne change d’état.

À la réception de la BPDU de S1, S3 se comporte différemment : il connaît R0 comme une meilleure racine que S1 grâce à son port alternatif vers S2. Il promeut ce port en port racine et rétrograde le port vers S1 en port désigné, ce qui nécessite un nouvel accord. Avancez d’un cran : S3 envoie une proposition à S1 avec R0 comme racine. S1 élit R0 comme racine et promeut son port vers S3 en port racine.

Lors de la même séquence, S3 reçoit aussi une BPDU de S2 affirmant que S1 est la racine. S3 n’a donc plus aucun port annonçant R0 comme racine : il élit S1 comme racine et son port vers S2 comme port racine. Avancez d’un cran : sa BPDU suivante vers S1 contient cette information et S1 s’élit de nouveau racine. Mais lors de la même vague, S1 envoie une proposition à S2 avec R0 comme racine. Alors que S1 et S3 s’accordent sur le fait que S1 est la racine, S2 croit désormais que c’est R0 ! À son tour, S2 convainc de nouveau S3 que R0 est la racine, S3 convainc S1, S1 convainc S2 et S2 convainc S3.

Cela pourrait durer indéfiniment, mais ce n’est pas le cas. Les BPDU affirmant « R0 est la racine » finissent par se périmer lorsque l’âge du message dépasse l’âge maximal. Dans l’exemple ci-dessus, à la onzième seconde, S2 envoie une BPDU à S3 avec R0 comme racine, mais S3 la jette car elle a atteint l’âge maximal. Avec un peu de chance, la convergence peut aussi être plus rapide si un port cesse de transmettre des BPDU après avoir atteint le nombre maximal autorisé par seconde : il s’agit du transmit hold count, dont la valeur par défaut est 6.

À propos de MSTP

MSTP est la version « compatible VLAN » de RSTP : il exécute plusieurs instances de RSTP et permet d’associer chaque VLAN à une instance donnée. Par exemple, vous pouvez rattacher les VLAN 100 à 200 à une première instance et les VLAN 300 à 400 à une seconde. Les VLAN restants sont rattachés à une instance spéciale appelée Internal Spanning Tree (IST). MSTP apporte sa propre complexité, mais l’idée est de disposer de plusieurs topologies logiques indépendantes. Pour creuser le sujet, jetez un œil à « MSTP Tutorial Part I: Inside a Region ».

À propos des exemples interactifs

Les exemples interactifs exécutent MSTPD directement dans votre navigateur, compilé en WebAssembly avec emscripten. Une API C remplace le code qui dialogue avec le noyau Linux : elle gère les ponts et les ports, exporte l’état en JSON et fait avancer le temps de manière déterministe. Une surcouche JavaScript la rend plus agréable à utiliser :

import { loadMSTPD } from "./dist/mstpd.mjs";
const mstp = await loadMSTPD();

// Crée 3 ponts
const a = mstp.createBridge("A", { priority: 4096 });
const b = mstp.createBridge("B", { priority: 8192 });
const c = mstp.createBridge("C");

// Chaque pont a deux ports
const a1 = a.addPort("a-b", { portno: 1 });
const a2 = a.addPort("a-c", { portno: 2 });
const b1 = b.addPort("b-a", { portno: 1 });
const b2 = b.addPort("b-c", { portno: 2 });
const c1 = c.addPort("c-a", { portno: 1 });
const c2 = c.addPort("c-b", { portno: 2 });

// Construit une topologie en triangle
mstp.link(a1, b1);
mstp.link(a2, c1);
mstp.link(b2, c2);

// Active tous les ponts et tous les ports
for (const br of [a, b, c]) br.enable();
for (const p of [a1, a2, b1, b2, c1, c2]) p.enable();

// Exécute 40 secondes de temps réel et affiche la topologie
mstp.step(40);
console.log("Topology:", mstp.topology());

Plusieurs dizaines de tests unitaires explorent les fonctionnalités de MSTPD et vérifient qu’elles se comportent correctement dans cet environnement :

$ node --test *.test.mjs
✔ two bridges: lower priority becomes root (41.657342ms)
✔ triangle loop: exactly one port blocks and all agree on the root (5.832ms)
✔ breaking the active link reconverges and restoring recovers (18.730753ms)
[…]
ℹ tests 40
ℹ pass 40
ℹ fail 0
[…]
ℹ duration_ms 396.190897

Du code JavaScript supplémentaire recherche les blocs <pre> contenant une définition de topologie et les transforme en composant interactif. Vous pouvez inspecter et modifier la définition en cliquant sur le bouton « edit ».

Il y a aussi une astuce pour déterminer si la topologie a convergé. Après chaque pas, nous enregistrons un instantané de la mémoire de la simulation, jouons 50 secondes en accéléré pour vérifier que la topologie est stable, puis remontons le temps en restaurant cet instantané. 🕰️

Le code complet se trouve sur GitHub. Je suis très satisfait du résultat. Il peut être difficile de suivre tout ce qui se passe à chaque étape, mais la possibilité d’avancer et reculer aide beaucoup. Je compte réutiliser cette approche dans de prochains articles.

Note

Michael Lynch a relu une première version de la version anglaise de cet article. Il est l’auteur de « Refactoring English », un livre pour améliorer votre écriture en anglais : articles de blog, documentation, messages de commit et tutoriels. Les erreurs restantes sont les miennes !

Les sprites de Gaston et Nono proviennent de Craftpix. ↩
STP a été introduit dans IEEE 802.1D-1990. Il est encore présent dans IEEE 802.1D-1998, mais il a été retiré d’IEEE 802.1D-2004 au profit de RSTP, introduit dans IEEE 802.1w-2001. MSTP est apparu dans IEEE 802.1s-2002 avant d’être intégré à IEEE 802.1Q-2003. Tous deux font partie d’IEEE 802.1Q-2022, aux côtés de SPB, ~~un protocole dont je n’avais jamais entendu parler avant d’écrire cet article~~. ↩
À partir d’ici, j’emploie le terme « pont » plutôt que le mot plus courant « commutateur ». ↩
MSTPD implémente la machine à états d’IEEE 802.1Q-2005, mais sous Linux, il ne fait tourner que RSTP. Linux 5.18 a ajouté la prise en charge de la commutation pour plusieurs arbres recouvrants, mais MSTPD ne l’utilise pas encore. Consultez la PR #150 pour suivre les avancées sur ce point. ↩
Le noyau Linux ne gère que STP. Il délègue les autres protocoles à l’espace utilisateur. ↩
La priorité est un multiple de 4 096 : avec MSTP, les 12 bits de poids faible de la priorité du pont encodent l’identifiant de l’instance MST, ne laissant que les 4 bits de poids fort pour la priorité configurée. ↩
Pour inspecter les BPDU qui circulent sur un lien, sélectionnez-le, cliquez sur le bouton « Download packets », puis ouvrez le fichier avec Wireshark. ↩
Un port de secours n’existe que si le pont possède plusieurs ports sur le même domaine de collision. Cela ne devrait pas se produire dans un réseau commuté. ↩
C’est la valeur du temporisateur « hello ». Elle était autrefois configurable, mais IEEE 802.1Q-2005 la fixe à 2. MSTPD n’autorise pas d’autre valeur. ↩
Si un port ne reçoit pas d’accord à l’expiration du temporisateur « hello » (ou de l’âge maximal si le port vient tout juste d’être activé), il se rabat sur la méthode à base de temporisateurs, par compatibilité avec STP : il passe à l’état d’apprentissage, attend de nouveau l’expiration du temporisateur « hello », puis passe à l’état de transmission. ↩
Comme dans beaucoup de propositions, S3 positionne aussi le bit d’accord à 1. Le bit de proposition signifie « je suis le port désigné sur ce lien et je veux passer à l’état de transmission ». Le bit d’accord signifie « je suis déjà synchronisé avec le reste de mon pont sur cette information de racine ». Les deux peuvent être vrais en même temps. ↩
S’il ne trouve aucune entrée, le pont duplique la trame Ethernet sur tous les ports, sauf celui d’entrée. Il en va de même si l’adresse MAC de destination est l’adresse de diffusion (ff:ff:ff:ff:ff:ff). Ce comportement amorce le processus d’apprentissage. ↩
Ce temporisateur rend RSTP résistant à la perte de paquets. ↩
Vous pouvez en trouver d’occasion pour moins de 100 €. Tous les ports utilisent PVST+ par défaut et basculent automatiquement vers RSTP classique. ↩
Une solution de rechange serait l’Ethernet Ring Protection Switching (ERPS), un autre protocole dont je n’avais jamais entendu parler avant de me documenter pour cet article. ↩
Si vous observez attentivement ce qui se passe à t=2s, vous verrez que R2 gagne en popularité comme racine : S17 à S36 croient que R2 est la racine. S16 ne suit pas car nous atteignons l’âge maximal. Plus tard, S17 à S20 changent d’avis. Je vous laisse explorer l’état des différents ponts pour en comprendre la cause. ↩
En portant l’âge maximal à 40, vous devez aussi augmenter le délai de transmission à 21 (:forward-delay 21), car le standard impose la condition suivante : 2 × (Forward Delay − 1) ≥ Max Age. Pour cette topologie précise, vous pourriez aussi porter l’âge maximal à 37 et le délai de transmission à 20. ↩
La simulation peut sembler lente, mais elle ne tourne pas en temps réel. Regardez l’horodatage dans le coin supérieur droit pour connaître le temps écoulé, par exemple « t=8s ». Une fois la topologie stabilisée, ce même coin affiche le temps de convergence, par exemple « 🌳 2s ». ↩
Khaled Elmeleegy, Alan Cox et Eugene Ng ont formalisé ce phénomène dans « On Count-to-Infinity Induced Forwarding Loops in Ethernet Networks », puis dans « Understanding and Mitigating the Effects of Count to Infinity in Ethernet Networks ». Ils proposent une correction qui n’a jamais trouvé sa place dans un standard. ↩

24 August, 2026 03:00PM by Vincent Bernat

June 16, 2026

L'usine à clous soviétique ou l'échec des KPI

En 2008, j’ai décroché mon second emploi, dans l’équipe réseau d’Orange Portails¹, la division derrière les sites web et le moteur de recherche de l’opérateur télécom français Orange. Tout y fonctionnait comme sur des roulettes : un environnement technique complet, une équipe dédiée pour chaque pan de l’activité et la liberté de me concentrer sur ce que je faisais de mieux. Quelques années plus tard, plus rien n’allait : minés par une obsession du chiffre, nous n’arrivions plus à livrer les nouveaux services dans les temps.

Avertissement

C’est une histoire que j’aime raconter pour mettre en garde contre la loi de Goodhart². Comme ces événements remontent à près de 15 ans, mes souvenirs sont un peu flous. Je suis parti en 2012.

Les premières années

À mes débuts, le département fonctionnait comme une startup. Son origine était l’entreprise française Echo. Elle avait bâti un moteur de recherche. France Télécom l’a racheté et rebaptisé Voila. C’était le moteur de recherche le plus consulté en France au début des années 2000. France Télécom a regroupé les activités de portail au sein de la division Wanadoo Portails, renommée plus tard Orange Portails.

L’environnement technique était excellent. Nous disposions de nombreux outils internes³ : un système de tickets, un outil de graphes RRD, un IPAM, un outil de reporting et un outil d’alerte basé sur SNMP⁴. Nous déployions nos serveurs Linux avec CFEngine. Nous installions les systèmes et les applications depuis des dépôts Debian internes. Nous documentions tout dans une instance MediaWiki privée. La supervision était basée sur un ancêtre de XYmon. L’architecture réseau était propre et évolutive, avec peu de dette technique. Un nouvel arrivant était opérationnel en une journée.

C’était un environnement épanouissant pour moi. J’ai développé plusieurs outils : lldpd, une implémentation de 802.1AB, Snimpy, une interface pythonique pour Net-SNMP, Wiremaps, un outil de découverte de niveau 2 doté d’une machine à remonter le temps pour savoir quel équipement est connecté où, Kitérő, un outil pour simuler des conditions réseau, QCSS-3, un contrôleur pour répartiteurs de charge, et ipoo, un service accessible via un bot Jabber et un script Greasemonkey pour exposer des informations liées aux adresses IP. J’ai ajouté le support SNMP pour Keepalived et Quagga. J’ai aussi lancé ce blog, avec des articles comme « DNS anycast », des articles sur TLS comme « Déni de service TLS : quelles solutions ? », des articles sur SNMP comme « Intégration de Net-SNMP dans une boucle d’évènements », des articles sur Linux comme « Comprendre la mise en cache des routes IPv4 sous Linux », et un article sur VXLAN bien avant que ce soit à la mode.

La chute

Quand nous avions besoin de nouveaux serveurs, l’équipe de proximité en prenait un lot dans l’inventaire, y installait notre distribution Linux, les déplaçait dans le datacenter et les câblait au réseau. Nous ouvrions un ticket décrivant les serveurs dont nous avions besoin et, une semaine plus tard, nos serveurs étaient disponibles. 💫

Orange voulait savoir si l’équipe de proximité était performante : elle a donc réclamé des KPI. Le choix s’est porté sur le nombre de tickets traités dans l’année. Orange a demandé à doubler ce nombre. Au lieu d’un seul ticket pour un nouveau service, nous en ouvrions six, un par serveur. À la fin de l’année, les KPI avaient plus que doublé.

Tout le monde y a vu une réussite du pilotage de la performance. Il a donc été demandé de récidiver l’année suivante. Cette fois, nous devions ouvrir un ticket par serveur et par étape. De nouveau, les KPI ont doublé. En coulisses, les tickets partaient à différentes personnes et n’étaient plus traités dans l’ordre. Aussi, pour l’année suivante, il a été décidé de créer des méta-tickets et de tenir des réunions pour suivre l’avancement de ces tickets. Bien sûr, toutes ces étapes supplémentaires faisaient encore grimper le KPI.

Cette méthode de pilotage de la performance s’est étendue aux autres équipes⁵. Tout est devenu plus lent. Au lieu de quelques semaines, il nous fallait six mois pour déployer un nouveau service. Nous avions bâti une usine à clous soviétique. Mais les KPI étaient bons et nous avons lâché l’affaire.

Prenons un autre exemple. Nous devions estimer l’impact de chaque opération de nuit. Nous n’étions pas mauvais : l’essentiel des opérations étaient déclarées « sans impact ». La plupart du temps, c’était le cas. Parfois, il y avait un impact de 5 secondes. On nous a demandé de faire plus d’efforts pour tenir l’impact annoncé. Qu’avons-nous fait ? Nous avons commencé à déclarer un impact attendu de 5 secondes. Un jour, nous avons eu un impact de 30 secondes et il nous a été reproché de ne pas avoir respecté l’impact annoncé. Au final, la plupart des opérations étaient déclarées avec un impact attendu de 10 minutes, et nous avons cessé de nous en préoccuper : au lieu de basculer le trafic avec soin, nous nous autorisions un impact de 5 minutes. Et nos KPI n’avaient jamais été aussi bons.

Graphique montrant l'impact des opérations de nuit. Année après année, la tolérance de l'impact est augmentée. La dernière année, l'impact attendu est de 10 minutes et toutes les opérations sont en dessous de ce seuil. Toutefois, les impacts sont beaucoup plus importants que la première année.

Les KPI ne sont pas inutiles, mais ils peuvent avoir des conséquences négatives. Utilisez-les avec précaution : laissez les personnes opérationnelles participer au choix des indicateurs et reliez ces indicateurs à la qualité du service rendu, par exemple avec des objectifs de niveau de service. Sinon, même les plus consciencieux finissent par lâcher prise et détourner le système avant de partir⁶. 📊

En interne, cette entité s’appelait « Hebex » (hébergement et exploitation) et était située sur les sites de Bagnolet et de Sophia-Antipolis. ↩
La loi de Goodhart est souvent citée, mais la loi de Campbell décrit encore mieux mon expérience : plus on s’appuie sur un chiffre pour prendre des décisions, plus vite les gens le corrompent. ↩
À l’époque, le SaaS n’était pas vraiment répandu. Je me souviens avoir envisagé, avec deux collègues, de vendre Wiremaps en SaaS, avec un chiffrement homomorphe pour la base de données. Mais qui aurait accepté d’externaliser sa pile d’observabilité ? ↩
Snalert était un outil d’alerte métacirculaire écrit en Perl. Il pouvait interroger un très grand nombre de cibles SNMP en peu de temps. Toute notre supervision reposait sur SNMP, y compris la supervision système. ↩
Mon équipe gérait aussi les règles de nombreux pare-feux sous Linux. Pour gonfler nos KPI, nous appliquions la même méthode : plutôt que d’accepter un seul ticket avec une matrice de flux, nous exigions un ticket par flux. ↩
Orange n’est pas un cas isolé. Le processus de promotion de Google est un autre exemple bien connu de KPI défaillant. Michael Lynch le raconte dans « Why I Quit Google to Work for Myself ». ↩

16 June, 2026 06:26AM by Vincent Bernat

June 09, 2026

Tenir un blog bilingue avec l'aide d'une IA

L’IA inonde le web de contenus insipides. Les articles sur LinkedIn avec une image générée par IA, remplis d’émojis, publiés par des soi-disant experts sur un sujet auquel ils ne portent pas assez d’intérêt pour écrire eux-mêmes, sont les pires spécimens. Bien que je sois très contrarié de cette situation, je m’appuie sur des LLMs pour la grammaire, les révisions linguistiques et la traduction. Je ne trouve pas cela incohérent.

Ma langue maternelle est le français mais j’écris la plupart des articles en anglais et en français. Quand j’ai commencé à écrire ce blog en 2011, je rédigeais d’abord en français avant de traduire en anglais. J’ai fini par comprendre qu’il était préférable de le faire dans l’autre sens afin de rendre le texte plus naturel et idiomatique. J’essaie d’écrire un anglais « correct » mais cela n’a jamais été mon point fort¹. Par exemple, j’ai toujours eu des difficultés sur l’accord des temps. J’apprends les règles et je les oublie immédiatement. Je ne me vois pas non plus embaucher un éditeur pour quelque chose que je considère comme un loisir.

À titre d’exemple, j’ai gardé l’historique des modifications successives lors de l’écriture de « Scaling Akvorado BMP RIB with sharding » :

la première ébauche rédigée à l’aide d’un dictionnaire de synonymes² ;
la version modifiée par la compétence « révision linguistique » ;
la traduction en français générée par la compétence « traduction » ;
la version révisée par un humain avec quelques modifications sur la version anglaise.

Je sais que les IA peuvent dénaturer la voix de l’auteur pendant l’édition, mais les corrections apportées lors de la seconde étape sont mineures. Les instructions sont « d’appliquer de légères modifications de style » tout en demandant d’éviter les formes passives, les phrases trop longues, les verbes peu expressifs et les mots inutiles. Elles définissent également l’audience cible : technique avec un niveau d’anglais B2.

Dans l’extrait suivant, j’ai utilisé « long time » au lieu de « long-standing ». Outre le trait d’union manquant, le premier s’applique à des personnes (a long-time friend), tandis que le second concerne des situations (a long-standing agreement). J’ai mis pas mal de temps à comprendre la seconde modification : l’IA préfère cette forme grammaticale pour introduire la définition de « RIB sharding ».

As the Internet routing table contains more than 1 million routes, Akvorado needs to scale to tens of millions of routes. This has been a ~~long time~~ long-standing challenge, but I expect this issue is now fixed by using RIB sharding, a method ~~to split~~ that splits the routing database into several parts to enable concurrent updates.

Dans la modification ci-dessous, l’IA utilise le mot « device » plutôt que le mot « équipement » car ce dernier est indénombrable. Je le sais mais je tombe régulièrement dans ce piège.

When Akvorado does not find a route from a specific device, it falls back to a route sent by another ~~equipment~~ device.

J’encourage l’IA à utiliser des verbes descriptifs et elle s’exécute en remplaçant une périphrase par un verbe précis :

The benchmarks demonstrate it ~~has better performance than~~ outperforms other ~~packages, both~~ packages for lookups, insertions, and memory usage.

Elle corrige aussi les erreurs de grammaire. Dans le passage suivant, « list of routes » est au singulier. De plus, « stored » représente un état et il ne faut pas le faire suivre de « into » qui indique un changement.

The list of routes for each prefix ~~are~~ is not stored directly ~~into~~ in the prefix tree.

Voici un dernier exemple : le verbe « require » doit être suivi d’un nom ou d’un objet suivi d’un infinitif. Il n’est pas possible de le faire suivre directement par un infinitif.

An alternative would be to have one prefix tree for each peer but it would require ~~to configure~~ configuring all routers to export their routes.

Même si je lis beaucoup d’anglais³, je bute toujours sur ces règles de grammaire. Le français est une langue relativement simple une fois les bases acquises alors que l’anglais est rempli d’irrégularités.

J’indique dans chaque pied de page si une IA a été utilisée pour modifier le contenu. Il y a 3 niveaux :

🧠: pas d’IA ou pratiquement pas (par exemple, des corrections grammaticales)
✨: amélioré par l’IA (par exemple, des révisions linguistiques)
🤖: généré par IA (par exemple, traduit depuis une autre langue)

Survolez avec la souris ou tapotez sur l’icône pour révéler le nom de l’IA et son rôle dans la modification du document.

Capture d'écran montrant le pied de page avec l'émoji « étincelles »

Le graphique ci-dessous représente par année les outils utilisés pour modifier chaque article. J’ai récemment demandé à une IA des corrections grammaticales sur les anciens articles, aussi bien en anglais qu’en français. Depuis 2018, les articles sont traduits en français à l’aide de DeepL puis ensuite d’une IA. Depuis 2024, je m’appuie sur une IA pour les révisions linguistiques des articles en anglais.

🖼 Graphique montrant l'utilisation de l'IA année par année. Chaque niveau a sa propre teinte.

Utilisation de l'IA année par année. Passez la souris sur une bande pour plus de détails.

Si vous êtes fermement opposé à l’utilisation des LLM dans l’écriture, j’espère que vous acceptez mon point de vue plus nuancé comme une contrepartie pour des articles en français, l’IA mâchant énormément le travail de traduction. En ce qui concerne l’anglais, la littérature sur le sujet s’accorde sur l’importance de choisir le bon mot pour capturer l’attention du lecteur jusqu’à la fin.

[…] Bien écrire consiste à maîtriser un certain nombre de choses fondamentales, à savoir le vocabulaire, la grammaire et le style, et à remplir le troisième compartiment de sa boîte à outils avec les bons instruments.

― Stephen King, On Writing

Note

Contrairement à d’autres articles récents, je n’ai pas utilisé d’IA, ni pour traduire en français, ni pour relire la version anglaise. Pour cette dernière, une personne anonyme a accepté de corriger ma copie.

Mise à jour (06.2026)

Voir la discussion associée à cet article sur Lobsters, ainsi que l’article « How developers react to AI-scented blog posts » de Cynthia Dunlop, l’une des coautrices de « Writing for Developers ».

J’ai récemment lu « Writing for Developers » du début à la fin et je l’ai trouvé motivant. Michael Lynch est en train d’écrire « Refactoring English » sur le même sujet et je me suis inscrit à l’accès anticipé. ↩
Je suis très satisfait des outils d’aide à l’écriture proposés par Kagi. L’outil de traduction et le dictionnaire me sont très utiles pour trouver le bon mot. Je recours aussi à l’assistant de recherche de Kagi lors de la phase de documentation. ↩
Dès le CM2, je jouais à Monkey Island 2 en anglais sans l’avoir appris à l’école. J’utilisais un dictionnaire et je restais perplexe à la vue des verbes irréguliers. ↩

09 June, 2026 08:15PM by Vincent Bernat

June 07, 2026

Stéphane Blondon

Just, make, task : trois outils pour faire (des trucs)

Sous Unix, un fichier Makefile est le moyen classique d’exécuter diverses tâches (en premier lieu des compilations de binaires). Récemment, deux outils (just et task) ont gagné en popularité. Ils ont le même objectif, tout en cherchant à être plus adaptés aux usages de développement actuels.

L’installation des différents outils est simple :

Le binaire make est dans le paquet make (incroyable !) et est probablement déjà installé.
Le binaire just est dans le paquet just (bis).
Debian ne contient pas de paquet task. Un binaire task est bien disponible dans le paquet taskwarrior mais c’est un outil pour décompter le temps passé. Les développeurs de Taskfile fournissent un paquet Debian, déclaré comme incompatible avec taskwarrior à cause du nom identique de l’exécutable. Compiler le binaire soi-même est facile une fois que les outils pour compiler du Go sont déjà présents sur la machine.

A. Formats de fichier

Voici des exemples minimaux pour les trois outils :

1. Makefile

			
cible:
	commande

Les fichiers Makefile utilisent des tabulations. Aujourd’hui, on s’attend plutôt à des espaces. Un éditeur correct sait déjà le gérer donc ça ne devrait pas être vraiment un problème mais peut surprendre un nouvel arrivant.

2. Justfile

			
cible:
    commande

Il n’y a pas de différence visible avec le Makefile précédent car les fichiers Justfile en sont proches. Le format est simple et utilise des espaces plutôt que des tabulations.

C’est un format spécifique que les autres outils ne prennent pas toujours bien en charge (ou pas par défaut). Par exemple, bat (dans le paquet Debian nommé batcat) ou pygments ne savent pas faire de la coloration syntaxique sur ce format. Par contre, il existe des greffons pour Codium ou pour emacs (par exemple, just-mode, son code source et le dépôt Melpa), etc. De même, WordPress ne le prend pas en compte donc tous les codes source de Justfile ne bénéficieront pas de coloration syntaxique dans cet article.

3. Taskfile

			
version: &apos3&apos
tasks:
  cible:
    cmd: commande

Taskfile réutilise le format YAML. Cela permet d’avoir une syntaxe connue et un outillage déjà prêt (coloration syntaxique et vérification de la syntaxe). Cependant, cela donne aussi des contenus plus verbeux que les Justfiles.

À noter que la ligne version est indispensable aux Taskfile car des versions antérieures du format de fichier sont incompatibles.

B. Exemples équivalents

Voici trois fichiers d’exemple montrant les mêmes commandes basiques pour les Makefile, Justfile et Taskfile :

1. Makefile

			
BINNAME = hellomake
.PHONY: build clean test
build: ## Compile le binaire
	gcc -o $(BINNAME) main.c
	./gen_assets.sh
clean: ## Supprime les fichiers générés
	rm -f $(BINNAME)
test: ## Exécute les tests
	./tests.sh

		

Historiquement, les Makefile étaient (et sont encore) utilisés pour produire des fichiers. Les cibles peuvent être des fichiers et donc on se retrouve régulièrement à utiliser .PHONY. C’est pratique mais ça ne me semble pas très élégant.

2. Justfile

			
BINNAME := "hellojust"
# Compile le binaire
build:
    gcc -o {{BINNAME}} main.c
    ./gen_assets.sh
# Supprime les fichiers générés
clean:
    rm -f {{BINNAME}}
# Exécute les tests
test:
    ./tests.sh

		

La syntaxe reste très proche d’un Makefile. En terme de possibilité, il n’y a pas de dépendances sur les fichiers pour exécuter (ou non) une commande.

3. Taskfile.yml

			
version: &apos3&apos
vars:
  BINNAME: hellotask
tasks:
  build:
    desc: Compile le binaire
    cmds:
      - gcc -o {{.BINNAME}} main.c
      - ./gen_assets.sh
  clean:
    desc: Supprime les fichiers générés
    cmd: rm -f {{.BINNAME}}
  test:
    desc: Exécute les tests
    cmd: ./tests.sh

		

Le format YAML permet de faire des listes ou de laisser sur une seule ligne s’il n’y a qu’une seule instruction (cf. cmd). L’ensemble des attributs rend le contenu assez explicite. Il n’y a pas de dépendances sur les fichiers (comme just).

C. Paramètres à passer à la commande

1. Makefile

Il est possible de fournir une valeur par défaut, modifiable sur la ligne de commande :

			
PORT ?= 8000
staticserver:
	python3 -m http.server $(PORT)

Le résultat dans un terminal :

			
$ make staticserver
python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
[...]
$ make staticserver PORT=8888
python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...

		

2. Justfile

Justfile a des paramètres avec des valeurs par défaut :

			
staticserver port="8000":
    python3 -m http.server {{port}}

Le résultat dans un terminal :

			
$ just staticserver
python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) …
[...]
$ just staticserver 8888
python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) …

		

À noter que just staticserver PORT=8888 provoque une erreur (invalid int value: 'PORT=8888').

3. Taskfile

			
version: &apos3&apos
tasks:
  staticserver:
    vars:
      PORT: &apos{{default "8000" .PORT}}&apos
    cmds:
      - python3 -m http.server {{.PORT}}

		

Le résultat dans un terminal :

			
$ task staticserver
task: [staticserver] python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
[...]
$ task staticserver PORT=8888
task: [staticserver] python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...

		

D. Prise en compte de fichier `.env`

La prise en charge est plus ou moins directe mais rien d’insurmontable.

1. Makefile

Contrairement à just et task, make ne prend pas nativement les fichiers .env en charge. Il suffit d’ajouter ces lignes en début de fichier pour que le fichier .env soit chargé :

			
# Chargement du fichier .env
ifneq (,$(wildcard ./.env))
    include .env
    export
endif

		

C’est simplement du code valide pour make : ici, la fonction wildcard permet de détecter l’existence du fichier .env. La directive include charge le fichier donc les données du fichier .env deviennent disponibles comme variables dans le Makefile. La directive export passe l’ensemble des variables en tant que variables d’environnement aux commandes exécutées par le Makefile.

C’est plus simple pour just et task car le chargement de fichiers d’environnement est déjà intégré aux outils.

2. Justfile

Il suffit d’activer l’usage de fichier .env puis de récupérer la variable d’environnement souhaitée :

			
set dotenv-load
port := env("PORT", "8000")

La variable port dans just vaudra ce que contient la variable d’environnement PORT si elle est disponible, sinon elle vaudra 8000.

3. Taskfile 

Il est possible de définir plusieurs fichiers qui écrasent leurs valeurs selon l’ordre de leur définition :

			
dotenv:
  - .env.local # config locale (priorité la plus haute)
  - [...]
  - .env # fichier par défaut (priorité la plus faible)

La variable d’environnement PORT définie (ou redéfinie) par le fichier d’environnement de plus grande priorité sera disponible via $PORT.

E. Lister les commandes disponibles

Cette possibilité est disponible nativement pour just et task :

just --list utilise le commentaire situé au-dessus de la commande.
task --list utilise la valeur de desc si elle est disponible pour documenter la commande.

L’usage est visible dans les exemples de la section « B. Exemples équivalents ».

Pour make, cela devrait être possible avec --print-targets dans le futur lorsqu’une nouvelle version sera publiée.

En attendant, il faut écrire une cible dédiée. Par exemple :

			
help: ## Montre les commandes disponibles
	@echo "Commandes disponibles :"
	@grep -E &apos^[a-zA-Z_-]+:.*?##&apos $(MAKEFILE_LIST) | \
		sort | \
		awk &aposBEGIN{FS=":.*?## "}{printf "  %-10s %s\n", $$1, $$2}&apos

		

Cela suppose que l’on a un commentaire qui suit la convention attendue par la cible help :

			
cible: ## viser le centre
	guillaume --tell --vise=pomme

F. Ne pas afficher la commande exécutée

Dans ce cas, seules les sorties standard et d’erreur sont affichées.

make et just utilisent la même astuce : préfixer la commande par @.

task utilise l’attribut silent qui peut être inséré à plusieurs endroits. Une variable d’environnement est aussi disponible.

			
tasks:
  echo:
    cmds:
      - cmd: echo "Print something"
        silent: true

		

Conclusion

Les trois outils ont des capacités non abordées dans cet article. J’ai l’impression que les cas d’usage entre just et task se recoupent complètement.

make est le choix classique avec la barrière à l’entrée la plus faible pour entrer sur une base de code. Cependant, si just ou task est déjà installé pour développer des services web par exemple, autant le mettre partout.

Entre les deux, j’ai une préférence pour just qui est moins verbeux. La popularité des deux projets est grandissante mais just a l’air de prendre l’avantage :

Comparaison des étoiles Github au 7 juin 2026

Actuellement :

just a 32,4 k★
task a 15,7 k★

Les restes

Versions utilisées pour l’article :

make 4.4.1
just 1.50.0
task 3.41.0

Un serveur HTTP de fichiers statiques est vraiment fourni avec Python : la commande python3 -m http.server est fonctionnelle. C’est pratique pour du réseau local mais une mauvaise idée en production.

Le graphique montrant l’évolution des étoiles Github a été téléchargé depuis https://www.star-history.com/?repos=go-task%2Ftask%2Ccasey%2Fjust&type=timeline&legend=top-left. Le service permet aussi de télécharger un fichier .csv si besoin.

07 June, 2026 06:27PM by ascendances

May 24, 2026

Vincent Bernat

Partitionner une table de routage pour des lectures sans verrou en Go

Pour associer des informations de routage, telles que les chemins d’AS ou les communautés BGP, aux flux, Akvorado peut importer des routes via le BGP Monitoring Protocol (BMP). Comme la table de routage Internet contient plus d’un million de routes, Akvorado doit gérer des dizaines de millions de routes¹. C’est un défi de longue date², mais je pense que ce problème est désormais résolu grâce au sharding de la RIB, une méthode qui découpe la base de routage en plusieurs parties afin de permettre les mises à jour concurrentes.

Implémentation précédente

Akvorado associe deux éléments pour construire sa RIB :

un arbre de préfixes et
une liste de routes attachée à chaque préfixe.

Implémentation de la RIB BMP d'Akvorado avant le sharding, avec la disposition mémoire de chaque structure et un unique verrou.

Dans le diagramme ci-dessus, la RIB stocke cinq préfixes IPv4 et deux préfixes IPv6. L’un d’eux, 2001:db8:1::/48, contient trois routes :

depuis le pair 3, via 2001:db8::3:1, AS 65402, chemin d’AS 65402, communauté 65402:31 ;
depuis le pair 4, via 2001:db8::4:1, mêmes ASN, chemin d’AS et communauté ;
depuis le pair 5, via 2001:db8::5:1, AS 65402, chemin d’AS 65401 65402, communauté 65402:31.

La structure rib est définie en Go de la manière suivante :

type rib struct {
    tree          *bart.Table[prefixIndex]
    routes        map[routeKey]route
    nlris         *intern.Pool[nlri]
    nextHops      *intern.Pool[nextHop]
    rtas          *intern.Pool[routeAttributes]
    nextPrefixID  prefixIndex
    freePrefixIDs []prefixIndex
}

L’arbre de préfixes s’appuie sur le paquet bart, une adaptation de l’algorithme ART de Donald Knuth. Les benchmarks montrent qu’il surpasse les autres implémentations pour les recherches, les insertions et la consommation mémoire³. De plus, l’auteur est d’une grande aide.

Stocker les routes dans une table associative

La liste des routes de chaque préfixe n’est pas stockée directement dans l’arbre de préfixes : cela mettrait trop de pression sur le ramasse-miettes en allouant un tableau par préfixe.

À la place, la RIB attribue un identifiant de 32 bits unique à chaque préfixe, soit en prenant le dernier identifiant disponible dans le tableau freePrefixIDs, soit en utilisant la valeur nextPrefixID avant de l’incrémenter. Les routes sont ensuite stockées dans la table associative routes, qui s’appuie en Go sur une structure particulièrement optimisée. Pour récupérer les routes attachées à un préfixe, nous les cherchons un par un dans la table routes via une clef de 64 bits qui combine l’index de 32 bits du préfixe avec l’index de 32 bits représentant la position de la route dans la liste. Akvorado parcourt les routes de la première à la dernière pour trouver la meilleure⁴. Il sait qu’il n’y a plus de route lorsque la clé ne renvoie aucun résultat.

type prefixIndex uint32
type routeIndex uint32
type routeKey uint64

Canonisation des routes

Une route contient un identifiant de pair BGP, un NLRI partiel⁵, le prochain saut et les attributs.

type route struct {
    peer       uint32
    nlri       intern.Reference[nlri]
    nextHop    intern.Reference[nextHop]
    attributes intern.Reference[routeAttributes]
    prefixLen  uint8
}

type nlri struct {
    family bgp.Family
    path   uint32
    rd     RD
}
type nextHop netip.Addr
type routeAttributes struct {
    asn              uint32
    asPath           []uint32
    communities      []uint32
    largeCommunities []bgp.LargeCommunity
}

Pour économiser la mémoire et les allocations, les NLRI, les prochains sauts et les attributs de route sont canonisés : un entier de 32 bits remplace la valeur réelle. Ce mécanisme est antérieur au paquet unique introduit dans Go 1.23. Nous le conservons car ses compromis sont différents :

il utilise un comptage de références explicite plutôt que des pointeurs faibles ;
il fonctionne avec des valeurs non comparables implémentant les méthodes Hash() et Equal()⁶ ;
il utilise des instances explicites pour la canonisation, ce qui se révèlera utile pour le sharding ;
il offre de meilleures performances. Voir par exemple ce benchmark ;
il consomme deux fois moins de mémoire grâce à des références 32 bits plutôt que des pointeurs ;
mais il n’est pas utilisable de manière concurrente.

Qu’est-ce qui pose problème ?

Note

Pour l’AS 12322, nous n’utilisons pas encore BMP⁷. Mais Gerhard Bogner a eu la patience, la disponibilité et les compétences techniques pour m’aider à déboguer ce problème.

Le verrou global en lecture/écriture est le goulot d’étranglement de cette implémentation. Mais pourquoi ? Plusieurs composants utilisent la RIB, chacun avec ses propres contraintes :

Les consommateurs Kafka consultent la RIB pour enrichir les flux avec des informations de routage. Leur nombre est bornée par la somme des partitions Kafka⁸. Akvorado ajuste également ce nombre afin de garantir un export groupé efficace des flux vers ClickHouse. Sur notre installation, la quantité de consommateurs oscille entre 8 et 16. Comme nous voulons observer les données récentes le plus tôt possible, nous ne pouvons pas nous permettre que les consommateurs Kafka prennent trop de retard.
Les routeurs surveillés envoient leurs routes via le protocole BMP. À la connexion, ils peuvent envoyer des millions de routes⁹. Après la synchronisation initiale, les mises à jour arrivent en continu et peuvent connaître des pics ponctuels. Le routeur détecte une station BMP bloquée lorsque sa fenêtre TCP est pleine. Dans ce cas, il réinitialise la session. Bien qu’Akvorado dispose d’un important tampon en entrée, il doit appliquer les routes reçues suffisamment vite pour ne pas être considéré comme bloqué.
Quand un pair BGP distant tombe, Akvorado purge les routes associées en parcourant la RIB. Quand un routeur surveillé tombe, Akvorado patiente un peu, mais finit par purger toutes les routes associées.

En résumé : sur une installation chargée, la contention sur le verrou est forte autant pour les lecteurs que pour les écrivains, et aucun des deux ne peut prendre trop de retard.

Sharding de la RIB

Première étape

Pour supprimer le verrou global, la RIB est découpée en plusieurs « shards », chacun gérant un sous-ensemble des préfixes :

Implémentation de la RIB BMP d'Akvorado après le sharding, avec la disposition mémoire de chaque structure et un verrou par partition.

L’arbre de préfixes reste global et protégé par un unique verrou. Chaque partition dispose de son propre verrou en lecture/écriture, de sa table de routes et de ses blocs de canonisation pour stocker les NLRI, les prochains sauts et les attributs de route, ce qui n’aurait pas été possible avec le paquet unique de Go. Les index de préfixes sont eux aussi partitionnés : les 8 bits de poids fort correspondent à l’index de la partition et les 24 bits de poids faible à l’index local du préfixe.

Gerhard a confirmé que suite à ce changement à l’aveugle, le composant BMP a commencé à ronronner. 🎉

J’ai ensuite écrit un benchmark portant sur un demi-million de routes synthétiques mais plausibles¹⁰, réparties entre 0 et 8 écrivains qui modifient les routes aussi vite que possible, tandis que 1 à 16 lecteurs consultent en boucle un ensemble de 10 000 routes. J’ignore si ce benchmark est réaliste, mais il confirme les améliorations à la fois sur les latences en lecture et en écriture :

Deux cartes de chaleur. L'une pour le ratio de latence en lecture, l'autre pour celui de la latence en écriture. Toutes deux comparent l'accélération entre le code avant et après le sharding via des cases colorées. La plupart des cases sont vertes.

Il montre également qu’un grand nombre d’écrivains dégrade la latence en lecture.

Deuxième étape

L’unique verrou en lecture/écriture protégeant l’arbre de préfixes constitue la cible suivante. Le paquet bart propose des méthodes alternatives pour les mutations. Elles renvoient un arbre mis à jour via une copie partielle. Les lecteurs n’ont plus besoin du verrou global, qui ne sert plus qu’à synchroniser les écrivains. L’arbre de préfixes est encapsulé dans un pointeur atomique.

Implémentation de la RIB BMP d'Akvorado pour le sharding avec lectures sans verrou, avec la disposition mémoire de chaque structure.

Sans verrou, un lecteur peut désormais récupérer un index de préfixe périmé en parcourant sa copie de l’arbre, lorsqu’un écrivain concurrent supprime la dernière route attachée à cet index et le recycle pour un autre préfixe. Pour éviter ce problème, nous combinons l’index de préfixe avec un numéro de génération que nous stockons dans l’arbre :

type generation uint32
type prefixRef struct {
    idx prefixIndex
    gen generation
}
type rib struct {
    mu     sync.Mutex
    tree   atomic.Pointer[bart.Table[prefixRef]]
    shards []*ribShard
}

Chaque partition stocke le numéro de génération de chaque index de préfixe local. Ce numéro est incrémenté quand l’index de préfixe associé est libéré. Lors de la recherche des routes attachées à un index de préfixe, le lecteur vérifie que le numéro de génération correspond. Sinon, il considère que l’index a été recyclé et que la liste de routes est vide¹¹. Le schéma précédent illustre ce cas pour l’index de préfixe 5, stocké avec un numéro de génération de 3, alors que la valeur actuelle dans le tableau []generations est 4. Le numéro de génération peut boucler, mais ce n’est pas un problème car les recherches sont rapides.

L’exécution du benchmark sur cette nouvelle implémentation montre les améliorations sur la latence en lecture ainsi qu’en écriture dès que le coût de la copie partielle de l’arbre de préfixes est amorti.

Six cartes de chaleur. Trois pour le ratio de latence en lecture, trois autres pour celui de la latence en écriture. Elles comparent par paires les valeurs sans sharding, avec sharding, et avec lectures sans verrou. Pour la latence en lecture, la plupart des cases sont vertes, ce qui traduit l'amélioration apportée par la seconde étape. Pour la latence en écriture, l'accélération est négative pour un faible nombre de lecteurs.

Parmi les nombreuses tentatives d’optimisation du composant BMP, le sharding de la RIB est l’une des plus satisfaisantes. Akvorado 2.2 implémente la première étape. La PR #2433, rédigée pendant l’écriture de ce billet, implémente la seconde et est sortie avec Akvorado 2.4. 🪓

Chaque routeur exportant des flux n’a pas besoin d’envoyer ses routes. Quand Akvorado ne trouve pas de route pour un équipement donné, il se rabat sur une route envoyée par un autre équipement. C’est à l’opérateur de juger si cette approximation est acceptable. ↩
J’ai effectué de nombreuses tentatives pour augmenter l’efficacité du composant BMP. Voir par exemple les PR #254, PR #255, PR #278, PR #2244 et PR #2245. Malgré ces efforts, ce composant est resté problématique pour certains utilisateurs. Voir la discussion #2287 comme exemple le plus récent. ↩
Cela continue de s’améliorer : bart 0.28.0 introduit une implémentation alternative qui troque un peu de mémoire contre de meilleures performances en recherche. Je ne l’ai pas encore essayée car cela fait déjà quelques mois que je prépare ce billet. ↩
Akvorado préfère la route dont le prochain saut correspond exactement. Sinon, il se rabat sur n’importe quelle autre route. C’est une approximation. Une alternative consisterait à maintenir un arbre de préfixes par pair BGP, mais il faudrait alors configurer tous les routeurs pour qu’ils exportent leurs routes. Le démon BMP de pmacct adopte cette approche. ↩
Si nous considérons la RIB BGP comme une base de données, le NLRI (Network Layer Reachability Information) en constitue la clé primaire. Son contenu dépend de la famille BGP. Pour IPv4 ou IPv6 unicast, il s’agit du préfixe. Pour les familles VPNv4 et VPNv6, il inclut le route distinguisher. Si l’extension ADD-PATH est activée, le NLRI contient également un identifiant de chemin.

Dans notre implémentation, nous ne stockons pas le préfixe : nous le reconstituons à partir de l’adresse IP recherchée et de la longueur de préfixe stockée séparément. ↩
Les méthodes Hash() s’appuient sur les paquets hash/maphash et unsafe pour une meilleure performance. Voir par exemple la fonction Hash() de la structure nlri. ↩
Bien qu’auteur ou co-auteur des premières RFC liées à BMP depuis 2016 (RFC 7854, RFC 8671, RFC 9069), Cisco n’a pas fourni d’implémentation utilisable dans IOS XR avant la version 24.2.1. Il nous reste encore quelques routeurs à mettre à jour pour activer cette fonctionnalité. ↩
La KIP-932 introduit, dans Kafka 4.2, la notion de groupes partagés pour permettre la consommation coopérative d’une même partition. Akvorado ne la prend pas encore en charge. ↩
BMP peut être configuré pour envoyer les routes de chaque pair BGP avant ou après l’application des politiques entrantes. Dans ce dernier cas, plus d’un million de routes peuvent arriver par transit. BMP peut aussi être configuré pour envoyer la RIB locale, qui ne contient que le meilleur chemin pour chaque préfixe. ↩
Les préfixes sont aléatoires, mais la distribution de leurs tailles et celle des longueurs de chemin AS suivent les données fournies par Geoff Huston. ↩
Une alternative aurait été de réessayer la recherche, mais cela n’aurait pas de sens : la RIB est une structure cohérente à terme et une liste de routes vide est bien un état qui s’est produit récemment. ↩

24 May, 2026 07:00PM by Vincent Bernat

April 26, 2026

Aurélien Jarno

Running upstream OpenSBI on SpacemiT K1

The SpacemiT K1 is a rather interesting RISC-V SoC, found for instance on boards like the Banana Pi BPI-F3 board. It's one of those platforms that looked promising on paper, but took a bit of time before things really started to move upstream. Things have clearly accelerated over the last few months.

Linux 7.0 brings, among other things PCIe support, making the board quite capable as a development board. SD card, CPU thermal sensor and cpufreq support are already in the pipe.

Unfortunately the situation is less advanced on the firmware side. There is only very basic support for the SpacemiT K1 in U-Boot for the second stage, and initial SPL support has been posted on the mailing list, but has not yet been merged. In practice, this means you still have to rely on the vendor U-Boot, which is based on the rather old 2022.10 release.

On the other hand, OpenSBI does have upstream support for the SpacemiT K1, however it is not compatible with the vendor U-Boot, mostly due to device tree differences.

This can be addressed by applying a few patches to the vendor U-Boot, which I have published in a git tree in the k1-bl-v2.2.y-opensbi branch (technically this can also be handled on the OpenSBI side, but I prefer using a vanilla upstream OpenSBI version). The first two patches update the configuration to get closer to the upstream U-Boot defaults, and to enable some configuration options for the Milk-V Jupiter board, which stores its firmware in SPI NOR flash, instead of eMMC for the Banana Pi BPI-F3. The following patches update the device tree by adding extra compatible entries to several devices, as expected by the upstream kernel and OpenSBI (thanks to Troy Mitchell for the hint about the UART change) and update the CPU riscv,isa properties. Finally an additional patch adds the SpacemiT P1 PMIC to the device tree, which is required for the OpenSBI reboot patchset I recently posted (this is currently done only for the Banana Pi BPI-F3 and Milk-V Jupiter boards, but extending it to other boards should be straightforward) [Update: This patchset is included in OpenSBI v1.9].

Building this U-Boot version is as simple as running this command in the source directory:

make k1_defconfig && make

On a Banana Pi BPI-F3 board, the resulting U-Boot can be flashed with:

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=FSBL.bin of=/dev/mmcblk0boot0 bs=512 seek=1
dd if=u-boot.itb of=/dev/mmcblk0p1

Building upstream OpenSBI is also fairly simple, and can be done by running this command in the source directory:

make PLATFORM=generic

On a Banana Pi BPI-F3 board, the resulting OpenSBI can be flashed with:

dd if=fw_dynamic.itb of=/dev/mmcblk0p2

Note that the vendor U-Boot version is patched to install OpenSBI in a separate partition instead of embedding, as the upstream U-Boot does. While this works well on the Banana Pi BPI-F3, the corresponding partition in the Milk-V Jupiter SPI NOR flash is too small for the upstream OpenSBI version, and can't be easily resized without breaking compatibility. To address this, the branch k1-bl-v2.2.y-opensbi-embedded contains an additional patch (a bit hackish I admit) to somehow restore the upstream approach. The build process remains simple, first build OpenSBI with the following command:

make PLATFORM=generic

Then build U-Boot, specifying the patch to the just built OpenSBI firmware:

make k1_defconfig && make OPENSBI=/path/to/opensbi/build/platform/generic/firmware/fw_dynamic.bin

On a Milk-V Jupiter board, the resulting combined U-Boot/OpenSBI can be flashed with:

modprobe mtdblock
dd bs=4k if=FSBL.bin of=/dev/mtdblock2
dd bs=4k if=u-boot.itb of=/dev/mtdblock5

This combined U-Boot/OpenSBI can also be used on a Banana Pi BPI-F3, using the same flashing procedure as above, while skipping the OpenSBI part (although running it won't cause any issue, it will simply be unused).

All of this is admittedly a bit hackish, but enabling the use of upstream OpenSBI is already one step forward. Hopefully, in a few months, we will be able to rely entirely on upstream U-Boot.

26 April, 2026 12:13PM by aurel32

April 22, 2026

Vincent Bernat

CSS & rythme vertical pour le texte, les images et les tableaux

Le rythme vertical structure les lignes selon un espacement régulier de haut en bas. Il permet de guider l’œil de manière fluide et prévisible. Grâce à l’unité CSS rlh, ce rythme est simple à mettre en place pour le texte¹. Mais les illustrations et les tableaux peuvent perturber la mise en page. Le typographe amateur en moi aspire à suivre la sagesse de Bringhurst :

Les titres, intertitres, citations, notes de bas de page, illustrations, légendes et autres intrusions dans le texte créent des syncopes et des variations par rapport au rythme de base d’un interlignage régulier. Ces variations peuvent et doivent animer la page, mais le texte principal doit également reprendre, après chaque variation, précisément la mesure et la phase.

― Robert Bringhurst, The Elements of Typographic Style

Pour le texte

Trois facteurs régissent le rythme vertical : la taille de police, la hauteur de ligne et la marge ou le remplissage. Posons la base avec une police de 18 pixels et une hauteur de ligne de 1,5 :

html {
  font-size: 112.5%;
  line-height: 1.5;
}
h1, h2, h3, h4 {
  font-size: 100%;
}
html, body,
h1, h2, h3, h4,
p, blockquote,
dl, dt, dd, ol, ul, li {
  margin: 0;
  padding: 0;
}

Le CSS Values and Units Module Level 4 définit l’unité rlh, égale à la hauteur de ligne de l’élément racine. Tous les navigateurs la gèrent depuis 2023². Utilisez-la pour insérer des espaces verticaux ou corriger la hauteur de ligne quand la taille de police change³ :

h1, h2, h3, h4 {
  margin-top: 2rlh;
  margin-bottom: 1rlh;
}
h1 {
  font-size: 2.5rem;
  line-height: 2rlh;
}
h2 {
  font-size: 1.5rem;
  line-height: 1rlh;
}
h3 {
  font-size: 1.25rem;
  line-height: 1rlh;
}
p, blockquote, pre {
  margin-top: 1rlh;
}
aside {
  font-size: 0.875rem;
  line-height: 1rlh;
}

Vérifions le résultat en superposant une grille⁴ au-dessus du texte :

Capture d'écran de mon site avec une grille en superposition et chaque ligne de texte alignée sur la grille

Si un sous-élément utilise une police aux métriques intrinsèques plus hautes, il peut étirer la boîte de la ligne au-delà de la hauteur configurée⁵. Une astuce consiste à ramener la hauteur de ligne à 1. Les glyphes débordent mais ne poussent pas la ligne plus haut.

code, kbd {
  line-height: 1;
}

Pour les images adaptatives

Les images adaptatives, dont la taille s’ajuste à la largeur de l’affichage, sont difficiles à aligner sur la grille car leur hauteur nous est inconnue. Le CSS Rhythmic Sizing Module Level 1 introduit la propriété block-step pour ajuster la hauteur d’un élément à un multiple d’une unité de pas. Cependant, la plupart des navigateurs ne la gèrent pas encore.

Avec JavaScript, nous pouvons ajouter un remplissage autour de l’image pour qu’elle ne perturbe pas le rythme vertical :

const targets = document.querySelectorAll(".lf-media-outer");
const adjust = (el, height) => {
  const rlh = parseFloat(getComputedStyle(document.documentElement).lineHeight);
  const padding = Math.ceil(height / rlh) * rlh - height;
  el.style.padding = `${padding / 2}px 0`;
};

targets.forEach((el) => adjust(el, el.clientHeight));

Capture d'écran de mon site avec une grille en superposition et une image qui ne rompt pas le rythme vertical. Un remplissage supplémentaire est visible avant et après l'image. La hauteur de l'image avec son remplissage est de 216.

Comme l’image est adaptative, sa hauteur peut varier. Il faut appeler la fonction adjust() dans un observateur :

const ro = new ResizeObserver((entries) => {
  for (const entry of entries) {
    const height = entry.contentBoxSize[0].blockSize;
    adjust(entry.target, height);
  }
});
for (const target of targets) {
  ro.observe(target);
}

Pour les tableaux

Les cellules d’un tableau pourraient fixer leur hauteur à 1rlh mais paraîtraient à l’étroit. Passer à 2rlh gaspille trop d’espace. À la place, nous utilisons l’interligne incrémental : une ligne sur cinq est alignée sur la grille.

table {
  border-spacing: 2px 0;
  border-collapse: separate;
  th {
    padding: 0.4rlh 1em;
  }
  td {
    padding: 0.2rlh 0.5em;
  }
}

Pour aligner les éléments après le tableau, il faut ajouter un peu de remplissage. Nous pouvons soit réutiliser le code JavaScript des images, soit utiliser quelques lignes de CSS qui comptent les lignes régulières et calculent le remplissage vertical manquant :

table:has(tbody tr:nth-child(5n):last-child)   { padding-bottom: 0.2rlh; }
table:has(tbody tr:nth-child(5n+1):last-child) { padding-bottom: 0.8rlh; }
table:has(tbody tr:nth-child(5n+2):last-child) { padding-bottom: 0.4rlh; }
table:has(tbody tr:nth-child(5n+3):last-child) { padding-bottom: 0 }
table:has(tbody tr:nth-child(5n+4):last-child) { padding-bottom: 0.6rlh; }

Une cellule d’en-tête a deux fois le remplissage d’une cellule régulière. Avec deux lignes régulières, le remplissage total vaut 2×2×0,2+2×0,4=1,6. Il faut ajouter 0.4rlh pour atteindre 2rlh de remplissage vertical supplémentaire autour du tableau.

Capture d'écran de mon site avec une grille en superposition et un tableau suivant le rythme vertical. Un remplissage supplémentaire est visible après le tableau. La hauteur du tableau avec son remplissage est de 405.

Rien de tout cela n’est indispensable, mais une fois l’œil entraîné, il devient difficile de ne plus le remarquer. En attendant que les navigateurs implémentent le CSS Rhythmic Sizing, un mélange de de bidouilles CSS et d’un peu de JavaScript suffit. Le texte principal reprend désormais après chaque intrusion « précisément la mesure et la phase ». 🎼

Voir « Vertical rhythm using CSS lh and rlh units » par Paweł Grzybek. Précédemment, une bonne référence était « Scale & Rhythm » de Iain Lamb. ↩
Pour une meilleure compatibilité, remplacez 2rlh par calc(var(--line-height) * 2rem) et définissez la propriété --line-height dans la pseudo-classe :root. J’ai écrit un petit greffon PostCSS à cet effet. ↩
Il aurait été plus élégant de calculer la hauteur de ligne avec calc(round(up, calc(2.4rem / 1rlh), 0) * 1rlh). Cependant, l’arithmétique typée n’est pas encore implémentée par Firefox. De plus, les navigateurs ne gèrent round() que depuis 2024. J’ai donc codé un autre greffon PostCSS pour cela. ↩

Ce code CSS définit une grille qui suit la hauteur de ligne :

body {
  position: relative;
}
body::after {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 9999;
  background: linear-gradient(180deg, #c8e1ff99 1px, transparent 1px);
  background-size: 20px 1rlh;
  pointer-events: none;
}

↩

Voir « Deep dive CSS: font metrics, line-height and vertical-align » par Vincent De Oliveira. ↩

22 April, 2026 07:48PM by Vincent Bernat

February 11, 2026

Louis-Philippe Véronneau

Contrecœur, Ray-Mont, les conteneurs et nous

Voici un texte que j'ai écris pour un numéro à paraître du journal Résister et fleurir. J'écris rarement en français sur mon blog (qui est principalement destiné à un auditoire international), mais cela m'arrive quand même parfois!

Annoncé pour la première fois en 2014, le projet d'expansion du Port de Montréal à Contrecœur a fait couler beaucoup d'encre dans les dernières années.

En effet, il est certain que les travaux en eau et la construction du nouveau terminal portuaire causeront des dommages environnementaux irréparables — pensons notamment au chevalier cuivré, qui verra son habitat essentiel saccagé. Cependant, ce projet soulève également des questions importantes quant à sa viabilité économique et à l'avenir des installations portuaires dans la grande région de Montréal.

Un contexte économique mondial qui a changé

Si le projet de Contrecœur pouvait avoir un certain sens pour les acteurs économiques lorsqu'il a été lancé en 2014, force est de constater que le contexte économique mondial a depuis changé. En effet, le Port de Montréal vit deux pressions qui fragilisent sa place comme acteur portuaire de premier plan en Amérique du Nord.

Premièrement, les chaînes d'approvisionnement internationales ont été fortement perturbées en 2019 à la suite de la pandémie et le commerce international ne s'en est jamais totalement remis. En effet, cet événement majeur a mis en lumière la fragilité de nos économies et beaucoup de pays ont compris le danger de dépendre (parfois substantiellement) de pays étrangers pour leurs besoins de base, comme l'alimentation.

Avec le retour de Donald Trump aux États-Unis, il est clair que nous vivons présentement la fin du statu quo pro-mondialisation qui régnait depuis les années 80. Si la remise en question de notre partenariat économique avec les États-Unis, dans un élan de diversification économique, aurait pu avoir comme effet l'augmentation des activités portuaires à destination de l'Europe et de l'Asie, il semble pour l'instant que cela n'a pas eu d'effet majeur dans le volume de marchandises transitant par le Port de Montréal.

Évolution du volume de marchandises transporté par le Port de Montréal

En second lieu, le Port de Montréal ne répond plus aux standards internationaux en terme d'infrastructures maritimes, principalement à cause du niveau d'eau insuffisant dans le fleuve à la hauteur de Montréal. Tel que noté dans un rapport scientifique récent demandé par la Société pour la nature et les parcs du Canada – section Québec (SNAP-Québec) :

« Le tirant d'eau du fleuve Saint-Laurent, qui atteint au maximum environ 11 mètres, limite l'accès à des navires de 4 500 EVP¹. Pour rivaliser avec les ports de Halifax ou de New York, il faudrait pouvoir accueillir des navires d'au moins 5 500 à 6 000 EVP. Cette contrainte physique ne peut pas être levée sans un dragage majeur. »

Ainsi, alors que le Port est limité à des navires de 4 500 EVP, ces bateaux ne forment plus que 30 % de la capacité mondiale de transport maritime. En effet, les plus gros bateaux, de classe Ultra Large Container Vessels, peuvent désormais transporter plus de 18 000 EVP.

Tel que présenté dans le graphique ci-dessous, l'effet conjoint de ces deux pressions cause une diminution marquée du volume de marchandises conteneurisées et une stagnation de celui des marchandises solides transitant par le Port de Montréal.

Un transfert de capacité plutôt qu'une augmentation nette

Quand on comprend le contexte économique dans lequel s'inscrit ce projet, les travaux à Contrecœur peuvent sembler étonnants. Si le nombre de conteneurs est au mieux appelé à rester stable dans les prochaines années, pourquoi le Port de Montréal souhaite-il augmenter sa capacité de près de 60 % ?

Dans le rapport de la SNAP-Québec mentionné plus haut, les chercheurs Henri Chevaliers et Éric Pineault avancent une piste de solution : l'administration portuaire s'est trompée dans ses calculs et le projet est déjà trop avancé pour revenir en arrière.

Bien que crédible, cette analyse paraît tout de même sommaire. Et si, plutôt que d'envisager le projet à Contrecœur comme une manière d'augmenter son volume de marchandises, le Port de Montréal souhaitait plutôt ... y déplacer une partie de sa capacité ?

Selon son rapport annuel 2024, 37 % des coûts totaux du Port sont des dépenses en main-d'œuvre. Pire encore, ces coûts sont la seule variable opérationnelle que l'entreprise ne contrôle pas directement. En effet, si elle peut continuer à investir des capitaux pour optimiser ses infrastructures, le rapport de force du Syndicat des débardeurs, bien connu pour être très combatif, rend le contrôle des coûts de main-d'œuvre complexe et imprévisible. Les grèves de 10 jours en 2020, 5 jours en 2022 et de 4 jours en 2024 lui ont causé des ennuis financiers importants, en plus de nuire à sa valeur réputationnelle à l'international.

Pour éviter ce genre de désagrément, il est fort probable que le nouveau terminal de Contrecœur soit presque entièrement automatisé. En procédant de la sorte, le Port réduirait fortement ses besoins en main‑d'œuvre et augmenterait son rapport de force face au Syndicat des débardeurs, grâce à la menace de déplacer toujours plus de capacité vers des installations ne requérant pas leurs services.

Sans Contrecœur, ce projet d'automatisation des installations du Port de Montréal serait difficilement réalisable. En effet, d'un point de vue technique, ce dernier doit continuer ses opérations et doit s'assurer de respecter ses contrats de manutention. Automatiser ses terminaux existants à Montréal serait l'équivalent de remplacer un moteur d'avion en plein vol : possible, mais techniquement complexe et donc particulièrement coûteux. De plus, la machinerie nécessaire pour opérer un tel terminal automatisé augmenterait grandement les nuisances sonores et visuelles, nuisances déjà souvent intolérables pour le voisinage...

Notons cependant que l'ouverture d'un nouveau terminal à Contrecœur n'entraînera pas la fin des activités du Port à Montréal, même à moyen ou à long terme. En effet, certains clients industriels comme Sucre Lantic ou Lallemand sont des partenaires du Port de très longue date et lui assurent une stabilité opérationnelle importante. Les infrastructures de ces clients sont fortement intégrées aux activités portuaires à Montréal et il serait impensable d'envisager leur déplacement.

Finalement, en libérant de l'espace sur ses quais à Montréal, le Port pourrait continuer d'améliorer ses infrastructures pour les bateaux de croisière, un secteur qui, malgré ses répercussions environnementales souvent désastreuses, a connu une croissance mondiale de 16 % depuis 2019.

Ray-Mont Logistiques, entre l'arbre et l'écorce

Qu'en est-il donc de Ray-Mont Logistiques dans tout cela ? À la lumière de cette analyse, en restant à Montréal, Charles Raymond risque littéralement de « manquer le bateau » et d'être pris avec des infrastructures portuaires moins intéressantes que celles auxquelles il pourrait avoir accès à Contrecœur.

Comme les investissements de l'entreprise sur le site d'Assomption Sud sont encore pour l'instant minimales en comparaison avec son projet final de phase 2 (augmentation importante de la surface asphaltée, chemins de fer, élévateurs à grain, infrastructures d'ensachement, etc.), il est encore le temps pour elle de lever l'ancre.

De plus, la réglementation en place limitant ses heures d'opération de 7h du matin à 19h le soir est une épine majeure dans son pied et freine ses perspectives rentabilité futures.

Le déménagement de RML serait cependant une victoire en demi-teinte, car elle ne réglerait pas le problème de fond de l'industrialisation croissante de nos environnements et pérenniserait la destruction des écosystèmes marins et terrestres à Contrecœur.

Il semble donc clair que notre stratégie de perturbation des activités de Ray-Mont Logistiques — tant sur le terrain qu'au niveau des différentes instances gouvernementales — fonctionne et est plus importante que jamais. Chaque retard dans les travaux menant à la phase 2 sera une occasion supplémentaire pour cette entreprise de fermer boutique et d'accepter que le site choisit dans Hochelaga, ne lui appartiendra jamais réellement.

De Viauville à Contrecœur, en passant par la forêt magique de Pointe-Aux-Père et la Grande Tourbière de Blainville, faisons-leur comprendre que nos espaces de vie ne sont pas à vendre, car en définitive, ils n'appartiennent à personne.

« Équivalent vingt pieds », une mesure standard de la capacité en conteneurs. ↩

11 February, 2026 06:46PM by Louis-Philippe Véronneau

December 20, 2025

Carl Chenet

Le travail en profondeur (deep work)

Le travail en profondeur (deep work en anglais) est l’énorme oublié de l’activité sur site. Étant donné l’organisation actuelle des bureaux, il n’est aujourd’hui possible (quasiment) qu’en télétravail.

Pour rappel, le travail en profondeur s’incarne dans des plages de temps de travail ininterrompues, de 1h à 4h. Vous commencez à voir le problème.

Impossible de se concentrer dans un open space. Les discussions au téléphone incessantes vous en empêchent. Des réunions démarrent tous les demi-heures, parfois tous les quarts d’heure, et viennent briser votre concentration.

Entre les deux, des collègues discutent de différents projets, mais aussi de la pluie et du beau temps sous votre nez, vous interpellent directement s’ils ont une question, perturbant les calculs complexes que vous étiez laborieusement en train d’essayer de mener à leur terme.

À midi, c’est le grand départ, des groupes se joignent, il faut courir pour manger avec untel ou unetelle, ou on vient vous chercher sans vergogne à votre bureau, sans se soucier du rythme de travail qui est nécessaire pour mener à bien votre étude en cours.

Bien sûr, tous les métiers n’ont peut-être pas besoin de travail en profondeur. Les métiers réactifs, ou on se met en avant en réagissant à tout ce qui se passe dans l’entreprise (et souvent à rien), sont ceux qui permettent d’être le plus visible et donc de se mettre en avant. Mais beaucoup le nécessitent. Le développement d’applications, la conception d’architecture complexe, et sûrement beaucoup d’autres demandent un travail en profondeur pour être mené à bien et dans les meilleures conditions.

Et vous ? Comment gérez-vous vos plages de travail en profondeur ? Vous y arrivez sur site ou vous attendez vos jours de télétravail ? Dites moi tout en commentaires

L’auteur

Je suis architecte infrastructure cloud (AWS et Azure) senior freelance, adepte du télétravail et du travail en profondeur, et conçois les infrastructures dont vous avez besoin pour faire tourner les services IT de vos entreprises. Disponible pour une nouvelle mission dès mi-janvier 2026. N’hésitez pas à me contacter si je peux vous aider dans vos projets.

20 December, 2025 01:08PM by Carl Chenet

September 18, 2025

Louis-Philippe Véronneau

Compte-rendu de livre: Santé Inc. Mythes et faillites du privé en santé d'Anne Plourde

Voici un texte que j'ai écris pour le numéro de septembre 2025 de mon journal syndical. J'écris rarement en français sur mon blog (qui est principalement destiné à un auditoire international), mais cela m'arrive quand même parfois!

Introduction

Dès l'introduction, Plourde annonce ses couleurs: ce livre s'adresse aux personnes qui croient en un système de santé universel, mais qui doutent de la capacité du système public d'y arriver.

Dans ce livre, cette dernière s'attaque plus particulièrement à « la 'Santé Inc.', et donc aux entreprises (qu'il s'agisse de grandes multinationales ou d'entrepreneurs indépendants) qui mènent leurs activités dans l'objectif d'en tirer un profit - ce qu'on appelle communément le secteur privé à but lucratif. » (p.14-15)

Le livre est divisé en 5 chapitres, qui abordent chacun un mythe.

A picture of the book cover

Faillite 1: Le privé en santé échoue depuis un siècle

Mythe: le système de santé est essentiellement public, le privé est une nouveauté.

Ce chapitre aborde l'histoire du système de santé au Québec. Plourde affirme ainsi qu'à partir du XX^e^ siècle, les avancées de la médecine font en sorte que les hôpitaux deviennent de réels lieux de soins (plutôt que des lieux de prise en charge des 'indigents')

En effet, mis à part la tranche de population très pauvre pour qui les soins sont gratuits, la forte majorité des gens n'ont pas accès aux soins pour des raisons financières.

À partir des années 1930, les syndicats réussissent à gagner la mise en place d'assurances privées sur les milieux de travail. Ce gain initial s'avère en fait être un échec, car les progrès de la médecine s'accompagnent d'une explosion des coûts, que les assurances collectives ont bien de la misère à assumer.

À partir des années 1950, ce système ne fonctionne plus (il n'a jamais réellement fonctionné...) et même les hôpitaux se montrent ouverts à la création d'une assurance publique universelle.

Plourde brosse un portrait des services offerts à cette époque et démontre qu'en fait, que ce soit à cause des coûts ou à cause de la présence de déserts médicaux dans les quartiers et régions rurales jugées non rentables par le privé, seuls les riches ont accès aux services de santé.

C'est dans ce contexte qu'en 1971 la commission Castonguay-Nepveu propose la mise en place d'une assurance publique et universelle:

« [...] la commission Castonguay-Nepveu recommandait non seulement l'adoption d'une assurance maladie publique et universelle, mais également la nationalisation de l'ensemble des services de santé et des services sociaux et leur intégration dans un système entièrement public. » p.29

L'État crée donc les CLSC, dans une optique de soins publics, démocratiques et holistiques. En plus d'offrir des soins de santé, ces derniers reçoivent comme mandat l'inclusion démocratique des patient·e·s dans le réseau de santé ainsi que la lutte contre les enjeux de santé causés par des facteurs comme la malnutrition, la pollution, l'insalubrité des logements, etc.

Les nouveaux CLSC sont cependant mis à mal par le refus des médecins d'abandonner leur statut de travailleurs autonomes et de devenir salarié·e·s. Suite à d'intenses campagnes de lobbying, l'État accepte finalement qu'ils restent la seule catégorie de travailleuses et de travailleurs de la santé à avoir des cabinets privés tout en pouvant bénéficier d'un financement public. Cette condition vient cependant avec l'impossibilité de travailler au privé.

Les autres catégories de professionnel·le·s de la santé (psychologues, dentistes, etc.) peuvent cependant continuer de recevoir du financement privé, ce qui permet la survie des assurances privées. En effet, à l'instar de la commission Parent, la commission Castonguay-Nepveu croit qu'il est plus stratégique d'augmenter graduellement la couverture des soins de santé à travers les années pour tenter de minimiser le choc fiscal initial. Cela n'arrivera toutefois jamais.

Ploudre démontre ainsi que le pourcentage des dépenses privées des ménages dans le total des dépenses de santé au Québec a en fait augmenté depuis les années 70. En 2021, un ménage moyen dépensait 2897$ en soins privés, pour un total de 19,4 milliards de dollars (25,8% du budget total public-privé en santé). Ce pourcentage en 1970 était d'environ 20%.

Preuve de la faillite des CLSC, de nos jours, seul 15% des médecins de famille y pratiquent. La forte majorité travaillent ainsi dans des cliniques privées, les GMF.

La conclusion de ce chapitre est donc que le privé ne peut pas sauver le réseau de la santé, car il n'a jamais réellement été chassé du réseau!

Faillite 2: Le privé en santé échoue à réduire les coûts

Mythe 2: le privé coûte moins cher

« Cela est vrai tant pour le financement privé que pour la prestation privée des services » p.46

L'auteure affirme qu'un problème majeur du régime québécois est le régime privé d'assurance médicaments, qui entraîne la multiplication des frais de gestion et brise le pouvoir de négociation collectif dont jouirait un régime public et universel. Pire encore, il laisse au public les cas les plus coûteux (soit les pauvres, qui sont statistiquement plus malades que les riches).

De plus, Plourde note que le marché privé vise le profit et non la promulgation de soins. Quand le rapport de force des entreprises est important, les prix montent:

« Ainsi, en pleine crise de santé mentale, les tarifs suggérés par l'Ordre des psychologues du Québec en 2023 étaient 50% plus élevés que ce qui était affiché sur le site en 2021. » p.49

Plourde affirme également que lorsque le privé arrive à réaliser certains actes à coûts plus faibles que le public, c'est parce qu'il rogne sur les conditions de travail et sur la qualité des services, deux choses qui ne sont pas désirables.

À son avis, un facteur majeur dans l'augmentation des coûts en santé est le fait que les médecins accaparent une partie très importante du budget de la santé au Québec:

« Alors que les médecins ne représentaient que l'équivalent de 6% des effectifs du réseau, cette profession accaparait à elle seule 15% des dépenses totales du MSSS en 2021-2022. La même année, les autres employé·e·s du réseau public, qui constituent donc 94% des effectifs, ont reçu une rémunération totale équivalent à moins de 30% des dépenses du MSSS.

La rémunération individuelle moyenne des médecins est de près de 400 000$ par année, ce qui est 6,4 fois plus élevé que la rémunération moyenne des autres employé·e·s du réseau, et 8,2 fois plus que le revenu d'emploi moyen de l'ensemble des travailleuses et travailleurs du Québec. » p.61

Plourde termine le chapitre en démontrant que les expériences faites sur les coûts en clinique privée au Québec et ailleurs au Canada démontrent systématiquement que le privé coûte substantiellement plus cher.

Faillite 3: Le privé en santé échoue à être efficace

Mythe 3: le privé est plus efficace

« la Commission Castonguay-Nepveu ne s'est pas contentée de recommander la nationalisation des services de santé: elle a également recommandé leur démocratisation. » p.73

Lors de la création des CLSC, les conseils d'administration sont formés de patient·e·s et de membres de la communauté. L'idée de démocratisation de la santé est alors explicite:

« Cette petite révolution représentait non seulement une importante perte de pouvoir pour les élites économiques, mais elle offrait aussi à la population des outils pour résister aux assauts que ces mêmes élites n'allaient pas tarder à lancer contre le nouveau système public. » p.74

Malheureusement, cette vision de la santé est mise à mal par l'imposition de pratiques de gestion néolibérales:

« Loin d'améliorer l'efficacité des services, ce processus de déconnexion grandissante avec le terrain aboutit donc, en contradiction complète avec les recommandations de la Commission Castonguay-Nepveu, à la destruction progressive des capacités du réseau à connaître les besoins réels de la population et d'y répondre adéquatement. » p.77

Conséquence de cette déconnexion, cette bureaucratisation accrue fait augmenter les coûts. Plourde affirme par exemple que les gens qui prodiguent des soins à domicile passent près de 70% de leur temps de travail à effectuer des tâches administratives.

« Cette centralisation des pouvoir promue par les nouvelle gestion publique et le milieu des affaires s'accompagne nécessairement d'une bureaucratisation des services, puisque, au fur et à mesure que les gestionnaires détenteurs d'un pouvoir réel s'éloignent du terrain, des mesures de contrôle administratifs de plus en plus lourdes et complexes doivent être développées. Celles-ci prennent par exemple la forme d'exigences de reddition de comptes statistiques auprès du personnel qui dispense les soins et les services. » p.76

Un autre exemple de bureaucratisation du système de santé est le financement à l'acte:

« Durant les années 1980, environ 600 actes pouvaient faire l'objet d'une facturation de la part des médecins auprès de la Régie de l'assurance malade. En une trentaine d'années, ce nombre déjà faramineux est passé à ... 11 000! La gestion de la rémunération médicale est si lourde et si complexe que les médecins eux-mêmes peinent désormais à s'y retrouver dans leur propre facturation et doivent faire appel à des firmes spécialisées pour accomplir ces tâches. » p.80

Pire encore:

« [...] le financement à l'activité a l'avantage considérable de mettre un prix précis sur chaque activité hospitalière et, du même coup, de faciliter leur achat et leur vente (et donc leur privatisation). » p.83

Plourde s'attarde par la suite à prouver l'inefficacité de GMF. Alors que ces cliniques privées ont été créés pour désengorger les urgences en offrant de plus longues plages horaires, cela ne semble pas avoir eu l'effet désiré. En effet, depuis leur création, les GMF n'ont jamais atteint les cibles de prise en charge de patient·e·s imposées par les gouvernements.

Comme les GMF sont incapables (lire: ils refusent) de prendre en charge des patient·e·s dans des plages horaires considérées comme peu attrayantes par les médecins (tard le soir et les fins de semaine), il leur est permis de signer des contrats avec d'autres organismes pour que ces derniers offrent cette prise en charge à leur place. Ainsi:

« En 2022, 41% des GMF avaient convenu de telles ententes et offraient donc une quantité d'heures de services inférieures à celle prévue par le programme GMF. Mais le plus surprenant et le plus choquant, c'est qu'au moins 37% de ces ententes ont été conclues avec les services d'urgence d'un hôpital! » p.87-88

Malgré ces manquants, les GMF continuent néanmoins de recevoir l'ensemble de leur financement.

Autre absurdité de ce système: le Ministère a décidé de 'prêter' gratuitement aux GMF des employé·e·s travaillant dans les CLSC pour combler leurs besoins en services de travail social et en psychologie:

« À partir de 2016, à la suite d'une directive du ministère en ce sens, une quantité grandissante de travailleurs sociaux et de travailleuses sociales ainsi que des psychologues qui pratiquaient jusqu'alors dans les CLSC ont été mis·e·s à la disposition des GMF, gratuitement, par les établissements publics. Officiellement, ces professionnel·le·s restent à l'emploi des établissements publics, mais ils et elles sont placé·e·s sous 'l'autorité fonctionnelle' des médecins de GMF et pratiquent dans leurs locaux. » p. 88

Une conséquence encore plus regrettable de ce système est la perte d'accès à ces services dans les CLSC:

« Ainsi, seules les personnes inscrites auprès d'un médecin de GMF ont accès aux professionnel·le·s qui y sont transféré·e·s par les établissements publics. Or, plus du tiers de la population du Québec n'a toujours pas cette chance. » p.89

Plourde répertorie ainsi une perte de 42% de l'offre de service en travail social (700 000 heures/an) et de 52% en psychologie (60 000 heures/an) dans les CLSC dans les dernières années.

Constatant les problèmes importants des GMF, le gouvernement a par la suite décidé de favoriser la création de super-GMF, qui offrent des services comme des radiographies, des prélèvements et doivent servir en théorie de 'mini-urgences'. Plourde démontre cependant qu'en 2017, 62% de ces groupes n'atteignaient pas le nombre minimal de visites exigées. En 2021, cette proportion était de 82%.

Elle constate finalement que pour tenter de remplir leurs quotas, les médecins de ces super-GMF ont tendance à délaisser leurs propres patient·e·s, qui doivent alors se tourner vers l'urgence ou d'autres super-GMF...

On en comprend donc que le privé n'est pas réellement plus efficace que le public en santé.

Faillite 4: Le privé en santé échoue à désengorger le public

Mythe 4: le privé aide à réduire les listes d'attente dans le public

« [...] dans les faits, le privé est plutôt un compétiteur féroce qui vampirise les ressources du public et réduit sa capacité à répondre aux besoins de la population » p. 95

C'est surtout le cas car la main d'œuvre en santé est finie et que le privé tend donc à 'voler' des travailleuses et des travailleurs qui iraient autrement au public. En général, si le privé arrive à être plus attractif, c'est parce qu'il est en mesure d'offrir de meilleurs salaires que le public et parce qu'il n'a pas besoin d'offrir des services 24h/24 7j/7.

En 1987, près de 60% des personnes dans le domaine de la santé et de l'assistance sociale travaillait au public. En 2019, ce n'était plus le cas que de 50% des travailleurs et travailleuses de ce domaine.

Selon Plourde, cette situation est causée par trois problèmes:

Le désengagement de l'État et les coupures budgétaires
La détérioration des conditions de travail
Le fait que l'État paie plus cher pour un même service offert au privé qu'au public

Cette dernière parle ainsi de 'ponts d'or' du public vers le privé pour décrire cette situation.

« Les difficultés à réduire les listes d'attente pour le type de procédures qui sont privatisées dans ces cliniques ne sont pas causées par des manques d'équipement ou de salles d'opération dans les hôpitaux publics. Elles sont causées par le manque de disponibilité du personnel, problème majeur qui force les hôpitaux à sous-utiliser leurs salles d'opération. » p.104

Face à ces problèmes, l'auteure remet de l'avant le fait que les barrières mises en place pour empêcher que les médecins ne travaillent au privé fonctionnent. En effet, très peu de médecins travaillent au public (~4%) alors qu'au contraire la pratique privé-publique est très populaire chez les physiothérapeutes ou les psychologues. Ces barrières pour empêcher la double pratique devraient donc être graduellement mises en place pour les autres professions, dans une optique de renationalisation des soins.

En effet, alors que de 2010 à 2020 le nombre de psychologues au Québec a augmenté de 5,5%, la crise de l'accessibilité s'est aggravée. Alors qu'en 2010, 28% des psychologues travaillaient dans la santé publique, en 2020, elles et ils n'étaient plus 23% à le faire. Pendant ce temps, la pratique privée a récupéré ces gens.

Plourde termine ce chapitre en mettant en garde contre la télémédecine, qui, n'étant pas offerte au public, est un service qui peut être offert par les médecins sans remettre en cause leur appartenance au réseau public. Elle craint en effet que cette pratique mixte ne prenne de l'ampleur, au profit du privé.

Faillite 5: Le privé en santé échoue à préserver la qualité et l'équité

Mythe 5: le privé améliore la qualité des soins sans nuire à l'équité dans l'accès aux services

« On nous fait croire également que lorsque des personnes mieux nanties paient pour avoir accès plus rapidement aux services dans le secteur privé, elles libèrent de la place dans le secteur public, facilitant ainsi l'accès pour les personnes qui n'ont pas les moyens de payer pour des services privés. » p. 124

Dans ce dernier chapitre, Plourde affirme que la décision de privatiser encore plus notre système de santé est une entreprise d'abord et avant tout idéologique. En effet:

« [...] une revue de la littérature internationale a montré en 2014 que la mortalité et les coûts des services étaient plus élevés dans les établissements de santé privé à but lucratif que dans les organismes sans but lucratif. » p. 126

Ces effets sont connus depuis longtemps déjà, le Québec n'étant pas le premier à s'engager dans ce chemin. Dès 1990, l'Italie privatise plusieurs services de santé et devient un contre-exemple marqué. On constate ainsi que plus le pourcentage de services assurés par le privé est grand, plus la mortalité des patient·e·s est importante. Des constats similaires ont été faits suite aux privatisations en santé en Angleterre en 2013 et en 2020 en Colombie-Britannique.

Selon Plourde, cette surmortalité est le résultat de la création d'un système à deux vitesses. En effet, alors que statistiquement les personnes plus aisées sont plus en santé, grâce au système privé, elles ont accès à des soins plus rapidement. À l'inverse, les personnes les plus pauvres sont obligées de se retourner vers le système public, définancé au profit du privé.

On en revient donc à la conclusion générale que:

« Traiter la maladie comme une source de profits ne conduit pas à l'amélioration de la santé et des services, bien au contraire. Persévérer dans la voie néfaste d'une privatisation accrue des services serait donc une grave erreur. » p. 154

18 September, 2025 04:00AM by Louis-Philippe Véronneau

April 08, 2025

Cher Hydro-Québec: le Quartier latin mérite mieux

Voici un texte que j'ai écris pour le numéro d'avril 2025 de mon journal syndical. J'écris rarement en français sur mon blog (qui est principalement destiné à un auditoire international), mais cela m'arrive quand même parfois!

Vue de haut de l'emprise du nouveau poste de transformation électrique, coin Berri et Ontario

Mai 2024. Le Devoir annonce qu'Hydro-Québec s'est entendue avec Bibliothèques et Archives nationales du Québec pour l'achat du terrain coin Berri et Ontario pour la construction d'un nouveau poste de transformation électrique. Berri-2, un poste de 315 000 volts, remplacera le jardin de lecture et le terrain gazonné face à l'Îlot Voyageur¹. Exit, la statue de Danny Laferrière.

On nous apprend ainsi qu'un bâtiment plus grand que la Grande Bibliothèque — sans fenêtres — s'érigera sur ce terrain d'ici 2033, entrainant la perte d'un des derniers espaces verts du Quartier latin. BAnQ, mise à genoux par plus d'une décennie de désinvestissement et de négligence de la part de Québec, n'a pas d'autre choix que d'accepter. La CAQ lui a en effet confié le mandat de revitaliser l'ancienne bibliothèque Saint-Sulpice, sur Saint-Denis, sans toutefois lui accorder les budgets nécessaires pour le faire.

La vente de ce terrain pour 22 millions de dollars, c'est pour BAnQ l'équivalent parapublic d'aller au Pawn Shop vendre sa guitare pour payer son loyer. Tout le monde constate l'humiliation imposée à l'institution, même si sa directrice, Marie Grégoire, ancienne bonze de l'Action démocratique du Québec, s'en cache bien. Après tout, défendre « une institution d'avant-garde et de référence vouée à l'enrichissement du savoir et de la culture »², c'est probablement le travail d'un·e autre.

* * *

Comme beaucoup d'autres québécois·e·s, j'entretiens avec Hydro-Québec une relation ambigüe.

Symbole inspirant d'une période de prise en main collective face aux diktats du privé — « Maintenant ou jamais! Maîtres chez nous » — Hydro-Québec représente également pour moi notre arrogance collective vis à vis des question autochtones.

En définitive, nous n'avons pas su bâtir cette « relation de nation à nations » tant de fois promise, jamais réalisée. Cette arrogance, que l'on voit encore chez Hydro-Québec dans ses projets d'infrastructure, elle provient de notre refus d'admettre que, nous aussi, nous étions et sommes encore actrices et acteurs de ce colonialisme destructeur qui ravage les Premières Nations, les Métis et les Inuit au Québec et au Canada…

Je m'égare ici peut-être un peu du sujet principal de cet article, mais c'est à mon avis un détour nécessaire. L'attitude de notre chère société d'État dans ce dossier n'est pas nouvelle et doit être replacée dans un contexte plus large.

Quand nous lui demandons plus de transparence et qu'elle nous ignore, quand nous tentons de lui faire comprendre que ses décisions mettent en péril nos milieux de vie et d'étude et qu'elle nous répond “qu'elle n'a pas le choix”, elle emploie somme toute les mêmes tactiques que celles utilisées pour déposséder les nations autochtones au Québec de leurs terres, de leurs lacs et de leurs rivières. Les mêmes tactiques, moins la police et la violence physique.

* * *

Estimation de la volumétrie du futur poste de transformation électrique

Avec raison, le Quartier latin s'enflamme et se mobilise. Lise Bissonnette, Christine St-Pierre, Phyllis Lambert, Michel Tremblay, Kev Lambert, Nicole Brossard, l'Association citoyenne du Village de Montréal, le SPUQ-UQÀM, Marie D. Martel, Carol Couture et bien d'autres dénoncent tour à tour le projet. Dans les mots de Denys Arcand: « dément. […] C'est du délire ! C'est complètement fou. »³.

Toujours au front, Manon Massé pose la question qui tue: ne pourrait-on pas utiliser … d'autres terrains? Le Quartier latin n'est en effet pas étranger aux lieux laissés à l'abandon pour profiter des effets de la spéculation immobilière rampante⁴. Réponse: « Hydro-Québec exclut d'emblée d'exproprier »⁵. Protéger (le capital) et servir (les intérêts des riches propriétaires des terrains du centre-ville), notre chère société d'État joue bien ici son rôle de police de l'énergie.

Hydro-Québec sort donc encore la même cassette: les communs et l'environnement n'ont pas de valeur et elle n'hésitera pas à les détruire si cela lui permet d'atteindre ses objectifs de rentabilité. “Énergie verte”, une hypocrisie telle qu'on croyait entendre la Caisse de dépôt et placement du Québec affirmant appliquer les plus hauts standards éthiques tout en continuant à investir dans des entreprises responsables du génocide en Palestine.

Au-delà de la question du terrain, avons-nous vraiment besoin d'un nouveau poste de transformation électrique plus gros et plus puissant? Si Hydro-Québec affirme que c'est nécessaire « pour répondre à la croissance de la demande en électricité du centre-ville », permettons-nous d'en douter. Il suffit en effet de jeter un coup d'œil le soir à tous ces bâtiments complètement illuminés pour voir à quel point le gaspillage d'énergie est un véritable leitmotiv québécois.

Dans les faits, cette “nécessité” est plutôt le résultat d'une course folle vers l'avant au nom de la “transition écologique”, alors que la solution réelle à nos problèmes environnementaux est le refus collectif. De la consommation. De la croissance. Du capitalisme. De la mort collective.

* * *

Nous apprenions récemment que le Cégep du Vieux Montréal et l'UQÀM collaboreront pour mettre de l'avant des « actions concertées entourant la relance du Quartier latin »⁶. Pourquoi ne pas en profiter pour défendre nos communs?

Il est clair que le conseil d'administration du CVM doit dénoncer le projet de construction d'un poste de transformation au coin Berri et Ontario et doit prendre position en faveur d'une rétrocession de ce terrain à BAnQ. La communauté du Quartier latin organise d'ailleurs une manifestation le samedi 26 avril pour dénoncer le manque d'écoute dans ce dossier.

Et au-delà de cet enjeu — après tout hyperlocal — continuons de dénoncer l'attitude d'Hydro-Québec, particulièrement envers les communautés autochtones. Vérité, réconciliation, transfert de 25% des parts de la société d'État aux nations autochtones au Québec?

Jean-François NADEAU et Étienne PARÉ, « Un poste d'Hydro-Québec en plein Quartier latin à quel prix? », Le Devoir (14 mai 2024), https://www.ledevoir.com/societe/transports-urbanisme/812870/projet-hydro-quebec-coeur-quartier-latin-tenu-secret ↩
BAnQ, « Déclaration de services aux citoyens (P-5) », 21 juin 2023, https://www.banq.qc.ca/declaration-de-services-aux-citoyens-p-5/ ↩
Jean-François NADEAU, « De grands noms de la culture dénoncent le projet d’Hydro-Québec au Quartier latin », Le Devoir (17 février 2025), https://www.ledevoir.com/societe/transports-urbanisme/845293/figures-culture-denoncent-projet-hydro-quebec-quartier-latin ↩
Exemple parmi tant d’autres: cet entrepôt de 140 mètres de long situé sur Saint-Hubert derrière l'Îlot Voyageur, véritable verrue urbaine qui pourrie tranquillement depuis 2003 en attendant que son propriétaire, l’Aquilini Investment Group, décide finalement d’en faire du logement. ↩
Jean-François NADEAU, « De l'électricité dans l'air autour du projet d’Hydro-Québec pour le Quartier latin », Le Devoir (23 octobre 2024), https://www.ledevoir.com/societe/transports-urbanisme/822244/electricite-air-autour-projet-hydro-quebec-quartier-latin ↩
Cégep du Vieux Montréal, « Le cégep du Vieux Montréal et l'UQAM signent une entente pour consolider leur partenariat privilégié et explorer de nouvelles pistes de collaboration », 12 février 2025, https://www.cvm.qc.ca/wp-content/uploads/COMMUNIQUE_cvm-uqam.pdf ↩

08 April, 2025 04:00AM by Louis-Philippe Véronneau

December 18, 2024

Grégory Colpart

MiniDebConf Toulouse 2024 (fr)

Après la MiniDebConf Marseille 2019, le COVID-19 a rendu impossible/difficile l’organisation de nouvelles MiniDebConf pendant quelques années. Avec la reprise progressive d’événements d’ampleur en présentiel (FOSDEM, DebConf, etc.), l’idée était de proposer une nouvelle MiniDebConf en France mais avec une organisation plus légère. En 2023, nous avons eu l’idée de contacter les organisateurs de Capitole du Libre afin de réitérer l’expérience de 2017 : pouvoir organiser une MiniDebConf en parallèle de l’événement annuel qui se tient à Toulouse en novembre. Mais notre demande était trop tardive pour 2023, donc après discussions avec Capitole du Libre en novembre 2023 à Toulouse puis en février 2024 à Bruxelles, nous avons pu confirmer la tenue d’une MiniDebConf Toulouse en novembre 2024 !

Nous avons alors constitué une petite équipe d’organisation et nous nous sommes lancés : Call for Papers en mai 2024, ajout d’un MiniDebCamp de deux jours, coordination avec la DebConf vidéo team, recherche de sponsors, création d’un logo, commande des T-shirts et stickers, planning, gestion des inscriptions… même avec une organisation plus légère (la gestion de la salle de conférence, des badges, de la nourriture pendant le week-end étant faite par Capitole du Libre), il restait un peu de travail de préparation.

Jeudi 14 et vendredi 15 novembre 2024, une quarantaine de développeurs débarquent du monde entier (France, Espagne, Italie, Suisse, Allemagne, Angleterre, Brésil, Urugay, Inde, Brest, Marseille…) pour passer deux jours de MiniDebCamp dans les beaux espaces collaboratifs d’Artilect dans le centre-ville de Toulouse.

Puis le samedi 16 et dimanche 17 novembre 2024, la MiniDebconf s’est tenue dans les locaux de l’ENSEEIHT au sein de l’évènement Capitole du Libre. On a démarré dès le samedi matin avec une ouverture (Jérémy Lecour) marquée par un hommage à Lunar (Nicolas Dandrimont), puis Reproducible Builds – rebuilding what is distributed from ftp.debian.org (Holger Levsen) et Discussion on my research work on sustainability of Debian OS (Eda). Après un déjeuner grâce aux food trucks du Capitole du Libre, c’est reparti pour un après-midi intense : What’s new in the Linux kernel (and what’s missing in Debian) (Ben Hutchings), Linux live patching in Debian (Santiago Ruano Rincón), Trixie on mobile: are we there yet? (Arnaud Ferraris), PostgreSQL container groups, aka cgroups down the road (Cédric Villemain), Upgrading a thousand Debian hosts in less than an hour (Jérémy Lecour et moi-même) et Using debusine to automate your QA (Stefano Rivera &co).

Dimanche, c’est le second jour, et l’on reprend avec une présentation de la DebConf 25 (Benjamin Somers) qui se déroulera à Brest en juillet 2025 puis l’on enchaîne la matinée avec How LTS goes beyond LTS (Santiago Ruano Rincón & Roberto C. Sánchez), Cross building (Helmut Grohne) et State of the javascript (Bastien Roucariès). L’après-midi, place aux Lightning Talks, PyPI Security: Past, Present & Future (Salvo “LtWorf” Tomaselli) et le classique Bits from DPL (Andreas Tille) avant la conférence de clôture (Pierre-Elliott Bécue).

Toutes les conférences sont à retrouver en vidéo sur le programme (encore merci à la formidable DebConf vidéo team), merci aux sponsors (Viridien, Freexian, Evolix, Collabora et Data Bene) et grand merci à toute l’équipe du Capitole du Libre de nous avoir « supporté »… rendez-vous à Brest en juillet 2025 !

Articles à propos (ou mentionnant) la MiniDebConf Toulouse :

18 December, 2024 04:45PM by Gregory Colpart

November 30, 2024

Aurélien Jarno

UEFI Unified Kernel Image for Debian Installer on riscv64

On the riscv64 port, the default boot method is UEFI, with U-Boot typically used as the firmware. This approach aligns more closely with other architectures, which avoid developping riscv64 specific code. For advanced users, booting using U-Boot and extlinux is possible, thanks to the kernel being built with CONFIG_EFI_STUB=y.

The same applies to the Debian Installer, which is provided as ISO images in various sizes and formats like on other architectures. These images can be put on a USB drive or an SD-card and booted directly from U-Boot in UEFI mode. Some users prefer to use the netboot "image", which in practice consists of a Linux kernel, an initrd, plus a set of Device Tree Blob (DTB) files.

However, booting this in UEFI mode is not straightforward, unless you use a TFTP server, which is also not trivial. Less known to users, there is also a corresponding mini.iso image, which contains all the above plus a bootloader. This offers a simpler alternative for installation, but depending on your (vendor) U-Boot version this still requires to go through a media.

Systemd version 257-rc2 comes with a great new feature, the ability to include multiple DTB files in a single UKI (Unified Kernel Image) file, with systemd-stub automatically loading the appropriate one for the current hardware. A UKI file combines a UEFI boot stub program, a Linux kernel image, an optional initrd, and further resources in a single UEFI PE file. This finally solves the DTB problem in the UEFI world for distributions, as a single image can work on multiple boards.

Building upon this, debian-installer on riscv64 now also creates a UEFI UKI mini.efi image, which contains systemd-stub, a Linux kernel, an initrd, plus a set of Device Tree Blob (DTB) files. Using this image also ensures that the system is booted in UEFI mode. Booting it with debian-installer is as simple as:

load mmc 0:1 $kernel_addr_r mini.efi # (can also be done using tftpboot, wget, etc.)
bootefi $kernel_addr_r

Additional parameters can be passed to the image using the U-Boot bootargs environment variable. For instance, to boot in rescue mode:

setenv bootargs "rescue/enable=true"

30 November, 2024 09:41AM by aurel32

November 25, 2024

Stéphane Blondon

Afficher une fenêtre de notification depuis le shell

Plusieurs commandes permettent d’afficher une fenêtre de notification qui disparaît automatiquement. Voici quelques outils avec les fonctionnalités minimales. Chacun d’entre eux a des paramètres supplémentaires spécifiques.

Notify-send

notify-send est disponible dans le paquet libnotify-bin (dans Debian et ses dérivées) et est probablement déjà installé. La capture montre le rendu avec Gnome. La commande :

$ notify-send "ici un titre" "ici le contenu"

Zenity

zenity est basé sur GTK et permet l’affichage de différents types de fenêtre. Pour obtenir la fermeture automatique de la fenêtre, il faut ajouter un paramètre spécifique :

$ zenity --info --title="ici un titre" --text="ici un contenu" --timeout=5

Kdialog

kdialog fait partie de KDE. Le type passivepopup est une notification qui apparaît dans un coin du bureau et disparaît automatiquement :

$ kdialog --passivepopup --title "ici un titre" "ici un contenu"

Xmessage

xmessage fait partie d’outils fournis avec X11 (paquet x11-utils sous Debian et dérivées). Il doit être disponible à peu près partout mais, contrairement aux commandes citées précédemment, ne bénéficie pas de l’intégration avec le thème du bureau. En bref, ça fonctionne mais c’est moche.

$ xmessage -timeout 5 "ici un contenu"

Versions utilisées

Le rendu des captures d’écran peuvent différer selon la version des logiciels utilisés. Les captures ont été faites avec :

Gnome 47
KDE Plasma 5.27
Zenity 4.0.2
Xmessage 1.0.7

25 November, 2024 09:05AM by ascendances

November 19, 2024

Aurélien Jarno

AI crawlers should be smarter

It would be fantastic if all those AI companies dedicated some time to make their web crawlers smarter (what about using AI?). Noawadays most of them still stupidly follow every link on a Git frontend.

Hint: Changing the display options does not provide more training data!

19 November, 2024 10:31PM by aurel32

October 08, 2024

Louis-Philippe Véronneau

Dette et déficit: jusqu'ici, tout va bien

Voici un texte que j'ai écris pour le dernier numéro de mon journal syndical. J'écris rarement en français sur mon blog (qui est principalement destiné à un auditoire international), mais cela m'arrive quand même parfois!

Dans une chronique publiée le 5 octobre dernier, Gérard Fillion, journaliste aux affaires économiques à Radio-Canada, titrait: « Le grand retour de la rigueur budgétaire ? »¹.

Nul besoin de ce point d'interrogation, cher Gérard: les coupures que nous vivons actuellement dans les cégeps et dans nos services publics marquent bel et bien le retour non pas de la rigueur, mais de l'austérité budgétaire.

Dans cet encadré, je vous propose de déconstruire trois mythes économiques trop souvent utilisés pour justifier des choix politiques sous le couvert de la nécessité économique.

1. Le Québec est trop endetté et doit réduire sa dette

Sophisme relativement courant, celui de la peur de la dette gouvernementale a la peau dure, et ce, malgré le bilan exemplaire du Québec (et du Canada!) en matière de finances publiques.

Adoptée en 2006, la Loi sur la réduction de la dette et instituant le Fonds des générations² établissait une cible d'endettement québécoise qui semblait alors raisonnable: en 2026, nous visions une dette brute équivalente à 45% du PIB.

Passons outre les subtilités du débat « dette nette vs dette brute » et regardons ce qu'il en est, près de 20 ans plus tard. Surprise! cette cible a été atteinte en 2022 et la dette brute se situe maintenant à 41,5% du PIB³ ⁴.

Péril en la demeure? Décote éventuelle du Québec sur les marchés financiers? Que nenni!

Mieux encore, tel que démontré dans le graphique ci-dessous, nous payons substantiellement moins d'intérêts sur notre dette qu'en 2012⁴.

Notons de plus « [qu'en] 2023, l'ensemble des agences [de notation] ont confirmé la cote de crédit du Québec avec perspective stable. »⁵.

Un graphique du service de la dette au Québec

Que devrions-nous donc faire, maintenant que la cible est atteinte?

Suite à un appel du Ministère des finances en 2021, l'Association des économistes québécois, le CIRANO, l'Institut du Québec et la Chaire de recherche en fiscalité et en finances publiques — des gens qui n'ont pas la réputation d'être particulièrement à gauche — en ont conclu que « la réduction de la dette ne devrait pas être un exercice sans fin »⁶.

Bref, la dette du Québec n'est pas du tout inquiétante et mieux vaudrait investir notre argent ailleurs...

2. Le déficit budgétaire force le gouvernement à couper

Ligne de communication populaire dans les médias depuis quelques temps, on ne cesse de répéter que le déficit budgétaire est de 11 milliards!

11 milliards, quel gros chiffre, penserez-vous sûrement. Difficile de s'imaginer ce que cela peut représenter, en termes de finances personnelles. Plusieurs centaines de maisons? Combien de millions de paires de bas?

Le hic est justement que les finances gouvernementales ne sont pas des finances personnelles. Contrairement à vous, le gouvernement est maître de ses revenus et ses déficits, déficits qui, loin d'être une fatalité, sont causés par des choix politiques. Nous y reviendrons plus bas au 3^e mythe.

Chose certaine, en ne cessant de répéter ce chiffre magique de 11 milliards, les journalistes, politicien·ne·s et autres figures publiques commettent notre second mythe économique. En effet, les finances publiques doivent se calculer en pourcentage du PIB, et non en argent nominal.

Si l'on procède de la sorte, c'est parce que le pourcentage du PIB prend en compte la capacité de payer d'un État. Un État qui a un grand PIB a ainsi plus de facilité à rembourser une même somme qu'un État qui a un plus petit PIB.

Voici un exemple simple que j'utilise en classe pour illustrer cette situation. Si un individu a des revenus annuels de 100$ et une dette de 100$, cette dette est très importante! Il devrait consacrer 100% de ses revenus à sa dette pour la rembourser au complet. À l'inverse, une autre personne qui a également une dette de 100$, mais des revenus annuels de 100 000$ n'est pas très endettée. Ce 100$ représente pour elle 0,1% de ses revenus.

Cette même dette de 100$ ne veut donc pas dire grand-chose si on ne la compare pas aux revenus. C'est la même chose pour les gouvernements. La dette du Québec est minuscule pour les États-Unis, mais serait très grande pour la municipalité de Sainte-Élie-de-Caxton.

Le PIB du Québec prévu pour 2024 est de 579 milliards de dollars. Le déficit annoncé de 11 milliards ne représente donc qu'un peu moins de 2% du PIB. Notons que la France anticipe cette année un déficit de 5,6% de son PIB et que l'Union Européenne considère 3% comme une cible maximale raisonnable⁷.

Quand les médias parlent de finances publiques en termes nominaux (en dollars) plutôt qu'en pourcentage du PIB, sachez que c'est un exercice de désinformation, qui vise à créer chez vous un sentiment de peur en vous mettant face à de très gros chiffres, sans les mettre en contexte.

3. Nous manquons d'argent pour nos politiques sociales

Dernier mythe économique, cette idée que nous manquons d'argent pour mettre en place des politique sociales durables et progressistes. Pour reprendre les doux mots de Pascale Déry, ministre de l'éducation supérieure: « On ne peut pas tout faire en même temps »⁸ !!!

Ce mythe est peut-être le plus facile des trois à déconstruire. En effet, les gouvernements semblent constamment nous prouver que leurs décisions économiques ne tiennent pas la route. Mentionnons en vrac:

1,7 milliards de perte récurrente suite à la plus récente baisse d'impôts, véritable cadeau aux riches⁷.
6,7 milliards de chèques à saveur électorale envoyés à la population en 2022 sous le couvert de la « lutte à l'inflation »⁹ ¹⁰.
2 milliards pour Bombardier, une entreprise qui, après avoir mis à pied des centaines d'employé·e·s au Québec, a été vendue à rabais l'étranger¹¹.
1,37 milliards pour Northvolt, une entreprise maintenant en faillite¹².
7 millions pour les Kings, une équipe de hockey détenue par un milliardaire¹³.
6,5 millions pour la PGA, une association qui génère plus de 2,6 milliards de revenus annuels¹⁴.

Difficile à la vue de ces chiffres d'affirmer qu'il manque d'argent pour offrir un repas par jour à tous les enfants du Québec (1,5 milliards/an¹⁵)...

D'un point de vue plus structurel, la Coalition Main Rouge propose depuis des années un ensemble de mesures pour dégager plus de 14 milliards de dollars en revoyant nos priorités fiscales¹⁶.

Certaines de ces mesures, comme « Adopter un régime entièrement public d’assurance médicaments » ou encore « Mettre fin à l'incorporation des médecins » sont d'une simplicité telle que leur absence ne peut s'expliquer que par une capture réglementaire de la part des lobbys visés.

Alors que nos priorités devraient être la faim, la pauvreté, l'éducation, la santé, l'environnement, etc., on cesse de nous répéter que la richesse est créée par ceux et celles qui sont déjà riches et qui sauront à leur gré nous donner généreusement leurs miettes.

Rejetons cette vision du monde absurde et donnons-nous finalement les moyens de nos ambitions collectives.

Fillion, G. (2024, 5 octobre). Le grand retour de la rigueur budgétaire?. Radio-Canada. https://ici.radio-canada.ca/nouvelle/2109983/retour-rigueur-budgetaire-economie-politique ↩
Québec. (2006). Loi sur la réduction de la dette et instituant le Fonds des générations, RLRQ c R-2.2.0.1. https://www.legisquebec.gouv.qc.ca/fr/document/lc/R-2.2.0.1 ↩
Gouvernement du Québec. (2022). Rapport préélectoral sur l'état des finances publiques du Québec. https://www.finances.gouv.qc.ca/documents/Autres/fr/RapportPreelectoralFR_2022.pdf ↩
Gouvernement du Québec. (2024). Budget 2024-2025. https://www.finances.gouv.qc.ca/Budget_et_mise_a_jour/budget/documents/Budget2425_PlanBudgetaire.pdf ↩↩
Ministère des Finances du Québec. (2024). Dette du Québec et Fonds des générations. https://www.finances.gouv.qc.ca/ministere/finances_publiques/dette_quebec_fonds_generations.asp ↩
CRFFP. (2021). Les règles budgétaires du Québec : réflexions d’un panel d’experts (Regard CFFP R2021/15). https://cffp.recherche.usherbrooke.ca/wp-content/uploads/2021/12/r_2021-15_regles_budgetaires_du_quebec.pdf ↩
Fillion, G. (2024, 21 février). Des déficits plus élevés à Québec : pourquoi avoir baissé les impôts?. Radio-Canada. https://ici.radio-canada.ca/nouvelle/2050907/deficits-quebec-baisse-impots-budget-provincial ↩↩
Goudreault, Z. (2024, 5 septembre). « On ne peut pas tout faire en même temps » dans les cégeps, affirme Déry. Le Devoir. https://www.ledevoir.com/societe/education/819278/on-ne-peut-pas-tout-faire-meme-temps-cegeps-affirme-dery ↩
Lecavalier, C. (2022, 22 mars). 500 $ pour 6,4 millions de Québécois. La Presse. https://www.lapresse.ca/affaires/economie/2022-03-22/budget-du-quebec/500-pour-6-4-millions-de-quebecois.php ↩
Bordeleau, S. (2022, 9 novembre). Inflation : Québec détaille son aide de 400 $ à 600 $. Radio-Canada. https://ici.radio-canada.ca/nouvelle/1931431/cheque-caq-inflation-modalites ↩
Arseneault, J. et Lecavalier, C. (2024, 24 juillet). Plus de 2 milliards de fonds publics: L'engrenage de la C Series. La Presse. https://www.lapresse.ca/affaires/2024-07-24/plus-de-2-milliards-de-fonds-publics/l-engrenage-de-la-c-series.php ↩
Labbé, J. (2024, 24 septembre). Les déboires de Northvolt placent Québec sur la défensive. Radio-Canada. https://ici.radio-canada.ca/nouvelle/2107011/debat-urgence-northvolt-quebec ↩
Tanguay, S. (2024, 3 octobre). Les oppositions à Québec mitraillent les «Kings des dépenses». Le Devoir. https://www.ledevoir.com/politique/quebec/821037/oppositions-quebec-mitraillent-kings-depenses ↩
Brousseault-Pouliot, V. (2024, 25 septembre). Coupe des Présidents: Québec défend sa subvention. La Presse. https://www.lapresse.ca/actualites/coupe-des-presidents/un-cout-de-9-millions-pour-les-contribuables/2024-09-25/coupe-des-presidents/quebec-defend-sa-subvention.php ↩
Plourde, A. (2023). Un programme universel d’alimentation scolaire pour le Québec. Institut de recherche et d’informations socioéconomiques. https://iris-recherche.qc.ca/publications/programme-alimentation-scolaire/ ↩
Coalition Main Rouge. (2021). Solutions fiscales et mesures de contrôle des dépenses proposées par la Coalition Main rouge Automne 2021. https://www.nonauxhausses.org/wp-content/uploads/Tableau10milliardsdesolutions2021.pdf ↩

08 October, 2024 04:00AM by Louis-Philippe Véronneau

September 26, 2024

Debian France

Debian France renouvelle ses instances

AGO de Debian France

Rappel

L'assemblée générale annuelle de l'association Debian-France vient de se terminer. Pour rappel, Debian France est une association qui se propose de représenter Debian en France, voire en Europe puisqu'elle est la seule organisation de confiance (Trusted Organization) active du projet Debian sur ce continent. Ce statut lui permet ainsi de recueillir des dons pour le projet Debian et de gérer le budget du projet qui lui incombe, en parallèle du sien.

Spécificité de l'AGO 2024

En 2023, il n'y a pas eu d'AGO. Cela est dû à plusieurs facteurs dont des soucis avec les outils de communication de l'association et un quotidien chargé pour les membres du bureau. Le CA a donc été renouvelé aux deux tiers cette année.

Bilan du vote

Les membres sortants du CA pour les années 2022 et 2023 étaient :

Alban Vidal ;
Cédric Boutillier ;
Cyril Brulebois ;
Grégory Colpart ;
Pierre-Elliott Bécue ;
William Bonnet.

À l'issue du scrutin, et en conformité avec les candidatures, ont été élus au CA :

Alban Vidal ;
Georges Khaznadar ;
Grégory Colpart ;
Pierre-Elliott Bécue ;
William Bonnet.

Élection du bureau

Le CA nouvellement élu s'est réuni et a nommé au bureau :

Président : Pierre-Elliott Bécue ;
Vice-Président : Alban Vidal ;
Trésorier : Jean-Pierre Giraud ;
Secrétaire : Jean-Philippe Mengual ;
Secrétaire adjoint : Quentin Lejard.

Mot du président

Après deux années de gestion somme toute "banale" (nous avons quand même intensifié notre activité autour de l'organisation des DebConfs en prenant part à la gestion financière de l'événement, ce qui induit une belle charge additionnelle), Debian France se voit confier des missions accrues pour 2024 et 2025. En effet, l'association aura la charge de l'organisation de la Mini DebConf Toulouse qui aura lieu les 16 et 17 novembre 2024 en parallèle du Capitole du Libre, et les préparatifs pour DebConf 25 qui se tiendra à Brest.

L'année risque donc d'être chargée, nous ne manquerons pas de communiquer sur nos activités.

26 September, 2024 06:11AM

June 07, 2024

Meetup 2024/2 - 13 Juin - Bordeaux

Meetup du 13 Juin à Bordeaux

Debian France organise un nouveau meetup à Bordeaux avec le soutien de Yaal Coop et de Collabora.

Il se déroulera le 13 Juin 2024 à partir de 18h00 au Yack (l'espace de co-working de Yaal) à Bègles (même lieu que le précédent meetup).

Il n'y a pas de sujet précis cette fois-ci, il s'agira donc d'une Bug Squashing Party! Le but sera de fermer (ou au moins proposer un patch) le plus grand nombre de bugs.

Merci de vous inscrire sur Mobilizon à l'évènement pour que nous puissions prévoir votre accueil dans les meilleures conditions.

Venez nombreux et n'hésitez pas à répandre l'information!

Lieu

1er étage du Bâtiment du 19 - 16 rue des Terres Neuves, 33130 Bègles. Voir sur OpenStreetMap

Liens

07 June, 2024 04:06PM

May 25, 2024

Retour du Meetup Debian à Bordeaux du 16 mai

Retour du Meetup du 16 Mai à Bordeaux

Le 16 mai dernier s'est tenu le meetup Debian au sein du Yack (le local de coworking de Yaal Coop).

Nous étions 8 participants dont : 2 développeurs Debian (sthibault et daissi), des contributeurs Debian (dont Stéphane à qui l'on doit entre autres le nouveau template de Debian Policy) et utilisateurs avancés de Debian (dev, devops, etc). Bien que plus que bienvenu, nous n'avons pas vu d'utilisateurs avec un profil moins technique. Une bonne partie des participants n'a appris l'existence de l'évènement avant que quelques jours avant celui-ci malgré les annonces tout au long du mois précédent. Une meilleure communication (via plus de rappels, en ciblant les communautés d'utilisateurs ou des distributions dérivées) en amont des prochains meetups pourrait éventuellement mobiliser plus de participants.

Comme prévu, le thème du jour était le packaging Debian avec les slides disponibles sur le wiki Debian. Trop occupés à discuter packaging Debian (et surtout l'heure des pizzas avait sonné), nous n'avons pas eu le temps d'emballer signal-estimator (et sa dépendance intrusive-shared-ptr). Cependant, la majeure partie du travail avait été réalisée en préparation du meetup, les paquets devraient être soumis pour inclusion dans l'archive Debian d'ici quelques jours/semaines. Nous avons également abordé différents thèmes dans le désordre : la courbe d'apprentissage de l'emballage Debian peu rude, Debian CI, la transition t64, l’absence de roadmap du projet Debian, etc.

Le prochain meetup Debian devrait avoir lieu à la mi-juin (à confirmer) également au Yack. Si ce premier meetup était plutôt théorique, le second sera lui plus pratique du genre BSP, packaging ou contribution à Debian.

PS : merci Samuel d'être venu avec un adaptateur USB-C - HDMI! 🙂

25 May, 2024 09:26AM

April 30, 2024

Meetup 2024/1 - 16 Mai - Bordeaux

Meetup du 16 Mai à Bordeaux

Debian France organise un nouveau meetup à Bordeaux avec le soutien de Yaal Coop et de Collabora.

Il se déroulera le 16 Mai 2024 à partir de 18h30 dans les locaux de Yaal Coop.

Le thème sera : « Packaging, l’art de créer des paquets selon la politique Debian »

Qu'est ce qu'un paquet Debian ? Quelles sont les bonnes pratiques du packaging ? Comment en construire un ? Nous allons créer ensemble votre premier paquet!

Si vous souhaitez empaqueter un logiciel lors du meetup, vous pouvez le soumettre à daissi@debian.org pour une évaluation de sa difficulté (dans la limite des places disponibles :-).

Merci de vous inscrire (soit sur le wiki Debian, soit sur Mobilizon) à l'évènement pour que nous puissions prévoir votre accueil dans les meilleures conditions.

Venez nombreux et n'hésitez pas à répandre l'information!

Lieu

1er étage du Bâtiment du 19 - 16 rue des Terres Neuves, 33130 Bègles. Voir sur OpenStreetMap

Liens

30 April, 2024 07:43PM

September 03, 2023

J. Fernando Lagrange

Ajout du paquet imapsync dans debian

Contexte

Avec la sortie de Debian 12, en juin dernier, je dois mettre à jour un serveur de dépôts de paquets.

Comme ce serveur contient un seul paquet (imapsync, qui n'est pas dans debian), il a été décidé de supprimer ce serveur de dépôt et de directement passer par le code source amont lorsqu'on a besoin d'utiliser cet outil au boulot.

Du travail a déjà été fait pour inclure imapsync dans debian, c'est d'ailleurs ce qui m'a permis de créer un paquet en août 2021.

Participer à mettre ce paquet directement dans Debian, c'est un peu ma façon de renvoyer l'ascenseur.

Reprise du travail

J'ai repris le travail là où la personne précédente l'a laissée.

Et j'ai indiqué ce que j'ai fait sur le bogue de suivi « Intent To Package » #919587: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919587

J'ai ensuite construit le paquet et je l'ai envoyé sur debian mentors.

03 September, 2023 03:17PM by Low Memory

August 16, 2023

Charles Plessy

J'ai oublié « make clean ».

Je ne me souviens plus de la dernière fois où j'ai utilisé la commande make clean. Si j'empaquète pour Debian, le travail se fait dans un dépôt git, et j'utilise les commandes git clean -fdx ; git checkout . que je peux rappeler depuis mon historique des commandes via Ctrl-r la plupart du temps. Et dans les autres cas, si les sources ne sont pas déjà dans git, alors les commandes git init . ; git add . ; git commit -m 'hopla' règlent le problème.

16 August, 2023 04:32AM

July 23, 2023

Aurélien Jarno

Welcome Debian riscv64

After many years of effort, I am happy to announce that Debian riscv64 is now an official architecture!

This milestone is not the end of the journey but rather the beginning of a new one: the port will need to be rebootstrapped in the official archive, build daemons will have to be reinstalled and handed over to DSA, many bugs will need to be fixed. If everything goes well, the architecture will eventually be released with Trixie. Please note that this process will be long and will span several months.

I would like to take this opportunity to thanks everyone who contributed to this significant milestone, including individuals and Debian teams, as well as the organizations and companies that provided us with resources (by rough chronological order): MIT CSAIL, Sifive, Mullvad, tetaneutral.net, OSU Open Source Lab, Microchip, BeagleBoard.org Foundation, RISC-V international, PLCT Lab (ISCAS), StarFive, and Metropolitan Area Network Darmstadt.

23 July, 2023 07:28PM by aurel32

July 14, 2023

Goodbye Debian GNU/kFreeBSD

Over the years, the Debian GNU/kFreeBSD port has gone through various phases. After many years of development, it was released as technology preview with the release of Squeeze and eventually became an official architecture with the release of Wheezy. However it ceased being an official architecture a couple of years later with the release of Jessie, although a jessie-kfreebsd suite was available in the official archive. Some years later, it was moved to the debian-ports archive, where it slowly regressed over the years. The development totally has now been stopped for over a year, and the port has been removed from the debian-ports archive. It's time to say it goodbye!

I feel a touch of nostalgia as I was deeply involved in the Debian GNU/kFreeBSD port for nearly a decade, starting in 2006. There are many different reasons to like GNU/kFreeBSD ranging from political to technical considerations. Personally, I liked the technical aspect, as the FreeBSD kernel, at that time, was ahead of the Linux kernel in term of features: jails, ZFS, IPv6 stateful firewalling, and at a later point superpages. That said it was way behind for hardware support and to the best of my knowledge this remains unchanged. Meanwhile, the Linux kernel development accelerated in the latter stages of the 2.6.x series, and eventually closed the feature gap. At some point, I began to lose interest, and also to lack time, and slowly stepped away from its development.

14 July, 2023 04:14PM by aurel32

May 10, 2023

Charles Plessy

Plussez pour patcher Firefox pour afficher du Markdown.

J'ai écrit auparavant que quand Firefox reçoit un fichier dont le type média est text/markdown, il le propose au téléchargement, alors que les autres navigateurs l'affichent comme un fichier texte.

Il est maintenant possible de plusser sur connect.mozilla.org pour demander que Firefox formatte le markdown par défaut.

10 May, 2023 11:43PM

March 09, 2023

If you work at Dreamhost, can you help us?

Update: thanks to the very kind involvment of the widow of our wemaster, we could provide enough private information to Dreamhost, who finally accepted to reset the password and the MFA. We have recovered evrything! Many thanks to everybody who helped us!

Due to tragic circumstances, one association that I am part of, Sciencescope got locked out of its account at Dreamhost. Locked out, we can not pay the annual bill. Dreamhost contacted us about the payment, but will not let us recover the access to our account in order to pay. So they will soon close the account. Our website, mailing lists and archives, will be erased. We provided plenty of evidence that we are not scammers and that we are the legitimate owners of the account, but reviewing it is above the pay grade of the custommer support (I don't blame them) and I could not convince them to let somebody higher have a look at our case.

If you work at Dreamhost and want to keep us as custommers instead of kicking us like that, please ask the support service in charge of ticket 225948648 to send the recovery URL to the secondary email adddresses (the ones you used to contact us about the bill!) in addition to the primary one (which nobody will read anymore). You can encrypt it for my Debian Developer key 73471499CC60ED9EEE805946C5BD6C8F2295D502 if you worry it gets in wrong hands. If you still have doubts I am available for calls any time.

If you know somebody working at Dreamhost can you pass them the message? This would be a big, big, relief for our non-profit association.

09 March, 2023 01:35PM

January 08, 2023

Quelqu'un pourrait-il patcher Firefox pour afficher du Markdown ?

Quand Firefox reçoit un fichier dont le type média est text/markdown, il le propose au téléchargement, alors que les autres navigateurs l'affichent comme un fichier texte. Dans le ticket 1319262, il est proposé d'afficher les fichiers Markdown par défaut. Mais il faudrait un patch…

08 January, 2023 12:18AM

December 16, 2022

Les grots mots dans Debian.

Une conversation sur la list debian-project a attiré mon attention sur un mot italien signifiant quelque chose comme « auriez-vous la gentillesse d'aller voir ailleurs ? », mais en version plus directe et vulgaire. J'ai ensuite utilisé http://codesearch.debian.net pour étudier plus en détail son emploi.

Je l'ai trouvé dans :

le code source de XEmacs ;
une liste de gros mots pour policer les conversations dans BZFlag ;
le générateur aléatoire de phrases PolyGen ;
le code source du jeu de plateau Tagua ;
une base de données d'épigrammes vulguaires pour la plateforme éducative WIMS ;
le jeu de mots croisés parololottero ;
une base de données d'épigrammes vulguaires pour messages de bienvenue ou signatures de courriels ;
des listes de mots de passes trop fréquents ;
un commentaire destiné à un déonmmé Wolf dans le code source d'un autre programme ;
a collection of rude gestures in the xwrists package.

Ce fut une promenade rafraîchissante et récréactive dans l'univers des paquets Debian.

16 December, 2022 01:00PM

October 04, 2022

Debian France

Évènements fin 2022 - début 2023

Bonjour à toutes et tous,

Dans les mois qui viennent, trois évènements auront lieu dans lesquels l'association Debian France tiendra un stand afin d'y faire de la promotion du projet Debian, mais aussi pour y proposer quelques goodie.

Comme chaque évènement, nous sommes à la recherche de volontaires pour tenir le stand Debian France. Pour chacun d'eux, un Framadate est ouvert pour recenser les volontaires et leurs disponibilités.

1) Open Source Experience - Paris

Dates : 8 et 9 Novembre 2022
Site de l'évènement : https://www.opensource-experience.com/
Lien d'inscription pour le stand Debian France : https://poll.debian.net/open-source-experience-2022

2) Capitole du libre - Toulouse

Dates : 19 et 20 Novembre 2022
Site de l'évènement : https://capitoledulibre.org/
Lien d'inscription pour le stand Debian France : https://poll.debian.net/capitole-2022

3) FOSDEM - Bruxelles (Belgique)

Dates : 4 et 5 Février 2023
Site de l'évènement : https://fosdem.org/2023/
Il s'agit d'un salon ou le stand Debian est tenu par de membres Debian France mais aussi des contributeurs d'autres pays. La page d'inscription n'est pas encore ouverte, mais sera disponible sur le Wiki Debian à l'adresse suivante : https://wiki.debian.org/DebianEvents/be

N'hésitez pas à contacter l'association pour toutes question à l'adresse asso@france.debian.net ou bien sur IRC, réseau OFTC, canal #debian-france.

Bien à vous et en espérant vous compter parmi nous,

Quentin et Alban - Secrétaires Debian France

04 October, 2022 10:42PM

February 08, 2022

Stéphane Blondon

Hello Debian en Brainfuck

screenshots.debian.net est un service qui permet d’afficher des captures d’écran de logiciels. C’est assez pratique pour se faire une idée d’une interface par exemple. Une capture d’écran montrait déjà l’interpréteur Brainfuck beef affichant un classique
Hello Word!. Mais on peut aussi personnaliser en affichant un
Hello Debian! :

Brainfuck

Brainfuck est un langage dont l’intérêt principal est d’être difficilement compréhensible par un humain. Pas la peine de s’étendre sur ses spécificités, wikipedia le fait très bien. Il ressemble à une machine de Turing: le programme déplace un curseur dans un tableau et modifie les valeurs contenues dans les cellules du tableau.
Voici une version commentée du programme utilisé (le début est quasi-identique au hello world fourni sur la page wikipedia puisqu’on veut écrire la même chose) :

++++++++++          affecte 10 à la case 0
[                   boucle initialisant des valeurs au tableau 
   >                avance à la case 1 
   +++++++          affecte 7 à la case 1
   >                avance à la case 2
   ++++++++++       affecte 10 à la case 2 
   >                avance à la case 3
   +++              affecte 3 à la case 3
   >                avance à la case 4
   +                affecte 1 à la case 4
   >                avance à la case 5
   +++++++++++      affecte 11 à la case 5
   <<<<<            retourne à la case 0
   -                enlève 1 à la case 0
]                   jusqu'à ce que la case 0 soit = à 0

La boucle initialise le tableau en 10 itérations et son état est alors :

Case	0	1	2	3	4	5
Valeur	0	70	100	30	10	110

Suite du programme :

>++                 ajoute 2 à la case 1 (70 plus 2 = 72)
.                   imprime le caractère 'H' (72)
>+                  ajoute 1 à la case 2 (100 plus 1 = 101)
.                   imprime le caractère 'e' (101)
+++++++             ajoute 7 à la case 2 (101 plus 7 = 108)
.                   imprime le caractère 'l'  (108)
.                   imprime le caractère 'l'  (108)
+++                 ajoute 3 à la case 2 (108 plus 3 = 111)
.                   imprime le caractère 'o' (111)
>++                 ajoute 2 à la case 3 (30 plus 2 = 32)
.                   imprime le caractère ' '(espace) (32)

<<<                 revient à la case 0
++                  ajoute 2 à la case 0 (0 plus 2 = 2)
[                   une boucle
   >                avance à la case 1 
   --               enlève 4 à la case 1 (72 moins 4 = 68)
   >                avance à la case 2
   -----            enlève 10 à la case 2 (111 moins 10 = 101)
   <<               retourne à la case 0
   -                enlève 1 à la case 0
]                   jusqu'à ce que la case 0 soit = à 0

>                   va case 1
.                   affiche 'D'
>                   va case 2
.                   affiche 'e'
---                 enlève 3 à la case 2 (101 moins 3 = 98)
.                   affiche 'b'
>>>                 va case 5
-----               enlève 5 à la case 5
.                   affiche 'i'
<<<                 va case 2
-                   enlève 1 à la case 2
.                   affiche 'a'
>>>                 va case 5
+++++               ajoute 5 à la case 5
.                   affiche 'n'
<<                  va à la case 3
+                   ajoute 1 à la case 3
.                   affiche un point d'exclamation

>                   va à la case 4
.                   imprime le caractère 'nouvelle ligne' (10)

screenshots.debian.net

Une capture de l’exécution du programme est disponible pour les interpréteurs beef et hsbrainfuck sur screenshot.debian.net.
Les images disponibles sur screenshots.debian.net sont aussi réutilisées par le service packages.debian.org (par exemple packages.debian.org) et par certains gestionnaires de paquets.
Si vous avez envie d’ajouter des captures d’écran à des paquets qui n’en auraient pas (les plus courants sont déjà faits), sachez que l’affichage n’est pas direct car il y a une validation manuelle des images envoyées. Le délai reste limité à quelques jours (voire à la journée).

08 February, 2022 07:50PM by ascendances

April 18, 2021

Florent Gallaire

Debian et RMS, la montagne a accouché d’une souris

Suite au retour de Richard Stallman (RMS) au board de la Free Software Foundation (FSF), pas moins de neuf anciens Debian Project Leader (DPL) – Neil McGovern, Stefano Zacchiroli, Ian Jackson, Lucas Nussbaum, Martin Michlmayr, Mehdi Dogguy, Sam Hartman, Sam Hocevar et Steve McIntyre – ainsi que l’actuel DPL Jonathan Carter, ont signé une lettre ouverte initiée par Molly de Blanc et intitulée An open letter to remove Richard M. Stallman from all leadership positions.

Rappelons que Richard Stallman n’est rien de moins que l’inventeur des quatre libertés essentielles définissant le logiciel libre et du concept juridique de copyleft, ainsi que le fondateur de la Free Software Foundation et du projet GNU (Linux sans le noyau).

Steve Langasek a ensuite soumis une General Resolution (GR) proposant que la personne morale Debian soutienne officiellement la prise de position de ses leaders. Mais rien ne s’est passé comme prévu, et ce qui devait être un référendum consensuel a tourné au pugilat sur la mailing list debian-vote en mars et en avril, ces discussions publiques n’étant bien sûr que la partie émergée de l’iceberg.

Huit options ont finalement été soumises au vote :

« Call for the FSF board removal, as in rms-open-letter.github.io«
« Call for Stallman’s resignation from all FSF bodies »
« Discourage collaboration with the FSF while Stallman is in a leading position »
« Call on the FSF to further its governance processes »
« Support Stallman’s reinstatement, as in rms-support-letter.github.io«
« Denounce the witch-hunt against RMS and the FSF »
« Debian will not issue a public statement on this issue »
« Further Discussion » (default option)

Pour faire court, c’est l’option 7 qui l’a emporté : Debian will not issue a public statement on this issue. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

En s’essayant à un peu de taxinomie politique, on constate que les options peuvent être classées en trois groupes. Les options explicites, anti et pro parlent d’elles-mêmes, mais comment connaître l’orientation d’une option implicite ? Sans la condamner, mais en refusant de participer à une chasse aux sorcières, l’option 7 constitue bien un soutien implicite à RMS. Le nombre de voix par rapport à l’option par défaut Further Discussion est le moyen le plus simple d’évaluer ce vote :

anti-RMS explicite (droite) : options 1, 2, 3 et 4 pour 203 + 222 + 219 + 221 = 216 voix de moyenne
pro-RMS implicite (centre) : option 7 pour 277 voix
pro-RMS explicite (gauche) : options 5 et 6 pour 52 + 84 = 68 voix de moyenne

Concernant les suffrages exprimés, il n’y a donc pas eu de vol de scrutin et la méthode Condorcet évite effectivement les problèmes de type Ballon d’or 2018, où l’éparpillement des voix d’un camp permet à une option minoritaire de l’emporter. En effet, une large majorité des votants voulait la peau de RMS, mais cette large majorité voulait aussi préserver le projet Debian d’une explosion probable, et a permis à l’option centriste de l’emporter de justesse.

Cependant, le système de vote de Debian a failli sur un point fondamental mais qui n’avait pourtant jamais semblé poser problème jusqu’ici. En effet, un vote concernant une General Resolution n’est pas secret, ce qui est une pratique totalitaire qui doit être changée. On peut ainsi consulter le détail des votes de chaque votant. S’agissant d’un sujet aussi controversé, la sincérité du scrutin a très probablement été altérée par un taux de participation inférieur à ce qu’il aurait pu être, avec seulement 420 votants sur 1018 Debian Developers.

18 April, 2021 07:19AM by fgallaire

Highvoltage 2.0 : Jonathan Carter réélu DPL pour 2021

Jonathan Carter (Highvoltage) vient d’être réélu Debian Project Leader (DPL). Il va donc pouvoir continuer le travail commencé l’année dernière.

La victoire de Jonathan est sans surprise, car sans réelle opposition, Sruthi Chandran incarnant pour la seconde année consécutive une candidature de témoignage – non-homme, non-blanc -, mais n’étant malheureusement pas une prétendante crédible à la victoire. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

Bravo à toi Jonathan, et bonne chance dans la mise en œuvre de ton programme !

18 April, 2021 01:47AM by fgallaire

March 21, 2021

Quel DPL pour 2021 ?

Le temps passe vite, et cela fait déjà presque un an que Jonathan Carter a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 7 et le 13 mars à la suite du traditionnel appel à candidatures.

Le 11 mars Jonathan exprimait le souhait de se représenter, tout comme Sruthi Chandran, elle aussi déjà candidate l’année dernière, dans ce qui constituera un remake de l’élection 2020.

Il y aura donc deux candidats cette année :

Les presque mille développeurs Debian seront libres de voter du 4 au 17 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

21 March, 2021 01:02PM by fgallaire

November 17, 2020

test cloud

17 November, 2020 03:46AM by fgallaire

September 27, 2020

Stéphane Blondon

Effet boomerang pour les contributions à du logiciel libre

Lorsqu’on corrige une anomalie ou qu’on a ajoute une fonctionnalité à un logiciel ou une bibliothèque, on peut la garder pour soi ou la partager. La deuxième solution demande un peu plus d’efforts à court terme mais est préférable à long terme.

Le délai de retour d’un correctif ou d’une amélioration dépend de l’endroit où il est proposé : plus il est poussé loin et plus il va mettre de temps à revenir mais le nombre de personnes/machines bénéficiant du correctif sera plus grand.

Les différentes possibilités

Gardé pour soi

Cette méthode est absente du schéma puisqu’elle consiste à ne pas envoyer la modification à l’extérieur. C’est le plus rapide à mettre en œuvre, d’autant plus que la qualité du correctif n’est validée qu’en interne (juste soi-même ou par l’équipe intégrant la modification). Diverses façons d’arriver à ses fins sont possibles comme surcharger la signature de la méthode qui pose problème, attraper l’erreur non traitée correctement, intégrer la bibliothèque dans le code et la modifier directement (vendoring), etc.

Par contre, personne d’autre ne bénéficie du correctif et personne d’extérieur ne fera une revue de code.

Publication solitaire

La vitesse de mise au point est équivalente à la méthode précédente. Le déploiement prend un peu de temps. Elle permet de rendre la modification disponible pour les autres utilisateurs s’ils la trouvent. Ce phénomène est visible avec l’incitation au fork proposée par les forges comme Github, Gitlab, Bitbucket, etc, sans pousser la modification vers le développeur amont (via une pull request). Cette technique est utilisée lorsque des développeurs :

forkent un dépôt,
créent un commit modifiant le nouveau dépôt,
font dépendre leur application de ce commit (npm install git+https://alice@forge...).

Cependant, ce comportement n’est pas limité aux forges publiques : il existait déjà avant en publiant le correctif dans un article de blog, une liste de diffusion (liste non exhaustive).

Envoyé vers la distribution

La correction est envoyée dans la distribution Linux utilisée ; c’est souvent fait en incluant la modification dans un fichier, attaché à un rapport de bogue sur la distribution.

Une fois que la modification sera intégrée et qu’un nouveau paquet sera publié, l’ensemble des utilisateurs, y compris l’auteur, en bénéficieront. Cela évite de maintenir la modification de son côté lorsque de nouvelles versions du paquet seront publiées. La durée d’intégration est plus longue selon la réactivité du mainteneur du paquet et le mode de publication (version espacée ou rolling release). Bien évidemment, le bénéfice de la modification sera perdu en cas de changement de distribution.

Cette solution est nécessaire pour corriger/améliorer un élément spécifique d’un paquet de la distribution. Cela peut arriver dans deux cas :

soit parce que c’est un paquet spécifique à la distribution (le paquet apt pour debian par exemple)
soit parce qu’une modification du logiciel spécifique à la distribution a une influence sur la modification soumise

Envoyé vers le développeur amont

Plutôt que d’envoyer le correctif vers la distribution utilisée, il est alors envoyé directement vers le développeur du logiciel. Si le développement est hébergé sur une forge publique, cela suppose le faire un fork (comme dans le cas d’une publication solitaire), puis de faire une pull request (terme Github), merge request (terme Gitlab). Sinon, il faut regarder quelle est la forme attendue : en postant sur une liste de diffusion, ou directement vers le mainteneur, etc. Il sera nécessaire de répondre aux remarques et demandes de corrections pour que la modification soit intégrée dans le logiciel amont.

Comme dans le cas d’une intégration dans la distribution, une fois intégrée, la modification sera disponible pour tous :

soit en réutilisant le logiciel directement via le paquet issus du langage (par exemple gem pour ruby, wheel pour python, crate pour Rust, etc.)
soit parce que la version du logiciel sera elle aussi intégrée dans la distribution et donc obtenue dans un paquet de la distribution

Ce type de contributions sont les plus longues à revenir au contributeur mais elles permettent le déploiement le plus large (et donc la plus grande disponibilité pour soi et pour les autres).

Autres considérations

S’il n’est pas possible d’attendre le retour de la modification, la solution optimale est de faire un correctif local et un envoi vers la distribution ou vers le développeur amont (pour qu’une solution long terme soit aussi disponible automatiquement).

Pour bénéficier de l’envoi amont, il faut que le temps de retour soit inférieur au temps de changement de techno/bibliothèque. Dans un écosystème où les outils et bibliothèques sont abandonnés très rapidement, l’effort d’intégration peut être perçu comme vain puisque la personne ayant fait le développement aura peu le temps d’en profiter. D’un point de vue général, avec une majorité de personnes faisant ce calcul, cela ne fait qu’empirer le problème, avec des multitudes de fork s’ignorant mutuellement, chacun avec une fonctionnalité ou une correction différente. Javascript me semble être dans cette situation.

À propos du schéma

Le schéma a été réalisé avec Dia, installable par le paquet du même nom pour Debian et dérivées.
Fichier source .dia

27 September, 2020 07:09PM by ascendances

April 19, 2020

Florent Gallaire

Jonathan Carter élu DPL pour 2020

C’est Jonathan Carter qui vient d’être élu Debian Project Leader (DPL) pour l’année 2020, succédant ainsi à Sam Hartman qui avait été élu en 2019.

Arrivé l’an passé derrière Sam Hartman presque à égalité avec Martin Michlmayr et Joerg Jaspert, Jonathan l’emporte logiquement cette année dans une élection sans réelle concurrence.

En effet, Brian Gupta avait immédiatement indiqué que le seul objet de sa candidature était de constituer un référendum, qui s’est révélé peu concluant, sur la création des fondations Debian US et Debian Europe ; tandis que la jeune indienne Sruthi Chandran, dont on devrait réentendre parler dans les prochaines années, manquait de légitimité pour le poste n’étant développeuse Debian que depuis un an.

Bravo à toi Jonathan, et bonne chance dans la mise en œuvre de ton programme !

19 April, 2020 02:18AM by fgallaire

June 05, 2019

Grégory Colpart

Mini-DebConf Marseille 2019 (fr)

L’idée d’organiser une mini-DebConf à Marseille est née à Toulouse en 2017 : après avoir participé avec plaisir à plusieurs (mini)DebConfs, se lancer dans l’organisation d’un tel évènement est une manière de rendre la pareille et de contribuer à Debian !

Fin 2018, après avoir réuni les personnes motivées, nous avons choisi la date du 25/26 mai 2019 et dimensionner l’évènement pour 50 à 70 personnes en sélectionnant un lieu approprié au centre-ville de Marseille. Je ne vais pas m’attarder ici sur détails de l’organisation (appel à conférences, enregistrement des participants, composition du programme etc.), car nous allons publier bientôt un « Howto Organizing a mini-DebConf » pour partager notre expérience.

Tout a commencé dès le mercredi 22 mai, où la formidable équipe vidéo DebConf s’est réunie pour un sprint de 3 jours pour préparer la couverture de l’événement avec le matériel déjà arrivé et former les membres qui gèreront le matériel pour la mini-DebConf Hambourg.

Vendredi 24 mai, l’équipe de traduction francophone de Debian est arrivée pour un sprint d’une journée. La plupart d’entre eux ne s’était jamais rencontré physiquement !

Une majeure partie des participants sont arrivés dans l’après-midi du vendredi 24 mai. Le bureau d’accueil (Front-Desk) était déjà prêt, et les arrivants ont pu récupérer leur badge et un T-shirt de l’événement. Pour des raisons écologiques, nous avions décidé de minimiser les goodies offerts au participants donc pas de sacs ou papiers superflus, mais un booklet distribué en amont. Si besoin, des goodies Debian (stickers, casquettes, polos, etc.) étaient aussi en vente au Front-Desk.

La soirée de vendredi a débuté avec un mini-CheeseWineBOF avec des denrées locales (fromages, vins, pastis, olives, fruits et légumes) et apportées par des participant(e)s : merci à Valhalla pour fromage italien, ainsi qu’à Urbec et Tzafrir !

La soirée de vendredi s’est poursuivie : pendant que l’équipe vidéo finalisait son installation dans la salle de conférence, les participants ont été invités à une réunion du Linux Users Group de Marseille : une présentation de Florence Devouard, pionnière de Wikipédia, qui est revenue l’historique de Wikipédia/Wikimédia avec de nombreuses anecdotes. La soirée s’est achevée avec une tradition locale : la dégustation de pizzas marseillaises. Le week-end n’est pas encore commencé, et déjà de bons moments sont partagés entre les participants !

Samedi matin, c’était le coup d’envoi officiel de la mini-DebConf ! Ouverture des portes à 8h30 pour le petit déjeuner : cookies fait-maison, café en grains, nous avons proposé durant tout le week-end de la cuisine locale, fait-main et végétarienne. Autre objectif : minimiser les déchets, et dans cette optique nous avons réfléchi à différents dispositifs : couverts en dur, tasses à étiqueter, Ecocups, etc.

75 participants s’étaient inscrits, ce qui correspondait au maximum de la capacité du lieu. Et 73 sont effectivement venus, ce qui est un bel exploit, notamment pour une conférence totalement gratuite. Si l’on compte quelques participants non-inscrits, nous avons été au total plus de 75 participants, soit au-delà de nos espérances !

À 9h45, c’est la conférence d’ouverture ! Jérémy déroule le programme du week-end, remercie les sponsors et rappelle le Code of Conduct, le système d’autorisations pour les photos, etc.

À 10h, c’est parti pour la première conférence ! Les choses sérieuses débutent : Cyril Brulebois – release manager du Debian Installer – détaille le fonctionnement de la migration d’un package vers Testing, et propose une solution pour visualiser les dépendances entre les packages et comprendre ainsi pourquoi un package peut être bloqué.

On enchaîne ensuite avec Peter Green – co-fondateur du projet Raspbian – qui présente l’outil autoforwardportergit qu’il utilise pour automatiser la création de packages Debian modifiés pour Raspbian.

Après une pause-café, c’est Raphaël Hertzog qui revient sur 5 ans du projet Debian LTS (Long Term Support). Il explique l’historique ainsi que le fonctionnement : la gestion des sponsors, le travail réparti entre plusieurs développeurs, l’offre extended LTS, l’infrastructure. Le sujet du financement des contributeurs provoquera plusieurs questions et suscitera un Lightning Talk sur le sujet dimanche matin.

Durant le midi, pendant que l’infatiguable équipe vidéo forme des débutants à ses outils, un déjeuner est servi sous forme de buffet végétalien ou végétarien. Nous sommes fiers d’avoir réussi à offrir une cuisine fait-maison avec des produits frais et locaux, et sans gâchis grâce à une bonne gestion des quantités.

Après le déjeuner, c’est l’heure de la KSP (Key Signing Party) organisée par Benoît. L’occasion pour chacun d’échanger des signatures de clés GPG et de renforcer le réseau de confiance.

Et l’on repart pour un cycle de conférences, avec Elena “of Valhalla” Grandi qui présente le protocole ActivityPub pour des réseaux sociaux fédérés comme Mastodon, Pixelfed, etc.

C’est au tour de Laura Arjona Reina venue de Madrid pour présenter la Welcome Team au sein de Debian qui œuvre pour accueillir les nouveaux arrivants.

Ensuite, Denis Briand – fraîchement élu président de Debian France – nous parle de l’association Debian France, de son but, de ses actions et de ses projets.

C’est au tour de Frédéric Lenquette d’aborder le sujet « Hardening and Secure Debian Buster » en explorant toutes les possibilités de sécurisation d’une Debian 10.

Enfin, dernière conférence de la journée de samedi : une partie de l’équipe de traduction francophone (Thomas Vincent, Jean-Philippe Mengual and Alban Vidal) présente son travail : comment fonctionne le travail en équipe, quelles tâches peuvent être faites par des débutants, etc.

Samedi soir, fin de la première journée : tous les participants sont invités à prolonger les échanges à la Cane Bière, un bar proche de la mini-DebConf.

Dimanche matin, on repart avec une présentation de l’équipe vidéo (représentée par Nicolas Dandrimont et Louis-Philippe Véronneau) qui révèle ses secrets pour assurer la couverture vidéo des (mini)DebConfs !

Puis on enchaîne avec une session de 6 Lightning Talks animés par Eda : « kt-update » (Jean-François Brucker), « the Debian Constitution » (Judit Foglszinger), « Elections, Democracy, European Union » (Thomas Koch), les méthodes de vote de Condorcet et du Jugement Majoritaire (Raphaël Hertzog), « encrypt the whole disk with LUKS2 » (Cyril Brulebois), « OMEMO – the big fish in the Debian bowl » (Martin) et « Paye ton Logiciel Libre » (Victor).

Après quelques mots pour clôturer les conférences, c’est déjà l’heure du rangement pour certains, tandis que d’autres en profitent pour faire un mini-DayTrip : descendre la Canebière à pied et embarquer au Vieux Port pour l’archipel du Frioul pour marcher et nager !

Nous remercions les 75 participant(e)s venus du monde entier (Canada, USA, Israël, Angleterre, Allemagne, Espagne, Suisse, Australie, Belgique etc.) ! Nous remercions également la fantastique équipe vidéo qui réalise un travail remarquable et impressionnant de qualité. Nous remercions Debian France qui a organisé l’événement, et les sponsors : Bearstech, Logilab et Evolix. Nous remercions la Maison du Chant de nous avoir mis à disposition les locaux. Nous remercions Valentine et Célia qui ont assuré tous les repas, il y a eu de nombreux compliments. Nous remercions Florence Devouard d’avoir assuré une belle présentation vendredi soir, ainsi que tous les orateurs(ices) de la mini-DebConf. Et je tiens à remercier tous les bénévoles qui ont assuré la préparation et le bon déroulement de l’événement : Tristan, Anaïs, Benoît, Juliette, Ludovic, Jessica, Éric, Quentin F. et Jérémy D. Mention spéciale à Eda, Moussa, Alban et Quentin L. pour leur implication et leur motivation, et à Sab et Jérémy qui se sont plongés avec moi dans cette folle aventure depuis plusieurs mois : you rock guys !

Twitter : https://twitter.com/MiniDebConf_MRS
Mastodon : https://mamot.fr/@minidebconf_mrs
Photos : https://minidebcloud.labs.evolix.org/apps/gallery/s/keMJaK5o3D384RA
Vidéos : https://ftp.acc.umu.se/pub/debian-meetings/2019/miniconf-marseille

05 June, 2019 01:57PM by Gregory Colpart

January 08, 2019

Stéphane Blondon

Processeur Intel -> Architecture AMD64 pour Debian

TL;DR

Nom courant	Dénomination Debian	Disponibilité
x86	i386	rarement en vente après 2010
x86_64	amd64	à moins d’acheter des ordinateurs spécifiques, il n’y a plus que ça pour le grand public

Si vous venez d’acheter un ordinateur, choisissez amd64.

L’histoire, avec un grand L

Intel avait conçu une architecture 8086, améliorée successivement jusqu’au 286 (un processeur 16 bits).
Au milieu des années 80, Intel améliore cette architecture qui devient 32 bits (avec les dénominations commerciales 386 puis 486, Pentium, Pentium II, etc.), nommée i386 par Debian, communément appelée x86. Cette architecture est aussi parfois nommée ia32 pour « Intel Architecture 32 bits ». D’autres constructeurs de processeurs comme AMD ou Cyrix concevaient des processeurs compatibles. C’est donc cette même architecture (i386) qui devait être utilisée pour ces processeurs.

Puis Intel décida de faire un nouveau processeur, 64 bits, incompatible avec les x86. Associé à HP, une nouvelle gamme de processeur, Itanium, voit le jour en 2001. La dénomination Debian est donc ia64 (« Intel Architecture 64 bits »). C’est un échec commercial, dû à des performances décevantes et l’absence de compatibilité ascendante. Cette gamme sera arrêtée dans l’indifférence générale en 2013.

Parallèlement à Intel, AMD décide d’étendre le processeur x86 pour qu’il fonctionne en 64 bits tout en ayant une compatibilité 32 bits. Cette architecture est souvent appelée x86_64, parfois x64. En 2003, AMD vend l’Athlon 64, premier processeur disponible au public de cette nouvelle architecture. Debian la désigne par le terme amd64. Des accords entre AMD et Intel permettant aussi à Intel de produire cette architecture, Intel a emboîté le pas à AMD et produit aussi des processeurs compatibles amd64. C’est pourquoi les processeurs modernes Intel nécessitent cette architecture lors de l’installation d’un système Debian.

D’autres architectures moins connues voire complètement oubliées existent

Debian est installable sur de nombreuses autres architectures, mais qui ne sont pas orientées grand public. La seule exception étant peut-être ARM avec les cartes RaspberryPi (cf. wiki).

Des exemples d’autres architectures et processeurs associés : https://lists.debian.org/debian-www/2017/10/msg00125.html (à la toute fin du message)

08 January, 2019 09:10PM by ascendances

October 16, 2018

Didier Raboud

Raksha – Une idée

J’étais donc ce week-end en cours CG (responsables de groupes) pour l’ASVd à Froideville. Je tombe sur une conversation entre Chat et Pélican au sujet du lancement d’une commission IT au niveau cantonal pour fournir des services aux groupes du canton.

On continue la discussion, qui embraie rapidement sur un échange d’idées sur Framasoft, MiData (db.scout.ch) et les différentes initiatives pour fournir des services IT aux groupes scouts du canton.

Pour un petit historique, il y’a déjà eu plusieurs initiatives dans ce sens, mais actuellement, je n’ai pas connaissance d’équipes actives ou fonctionnelles pour ça:

Pour l’ASVd:
- un bénévole s’occupe des services cloud (NextCloud), email, listes et site Internet (WordPress).
- des groupes DropBox continuent d’exister.
Pour les groupes:
- rien de centralisé, mais différentes initiatives isolées naîssent et meurent (Trello, Mattermost, etc)

Bref. La discussion a finalement tourné autour des idées suivantes:

Un service scout
S’inspirer de ce que fait Framasoft et les collectifs Chatons: décentraliser les services et reprendre le contrôle!
Commencer petit; proposer quelque chose de spécifique aux scouts suisses, voir même scouts vaudois pour commencer.
Tirer profit du bénévolat, mais couvrir tous les frais
Offrir des services « collectifs » (une instance cloud par canton) et « spécifiques » (une instance Mattermost par groupe)
Avoir des ambitions techniques élevées:
- uniquement du logiciel libre
- automatisation des processus
- confiance dans les données (backup)
- monitoring des services
- intégrations qui font sens
- authentification unifiée
- reproductibilité du projet

Tout ça est évidemment à discuter, clarifier, raffiner, prioriser avec les premiers intéressés. Mais… Je cherchais un nom, en rapport autant avec le champ lexical des chats (Chatons) et du scoutisme. J’avais d’abord pensé à « gamelle », qui me plaisait bien, mais tous les `.ch` étaient pris. « Veillée », vraiment bien, et veillée.ch est libre; mais il y’aurait confusion avec le même nom sans accent.

En feuilletant mon Livre de la Jungle de poche (non, non, en vrai: https://fr.wikipedia.org/wiki/Le_Livre_de_la_jungle#Les_animaux ), j’ai commencé à parcourir les différents animaux de l’histoire en testant leur disponibilité en .ch . Et c’est là que Mère Louve; Raksha, est apparue libre!

Raksha : la louve grise, également appelée Mère-Louve ou La démone, mère adoptive de Mowgli. Elle le défend lorsque Shere-Khan le réclame à l’entrée de sa tanière.

C’est plutôt un bon nom: les scouts avec une âme de louveteaux reconnaîtront le nom immédiatement, et c’est également un animal qui a des petits par portées, avec un aspect de défense des intérêts des scouts, et un aspect de collectif. Des chatons au louveteaux, on n’est pas très loin!

Bref. On doit se voir pour en discuter!

16 October, 2018 08:15AM by OdyX

August 31, 2018

Louis-Philippe Véronneau

Introduction à Gitlab CI

Voici les notes de l'atelier d'introduction à Gitlab CI que je donne le 23 septembre dans le cadre de la Semaine québécoise de l'informatique libres.

Pourquoi faire de l'intégration continue?

Il y a plusieurs bonnes raisons pour commencer à faire de l'intégration continue (CI). En voici quelques unes:

Tester son code. Souvent, l'intégration continue est une bonne manière de commencer à tester son code. Les tests automatisés permettent de trouver des erreurs d'inattention et forcent à vérifier si le code que l'on écrit fonctionne réellement.
Tester son code sur des environnements radicalement différents. Avoir des tests que l'on peut faire rouler localement sur sa machine est une bonne chose, mais utiliser un CI permet de tester son code sur des environnements sur lesquels on ne travaille pas.
Tester son code automatiquement. Utiliser un CI lié à une plateforme d'hébergement git permet de s'assurer que les nouveaux commits réussissent les tests avant d'être ajoutés à la branche master.
Déployer son code automatiquement. Il est possible d'aller une étape plus loin et d'utiliser le CI pour publier du code sur une archive comme PyPi ou NPM automatiquement si tous les tests passent. On parle alors de déploiement continu (CD).

Introductions aux fonctionnalités de Gitlab CI

Aperçu

Pour utiliser Gitlab CI, il faut tout d'abord avoir un projet sur une instance Gitlab. Quand on ajoute un commit git au dépôt, si un fichier .gitlab-ci.yml est présent dans le dépôt, Gitlab suit ces instructions et roule un script dans le runner, une machine externe qui sert à faire des tests.

Sur la plupart des instances Gitlab, il existe des runners partagés que tout le monde peut utiliser. Il est également possible de monter un runner privé pour son propre projet. Cela peut être intéressant si on a des tests qui demandent beaucoup de ressources.

Le fichier .gitlab-ci.yml

Pour commencer à utiliser Gitlab CI, il faut tout d'abord créer un fichier .gitlab-ci.yml.

Voici un exemple très simple de fichier:

---
image: debian:stable

test12345:
  script:
  - echo 'deb http://deb.debian.org/debian buster main contrib non-free' >> /etc/apt/sources.list
  - apt-get update
  - apt-get install -y -t buster rolldice
...

La première partie du fichier est le paramètre image. C'est l'image docker qui va être utilisée par défaut dans les tests que l'on effectue. Cette image est récupérée du Docker Hub. Pour utiliser une image, on spécifie le tag complet de l'image. Ainsi, l'image pour la version stable de Debian est debian:stable.

La seconde partie du fichier est le test que l'on roule. Il est possible d'avoir plusieurs tests l'un à la suite de l'autre. Le test dans notre exemple est nommé test12345, mais il aurait été possible de le nommer d'une autre manière. apt:rolldice aurait également été un nom valide.

Chaque test doit comporter un script. Ce script est un ensemble de commandes shell de type bash. L'ensemble des commandes que l'on souhaite effectuer s'y retrouvent étapes par étapes.

Il est possible d'avoir plusieurs tests l'un à la suite de l'autre:

---
image: debian:stable

apt:rolldice:stable:
  script:
  - apt-get install -y rolldice

apt:rolldice:buster:
  script:
  - echo 'deb http://deb.debian.org/debian buster main contrib non-free' >> /etc/apt/sources.list
  - apt-get update
  - apt-get install -y -t buster rolldice
...

Il est également possible de changer l'image par défaut utilisée dans un test:

---
image: debian:stable

apt:rolldice:stable:
  script:
  - apt-get install -y rolldice

apt:rolldice:buster:
  image: debian:buster
  script:
  - apt-get install -y rolldice
...

Les fichiers présents dans votre dépôt git sont accessibles par vos scripts comme si vous travailliez directement dans ce dossier:

> foobar.txt

Hello World

> .gitlab-ci.yml

---
image: debian:stable

test:hello:
  script:
  - cat foobar.txt
  - cat foobar.txt | grep "Hello World"
...

Le paramètre service

Pour certains tests plus complexes, il est parfois nécessaire d'avoir un service externe différent de notre image docker principale, par exemple une base de données.

Gitlab CI permet de rouler un service externe accessible par nos tests. Ces services sont également des images Docker. Par voici un exemple simple d'utilisation d'une base de données:

> mytest.sql

CREATE TABLE `table1` (randomvar VARCHAR(30) NOT NULL);
CREATE TABLE `table2` (randomvar VARCHAR(30) NOT NULL);
CREATE TABLE `table3` (randomvar VARCHAR(30) NOT NULL);
CREATE TABLE `table4` (randomvar VARCHAR(30) NOT NULL);

> .gitlab-ci.yml

---
image: debian:stable

services:
  - mariadb:10.1

variables:
  MYSQL_DATABASE: mytest
  MYSQL_ALLOW_EMPTY_PASSWORD: 1

test:mariadb:
  script:
  - apt-get update && apt-get -y install mariadb-client-10.1
  - mariadb -u root -h mariadb -D mytest < mytest.sql
  - mariadb -u root -h mariadb -e "SELECT * FROM information_schema.columns WHERE table_schema = 'mytest'";
...

N'importe quelle image Docker peut être utilisée comme service. Si vous avez des besoins particuliers, il est nécessaire de créer une image Docker par vous même.

Artifacts

Si vous souhaitez utiliser Gitlab CI pour compiler du code ou créer des fichiers que vous souhaitez conserver par la suite, il est nécessaire d'utiliser le paramètre artifacts. Sa fonction est de spécifier un fichier ou un dossier qui va être enregistré par Gitlab et que vous allez pouvoir récupérer par la suite.

> input.md

# Hello World

This is a markdown test. It should be rendered to HTML properly using the great
[pandoc](https://pandoc.org/MANUAL.html).

> .gitlab-ci.yml

---
image: debian:stable

build:html:
  script:
  - apt-get update && apt-get -y install pandoc
  - pandoc -o output.html input.md
  artifacts:
    paths:
    - output.html
...

Tests à plusieurs étapes

Par défaut, les tests dans Gitlab CI fonctionnent tous simultanément. Cela est pratique pour des tests de type unit test. Pour des tests plus élaborés, on peut parfois vouloir fonctionner par étapes et créer des dépendances entre nos tests.

Le paramètre stage permet de spécifier des groupes dans lesquels on peut placer nos différentes tâches. Ces groupes peuvent par la suite être ordonnés, pour que les tests roulent dans un ordre précis.

On peut également utiliser le paramètre dependencies pour créer un lien de dépendance entre différentes tâches. Les artifacts créés dans une tâches sont automatiquement passés à une seconde tâche si elle en dépend.

> hello.c

#include 

int
main (void)
{
  printf ("Hello, world!\n");
  return 0;
}

> .gitlab-ci.yml

---
stages:
  - build
  - test

compile:debian:
  image: debian:stable
  stage: build
  script:
  - apt-get update && apt install -y build-essential
  - gcc -Wall hello.c -o hello
  artifacts:
    paths:
    - hello

compile:alpine:
  image: alpine
  stage: build
  script:
  - apk add --update build-base
  - gcc -Wall hello.c -o hello
  artifacts:
    paths:
    - hello

test:debian:
  image: debian:stable
  stage: test
  dependencies:
  - compile:debian
  script:
  - ./hello

test:alpine:
  image: alpine
  stage: test
  dependencies:
  - compile:alpine
  script:
  - ./hello
...

Variables secrètes

Si vous souhaitez utiliser Gitlab pour publier votre projet sur une plateforme comme PyPi ou NPM, il est nécessaire de stocker vos informations d'authentification quelque part.

Il n'est bien évidemment pas recommandé d'ajouter vos mots de passes directement dans votre fichier .gitlab-ci.yml ou dans un autre fichier dans votre dépôt git pour des raisons de sécurité: n'importe qui pourrait lire ces fichiers et compromettre vos comptes.

Gitlab permet de stocker des variables secrètes. Pour ce faire, il faut aller dans l'onglet Settings > CI/CD > Variables de votre projet.

Une fois que vous avez créé une variable secrète, il est possible d'y référer comme une variable normale dans votre fichier .gitlab-ci.yml.

---
image: debian:stable

test:secret-var:
  script:
  - apt-get update && apt-get -y install wget
  - wget https://agendadulibre.qc.ca/events/$SECRET
...

Compiler et héberger un site web statique à l'aide de Gitlab CI et Gitlab Pages

Un cas de figure intéressant pour Gitlab CI est la compilation d'un site web statique. Une fois compilé, ce site web peut par la suite être hébergé directement sur Gitlab grâce au projet Gitlab Pages. Cela peut être utile pour héberger la documentation d'un projet.

Voici un exemple de projet utilisant Gitlab CI et Gitlab Pages. Ce projet utilise Sphinx avec le thème Read the Docs. Le site web compilé est disponible en ligne ici.

Une fois que l'on a ajouté un fichier .gitlab-ci.yml qui compile notre site statique, il faut aller dans l'onglet Settings > Pages de notre projet git pour mettre en ligne notre projet. Gitlab offre également la possibilité d'utiliser un domaine externe.

Plus d'informations

La documentation complète du fichier .gitlab-ci.yml est disponible en ligne.

Atelier collaboratif d'utilisation de Gitlab CI

Trouvez un projet qui vous intéresse et tentez de créer une série de tests ầ l'aide de Gitlab CI.

Instructions pour installer Gitlab CI + Docker sur une machine privée (avancé)

On souhaite installer Docker et Gitlab CI sur un serveur Debian Stretch. Ces étapes nécessitent une certaine connaissance de la ligne de commande.

Docker

L'executor Docker est le plus simple et le plus flexible. C'est également celui qui est mis en place sur gitlab.com.

On commence donc par installer Docker sur notre machine. En temps normal, on installerait Docker à partir du dépôt officiel Debian. Malheureusement, Docker n'est pas packagé dans Debian alors il est nécessaire de l'installer à partir du dépôt offert par Docker.

On commence par ajouter un fichier source à apt:

> /etc/apt/sources.list.d/docker.sources

Types: deb
URIs: https://download.docker.com/linux/debian/
Suites: stretch
Architectures: amd64
Components: main
Signed-By: /usr/share/keyrings/docker-archive-keyring.gpg

On complète l'installation en téléchargeant la clef GPG et en installant les packets¹:

$ apt install apt-transport-https
$ curl https://download.docker.com/linux/debian/gpg | gpg --dearmor > /usr/share/keyrings/docker-archive-keyring.gpg
$ apt update
$ apt install docker-ce

Docker a la fâcheuse habitude de démarrer avant que l'interface réseau ne soit en ligne. Cela fait en sorte que quand notre machine redémarre, notre CI n'a plus accès à internet, ce qui fait avorter nos tests.

Pour remédier à ce problème, on créé un fichier cron qui redémarre Docker 30 secondes après que notre machine ait démarrée:

$ sudo echo '@reboot root /bin/sleep 30 && /bin/systemctl restart docker' > /etc/cron.d/docker-reboot

On souhaite également éviter que notre serveur se remplisse des instances de test que l'on fait rouler. On ajoute donc un autre fichier cron pour purger Docker périodiquement:

$ sudo echo '0 3 * * * root /usr/bin/docker system prune -a -f > /dev/null 2>&1' > /etc/cron.d/docker-prune

Et voilà! Docker est prêt à être utilisé dans notre installation future de Gitlab CI!

Gitlab CI

Encore une fois, plutôt que d'utiliser le dépôt Gitlab offert par Debian pour installer Gitlab CI, on choisi plutôt le dépôt offert par Gitlab.

Gitlab est encore très jeune dans Debian et il y de nombreuses mises à jour de sécurité. Peut-être dans le futur les paquets Debian vont être plus fiables, mais ce n'est pas le cas pour l'instant.

On commence par ajouter un fichier source à apt:

> /etc/apt/sources.list.d/gitlab.sources

Types: deb
URIs: https://packages.gitlab.com/runner/gitlab-runner/debian/
Suites: stretch
Architectures: amd64
Components: main
Signed-By: /usr/share/keyrings/gitlab-archive-keyring.gpg

On complète l'installation en téléchargeant la clef GPG et en installant les packets:

$ curl https://packages.gitlab.com/gpg.key | gpg --dearmor > /usr/share/keyrings/gitlab-archive-keyring.gpg
$ apt update
$ apt install gitlab-runner

Une fois gitlab-runner installé, on peut utiliser l'outil en ligne de commande pour créer un nouveau runner:

$ sudo gitlab-runner register
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
> https://url-de-l-instance-gitlab
Please enter the gitlab-ci token for this runner:
> le-token-de-votre-projet                 
Please enter the gitlab-ci description for this runner:
> La description du runner
Please enter the gitlab-ci tags for this runner (comma separated):
> nom-du-runner-gitlab-ci, docker

Pour obtenir le token nécessaire à la création du runner, il faut aller dans l'onglet Settings > CI/CD > Runners dans votre projet git. Le token est spécifié dans la section Setup a specific Runner manually.

Et voilà! Si tout fonctionne correctement, le runner devrait s'afficher dans la l'onglet Settings > CI/CD > Runners de votre projet.

Pro Tip

Si vous utilisez votre propre runner Gitlab CI dans un environnement en production, il est important de s'assurer que ce dernier fonctionne pour s'éviter de fâcheux ennuis.

Pour s'assurer que notre runner est fonctionnel, on peut créer un projet git dont le seul but est de s'assurer que le CI fonctionne. Ce dernier n'a qu'à contenir un fichier .gitlab-ci.yml de base.

Par la suite, vous pouvez faire rouler le test à tous les jours ou à toutes les heures en créant un nouvel item dans dans l'onglet CI/CD > Schedules de votre projet.

Voici un exemple de fichier gitlab-ci.yml que l'on peut utiliser:

---
image: debian

test-ci:
  script:
  - apt-get update && apt-get -y install rolldice
  tags:
    - nom-du-runner-gitlab-ci
...

Il est bien important de spécifier le nom du runner sur lequel vous souhaitez que le test roule dans la section tags pour éviter de faire le test sur une autre machine que la vôtre.

Cette méthode est bien plus sécuritaire qu'utiliser apt-key add car elle elle autorise la clef GPG externe seulement pour la source que l'on souhaite ajouter et non pour toutes les autres sources. Plus de détails sur cette méthode ici. ↩

31 August, 2018 04:00AM by Louis-Philippe Véronneau

April 21, 2017

Raphaël Hertzog

Le logiciel libre a t’il une couleur politique ?

En pleine campagne présidentielle, après avoir échoué à obtenir les parrainages pour Charlotte Marchandise, j’ai décidé de soutenir Jean-Luc Mélenchon.

Il se trouve que le volet numérique du programme de la France Insoumise est très bien ficelé et fait la part belle aux logiciels libres.

Mais face aux enjeux, ce n’est évidemment pas mon seul critère de choix. L’élément décisif pour ma part est la mise en place d’une assemblée constituante avec des citoyens tirés au sort pour changer nos institutions et notre système électoral à bout de souffle. Il nous faut le jugement majoritaire (cliquez le lien pour tester la méthode sur cette élection présidentielle) pour en finir avec le vote utile. Il faut dépasser la monarchie présidentielle et apprendre à travailler ensemble pour le bien de tous.

Mais même en allant au delà de ces deux aspects, je me retrouve en accord avec le programme de la France Insoumise sur la quasi totalité des thématiques sauf l’Europe et sur le revenu universel (qui est absent!).

Pour autant, je n’aime pas le personnage de Jean-Luc Mélenchon (ce n’est pas pour rien que je soutenais Charlotte Marchandise) et son historique politique (cumul dans le temps…) n’est pas en phase avec mes convictions, mais il n’y a pas de candidat parfait et il a promis de démissionner une fois la nouvelle constitution en place alors je m’en accommode.

Bref, pour en revenir avec le sujet de mon article, très peu de candidats[1] à la présidence ont pris des positions aussi claires en faveur des logiciels libres alors je m’interroge. Est-ce un hasard que le seul projet qui défend le logiciel libre soit aussi celui qui me correspond le mieux par ailleurs ? Ou bien est-ce que le fait que je fasse partie de la communauté du logiciel libre peut avoir une relation avec le côté humaniste/progressiste/écologiste qui m’attire en politique ?

J’ai l’habitude de présenter le logiciel libre comme apolitique, car les gens de gauche y voient un modèle de coopération et de partage des communs, et les gens de droite y voient la liberté totale et un marché ouvert avec une concurrence parfaite. Et parfois j’ai l’impression que cette distinction se retrouve aussi dans la différence de terminologie « logiciel libre » vs « open-source »…

L’existence même de ces deux tendances discréditerait alors la corrélation que je semble observer. Mais tout de même, lorsqu’on parle de « communauté du logiciel libre » j’ai remarqué que ceux qui se reconnaissent derrière ce label sont plutôt des contributeurs qui sont portés par des motivations (au moins partiellement) altruistes et lorsque je discute avec d’autres contributeurs bénévoles aussi impliqués que moi, il est assez rare que je tombe sur des personnes avec des valeurs en forte opposition aux miennes.

Ceux pour qui le logiciel libre se résume à l’open-source ne semblent pas s’identifier à la notion de communauté du logiciel libre et sont moins impliqués/présents/visibles dans les événements qui fédèrent les communautés (conférences, sprints, etc.).

Qu’en dites-vous ? Faites-vous le même constat que moi ? Ou bien avez-vous une expérience diamétralement opposée à la mienne ?

Il est possible (voire probable) que la communauté Debian (dont je fais partie) ne soit pas forcément représentative de l’ensemble de la communauté du libre. L’existence même du contrat social comme texte fondateur explique peut-être un biais vers le côté humaniste/progressiste.

En tout cas, avec le nombre de chercheurs qui ont déjà étudié les développeurs de logiciels libres, je m’étonne que cette problématique n’ait pas encore été étudiée. Si vous connaissez une étude à ce sujet, partagez la dans les commentaires, cela m’intéresse et je rajouterai volontiers un lien dans l’article.

[1] François Asselineau soutient aussi le logiciel libre. Mais j’ai l’impression que c’est plus par anti-impérialisme américain — car les logiciels propriétaires dominants viennent de là — que par conviction.

21 April, 2017 12:36PM by Raphaël Hertzog

February 13, 2017

Mes activités libres en janvier 2017

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

Ce mois-ci ce sont 10 heures de travail sur les mises à jour de sécurité pour Debian 7 Wheezy qui ont été subventionnées. Elles ont été consacrées aux tâches suivantes :

J’ai passé en revue de multiples CVE affectant ntp, et décidé de les marquer comme « no-dsa » (de manière identique à ce qui a été réalisé pour Jessie);
J’ai relancé les auteurs amont de jbig2dec (ici) et XML::Twig (par message privé) concernant les rapports de bogue n’ayant pas encore eu de retour de leur part;
J’ai demandé plus de détails sur la liste oss-security au sujet de la CVE-2016-9584, car le fait qu’elle ait déjà été remontée à l’amont n’était pas évident. Il s’est avéré que c’était bien le cas, j’ai donc mis à jour le suiveur de sécurité en conséquence;
Après avoir obtenu une réponse sur jbig2dec, j’ai commencé à rétroporter le patch désigné par l’amont, ce qui ne fut pas chose facile. Lorsque cela a été fait, j’ai également reçu le fichier permettant de reproduire le problème qui est à l’origine du rapport… et qui ne provoquait malheureusement plus le même problème avec la vieille version de jbig2dec présente dans Wheezy. Cela étant, Valgrind a tout de même identifié des lectures en-dehors de l’espace mémoire alloué. C’est à partir de cet instant que j’ai examiné avec plus d’attention l’historique Git, et découvert que les trois dernières années n’avaient vu principalement que des correctifs de sécurité pour des cas similaires n’ayant jamais été remontés en tant que CVE. En conséquence, j’ai ouvert une discussion sur comment régler cette situation;
Matthias Geerdsen a remonté dans le n°852610 une régression concernant libtiff4. J’ai confirmé le problème et passé de nombreuses heures à élaborer un correctif. Le patch ayant entraîné la régression était spécifique à Debian, car l’amont n’avait pas encore corrigé le problème. J’ai publié un paquet mis à jour dans la DLA-610-2.

Empaquetage Debian

La période de gel « fort » approchant, j’ai procédé à quelques mises à jour de dernière minute :

schroot 1.6.10-3 : correction de quelques problèmes anciens avec la manière dont les montages bind sont partagés, et autres corrections importantes;
live-boot 1:20170112 : correction d’un échec au démarrage sur système de fichier FAT, et autres corrections mineures;
live-config 5.20170112 : regroupement de plusieurs patchs utiles en provenance du BTS;
J’ai fini la mise à jour de hashcat 3.30 avec sa nouvelle bibliothèque privée, et corrigé en même temps le bogue critique pour la publication n°851497. Le travail avait été initié par des collègues de l’équipe pkg-security team.

Travaux divers

Parrainages J’ai parrainé un nouvel envoi de asciidoc abaissant une dépendance en recommandation (cf. le n°850301). J’ai parrainé une nouvelle version amont de dolibarr.

Discussions J’ai appuyé plusieurs modifications préparées par Russ Allbery sur debian-policy. J’ai aidé Scott Kitterman au sujet d’une incompréhension sur la manière dont les fichiers de service Postfix sont supposés fonctionner, en lien avec le rapport n°849584. J’ai discuté dans le rapport n°849913 d’une régression dans la compilation des compilateurs croisés, et fourni un patch afin d’éviter le problème. Guillem est finalement parvenu à une meilleure solution.

Bogues J’ai analysé le n°850236 concernant l’échec d’un test Django durant la première semaine suivant chaque année bisextile. J’ai créé le n°853224 afin de remonter plusieurs petits problèmes en lien avec les scripts mainteneur de desktop-base.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in January 2016 contribuée par Weierstrass01.

13 February, 2017 10:37AM by Raphaël Hertzog

February 02, 2017

Élections présidentielles, logiciel libre et Charlotte Marchandise

L’élection présidentielle approche et commence à prendre une grande place médiatique. À cette occasion, les associations comme l’April essaient d’interpeller les candidats pour les sensibiliser sur le sujet…

En temps qu’association, il faut garder ses distances et ne pas prendre position. Mais en tant qu’individu, je peux aller plus loin et soutenir explicitement un candidat qui partage les valeurs du logiciel libre.

C’est ce que je veux faire aujourd’hui. Je vous invite à découvrir Charlotte Marchandise. C’est la gagnante des primaires citoyennes organisées par laprimaire.org et son programme politique est en parfaite adéquation avec mes valeurs (revenu de base inconditionnel, 6ème république, transition écologique, etc.) y compris sur le logiciel libre (voir ici l’article dédié de son programme).

C’est une candidature citoyenne non-partisane qui ne peut donc s’appuyer sur aucun financement pré-existant. Elle a donc besoin de nos dons. J’ai déjà fait un don conséquent et je vous invite à en faire de même. Cliquez ici pour accéder au formulaire permettant de soutenir la campagne de Charlotte Marchandise.

Si vous ne pouvez pas donner, je vous invite simplement à parler de Charlotte et de son programme dans votre entourage et à partager cet article. Si vous avez un peu de temps à investir, vous pouvez participer à la recherche de parrainages.

Je fais partie de ceux qui ne veulent plus de la classe politique en place et qui souhaite une réforme des institutions et du système électoral en premier lieu. Avec cette candidature citoyenne, « hackons le système » !

02 February, 2017 01:57PM by Raphaël Hertzog

January 14, 2017

Mes activités libres en décembre 2016

Debian LTS

Ce mois-ci ce sont 10 heures de travail sur les mises à jour de sécurité pour Debian 7 Wheezy qui ont été subventionnées. Elles ont été consacrées aux tâches suivantes :

J’ai publié la DLA-741-1 concernant unzip. Ce fut une mise à jour facile;
J’ai passé en revue le patch de Roberto Sanchez pour la CVE-2014-9911 concernant ICU;
J’ai publié la DLA-759-1 concernant nss, en collaboration avec Antoine Beaupré. J’ai fusionné et mis à jour le travail de Guido pour activer la suite de tests au cours de la compilation, et pour ajouter les tests DEP-8;
J’ai créé le dépôt Git qui sera utilisé pour la maintenance de php5 dans Debian LTS, et j’ai commencé à travailler sur une mise à jour. J’ai ajouté les patchs pour 2 CVE (CVE-2016-3141 et CVE-2016-2554), ainsi que quelques fichiers binaires requis par certains tests (qui échouent, à l’heure actuelle).

Empaquetages divers

Avec l’approche du gel définitif de Stretch, certains clients m’ont demandé de pousser des paquets dans Debian et/ou de corriger des paquets sur le point d’être retirés de cette distribution.

Alors que j’essayais de ramener uwsgi dans testing, j’ai créé les rapport de bogue n°847095 (libmongoclient-dev: Ne devrait pas rentrer en conflit avec le paquet de transition mongodb-dev) et n°847207 (uwsgi: FTBFS sur de multiples architectures avec des références indéfinies à des symboles uwsgi_*), de même que j’ai travaillé sur quelques-uns des bogues critiques pour la publication qui maintenaient le paquet hors de testing.

J’ai également travaillé sur quelques nouveaux paquets (lua-trink-cjson, lua-inotify, lua-sandbox-extensions) qui améliorent le paquet « hindsight » dans certains cas d’usage, et j’ai parrainé une mise à jour de rozofs dans experimental, afin de corriger un conflit de fichiers avec inn2 (cf. le n°846571).

Travaux Debian divers

Debian Live J’ai publié deux mises à jour de live-build. Avec la seconde ont été ajoutées plusieurs options de personnalisation de la configuration GRUB (que nous utilisons dans Kali pour surcharger le thème, et ajouter de nouvelles entrées au menu), à la fois pour le boot EFI et pour le boot normal.

Rapports de bogue divers Rapport de bogue n°846569 concernant libsnmp-dev, afin de tenir compte de la transition libssl (j’avais remarqué que le paquet n’était pas maintenu, j’ai en conséquence fait appel aux nouveaux mainteneurs potentiels sur la liste debian-devel). Le n°847168 sur devscripts pour debuild qui a commencé à échouer lorsque lintian échouait (régression inattendue). Le n°847318 concernant lintian, afin d’éviter les faux-positifs sur les paquets Kali (ce qui était ennuyeux du fait de la régression debuild précédemment mentionnée). Le n°847436 concernant un problème de mise à jour avec tryton-server. Le n°847223 concernant firefoxdriver, dans la mesure où il dépendait toujours d’iceweasel au lieu de firefox.

Parrainage J’ai parrainé une nouvelle version d’asciidoc (rapport de bogue n°831965), ainsi que de ssldump (version 0.9b3-6), pour la transition libssl. J’ai également poussé une nouvelle version de mutter, afin de corriger le n°846898 (elle était déjà prête dans SVN).

Distro Tracker

Pas grand chose de nouveau, j’ai corrigé le n°814315 en basculant quelques URLs restantes vers https. J’ai fusionné les patchs d’efkin pour corriger la suite de tests fonctionnels (cf. le n°814315), ce qui constitue une contribution vraiment très utile ! Ce même contributeur s’est attaqué à un autre ticket (le n°824912) concernant l’ajout d’une API pour récupérer les objets d’action. Cela représente une tâche plus importante et demande quelques réflexions. Je dois encore lui faire mes retours sur ses derniers patchs (après déjà deux itérations).

Travaux divers

J’ai mis à jour la formule salt letsencrypt-sh pour la version 0.3.0, et ajouté la possibilité de personnaliser le script hook pour recharger le serveur Web.

Le compte Twitter @planetdebian n’est plus actif depuis que twitterfeed.com a fermé ses portes, et que son remplaçant (dlvr.it) n’apprécie pas le fil RSS de planet.debian.org. J’ai créé le n°848123 concernant planet-venus, ce dernier ne préservant pas l’attribut isPermalink dans le tag guid.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in December 2016 contribuée par Weierstrass01.

14 January, 2017 01:55PM by Raphaël Hertzog

December 11, 2016

Mes activités libres en novembre 2016

Debian LTS

Dans les 11 heures de travail (rémunérées) qui m’incombaient, je suis parvenu à publier la DLA-716-1, aussi connue sous le nom de tiff 4.0.2-6+deb7u8, corrigeant les CVE-2016-9273, CVE-2016-9297 et CVE-2016-9532. On dirait bien que ce paquet est concerné par de nouvelles CVE tous les mois.

J’ai ensuite consacré pas mal de temps à passer en revue toutes les entrées dans dla-needed.txt. Je souhaitais me débarrasser des commentaires erronés ou qui ne sont plus pertinents, et en même temps aider Olaf, qui s’occupait du « frontdesk LTS » pour la première fois. Cela a abouti au marquage de pas mal d’entrées comme « no-dsa » (c’est à dire que rien ne sera fait pour elles, leur gravité ne le justifiant pas), telles que celles affectant dwarfutils, dokuwiki, irssi. J’ai supprimé libass, car la CVE ouverte était sujette à débat et marquée comme « pas importante ». Tandis que je faisais cela, j’ai corrigé un bogue dans le script bin/review-update-needed que nous utilisons pour identifier les entrées n’ayant fait aucun progrès dernièrement.

Je me suis ensuite attaqué à libgc, et publié la DLA-721-1, ou libgc 1:7.1-9.1+deb7u1. Elle corrige la CVE-2016-9427. Le patch était important et a du être rétroporté manuellement, car il ne s’appliquait pas correctement.

Enfin, la dernière tâche réalisée fut le test d’une nouvelle version d’imagemagick et la revue d’une mise à jour préparée par Roberto.

Travaux concernant pkg-security

L’équipe pkg-security continue sur sa bonne lancée : j’ai parrainé le travail de patator concernant le nettoyage d’une dépendance inutile de pycryptopp, qui allait être retiré de Testing du fait du ticket n°841581. Après m’être penché sur ce bogue, il s’est avéré que celui-ci était résolu dans libcrypto++ 5.6.4-3. Je l’ai donc clôturé.

J’ai parrainé plusieurs envois : polenum, acccheck, sucrack (mises à jour mineures), bbqsql (nouveau paquet importé de Kali). Quelques temps plus tard, j’ai corrigé quelques soucis dans le paquet bbsql, qui avait été rejeté de NEW.

Je me suis également occupé de quelques bogues critiques pour la publication, et liés à la transition vers openssl 1.1 : j’ai adopté dans l’équipe sslsniff et corrigé le n°828557, par une compilation dépendante de libssl1.0-dev. Ceci après avoir ouvert le ticket amont correspondant. J’ai fait la même chose pour ncrack et le n°844303 (le ticket amont est ici). Quelqu’un d’autre s’est occupé de samdump2, mais j’ai tout de même adopté le paquet dans l’équipe pkg-security, dans la mesure où il s’agit d’un paquet concernant le thème de la sécurité. J’ai aussi effectué un envoi en tant que non-mainteneur d’axel et du n°829452 (cela ne concerne pas pkg-security, mais nous l’utilisons dans Kali).

Travaux Debian divers

Django J’ai participé à la discussion débattant de l’opportunité de laisser Django compter le nombre de développeurs qui l’utilisent. L’impact quant à la diffusion de données personnelles que ce changement entraînerait a suscité l’intérêt des listes de diffusion Debian, et jusqu’à celui de LWN.

Sur un plan plus technique, j’ai poussé la version 1.8.16-1~bpo8+1 vers jessie-backports, et corrigé le bogue critique pour la publication n°844139. Pour se faire, j’ai rétroporté deux commits amont, ce qui a mené à l’envoi 1.10.3-2. Je me suis ensuite assuré que cela était également corrigé dans la branche amont 1.10.x.

dpkg et /usr fusionné. En parcourant debian-devel, j’ai découvert que le bogue n°843073 menaçait la fonctionnalité d’un /usr fusionné. Dans la mesure où le bogue était présent dans du code que j’avais écrit il y a plusieurs années, et du fait que Guillem n’était pas intéressé par sa correction, j’ai passé une heure à mettre au point un patch relativement propre que ce dernier pourrait appliquer. Guillem n’a malheureusement pas encore réussi à sortir une nouvelle version de dpkg embarquant ces patchs. Espérons que cela ne tardera plus trop.

Debian Live J’ai fermé le n°844332 , qui demandait le retrait de live-build de Debian. Étant marqué comme orphelin, j’avais toujours gardé un œil sur ce paquet, et avait poussé quelques petites corrections vers Git. J’ai décidé cette fois d’adopter officiellement le paquet au sein de l’équipe debian-live, et de travailler un peu plus dessus. J’ai passé en revue tous les patchs en attente dans le suiveur de bogues, et poussé de nombreuses modifications vers Git. Quelques changements restent à faire pour finaliser un meilleur rendu du menu GRUB, et j’ai prévu de pousser une nouvelle version très prochainement.

Diverses créations de tickets J’ai créé deux tickets amont concernant uwsgi, afin d’aider à la correction de bogues ouverts et critiques pour la publication affectant ce paquet. J’ai créé le n°844583 concernant sbuild, afin de supporter les suffixes arbitraires de version pour les recompilations binaires (binNMU). Et j’ai créé le n°845741 concernant xserver-xorg-video-qxl, afin qu’il soit corrigé pour la transition vers xorg 1.19.

Zim. Alors que j’essayais de corriger le n°834405 et de mettre à jour les dépendances requises, j’ai découvert que je devais mettre à jour pygtkspellcheck en premier lieu. Le mainteneur de ce paquet étant malheureusement aux abonnés absents (MIA – missing in action), je l’ai adopté en tant que membre de l’équipe python-modules.

Distro Tracker. J’ai corrigé un petit bogue, qui entraînait l’affichage d’une affreuse trace à l’occasion de requêtes avec un HTTP_REFERER non-ASCII.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in November 2016 contribuée par Weierstrass01.

11 December, 2016 07:37PM by Raphaël Hertzog

November 23, 2016

Tanguy Ortolo

Interdit ou autorisé ?

Vu près de l'entrée d'un jardin public, celui de Brimborion, de mémoire :

Panneau rond avec une large bordure verte et un vélo noir au milieu

Alors, dans ce parc, le vélo est-il autorisé, interdit, recommandé, obligatoire ? (Rayez les mentions inutiles.)

C'est interdit, évidemment, mais modifier ainsi la couleur d'un panneau standard est une très mauvaise idée. Et la raison pour laquelle cette erreur a été commise, à savoir mieux s'assortir avec la couleur de l'environnement, est parfaitement stupide. Service des parcs de Sèvres, changez-moi ça tout de suite !

23 November, 2016 05:56PM by Tanguy

October 29, 2016

J. Fernando Lagrange

Certificats Let’s Encrypt ! avec certbot

Qu’est-ce que c’est donc ? (bis)

Le mois dernier, j'avais partagé comment je faisais pour renouveler des certificats Let's Encrypt ! Je me suis alors rendu compte qu'il y a des outils dédiés dans le projet Debian, et qu'ils ont étés rétroportés pour Jessie: le paquet Debian certbot. Voici comment j'utilise ce paquet.

Pour rappel:
« Let's Encrypt (abrégé LE) est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet. »
Contenu soumis à la licence CC-BY-SA 3.0. Source : Article Let's Encrypt de Wikipédia en français (auteurs ).

Voici donc comment j'utilise ce paquet Debian certbot pour:

Créer de nouveaux certificats (pour nginx)
Mettre à jour ces certificats

Préambule: installation

Pour installer le paquet certbot, il faut d'abord ajouter la source des paquets rétroportés. C'est indiqué dans les instructions (en anglais) et sur la page wiki (en français). Personnellement, voici comment j'ai fait:

J'ai créé un fichier /etc/apt/sources.list.d/backports.list contenant la ligne suivante:

deb http://ftp.debian.org/debian jessie-backports main

Puis lancé les commandes suivantes:

root@server ~# apt update
[…]
root@server ~# apt install certbot
[…]

Créer de nouveaux certificats (pour nginx)

J'utilise nginx comme serveur web. J'ai mis en place le certificat Let's Encrypt ! en 3 étapes:

Créer le certificat
Configurer nginx pour utiliser le nouveau certificat
Relancer nginx

Créer le certificat

Voici comment j'ai créé les certificats pour le site web www.fosforito.fr:

root@server ~# systemctl stop nginx.service
root@server ~# certbot certonly -d www.fosforito.fr
[…]

Puis, j'ai suivi les instructions (en anglais) pour utiliser l'authentification avec un serveur web autonome (standalone). Cela autorise certbot à lancer son propre serveur web, le temps de créer le certificat. nginx ne doit donc pas fonctionner le temps de créer le certificat (quelques secondes dans mon cas), c'est le but de la première commande. Pour le relancer, j'ai utilisé la commande suivante:

root@server ~# systemctl start nginx.service

Configuration de nginx

Pour utiliser la configuration ci-dessous, j'ai d'abord créé une clé Diffie-Hellman comme indiqué par SSL Labs:

root@server ~# openssl dhparam -out /etc/nginx/dhparams.pem 2048
[…]

Voici le fichier /etc/nginx/sites-available/www.fosforito.fr.conf que j'utilise avec la commande root@server ~# ln -s /etc/nginx/sites-available/www.fosforito.fr.conf /etc/nginx/sites-enabled/www.fosforito.fr.conf:

server {
    listen 443;
    server_name www.fosforito.fr;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/www.fosforito.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.fosforito.fr/privkey.pem;

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    ssl_prefer_server_ciphers on;

    ssl_dhparam /etc/nginx/dhparams.pem;

    root /srv/www.fosforito.fr/;
    index index.html;

    access_log      /var/log/nginx/www.ssl.access.log;
    error_log       /var/log/nginx/www.ssl.error.log;


}

Une fois tout cela mis en place, je teste avec SSL Labs et je vois que ce site obtient un A, ce qui me va bien.

Mise à jour du certificat

Le paquet certbot met en place une tâche planifiée pour mettre à jour automatiquement le(s) certificat(s) Let's Encrypt ! présent(s) sur le serveur. Malheureusement, pour l'instant, cela ne fonctionne que pour le serveur web apache (paquet apache2 dans Debian).
Pour nginx, j'ai simplement modifié la tâche planifiée, dans le fichier /etc/cron.d/certbot, pour arrêter le serveur web avant le renouvellement de certificat et le relancer après. Voici le fichier au complet (notez les options pre-hook et post-hook):

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew --pre-hook "service nginx stop" --post-hook "service ngnix start"

Récapitulatifs

Mise en place du certificat pour nginx

Arrêter nginx
Créer le certificat Let's Encrypt !
Créer le groupe Diffie-Hellman
Mettre en place la configuration du site web
Relancer nginx

Renouvellement du(des) certificat(s)

Ajouter les options pre-hook et post-hook à la tâche plannifiée.

29 October, 2016 06:36PM by Low Memory

August 17, 2016

Tanguy Ortolo

Aux concepteurs de voies cyclables

À voir le tracé de certaines voies cyclables, ceux qui les conçoivent ne sont pas toujours conscients qu'un cycliste se déplace avec une vitesse de l'ordre de 20 km/h. Ce genre d'aménagement, qui serait impensable pour une route normale :

Au top, braquez et serrez le frein à main. Attention… TOP ! ;-)

… ce genre d'aménagement donc, est tout aussi invraisemblable pour une voie cyclable :

Piste cyclable avec une chicane à angle droit !

Au top, tournez votre guidon à 90°. Attention… TOP ! ;-)

Un cycliste ne peut pas tourner sur place à angle droit. Au mieux, on peut essayer de s'en approcher, mais ces virages à rayon de courbure nul sont pénibles et toujours dangereux, parce que cela implique :

de freiner brutalement — et paf, le cycliste qui arrive derrière et qui n'a pas remarqué cette anomalie du tracé ;
de tourner avec un angle déraisonnable — et zip, le cycliste sur route mouillée ou jonchée de gravier ou de feuilles mortes.

Mesdames, Messieurs les responsables des aménagements de voirie, pour éviter ce genre d'erreur de conception, ce n'est pas compliqué : lorsque vous tracez une voie cyclable, essayez d'imaginer qu'il s'agit d'une route normale, en plus petit. Vous n'iriez tout de même pas mettre une chicane à angle droit sur une route normale ? Eh bien, sur une piste cyclable, c'est pareil, si vous devez mettre une chicane, prévoyez un rayon de courbure raisonnable. Sans cela, dans le meilleur cas, les cyclistes ne respecteront pas votre aménagement inapproprié, et dans le pire des cas vous ramasserez des cyclistes et des piétons accidentés, direction l'hôpital le plus proche.

17 August, 2016 12:16PM by Tanguy

August 10, 2016

J. Fernando Lagrange

Renouvellement de certificats LetsEncrypt avec systemd

Qu'est-ce que c'est donc ?

« Let's Encrypt (abrégé LE) est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d'un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites internet¹. » (Contenu soumis à la licence CC-BY-SA 3.0. Source : Article Let's Encrypt de Wikipédia en français (auteurs) )

Bref, c'est bien pratique pour faire du HTTPS (entre autres) et on peut automatiser le renouvellement des certificats. Il y a plusieurs années, j'aurais fait un cron, mais comme j'ai appris que systemd pouvait gérer des tâches répétitives, je me suis dit que c'était l'occasion de m'y mettre !

Comment on fait ?

Voici les étapes suivies, détaillées ci-dessous puis quelques documents qui m'ont permis de le faire, sans compter le conseil d'un ami: « T'as qu'à faire un timer ! » :

Copier certbot sur le serveur, logiciel (libre, non-copyleft) de gestion des certificats de Let's Encrypt
Créer un script pour renouveler les certificats avec certbot
Créer un service systemd pour lancer le script
Créer une minuterie (timer) systemd pour lancer le service à intervalles réguliers

Enfin, activer et lancer la minuterie puis vérifier que ça fonctionne.

1. Copier certbot sur le serveur

Je le copie dans le dossier /opt du serveur:

root@serveur:~# cd /opt/ && git clone https://github.com/certbot/certbot
[…]

2. Créer le script pour utiliser certbot

Le script se nomme certbot-renew, il est créé dans /opt/certbot/, au même endroit que certbot. Créez aussi le dossier pour les journaux avec la commande mkdir /var/log/letsencrypt/.

Si vous utilisez le serveur web apache, changez le service que systemd doit arrêter et redémarrer, en gras dans le code ci-dessous:

root@serveur:~# cat > /opt/certbot/certbot-renew << EOF
#!/bin/sh
# Inspired by <https://letsencrypt.org/getting-started/>
systemctl stop nginx.service
/opt/certbot/certbot-auto renew -nvv --standalone > /var/log/letsencrypt/renew.log 2>&1
LE_STATUS=$?
systemctl start nginx.service
if [ "$LE_STATUS" != 0 ]; then
echo Automated renewal failed:
tail -n 200 /var/log/letsencrypt/renew.log
exit 1
fi
EOF

3. Créer le service systemd

C'est ce service qui va lancer le script /opt/certbot/certbot-renew créé à l'étape précédente:

root@serveur:~# cat > /etc/systemd/system/certbot-renew.service << EOF
# Voir <https://mjanja.ch/2015/06/replacing-cron-jobs-with-systemd-timers/>
[Unit]
Description=Renouvellement des certificats letsencrypt

[Service]
Type=simple
nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/opt/certbot/certbot-renew
EOF

4. Créer la minuterie systemd

C'est cette minuterie qui va lancer le service créé à l'étape précédente. Notez que la valeur daily pour OnCalendar lance le service à minuit. Comme le serveur était programmé pour faire d'autres choses à minuit, j'ai utilisé un autre moment. ^^

root@serveur:~# cat > /etc/systemd/system/certbot-renew.timer << EOF
# Voir <https://mjanja.ch/2015/06/replacing-cron-jobs-with-systemd-timers/>
[Unit]
Description=Renouvellement des certificats letsencrypt

[Timer]
#OnCalendar=daily
OnCalendar=*-*-* 04:20:42

[Install]
WantedBy=timers.target
EOF

Il ne reste plus qu'à activer cette minuterie pour qu'elle soit lancée à chaque démarrage du serveur: systemctl enable certbot-renew.timer

Pour éviter un redémarrage, la minuterie peut être lancée manuellement: systemctl start certbot-renew.timer

Pour vérifier que tout fonctionne bien le service peut aussi être lancé manuellement: systemctl start certbot-renew.service. Vérifiez alors les journaux pour voir si tout s'est bien déroulé.

Voici donc comment j'ai procédé, il doit exister bien d'autres façons de faire, n'hésitez-pas à m'en faire part et/ou à améliorer ce que je présente ici.

Documentation, ressources:

Manuels de systemd: systemd.exec, systemd.service et systemd.timer.
Manuel de ioprio_set.
Remplacer les cron jobs par des minuteries systemd (en anglais).
Pour débuter avec Let's Encrypt (en anglais).

Un brin de persévérance, un tonneau de tests et quelques couplets de corrections.

10 August, 2016 09:02PM by Low Memory

June 28, 2016

Tanguy Ortolo

J'ai testé pour vous UltraViolet (c'est de la merde)

Après avoir acheté un beau coffret de la trilogie cinématographique Le Hobbit, j'ai eu la surprise d'un trouver des instructions pour « récupérer une copie numérique » pour regarder ces films « sur tous mes écrans » grâce à un machin appelé UltraViolet. Les instructions indiquées sont les suivantes :

allez sur warnerbros.fr/uv ;
entrez un code d'activation.

S'agissant d'un machin développé par la MAFIAA, je pouvais déjà prédire le résultat, mais par acquit de conscience, j'ai tout de même essayé, avec un navigateur Web Firefox sous Debian GNU/Linux, plugin Flash installé et à jour, JavaScript et cookies activés sans restriction. Après tout, il est bien indiqué sur le papier que c'est censé marcher « sur tous mes écrans », avec de beaux petits schémas représentant un téléphone, une tablette, un ordinateur portable et un téléviseur.

Étape 1, Warner Bros

Deux étapes, on pourrait difficilement faire plus simple ! Sauf qu'évidemment, ça se complique. Sur la page UltraViolet de Warner Bros, il n'y a pas d'endroit où saisir un code ; au lieu de cela, il est proposé deux sites partenaires où on doit pouvoir l'entrer : Nolim films et Flixter.

Étape 1, deuxième partie, premier essai, Nolim films

Lorsque j'ai essayé, hier, la page de Nolim films affichait seulement « chargement en cours ». Après quelques minutes, j'ai donc renoncé et été voir chez Flixter.

Étape 1, deuxième partie, deuxième essai, Flixter

Côté Flixter, ça commence bien, on arrive sur un site en anglais. Une fois passé en français, il y a un bouton pour « Utiliser un code ». On tape le code et… ça dit qu'il n'y a aucun résultat. En fait, il faut saisir le titre du film, et ensuite seulement, saisir le code d'activation.

Étape 2, (essayer de) regarder ou télécharger le film

Il faut alors créer un compte, qui demande de fournir des renseignements personnels, c'est à dire des informations qui ne devraient certainement pas les concerner : pour regarder un film qu'on a acheté, il est anormal de devoir donner son nom, prénom et date de naissance. Personnellement, j'ai renseigné mon nom, mais une date de naissance bidon.

Enfin, on peut regarder son film. Enfin, essayer, parce que ça ne marche pas : ça lance une page avec Flash, qui affiche… du noir, puis un indicateur de chargement, et qui finit par planter le lecteur Flash.

On peut aussi télécharger son film avec un logiciel propriétaire proposé pour cela. Il est prévu pour Windows, et ne s'installe pas sous Wine.

Étape 3, ripper son DVD

Comme prédit, ça ne fonctionne pas. Il est donc temps de faire un peu chauffer mon processeur pour ripper mes DVD : ça au moins, ça fonctionne, et sans la moindre restriction. Autrement, ces flims doivent également être disponibles sur les réseaux de contrefaçon : contrairement à l'UltraTropLaid, ça aussi, ça fonctionne.

28 June, 2016 01:34PM by Tanguy

June 17, 2016

J. Fernando Lagrange

La brique en voyage

La situation

Il se trouve que j'ai déménagé récemment. J'en ai profité pour demander un abonnement Internet à l'association de la Fédération FDN de mon coin: Rézine. J'ai donc mis ma brique Internet chez quelqu'un, le temps que l'accès Internet soit en place.

Le problème

Quand j'ai connecté la brique depuis un autre accès Internet, plus rien n'a fonctionné : pas de nouvelles de la brique sur Internet, ni sur le réseau local !

La solution

Note pour les avocats: cette solution a fonctionné chez moi, mais il y a un risque de perdre des données. Rien ne garanti qu'elle fonctionnera chez vous ! Je ne peux pas être tenu pour responsable des actions que vous faites. En cas de doute, demandez de l'aide au membre FFDN le plus proche de chez vous !

"Malheureusement", j'ai un modèle de brique datant de juillet 2015 (avec la migration du blog sur la brique fin 2015). Et une fois fonctionnelle, je ne me suis pas occupé de son entretien: ne pas toucher à quelque chose qui fonctionne me semble un bon conseil à suivre en informatique.

Mais là, je n'avais pas vu qu'il y avait des erreurs sur le disque. Ces erreurs n'ont été gênantes qu'une fois la brique éteinte et rallumée. J'ai donc pris le disque dur de la brique (la carte microSD) et je l'ai mis dans mon PC.

Puis, avec la commande lsblk j'ai vu que la partition de ce disque était /dev/sdc1; j'ai alors pu lancer une vérification du disque avec la commande suivante:

# fsck /dev/sdc1
[…là, ça défile et des fois ça pose des questions…]

Quand la question était posée de corriger les erreurs, j'ai répondu oui. Une fois toutes les erreurs corrigées, j'ai relancé la commande pour vérifier qu'il n'y avait plus d'erreur:

# fsck /dev/sdc1
fsck de util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/sdc1 : propre, 93335/917568 fichiers, 848399/3859968 blocs

C'est alors, plein d'espoir que j'ai remis le disque dur dans la brique pour la brancher et l'allumer: ça marchait à nouveau !

Deuxième problème

Tout content que la brique refonctionne, j'ai payé un coup à boire à la personne qui l'héberge et je suis rentré chez moi. C'est avec un peu de déception que j'ai réalisé le lendemain que la brique ne fonctionnait plus ! :'-(

Ce deuxième problème est aussi lié au fait que j'ai mis en place ma brique en juillet 2015: à partir du moment où l'application vpnclient mettait en place le tunnel chiffré, la brique n'avait plus accès aux DNS (dont on parle dans cette superbe conférence) !

Après demande d'information à mon fournisseur de tunnels, c'est normal pour pleins de raisons diffèrentes, bref je dois utiliser leur DNS.

Deuxième solution

Une fois le problème identifié, la solution n'est pas loin ! Ici, j'ai mis à jour l'application vpnclient et le tour était joué: la dernière version de cette application prends en compte les DNS ! \o/

Je peux donc maintenant bloguer à nouveau, par exemple pour indiquer comment j'ai déplacé ma brique !

Prochaines étapes: mise en place de sauvegardes… Stay tuned for more info

17 June, 2016 09:13AM by Low Memory

April 28, 2016

Tanguy Ortolo

Pour des cartes restaurant anonymes

Contexte

Dans les années 2000, la RATP et la SNCF on progressivement imposé le remplacement des tickets de papier anonymes par des cartes à puce nommées Navigo, pour les utilisateurs d'abonnements. Le problème, c'est que ces cartes à puces étaient nominatives, et que dans un pays libre, « aller et venir librement, anonymement, est l’une des libertés fondamentales. » La CNIL a donc imposé la création d'une carte Navigo anonyme.

L'histoire bégaie un peu. Dans les années qui viennent, sous la pression de l'État, les opérateurs de titres restaurant vont progressivement imposer le remplacement des titres de papier anonymes par des cartes à puce, qui permettent un plus grand contrôle des usages, afin d'en limiter les utilisations détournées. Le problème, c'est que ces cartes à puce sont nominatives, et que dans un pays libre, se nourrir, et plus généralement consommer librement, anonymement, est l'une des libertés fondamentales. La CNIL devrait donc imposer la création de cartes restaurant anonymes.

C'est possible

Les opérateurs de titres restaurant objecteront peut-être que c'est techniquement impossible. Pour les aider ainsi que la CNIL, voici une description d'un système qui rendrait possible l'utilisation de cartes restaurant anonymes. Comme pour les cartes de transport, choisir l'anonymat peut impliquer de renoncer à certains avantages.

L'entreprise distribuant des titres restaurant à ses salariés dispose d'un stock de quelques cartes anonymes, seulement identifiées par leur numéro. Comme toute carte restaurant, chacune est associée à un compte initialement vide.

Lorsqu'un salarié demandé à disposer d'une carte anonyme, l'entreprise lui fournit une de ces cartes. Elle peut noter et transmettre à l'opérateur le fait que cette carte est maintenant attribuée, mais a interdiction de relever le nom du salarié qui l'utilise. Si le salarié disposait déjà d'une carte nominative, son numéro doit être relevé afin de cesser d'alimenter le compte correspondant, ce qui peut être traité de la même façon qu'un retrait de l'offre de titres restaurant. Évidemment, l'entreprise a interdiction de tenter de dissuader les salariés de choisir l'anonymat, et de pénaliser ceux qui feraient ce choix.

Chaque mois, lors de la distribution des titres restaurant, le salarié utilisateur d'une carte anonyme se présente en personne, comme cela se fait pour des titres en papier. Le responsable approvisionne le compte correspondant au numéro indiqué sur la carte, et note sur un registre séparé que ce salarié a bien bénéficié de la distribution. L'entreprise a interdiction de noter sur ce registre le numéro de la carte créditée, et, d'une façon générale, de noter ou de transmettre tout ce qui pourrait permettre d'associer les noms des salariés avec les numéros des cartes anonymes. Encore une fois, l'entreprise a interdiction de pénaliser les salariés qui se présentent pour une distribution anonyme.

Le salarié utilise sa carte restaurant de façon normale pour régler ses consommations et achats éligibles dans les conditions prévues. Les restaurateurs de enseignes acceptant les paiements par carte restaurant ont interdiction de pénaliser les utilisateurs de cartes anonymes. Seules les fonctionnalités annexes de gestion peuvent être affectées par le caractère anonyme de la carte : ainsi, en cas de perte, l'opposition sur cette carte ne pourra pas être effectuée avec le seul nom du bénéficiaire, mais nécessitera la connaissance de son numéro, faute de quoi elle ne pourra être réalisé, et le crédit restant devra être considéré comme non récupérable. De telles restrictions doivent être justifiées par une raison technique : ainsi, il ne serait pas admissible de restreindre une opération de promotion chez un restaurateur partenaire aux seuls titulaires de cartes nominatives.

28 April, 2016 07:47PM by Tanguy

April 25, 2016

Parking Méditerranée - Gare de Lyon : attention, hostile aux vélos

Parking Méditerranée

La Gare de Lyon est une grande gare parisienne, qui est desservie à la fois par le réseau régional et par plusieurs grandes lignes nationales. On y trouve donc :

des riverains, qui habitent ou travaillent près de la gare ;
des usagers quotidiens ;
des voyageurs occasionnels, qui partent ou reviennent par exemple de week-end ou de vacances en province.

Le parking Méditerranée, opéré par la SAEMES, est situé sous la gare de Lyon, et accueille le même type de clients :

des usagers quotidiens, qui y parquent leur véhicule tous les jours ou toutes les nuits ;
des voyageurs occasionnels, qui parquent ponctuellement leur véhicule pour quelques jours, voire quelques semaines.

Cet usage est indépendant du type de véhicule, qu'il s'agisse d'une voiture, d'une moto ou d'une bicyclette.

Théoriquement, un accès vélo

Sur sa page Web, le parking Méditerranée - Gare de Lyon affiche un joli logo vélo, qui suggère la possibilité d'y garer sa bicyclette (qu'est-ce que ça pourrait bien vouloir dire d'autre ?).

De surprise en surprise

La réalité est toute autre. Le voyageur qui arrive à vélo au parking Méditerranée va de surprise en surprise (et de pire en pire) :

L'espace vélo n'est pas indiqué, les panneaux donnant seulement le choix entre l'espace voiture et l'espace moto. Faute de mieux, autant choisir l'espace moto, c'est ce qui se fait de plus approchant.
On est censé prendre un ticket, mais la machine n'en distribue pas aux vélos : on a beau appuyer sur le bouton prévu pour cela, rien ne sort et la barrière reste fermée. Qu'à cela ne tienne, un vélo est suffisamment maniable pour contourner la barrière, mais ça commence mal (et ça va mal finir, mais pour le moment, on a un train à prendre)…
Une fois arrivé dans l'espace moto, comme on peut s'y attendre, rien n'est prévu pour fixer des vélos. Peu importe, un cycliste urbain est de toute façon habitué à stationner comme il le peut, une barrière fera donc l'affaire, en vérifiant bien qu'on ne gêne pas le passage ou le stationnement des autres usagers.
Une fois rentré de voyage, et de retour à la gare de Lyon, on constate que l'exploitant du parking a enchaîné la bicyclette, sans un mot d'explication, sans doute parce qu'elle était mal garée, mais comment pourrait-elle être bien garée puisque l'espace vélos n'est pas indiqué ?
À l'accueil, l'exploitant exige un paiement pour libérer le vélo. Pourquoi pas, mais 15 €, c'est un peu cher pour trois jours de stationnement en occupant zéro emplacement.

Un parking hostile aux vélos

Le parking Méditerranée - Gare de Lyon, qui s'affiche sur le Web avec un espace vélo, est en réalité hostile à ce type de véhicule. Le fait d'afficher un espace vélo, qui s'avère en réalité indisponible, pourrait d'ailleurs relèver de la publicité mensongère.

Suite à cette désagréable expérience, j'ai commencé une enquête sur le stationnement vélo dans les parkings publics des grandes gares parisiennes, dont certains indiquent ainsi disposer d'un espace vélo, qui peut s'avérer inexistant. Affaire à suivre.

25 April, 2016 07:01PM by Tanguy

April 11, 2016

Carl Chenet

Richard Stallman ce samedi à Choisy-le-roi

Pour information j’ai découvert ce week-end que Richard Stallman sera présent à la médiathèque de Choisy-le-roi ce samedi 16 avril 2016 à 17h. Pour information des Parisiens indécrottables, c’est en très proche banlieue parisienne :p Comptez par exemple entre 20 et 30 mn depuis le centre de Paris en passant par le RER C pour y arriver.

saint-stallman

Bref si vous n’avez jamais vu le monsieur et ses célèbres conférences ou que vous aimeriez une mise-à-jour sur ses positions, c’est l’occasion de le voir. Pour ma part j’y serai.

Peut-être à samedi donc

11 April, 2016 06:53AM by Carl Chenet

April 07, 2016

« La » communauté du Logiciel Libre, ça n’existe pas

Suivez-moi aussi sur Diaspora* ou Twitter

J’avais depuis quelques temps envie d’écrire un billet de blog au sujet de la soi-disant communauté du Logiciel Libre et le dernier article de Frédéric Bezies , où il regrette le manque de coordination et d’unité de cette communauté, m’a donné la motivation pour finalement expliquer pourquoi tant de gens se désillusionnent quant à « cette » communauté.

« La » communauté du Logiciel Libre, ça n’existe pas

Il est en effet vain dans la plupart des cas de parler de « la » communauté du Logiciel Libre. On peut – et je le fais souvent moi-même – parler de la communauté du Logiciel Libre pour regrouper dans un même sac tous les acteurs touchant de près ou de loin au Logiciel Libre, mais c’est une dénomination vague, peu précise et que l’on ne doit pas employer à tort et à travers.

Et pour cause, car aussi bien d’un point de vue technique que d’un point de vue idéologique, nous, les acteurs de cette soi-disant communauté, sommes profondément et sûrement irrémédiablement divisés.

Les communautés techniques

Rappelons-le car beaucoup de personnes même proches du Logiciel Libre ont tendance à l’oublier. 99% du temps, un projet du Logiciel Libre, c’est au départ un individu isolé non rémunéré qui se motive et prend son courage à deux mains pour écrire du code et porter seul – au moins au début – un projet pour répondre à un besoin existant qui le dérange lui.

Ce faisant, il s’insère dans une communauté technique, celle des outils qu’il utilise pour régler son problème, puis le jour où son projet est prêt, s’il fait le choix de le rendre public, dans une communauté idéologique répondant aux critères que l’on verra au chapitre suivant.

La communauté Python, avec sa propre licence : la PSF, sa propre vision, ses propres objectifs

Au premier niveau, le développeur du Logiciel Libre, c’est donc un utilisateur des outils qui sont mis à disposition par une communauté technique. Il adhère souvent aux idées derrière les outils qu’ils utilisent au quotidien parce qu’il y voit un avantage direct et ressent la cohérence des choix techniques et idéologiques faits par la communauté l’ayant précédé.

Maintenant si on parle de « la » communauté du Logiciel Libre, ça sous-entend que le premier niveau dont je parlais à l’instant se fond dans un deuxième niveau, un niveau plus vaste, plus abstrait, plus global. Donc plus éloigné du développeur au quotidien, touchant des problématiques qu’il ne ressent peut-être pas tous les jours.

Alors qu’au quotidien pour lui, « sa » communauté, c’est par exemple le langage Python et ses membres, pas Perl. Ou la distribution Debian et les buts du projet Debian, pas les systèmes BSD. On se construit donc aussi en opposition à d’autre communautés techniques et idéologiques.

Les développeurs contribuent donc – le plus souvent dans le cadre de leur temps libre, le plus souvent de façon non-rémunérée, et dans ce domaine seule la motivation permet d’avancer – aux sujets qui nous intéressent et nous motivent au sein d’une communauté technique et idéologique et pas sur les sujets dont « la communauté du Logiciel Libre » aurait besoin.

La diversité des acteurs et de leurs idées, de leurs approches techniques et des solutions qu’ils trouvent au quotidien sont les éléments qui rendent aussi attractif pour beaucoup d’entre nous ce milieu technique et idéologique.

GPL contre BSD/MIT

J’ai évoqué et développé ce point dans l’un de mes précédents articles le danger Github : d’un point de vue idéologique, principalement deux idées du Logiciel Libre coexistent.

La vision incarnée par la licence GPL peut être résumée à une notion fondamentale intégrée par ses défenseurs et ses détracteurs : contaminante. La GPL va nourrir d’elle-même la communauté en réinjectant automatiquement dans le parc logiciel sous GPL tous les dérivés des logiciels eux-mêmes sous GPL. La communauté sert la communauté. Les utilisateurs de la GPL trouvent cohérents de n’utiliser que du Logiciel Libre pour ne pas nourrir l’ennemi , c’est-à-dire le logiciel privateur.

Les licences BSD/MIT sont pour leur part plus permissives, permissives à l’extrême. Rappelons qu’un logiciel dérivé d’un logiciel sous licence BSD/MIT peut être déposé sous une licence propriétaire. Les licences BSD/MIT sont donc non-contaminantes. On a donc la liberté de rendre un logiciel – libre à la base – privateur. Ce qui se fait beaucoup et l’on retrouve les systèmes d’exploitation BSD dans nombre de système d’exploitation propriétaires. voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD.

Les défenseurs des licences BSD/MIT parlent de liberté réelle face à la GPL, ses détracteurs de la liberté de se tirer une balle dans le pied. Étant donné que les défenseurs de ces licences permissives type BSD/MIT trouvent normal la coexistence du Logiciel Libre et du logiciel privateur, ils utilisent eux-mêmes les deux sans problème, ce qui est cohérent idéologiquement.

bsdvsgpl

Donc au final deux visions très différentes du Logiciel Libre – la GPL plus conquérante, les BSD/MIT plus flexibles – coexistent.

Des communautés constituent le Logiciel Libre

On l’a vu, il serait donc plus précis de parler des communautés qui constituent le Logiciel Libre. Elles sont à la fois techniques et idéologiques et apportent des outils concrets à leurs membres. Elles se définissent par rapport à ce qu’elles construisent, à leurs contributions, mais aussi par opposition aux autres communautés techniques et idéologiques. Il est donc impossible de parler d’une communauté du Logiciel Libre, à moins de la réduire au peu d’idées transverses aux différentes communautés techniques et idéologique la constituant.

J’ai pu remarquer que de nombreux intervenants parlent souvent de la communauté du Logiciel Libre pour parler en fait d’un sous-ensemble de celle-ci, en fait de leur communauté.Par exemple un défenseur de la GPL va parler de la communauté du Logiciel Libre en omettant l’idée de liberté complète derrière les licences BSD/MIT. Ou un idéologue auto-proclamé du Logiciel Libre va déclarer de grandes directions que « le Logiciel Libre » devrait prendre dans une approche top-down alors que, comme nous l’avons vu, tous les contributeurs techniques du Logiciel libre intègrent avant tout une communauté technique et idéologique précise, un sous-ensemble de « la » communauté du Logiciel libre.

Au final il est peut-être rageant de voir au quotidien des projets s’affronter, se troller, de voir des projets réinventer ce qui existent déjà au lieu de l’améliorer. Il semble même incompréhensible de voir des projets entièrement recoder pour des questions de licences ou parfois juste d’ego entre membres de ce qu’on croit être une même communauté. Mais cela tient à une incompréhension de l’organisation et des interactions des projets du Logiciel Libre entre eux.

L’explication tient au fait que le Logiciel Libre est constitué de nombreuses communautés, qui partagent quelques grandes idées communes certes, mais qui portent chacune des solutions techniques, une vision et une identité propres. Elles arrivent à se rejoindre très ponctuellement autour d’un effort commun sur un point extrêmement consensuel, mais il sera tout simplement impossible de les faire toutes et en permanence converger vers des grands objectifs qui bénéficieraient (ou pas) à une vague communauté globale dans laquelle se reconnaîtraient tous les acteurs du Logiciel Libre.

La diversité des communautés qui le compose fait la force du Logiciel Libre, nous partageons quelques grandes idées et nous inventons au quotidien nos propres solutions. Et c’est de cette façon que nous avons avancé jusqu’à aujourd’hui.

07 April, 2016 10:00PM by Carl Chenet

April 03, 2016

Nouveau forum pour l’emploi dans la communauté du Logiciel Libre et opensource

Suivez-moi aussi sur Diaspora* ou Twitter

Un rapide message pour annoncer le lancement d’un forum dédié à l’emploi dans la communauté du Logiciel Libre et opensource :

Le forum de LinuxJobs.fr : https://forum.linuxjobs.fr

Devant le succès de LinuxJobs.fr , le site d’emploi de la communauté du Logiciel Libre et opensource, et la communauté d’utilisateurs qui s’est constitué autour, il était dommage de s’arrêter à l’échange d’offres d’emplois. C’est pourquoi LinuxJobs.fr créé un lieu d’échange et de discussions pour sa communauté, avec des catégories comme les rémunérations, le droit du travail, les questions des jeunes diplômés, des les étudiants ou l’entrepreunariat.

Ce nouveau forum est fièrement propulsé par le nouveau moteur de forums Flarum, un logiciel libre sous licence MIT.

Au plaisir de discuter bientôt avec vous sur le forum de LinuxJobs.fr.

Quelques liens pour finir :

Le forum de LinuxJobs.fr
Linuxjobs.fr, le site d’emploi de la communauté du Logiciel Libre et opensource
Le blog de LinuxJobs.fr

03 April, 2016 10:00PM by Carl Chenet

March 31, 2016

Le danger Github (revu et augmenté)

Suivez-moi aussi sur Diaspora* ou Twitter

Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez Github (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de Github par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.

Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par Github ont pris une place considérable dans l’ingénierie logicielle ces dernières années.

Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.

1. Points critiques

1.1 La centralisation

L’application Github appartient et est gérée par une entité unique, à savoir Github, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.

De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas Github, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on est pas « dans le coup » quand on n’utilise pas Github, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).

1.2 Un logiciel privateur

Lorsque vous interagissez avec Github, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de Github on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec Github). Et surtout un outil crucial propriétaire fourni par Github qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.

1.3 L’uniformisation

Travailler via l’interface Github est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant Github comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils Github en travaillant pour une autre société. Cette fréquence de l’utilisation de Github dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.

L'uniforme évoque l'armée, ici l'armée des clones

2. Validité des points critiques

2.1 Les critiques de la centralisation

2.1.1 Taux de disponibilité du service

Comme dit précédemment, Github est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée. Des attaques massives par dénis de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de Github elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.

2.1.2 Blocage de la construction du Logiciel Libre par réaction en chaîne

Aujourd’hui plusieurs outils de gestion des dépendances comme npm dans le monde javascript, Bundler dans le monde Ruby ou même pip pour le monde Python sont capables d’aller chercher le code source d’une application directement depuis Github. Les projets du Logiciel Libre étant de plus en plus intriqués, dépendants les uns des autres, si l’un des composants de la chaîne de construction vient à manquer, c’est toute la chaîne qui s’arrête.

Un excellent exemple de cet état de fait est la récente affaire du npmgate (voir l’article Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre). Github peut très bien demain être mis en demeure par une entreprise de retirer du code source de son dépôt, ce qui pourrait entraîner une réaction en chaîne menant à l’impossibilité de construire de nombreux projets du Logiciel Libre, comme cela vient d’arriver à la communauté Node.js à cause de la société Npm, inc. gérant l’infrastructure de l’installeur automatisé npm.

2.2 Un peu de recul historique : SourceForge

Même si l’ampleur du phénomène n’a pas été la même, il est bon de rappeler que Github n’est pas apparu ex-nihilo et avait un prédécesseur ayant joui en son temps d’un engouement important : SourceForge.

Fortement centralisé, reposant également sur de fortes interactions avec la communauté, SourceForge est un SAAS fortement vieillissant ces dernières années et subit une véritable hémorragie de ses utilisateurs au profit de Github. Ce qui signifie beaucoup d’ennuis pour ceux qui y sont restés. Pour le projet Gimp, il s’agit tout d’abord d’abus publicitaires trompeurs indignes, qui entraînent également le départ du projet VLC , puis l’apparition d’installeurs comprenant des adwares se faisant passer pour l’installeur officiel Windows de Gimp. Et enfin purement et simplement le piratage du compte SourceForge du projet Gimp par… les équipes de SourceForge elle-même.

Nous voyons ici des exemples récents et très concrets des pratiques dont sont capables les sociétés commerciales lorsqu’elles sont sous la pression de leurs actionnaires. D’où la nécessité de bien comprendre l’enjeu représenté par le fait de leur confier une centralisation des données et des échanges ayant de fortes conséquences sur le fonctionnement et les usages de la communauté du Logiciel Libre et opensource.

2.3 Les critiques relatives à utiliser un logiciel privateur

2.3.1 Une communauté, différents rapports au logiciel propriétaire

Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre et opensource, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

bsdvsgpl

Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek, car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.

Les pendants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser Github. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.

FreeBSD, principal projet des BSD sous licence MIT

2.3.2 Les pertes de données et obstructions liées à l’usage d’un logiciel privateur

Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de Github elle-même, l’utilisation du gestionnaire de suivi de bugs de Github pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.

Github propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de Github ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par Github ?

L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez Github serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez Github ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de Github.

Autre perte si Github disparaît ou devient inaccessible : le travail de revue des « push requests » (abrégées par PRs) en cours. Pour les lecteurs qui ne connaîtraient pas cette fonctionnalité de Github, il s’agit d’adresser de cloner le dépôt Github d’un projet, de modifier ce clone pour l’adapter à vos besoins, puis ensuite de proposer vos modifications au dépôt d’origine. Le propriétaire du dépôt d’origine va alors étudier les modifications qui lui ont été proposées et si elles lui conviennent les fusionner à son propre dépôt. Il s’agit donc d’une fonctionnalité très importante offerte de Github, qui propose de réaliser les différentes opérations graphiquement via son interface.

Toutefois le travail de revue des modifications proposées peut être long et il est courant d’avoir, pour un projet qui marche bien, plusieurs PRs en cours. Et il est également courant d’échanger des commentaires via ces PRs et/ou via le système de suivi de bugs propriétaires de Github dont nous avons parlé plus haut.

Le code en lui-même n’est donc pas perdu si Github devient inaccessible (quoique, voire plus bas un cas spécifique), mais le travail de revue matérialisée par les éventuels demandes et commentaires présents dans les PRs et les suivis de bugs associés l’est bien, lui. Rappelons également que Github permet de cloner des projets via son interface web propriétaire, puis d’y apporter toujours via la même interface des modifications et ensuite de générer des PRs sans télécharger aucunement le code sur son poste. Dans ce cas de figure, si Github devient indisponible, la perte du code et du travail en cours est totale.

Enfin certains utilisateurs se servent de Github entre autre comme d’une application de favoris, afin de suivre l’activité de leurs projets préférés en s’abonnant à ces projets par la fonctionnalité « Watch ». Ce travail de réunion de données pour la veille technologique est perdu en cas d’indisponibilité du service Github.

Debian, l’un des principaux projets du Logiciel Libre avec autour de 1000 contributeurs officiels

2.4 L’uniformisation

La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.

Github a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.

Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur Github avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.

Et c’est bien dommage car Github, en proposant une expérience unique et originale à ses utilisateurs, taille à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à Github d’initier à Git les nouveaux arrivants dans le développement à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.

3. Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?

Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.

L’effet Github est donc délétère au point de vue des effets qu’il entraîne : la centralisation, l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre « Cher Github… » met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de Github d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.

Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternative et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capable de programmer devrait avoir ce réflexe. Vous n’aimez pas ce qu’offre Github ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.

Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à Github et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.

Finalement, l’utilisation de Github suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec Github. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.

Texte sous licence Creative Commons CC BY-ND 3.0 FR

31 March, 2016 09:00PM by Carl Chenet

August 01, 2012

Grégory Colpart

Astuces pour gérer un répertoire ext3 bien rempli

Disclaimer : Valable pour de l’ext3 sous Linux (utilisable sur d’autres filesystems ou Unix à vos disques et péril)

Vous avez un répertoire rempli à rabord de nombreux fichiers, et il est impossible de connaître sa taille, le lister ou l’effacer sans impact sur la production ?

Voici quelques astuces :

– Avec un “ls -ld” sur le répertoire, vous pouvez estimer grossièrement le nombre de fichiers présents dans un répertoire. En effet, un répertoire vide fait 4 Ko (je simplifie). Et plus il contient de fichiers, plus sa taille va augmenter. Par exemple, un répertoire contenant 2 millions de fichiers pourra faire une taille de 100 Mo (je parle bien de la taille du répertoire et non pas de la taille du contenu). Attention, c’est variable selon la longueur des noms des fichiers. Et prendre garde aussi que ce n’est pas dynamique : si vous videz complètement un répertoire bien rempli, il gardera sa taille volumineuse (d’où l’intérêt de recréer un répertoire qui s’est rempli “par erreur”).

– Pour lister les fichiers du répertoire, utiliser la commande “ls” n’est pas une bonne idée car elle accède à toute la liste avant de l’afficher. Voici comment lister 10 fichiers sans attendre :

perl -le 'opendir DIR, "." or die; $i=0; while ($i<10) { my $f = readdir DIR; print $f; $i++; }; closedir DIR'

Grâce à leurs noms, vous pouvez désormais examiner (ouvrir, connaître sa taille) un échantillon de fichiers contenus dans votre fameux répertoire.

Pour lister l’ensemble des fichiers sans attendre comme “ls” :

perl -le 'opendir DIR, "." or die; print while $_ = readdir DIR; closedir DIR'

– Pour effacer le contenu du répertoire en limitant l’impact sur la production, oubliez “rm -rf” qui va saturer vos I/O disque mais préférez le faire par blocs de N fichiers avec des pauses de quelques secondes ! Voici une commande “conviviale” qui va faire cela par blocs de 300 fichiers avec des pauses de 5 secondes :

perl -le 'use POSIX qw/strftime/; opendir DIR, "." or die; $i=0; printf "DELETING IN PROGRESS...";
 while (my $f = readdir DIR) {unlink $f;  $i++;
 if ($i % 300 == 0) {printf "...$i files deleted\n".strftime("%Y-%m-%d %H:%M:%S",localtime)." : PAUSE...";
 $| = 1; sleep 5 ; printf "...DONE. "; printf "DELETING IN PROGRESS..."}}; printf "...DONE"; closedir DIR'

EDIT : en complément, on n’oubliera pas que l’on peut aussi gérer la priorité d’ordonnancement des I/O avec la commande ionice
(merci à Sylvain B. de l’avoir souligné)

01 August, 2012 02:24AM by Gregory Colpart

August 18, 2010

Mon compte-rendu de DebConf 10 à New York

DebConf est la conférence annuelle des développeurs du projet Debian. Cela permet aux développeurs et contributeurs de Debian d’assister à des présentations techniques, sociales et politiques, mais aussi de se rencontrer et travailler ensemble. Cette année, la 11e DebConf s’est tenue à New York du 1er au 7 août. Evolix a sponsorisé cette conférence et j’étais donc sur place, voici mon résumé de cette semaine.

Premiers pas plutôt festifs le vendredi soir avec le SysAdmin Day dans un bar à Manhattan puis direction Brooklyn pour une Debian Party organisée par NYC Resistor, un collectif local de hackers en électronique à l’origine de MakerBot, une imprimante 3D Open Source. Samedi c’est l’arrivée à Columbia University, l’université américaine qui accueille la DebConf 10. Une bonne partie des participants est hébergée sur le campus universitaire, dans des chambres avec accès haut-débit et une cafétéria à volonté.

C’est donc le dimanche 1er août que commence la DebConf avec des présentations orientées grand public pour cette première journée appelée le “Debian Day”. Un grand message de bienvenue pour un public plus large en ce premier jour, puis enchaînement des présentations. J’ai tout d’abord assisté à une présentation sur le sysadmin par François Marier qui a livré toutes ses astuces et une série de packages intéressants (unattended-upgrades, safe-rm, etckeeper, fcheck, fwknop, etc.). J’ai d’ailleurs pu échanger par la suite avec lui d’autres informations, sachant qu’il travaille dans une boîte similaire à Evolix : Catalyst située en Nouvelle-Zélande ! J’ai ensuite assisté à la présentation de Stefano Zacchiroli, l’actuel leader Debian, qui encourage fortement les développeurs à réaliser des NMU (Non Maintainer Upload), c’est-à-dire la publication d’un package par un autre développeur que celui responsable officiellement. J’ai ensuite poursuivi avec la présentation du Google Summer of Code 2010 de Debian : une présentation générale puis plusieurs “étudiants” expliquent leur projet en cours : Debian-Installer pour OpenMoko, GUI pour aptitude en QT, etc. D’autres présentations ont ensuite suivies, mais j’ai plutôt été découvrir le “hacklab” : une pièce pourvue de multiprises, switches et points d’accès afin de permettre à plusieurs dizaines de personnes de travailler/hacker. Le “Debian Day” a été un franc succès avec plusieurs centaines de participants. En soirée, c’est l’heure du coup d’envoi “officiel” de la DebConf par Gabriella Coleman, l’une des organisatrices de la DebConf 10, qui présente avec humour la semaine à venir, avec un petit retour en images sur les éditions précédentes.

Deuxième jour, on a le droit à un Bits from DPL en direct de la part de Stefano Zacchiroli (au lieu du traditionnel mail). Ensuite, il y a de nombreuses présentations. Durant DebConf, il y en aura plus de 100 au total, réparties dans 3 salles : Davis (avec vidéo), 414 Schapiro et Interschool (avec vidéo). Le choix est parfois difficile ! Pour ma part, j’ai assisté en fin de matinée à la présentation de la structure américaine à but non lucractif SPI : c’est elle qui gère les droits de la marque Debian, mais pas seulement : OpenOffice.org, Drupal, PostgreSQL, Alfresco, etc. de nombreux projets de logiciels libres utilisent cette structure légale ! Dans l’après-midi, c’est Mark Shuttleworth, fondateur d’Ubuntu et CEO de Canonical, qui nous présente le travail réalisé pour améliorer l’interface graphique des netbooks, notamment par l’intermédiaire du projet Ayatana. Puis, Jorge Castro, responsable chez Canonical des relations avec les développeurs extérieurs, parle de la collaboration entre Ubuntu et Debian. On notera que toute une équipe de Canonical est venue à DebConf et que les relations avec Debian semblent devenir plus sereines. Le soir venu, c’est l’heure de Wine&Cheese, un évènement devenu incontournable pour une DebConf : imaginez des centaines de fromages et alcools venus du monde entier (Italie, Allemagne, France, Mexique, Brésil, USA, Taïwan, Pologne, Kazhastan, Espagne, Nouvelle-Zélande, Corse, Vénézuela, Hollande, Marseille, Irlande, Angleterre, Japon, etc. etc.) et plus d’une centaine de développeurs Debian lâchés dessus pendant des heures… le résultat est… indescriptible ! Pour ma part, j’avais apporté un rosé Bandol, des bières La Cagole, du Banon et de la Tapenade… qui n’ont pas fait long feu.

Troisième jour et l’on débute par un talk d’Eben Moglen, avocat de la FSF, qui rappelle les dangers du Cloud Computing comme la gestion des données privées. Sa réponse : “Chacun devrait avoir un serveur chez soi” et il évoque la FreedomBox, une boi-boîte que tout le monde aurait chez soi pour faire office de petit serveur avec les fonctionnalités classiques (web, messagerie, VoIP). Cette idée rencontre un certain enthousiasme et plusieurs réfléchissent déjà à la réalisation de cette idée ! J’ai ensuite suivi une succession de présentations sur le thème de l’entreprise. On a parlé du déploiement de machines avec le logiciel Puppet, de l’installation automatisée de Debian avec FAI et Gosa, notamment présentée par Mickaël Bank, un développeur allemand très actif dans Debian. On a également des témoignages très intéressants : Russ Allbery, administrateur système et réseau à l’université de Standford en Californie, explique quels sont les arguments en faveur de Debian en entreprise et en profite pour présenter la gestion de Debian à Standford ; Faidon Liambotis, sysadmin chez GRNET (un opérateur public grec), présente leur utilisation de Debian mais aussi leurs choix en terme de déploiement (Puppet/FAI) ou de virtualisation (KVM/Ganeti). Pour terminer la journée, Guido Trotter de chez Google, nous parle des fonctionnalités réseau intéressantes sous Linux (VLAN, tunnels, routing, etc.). Une journée riche en idées et en informations ! En soirée, nous avons visualisé le film Open Source Sita Sings the Blues et Nina Paley nous a expliqué son choix d’une licence libre pour son film.

Le quatrième jour, c’est le Day Trip. Il s’agit classiquement d’une journée consacrée à des activités touristiques extérieures. Nous avons été visiter l’église Trinity Church à Manhattan où le drame du 11 septembre 2001 a mis un superbe orgue hors d’usage, remplacé temporairement par un orgue électronique “Powered by Linux”… qui a finalement été conservé en raison de sa qualité. Keith Packard, l’un des gourous de X.org employé chez Intel, a joué quelques minutes sur cet orgue. Ensuite, direction la plage de Coney Island. Puis un match de baseball où Stefano Zacchiroli lancera la première balle du match.

Cinquième jour, on reprend avec un BoF (un BoF=Birds of a Feather est une discussion informelle de groupe) sur la virtualisation où plusieurs personnes témoignent de leurs expériences et connaissances sur le sujet. Pas mal d’informations intéressantes, notamment sur le couple Ganeti/KVM pas mal mis en avant par Iustin Pop, l’un des développeurs de Ganeti employé chez Google. J’y apprends notamment que KVM gère une notion de mémoire partagée et ainsi démarrer une 2e machine virtuelle avec un même OS ne consommerait pas de mémoire supplémentaire sur le système hôte ! Suite des présentations, notamment une portant sur DebConf 12 qui pourrait peut-être se dérouler au Brésil. Et fin de la matinée avec François Marier qui présente le projet Libravatar permettant d’offrir une alternative à Gravatar, l’outil centralisé de gestion des avatars. Ses idées sont de se baser sur les DNS pour répartir les avatars pour chaque noms de domaine. Il a déjà commencé à développer une application en Django pour gérer cela. Suite de la journée avec un BoF sur Lintian (outil de vérification de la conformité des packages Debian) géré par Russ Allbery. Puis j’ai assisté à une présentation de Guido Günther qui a expliqué comment gérer son packaging avec Git et notamment git-buildpackage (très intéressant pour moi car je gère déjà mes packages Debian comme ça). Ensuite, petite pause sportive, car une dizaine de développeurs Debian a été participé à un cross de 5 kms dans le Bronx, avec des résultats honorables !

Sixième jour, on débute par Bits from Release Team qui déclare en direct que Squeeze, la prochaine version stable, est désormais freezée ! Un scoop à DebConf ! C’est ensuite Stefano Zacchiroli qui nous présente son travail en cours sur une amélioration de la gestion des dépendances, non seulement pour Debian mais aussi pour les autres distributions : plus de détails sur le site du projet Mancoosi. C’est ensuite la traditionnelle photo de groupe. En début d’après-midi, Margarita Manterola dresse un constat très lucide de l’état de Debian avec son talk Making Debian Rule, again. Puis en fin d’après-midi, c’est un BoF très apprécié mené par Joey Hess sur CUT (Constantly Usable Testing) qui explore les possibilités d’avoir une distribution Testing utilisable en permanence ! Le soir venu, c’est un BoF sur l’utilisation d’OpenPGP et la classique Keysigning Party qui a regroupé plusieurs dizaines de participants.

Septième et dernier jour, encore de nombreuses présentations. J’ai notamment assisté à celle de Philippe Kern, membre de la Release Team, qui a parlé du management de la version stable et de volatile. On notera par exemple qu’on peut désormais corriger des bugs en priorité “Important” dans les points de Release. La suite ce sont des fameux Lightnings Talks, une dizaine de présentations très courtes : une qui suggère d’arrêter complètement d’utiliser les mots de passe, une autre sur le logiciel runit, une autre sur les éclairs (lightnings !) ou encore l’historique en photos des Wine&Cheese Party ! Fun et instructif. Puis c’est l’heure de la conférence de clôture, où l’on remet des prix à ceux qui ont corrigé le plus de bugs mais surtout tous les volontaires sont vivement remerciés et j’en profite pour adresser une nouvelle fois mes remerciements à :
– L’équipe qui a organisé cette DebConf 10 : un travail impressionnant pour un résultat professionnel et communautaire à la fois : on frôle la perfection !
– L’équipe vidéo qui a fait un travail génial et vous pouvez ainsi retrouver l’ensemble des talks en vidéo,
– Les centaines de personnes sympas et passionnées qui contribuent à faire de Debian une distribution de grande qualité… et qui sait évoluer, la preuve avec les sujets abordés lors de cette DebConf !

Petite conclusion de cette semaine intensive, comme vous avez pu le lire : j’ai pu acquérir de nombreuses informations et faire le plein de nouvelles idées, mais aussi avoir des contacts réels avec d’autres développeurs et comprendre encore mieux le fonctionnement “social” de Debian. C’est donc très positif et cela va me permettre d’améliorer mon travail quotidien au sein d’Evolix, mais aussi réfléchir à d’autres projets et me motiver pour contribuer davantage à Debian. Debian rules !

18 August, 2010 11:52AM by Gregory Colpart

January 24, 2010

Autres exemples de migration Etch->Lenny [1]

La fin du support officiel de Debian Etch approchant, il est grand temps de migrer vers Lenny pour les machines pas encore à jour. Après un premier exemple de migration Debian Etch->Lenny, je poursuis la série avec des informations tirées de plusieurs migrations récentes sur des serveurs en production.

Je ne rappellerais pas toutes les précautions nécessaires (tests préalables, sauvegardes, désactivations des services, etc.) ni la classique question sur “quand faut-il migrer ?”, vous trouverez tout cela dans mes exemples précédents. Je rappelle simplement l’idée de base : prendre les précieuses Release Notes, mettre à jour le fichier sources.list, puis exécuter les commandes aptitude update && aptitude upgradex, puis mettre-à-jour les services les plus critiques via aptitude install <PACKAGE>, et enfin aptitude dist-upgrade && aptitude dist-upgrade (répéter dist-upgrade est souvent nécessaire).

Passons désormais aux différentes remarques sur ces migrations :

– PostgreSQL : on passe de la version 8.1 à 8.3. Notez qu’il s’agit de paquets différents, il est donc possible de garder la version 8.1 en Etch, et d’installer en parallèle la version 8.3, afin de faciliter encore plus la migration. Pour migrer les données, on réalisera un dump avec pg_dumpall qui sera réinjecté dans la nouvelle base. On pourra ensuite adapter le port dans postgresql.conf pour passer la version 8.3 en production.

– phpPgAdmin : avec PostgreSQL 8.3, on ne peut plus se connecter à la table template1 : c’est le comportement par défaut de phpPgAdmin, qu’on devra donc modifier en mettant postgres à la place (pour la variable $conf[‘servers’][0][‘defaultdb’] dans le fichier config.inc.php)

– Apache : la configuration de l’alias /icons/ est déplacé dans le fichier mods-available/alias.conf, il peut donc faire doublon avec la déclaration dans apache2.conf, ce qui sera signalé via le warning suivant : [warn] The Alias directive in /etc/apache2/apache2.conf at line 240 will probably never match because it overlaps an earlier Alias. Commenter les directives dans le fichier apache2.conf résoudra ce petit soucis.

– OpenLDAP : on passe d’une version 2.3 à 2.4, mais le plus marquant pour la migration est que cela force le processus à tourner avec un utilisateur/groupe dédié. Pour diverses raisons (dist-upgrade interrompu par exemple), on pourra rencontrer des soucis plus ou moins alarmants. Ainsi, j’ai pu rencontrer cette erreur :
bdb(dc=example,dc=com): PANIC: fatal region error detected; run recovery
bdb_db_open: database “dc=example,dc=com” cannot be opened, err -30978. Restore from backup!
backend_startup_one: bi_db_open failed! (-30978)
slap_startup failed
On veillera donc sur l’utilisateur/groupe propriétaire des fichiers dans le répertoire /var/lib/ldap et, au besoin, on ajustera : chown -R openldap:openldap /var/lib/ldap/
Mon conseil : mettre-à-jour le paquet slapd de façon spécifique avant le dist-upgrade

– Postfix : on passe de 2.3 à 2.5. On notera simplement la valeur par défaut de $smtp_line_length_limit characters qui passe à 990, ce qui coupe les lignes trop longues pour se conformer au standard SMTP. Si cela posait problème, on pourrait revenir à l’ancien comportement en positionnant smtp_line_length_limit=0

– SpamAssassin : l’utilisant en stockant la configuration des utilisateurs dans un annuaire LDAP, le daemon spamd s’est mis à râler : cannot use –ldap-config without -u
Le problème sera résolu en ajoutant l’option -u nobody, ce qui fera tourner spamd en tant que nobody (ce qui n’est pas une mauvaise chose, au contraire).

– Amavis : apparemment, lors de la détection d’un virus, le code retourné n’est plus 2.7.1 mais 2.7.0 : 2.7.0 Ok, discarded, id=13735-07 – VIRUS: Eicar-Test-Signature
Rien de bien grave, mais cela a nécessité d’adapter un plugin Nagios pour qu’il attende le bon code de retour.

– Courier-imapd-ssl : après une mise-à-jour gardant mon fichier /etc/courier/imapd-ssl actuel, j’obtenai des erreurs avec certains clients IMAP :
couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
En regardant de plus près, certaines directives changent dans ce fichier de configuration, et il est donc conseillé de repartir du fichier proposé par Lenny, et d’y apporter ses modifications (souvent, cela se limite à préciser le certificat).

– Horde : si vous utilisez une base de données pour stocker les paramètres ou autres, la paquet php-db (déjà en Recommends: en Etch) est d’autant plus nécessaire, sous peine d’obtenir l’erreur : PHP Fatal error: _init() [<a href=’function.require’>function.require</a>]: Failed opening required ‘DB.php’ (include_path=’/usr/share/horde3/lib:.:/usr/share/php:/usr/share/pear’) in /usr/share/horde3/lib/Horde/DataTree/sql.php on line 1877

– Sympa : on attaque là le cauchemard de mes migrations. À chaque fois, tellement de soucis majeurs et mineurs, que j’ai l’impression d’être le seul à utiliser ce paquet. Voici en vrac tous les soucis rencontrés : les accents dans les descriptions ont sautés (une sorte de double encodage) et cela a nécessité des corrections manuelles, la table logs_table doit être créée à la main (j’utilise Sympa avec PostgreSQL), et enfin une typo surprenante un “GROUP BY” à la place d’un “ORDER BY” (j’ai ouvert le bug #566252 à ce sujet).

– Asterisk : on passe de la version 1.2 à la version 1.4. Lors de la migration, j’ai constaté un bug étrange, le fichier modules.conf qui charge les modules additionnels a disparu. Du coup, sans lui, Asterisk ne charge pas les modules nécessaires (SIP, etc.). Il a donc fallu le restaurer.

– udev : le meilleur ami des sysadmins (ou pas). Si les migrations douloureuses Sarge->Etch sont loin derrière nous, il reste néanmoins quelques blagues. La dernière en date a été un renommage des interfaces réseau : eth0->eth1 et eth1->eth2. Classique mais étonnant, ce genre d’humour est sensé être dépassé grâce aux “persistent rules” qui nomment les interfaces en fonction de l’adresse MAC. À rester vigilant sur ce point avant le redémarrage donc.

Voilà pour les remarques. Vous noterez que je n’ai pas abordé le noyau Linux. C’est parce que pour la majorité de nos serveurs, ils sont gérés de façons spécifiques (au lieu d’utiliser les noyaux officiels Debian). Ainsi, ils restent dans leur version actuelle (2.6.31 à cette heure) pendant la migration. Bien sûr, cela n’empêche pas d’effectuer un redémarrage de la machine suite à la mise-à-jour : cela permet de s’assurer que tout est bien en place et le sera toujours après un éventuel redémarrage d’urgence.

Rendez-vous pour de prochaines migrations !

24 January, 2010 06:05PM by Gregory Colpart

August 24, 2026

Les bases

Interlude historique

Élection de la racine

Attribution des rôles aux ports

Transition d’état des ports

Notification de changement de topologie

Sécurité

Pourquoi RSTP aujourd’hui ?

Quelle taille pour un réseau ?

RSTP est-il rapide ?

À propos de MSTP

À propos des exemples interactifs

June 16, 2026

Les premières années

La chute

June 09, 2026

June 07, 2026

A. Formats de fichier

1. Makefile

2. Justfile

3. Taskfile

B. Exemples équivalents

1. Makefile

2. Justfile

3. Taskfile.yml

C. Paramètres à passer à la commande

1. Makefile

2. Justfile

3. Taskfile

D. Prise en compte de fichier .env

1. Makefile

2. Justfile

3. Taskfile

E. Lister les commandes disponibles

F. Ne pas afficher la commande exécutée

Conclusion

Les restes

May 24, 2026

Implémentation précédente

Stocker les routes dans une table associative

Canonisation des routes

Qu’est-ce qui pose problème ?

Sharding de la RIB

Première étape

Deuxième étape

April 26, 2026

April 22, 2026

Pour le texte

Pour les images adaptatives

Pour les tableaux

February 11, 2026

Un contexte économique mondial qui a changé

Un transfert de capacité plutôt qu'une augmentation nette

Ray-Mont Logistiques, entre l'arbre et l'écorce

December 20, 2025

L’auteur

September 18, 2025

Introduction

Faillite 1: Le privé en santé échoue depuis un siècle

Faillite 2: Le privé en santé échoue à réduire les coûts

Faillite 3: Le privé en santé échoue à être efficace

Faillite 4: Le privé en santé échoue à désengorger le public

Faillite 5: Le privé en santé échoue à préserver la qualité et l'équité

April 08, 2025

December 18, 2024

November 30, 2024

November 25, 2024

Notify-send

Zenity

Kdialog

Xmessage

Versions utilisées

November 19, 2024

October 08, 2024

1. Le Québec est trop endetté et doit réduire sa dette

2. Le déficit budgétaire force le gouvernement à couper

3. Nous manquons d'argent pour nos politiques sociales

September 26, 2024

AGO de Debian France

Pourquoi RSTP aujourd’hui ?

Quelle taille pour un réseau ?

RSTP est-il rapide ?

D. Prise en compte de fichier `.env`

3. Taskfile 

Qu’est-ce qui pose problème ?