O velho .deb do openfortivpn serve para o seu Raspberry Pi?

Uma resposta num fórum entrega-lhe um nome de ficheiro completo, e o nome parece a solução: um .deb, um comando, feito. O que essa cadeia codifica na realidade é uma versão de pacote, uma arquitetura de CPU e a suite da distribuição contra a qual foi compilado no dia em que alguém escreveu a mensagem. Nenhum desses três descreve automaticamente a placa que está na sua secretária. A descarga antiga é um instantâneo da situação de uma máquina, não um plano de instalação para a sua.

O que o nome do ficheiro fixa em silêncio

Leia um nome como openfortivpn_1.17.0-1_armhf.deb da direita para a esquerda. O sufixo é a arquitetura para a qual o binário foi compilado, o campo central é a revisão de upstream e de empacotamento, e o quarto campo implícito é o conjunto de bibliotecas da suite em que foi compilado.

Numa instalação de 64 bits do Raspberry Pi OS a arquitetura do sistema é arm64, pelo que dpkg -i recusa um pacote armhf por incompatibilidade de arquitetura. Mesmo onde o multiarch permite a instalação, o binário espera versões de biblioteca da versão contra a qual foi compilado, e um sistema base mais recente pode já não as fornecer. O resultado é um pacote instalado cujo executável não arranca, e essa é a falha que as pessoas costumam interpretar mal como se o próprio cliente estivesse avariado.

O facto de a placa ser um dispositivo ARM não torna um pacote ARM apropriado. A arquitetura é um eixo; a versão e a ABI são os outros dois, e falham de forma independente.

Pergunte à distribuição antes de pedir uma ligação de descarga

Cada canal mantido pode dizer-lhe o que instalaria neste momento. Execute a consulta na máquina de destino, com os repositórios que ela realmente utiliza, antes de considerar qualquer transferência de ficheiros.

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

Uma linha de candidato com uma versão e um nome de repositório significa que a distribuição já tem uma compilação para este sistema. Não haver candidato, ou o candidato vir de uma suite que não tencionava usar, é informação sobre as suas fontes, não sobre se o software existe em algum lugar.

Se a atualização dos metadados falhar, mantenha essa falha separada da questão do pacote. A resolução de nomes, o transporte do repositório, uma assinatura Release em falta e uma suite no fim da vida útil quebram todos o apt update antes de o cliente estar envolvido. Corrigir as fontes é uma tarefa diferente de escolher um cliente VPN, e misturar as duas é como as pessoas acabam por apontar um sistema atual para uma versão obsoleta.

O que o apt verifica, e o que um ficheiro descarregado não recebe

Uma instalação normal segue uma cadeia de assinaturas: o arquivo assina o seu índice, o índice transporta hashes para cada pacote, e o pacote tem de corresponder. referência de autenticação do arquivo separa essa cadeia da ideia de verificar uma assinatura anexada a cada ficheiro individual.

Um ficheiro guardado a partir de uma ligação HTTP antiga não tem nada disso. Chega sem identidade de repositório, não é atualizado quando a distribuição corrige o cliente, e nada registra quem é responsável por o substituir. Isso ainda pode ser uma escolha legítima para um administrador com um artefacto fixado, mas a escolha tem de vir com um proprietário, uma soma de verificação registada em algum lugar e um plano para a próxima atualização de segurança.

Suprimir erros de assinatura ou desativar a verificação TLS para manter uma instrução antiga a funcionar remove a única parte do processo que verificava alguma coisa. Restaure antes a verificação que falha.

Instale o cliente e depois depure a ligação separadamente

Quando existir um candidato mantido, instale-o através da transação revista normal e deixe o gestor de pacotes registar o que fez.

Se a implementação precisar realmente de uma compilação de upstream, siga as instruções de compilação atuais do projeto e trate-a como software que agora mantém: os pacotes de desenvolvimento, pkg-config, os cabeçalhos da biblioteca TLS e o daemon PPP são dependências reais, e o mesmo se aplica ao procedimento de remoção de que vai precisar mais tarde.

A instalação é apenas a fase local do software. A gateway tem de aceitar o protocolo e o fluxo de autenticação do cliente, o cliente tem de confiar no certificado apresentado pela gateway, e o túnel precisa de uma camada PPP funcional mais rotas e um proprietário do resolvedor. Uma transação de pacote concluída não prova nada sobre se a gateway aceita a conta ou se o intervalo privado é alcançável. Teste cada camada onde ela quebra em vez de voltar a executar o instalador.

O plano que deveria substituir o nome de ficheiro antigo

Escreva primeiro a identidade da plataforma: versão do sistema, arquitetura e a lista de fontes em uso. Depois nomeie o local autorizado de onde vem o pacote, seja um repositório de distribuição, um repositório de fornecedor com uma chave fixada ou uma compilação que compila e empacota você mesmo.

Por fim, nomeie o mantenedor e o caminho de atualização. Um Pi que executa um cliente que ninguém possui continuará a funcionar até à primeira atualização de biblioteca, e então alguém com o mesmo problema voltará a encontrar o mesmo tópico do fórum.

A crença corrigida é suficientemente simples para ser dita numa linha: o pacote antigo é prova de que o cliente alguma vez foi compilado e funcionou, não prova de que será instalado na sua placa esta noite. Verifique os três eixos e depois escolha um canal que possa continuar a atualizar.