Repopakke eller VPN-klientpakke: hvilken kommer først?

Du installerer leverandørens pakke, kommandoen returnerer null, og det finnes fortsatt ingen VPN-applikasjon å starte. Det skjer når pakken du installerte konfigurerte et repo i stedet for å levere klienten, og forskjellen vises i det den la igjen på disken. Om du trenger begge, og i hvilken rekkefølge, avhenger av tre betingelser og ikke av leverandørens navngiving. Avgjørelsen nedenfor holder kildeoppsett, oppdatering av metadata og installasjon av applikasjonen som separate handlinger med separate bevis.

Hva hver pakke faktisk endrer

En repokonfigurasjonspakke skriver en APT-kildeoppføring, importerer signeringsnøkkelen den oppføringen stoler på, og avslutter. Innholdet er et par filer under /etc/apt pluss en nøkkelring, og ingenting som kan kjøres. En klientpakke leverer dæmonen eller skrivebordsapplikasjonen, bibliotekene og avhengighetene dens, og det er objektet som ender i en meny eller en systemd-enhet.

Filnavn som slutter på -release antyder den første typen, men endelsen er en konvensjon, ikke en garanti. Den pålitelige påstanden om en pakkes rolle er fillisten og avhengighetene, og begge er lesbare før du installerer noe. En leverandør som former om pakkingen sin beholder samme filnavn og endrer innholdet, så et svar kopiert fra en to år gammel tråd kan beskrive en pakke som ikke finnes lenger. Les leverandørens gjeldende instruksjoner for utgivelsen du kjører, og sjekk deretter hva pakken erklærer.

Tre trinn følger av den delingen: registrer kilden, oppdater metadataene den mater, og installer deretter applikasjonen ved navn. Installasjonsveiledningen for Debian og Ubuntu holder dem atskilt, og derfor blir klienten bedt om i et senere trinn og ikke av pakken som satte opp kilden.

Tre betingelser som avgjør rekkefølgen

Den første betingelsen er om leverandøren publiserer et repo for nøyaktig din distribusjonsutgivelse. En kildelinje bygget for én suite kan løses mot en annen suites avhengigheter og installere en blanding ingen har testet.

Den andre er om distribusjonen din allerede har klienten. Når den har det, følger distribusjonspakken bibliotekovergangene og sikkerhetsoppdateringene til utgivelsen din, mens leverandørpakken kan bevege seg raskere og ta med egne kopier av delte biblioteker.

Den tredje er hvilke funksjoner du faktisk trenger. En leverandørbygg kan levere en nyere protokollimplementasjon eller en skrivebordsintegrasjon distribusjonen din ikke har pakket, og det er en reell grunn til å godta en ekstra kilde. Hvis distribusjonsbygget dekker bruken din, kjøper et tredjepartsrepo oppdateringsarbeid og ett til tillitsforhold for svært lite.

Avgjør de tre svarene før kildelinjen finnes, fordi å fjerne den senere betyr å rense pakken og nøkkelen. Når de er avgjort, er rekkefølgen i leverandørsporet ikke et valg: kilde først, metadata andre, applikasjon tredje, aldri omvendt.

Sjekk hva utgivelsespakken la igjen

Før du installerer noe annet, les fillisten i stedet for beskrivelsen. På systemer i Debian-familien svarer pakkemanifestet på hva den konfigurerte og hvor nøkkelen landet.

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 første linjen viser kildefilen og banen til nøkkelringen, mens den andre rapporterer hvilken versjon de konfigurerte kildene kan tilby. Hvis apt-cache policy ikke skriver ut noe for klientnavnet, har ikke metadataoppdateringen skjedd, eller kilden retter seg mot en annen suite. Den tredje bekrefter at oppføringen ligger der APT faktisk leser.

Sammenlign banen til nøkkelringen med signed-by=-feltet i kildelinjen. En nøkkel i feil katalog gir en feil om uautentisert kilde, som er en annen feil enn en utilgjengelig pakke.

Behandle en avhengighetsfeil som et eget trinn

Å installere en nedlastet .deb med dpkg -i løser ingenting: den sjekker avhengigheter, rapporterer hva som mangler og lar pakken være halvkonfigurert. Det er forventet atferd, ikke en ødelagt nedlasting.

apt --fix-broken install ber deretter APT om en konsistent tilstand fra kildene du har. APT vet ikke hvilken VPN du ønsket, og planen kan fjerne pakker for å oppfylle begrensningen den fant. Les transaksjonen som foreslås før du svarer ja, og stopp hvis fjerningen berører noe du trenger. Å gjenta reparasjonen uten å lese planen er måten et lite avhengighetsgap blir et skrivebord som ikke starter lenger.

Ta vare på den første meningsfulle meldingen fra pakkebehandleren og klassifiser den før du handler. Et usignert repo, en pakke de konfigurerte kildene ikke har, en versjonskonflikt og en klient som starter og deretter dør er fire forskjellige feil.

Verifiser applikasjonen, ikke repoet

Bekreft at klienten nådde installert tilstand, og bekreft deretter at programmet starter. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop skal rapportere install ok installed med en versjon, og en startfeil etterpå er et applikasjonsproblem og ikke et pakkeproblem.

Registrer repoeieren og applikasjonspakken som separate objekter, slik at en senere fjerning tar den riktige og lar den andre være intakt. Når leverandøren endrer veiledningen sin, er kildeoppføringen det du leser på nytt; klientnavnet er det du installerer på nytt.