Warum apt-cache für Ihr VPN-Paket Installiert (keine) anzeigt

Ein VPN-Paket, das Installed: (none) meldet, fehlt nicht; es ist einfach nicht installiert. Die Zeile, die entscheidet, ob Sie es installieren können, ist Candidate, und APT leitet sie aus den Indizes, dem Suite-Namen, der Architektur und allen geltenden Pinning-Regeln ab. Die meisten Berichte über ein verschwundenes VPN-Paket entpuppen sich als Kandidatenproblem und nicht als Paketierungsproblem. Lesen Sie beide Zeilen, bevor Sie einen einzigen Quelleneintrag anfassen.

Ich prüfe zuerst den Kandidaten, weil das nur einen Befehl kostet und die Hälfte der üblichen Vermutungen ausschließt.

Was Ihnen die Ausgabe von apt-cache policy sagt

apt-cache policy liest den lokalen Paket-Cache, nicht das Netzwerk. Es zeigt die installierte Version, die Kandidatenversion und eine Tabelle jedes Index, der das Paket anbietet, samt der ihm zugeordneten Priorität.

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

Der Kandidat ist die Version, die APT gerade jetzt wählen würde. madison listet auf, was jede Quelle mit ihrer Priorität anbietet, und so erkennen Sie ein Paket, das in einem Index existiert, aber den Pinning-Wettbewerb verliert. Das apt-cache-Handbuch dokumentiert beides als Cache-Lesevorgänge, daher beweist keines von beiden, dass der Spiegel in diesem Moment erreichbar ist.

Ist die Kandidatenzeile leer oder zeigt (none), ist nichts in den konfigurierten Quellen für dieses System in seiner Konfiguration geeignet.

Vier Gründe, warum ein Kandidat verschwindet

In der Praxis ist die Ursache fast immer eine von vier Sachen, und jede hat eine andere Lösung.

Der Suite-Name in Ihren Quellen muss zur Distribution passen, für die das Paket gebaut wurde. Ein Debian-bookworm-System, das auf einen trixie-Spiegel zeigt, oder eine Ubuntu-Version, die während eines Upgrades in einer sources.list.d-Datei umbenannt wurde, löst nichts für Pakete, die nur in der anderen Suite existieren. Vergleichen Sie lsb_release -cs mit dem Suite-Feld in jedem Eintrag.

APT sieht nur Pakete, die für die Architekturen gebaut wurden, die dpkg kennt. Ein 32-Bit-Container, ein arm64-Image oder eine Raspberry-Pi-Installation, die ein Paket anfordert, das nur für amd64 ausgeliefert wird, bekommt einen leeren Kandidaten statt einer Fehlermeldung. dpkg --print-architecture und dpkg --print-foreign-architectures sagen Ihnen, in welchem Satz Sie tatsächlich sind.

Auch Komponenten zählen. Ein Paket in contrib oder non-free ist unsichtbar, wenn nur main aktiviert ist, und Ubuntus universe verhält sich genauso. Der Index existiert, und das Paket ist darin; Ihre Liste aktivierter Komponenten enthält es nur nicht.

Pinning ist der stille Fall. Eine Datei in /etc/apt/preferences.d kann ein Paket unter die Installationsschwelle drücken, und dann verschwindet ein völlig guter Kandidat aus der Ausgabe, während der Index ihn weiter listet. Weil policy die Prioritäten neben jeder Quelle ausgibt, ist ein Paket, dessen jede Quelle eine niedrige Pin-Nummer trägt, der Fingerzeig.

Veraltete Indizes sehen wie fehlende Pakete aus

Der Cache ist eine Momentaufnahme. Wenn das letzte apt update an einem Index fehlgeschlagen ist, antworten Abfragen weiter aus der älteren Kopie, und das erwartete Paket ist womöglich nicht in dieser Kopie.

apt update gibt Fehler pro Index aus, also lesen Sie sie, statt direkt zur letzten Zeile zu scrollen.

Eine Aktualisierung, die an einem Signaturfehler, einer abgelaufenen Release-Datei oder einem nicht erreichbaren Spiegel scheitert, lässt den vorherigen Index stehen. Das ist sinnvoll, denn es bewahrt einen funktionierenden Cache, wenn ein Spiegel kurz ausfällt. Der Nebeneffekt ist, dass eine Suche gelingen kann, während das Repository offline ist. Es bedeutet auch, dass die Abwesenheit eines Pakets nichts beweist, bis Sie wissen, wann der Index zuletzt geholt wurde. Prüfen Sie die Dateidaten unter /var/lib/apt/lists, bevor Sie den Paketnamen beschuldigen.

Benennen Sie das Paket, das Sie wirklich brauchen

OpenVPN ist ein Daemon, und die Teile, die Leute üblicherweise wollen, sind separate Pakete.

Die Engine, das NetworkManager-Plugin und der Desktop-Editor sind drei Pakete mit drei Namen, und das Plugin hat eine GTK-Variante, deren Name sich zwischen Distributionen unterscheidet. apt-cache search --names-only openvpn gleicht Namen und bereitgestellte Namen statt Beschreibungen ab, und das ist genau das, was Sie wollen, wenn Sie ungefähr wissen, wie das Ding heißt.

Ist der Name wirklich unbekannt, durchsuchen Sie einmal die Beschreibungen und gehen Sie dann zu exakten Namen zurück. Hängen Sie kein aus einer anderen Distribution entlehntes -gui-Suffix an und schließen Sie daraus, dass das Paket nicht mehr existiert.

Quellen zuletzt ändern, dann die Transaktion prüfen

Ein Repository hinzuzufügen ändert, wer Ihre Updates liefert, daher gehört es an das Ende der Untersuchung, nicht an den Anfang.

Bestätigen Sie vorher Release, Architektur, Komponente und Pin-Status. Notieren Sie, welche der vier Sie geprüft haben, damit die nächste Person den Durchgang nicht wiederholt. Wenn alle vier stimmen und der Kandidat weiter fehlt, ist die ehrliche Schlussfolgerung, dass diese Version dieses Paket nicht ausliefert. Die verbleibenden Optionen sind ein Backport, ein Herstellerpaket oder eine andere unterstützte Version, und jede davon ist eine bewusste Wahl statt einer Vermutung.

Wenn der Kandidat dann erscheint, simulieren Sie, bevor Sie bestätigen: apt-get install --simulate mit dem Paketnamen zeigt, was hereingezogen und was entfernt würde. Paketverfügbarkeit, Installation und ein funktionierender Tunnel bleiben drei getrennte Stufen, und der Tunnel braucht weiterhin sein Profil, seine Anmeldedaten, Routen und DNS, bevor er Traffic trägt.