Resumo

  • O lançador histórico de rpki-client usa rpkic_rpkiv5_cache nas duas ações, mas muda o destino de /var/cache/rpki-client para /root/cache.
  • Um volume com nome pode continuar existindo enquanto seu ponto de montagem muda. O código não demonstra qual caminho a imagem usa como cache nem se algum teste perdeu dados.
  • A imagem, os argumentos compartilhados e a ligação das âncoras de confiança permanecem iguais. Os outros três lançadores examinados preservam seus próprios destinos.
  • A análise consulta, em 14 de setembro de 2026, um commit de 1º de abril de 2024. Não executa comandos e não relata uma migração atual ou uma falha de produção.

O estado inicial faz parte da pergunta

O experimento descrito pelo LACNIC não começa com dois programas vazios. O README pede que o operador execute primeiro o software contra o serviço existente, espere a conclusão de uma rodada com o cache preenchido, pare o contêiner e inicie a ação voltada ao serviço substituto. O cache deve atravessar essa passagem. Sem ele, o segundo teste pode continuar útil, mas passa a responder a outra pergunta.

Esse software desempenha o papel de parte confiante: processa material RPKI e produz informações de roteamento validadas. Um programa que já possui estado adquirido e um programa que descobre tudo novamente podem enfrentar condições distintas. Não é preciso afirmar que isso provocou qualquer problema para reconhecer a diferença. Se o objetivo escrito é testar uma passagem com estado anterior, a presença e o uso desse estado precisam ser estabelecidos.

O volume persistente é uma escolha razoável para transportar os arquivos além da vida de um contêiner. No arquivo rpkic_run.sh, seu nome é rpkic_rpkiv5_cache tanto na ação current quanto na ação rpkiv5. A primeira o monta em /var/cache/rpki-client; a segunda, em /root/cache. O lado que seleciona o armazenamento fica constante. O lado que define onde o conteúdo aparece dentro do contêiner muda.

Essa observação é estreita. Não mostra que o conteúdo foi apagado, que o programa ignorou o volume ou que uma migração falhou. Mostra uma alteração nas condições declaradas de acesso ao armazenamento. Para passar dessa alteração a uma conclusão sobre o cache, é necessário saber qual diretório a imagem selecionada efetivamente utiliza. Essa relação ainda não foi verificada nesta análise.

A promessa do Docker termina antes da aplicação

A documentação oficial separa a origem do volume de seu destino no contêiner. Um volume com nome pode sobreviver à remoção do contêiner que o utilizou e ser reutilizado por outro. O nome identifica o armazenamento escolhido; o caminho de destino indica o diretório onde ele será exposto. Nenhuma dessas duas informações, sozinha, determina a configuração interna do programa.

Conservar o nome é, portanto, uma evidência positiva. O script não seleciona explicitamente outro armazenamento para a segunda ação. Mudar o destino tampouco é uma operação de apagar o conteúdo do volume. Mas a permanência do armazenamento não certifica que a aplicação reencontre seus dados. Ser preservado, estar visível e ser utilizado são propriedades relacionadas, não sinônimos.

Pode haver uma configuração, um atalho de diretório ou uma organização do ponto de entrada que torne as duas posições equivalentes para a aplicação. Também pode haver uma posição efetiva diferente das duas que o leitor presume. Não foi feita inspeção da imagem, de suas permissões, de ligações simbólicas ou do caminho usado pelo programa. Assim, nem a reutilização nem a ausência do cache estão demonstradas.

O Docker também explica que um volume montado sobre um diretório não vazio pode ocultar o conteúdo que já estava na imagem. Um volume inicialmente vazio pode receber conteúdo anterior do contêiner conforme o comportamento de cópia padrão. São regras da plataforma que tornam o destino relevante. Não são observações do conteúdo dessa imagem, nem uma prova de como essa versão de rpki-client organiza seu cache.

Há uma intenção pública, não uma execução reconstruída

O README descreve uma substituição de resolução de nome para levar a ação nova ao serviço RRDP de reposição, a superfície de recuperação de repositório nomeada nos scripts. Em seguida, sugere comparar as saídas manualmente, usando como exemplo a quantidade de cargas úteis validadas de origem de rota, as VRP. A sequência tenta mudar o serviço sem abandonar o estado da parte confiante.

Uma comparação com estado preservado e uma comparação a partir de estado novo devem continuar identificadas como cenários diferentes. Se o segundo programa não utilizar o mesmo estado inicial, uma diferença de saída poderá misturar a mudança de serviço com a mudança de condição de partida. Isso é uma possibilidade de interpretação, não um efeito observado. O material examinado não fornece uma execução emparelhada que resolva a questão.

Uma contagem igual também tem alcance limitado. Dois conjuntos podem conter a mesma quantidade de elementos e ter composições distintas. Não se constatou aqui que as saídas divergiram dessa forma. O ponto é que uma quantidade não demonstra identidade do conjunto e muito menos a origem do estado usado para produzi-lo. A observação precisa ser vinculada à afirmação específica que pretende sustentar.

