Résumé

  • Dans le lanceur historique de rpki-client, les deux actions réutilisent rpkic_rpkiv5_cache, mais le montage passe de /var/cache/rpki-client à /root/cache.
  • La persistance du volume ne suffit pas à prouver que l’application retrouve son cache. Le chemin effectivement utilisé par l’image n’a pas été vérifié ici.
  • L’image, les arguments communs et le montage des ancres de confiance restent identiques. Les trois autres lanceurs examinés conservent leurs destinations respectives.
  • L’analyse porte sur un état du dépôt daté du 1er avril 2024, consulté le 14 septembre 2026. Elle ne constate ni nouvelle migration, ni perte de données, ni échec en production.

Une expérience comporte aussi une adresse

Pour comparer deux services, il faut savoir ce qui passe de l’un à l’autre. Le dépôt public de LACNIC propose une séquence très concrète : lancer une partie utilisatrice contre le service existant, attendre que son cache soit rempli, arrêter le conteneur, puis recommencer contre le service de remplacement en conservant ce cache. Le stockage persistant est donc une condition de l’expérience, pas seulement un moyen commode de ranger des fichiers.

Une partie utilisatrice est ici le logiciel qui traite les données RPKI pour produire des informations de routage validées. Une exécution avec des données déjà acquises n’interroge pas exactement la même situation qu’une découverte à partir d’un état vierge. Les deux essais peuvent être utiles. Encore faut-il éviter que l’un soit présenté comme l’autre. La comparaison annoncée suppose de transporter un état antérieur, pas simplement de réutiliser un nom.

Le fichier rpkic_run.sh conserve effectivement ce nom : rpkic_rpkiv5_cache. Dans l’action current, le volume est exposé à /var/cache/rpki-client à l’intérieur du conteneur. Dans l’action rpkiv5, il apparaît à /root/cache. Le stockage sélectionné reste le même dans les instructions ; la coordonnée sous laquelle il devient visible change. C’est ce décalage, et lui seul, qui motive la question.

La documentation de Docker distingue les deux éléments. La source désigne le volume ; la destination désigne le répertoire du conteneur où son contenu est monté. Un volume nommé peut survivre au conteneur qui l’a utilisé et être rattaché à un autre. Cela ne détermine pas automatiquement le répertoire où un programme cherchera ses données. Conserver le meuble et déplacer sa porte d’accès ne suffit pas à montrer que le programme emprunte cette porte.

Cette dernière image ne doit pas remplacer la preuve. Une configuration interne, un lien symbolique ou l’organisation de l’image pourrait rendre les deux destinations équivalentes pour l’application. Rien de cela n’a été examiné. On ne sait donc pas si une exécution réelle aurait retrouvé son cache, commencé sans lui, ou utilisé un autre emplacement. Le changement de chemin est observable dans le code ; la perte du cache ne l’est pas.

Le périmètre est historique, pas opérationnel

Les fichiers étudiés appartiennent au commit immuable fdbecab2890e0da2f9a393ac4be2659d14f54ca2, daté du 1er avril 2024. La consultation du 14 septembre 2026 ne transforme pas ce matériau en annonce actuelle. Elle permet de discuter une instruction publique précisément située. Elle ne reconstruit pas les conteneurs effectivement employés lors de la migration et ne décrit pas les installations actuelles de LACNIC.

Le README indique que l’action de remplacement détourne la résolution d’un nom pour atteindre le nouveau service RRDP, la surface de récupération des dépôts nommée dans les scripts. Il propose ensuite une comparaison manuelle des sorties, par exemple du nombre de charges utiles validées d’origine de route, les VRP. Il mentionne aussi une autorité de certification enfant qui n’était pas encore répliquée dans le contexte décrit. Cette réserve est historique ; elle ne prouve aucune absence actuelle.

L’intérêt du document est de rendre l’objectif explicite. Le premier conteneur doit avoir terminé un cycle et constitué un cache avant le second. Si cette condition n’est pas établie, une différence de sortie peut mêler deux changements : celui du service et celui de l’état initial. Une égalité de sortie ne résout pas nécessairement la difficulté non plus. Elle indique une observation, dont la portée dépend des conditions qui l’ont produite.

Le nombre d’éléments constitue une comparaison utile mais limitée. Deux ensembles de même taille peuvent contenir des éléments différents. Ce constat logique n’est pas une accusation selon laquelle les sorties du test auraient divergé. Il rappelle simplement qu’un total ne certifie ni l’identité du résultat ni la continuité du cache. Le paquet de sources examiné ne fournit pas un compte rendu d’exécution appariée permettant d’établir cette continuité.

Ce qui ne change pas mérite autant d’attention

