Pourquoi un nouveau raccourci VPN ne restaure pas les réglages perdus
Un lanceur décide comment un programme démarre, pas où il conserve ses préférences. Comparez le contexte de l’exécutable, de l’utilisateur et de la configuration avant d’accuser l’icône.
Entrées de menu manquantes et préférences qui disparaissent se réparent avec le même réflexe, et ce sont des problèmes sans rapport. L’un relève de l’intégration au bureau, l’autre de l’état de l’application, et une nouvelle icône ne change ni l’un ni l’autre à elle seule. Séparer les deux coûte une expérience et explique l’essentiel de la confusion que les gens apportent à ce sujet. Le lanceur démarre un programme ; le programme décide de ce qu’il retient.
Deux tâches qui ne ressemblent qu’à une
L’intégration au bureau signifie que l’environnement peut trouver un exécutable, présenter un nom et une icône et transmettre les bons arguments. L’état de l’application signifie que le programme écrit un profil dans un endroit durable et le relit au démarrage suivant. Ni l’un ni l’autre n’implique l’autre, et c’est pourquoi un raccourci qui fonctionne peut lancer un client qui a tout oublié.
Modifiez une préférence d’affichage anodine depuis les propres contrôles de l’application, puis fermez-la et rouvrez-la de la même manière. Si la préférence revient, la persistance fonctionne et la plainte restante concerne la recherche de la fenêtre plutôt l’enregistrement des données. Si elle disparaît, le raccourci est une distraction et la vraie question est où ce processus garde ses fichiers. Testez une préférence à la fois, car un client qui redemande un mot de passe protège peut-être un secret plutôt que de perdre une configuration.
Comparez les entrées de lancement avant de réinstaller
Partez de l’entrée de bureau et lisez ce qu’elle fait réellement, car un lancement depuis le menu n’est pas automatiquement le même environnement de processus qu’un lancement depuis le terminal. Les clés qui comptent sont Exec, Path et, indirectement, l’environnement fourni par la session. Un script enveloppe dans Exec peut définir une variable, changer de répertoire ou invoquer un assistant privilégié que le menu ne montre jamais. Réinstaller remplace des fichiers que l’application possédait déjà, et c’est rarement la variable qui a changé.
grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop
Regardez le fichier sous ~/.local/share/applications avant celui de /usr/share/applications, car une copie utilisateur masque la copie système. Lancez desktop-file-validate lorsque l’entrée se comporte mal et cherchez une copie obsolète qui pointe encore vers un chemin supprimé. Une copie utilisateur invalide reste préférée par la plupart des bureaux, si bien qu’un fichier cassé peut retirer l’entrée du menu alors que le fichier du paquet reste valide. Exécutez ensuite la même commande à la main et comparez ce que produisent les deux lancements.
Où vit réellement une préférence
Les applications qui suivent les règles de répertoires de base XDG placent la configuration sous $XDG_CONFIG_HOME, l’état durable sous $XDG_STATE_HOME et les données jetables sous $XDG_CACHE_HOME, en utilisant par défaut ~/.config, ~/.local/state et ~/.cache lorsque ces variables ne sont pas définies. Les trois sont des rôles et non des promesses, aussi un produit VPN particulier peut documenter tout autre chose. Lire la documentation du fournisseur lui-même vaut mieux que deviner un chemin à partir d’un nom de répertoire. Quand la documentation est mince, observez le processus plutôt que le système de fichiers.
Une trace filtrée sur les ouvertures de fichiers montre chaque chemin de configuration que le client tente, y compris celui qu’il écrit en quittant. Lancez-la avec le même utilisateur et le même environnement, puis comparez ces chemins aux répertoires que vous attendiez.
strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client
Les secrets et les profils ont des propriétaires différents
Un profil enregistré et un identifiant enregistré sont des objets distincts, souvent avec un stockage distinct. L’un peut vivre dans un fichier de configuration tandis que l’autre siège dans un trousseau qui se déverrouille par session, si bien qu’un client qui redemande un mot de passe fait peut-être simplement ce pour quoi il a été conçu. Supprimer le profil pour arrêter l’invite est la façon dont les gens perdent une configuration qui fonctionnait.
Les lancements privilégiés compliquent encore cela, car un lancement via sudo ou un assistant PolicyKit peut présenter un autre répertoire personnel et donc un autre jeu de configuration. Corrigez la propriété sur le fichier précis que l’application documente plutôt que récursivement sur tout le répertoire personnel, puis décidez quelle identité doit posséder le profil désormais et gardez les lancements futurs cohérents avec elle.
Ce que l’icône peut vous dire et ce qu’elle ne peut pas
Une icône prouve qu’un fichier de lanceur se résout, et rien de plus. L’état de la connexion appartient au client, donc la seule vérification fiable est l’interface, la route ou la sortie d’état du client lui-même. Une applet de barre qui n’a pas démarré peut faire paraître cassé un tunnel qui fonctionne, tandis qu’une applet obsolète peut faire paraître correct un tunnel cassé. Testez la connexion et le lanceur séparément, puis notez lequel des deux vous avez réellement réparé.
Si les deux étaient cassés, résistez à traiter la réparation comme un seul changement. Réparez l’entrée, confirmez le lancement, puis confirmez le tunnel, et notez le résultat de chaque étape. Ce relevé est ce qui rend le prochain rapport de réglages perdus diagnosticable au lieu d’une répétition de celui-ci, et c’est aussi ce qui dit à la personne suivante quelle moitié du problème était réelle.