Vous double-cliquez sur le fichier téléchargé la semaine dernière, la connexion fonctionne, et l'habitude s'installe : à chaque fois que le VPN tombe, vous relancez ce même fichier. Rien ne casse tout de suite, et c'est pourquoi le schéma perdure. Ce que vous faites en réalité, c'est réinstaller l'application par-dessus elle-même, puis la rouvrir depuis la fin de l'installateur.

Une fois l'installateur terminé, le programme vit ailleurs sur le disque et possède sa propre icône, ses propres réglages et son propre service en arrière-plan. Le téléchargement était le mécanisme de livraison, et le conserver ne pose aucun problème, mais ce n'est pas ce avec quoi vous vous connectez.

Ce que le téléchargement a réellement déposé sur le disque

Un fichier .run est une convention de nommage, pas un type de fichier. Il peut être un script shell, une archive auto-extractible, un binaire compilé ou quelque chose qui décide à l'exécution lequel de ces éléments il est. Le suffixe ne vous dit rien sur qui l'a publié ni si vous devriez lui faire confiance, et c'est pourquoi les instructions d'installation commencent par l'obtenir depuis un canal vérifié plutôt que par une commande.

Pour un fournisseur qui distribue de cette façon, l'installateur décompresse sa charge utile, écrit l'application et ses fichiers de support, et enregistre dans l'environnement de bureau ce dont il a besoin. Quand il a terminé, les artefacts intéressants sont le binaire de l'application, une entrée de bureau et souvent un service que l'application démarre. Aucun d'eux n'est le fichier que vous avez téléchargé. Regardez dans le répertoire que l'installateur nomme dans sa sortie finale et vous verrez la différence immédiatement.

L'habitude de le relancer masque aussi un diagnostic. Si l'application s'ouvre après une réinstallation complète mais pas depuis le menu, vous n'apprenez rien sur la pièce qui manquait, car l'installateur les a toutes reconstruites.

Installez une fois, avec l'invocation du fournisseur lui-même

Suivez l'invocation documentée à la lettre, y compris l'interpréteur qu'elle nomme. Pour le client Linux de PIA, le guide appelle l'installateur via sh, donc la forme de la commande est l'interpréteur suivi du fichier que vous avez réellement téléchargé.

sh ./pia-linux-VERSION.run

VERSION est un espace réservé pour la version que vous avez récupérée, pas une recommandation de chercher un numéro précis. Traitez cette commande comme une exécution de code aux conséquences au niveau du système, car c'est ce qu'elle est : ce n'est pas un moyen d'inspecter le fichier, et l'exécuter deux fois ne vous apprend rien que la première n'ait déjà appris.

Un détail du même guide est facile à sauter et mérite d'être répété : ne faites pas précéder l'installateur de sudo. Il demande lui-même l'autorisation administrative dont il a besoin, et l'envelopper dans un shell root change l'environnement utilisateur dans lequel l'installation atterrit. Pour la même raison, « rendre chaque téléchargement exécutable et le lancer » n'est pas une règle générale ; demander à un interpréteur de lire un script et exécuter un fichier directement sont deux opérations différentes avec des modes de défaillance différents.

Quand l'installateur est terminé, le fournisseur documente la connexion et la connexion via l'application qui vient d'être installée. Toute connexion ultérieure se fait là. Si vous tapez encore le chemin de l'installateur pour être en ligne, vous avez fait de l'installateur une partie de votre flux de travail par accident.

Lanceur, boutique et zone de notification sont trois endroits différents

Le menu des applications, le catalogue d'une boutique de logiciels et la zone de notification sont des interfaces distinctes maintenues par des composants différents, et un installateur peut en remplir une sans toucher aux autres. Un installateur autonome écrit généralement une entrée de bureau, ce qui n'est que l'intégration au lanceur et rien de plus. Il ne transforme pas l'application en installation gérée par la boutique et ne garantit pas d'icône dans la zone de notification.

Un indicateur de zone de notification a besoin du soutien des deux côtés : l'application en cours d'exécution doit en exporter un, et le bureau doit lui fournir un hôte. Sur les bureaux qui ont supprimé la zone de notification traditionnelle, une application qui en attend une peut fonctionner parfaitement et n'afficher rien, et c'est une lacune d'intégration, pas une installation ratée. Indiquer la version du bureau et la version de l'application est ce qui rend cette lacune exploitable.

Donc quand l'application s'ouvre mais que l'icône manque, ne réinstallez pas. Vérifiez si un processus tourne, si la fenêtre est masquée derrière un démarrage en arrière-plan, et si le bureau prend en charge ce genre d'indicateurs. Un indicateur absent sur un bureau sans hôte de zone de notification est un comportement attendu, pas un défaut. Réinstaller le même téléchargement une cinquième fois ne rafraîchit que ce qui fonctionnait déjà.

Notez le propriétaire de l'installation

Notez quel canal a installé l'application, quel composant la met à jour et ce qui la supprime. Ces trois réponses ne sont généralement pas le même programme, et une machine où personne ne les connaît est une machine où deux copies d'un client VPN finissent par se disputer les mêmes routes.

Supprimer l'installateur téléchargé ne désinstalle rien, et fermer la fenêtre n'arrête pas forcément le service ni la politique de blocage qu'il a installés. Avant de nettoyer, découvrez ce qui s'exécute à la connexion et ce qui survit à un redémarrage.

Une fois que l'installateur a fait son travail, rangez-le dans un dossier dont vous vous souviendrez et cessez de le traiter comme l'application. La prochaine fois que le tunnel se comportera mal, partez de l'application installée, et laissez le téléchargement n'être qu'un artefact du jour où vous l'avez installé. Le guide d'installation de PIA pour Linux est la référence pour l'invocation et les premières étapes de lancement décrites ci-dessus.

Articles similaires