Repopakket of VPN-clientpakket: wat komt eerst?

Je installeert het pakket van de leverancier, de opdracht geeft nul terug, en toch is er geen VPN-applicatie om te starten. Dat gebeurt wanneer het pakket dat je installeerde een repo configureerde in plaats van de client mee te leveren, en het verschil is zichtbaar in wat het op schijf achterliet. Of je beide nodig hebt, en in welke volgorde, hangt af van drie voorwaarden en niet van de naamgeving van de leverancier. De beslissing hieronder houdt broninstelling, verversen van metadata en installatie van de applicatie als afzonderlijke handelingen met afzonderlijk bewijs.

Wat elk pakket werkelijk verandert

Een repoconfiguratiepakket schrijft een APT-bronvermelding, importeert de ondertekeningssleutel die die vermelding vertrouwt, en stopt. De inhoud is een paar bestanden onder /etc/apt plus een sleutelbos, en niets uitvoerbaars. Een clientpakket levert de daemon of de desktopapplicatie, de bibliotheken en de afhankelijkheden, en dat is het object dat in een menu of een systemd-unit belandt.

Bestandsnamen die op -release eindigen suggereren het eerste type, maar het achtervoegsel is een conventie, geen garantie. De betrouwbare uitspraak over de rol van een pakket is de bestandslijst en de afhankelijkheden, beide leesbaar voordat je iets installeert. Een leverancier die zijn verpakking hervormt, houdt dezelfde bestandsnaam en verandert de inhoud, dus een antwoord dat uit een twee jaar oude thread is gekopieerd kan een pakket beschrijven dat niet meer bestaat. Lees de huidige instructies van de leverancier voor de release die je draait, en controleer daarna wat het pakket verklaart.

Uit die splitsing volgen drie fasen: registreer de bron, ververs de metadata die zij voedt, en installeer daarna de applicatie op naam. De installatiehandleiding voor Debian en Ubuntu houdt ze gescheiden, en daarom wordt de client in een latere stap gevraagd en niet door het pakket dat de bron instelde.

Drie voorwaarden die de volgorde bepalen

De eerste voorwaarde is of de leverancier een repo publiceert voor precies jouw distributierelease. Een bronregel die voor de ene suite is gebouwd, kan tegen de afhankelijkheden van een andere suite oplossen en een mengeling installeren die niemand heeft getest.

De tweede is of jouw distributie de client al meelevert. Als dat zo is, volgt het distropakket de bibliotheekovergangen en beveiligingsupdates van jouw release, terwijl het leverancierspakket sneller kan bewegen en eigen kopieën van gedeelde bibliotheken kan meebrengen.

De derde is welke functies je echt nodig hebt. Een build van de leverancier kan een nieuwere protocolimplementatie of een desktopintegratie leveren die jouw distributie niet heeft verpakt, en dat is een echte reden om een tweede bron te accepteren. Als de distro-build jouw gebruik dekt, koopt het toevoegen van een externe repo updatewerk en nog een vertrouwensrelatie voor heel weinig.

Bespreek die drie antwoorden voordat de bronregel bestaat, want die later verwijderen betekent het pakket en zijn sleutel opschonen. Zodra ze vaststaan, is de volgorde binnen het leverancierspad geen keuze: bron eerst, metadata tweede, applicatie derde, nooit omgekeerd.

Controleer wat het releasepakket achterliet

Lees voordat je iets anders installeert de bestandslijst in plaats van de beschrijving. Op systemen uit de Debian-familie beantwoordt het pakketmanifest wat het configureerde en waar de sleutel terechtkwam.

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

De eerste regel toont het bronbestand en het pad naar de sleutelbos, terwijl de tweede meldt welke versie de geconfigureerde bronnen kunnen bieden. Als apt-cache policy niets afdrukt voor de clientnaam, heeft het verversen van de metadata niet plaatsgevonden of richt de bron zich op een andere suite. De derde bevestigt dat de vermelding staat waar APT werkelijk leest.

Vergelijk het pad van de sleutelbos met het veld signed-by= in de bronregel. Een sleutel in de verkeerde map levert een fout over een niet-geverifieerde bron op, wat een ander defect is dan een niet-beschikbaar pakket.

Behandel een afhankelijkheidsfout als een aparte fase

Een gedownload .deb met dpkg -i installeren lost niets op: het controleert afhankelijkheden, meldt wat ontbreekt en laat het pakket half geconfigureerd achter. Dat is verwacht gedrag, geen beschadigde download.

apt --fix-broken install vraagt APT daarna om een consistente toestand uit de bronnen die je hebt. APT weet niet welke VPN je wilde, en het plan kan pakketten verwijderen om de gevonden beperking te vervullen. Lees de voorgestelde transactie voordat je ja antwoordt, en stop als de verwijderingen iets raken dat je nodig hebt. De reparatie herhalen zonder het plan te lezen is hoe een kleine afhankelijkheidskloof een desktop wordt die niet meer start.

Bewaar het eerste betekenisvolle bericht van de pakketbeheerder en classificeer het voordat je handelt. Een niet-ondertekende repo, een pakket dat de geconfigureerde bronnen niet bevatten, een versieconflict en een client die start en daarna sterft zijn vier verschillende defecten.

Verifieer de applicatie, niet de repo

Bevestig dat de client de geïnstalleerde toestand bereikte en bevestig daarna dat het programma start. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop hoort install ok installed met een versie te melden, en een startfout daarna is een applicatieprobleem en geen verpakkingsprobleem.

Leg de eigenaar van de repo en het applicatiepakket vast als aparte objecten, zodat een latere verwijdering het juiste wegneemt en het andere intact laat. Wanneer de leverancier zijn handleiding wijzigt, is de bronvermelding wat je opnieuw leest; de clientnaam is wat je opnieuw installeert.