De ce o comandă rapidă VPN nouă nu readuce setările pierdute

Intrări de meniu lipsă și preferințe care dispar se repară cu același reflex, iar acestea sunt probleme fără legătură. Una este integrarea cu desktopul, cealaltă este starea aplicației, iar o pictogramă nouă nu le schimbă pe niciuna de la sine. Separarea lor costă un experiment și explică cea mai mare parte a confuziei pe care oamenii o aduc în acest subiect. Lansatorul pornește un program; programul decide ce reține.

Două sarcini care doar par una

Integrarea cu desktopul înseamnă că mediul poate găsi un executabil, poate prezenta un nume și o pictogramă și poate transmite argumentele corecte. Starea aplicației înseamnă că programul scrie un profil într-un loc durabil și îl recitește la următoarea pornire. Niciuna nu o implică pe cealaltă, de aceea o comandă rapidă funcțională poate lansa un client care a uitat totul.

Schimbați o preferință de afișare inofensivă prin controalele proprii ale aplicației, apoi închideți-o și redeschideți-o în același mod. Dacă preferința revine, persistența funcționează, iar reclamația rămasă este despre găsirea ferestrei și nu despre salvarea datelor. Dacă dispare, comanda rapidă este o distragere, iar întrebarea reală este unde ține acel proces fișierele sale. Testați o singură preferință o dată, pentru că un client care cere din nou parola poate proteja un secret în loc să piardă o configurație.

Comparați intrările de lansare înainte de reinstalare

Începeți cu intrarea din desktop și citiți ce face de fapt, pentru că o lansare din meniu nu este automat același mediu de proces ca o lansare din terminal. Cheile care contează sunt Exec, Path și, indirect, mediul oferit de sesiune. Un script wrapper în Exec poate seta o variabilă, schimba directorul sau invoca un ajutor privilegiat pe care meniul nu îl arată niciodată. Reinstalarea înlocuiește fișiere pe care aplicația le avea deja, iar aceea este rareori variabila care s-a schimbat.

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

Uitați-vă la fișierul din ~/.local/share/applications înaintea celui din /usr/share/applications, pentru că o copie de utilizator umbrește copia de sistem. Rulați desktop-file-validate când intrarea se comportă prost și căutați o copie învechită care indică încă o cale eliminată. Majoritatea desktopurilor preferă în continuare o copie de utilizator invalidă, așa că un fișier stricat poate scoate intrarea din meniu în timp ce fișierul pachetului rămâne valid. Apoi rulați aceeași comandă manual și comparați ce produc cele două lansări.

Unde trăiește de fapt o preferință

Aplicațiile care urmează regulile directoarelor de bază XDG pun configurația sub $XDG_CONFIG_HOME, starea durabilă sub $XDG_STATE_HOME și datele de unică folosință sub $XDG_CACHE_HOME și folosesc implicit ~/.config, ~/.local/state și ~/.cache atunci când acele variabile nu sunt setate. Cele trei sunt roluri, nu promisiuni, așa că un anumit produs VPN poate documenta cu totul altceva. Citirea documentației furnizorului însuși este mai bună decât ghicirea unei căi după numele unui director. Când documentația este subțire, observați procesul în locul sistemului de fișiere.

O urmărire filtrată pe deschideri de fișiere arată fiecare cale de configurație pe care o încearcă clientul, inclusiv pe cea pe care o scrie la ieșire. Rulați-o ca același utilizator și în același mediu, apoi comparați acele căi cu directoarele la care vă așteptați.

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

Secretele și profilurile au proprietari diferiți

Un profil salvat și o acreditare salvată sunt obiecte separate, adesea cu stocare separată. Unul poate locui într-un fișier de configurație în timp ce celălalt stă într-un portchei care se deblochează pe sesiune, așa că un client care cere din nou parola poate pur și simplu să facă ceea ce a fost proiectat să facă. Ștergerea profilului pentru a opri solicitarea este modul în care oamenii pierd o configurație funcțională.

Lansările privilegiate complică acest lucru și mai mult, pentru că o lansare prin sudo sau printr-un ajutor PolicyKit poate prezenta un alt director home și, prin urmare, un alt set de configurație. Corectați proprietatea pe fișierul specific pe care aplicația îl documentează, nu recursiv pe tot directorul home, apoi decideți ce identitate ar trebui să dețină profilul de acum înainte și păstrați lansările viitoare consecvente cu ea.

Ce poate și ce nu poate să vă spună pictograma

O pictogramă dovedește că un fișier de lansator se rezolvă, și nimic mai mult. Starea conexiunii aparține clientului, așa că singura verificare fiabilă este interfața, ruta sau propria ieșire de stare a clientului. O aplicație din tavă care nu a pornit poate face un tunel funcțional să pară stricat, în timp ce una învechită poate face un tunel stricat să pară în regulă. Testați conexiunea și lansatorul separat, apoi notați pe care dintre ele l-ați reparat de fapt.

Dacă ambele erau stricate, rezistați tentației de a trata reparația ca o singură schimbare. Reparați intrarea, confirmați lansarea, apoi confirmați tunelul și notați rezultatul fiecărui pas. Acea înregistrare este ceea ce face următorul raport despre setări pierdute diagnosticabil în loc de o repetare a acestuia, și tot ea îi spune persoanei următoare care jumătate a problemei era reală.