Hvorfor apt-cache viser installeret (ingen) for din VPN-pakke

En VPN-pakke, der rapporterer Installed: (none), mangler ikke; den er simpelthen ikke installeret. Linjen, der afgør, om du kan installere den, er Candidate, som APT udleder af indeksene, suite-navnet, arkitekturen og eventuelle pin-regler, der gælder. De fleste rapporter om en forsvundet VPN-pakke viser sig at være et kandidatproblem snarere end et pakkeproblem. Læs begge linjer, før du rører en eneste kildeindgang.

Jeg tjekker kandidaten først, fordi det koster én kommando og udelukker halvdelen af de sædvanlige gæt.

Hvad policy-outputtet fortæller dig

apt-cache policy læser den lokale pakkecache, ikke netværket. Den udskriver den installerede version, kandidatversionen og en tabel over hvert indeks, der tilbyder pakken, med den prioritet, der er knyttet til det.

apt-cache policy openvpn
apt-cache madison openvpn
apt list -a network-manager-openvpn

Kandidaten er den version, APT ville vælge lige nu. madison viser, hvad hver kilde tilbyder med sin prioritet, og det er sådan, du spotter en pakke, der findes i et indeks, men taber pin-konkurrencen. apt-cache-manualen dokumenterer begge som cachelæsninger, så ingen af dem beviser, at spejlet kan nås i dette øjeblik.

Hvis kandidatlinjen er tom eller viser (none), er intet i de konfigurerede kilder kvalificeret til dette system, som det er konfigureret.

Fire årsager til at en kandidat forsvinder

I praksis er årsagen næsten altid en af fire ting, og hver især har en forskellig løsning.

Suite-navnet i dine kilder skal matche den distribution, pakken blev bygget til. Et Debian bookworm-system, der peger på et trixie-spejl, eller en Ubuntu-udgivelse, der blev omdøbt i en sources.list.d-fil under en opgradering, løser intet for pakker, der kun findes i den anden suite. Sammenlign lsb_release -cs med suite-feltet i hver indgang.

APT ser kun pakker bygget til de arkitekturer, dpkg kender. En 32-bit-container, et arm64-image eller en Raspberry Pi-installation, der beder om en pakke, der kun leveres til amd64, får en tom kandidat i stedet for en fejlmeddelelse. dpkg --print-architecture og dpkg --print-foreign-architectures fortæller dig, hvilket sæt du faktisk er i.

Komponenter betyder også noget. En pakke i contrib eller non-free er usynlig, når kun main er aktiveret, og Ubuntus universe opfører sig på samme måde. Indekset findes, og pakken er i det; din liste over aktiverede komponenter inkluderer den bare ikke.

Pinning er den stille. En fil i /etc/apt/preferences.d kan begrænse en pakke under installationsgrænsen, og så forsvinder en helt fin kandidat fra outputtet, mens indekset stadig viser den. Fordi policy udskriver prioriteterne ved siden af hver kilde, er en pakke, hvor hver kilde har et lavt pin-nummer, det afslørende tegn.

Forældede indekser ligner manglende pakker

Cachen er et øjebliksbillede. Hvis den sidste apt update fejlede på ét indeks, fortsætter forespørgsler med at svare fra den ældre kopi, og den pakke, du forventer, er måske ikke i den kopi.

apt update udskriver fejl for hvert indeks, så læs dem i stedet for at rulle direkte til den sidste linje.

En opdatering, der fejler på en signaturfejl, en udløbet release-fil eller et utilgængeligt spejl, lader det forrige indeks blive liggende. Det er et fornuftigt design, fordi det bevarer en fungerende cache, når et spejl kortvarigt er nede. Bivirkningen er, at en søgning kan lykkes, mens repositoriet er offline. Det betyder også, at fraværet af en pakke ikke beviser noget, før du ved, hvornår indekset sidst blev hentet. Tjek fildatoerne under /var/lib/apt/lists, før du skyder skylden på pakkenavnet.

Navngiv den pakke, du faktisk har brug for

OpenVPN er en daemon, og de dele, folk normalt vil have, er separate pakker.

Motoren, NetworkManager-pluginet og skrivebordseditoren er tre pakker med tre navne, og pluginet har en GTK-variant, hvis navn er forskelligt mellem distributioner. apt-cache search --names-only openvpn matcher navne og angivne navne i stedet for beskrivelser, og det er, hvad du vil, når du nogenlunde ved, hvad tingen hedder.

Hvis navnet virkelig er ukendt, søg i beskrivelser én gang, og gå derefter tilbage til præcise navne. Tilføj ikke et -gui-suffiks lånt fra en anden distribution og konkluder, at pakken ikke findes længere.

Skift kilder sidst, og verificér derefter transaktionen

Tilføjelse af et repository ændrer, hvem der leverer dine opdateringer, så det hører til i slutningen af undersøgelsen, ikke i begyndelsen.

Før det skal du bekræfte udgivelse, arkitektur, komponent og pin-status. Skriv ned, hvilke af de fire du tjekkede, så den næste person ikke gentager gennemgangen. Hvis alle fire er rigtige, og kandidaten stadig mangler, er den ærlige konklusion, at denne udgivelse ikke leverer den pakke. De resterende muligheder er en backport, en leverandørpakke eller en anden understøttet udgivelse, og hver af dem er et bevidst valg snarere end et gæt.

Når kandidaten så dukker op, skal du simulere, før du bekræfter: apt-get install --simulate med pakkenavnet viser, hvad der ville blive trukket ind, og hvad der ville blive fjernet. Pakketilgængelighed, installation og en fungerende tunnel forbliver tre separate faser, og tunnelen har stadig brug for sin profil, legitimationsoplysninger, ruter og DNS, før den bærer trafik.