És adequat aquest vell .deb d'openfortivpn per al vostre Raspberry Pi?

Una resposta al fòrum us dona un nom de fitxer complet, i el nom sembla la solució: un .deb, una ordre, fet. El que aquesta cadena codifica realment és una versió de paquet, una arquitectura de CPU i el conjunt de la distribució contra el qual es va compilar el dia que algú va escriure el missatge. Cap d'aquests tres no descriu automàticament la placa que teniu damunt la taula. La descàrrega antiga és una instantània de la situació d'una màquina, no un pla d'instal·lació per a la vostra.

Què fixa silenciosament el nom del fitxer

Llegiu un nom com openfortivpn_1.17.0-1_armhf.deb de dreta a esquerra. El sufix és l'arquitectura per a la qual es va compilar el binari, el camp central és la revisió d'upstream i d'empaquetatge, i el quart camp implícit és el conjunt de biblioteques de la distribució on es va compilar.

En una instal·lació de 64 bits de Raspberry Pi OS l'arquitectura del sistema és arm64, així que dpkg -i rebutja un paquet armhf per una discrepància d'arquitectura. Fins i tot quan multiarch en permet la instal·lació, el binari espera versions de biblioteques de la versió contra la qual es va compilar, i un sistema base més nou potser ja no les proporciona. El resultat és un paquet instal·lat el fitxer executable del qual no s'inicia, i aquesta és la fallada que la gent sol interpretar malament com si el client mateix estigués trencat.

Que la placa sigui un dispositiu ARM no fa adequat un paquet ARM. L'arquitectura és un eix; la versió i l'ABI són els altres dos, i fallen de manera independent.

Pregunteu a la distribució abans de demanar un enllaç de descàrrega

Cada canal mantingut us pot dir què instal·laria ara mateix. Executeu la consulta a la màquina objectiu, amb els repositoris que realment utilitza, abans de considerar cap transferència de fitxers.

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

Una línia de candidat amb una versió i un nom de repositori vol dir que la distribució ja té una compilació per a aquest sistema. Que no hi hagi candidat, o que el candidat vingui d'una distribució que no teníeu previst utilitzar, és informació sobre les vostres fonts, no sobre si el programari existeix en algun lloc.

Si falla l'actualització de metadades, manteniu aquesta fallada separada de la qüestió del paquet. La resolució de noms, el transport del repositori, una signatura Release absent i una distribució al final de la seva vida útil trenquen apt update abans que el client hi intervingui. Arreglar les fonts és una tasca diferent de triar un client VPN, i barrejar les dues és com la gent acaba apuntant un sistema actual a una versió obsoleta.

Què verifica apt i què no obté un fitxer descarregat

Una instal·lació normal segueix una cadena de signatures: l'arxiu signa el seu índex, l'índex porta els hashes de cada paquet, i el paquet ha de coincidir. referència d'autenticació de l'arxiu separa aquesta cadena de la idea de comprovar una signatura adjunta a cada fitxer individual.

Un fitxer desat des d'un enllaç HTTP antic no en té res. Arriba sense identitat de repositori, no s'actualitza quan la distribució pedaça el client, i res no registra qui és responsable de substituir-lo. Encara pot ser una opció legítima per a un administrador amb un artefacte fixat, però l'opció ha de venir amb un propietari, una suma de verificació enregistrada en algun lloc i un pla per a la propera actualització de seguretat.

Suprimir errors de signatura o desactivar la verificació TLS perquè una instrucció antiga continuï funcionant elimina l'única part del procés que comprovava alguna cosa. Restaureu més aviat la comprovació que falla.

Instal·leu el client, després depureu la connexió per separat

Quan existeixi un candidat mantingut, instal·leu-lo mitjançant la transacció revisada normal i deixeu que el gestor de paquets registri què ha fet.

Si el desplegament necessita realment una compilació d'upstream, seguiu les instruccions de compilació actuals del projecte i tracteu-la com a programari que ara manteniu: els paquets de desenvolupament, pkg-config, les capçaleres de la biblioteca TLS i el dimoni PPP són dependències reals, i també ho és el procediment de desinstal·lació que voldreu més endavant.

La instal·lació és només l'etapa local del programari. La passarel·la ha d'acceptar el protocol i el flux d'autenticació del client, el client ha de confiar en el certificat que presenta la passarel·la, i el túnel necessita una capa PPP funcional més rutes i un propietari del resolutor. Una transacció de paquet completada no demostra res sobre si la passarel·la accepta el compte o si el rang privat és abastable. Proveu cada capa on es trenca en lloc de tornar a executar l'instal·lador.

El pla que hauria de substituir el nom de fitxer antic

Primer escriviu la identitat de la plataforma: versió del sistema, arquitectura i la llista de fonts en ús. Després nomeu el lloc autoritzat d'on ve el paquet, ja sigui un repositori de distribució, un repositori de proveïdor amb una clau fixada o una compilació que compileu i empaqueteu vosaltres mateixos.

Finalment, nomeu el mantenidor i el camí d'actualització. Un Pi que executa un client que ningú posseeix continuarà funcionant fins a la primera actualització de biblioteca, i llavors algú amb el mateix problema trobarà de nou el mateix fil del fòrum.

La creença corregida és prou simple per dir-la en una línia: el paquet antic és evidència que el client es va compilar i es va executar algun cop, no evidència que s'instal·larà a la vostra placa aquesta nit. Comproveu els tres eixos i després trieu un canal que pugueu seguir actualitzant.