Tárolócsomag vagy VPN-klienscsomag: melyik jön előbb?

Telepíti a szállító csomagját, a parancs nullát ad vissza, és mégsincs elindítható VPN-alkalmazás. Ez akkor történik, amikor a telepített csomag tárolót állított be ahelyett, hogy a klienst szállította volna, és a különbség abban látszik, mit tett a lemezre. Hogy mindkettőre szüksége van-e, és milyen sorrendben, három feltételtől függ, nem a szállító elnevezésétől. Az alábbi döntés a forrás beállítását, a metaadatok frissítését és az alkalmazás telepítését külön műveletként tartja, külön bizonyítékokkal.

Mit változtat valójában az egyes csomagok

A tároló-beállító csomag beír egy APT-forrásbejegyzést, importálja az aláírókulcsot, amelyben az a bejegyzés bízik, majd kilép. A tartalma néhány fájl a /etc/apt alatt és egy kulcstartó, és semmi futtatható. A klienscsomag a démont vagy az asztali alkalmazást, annak könyvtárait és függőségeit szállítja, és ez az objektum kerül a menübe vagy egy systemd-egységbe.

A -release végződő fájlnevek az első fajtára utalnak, de az utótag szokás, nem garancia. Egy csomag szerepéről a megbízható állítás a fájllistája és a függőségei, és mindkettő olvasható bármi telepítése előtt. Az a szállító, amely újraformálja a csomagolását, megtartja ugyanazt a fájlnevet és megváltoztatja a tartalmat, ezért egy két évvel ezelőtti szálból másolt válasz olyan csomagot írhat le, amely már nem létezik. Olvassa el a szolgáltató jelenlegi útmutatóját a futtatott kiadáshoz, majd ellenőrizze, mit nyilatkozik a csomag.

Ebből a felosztásból három szakasz következik: regisztrálja a forrást, frissítse az általa táplált metaadatokat, majd telepítse az alkalmazást név szerint. A Debian és Ubuntu telepítési útmutató külön tartja őket, ezért a klienst egy későbbi lépésben kérik, nem a forrást beállító csomagban.

Három feltétel, amely eldönti a sorrendet

Az első feltétel, hogy a szállító közzétesz-e tárolót a pontos disztribúció-kiadásához. Az egyik sorozathoz épített forrássor egy másik sorozat függőségeihez illeszkedhet, és olyan keveréket telepíthet, amelyet senki sem próbált ki.

A második, hogy a disztribúciója már tartalmazza-e a klienst. Ha igen, a disztribúciós csomag követi a kiadás könyvtárváltásait és biztonsági frissítéseit, míg a szállító csomagja gyorsabban mozoghat, és saját példányokat hozhat a megosztott könyvtárakból.

A harmadik, hogy mely funkciókra van valóban szüksége. A szállító buildje újabb protokoll-megvalósítást vagy olyan asztali integrációt szállíthat, amelyet a disztribúciója nem csomagolt, és ez valódi ok egy második forrás elfogadására. Ha a disztribúció buildje lefedi a használatát, egy harmadik féltől származó tároló hozzáadása frissítési munkát és még egy bizalmi viszonyt vásárol nagyon kevésért.

Döntse el ezt a három választ, mielőtt a forrássor létezne, mert az utólagos eltávolítás a csomag és a kulcsa tisztítását jelenti. Ha eldőlt, a szállító útvonalán belüli sorrend nem választás: forrás először, metaadatok másodszor, alkalmazás harmadszor, soha fordítva.

Ellenőrizze, mit hagyott maga után a kiadási csomag

Mielőtt bármi mást telepítene, a fájllistát olvassa el, ne a leírást. A Debian család rendszerein a csomag jegyzéke megválaszolja, mit állított be, és hová került a kulcs.

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

Az első sor a forrásfájlt és a kulcstartó útvonalát mutatja, a második pedig azt jelenti, milyen verziót kínálhatnak a beállított források. Ha a apt-cache policy semmit sem ír ki a kliens nevére, a metaadatok frissítése nem történt meg, vagy a forrás másik sorozatot céloz. A harmadik megerősíti, hogy a bejegyzés ott van, ahol az APT valóban olvas.

Illessze a kulcstartó útvonalát a forrássor signed-by= mezőjéhez. A rossz könyvtárban lévő kulcs hitelesítetlen forrás hibáját okozza, ami más hiba, mint az elérhetetlen csomag.

Kezelje a függőségi hibát külön szakaszként

Egy letöltött .deb telepítése a dpkg -i paranccsal semmit sem old meg: ellenőrzi a függőségeket, jelenti, mi hiányzik, és félkész állapotban hagyja a csomagot. Ez várható viselkedés, nem sérült letöltés.

A apt --fix-broken install ezután konzisztens állapotot kér az APT-tól a meglévő forrásokból. Az APT nem tudja, melyik VPN-t akarta, és a terve csomagokat távolíthat el, hogy kielégítse a talált megkötést. Olvassa el a javasolt tranzakciót, mielőtt igent mond, és álljon meg, ha az eltávolítások valami szükségeset érintenek. A javítás ismétlése a terv elolvasása nélkül az az út, amelyen egy kis függőségi résből olyan asztal lesz, amely már nem indul el.

Őrizze meg a csomagkezelő első értelmes üzenetét, és osztályozza, mielőtt cselekszik. Az aláírás nélküli tároló, a beállított forrásokban nem szereplő csomag, a verzióütközés és az elinduló, majd leálló kliens négy különböző hiba.

Az alkalmazást ellenőrizze, ne a tárolót

Erősítse meg, hogy a kliens elérte a telepített állapotot, majd azt, hogy a program elindul. A dpkg-query -W -f='${Status} ${Version}' proton-vpn-gnome-desktop parancsnak install ok installed állapotot kell jelentenie verzióval, az utána következő indítási hiba pedig alkalmazásprobléma, nem csomagolási hiba.

Rögzítse a tároló tulajdonosát és az alkalmazáscsomagot külön objektumként, hogy egy későbbi eltávolítás a megfelelőt vigye el, a másikat pedig érintetlenül hagyja. Amikor a szállító megváltoztatja az útmutatóját, a forrásbejegyzés az, amit újraolvas; a kliens neve az, amit újratelepít.