Il vecchio .deb di openfortivpn va bene per il vostro Raspberry Pi?

Una risposta su un forum vi consegna un nome di file completo, e il nome sembra la soluzione: un .deb, un comando, fatto. Quello che quella stringa codifica davvero è una versione del pacchetto, un'architettura della CPU e la suite della distribuzione contro cui è stato compilato il giorno in cui qualcuno ha scritto il messaggio. Nessuno di questi tre descrive automaticamente la scheda sulla vostra scrivania. Il vecchio download è un'istantanea della situazione di una macchina, non un piano di installazione per la vostra.

Cosa fissa in silenzio il nome del file

Leggete un nome come openfortivpn_1.17.0-1_armhf.deb da destra a sinistra. Il suffisso è l'architettura per cui è stato compilato il binario, il campo centrale è la revisione upstream e di pacchettizzazione, e il quarto campo implicito è l'insieme di librerie della suite in cui è stato compilato.

Su un'installazione a 64 bit di Raspberry Pi OS l'architettura del sistema è arm64, quindi dpkg -i rifiuta un pacchetto armhf per un disallineamento di architettura. Anche dove multiarch ne consente l'installazione, il binario si aspetta versioni delle librerie della versione contro cui è stato compilato, e un sistema di base più recente potrebbe non fornirle più. Il risultato è un pacchetto installato il cui eseguibile non si avvia, e questo è il guasto che la gente di solito interpreta male come se il client stesso fosse rotto.

Il fatto che la scheda sia un dispositivo ARM non rende appropriato un pacchetto ARM. L'architettura è un asse; la versione e l'ABI sono gli altri due, e falliscono indipendentemente.

Chiedete alla distribuzione prima di chiedere un link di download

Ogni canale mantenuto può dirvi cosa installerebbe in questo momento. Eseguite la query sulla macchina di destinazione, con i repository che usa davvero, prima di considerare qualsiasi trasferimento di file.

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

Una riga candidata con una versione e un nome di repository significa che la distribuzione ha già una build per questo sistema. L'assenza di candidati, o un candidato da una suite che non intendevate usare, è un'informazione sulle vostre fonti, non sull'esistenza del software da qualche parte.

Se l'aggiornamento dei metadati fallisce, tenete quel fallimento separato dalla questione del pacchetto. Risoluzione dei nomi, trasporto dei repository, una firma Release mancante e una suite a fine vita rompono tutti apt update prima che il client entri in gioco. Riparare le fonti è un compito diverso dallo scegliere un client VPN, e mescolare le due cose è il modo in cui la gente finisce per puntare un sistema attuale a una versione obsoleta.

Cosa verifica apt e cosa non ottiene un file scaricato

Un'installazione normale segue una catena di firme: l'archivio firma il proprio indice, l'indice porta gli hash di ogni pacchetto, e il pacchetto deve corrispondere. riferimento di autenticazione dell'archivio separa quella catena dall'idea di controllare una firma allegata a ogni singolo file.

Un file salvato da un vecchio link HTTP non ha nulla di tutto ciò. Arriva senza identità di repository, non viene aggiornato quando la distribuzione corregge il client, e nulla registra chi sia responsabile di sostituirlo. Può ancora essere una scelta legittima per un amministratore con un artefatto fissato, ma la scelta deve venire con un proprietario, un checksum registrato da qualche parte e un piano per il prossimo aggiornamento di sicurezza.

Sopprimere gli errori di firma o disattivare la verifica TLS per far continuare a funzionare una vecchia istruzione rimuove l'unica parte del processo che controllava qualcosa. Ripristinate invece il controllo che fallisce.

Installate il client, poi risolvete la connessione separatamente

Quando esiste un candidato mantenuto, installatelo tramite la normale transazione rivista e lasciate che il gestore dei pacchetti registri cosa ha fatto.

Se il deployment ha davvero bisogno di una build da upstream, seguite le istruzioni di build attuali del progetto e trattatela come software che ora mantenete voi: pacchetti di sviluppo, pkg-config, le intestazioni della libreria TLS e il demone PPP sono dipendenze reali, e lo è anche la procedura di rimozione che vi servirà più avanti.

L'installazione è solo la fase software locale. Il gateway deve accettare il protocollo e il flusso di autenticazione del client, il client deve fidarsi del certificato presentato dal gateway, e il tunnel ha bisogno di uno strato PPP funzionante più rotte e un proprietario del resolver. Una transazione di pacchetto completata non dimostra nulla su se il gateway accetti l'account o se la rete privata sia raggiungibile. Testate ogni strato dove si rompe invece di rieseguire l'installer.

Il piano che dovrebbe sostituire il vecchio nome del file

Scrivete prima l'identità della piattaforma: versione del sistema, architettura e l'elenco delle fonti in uso. Poi nominate il luogo autorizzato da cui proviene il pacchetto, che sia un repository di distribuzione, un repository del fornitore con una chiave fissata o una build che compilate e impacchettate voi stessi.

Infine, nominate il manutentore e il percorso di aggiornamento. Un Pi che esegue un client che nessuno possiede continuerà a funzionare fino al primo aggiornamento di libreria, e poi qualcuno con lo stesso problema troverà di nuovo lo stesso thread del forum.

La convinzione corretta è abbastanza semplice da esprimere in una riga: il vecchio pacchetto è prova che il client una volta è stato compilato e ha funzionato, non prova che si installerà sulla vostra scheda stasera. Controllate i tre assi, poi scegliete un canale che potete continuare ad aggiornare.