Le lanceur de rpki-client garde plusieurs paramètres constants. Les deux actions sélectionnent la chaîne d’image rpki/rpki-client:8.2, montent le même répertoire local d’ancres de confiance à /etc/tals et emploient la chaîne commune -s 480 -c -v -v -v. Les options communes de lancement détaché et de DNS restent également les mêmes. D’autres versions de l’image figurent en commentaire, pas comme commandes actives.

Ces constantes réduisent la portée de la critique. Il serait inexact de raconter un essai où tout aurait été remplacé sans précaution. Le code conserve plusieurs contrôles pertinents, dont le nom du volume lui-même. L’écart porte sur sa destination. Si l’image démontre que cette destination correspond bien au chemin effectif du cache, l’inquiétude se trouverait réduite. La preuve doit toutefois venir de cette relation, pas du seul caractère rassurant du nom.

La chaîne de version ne constitue pas non plus un examen de l’image. Aucun téléchargement, aucune inspection d’un point d’entrée, aucun contrôle des permissions ou des alias de répertoire n’a été effectué. Le sens précis des options n’a pas été déduit sans documentation de version. L’analyse constate seulement que les mêmes chaînes apparaissent dans les deux actions. Elle ne prétend pas savoir ce que l’application a exécuté derrière elles.

L’action rpkiv5 ajoute une correspondance du nom RRDP vers 96.126.99.186. Cette adresse est un paramètre historique, non une destination contactée pendant ce travail. Changer de service est attendu dans une expérience de migration. Changer simultanément la destination du stockage est un autre paramètre, qui doit être expliqué si l’on veut attribuer le résultat au seul passage vers le service de remplacement.

Les voisins empêchent une conclusion trop large

Le lanceur de FORT conserve /root/cache dans ses deux actions. Les deux lanceurs de Routinator conservent chacun /home/routinator/.rpki-cache. La variante antérieure à 0.12 sélectionne une chaîne d’image v0.10.1. Ces observations ne démontrent pas que ces programmes ont effectivement réutilisé leurs caches. Elles montrent néanmoins qu’un déplacement de destination n’est pas une nécessité générale du mécanisme de migration publié.

L’écart du lanceur de rpki-client ne peut donc pas devenir « les validateurs de LACNIC perdent leur cache ». On observe un changement dans une paire d’instructions. On n’a observé ni la flotte de production du registre, ni une exécution d’opérateur, ni une perte de charges utiles. Les autres scripts servent ici de contrepoints, pas de résultats de conformité ou de garanties de sécurité attribuées à leurs auteurs.

Ils révèlent aussi des paramètres secondaires qu’un compte rendu d’essai devrait conserver. Dans le lanceur récent de Routinator, l’action courante utilise les arguments communs de serveur avec --refresh=120, tandis que l’action de remplacement écrit séparément des arguments sans cette option explicite. Le comportement par défaut n’est pas établi. Ce détail ne démontre donc ni retard ni anomalie ; il indique un élément supplémentaire à distinguer dans une comparaison.

Le fichier dnsmasq contient des correspondances RRDP et de dépôt de remplacement, ainsi que des correspondances anciennes commentées. Le README évoque la modification de l’option DNS si ce service n’est pas employé. Ces textes ne disent pas quel service DNS tournait réellement avant un essai. Il faut résister à une seconde histoire séduisante : celle d’une référence prétendument déjà dirigée vers le nouveau service. La configuration publiée ne suffit pas à l’établir.

Stockage, montage et état ne sont pas synonymes

Docker précise qu’un montage peut masquer les fichiers déjà présents dans le répertoire de destination d’un conteneur. Il décrit aussi la copie initiale possible de ces fichiers vers un volume vide selon le comportement par défaut. Ce sont des propriétés de la plateforme. Elles ne révèlent pas le contenu de l’image sélectionnée ni le chemin choisi par cette version de rpki-client. Leur rôle est de montrer pourquoi le répertoire de destination est une donnée significative.

Il faut donc conserver trois niveaux de description. Le volume est le stockage géré par l’hôte. Le montage est son exposition dans un conteneur donné. Le cache est l’état que le programme consulte et utilise effectivement. La stabilité du premier ne certifie pas les deux suivants. Mais le changement du deuxième ne prouve pas la destruction du premier. Cette séparation protège l’analyse dans les deux sens : contre une continuité imaginée comme contre un échec inventé.

Sources

Sept documents fondent cette analyse : le README historique, le lanceur de rpki-client, celui de FORT, le lanceur récent de Routinator, sa variante ancienne, la configuration DNS et la documentation Docker. Deux sites de publication, pas sept enquêtes indépendantes. Aucun script n’a été exécuté.