Per què una drecera VPN nova no recupera la configuració perduda

Entrades de menú que falten i preferències que desapareixen es reparen amb el mateix reflex, i són problemes sense relació. Un és la integració d’escriptori, l’altre és l’estat de l’aplicació, i una icona nova no canvia cap dels dos per si sola. Separar-los costa un experiment i explica la major part de la confusió que la gent porta a aquest tema. El llançador inicia un programa; el programa decideix què recorda.

Dues feines que només semblen una

La integració d’escriptori vol dir que l’entorn pot trobar un executable, presentar un nom i una icona i passar els arguments correctes. L’estat de l’aplicació vol dir que el programa escriu un perfil en un lloc durador i el torna a llegir al següent inici. Cap dels dos implica l’altre, i per això una drecera que funciona pot iniciar un client que ho ha oblidat tot.

Canvieu una preferència de visualització innòcua amb els controls propis de l’aplicació, i després tanqueu-la i torneu-la a obrir de la mateixa manera. Si la preferència torna, la persistència funciona i la resta de la queixa tracta de trobar la finestra, no de desar dades. Si desapareix, la drecera és una distracció i la pregunta real és on guarda els fitxers aquest procés. Proveu una preferència alhora, perquè un client que torna a demanar la contrasenya pot estar protegint un secret en lloc de perdre una configuració.

Compareu les entrades d’inici abans de reinstal·lar

Comenceu per l’entrada d’escriptori i llegiu què fa realment, perquè un inici des del menú no és automàticament el mateix entorn de procés que un inici des del terminal. Les claus que importen són Exec, Path i, indirectament, l’entorn que proporciona la sessió. Un script embolcall a Exec pot definir una variable, canviar de directori o invocar un auxiliar privilegiat que el menú no mostra mai. Reinstal·lar substitueix fitxers que l’aplicació ja tenia, i aquesta poques vegades és la variable que va canviar.

grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop

Mireu el fitxer de ~/.local/share/applications abans que el de /usr/share/applications, perquè una còpia d’usuari fa ombra a la còpia del sistema. Executeu desktop-file-validate quan l’entrada es comporta malament i busqueu una còpia obsoleta que encara apunta a una ruta eliminada. La majoria d’escriptoris encara prefereixen una còpia d’usuari no vàlida, així que un fitxer trencat pot treure l’entrada del menú mentre el fitxer del paquet continua essent vàlid. Després executeu la mateixa ordre a mà i compareu què produeixen els dos inicis.

On viu realment una preferència

Les aplicacions que segueixen les regles de directoris base XDG posen la configuració a $XDG_CONFIG_HOME, l’estat durador a $XDG_STATE_HOME i les dades d’un sol ús a $XDG_CACHE_HOME, amb ~/.config, ~/.local/state i ~/.cache per defecte quan aquestes variables no estan definides. Els tres són papers i no promeses, així que un producte VPN concret pot documentar una cosa completament diferent. Llegir la documentació del mateix proveïdor és millor que endevinar una ruta a partir d’un nom de directori. Quan la documentació és escassa, observeu el procés en lloc del sistema de fitxers.

Un rastre filtrat per obertures de fitxers mostra cada ruta de configuració que prova el client, inclosa la que escriu en sortir. Executeu-lo com el mateix usuari i amb el mateix entorn, i després compareu aquestes rutes amb els directoris que esperàveu.

strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client

Els secrets i els perfils tenen propietaris diferents

Un perfil desat i una credencial desada són objectes separats, sovint amb emmagatzematge separat. Un pot viure en un fitxer de configuració mentre l’altre se’n va a un anell de claus que s’obre per sessió, així que un client que torna a demanar la contrasenya potser simplement fa el que va ser dissenyat per fer. Esborrar el perfil per aturar la sol·licitud és com la gent perd una configuració que funcionava.

Els inicis privilegiats ho compliquen encara més, perquè un inici mitjançant sudo o un auxiliar PolicyKit pot presentar un directori personal diferent i, per tant, un conjunt de configuració diferent. Corregiu la propietat del fitxer concret que documenta l’aplicació en lloc de fer-ho recursivament per tot el directori personal, i després decidiu quina identitat ha de posseir el perfil d’ara endavant i manteniu els inicis futurs coherents amb ella.

Què us pot dir la icona i què no

Una icona demostra que un fitxer de llançador es resol, i res més. L’estat de la connexió pertany al client, així que l’única comprovació fiable és la interfície, la ruta o la mateixa sortida d’estat del client. Una miniaplicació de la safata que no s’ha iniciat pot fer que un túnel que funciona sembli trencat, mentre que una miniaplicació obsoleta pot fer que un de trencat sembli bé. Proveu la connexió i el llançador per separat i després anoteu quin dels dos heu arreglat realment.

Si tots dos estaven trencats, resistiu la temptació de tractar la reparació com un sol canvi. Arregleu l’entrada, confirmeu l’inici, confirmeu després el túnel i anoteu el resultat de cada pas. Aquest registre és el que fa que el proper informe de configuració perduda sigui diagnosticable en lloc d’una repetició d’aquest, i també és el que diu a la propera persona quina meitat del problema era real.