Pakiet repozytorium czy pakiet klienta VPN: co najpierw?

Instalujesz pakiet dostawcy, polecenie zwraca zero, a mimo to nie ma aplikacji VPN do uruchomienia. Dzieje się tak, gdy zainstalowany pakiet skonfigurował repozytorium zamiast dostarczyć klienta, a różnicę widać w tym, co zostawił na dysku. Czy potrzebujesz obu i w jakiej kolejności, zależy od trzech warunków, a nie od nazewnictwa dostawcy. Poniższa decyzja utrzymuje konfigurację źródła, odświeżenie metadanych i instalację aplikacji jako osobne czynności z osobnymi dowodami.

Co naprawdę zmienia każdy pakiet

Pakiet konfiguracji repozytorium zapisuje wpis źródła APT, importuje klucz podpisu, któremu ten wpis ufa, i kończy działanie. Jego zawartość to kilka plików w /etc/apt oraz brelok z kluczami, i nic do uruchomienia. Pakiet klienta dostarcza demona lub aplikację pulpitu, jej biblioteki i zależności, i to on trafia do menu lub jednostki systemd.

Nazwy plików kończące się na -release sugerują pierwszy rodzaj, ale przyrostek jest konwencją, nie gwarancją. Rzetelnym stwierdzeniem o roli pakietu jest jego lista plików i zależności, a obie można odczytać przed czymkolwiek zainstalowaniem. Dostawca, który przekształca swoje pakowanie, zachowuje tę samą nazwę pliku i zmienia zawartość, więc odpowiedź skopiowana z wątku sprzed dwóch lat może opisywać pakiet, którego już nie ma. Przeczytaj aktualne instrukcje dostawcy dla wydania, które uruchamiasz, a następnie sprawdź, co deklaruje pakiet.

Z tego podziału wynikają trzy etapy: zarejestruj źródło, odśwież metadane, które ono zasila, a następnie zainstaluj aplikację po nazwie. Przewodnik instalacji dla Debiana i Ubuntu trzyma je osobno, dlatego klient jest wymagany w późniejszym kroku, a nie przez pakiet, który ustawił źródło.

Trzy warunki decydujące o kolejności

Pierwszy warunek to czy dostawca publikuje repozytorium dla dokładnie twojego wydania dystrybucji. Linia źródła zbudowana dla jednego zestawu może zostać rozwiązana wobec zależności innego zestawu i zainstalować mieszankę, której nikt nie testował.

Drugi to czy twoja dystrybucja już zawiera klienta. Gdy zawiera, pakiet dystrybucji podąża za przejściami bibliotek i aktualizacjami bezpieczeństwa twojego wydania, podczas gdy pakiet dostawcy może poruszać się szybciej i przynosić własne kopie współdzielonych bibliotek.

Trzeci to jakich funkcji naprawdę potrzebujesz. Kompilacja dostawcy może dostarczyć nowszą implementację protokołu lub integrację z pulpitem, której twoja dystrybucja nie spakowała, i to jest realny powód, by zaakceptować drugie źródło. Jeśli kompilacja dystrybucji pokrywa twoje użycie, dodanie repozytorium firmy trzeciej kupuje pracę przy aktualizacjach i jeszcze jedną relację zaufania za bardzo niewiele.

Rozstrzygnij te trzy odpowiedzi, zanim linia źródła powstanie, bo usunięcie jej później oznacza czyszczenie pakietu i jego klucza. Gdy są rozstrzygnięte, kolejność w ścieżce dostawcy nie jest wyborem: źródło pierwsze, metadane drugie, aplikacja trzecia, nigdy odwrotnie.

Sprawdź, co zostawił pakiet wydania

Przed zainstalowaniem czegokolwiek innego przeczytaj listę plików, a nie opis. W systemach rodziny Debiana manifest pakietu odpowiada, co skonfigurował i gdzie wylądował klucz.

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

Pierwsza linia pokazuje plik źródła i ścieżkę breloka z kluczami, a druga informuje, jaką wersję mogą zaoferować skonfigurowane źródła. Jeśli apt-cache policy nic nie wypisuje dla nazwy klienta, odświeżenie metadanych nie nastąpiło albo źródło celuje w inny zestaw. Trzecia potwierdza, że wpis znajduje się tam, gdzie APT naprawdę czyta.

Dopasuj ścieżkę breloka z kluczami do pola signed-by= w linii źródła. Klucz w niewłaściwym katalogu powoduje błąd nieuwierzytelnionego źródła, a to inna usterka niż niedostępny pakiet.

Traktuj błąd zależności jako osobny etap

Instalacja pobranego .deb za pomocą dpkg -i niczego nie rozwiązuje: sprawdza zależności, zgłasza braki i zostawia pakiet w połowie skonfigurowany. To oczekiwane zachowanie, a nie uszkodzone pobieranie.

Następnie apt --fix-broken install prosi APT o spójny stan z dostępnych źródeł. APT nie wie, jakiego VPN chciałeś, a jego plan może usuwać pakiety, by spełnić znalezione ograniczenie. Przeczytaj proponowaną transakcję, zanim odpowiesz tak, i zatrzymaj się, jeśli usunięcia dotyczą czegoś, czego potrzebujesz. Powtarzanie naprawy bez czytania planu to sposób, w jaki mała luka w zależnościach staje się pulptem, który już się nie uruchamia.

Zachowaj pierwszą istotną wiadomość menedżera pakietów i sklasyfikuj ją przed działaniem. Niepodpisane repozytorium, pakiet, którego nie ma w skonfigurowanych źródłach, konflikt wersji i klient, który startuje, a potem umiera, to cztery różne usterki.

Weryfikuj aplikację, nie repozytorium

Potwierdź, że klient osiągnął stan zainstalowany, a następnie potwierdź, że program się uruchamia. dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop powinien zgłosić install ok installed z wersją, a niepowodzenie uruchomienia po tym jest problemem aplikacji, nie pakowania.

Zarejestruj właściciela repozytorium i pakiet aplikacji jako osobne obiekty, aby późniejsze usunięcie zabrało właściwy i zostawiło drugi nietknięty. Gdy dostawca zmienia swój przewodnik, wpis źródła jest tym, co czytasz ponownie; nazwa klienta jest tym, co instalujesz ponownie.