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

Du installerer leverandørens pakke, kommandoen returnerer nul, og der er stadig ingen VPN-applikation at starte. Det sker, når den pakke, du installerede, konfigurerede et repositorium i stedet for at levere klienten, og forskellen ses i, hvad den placerede på disken. Om du har brug for begge, og i hvilken rækkefølge, afhænger af tre betingelser og ikke af leverandørens navngivning. Beslutningen nedenfor holder kildeopsætning, metadataopdatering og applikationsinstallation som separate handlinger med separate beviser.

Hvad hver pakke faktisk ændrer

En pakke til repository-konfiguration skriver en APT-kildepost, importerer den signeringsnøgle, som posten stoler på, og afslutter. /etc/apt Dens indhold er et par filer og en nøglering, og intet du kan køre. En klientpakke leverer dæmonen eller skrivebordsapplikationen, dens biblioteker og dens afhængigheder, og det er det objekt, der ender i en menu eller i en systemd-enhed.

Filenavne med endelsen -release tyder på den første slags, men endelsen er en konvention, ikke en garanti. Det pålidelige udsagn om en pakkes rolle er dens filliste og dens afhængigheder, begge læsbare før du installerer noget. En leverandør, der omformer sin pakning, beholder det samme filnavn og ændrer indholdet, så et svar kopieret fra en tråd fra for to år siden kan beskrive en pakke, der ikke findes længere. Læs udbyderens aktuelle instruktioner for den udgivelse, du kører, og kontrollér derefter, hvad pakken erklærer.

Tre trin følger af den opdeling: registrér kilden, opdater de metadata, den fodrer, og installér derefter applikationen ved navn. Vejledningen til installation på Debian og Ubuntu holder dem adskilt, og derfor anmodes klienten om i et senere trin og ikke af den pakke, der satte kilden op.

Tre betingelser, der afgør rækkefølgen

Den første betingelse er, om leverandøren udgiver et repositorium til netop din distributionsudgivelse. En kildelinje bygget til én udgivelse kan opløses mod en anden udgivelses afhængigheder og installere en blanding, som ingen har testet.

Den anden er, om din distribution allerede har klienten. Når den har, følger distro-pakken din udgivelses biblioteksovergange og sikkerhedsopdateringer, mens leverandørpakken kan bevæge sig hurtigere og medbringe sine egne kopier af delte biblioteker.

Den tredje er, hvilke funktioner du faktisk har brug for. Et leverandørbuild kan levere en nyere protokolimplementering eller en skrivebordsintegration, som din distribution ikke har pakket, og det er en reel grund til at acceptere en anden kilde. Hvis distroens build dækker din brug, køber et tredjepartsrepositorium opdateringsarbejde og endnu et tillidsforhold for meget lidt.

Afgør de tre svar, før kildelinjen findes, fordi fjernelse senere betyder at rense pakken og dens nøgle ud. Når de er afgjort, er rækkefølgen i leverandørvejen ikke et valg: kilde først, metadata andet, applikation tredje, aldrig omvendt.

Kontrollér, hvad udgivelsespakken efterlod

Før du installerer noget andet, så læs fillisten i stedet for beskrivelsen. På systemer af Debian-familien svarer pakkens manifest på, hvad den konfigurerede, og hvor nøglen landede.

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 linje viser kildefilen og nøgleringens sti, mens den anden rapporterer, hvilken version de konfigurerede kilder kan tilbyde. Hvis apt-cache policy ikke udskriver noget for klientnavnet, er metadataopdateringen ikke sket, eller kilden peger på en anden udgivelse. Den tredje bekræfter, at posten står, hvor APT faktisk læser.

Sammenlign nøgleringens sti med feltet signed-by= i kildelinjen. En nøgle i den forkerte mappe giver en fejl om ikke-autentificeret kilde, og det er en anden fejl end en utilgængelig pakke.

Behandl en afhængighedsfejl som et selvstændigt trin

Installation af en downloadet .deb med dpkg -i løser intet: den kontrollerer afhængigheder, rapporterer hvad der mangler og efterlader pakken halvkonfigureret. Det er forventet adfærd, ikke en beskadiget download.

apt --fix-broken install beder derefter APT om en konsistent tilstand ud fra de kilder, du har. APT ved ikke, hvilken VPN du ville have, og dens plan kan fjerne pakker for at opfylde den begrænsning, den fandt. Læs den foreslåede transaktion, før du svarer ja, og stop, hvis fjernelserne rører noget, du har brug for. At gentage reparationen uden at læse planen er, hvordan et lille afhængighedshul bliver et skrivebord, der ikke starter længere.

Behold den første meningsfulde besked fra pakkehåndteringen, og klassificér den, før du handler. Et usigneret repositorium, en pakke som de konfigurerede kilder ikke har, en versionskonflikt og en klient, der starter og derefter dør, er fire separate fejl.

Verificér applikationen, ikke repositoriet

Bekræft, at klienten nåede den installerede tilstand, og bekræft derefter, at programmet starter. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop skal rapportere install ok installed med en version, og en startfejl derefter er et applikationsproblem, ikke et pakningsproblem.

Registrér repositoryets ejer og applikationspakken som separate objekter, så en senere fjernelse tager den rigtige og lader den anden være intakt. Når leverandøren ændrer sin vejledning, er kildeposten det, du læser igen; klientnavnet er det, du geninstallerer.