Wêrom apt-cache foar jo VPN-pakket ynstalleare (gjin) sjen lit

In VPN-pakket dat Installed: (none) rapportearret, ûntbrekt net; it is gewoan net ynstalleare. De rigel dy't beslút oft jo it ynstallearje kinne, is Candidate, dy't APT ôfliedt fan 'e yndeksen, de suite-namme, de arsjitektuer en alle jildende pinning-regels. De measte rapporten oer in ferdwûn VPN-pakket blike in kandidaatprobleem te wêzen en gjin ferpakkingprobleem. Lês beide rigels foardat jo ien boarne-ynfier oanreitsje.

Ik kontrolearje earst de kandidaat, want dat kostet ien opdracht en slút de helte fan 'e gewoane giskingen út.

Wat de útfier fan apt-cache policy jo fertelt

apt-cache policy lêst de pleatslike pakketkaasje, net it netwurk. It printsje de ynstalleare ferzje, de kandidaatferzje en in tabel fan elke yndeks dy't it pakket oanbiedt, mei de prioriteit dy't dêroan ferbûn is.

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

De kandidaat is de ferzje dy't APT no kieze soe. madison listet op wat elke boarne oanbiedt mei syn prioriteit, en sa merke jo in pakket op dat yn in yndeks bestiet mar de pinning-wedstriid ferliest. De apt-cache-hantlieding dokumintearret beide as kaasjelêzingen, dus gjin fan beide bewiist dat de spegel op dit stuit berikber is.

As de kandidaatrigel leech is of (none) sjen lit, is neat yn 'e konfigurearre boarnen geskikt foar dit systeem sa't it konfigurearre is.

Fjouwer redenen wêrom't in kandidaat ferdwynt

Yn 'e praktyk is de oarsaak hast altyd ien fan fjouwer dingen, en elk hat in oare oplossing.

De suite-namme yn jo boarnen moat oerienkomme mei de distribúsje wêrfoar it pakket boud is. In Debian bookworm-systeem rjochte op in trixie-spegel, of in Ubuntu-útjefte dy't by in upgrade yn in sources.list.d-bestân omneamd is, lost neat op foar pakketten dy't allinnich yn 'e oare suite bestean. Ferlykje lsb_release -cs mei it suite-fjild yn elke ynfier.

APT sjocht allinnich pakketten boud foar de arsjitektueren dy't dpkg ken. In 32-bit-kontener, in arm64-ôfbylding of in Raspberry Pi-ynstallaasje dy't in pakket freget dat allinnich foar amd64 levere wurdt, krijt in lege kandidaat ynstee fan in flaterberjocht. dpkg --print-architecture en dpkg --print-foreign-architectures fertelle jo yn hokker set jo eins binne.

Komponinten telle ek mei. In pakket yn contrib of non-free is ûnsichtber as allinnich main ynskeakele is, en Ubuntu's universe hâldt him itselde. De yndeks bestiet en it pakket sit deryn; jo list fan ynskeakele komponinten befettet it gewoan net.

Pinning is de stille. In bestân yn /etc/apt/preferences.d kin in pakket ûnder de ynstallaasjedrompel beheine, en dan ferdwynt in folslein goed kandidaat út 'e útfier wylst de yndeks it noch listet. Om't policy de prioriteiten njonken elke boarne printsjet, is in pakket dêr't elke boarne in leech pinnûmer foar hat it teken.

Ferâldere yndeksen lykje op ûntbrekkende pakketten

De kaasje is in momintopname. As de lêste apt update op ien yndeks mislearre, bliuwe fragen antwurdzje út 'e âldere kopy, en it pakket dat jo ferwachtsje is miskien net yn dy kopy.

apt update printsjet flaters per yndeks, dus lês se ynstee fan direkt nei de lêste rigel te skowen.

In fernijing dy't mislearret troch in hantekeningflater, in ferrûn release-bestân of in ûnberikbere spegel lit de foarige yndeks stean. Dat is in ferstannich ûntwerp, want it behâldt in wurkjende kaasje as in spegel koart del is. It by-effekt is dat in syktocht slagje kin wylst it repository offline is. It betsjut ek dat it ûntbrekken fan in pakket neat bewiist oant jo witte wannear't de yndeks foar it lêst helle is. Kontrolearje de bestânsdatums ûnder /var/lib/apt/lists foardat jo de pakketnamme de skuld jouwe.

Neam it pakket dat jo echt nedich hawwe

OpenVPN is in daemon, en de stikken dy't minsken gewoanwei wolle binne aparte pakketten.

De motor, de NetworkManager-plug-in en de buroblêdredakteur binne trije pakketten mei trije nammen, en de plug-in hat in GTK-fariant waans namme tusken distribúsjes ferskilt. apt-cache search --names-only openvpn oerienkomt nammen en levere nammen ynstee fan beskriuwings, en dat is wat jo wolle as jo sawat witte hoe't it ding hjit.

As de namme eins ûnbekend is, sykje dan ien kear yn beskriuwings en gean dan werom nei krekte nammen. Foegje gjin -gui-efterheaksel ta dat fan in oare distribúsje liend is en konkludearje net dat it pakket net mear bestiet.

Feroarje boarnen as lêste, kontrolearje dan de transaksje

It tafoegjen fan in repository feroaret wa't jo updates leveret, dus it heart oan 'e ein fan it ûndersyk, net oan it begjin.

Foardat, befêstigje útjefte, arsjitektuer, komponint en pinningstatus. Skriuw op hokker fan 'e fjouwer jo kontrolearre hawwe, sadat de folgjende persoan de rûn net werhellet. As alle fjouwer kloppe en de kandidaat noch ûntbrekt, is de earlike konklúzje dat dizze útjefte dat pakket net leveret. De oerbleaune opsjes binne in backport, in leveransierspakket of in oare stipe útjefte, en elk dêrfan is in bewuste kar ynstee fan in gissing.

As de kandidaat dan ferskynt, simulearje foardat jo befêstigje: apt-get install --simulate mei de pakketnamme lit sjen wat helle en wat fuortsmiten wurde soe. Pakketbeskikberens, ynstallaasje en in wurkjende tunnel bliuwe trije aparte stadia, en de tunnel hat noch syn profyl, syn ynloggegevens, syn rûtes en DNS nedich foardat er ferkear draacht.