Bewaarplekpakket of VPN-kliëntpakket: wat kom eerste?

Jy installeer die verskaffer se pakket, die opdrag gee nul terug, en daar is steeds geen VPN-toepassing om te begin nie. Dit gebeur wanneer die pakket wat jy geïnstalleer het ’n bewaarplek opgestel het eerder as om die kliënt te lewer, en die verskil is sigbaar in wat dit op die skyf geplaas het. Of jy albei nodig het, en in watter volgorde, hang van drie voorwaardes af eerder as van die verskaffer se naamgewing. Die besluit hieronder hou bronopstelling, metadata-verfrissing en toepassingsinstallering as aparte handelinge met aparte bewyse.

Wat elke pakket werklik verander

’n Bewaarplek-opstellingspakket skryf ’n APT-broninskrywing, voer die ondertekeningsleutel in wat daardie inskrywing vertrou, en stop. /etc/apt Die vrag daarvan is ’n paar lêers saam met ’n sleutelhanger, en niks wat jy kan uitvoer nie. ’n Kliëntpakket lewer die daemon of die lessenaartoepassing, sy biblioteke en sy afhanklikhede, en dit is die objek wat in ’n kieslys of ’n systemd-eenheid beland.

Lêername wat eindig op -release dui op die eerste soort, maar die agtervoegsel is ’n konvensie eerder as ’n waarborg. Die betroubare stelling oor ’n pakket se rol is sy lêerlys en sy afhanklikhede, albei leesbaar voordat jy enigiets installeer. ’n Verskaffer wat sy verpakking hervorm, hou dieselfde lêernaam en verander die inhoud, so ’n antwoord uit ’n twee jaar oue draad kan ’n pakket beskryf wat nie meer bestaan nie. Lees die verskaffer se huidige instruksies vir die vrystelling wat jy gebruik, en kyk dan wat die pakket verklaar.

Drie stadiums volg uit daardie verdeling: registreer die bron, verfris die metadata wat dit voer, en installeer dan die toepassing by naam. Die Debian- en Ubuntu-installasiegids hou hulle apart, en daarom word die kliënt in ’n latere stap aangevra eerder as deur die pakket wat die bron opgestel het.

Drie voorwaardes wat die volgorde bepaal

Die eerste voorwaarde is of die verskaffer ’n bewaarplek vir jou presiese distribusievrystelling publiseer. ’n Bronlyn wat vir een suite gebou is, kan teen ’n ander suite se afhanklikhede oplos en ’n mengsel installeer wat niemand getoets het nie.

Die tweede is of jou distribusie die kliënt reeds bevat. Wanneer dit wel die geval is, volg die distro-pakket jou vrystelling se biblioteekoorgange en sekuriteitsopdaterings, terwyl die verskafferpakket vinniger kan beweeg en sy eie kopieë van gedeelde biblioteke kan saambring.

Die derde is watter funksies jy werklik nodig het. ’n Verskafferbou kan ’n nuwer protokolimplementering of ’n lessenaarintegrasie lewer wat jou distribusie nie verpak het nie, en dit is ’n geldige rede om ’n tweede bron te aanvaar. As die distro-bou jou gebruik dek, koop die byvoeging van ’n derdeparty-bewaarplek opdateringswerk en nog ’n vertrouensverhouding vir baie min.

Besleg daardie drie antwoorde voordat die bronlyn bestaan, want om dit later te verwyder beteken om die pakket en sy sleutel te suiwer. Sodra dit besleg is, is die volgorde binne die verskafferpad nie ’n keuse nie: bron eerste, metadata tweede, toepassing derde, nooit omgekeerd nie.

Kyk wat die vrystellingspakket agtergelaat het

Voordat jy enigiets anders installeer, lees die lêerlys eerder as die beskrywing. Op Debian-familie-stelsels antwoord die pakketmanifes wat dit opgestel het en waar die sleutel beland het.

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

Die eerste lyn wys die bronlêer en die sleutelhangerpad, terwyl die tweede rapporteer watter weergawe die opgestelde bronne kan bied. As apt-cache policy niks vir die kliëntnaam druk nie, het die metadata-verfrissing nie plaasgevind nie of die bron teiken ’n ander suite. Die derde bevestig die inskrywing sit waar APT dit werklik lees.

Pas die sleutelhangerpad teen die signed-by= veld in die bronlyn. ’n Sleutel in die verkeerde gids lewer ’n ongemagtigde-bron-fout, wat ’n ander fout is as ’n onbeskikbare pakket.

Behandel ’n afhanklikheidsfout as ’n aparte stadium

Om ’n afgelaaide .deb met dpkg -i te installeer, los niks op nie: dit kontroleer afhanklikhede, rapporteer wat ontbreek en laat die pakket half opgestel. Dit is verwagte gedrag, nie ’n korrupte aflaai nie.

apt --fix-broken install vra dan vir APT ’n konsekwente toestand uit die bronne wat jy het. APT weet nie watter VPN jy wou hê nie, en sy plan kan pakkette verwyder om die beperking wat dit gevind het, te bevredig. Lees die voorgestelde transaksie voordat jy ja antwoord, en stop as die verwyderings iets raak wat jy nodig het. Om die herstel te herhaal sonder om die plan te lees, is hoe ’n klein afhanklikheidsgaping ’n lessenaar word wat nie meer begin nie.

Hou die eerste betekenisvolle boodskap van die pakketbestuurder en klassifiseer dit voordat jy optree. ’n Ongetekende bewaarplek, ’n pakket wat die opgestelde bronne nie dra nie, ’n weergawekonflik, en ’n kliënt wat begin en dan sterf, is vier aparte foute.

Verifieer die toepassing, nie die bewaarplek nie

Bevestig dat die kliënt die geïnstalleerde toestand bereik het, bevestig dan dat die program begin. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop moet rapporteer install ok installed met ’n weergawe, en ’n bekendstellingsfout daarna is ’n toepassingsprobleem eerder as ’n verpakkingsprobleem.

Rekord die bewaarplekeienaar en die toepassingspakket as aparte objekte, sodat ’n latere verwydering die regte een uithaal en die ander een ongeskonde laat. Wanneer die verskaffer sy gids verander, is die broninskrywing wat jy herlees; die kliëntnaam is wat jy herinstalleer.