Repopakke eller VPN-klientpakke: kva kjem fyrst?
Ei utgåvepakke registrerer berre ei kjelde og ein signeringsnøkkel. Avgjer om repoet til leverandøren er verdt det, og installer deretter klienten som eit eige steg.
Du installerer pakka til leverandøren, kommandoen returnerer null, og det finst framleis ingen VPN-program å starte. Det skjer når pakka du installerte konfigurerte eit repo i staden for å levera klienten, og skilnaden syner seg i det ho la att på disken. Om du treng begge, og i kva rekkjefølgje, kjem an på tre vilkår og ikkje på namngjevinga til leverandøren. Avgjerda nedanfor held kjeldeoppsett, oppdatering av metadata og installasjon av programmet som skilde handlingar med skilde prov.
Kva kvar pakke faktisk endrar
Ei repokonfigurasjonspakke skriv ein APT-kjeldeoppføring, importerer signeringsnøkkelen som oppføringa stolar på, og avsluttar. Innhaldet er eit par filer under /etc/apt pluss ein nøkkelring, og ingenting som kan køyrast. Ei klientpakke leverer daemonen eller skrivebordsprogrammet, biblioteka og avhengnadene, og det er objektet som hamnar i ei meny eller ei systemd-eining.
Filnamn som endar på -release tyder på den fyrste typen, men endinga er ein konvensjon, ikkje ei garanti. Den pålitelege påstanden om rolla til ei pakke er fillista og avhengnadene, og begge er lesbare før du installer noko. Ein leverandør som formgjev pakkinga si på nytt, held same filnamn og endrar innhaldet, så eit svar kopiert frå ein tråd som er to år gammal, kan skildra ei pakke som ikkje finst lenger. Les dei gjeldande instruksjonane til leverandøren for utgåva du køyrer, og sjekk deretter kva pakka erklærer.
Tre steg følgjer av den delinga: registrer kjelda, oppdater metadataa ho fører med seg, og installer så programmet ved namn. Installasjonsrettleiinga for Debian og Ubuntu held dei skilde, og difor blir klienten beden om i eit seinare steg og ikkje av pakka som sette opp kjelda.
Tre vilkår som avgjer rekkjefølgja
Det fyrste vilkåret er om leverandøren publiserer eit repo for nøyaktig di distribusjonsutgåve. Ei kjeldelinje bygd for ein suite kan løysast mot avhengnadene til ein annan suite og installera ei blanding ingen har prøvd.
Det andre er om distribusjonen din allereie har klienten. Når han har det, følgjer distribusjonspakka bibliotekovergangane og tryggingsoppdateringane til utgåva di, medan leverandørpakka kan flytta seg snøggare og ta med eigne kopiar av delte bibliotek.
Det tredje er kva funksjonar du faktisk treng. Ein bygg frå leverandøren kan levera ein nyare protokollimplementasjon eller ein skrivebordsintegrasjon som distribusjonen din ikkje har pakka, og det er ei reell grunn til å godta ei ekstra kjelde. Viss distribusjonsbygget dekkjer bruken din, kjøper eit tredjepartsrepo oppdateringsarbeid og eitt til tillitshøve for svært lite.
Avgjer dei tre svara før kjeldelinja finst, fordi å fjerna ho seinare tyder å reinska pakka og nøkkelen. Når dei er avgjorde, er rekkjefølgja i leverandørsporet ikkje eit val: kjelde fyrst, metadata andre, program tredje, aldri omvendt.
Sjekk kva utgåvepakka la att
Før du installer noko anna, les fillista i staden for skildringa. På system i Debian-familien svarar pakkemanifestet på kva ho konfigurerte og kvar nøkkelen landa.
dpkg -L proton-vpn-release | grep -E 'apt|keyring'
apt-cache policy proton-vpn-gnome-desktop
grep -r protonvpn /etc/apt/sources.list.d/
Den fyrste linja syner kjeldafila og stigen til nøkkelringen, medan den andre melder kva versjon dei konfigurerte kjeldene kan by på. Viss apt-cache policy ikkje skriv noko for klientnamnet, har ikkje metadataoppdateringa skjedd, eller kjelda rettar seg mot ein annan suite. Den tredje stadfester at oppføringa ligg der APT faktisk les.
Samanlikn stigen til nøkkelringen med feltet signed-by= i kjeldelinja. Ein nøkkel i galen mappe gjev ein feil om uautentisert kjelde, som er ein annan feil enn ei pakke som ikkje er tilgjengeleg.
Behandle ein avhengnadsfeil som eit eige steg
Å installera ei nedlasta .deb med dpkg -i løyser ingenting: ho sjekkar avhengnader, melder kva som manglar og lèt pakka vera halvkonfigurert. Det er venta åtferd, ikkje ei øydelagd nedlasting.
apt --fix-broken install ber deretter APT om ein konsistent tilstand frå kjeldene du har. APT veit ikkje kva VPN du ville ha, og planen kan fjerna pakker for å oppfylla avgrensinga han fann. Les transaksjonen som blir føreslått, før du svarar ja, og stopp viss fjerningane rører noko du treng. Å gjenta reparasjonen utan å lesa planen er måten eit lite avhengnadshol blir eit skrivebord som ikkje startar lenger.
Ta vare på den fyrste meiningsfulle meldinga frå pakkehandsamaren og klassifiser ho før du handlar. Eit usignert repo, ei pakke dei konfigurerte kjeldene ikkje har, ein versjonskonflikt og ein klient som startar og så døyr er fire ulike feil.
Stadfest programmet, ikkje repoet
Stadfest at klienten nådde installert tilstand, og stadfest deretter at programmet startar. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop skal melda install ok installed med ein versjon, og ein startfeil etterpå er eit programproblem og ikkje eit pakkeproblem.
Registrer eigaren av repoet og programpakka som skilde objekt, slik at ei seinare fjerning tek den rette og lèt den andre vera intakt. Når leverandøren endrar rettleiinga si, er kjeldeoppføringa det du les på nytt; klientnamnet er det du installer på nytt.