A análise não diz que os responsáveis jamais realizaram testes internos. Distingue o que se pode ler nos arquivos públicos do que dependeria de um registro de execução. O código oferece nomes, destinos e parâmetros. Para demonstrar que uma execução carregou o cache anterior, seria preciso mostrar a relação efetiva entre armazenamento, aplicação e observação. Uma leitura estática não deve se apresentar como uma auditoria de funcionamento.

A data impede uma acusação fora de contexto

Os arquivos pertencem ao commit imutável fdbecab2890e0da2f9a393ac4be2659d14f54ca2, datado de 1º de abril de 2024. Foram examinados em 14 de setembro de 2026. Encontrar uma instrução histórica não a transforma em configuração atual de produção. Este texto não anuncia uma nova migração e não reconstrói quais contêineres realmente foram executados na transição antiga.

O README registra que uma autoridade certificadora filha ainda não havia sido replicada no contexto descrito. Essa ressalva deve permanecer histórica. Não comprova uma ausência hoje. Da mesma forma, os endereços e os nomes presentes nos scripts são entradas do experimento publicado, não destinos contactados durante esta revisão nem um retrato das instalações atuais do registro.

Fixar o commit permite falar de uma instrução precisa e preservar a diferença entre comentário e comando ativo. Não fixa o conteúdo de um volume existente no anfitrião, a identidade de uma imagem usada em uma execução ou os objetos que o programa já havia adquirido. Isso não significa que tais condições tenham mudado. Significa apenas que sua identidade exige evidência diferente da identidade do código.

Os controles que permanecem iguais

As duas ações de rpki-client escolhem a cadeia rpki/rpki-client:8.2. Ambas ligam o diretório local de âncoras de confiança a /etc/tals, usam os argumentos compartilhados -s 480 -c -v -v -v e mantêm as opções comuns de execução em segundo plano e DNS personalizado. As outras versões de imagem aparecem comentadas. Não devem ser tratadas como escolhas executadas por essas ações.

Essas constantes importam. O arquivo não troca indiscriminadamente todos os fatores. Preserva imagem, entradas de confiança, parâmetros compartilhados e origem do armazenamento. A crítica deve ficar na mudança de destino e na relação que falta verificar. Se uma explicação específica da imagem mostrar que os caminhos são equivalentes, a preocupação com o acesso ao cache diminui. Uma análise séria precisa reservar espaço para essa possibilidade.

A cadeia de imagem não equivale a uma imagem inspecionada com resumo criptográfico confirmado. Nenhuma imagem foi baixada ou executada. Também não se atribui um significado específico de versão às opções sem documentação adicional. Registrar igualdade de cadeias é mais restrito do que certificar igualdade de comportamento, mas é justamente o controle positivo que os arquivos permitem registrar.

A ação de reposição acrescenta uma correspondência do nome RRDP com 96.126.99.186. Não houve conexão a esse endereço. Mudar o serviço é esperado no desenho da migração; mudar onde o volume aparece é outra entrada. Se esta última alterar o estado efetivo, uma saída posterior não poderá ser atribuída somente ao serviço substituto. O script, isoladamente, não estabelece essa hipótese nem a descarta.

Os vizinhos limitam a generalização

O lançador de FORT mantém /root/cache em suas duas ações. O lançador mais recente de Routinator mantém /home/routinator/.rpki-cache; a versão anterior a 0.12 também mantém esse destino no próprio par e escolhe a cadeia de imagem v0.10.1. São comparações de instruções. Não provam reutilização correta de cache pelos três programas, mas mostram que deslocar o destino não é uma exigência geral do método publicado.

Por isso, a diferença de rpki-client não autoriza dizer que os validadores do LACNIC perdem cache. Não se observou a frota de produção do registro nem a execução de operadores. Os outros arquivos funcionam como contrapontos que mantêm a conclusão no par efetivamente examinado. A autoria institucional do repositório não amplia automaticamente o alcance operacional de cada linha.

Há parâmetros secundários a registrar sem transformar o artigo em outra tese. O Routinator recente usa, na ação atual, uma cadeia compartilhada de servidor com --refresh=120; na ação nova escreve argumentos separados sem essa opção explícita. Seu valor efetivo padrão não foi estabelecido. O arquivo dnsmasq contém correspondências de reposição e antigas correspondências comentadas, mas não demonstra qual serviço DNS estava realmente ativo.

O README admite editar a opção DNS se aquele serviço não for usado. Não se deve concluir, só pela configuração, que a referência já estava apontada ao serviço novo ou que houve um atraso de atualização. Esses seriam fatos adicionais sem observação. O assunto permanece a identidade do armazenamento e sua posição efetiva para a aplicação.

Fontes

Foram consultados o README histórico, o lançador de rpki-client, o de FORT, o Routinator recente, o lançador anterior, a configuração DNS e a documentação Docker. Sete documentos em dois locais de publicação, não sete investigações independentes. Nenhum comando de contêiner ou validador foi executado.