Pachet de depozit sau pachet de client VPN: care vine primul?

Instalați pachetul furnizorului, comanda returnează zero și tot nu există nicio aplicație VPN de pornit. Se întâmplă când pachetul instalat a configurat un depozit în loc să livreze clientul, iar diferența se vede în ce a lăsat pe disc. Dacă aveți nevoie de amândouă și în ce ordine depinde de trei condiții, nu de denumirea furnizorului. Decizia de mai jos păstrează configurarea sursei, reîmprospătarea metadatelor și instalarea aplicației ca acțiuni separate, cu dovezi separate.

Ce schimbă de fapt fiecare pachet

Un pachet de configurare a depozitului scrie o intrare de sursă APT, importă cheia de semnare în care acea intrare are încredere și se oprește. Conținutul său sunt câteva fișiere sub /etc/apt plus un inel de chei și nimic de executat. Un pachet de client livrează demonul sau aplicația de birou, bibliotecile și dependențele ei, iar acesta este obiectul care ajunge într-un meniu sau într-o unitate systemd.

Numele de fișiere care se termină cu -release sugerează primul tip, dar sufixul este o convenție, nu o garanție. Afirmația de încredere despre rolul unui pachet este lista de fișiere și dependențele sale, ambele citibile înainte de a instala ceva. Un furnizor care își remodelează ambalarea păstrează același nume de fișier și schimbă conținutul, așa că un răspuns copiat dintr-un fir vechi de doi ani poate descrie un pachet care nu mai există. Citiți instrucțiunile actuale ale furnizorului pentru versiunea pe care o rulați, apoi verificați ce declară pachetul.

Trei etape decurg din această separare: înregistrați sursa, reîmprospătați metadatele pe care le alimentează, apoi instalați aplicația după nume. Ghidul de instalare pentru Debian și Ubuntu le ține separate, de aceea clientul este cerut într-un pas ulterior și nu de pachetul care a configurat sursa.

Trei condiții care decid ordinea

Prima condiție este dacă furnizorul publică un depozit pentru versiunea exactă a distribuției dumneavoastră. O linie de sursă construită pentru o suită se poate rezolva împotriva dependențelor altei suite și poate instala un amestec pe care nimeni nu l-a testat.

A doua este dacă distribuția dumneavoastră are deja clientul. Când îl are, pachetul distribuției urmează tranzițiile de biblioteci și actualizările de securitate ale versiunii dumneavoastră, în timp ce pachetul furnizorului poate merge mai repede și poate aduce propriile copii ale bibliotecilor partajate.

A treia este de ce funcții aveți nevoie cu adevărat. O compilare a furnizorului poate livra o implementare de protocol mai nouă sau o integrare cu biroul pe care distribuția dumneavoastră nu a împachetat-o, iar acesta este un motiv real pentru a accepta o a doua sursă. Dacă compilarea distribuției acoperă utilizarea dumneavoastră, adăugarea unui depozit terț cumpără muncă de actualizare și încă o relație de încredere pentru foarte puțin.

Rezolvați aceste trei răspunsuri înainte de a exista linia de sursă, pentru că eliminarea ei mai târziu înseamnă curățarea pachetului și a cheii sale. Odată stabilite, secvența din calea furnizorului nu este o alegere: sursa prima, metadatele a doua, aplicația a treia, niciodată invers.

Verificați ce a lăsat pachetul de lansare

Înainte de a instala orice altceva, citiți lista de fișiere, nu descrierea. Pe sistemele din familia Debian manifestul pachetului răspunde ce a configurat și unde a ajuns cheia.

dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/

Prima linie arată fișierul sursă și calea inelului de chei, iar a doua raportează ce versiune pot oferi sursele configurate. Dacă apt-cache policy nu afișează nimic pentru numele clientului, reîmprospătarea metadatelor nu a avut loc sau sursa vizează altă suită. A treia confirmă că intrarea se află acolo unde APT citește cu adevărat.

Potriviți calea inelului de chei cu câmpul signed-by= din linia sursei. O cheie în directorul greșit produce o eroare de sursă neautentificată, care este o defecțiune diferită de un pachet indisponibil.

Tratați o eroare de dependență ca o etapă separată

Instalarea unui .deb descărcat cu dpkg -i nu rezolvă nimic: verifică dependențele, raportează ce lipsește și lasă pachetul pe jumătate configurat. Acesta este comportamentul așteptat, nu o descărcare coruptă.

apt --fix-broken install cere apoi APT o stare consecventă din sursele pe care le aveți. APT nu știe ce VPN ați dorit, iar planul său poate elimina pachete pentru a satisface constrângerea găsită. Citiți tranzacția propusă înainte de a răspunde da și opriți-vă dacă eliminările ating ceva de care aveți nevoie. Repetarea reparației fără a citi planul este felul în care o mică lipsă de dependențe devine un birou care nu mai pornește.

Păstrați primul mesaj semnificativ al managerului de pachete și clasificați-l înainte de a acționa. Un depozit nesemnat, un pachet pe care sursele configurate nu îl conțin, un conflict de versiuni și un client care pornește și apoi moare sunt patru defecțiuni diferite.

Verificați aplicația, nu depozitul

Confirmați că clientul a ajuns în starea instalată, apoi confirmați că programul pornește. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop ar trebui să raporteze install ok installed cu o versiune, iar o eroare de pornire după aceea este o problemă a aplicației, nu a ambalării.

Înregistrați proprietarul depozitului și pachetul aplicației ca obiecte separate, astfel încât o eliminare ulterioară să îl ia pe cel corect și să îl lase pe celălalt intact. Când furnizorul își schimbă ghidul, intrarea de sursă este ceea ce recitiți; numele clientului este ceea ce reinstalați.