Ce vieux .deb openfortivpn convient-il à votre Raspberry Pi ?

Une réponse sur un forum vous donne un nom de fichier complet, et le nom ressemble à la solution : un .deb, une commande, terminé. Ce que cette chaîne code réellement, c'est une version de paquet, une architecture de processeur et la suite de la distribution contre laquelle il a été compilé le jour où quelqu'un a écrit le message. Aucun de ces trois éléments ne décrit automatiquement la carte posée sur votre bureau. L'ancien téléchargement est un instantané de la situation d'une machine, pas un plan d'installation pour la vôtre.

Ce que le nom de fichier fige sans le dire

Lisez un nom comme openfortivpn_1.17.0-1_armhf.deb de droite à gauche. Le suffixe est l'architecture pour laquelle le binaire a été compilé, le champ du milieu est la révision amont et d'empaquetage, et le quatrième champ implicite est l'ensemble de bibliothèques de la suite dans laquelle il a été construit.

Sur une installation 64 bits de Raspberry Pi OS, l'architecture du système est arm64, donc dpkg -i refuse un paquet armhf pour incompatibilité d'architecture. Même lorsque multiarch en permet l'installation, le binaire attend des versions de bibliothèques de la version contre laquelle il a été compilé, et un système de base plus récent peut ne plus les fournir. Le résultat est un paquet installé dont l'exécutable ne démarre pas, et c'est la panne que les gens interprètent souvent à tort comme le client lui-même cassé.

Ce n'est pas parce que la carte est un appareil ARM qu'un paquet ARM est approprié. L'architecture est un axe ; la version et l'ABI sont les deux autres, et ils échouent indépendamment.

Interrogez la distribution avant de demander un lien de téléchargement

Chaque canal maintenu peut vous dire ce qu'il installerait en ce moment. Exécutez la requête sur la machine cible, avec les dépôts qu'elle utilise réellement, avant d'envisager un quelconque transfert de fichier.

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

Une ligne de candidat avec une version et un nom de dépôt signifie que la distribution a déjà une compilation pour ce système. Pas de candidat, ou un candidat provenant d'une suite que vous ne comptiez pas utiliser, est une information sur vos sources, pas sur l'existence du logiciel quelque part.

Si le rafraîchissement des métadonnées échoue, gardez cet échec séparé de la question du paquet. La résolution de noms, le transport des dépôts, une signature Release manquante et une suite en fin de vie cassent tous apt update avant même que le client n'entre en jeu. Réparer les sources est une tâche différente du choix d'un client VPN, et mélanger les deux est la façon dont les gens finissent par pointer un système actuel vers une version obsolète.

Ce qu'apt vérifie, et ce qu'un fichier téléchargé n'obtient pas

Une installation normale suit une chaîne de signatures : l'archive signe son index, l'index porte les empreintes de chaque paquet, et le paquet doit correspondre. référence d'authentification de l'archive sépare cette chaîne de l'idée de vérifier une signature attachée à chaque fichier individuel.

Un fichier enregistré depuis un ancien lien HTTP n'en a rien. Il arrive sans identité de dépôt, il n'est pas mis à jour quand la distribution corrige le client, et rien n'enregistre qui est responsable de son remplacement. Cela peut encore être un choix légitime pour un administrateur disposant d'un artefact figé, mais le choix doit venir avec un propriétaire, une somme de contrôle consignée quelque part et un plan pour la prochaine mise à jour de sécurité.

Supprimer les erreurs de signature ou désactiver la vérification TLS pour qu'une ancienne instruction continue de fonctionner retire la seule partie du processus qui vérifiait quoi que ce soit. Restaurez plutôt la vérification qui échoue.

Installez le client, puis déboguez la connexion séparément

Lorsqu'un candidat maintenu existe, installez-le par la transaction révisée habituelle et laissez le gestionnaire de paquets consigner ce qu'il a fait.

Si le déploiement a réellement besoin d'une compilation amont, suivez les instructions de compilation actuelles du projet et traitez-la comme un logiciel que vous maintenez désormais : les paquets de développement, pkg-config, les en-têtes de la bibliothèque TLS et le démon PPP sont de vraies dépendances, tout comme la procédure de suppression dont vous aurez besoin plus tard.

L'installation n'est que l'étape logicielle locale. La passerelle doit accepter le protocole et le flux d'authentification du client, le client doit faire confiance au certificat présenté par la passerelle, et le tunnel a besoin d'une couche PPP fonctionnelle ainsi que de routes et d'un propriétaire de résolveur. Une transaction de paquet terminée ne prouve rien quant à savoir si la passerelle accepte le compte ou si la plage privée est joignable. Testez chaque couche là où elle casse au lieu de relancer l'installateur.

Le plan qui devrait remplacer l'ancien nom de fichier

Écrivez d'abord l'identité de la plateforme : version du système, architecture et liste des sources utilisées. Nommez ensuite l'endroit autorisé d'où vient le paquet, qu'il s'agisse d'un dépôt de distribution, d'un dépôt de fournisseur avec une clé figée ou d'une compilation que vous compilez et empaquetez vous-même.

Enfin, nommez le mainteneur et le chemin de mise à jour. Un Pi qui exécute un client que personne ne possède continuera de fonctionner jusqu'à la première mise à jour de bibliothèque, puis quelqu'un ayant le même problème retrouvera le même fil de forum.

La croyance corrigée est assez simple pour être énoncée en une ligne : l'ancien paquet prouve que le client a été compilé et a fonctionné un jour, pas qu'il s'installera sur votre carte ce soir. Vérifiez les trois axes, puis choisissez un canal que vous pouvez continuer à mettre à jour.