APT csomagkezelés

Csomagkezelésről általában

A csomagkezelés a Linux rendszerek egyik alapvető szolgáltatása. A különböző disztribúciók azonban ezen a területen más-más csomagformátumokat és segédprogramokat használnak, melyek egymással nem kompatibilisek. Példaképpen a RedHat által használatos RPM formátum és rpm vagy yum segédprogramok, és a Debian és Ubuntu által használt DEB formátum, és apt vagy dpkg programok hozhatók fel. Ebben az írásban ezen utóbbival fogunk foglalkozni.

Egy csomagkezelő rendszer általában a következő szolgáltatásokat nyújtja:

Repository-k (tároló) kezelése: A Linux csomagkezelés központi eleme a repository (tároló). Ez tartalmazza a különböző szoftvereket (csomagokat) és a hozzájuk tartozó információkat, melyek tárolása vagy távoli szervereken, vagy a helyi fájlrendszeren történik.
Függőségek kezelése: Az egyes csomagok egymástól függenek. Ha például szeretnénk felinstallálni a Midnight Commander fájlkezelőt, akkor ahhoz, hogy a biztonságos fájlkezelése is támogassa, fel kell installálnunk az OpenSSL-t. Vagyis a Midnight Commander függ az OpenSSL-től. A csomagkezelés lehetővé teszi ezeknek a függőségek automatikus kezelését. Amikor egy csomag telepítése vagy frissítése megtörténik, a csomagkezelő figyelembe veszi a szükséges függőségeket, és azokat szintén telepíti vagy frissíti, hogy a szoftverek helyesen működjenek.
Telepítés, frissítés és eltávolítás: A csomagkezelők olyan segédprogramot tartalmaz, melyek lehetővé teszi a csomagok telepítését, frissítését és eltávolítását.
Csomagok verziókezelése: A csomagkezelő lehetővé teszi a csomagok verzióinak kezelését, ezen belül az egyes verziók közötti váltást, a korábbi verziók helyreállítását.
Biztonság és hitelesség: A Linux csomagkezelése olyan beépített biztonsági mechanizmusokat tartalmaz, mint a csomagok hitelességének ellenőrzése digitális aláírások és titkosított csatornák használatával. Ezáltal megakadályozzák, hogy a nem biztonságos csatornákon keresztül felinstallált csomagok rosszindulatú szoftvereket terjesszenek.
Felhasználóbarát felület biztosítása: Habár a rendszergazdák általában karakteres felületen dolgoznak, a legtöbb Linux disztribúció a csomagkezeléshez rendelkezik grafikus felhasználói felülettel is.

A Debián és az Ubuntu csomagkezelési segédprogramjai

apt: Az apt (Advanced Package Tool) az egyik legelterjedtebb segédprogram, ami csomagkezelési szolgáltatásokat nyújt. Legfontosabb feladatai közé tartozik a távoli csomagtárolókkal való kapcsolattartás és a csomagok kezelése. A tárolókból információkat képes lehívni, amelyeket a helyi rendszeren gyorstáraz, valamint ellátja a csomagok felinstallálását, frissítését, törlését. (A korábbi rendszereken az apt feladtait az apt-get látta el. A visszafelé kompatibilitás miatt ez a parancs is elérhető maradt.)

apt-cache: Az apt-cache segítségével a helyi gyorstárból lehet a rendelkezésre álló csomagokról információkat lekérni. Ilyen információk lehetnek a csomagok közötti függőségek, egy csomag feladatának, vagy egy adott funkciót ellátó csomag nevének lekérése.

dpkg: A dpkg programmal az egyes DEB formátumú csomagokat tudjuk kezelni. Amíg az apt a csomagok közötti függőségeket is látja, a dpkg az egyes csomagokkal foglalkozik, de azokkal akár a belső szerkezetük szintjén. Amíg az apt a repository-kat is kezeli, addig a dpkg nem látja a tárolókat. Ezért mondjuk, hogy a dpkg egy alacsonyabb szintű csomagkezelő, mint az apt.

A helyi csomag-gyorstár frissítése

A távoli repository-kat az adott disztribúció vagy tároló kezelői folyamatosan frissítik. A csomagkezelő segédprogramok azonban mindig a helyi csomag-gyorstár adatai alapján dolgoznak, ezért fontos, hogy a távoli tárolók alapján a helyi gyorstárat frissítsük. Erre szolgál az apt update parancs:

root@server2:~# apt update

Hit:1 http://hu.archive.ubuntu.com/ubuntu kinetic InRelease
...
Get:17 http://hu.archive.ubuntu.com/ubuntu kinetic-security/universe amd64 c-n-f Metadata [8,640 B]
Fetched 1,901 kB in 1s (3,273 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
49 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: https://download.docker.com/linux/ubuntu/dists/focal/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

A parancs kimenetében láthatjuk azokat a tárolókat (Get:1-Get:17), amelyeket sikeresen elért. (A Hit azt jelenti, hogy a repository-ról már a legújabb információ van gyorstárazva, míg a Get esetén frissíteni kellett azt.) Láthatjuk, hogy letöltötte a csomaglistát (Reading package lists), meghatározta a függőségeket (Building dependency tree), és beolvasta az állapotinformációkat (Reading state information). (Ilyen állapotinformáció, hogy egy csomag például frissítendő, eltávolítandó, stb.) Az összes letöltött információ mennyisége és a letöltés sebessége is megjelenik (Fetched..). Láthatjuk, hogy 49 csomag frissíthető (a frissítés még nem történt meg!). Az apt update kimenetének utolsó sorában (W:) arról kapunk egy figyelmeztetést, hogy a docker csomag kulcsának kezelése nem felel meg a korszerű követelményeknek. A frissítendő csomagokról a list –upgradable paranccsal kérhetünk le információt:

root@server2:~# apt list --upgradable

Listing... Done
bind9-dnsutils/kinetic-updates,kinetic-security 1:9.18.12-0ubuntu0.22.10.2 amd64 [upgradable from: 1:9.18.4-2ubuntu2.1]
bind9-host/kinetic-updates,kinetic-security 1:9.18.12-0ubuntu0.22.10.2 amd64 [upgradable from: 1:9.18.4-2ubuntu2.1]
bind9-libs/kinetic-updates,kinetic-security 1:9.18.12-0ubuntu0.22.10.2 amd64 [upgradable from: 1:9.18.4-2ubuntu2.1]
...

Ha azt tapasztaljuk, hogy egy csomagot nem érünk el, először mindig a gyorstár frissítésével próbálkozzunk.

Valamennyi csomag frissítése

Miután frissítettük a gyorstárat, frissíthetjük a már felinstallált csomagokat, melyre több módszer is létezik. Amennyiben a teljes rendszer valamennyi csomagját frissíteni szeretnénk, az upgrade és a full-upgrade parancsokat használhatjuk. (Az egyes csomagok frissítését később nézzük.) A két parancs működése között az az alapvető különbség, hogy az upgrade használata esetén a frissítés közben egyetlen más program sem kerül eltávolításra, míg a full-upgrade esetén, amennyiben szükséges, igen. Tegyük fel, hogy a korábban említett Midnight Comamnder-t úgy modósítják, hogy már nem az OpenSSL-t használja, hanem egy másik hasonló funkciókkal rendelkező csomagot. (És azt is tegyük fel, hogy az OpenSSL-re ezután senkinek nem lesz szüksége, vagyis nincsen függőségben egyetlen más csomaggal sem.) A full-upgrade ilyenkor eltávolítja az OpenSSL-t, telepíti a szükséges új csomagokat, és frissíti a Midnight Commander-t. Az upgrade viszont alapértelmezetten nem hajtja végre a más csomagok eltávolításával járó frissítéseket.

Meg kell jegyezni, hogy mind az upgrade mind a full-upgrade használata után az addig jól működő rendszerünkben akár problémák is felléphetnek, mert ugyan az egyes csomagok frissülnek, de ez nem azt jelenti hogy az egymással együttműködő szolgáltatások is zökkenőmentesen dolgoznak együtt tovább. (Éles rendszeren érdemes a gyorstár információinak frissítése után lekérni a frissítendő csomagok listáját a korábban látott módon, és a kritikusabb szolgáltatások esetén utánanézni, milyen változásokat eszközöltek a frissítésük során.)

apt upgrade
apt full-upgrade

Ha kiadjuk ezt a parancsot, az alábbihoz hasonló kimenetet kapunk:

root@server2:~# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libcamera0 raspi-config rpi-eeprom
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,854 kB of archives.
After this operation, 1,712 kB of additional disk space will be used.
Do you want to continue? [Y/n]

A megjelenő információk hasonlóak az update parancsnál tárgyaltakra. Láthatjuk hány csomagot kell frissíteni, installálni, eltávolítani, illetve hánynak a frissítése lesz kihagyva. Leolvashatjuk, mekkora adatmennyiséget tölt le a parancs, és mekkora helyre lesz szüksége a frissítések telepítéséhez.

Ezek a parancsok számos opcióval rendelkeznek. Nézzünk pár gyakran használtat:

-y: A frissítés közben minden feltett kérdésre automatikusan igennel (yes) válaszol. Különösen alkalmas ez, ha valamilyen szkript indítja el a frissítést, hiszen akkor nem mindig vagyunk jelen kezelni a billentyűzetet.
–no-download: Új csomagokat nem tölt le a frissítés közben. Azoknál a programoknál, amelyekhez új csomag telepítése szükséges, átugorja a frissítést. (Ez azért hasznos, mert ha új csomag kerül a gépre, arról érdemes előtte tájékozódni, mire szolgál, milyen konfigurációt igényel.)
-s: Szimulációs módban frissít, vagyis végigcsinálja a frissítés minden lépését, de egyetlen csomagot sem változtat meg a rendszerben. (Ezt a kapcsolót még a –simulate és a –dry-run néven is elérjük.) Ilyenkor a parancs kimenetéből számos információt megkapunk a frissítésre vonatkozólag anélkül, hogy a rendszer megváltozna.

Felmerülhet a kérdés, hogyan lehet elkerülni azt, hogy egyes csomagok frissítésre kerüljenek? A későbbiekben látni fogjuk, hogy minden csomagnak van állapota, ezek közül az egyik a Version Hold (verzió tartás). Ebben az állapotban a csomag nem kerül frissítésre. Tartás állapotba egy csomagot az apt-hold paranccsal teszünk, míg innen az apt-mark unhold paranccsal veszünk ki:

apt-mark hold csomag-név
apt-mark unhold csomag-név

Egyedi csomagok installálása, frissítése

Amennyiben csak egyetlen csomagot szeretnénk frissíteni, az install parancsot alkalmazzuk. Ez a parancs, amennyiben a csomag még nincsen telepítve, akkor feltelepíti, ha pedig már fent van a rendszeren és van frissebb verziója, frissíti.

apt install csomag-neve

Ha csak szimulálni szeretnénk a csomag installálását (vagy frissítését), a korábban említett -s kapcsolót használhatjuk:

apt install -s csomag-neve

Az install parancs után több csomag nevét is megadhatjuk szóközzel elválasztva. Ha csak frissíteni szeretnénk, használjuk a –only-upgrade kapcsolót. (Ilyenkor ha nincsen még telepítve, nem telepíti.)

apt install --only-upgrade csomag-neve

Itt is használhatjuk a korábban megismert kapcsolókat. Amennyiben szeretnénk megnézni a telepítés után, hogy hol találjuk magát a telepített programot, használhatjuk a which parancsot, mely megmutatja a parancs elérési útvonalát. (A későbbiekben látni fogjuk, hogy a csomaghoz tartozó valamennyi fájl is kilistázható.)

root@server2:~$ which mc
/usr/bin/mc

Arra is van lehetőség, hogy egy csomag egy bizonyos verzióját kérjük le a csomagtárolóból. Ehhez először meg kell határozni, hogy milyen verziók állnak rendelkezésre. Ezt a helyi gyorstárból kérjük le. Erre szolgál az apt-cache parancs. (Persze, hogy ez a valóságot mutassa, le kell futtatni egy update-et.)

root@server2:~# apt-cache policy apache2
apache2:
  Installed: 2.4.54-2ubuntu1.3
  Candidate: 2.4.54-2ubuntu1.3
  Version table:
 *** 2.4.54-2ubuntu1.3 500
        500 http://hu.archive.ubuntu.com/ubuntu kinetic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.4.54-2ubuntu1.2 500
        500 http://hu.archive.ubuntu.com/ubuntu kinetic-security/main amd64 Packages
     2.4.54-2ubuntu1 500
        500 http://hu.archive.ubuntu.com/ubuntu kinetic/main amd64 Packages

Jól látható, hogy a legfrissebb verzió van telepítve (az Installed és a Candidate sorban ugyanaz szerepel). A verziótáblázat (Version Table) mutatja, hogy melyik tárolókból a csomag melyik verziói érhetők el. (A *** jelzi, hogy melyik verzió honnan van éppen telepítve.) Ha mi telepítéskor a verziót is szeretnénk megadni, így kell kiadni a parancsot:

apt install apache2=2.4.54-2ubuntu1

Ügyeljünk arra, hogy az ilyen verzióváltás könnyen inkompatibilitási problémákhoz vezethet. (Érdemes először szimulált installálást végrehajtani.)

Amennyiben felinstallálunk egy csomagot, általában egy alapértelmezett konfigurációval kezdhetjük el használni. Némelyikük viszont egy olyan konfigurációs szkripttel érkezik, mely a csomag telepítése után automatikusan lefut, és interaktív beavatkozást is igényelhet, vagyis feltesz pár kérdést, melyeket meg kell válaszolnunk. Ha a későbbiekben ezt a konfigurációt újra ki szeretnénk kényszeríteni, használjuk a dpkg-reconfigure parancsot. A következő példában a tzdata programon kényszerítjük ki az újrakonfigurálást:

dpkg-reconfigure tzdata

Ha egy szoftverfejlesztő a programját közvetlenül .deb fájlban terjeszti, az felinstallálható a dpkg paranccsal. Vigyázzunk, ez nem kezeli a függőségeket, így ha vannak fel nem oldott függőségek, a program nem lesz használható. (A későbbiekben látjuk majd, hogy az ilyen függőségi problémák hogyan kezelhetők.) Egy ilyen .deb kiterjesztésű csomagot aztán a dpkg –install paranccsal installálhatunk fel.

dpkg --install csomag-nev.deb

A repository-ból is letölthetjük a csomagok .deb fájlját download paranccsal. A letöltött csomag a felhasználó home könyvtárába kerül.

apt download csomag-név

Telepített csomagok keresése

Az apt search paranccsal lehetőségünk van a csomagok között keresni. Keresük meg például a Midnight Commander-t:

root@server2:~# apt search "Midnight Commander"
Sorting... Done
Full Text Search... Done
...
mc/kinetic,now 3:4.8.28-1 amd64 [installed]
  Midnight Commander - a powerful file manager

mc-data/kinetic,now 3:4.8.28-1 all [installed,automatic]
  Midnight Commander - a powerful file manager -- data files
...

Láthatjuk, hogy nem csak a keresett csomagot írja ki, hanem minden olyan más csomagot is, amelyeknek leírásában megtalálta a keresett nevet.

Ha csak a csomagnevek között akarunk keresni, használjuk a -n kapcsolót:

Függőségi problémák kezelése

A csomagok futása más csomagoktól függnek. Ezek a csomagok pedig újabb csomagoktól. Amennyiben szép szabályosan minden csomagot az apt-vel kezelünk, a függőségek kezelése elvileg automatikusan megtörténik. De sajnos nem minden csomagot rakhatunk fel így, és ilyen helyzet fordulhat elő akkor is, ha egy csomag telepítése előre nem látható okból megszakad (pl. a számítógép tápellátása hirtelen leáll…) Sőt, arra az esetre most nem is gondoljunk, hogy ha programot fejlesztünk a rendszeren, vagy forráslistából fordítunk le programokat, akkor a forráskódban használt utasítások futása is függ felinstallált programkönyvtáraktól.
Az apt lehetőséget ad a -f kapcsolóval, hogy az esetleges sérült függőségeket megjavítsuk:

Ha minden rendben van, a parancs nem jelez hibát:

root@server2:~# apt install -f
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 49 not upgraded.

Amennyiben nem, akkor valami ilyesmi kimenetet kapunk:

root@server2:~# apt install -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  libexample1 libexample-dev
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libdependency
The following NEW packages will be installed:
  libdependency
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
4 not fully installed or removed.
Need to get 0 B/10 kB of archives.
After this operation, 100 kB of additional disk space will be used.
Do you want to continue? [Y/n]

A kimenetből kiolvasható, hogy egy csomagra nincsen szükség (libexample1 libexample-dev), egyet pedig telepíteni kell (libdependency).
Az apt elvégzi a telepítést, de a csomag eltávolítását már nekünk kell.

Ilyen függőségi problémát eredményez sok esetben a korábban látott dpkg –install parancs használata, hiszem az nem kezeli a függőségeket. A következő példában idézzünk elő egy ilyen hibát, majd orvosoljuk. Első lépésben töltsük le a nginx csomagot, majd telepítsük a dpkg-val, majd javítsuk ki a függőségi hibákat.

apt download nginx
dpkg --install nginx_1.22.0-1ubuntu1.1_amd64.deb
apt install -f

Csomagok eltávolítása

Amennyiben egy szolgáltatásra vagy programra nincsen már szükségünk, el tudjuk távolítanunk a rendszerből. Erre szolgálnak a remove és a purge parancsok. A kettő között az a különbség, hogy míg a remove csak a csomagot törli le (és a hozzá tartozó, más csomagoktól nem függő csomagokat), de érintetlenül hagyja a konfigurációs állományokat, addig a purge a konfigurációs állományokat is eltávolítja.

apt remove csomag-név
apt purge csomag-név

Amennyiben egy szabálytalanul megszakított csomagtelepítés (vagy éppen eltávolítás) után fölösleges csomagok maradnak a rendszerben, akkor ezt az autoremove paranccsal távolíthatjuk el. (Ezeket, ahogyan korábban láttuk, az apt install -f paranccsal deríthetjük fel.) Az autoremove sem távolítja el a konfigurációs állományokat, ha erre szükség van, akkor használjuk a –purge kapcsolót is.

apt autoremove
apt --purge autoremove

Ha már régóta használunk egy rendszert, előfordulhat, hogy olyan csomagok is maradnak letöltve a helyi adattárolón, amelyekre már nincsen szükség. Ezeket eltávolítva az autoclean paranccsal, tárhelyet szabadíthatunk fel.

apt autoclean

Információk gyűjtése a csomagokról

Ahogyan korábban láttuk, a csomaginformációk a helyi gépen a gyorstárban vannak eltárolva. A gyorstárat az apt-cache paranccsal kezelhetjük, és ezek az információk a show paranccsal kérdezhetők le:

apt-cache show csomag-név

ELég sok információt kapunk eredményül, nézzük meg ezek közül a fontosabbakat:

Package: Erről a csomagról kértünk le információkat (pl. apache2)
Architecture: Erre az architektúrára készült a csomag (pl. amd64)
Version: A csomag verziószáma
Priority: A csomag prioritása, amely megmutatja, mennyire fontos a csomag a rendszer szempontjából
Section: A csomag milyen kategóriába tartozik (Pl. web)
Origin: A csomag eredete (Pl. Ubuntu)
Maintainer: A csomag karbantartója (Pl. Ubuntu Developers)
Original-Maintainer: Az eredeti csomagkarbantartó (Pl. Debian Apache Maintainers)
Bugs: A csomaghoz tartozó hibajelentések linkje
Installed-Size: A csomag telepített mérete
Provides: A csomag által biztosított szolgáltatások
Pre-Depends: A csomag telepítése akkor lesz sikeres, ha ezek a csomagok már előre telepítve vannak.
Depends: A csomag működése akkor lesz sikeres, ha ezek a csomagok is telepítésre kerülnek.
Recommends: Ajánlott csomagok, amelyeket érdemes telepíteni a csomaghoz, hogy minden funkciója működjön
Suggests: Opcionális csomagok, amelyek hasznosak lehetnek a csomaggal kapcsolatban (pl. dokumentációk)
Filename: A csomag fájlneve és elérési útvonala a tárolóban
Size: A csomag mérete
MD5sum: A csomagfájl MD5 kivonata
SHA1: A csomagfájl SHA1 kivonata
SHA256: A csomagfájl SHA256 kivonata
SHA512: A csomagfájl SHA512 kivonata
Homepage: A csomaghoz kapcsolódó webhely
Description-en: A csomag funkcióinak rövid angol nyelvű leírása
Description-md5: A rövid ismertető MD5 kivonata
Task: A csomag ehhez a feladathoz van rendelve (pl. az apache2 a LAMP szerverhez)

Egy másik parancs, amellyel információkat tudunk lekérdezni a csomagról, a showpkg. Érdekessége az, hogy fordított függőségi listát ír ki, vagyis azt, hogy mely más csomagok függnek ettől a csomagtól:

apt-cache showpkg csomag-név

Amennyiben nem a helyi gyorstárból akarunk információkat lekérni, hanem közvetlenül a csomagfájlból, használjuk a dpkg –info parancsot. A parancsnak csomag teljes elérési útvonalát kell átadni:

root@server2:~# dpkg --info /var/cache/apt/archives/bind9-host_1%3a9.18.12-0ubuntu0.22.10.2_amd64.deb
 new Debian package, version 2.0.
 size 50684 bytes: control archive=641 bytes.
     637 bytes,    17 lines      control
     179 bytes,     3 lines      md5sums
 Package: bind9-host
 Source: bind9
 Version: 1:9.18.12-0ubuntu0.22.10.2
 Architecture: amd64
 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
 Installed-Size: 182
 Depends: bind9-libs (= 1:9.18.12-0ubuntu0.22.10.2), libc6 (>= 2.34), libidn2-0 (>= 2.0.0)
 Breaks: bind-host (<< 1:9.13.6~)
 Replaces: bind-host (<< 1:9.13.6~)
 Provides: host
 Section: net
 Priority: standard
 Homepage: https://www.isc.org/downloads/bind/
 Description: DNS Lookup Utility
  This package provides the 'host' DNS lookup utility in the form that
  is bundled with the BIND 9 sources.
 Original-Maintainer: Debian DNS Team <team+dns@tracker.debian.org>

Az előzőek fényében már nem okozhat gondot a kiírt információk értelmezése.

Egy csomag függőségeit közvetlenül is lekérhetjük a gyorstárból:

root@server2:~# apt-cache depends apache2
apache2
  PreDepends: ...
  Depends: ...
  Recommends: ...
  Suggests: ...

A parancs négy szakaszba sorolja függőségeket. A PreDepends szakaszban felsoroltak már a csomag felinstallálásához szükségesek, a Depends-ben láthatók a működéséhez kellenek, a Recommends szakasz csomagjait csak ajánlott telepíteni, hogy minden funkciót ki tudjunk használni, míg a Suggest szakaszban olyan csomagok találhatók, amelyek noha nem szükségesek a használatához, de hasznosak (például a dokumentáció).

Az rdepends paranccsal az inverz függőségi lista is lekérdezhető (vagyis mely csomagok függnek ettől). Az inverz függőségi lista nagyon hasznos akkor, ha el akarunk távolítani egy csomagot, de előtte meg akarunk győződni arról, mely más csomagok akarják használni.

root@server2:~# apt-cache rdepends apache2

Ha valamennyi telepített csomag listájára van szükségünk, ismét a dpkg parancsot kell használnunk:

server2# dpkg -l
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                  Version                                  Architecture Description
+++-=====================================-========================================-============-================================================================================
ii  adduser                               3.121ubuntu1                             all          add and remove users and groups
ii  amd64-microcode                       3.20220411.1ubuntu3                      amd64        Processor microcode firmware for AMD CPUs
ii  apparmor                              3.0.7-1ubuntu2                           amd64        user-space parser utility for AppArmor
ii  apport                                2.23.1-0ubuntu3.2                        all          automatically generate crash reports for debugging
ii  apport-symptoms                       0.24                                     all          symptom scripts for apport
...

A parancs kimenetéből számos információ kiolvasható: A csomag neve (Name), verziója (Version) mellett, láthatjuk, hogy milyen rendszeren futtatható (Architecture) és a egy rövid leírása (Description). A név előtt 2 vagy 3 betűkódot látunk, melyből az első az, hogy mi a csomag kívánt (Desired) állapota (u=ismeretlen, i=installált, r=eltávolítás, p=törlés a konfigurációs állományokkal, h=tartás, nem akarjuk módosítani). A második betűkód az aktív (Status) állapot (n=nincs telepítve vagy eltávolítva, i=telepítve van, c=a csomag nincsen telepítve, de jelen van a konfigurációs állománya, u=a csomag már kibontásra került, de még nincsen konfigurálva, f=a csomag részben konfigurálva van, h=a csomag részben telepítve van, w=a csomag eseményre vár, t=a csomag eseményének végrehajtása várakozás alatt van.) A harmadik kód (Error) csak akkor jelenik meg, ha valamilyen hiba történt. Az R betű ilyenkor az újratelepítését szükségességét jelzi.

Természetesen ha nem az összes csomag státuszára vagyunk kíváncsiak, megadhatjuk a keresett csomagnevet:

server2# dpkg -l cron
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version           Architecture Description
+++-==============-=================-============-=================================
ii  cron           3.0pl1-137ubuntu3 amd64        process scheduling daemon

Van egy másik lehetőség az installált (illetve eltávolított de nem letörölt (=purged)) csomagok listázására. Ennek a parancsnak a kimenetén kevesebb információ jelenik meg, de néha a kevesebb több, mert átláthatóbb.

server2# dpkg --get-selections
adduser                                         install
amd64-microcode                                 install
apparmor                                        install

Egy egyszerű átirányítással leválogathatjuk az installált és a remove-val törölt (tehát a konfigurációs fájljai még megvannak):

root@server2:~# dpkg --get-selections | awk '$2 ~ /^install/'
adduser                                         install
amd64-microcode                                 install
apparmor                                        install

root@server2:~# dpkg --get-selections | awk '$2 !~ /^install/'
linux-image-5.19.0-38-generic                   deinstall
linux-image-5.19.0-40-generic                   deinstall
linux-image-5.19.0-41-generic                   deinstall

Mindkét parancs azonos elven működik: A dpkg kimenetének első oszlopában a csomagok neve, második oszlopában az állapota jelenik meg. Ennek a parancs kimenete van átirányítva az awk-nak a | (pipe) karakterrel. Az awk egy adatelemző program, amely itt a kimenet 2. oszlopát ($2) kiemeli, és ráilleszti a /^install/ reguláris kifejezést. Ez a kifejezés akkor illeszkedik, ha a szöveg elején megtalálja az install karaktersorozatot. Az első parancsban azokat a sorokat adja vissza, ahol ez illeszkedik (~), a másodikban azokat, ahol ez nem illeszkedik (!~).

Természetesen egyetlen csomag állapota is lekérdezhető:

root@server2:~# dpkg --get-selections mc
mc                                              install

Egy csomag felinstallálásával nagyszámú fájl kerülhet fel a rendszerre. Ezek kilistázása a -L kapcsolóval lehetséges:

root@server2:~# dpkg -L mc
/.
/etc
/etc/mc
/etc/mc/edit.indent.rc
/etc/mc/filehighlight.ini
/etc/mc/mc.default.keymap
...

A -S kapcsolóval fordítva is lekérdezhetjük ezt az információt, tehát egy adott fájlról megállapíthatjuk, melyik csomaghoz tartozik:

root@server2:~# dpkg -S /etc/mc/edit.indent.rc
mc: /etc/mc/edit.indent.rc

A dpkg csak a felinstallált csomagok információit tudja lekérni. Van azonban egy apt-file nevű program, amely saját adatbázist tart fent (amit frissíteni kell), és innen tud információkat lekérni. Az update paranccsal lehet frissíteni az adatbázisát, a list paranccsal lehet kilistázni a hozzátartozó fájlokat (akkor is ha a csomag nincsen telepítve), és a search paranccsal lehet egy fájlról lekérdezni, melyik csomaghoz tartozik. Ez utóbbi akkor is működik, ha a csomagot már eltávolították, de bizonyos fájljai a rendszeren maradtak. (Fontos, hogy ez csak azokra a fájlokra tud rákeresni, amelyeket a program nem a telepítése után hozott létre, hiszen azok nincsenek bent az adatbázsiban.)

apt update
apt install apt-file

apt-file update
apt-file list csomag-név
apt-file search /path/to/file

A csomagtárolók (repository-k) kezelése

Mint korábban olvastuk, a csomagokat az Interneten csomagtárakban (repository-kban) gyűjtik össze. Az itt található csomagokat külső vagy belső fejlesztői csapatok fejlesztik, ellenőrzik, karbantartják. Amikor egy csomag bekerül egy repository-ba, akkor ha magában a tárolóban (a mögöttük álló csapatban) megbízunk, akkor a csomagban is megbízhatunk. A disztibúciókhoz tartozó hivatalos tárolók általában megbízhatók, elektronikus aláírásukkal hitelesítik. (A tárolók biztonságáról később még részletesen szó lesz.) De nem minden tároló ilyen! A tárolóknak van azonban nem az egyes disztibúciók által karbantartott típusa, a PPA-k (Personal Package Archives) melyek mögött a közvetlenül a fejlesztők állhatnak. A biztonság szempontjából nagyon körültekintően kell eljárnunk, amikor egy tárolót hozzáadunk majd a rendszerünkhöz, hiszen ha elfogadunk egy tárolót, akkor a benne található csomagokat is elfogadjuk. Meg kell jegyezni, hogy csomagokat nem csak tárolókból, hanem közvetlenül a fejlesztői oldalról is lekérhetők, de ennek biztonságáról is majd később.

Kezdjük először a hivatalos, disztribúciókhoz köthető tárolókkal: Amikor felinstallálunk egy Linux disztribúciót, szinte mindig kapunk előre konfigurálva egy repository listát, amelyekből új csomagok telepítése, és a meglévők frissítése történhet. Az alapértelmezett repository listája a /ect/apt/sources.list fájlban található. A későbbiek során ha új repository-t adunk a rendszerhez, azt vagy ennek a fájlnak a bővítésével tehetjük meg, vagy a /etc/apt/sources.list.d könyvtárba helyezünk el mindegyikről egy-egy különálló fájlt.

A /etc/apt/sources.list.d könyvtár tartalma:

root@server2:~# ls -l /etc/apt/sources.list.d
total 16
-rw-r--r-- 1 root root 148 Jun 29 19:55 archive_uri-https_download_docker_com_linux_ubuntu-kinetic.list

Ennek a fájlnak a tartalma:

root@server2:~# cat /etc/apt/sources.list.d/archive_uri-https_download_docker_com_linux_ubuntu-kinetic.list
deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable
# deb-src [arch=amd64] https://download.docker.com/linux/ubuntu focal stable

Míg a /ect/apt/sources.list fájl tartalma (részben):

root@server2:~# cat /etc/apt/sources.list
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://hu.archive.ubuntu.com/ubuntu kinetic main restricted
# deb-src http://hu.archive.ubuntu.com/ubuntu kinetic main restricted
...

Látható, habár más-más tárolót írnak le ezek a bejegyzések, a formátumuk azonos:

deb http://hu.archive.ubuntu.com/ubuntu kinetic main restricted

A deb a bináris formátumú csomagokat jelenti (lehetne még deb-src, ami a forráskódú csomagokra utal), a link a csomagok elérésének az URL-je, míg a kinetic a disztibúció kódneve (a verziót azonosítja). Az utolsó két kulcsszó arra utal, hogy a tároló milyen típusú csomagokat tartalmaz. Négy alapvető típust különböztetünk meg:

main: Az Ubuntu hivatalosan támogatott és karbantartott szabadon felhasználható szoftvereit tartalmazza.
restricted: Olyan korlátozott licenszű vagy zárt forráskódú szoftverek, amelyek használatához speciális engedély szükséges. Ilyenek lehetnek például bizonyos hardverillesztők és multimédiás kodekek.
universe: Ezek a csomagok szintén nyílt forráskódúak és szabadon felhasználhatóak, de nem részei az Ubuntu hivatalos támogatásának. Az Ubuntu közösség tagjai által fejlesztett és karbantartott, szabadon felhasználható projektek találhatók itt.
multiverse: Olyan szoftvereket tartalmaz, amelyek nem felelnek meg a szabad szoftver definícióinak. (Például zárt forráskódúak, vagy bizonyos jogi korlátozásokkal rendelkeznek.)

A tárolók kezelésére az add-apt-repository parancsot használhatjuk. (Nevével ellentétben nem csak tároló hozzáadására való.) Ha nem találjuk meg ezt a parancsot a rendszeren, telepítsük fel a software-properties-common csomagot.

Ha a rendszerünkhöz új tárolót adunk, akkor mindenképpen ügyelni kell arra, hogy a tárolóból származó csomagok telepítése biztonságosan történjen. Ez egy elég összetett feladatkör, de minimálisan meg kell tennünk, hogy a tároló nyilvános kulcsát be kell importálnunk a rendszerünkbe. Ezzel a kulccsal tudjuk majd a tároló üzemeltetőjének elektronikus aláírását leellenőrizni. Tehát nem csak a tárolót kell megkeresnünk, hanem a kulcsát is! A következő példában a Webmin webes adminisztrációs felület fejlesztőinek tárolóját adjuk a rendszerünkhöz:

Töltsük le első lépésben a tároló nyilvános kulcsát, és adjuk a rendszerhez:

wget -qO- https://download.webmin.com/jcameron-key.asc | tee -a /etc/apt/trusted.gpg.d/jcameron-key.asc

A fenti parancs letölti a megadott url-ről a kulcsot tartalmazó fájlt úgy, hogy közben nem ír ki semmit a kimenetre (-q), és a letöltött fájlt nem fájlként tárolja (-O), hanem átirányítja a tee parancshoz, amely kulcskönyvtárba menti a kulcsfájlt. (A kulcsok kezeléséről a következő fejezetben még részletesen szó lesz.)

Ezután adjuk a tárolót is a hozzá:

add-apt-repository "deb [arch=amd64] http://download.webmin.com/download/repository sarge contrib"

Most már felinstallálhatjuk a csomagot. Az apt a rendelkezésre álló kulccsal automatikusan leellenőrzi az aláírást:

apt install webmin

Ahogy korábban olvastuk, a hivatalos tárolók mellett úgynevezett PPA-k (personal package archives) használatára is lehetőség van. Ha ilyen PPA-kat adunk a rendszerünkhöz, az azokban található csomagokat a szokásos segédprogramokkal tudjuk kezelni. Viszont nagyon fontos arra figyelni, hogy csak megbízható csomagok kerülhetnek be ezekbe a PPA-kba.

Egy PPA-t szintén az add-repository paranccsal tudunk a rendszerünkhöz rendelni a következő formában:

add-apt-repository ppa:owner_name/ppa_name

Az alábbi példában az Ansible csomag PPA tárolóját adjuk a rendszerhez. (Az Ansible egy nyílt forráskódú konfigurációkezelő és automatizálási eszköz, amelyet rendszerek konfigurálására, telepítésére, telepített szoftverek karbantartására és infrastruktúra automatizálására használnak.) Mielőtt az ansible PPA-ját hozzáadnánk, nézzük meg, hogy máshonnan elérhető lenne-e a csomag:

root@server2:~# apt policy ansible
ansible:
  Installed: (none)
  Candidate: 5.5.0-1
  Version table:
     5.5.0-1 500
        500 http://hu.archive.ubuntu.com/ubuntu kinetic/universe amd64 Packages

Azt látjuk, hogy igen, az Ubuntu egyik tárolójából az 5.5.0-1 verzió érhető el. Adjuk most hozzá a fejlesztők PPA-ját:

add-apt-repository PPA:ansible/ansible

Nézzük meg, hogy a tároló megjelent a többi között:

root@server2:~# apt-cache policy | grep ansible
 500 https://ppa.launchpadcontent.net/ansible/ansible/ubuntu kinetic/main amd64 Packages
     release v=22.10,o=LP-PPA-ansible-ansible,a=kinetic,n=kinetic,l=ansible,c=main,b=amd64

És most nézzük meg, hogy a csomag melyik tárolókból érhető el így:

root@server2:~# apt policy ansible
ansible:
  Installed: (none)
  Candidate: 7.7.0-1ppa~kinetic
  Version table:
     7.7.0-1ppa~kinetic 500
        500 https://ppa.launchpadcontent.net/ansible/ansible/ubuntu kinetic/main amd64 Packages
     5.5.0-1 500
        500 http://hu.archive.ubuntu.com/ubuntu kinetic/universe amd64 Packages

Látható, hogy most már a PPA-n keresztül egy sokkal frissebb verzió érhető el. Installáljuk fel a programot:

root@server2:~# apt install ansible

Majd nézzük meg azt, melyik csomagból került fel az ansible. Láthatjuk, a PPA verziója került a rendszerbe:

root@server2:~# dpkg -s ansible
...
Version: 7.7.0-1ppa~kinetic
...

Ugyanezt az információt a PPA-val együtt az apt-cache-ből is lekérdezhetjük:

root@server2:~# apt-cache policy ansible
ansible:
  Installed: 7.7.0-1ppa~kinetic
  Candidate: 7.7.0-1ppa~kinetic
  Version table:
 *** 7.7.0-1ppa~kinetic 500
        500 https://ppa.launchpadcontent.net/ansible/ansible/ubuntu kinetic/main amd64 Packages
        100 /var/lib/dpkg/status
     5.5.0-1 500
        500 http://hu.archive.ubuntu.com/ubuntu kinetic/universe amd64 Packages

A PPA kulcsa itt automatikusan bekerült az apt kulcstárolójába:

root@Linux2:~# apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg.d/ansible-ubuntu-ansible.gpg
-------------------------------------------------
pub   rsa4096 2014-06-10 [SC]
      6125 E2A8 C77F 2818 FB7B  D15B 93C4 A3FD 7BB9 C367
uid           [ unknown] Launchpad PPA for Ansible, Inc.

Arra is lehetősg van, hogy az add-apt-repository parancs helyett a PPA tárolót közvetlenül egy saját repository listában helyezzük el a rendszerben. Ehhez létre kell hozni egy ppa_ansible.list fájlt (a neve tetszőleges) a /etc/apt/sources.list.d könyvtárban, majd el kell benne helyezni a PPA-ra hivatkozó sort:

nano /etc/apt/sources.list.d/ppa_ansible.list

deb https://ppa.launchpadcontent.net/ansible/ansible/ubuntu/ jammy main

A sorok egyes részeinek jelentése nagyon hasonlít a korábban megismerthez:

deb: Debián formátumú bináris
https://ppa.launchpadcontent.net: A repository-hoz vezető url
ansible: ez az entitás hozta létre a PPA-t
ansible: a PPA neve
jammy: az Ubuntu verziójának kódja
main: hivatalosan támogatott és karbantartott kód

Ügyeljünk arra, hogy ha így manuálisan helyezzük el a PPA elérhetőségét a sources.list.d könyvtárba, akkor az apt update parancsot mindenképpen futtassuk le, hogy az apt felismerje az új forrást! Ne feledkezzünk el a kulcs installálásáról is!

A tárolók eltávolítása ugyan ilyen egyszerű, csak a remove opciót kell használni. Távolítsuk el az előző PPA-t:

add-apt-repository --remove ppa:ansible/ansible

A csomagkezelés biztonsága

Mindenki, aki már bármilyen szoftveres rendszer építésével foglalkozott, szembetalálkozott azzal a figyelmeztetéssel, hogy csak megbízható forrásból szabad programokat letölteni és installálni. A csomagkezelésben ezt az ellenőrző összegek és az elektronikus aláírás használata biztosítja.

Az ellenőrző összeg egy adott fájl tartalmának egyértelmű kivonata. Egy megfelelő matematikai algoritmussal a fájlból egy sokkal rövidebb számsorozatot (karaktersorozatot) generálnak. Ez a karaktersorozat aztán egyértelműen azonosítja a fájlt. (Mint egy embert az ujjlenyomata.) A kivonatkészítésnek sok módja van, ha visszalapozunk az apt-cache show parancs kimenetéhez, ott MD5, SHA1, SHA256, SHA512 módszerrel generált kivonatokat láthatunk. Ha bármikor letöltenek egy csomagot, helyileg kiszámolják a kivonatát, és összehasonlítják a tárolóban található kivonatával. Ha a kettő megegyezik, akkor az eredeti fájllal dolgozunk, ha nem, akkor valahol megváltozott. (Ezt nevezzük integritásvédelemnek.) Persze valahogy biztosítani kell, hogy az eredeti kivonattal hasonlítsuk össze. (Tehát egy nem megbízható helyről letöltött csomag mellett látható kivonata is lehet megbízhatatlan.) Az alábbi példában az Midnight Commander csomagjának ellenőrző összegei láthatók:

root@server2:~# apt-cache show mc
...
MD5sum: a2c099b15f934bd1e00c749e3c833904
SHA1: c1c360d19991830f6fe178dc1f4b9303b950e10e
SHA256: 2291dcca93389c92bb86e1547b58151ecd95fddf3d12adbabb4b3ecb97b77536
SHA512: b7da732d8bead4be4f63d840a78bc0d93849f744cf8dd456d3d341b6b926e49070a39d7bb23d8f1da5d7e6ee7d96ebde82b59c682a297340e94d3f277a3139f5
...

Hol tárolódnak ezek az ellenőrző összegek? Minden repository-nak van egy release fájl-ja, amely többek között a tárolóban található csomagok listája mellett, a csomagok ellenőrzőösszegeit is tartalmazza. Ha ezt a fájlt egy frissítés során nem találja az apt, akkor nem képes leellenőrizni, hogy a letöltött csomagok ellenőrzőösszege megváltozott-e az eredetihez képest, így a release fájlok megléte elsődleges fontosságú.

A következő probléma az, hogy vajon hinnünk kell-e a release fájlban tárolt információknak? Itt jön képbe az elektronikus aláírás.

Az elektronikus aláírás a publikus kulcsú rendszernek (PKI) egyik fontos technikája. Részletekbe menő ismertetése túlmutat ezen cikk keretein (az oldalon számos bejegyzés foglalkozik vele). Ami számunkra fontos, hogy a release fájl terjesztője (aki jelen esetben az Ubuntu csomagtárolóinak karbantartója) rendelkezik egy titkos és egy publikus kulccsal. A titkos kulcsára nagyon vigyáz, a publikusat viszont szabadon elérhetővé teszi. A titkos kulcsának felhasználásával aláírja a fájlt. Ezt az aláírást csak ő képes létrehozni, hiszen a titkos kulcsával csak saját maga rendelkezik. Amikor ezt az aláírt release fájlt letöltjük, az apt automatikusan letölti hozzá az aláírást is általában a release.gpg fájlban. Ezt az aláírást az aláírás készítőjének a nyilvános kulcsával ellenőrizhetjük le. De honnan jutunk hozzá ehhez a nyilvános kulcshoz? Az Ubuntu installálásakor automatikusan telepítésre kerül az ubuntu-keyring.deb csomag, mely ilyen nyilvános kulcsokat tartalmaz.

root@server2:~# apt-cache show ubuntu-keyring | grep Description-en
Description-en: GnuPG keys of the Ubuntu archive

Ezek szerint a csomagok ellenőrző összege a release fájlban van, ez hitelesítve van elektronikus aláírással, az aláírást a release.gpg tartalmazza, melyet az ubuntu-keyring.deb csomagban található nyilvános kulccsal tudunk leellenőrizni. Ha az ellenőrzés sikeres, megbízhatunk az ellenőrzőösszegek valódiságában, így azokkal ellenőrizni tudjuk a csomagok integritását.

A csomagok ellenőrző összege ezek szerint már hitelesített, és megfelelő védelmet nyújt a csomagok megváltoztatása ellen. Hiszen ha valaki megváltoztatja a csomag tartalmát, változik az ellenőrzőösszeg, és a release fájlban található ellenőrzőösszeggel nem lesz egyenlő. A release fájlt meg ugye nem lehet módosítani észrevétlenül az elektronikus aláírás miatt.

Maguk a csomagok azonban rendelkeznek egy másik védelmi vonallal azáltal, hogy maguk a csomagok is alá vannak írva elektronikusan. Ez az aláírás általában a csomag nevével megegyező .sig fájlban, míg az aláírást ellenőrző nyilvános kulcs általában egy .asc kiterjesztéssel ellátott fájlban van tárolva. (De a hivatalos tárolók csomagjai aláírást ellenőrző kulcsok ahogy láttuk a rendszer telepítésekor felkerülnek az előzőek szerint.) Az aláírás ellenőrzése teljesen automatikus. Ha viszont más tárolóból töltünk le csomagot, ott lehet, hogy ezt az ellenőrzést manuálisan kell megtennünk.

Az Ubuntu csomagtárolóiban található csomagok általában a csomagkarbantartók, vagy a Canonical Ltd. cég (mely az Ubuntu alapítójának a cége) elektronikus aláírásával rendelkeznek. Az elektronikus aláírás ellenőrzését az APT a gpg (OpenGPG) programra bízza.

Az apt-key paranccsal tudjuk ezeket a kulcskarikákat, és így a kulcsokat kezelni. Például listázzuk ki a kulcsokat az apt-key list paranccsal. (Vegyük észre, hogy a parancs figyelmeztet arra, hogy a kulcsok apt-key-jel való kezelése már nem támogatott. (Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).) Ennek az üzenetnek a háttere a következő: A korábbi Ubuntu verziókban (Ubuntu 20.04 előtt) a rendszer által által használt nyilvános kulcsok a /etc/apt/trusted.gpg fájlban voltak egyben tárolva. Ez azzal biztonsági kockázattal jár, hogy ha telepítettünk egy csomagot, amely aláíráshoz tartozó csomag vagy tároló nyilvános kulcsa bekerült ebbe a fájlba, azt a kulcsot az apt nem csak ehhez a csomaghoz, hanem a többihez is használhatta, mindegyikhez megbízhatónak tekintette. Az apt áttért arra, hogy ezután ezeket a kulcsokat külön-külön a /etc/apt/trusted.gpg.d könyvtárban tárolja, és így sokkal rugalmasabban és kontrollálhatóbb módon lehet az egyes kulcsokat tárolókhoz rendelni. Ha csak a könyvtárat látjuk, akkor a használt disztribúciónk már nem is támogatja a régi módszert. (Hasonlít ez a csomagtárolókhoz: Régen mindegyik elérhetőségét a /etc/apt/sources.list fájlban tároltuk, de most már a /etc/apt/sources.list.d könyvtárban külön-külön.) Nézzük meg a trusted.gpg.d könyvtár tartalmát:

root@server2:~# ls -l /etc/apt/trusted.gpg.d
total 8
-rw-r--r-- 1 root root 2794 Mar 26  2021 ubuntu-keyring-2012-cdimage.gpg
-rw-r--r-- 1 root root 1733 Mar 26  2021 ubuntu-keyring-2018-archive.gpg

Noha az apt-key parancs kivezetésre kerül a későbbiekben, még használhatjuk a kulcsok lekérdezésére. A parancs kimenetének látható, hogy két kulcsot talált a rendszeren. Ezeket a kulcsokat már a /etc/apt/trusted.gpg.d könyvtárból veszi.

root@server2:~# apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg
------------------------------------------------------
pub   rsa4096 2012-05-11 [SC]
      8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid           [ unknown] Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>

/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
------------------------------------------------------
pub   rsa4096 2018-09-17 [SC]
      F6EC B376 2474 EDA9 D21B  7022 8719 20D1 991B C93C
uid           [ unknown] Ubuntu Archive Automatic Signing Key (2018) <ftpmaster@ubuntu.com>

Látható a könyvtárban tárolt két kulcs. Mind a kettő publikus (Hát persze, a titkos kulcsokat titokban tartják a csomagkezelők.) Mindkettő RSA4196 típusú, láthatjuk a létrehozásuk dátumát és az azonosítójukat, mire szolgál, és annak az email címét, aki karbantartja.

Ezeket a kulcsokat teljesen automatikusan használja a rendszer. Azonban ha egy csomagot nem az Ubuntu tárolóiból töltjük le, hanem közvetlenül a fejlesztő oldaláról, akkor szükség van arra, hogy manuálisan ellenőrizzük le a hitelességét. Nézzünk erre egy példát:

A rendszerünkre telepítsük a VeraCrypt programot, amely segítségével például titkosított pendrive-ot tudunk létrehozni. A programról bővebben ezen a weboldalon olvashatunk: https://www.idrix.fr/Root/content/category/7/32/60//#Downloads Első lépésben töltsük le a program csomagját és elektronikus aláírását a fejlesztő oldaláról:

wget https://launchpad.net/veracrypt/trunk/1.25.9/+download/veracrypt-console-1.25.9-Ubuntu-22.04-amd64.deb
wget https://launchpad.net/veracrypt/trunk/1.25.9/+download/veracrypt-console-1.25.9-Ubuntu-22.04-amd64.deb.sig

Ezután letöltjük a fejlesztő nyilvános kulcsát, amellyel leellenőrizhetjük majd az elektronikus aláírást. Ezt a fájlt szintén a fejlesztő oldalán találjuk meg:

wget https://www.idrix.com/VeraCrypt/VeraCrypt_PGP_public_key.asc

A biztonság kedvéért ellenőrizzük le, hogy a nyilvános kulcs ellenőrző összege megegyezik-e azzal, amit az oldalon hirdetnek. Ehhez először határozzuk meg a gpg programmal a letöltött kulcs ellenőrző összegét, mely a parancs kimenetének második sorában jelenik meg.

root@server2:~# gpg --show-keys VeraCrypt_PGP_public_key.asc
pub   rsa4096 2018-09-11 [SC]
      5069A233D55A0EEB174A5FC3821ACD02680D16DE
uid                      VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>
sub   rsa4096 2018-09-11 [E]
sub   rsa4096 2018-09-11 [A]

Ezután menjünk a fejlesztő oldalára (a korábban megadott linken keresztül), és hasonlítsuk össze az ott feltüntetett karaktersorozatot ezzel. (A Downloads bekezdés utolsó sorában látható.) Remélhetőleg azt látjuk, hogy a kettő megegyezik. Miután meggyőződtünk a publikus kulcs valódiságáról, beimportáljuk a GPG publikus kulcskarikájába:

root@server2:~# gpg --import VeraCrypt_PGP_public_key.asc
gpg: key 821ACD02680D16DE: 1 signature not checked due to a missing key
gpg: key 821ACD02680D16DE: public key "VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found

A parancs kimenetén látható, hogy a kulcsot ugyan beimportálta, de figyelmeztet arra, hogy noha a kulcsot hitelesítették egy elektronikus aláírással, de azt nem tudja leellenőrizni. Ennek az az oka, hogy a nem rendelkezik az aláíró publikus kulcsával. (Tehát nem csak a csomagot lehet aláírni, hanem a csomaghoz tartozó nyilvános kulcsot is, amely leellenőrzéséhez megint kellene egy nyilvános kulcs.) Nézzük meg, hogy a kulcs bekerült-e a kulcstárolóba:

root@server2:~# gpg --list-keys
/root/.gnupg/pubring.kbx
------------------------
pub   rsa4096 2018-09-11 [SC]
      5069A233D55A0EEB174A5FC3821ACD02680D16DE
uid           [ unknown] VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>
sub   rsa4096 2018-09-11 [E]
sub   rsa4096 2018-09-11 [A]

Igan, bekerült. A parancs kimenetének 5. sorában láthatjuk annak a kulcsnak az azonosítóját (0x54DDD393), amelyet lecseréltek erre az új kulcsra. Az 5069A233D55A0EEB174A5FC3821ACD02680D16DE karaktersorozat a gpg számára azonosítja a kulcsot a különböző műveletekhez.

A nyilvános kulcsok egy igen hosszú karaktersorozatból állnak. Az előző kulcs például így kezdődik:

Minden kulcs egy egyedi azonosítóval is rendelkezik, amellyel könnyebben hivatkozhatunk rá. De hol? A cégek a nyilvános kulcsaikat úgynevezett kulcsszervereken keresztül hirdetik, és ezekben a szerverekben hivatkozhatunk a keresett kulcsra az azonosítóján keresztül. Ilyen nyilvános kulcsszervereket sok helyen találhatunk, az Ubuntu is üzemeltet egyet keyserver.ubuntu.com néven. Töröljük most ki a korábban beimportált VeraCrypt kulcsot, és töltsük le azonosító alapján egy kulcsszerverről. (Az azonosítót ismét a fejlesztő oldalán találhatjuk meg, jelen esetben ez a 0x680D16DE.)

Először törüljük le a kulcsot:

root@server2:~# gpg --delete-key 5069A233D55A0EEB174A5FC3821ACD02680D16DE
gpg (GnuPG) 2.2.35; Copyright (C) 2022 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  rsa4096/821ACD02680D16DE 2018-09-11 VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>

Delete this key from the keyring? (y/N) y

Leellenőrizhetjük, hogy a kulcs a törlés után már nincsen bent a tárolóban:

root@server2:~# gpg --list-keys

Importáljuk be ismét a kulcsot, de most az Ubuntu kulcsszerveréről:

root@server2:~# gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 0x680D16DE
gpg: key 821ACD02680D16DE: public key "VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>" imported
gpg: Total number processed: 1
gpg:               imported: 1

És máris megjelent a rendszerben:

root@server2:~# gpg --list-keys
/root/.gnupg/pubring.kbx
------------------------
pub   rsa4096 2018-09-11 [SC]
      5069A233D55A0EEB174A5FC3821ACD02680D16DE
uid           [ unknown] VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>
sub   rsa4096 2018-09-11 [A]
sub   rsa4096 2018-09-11 [E]

Bárhogy is importáltuk be a kulcsot, ellenőrizzük most le, hogy ténylegesen ehhez a nyilvános kulcshoz tartozó titkos kulccsal írták alá a csomagot:

root@server2:~# gpg --verify veracrypt-console-1.25.9-Ubuntu-22.04-amd64.deb.sig veracrypt-console-1.25.9-Ubuntu-22.04-amd64.deb
gpg: Signature made Wed 18 May 2022 10:13:10 PM UTC
gpg:                using RSA key 5069A233D55A0EEB174A5FC3821ACD02680D16DE
gpg: Good signature from "VeraCrypt Team (2018 - Supersedes Key ID=0x54DDD393) <veracrypt@idrix.fr>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 5069 A233 D55A 0EEB 174A  5FC3 821A CD02 680D 16DE

Az aláírás ellenőrzése sikeresen megtörtént (Good signature from…), de a parancs arra is figyelmeztet, hogy semmi nem biztosítja, hogy valaki nem adja ki magát ennek a VeraCrypt cégnek, és a saját (hamis) titkos kulcsával írta alá a csomagot, és a weboldalra a saját hamis nyilvános kulcsát és annak ellenőrző összegét töltötte fel. (Persze ehhez fel kellett volna törnie a cég weboldalát…) Nagyobb bizonyosságot az adna, ha a nyilvános kulcs elektronikus aláírást is leellenőrizhettük volna…

Ha most ezt a letöltött csomagot installálni akarjuk, akkor használjuk a dpkg parancsot, majd a függőségi problémákat tegyük rendbe az apt-vel:

dpkg -i veracrypt-console-1.25.9-Ubuntu-22.04-amd64.deb
apt install -f

Csomaglisták mozgatása rendszerek között

Sokat kell dolgoznunk azon, hogy egy rendszeren azok és csak azok a csomagok legyenek felinstallálva, amelyekre szükségünk van. Amikor egy ilyen jól üzemelő rendszer megbízhatóan működik, érdemes a csomagjainak állapotáról biztonsági másolatot készíteni, hogy bármilyen gond esetén vissza tudjuk állítani majd. De ugyanígy használhatjuk ezt a másolatot, ha egy másik, ugyanilyen gépet szeretnénk létrehozni. A felinstallált csomagok listájának előállításához ismét a dpkg programot használhatjuk úgy, hogy kimenetét átirányítjuk egy fájlba:

root@server2:~# dpkg --get-selections > ~/packages_list.txt

root@server2:~# cat packages_list.txt
adduser                                         install
amd64-microcode                                 install
apparmor                                        install
...

Ez azonban lehet, hogy még nem elegendő. Szükség esetén listát kell készítenünk a forrásainkról, és a hozzájuk tartozó megbízható kulcsokról is. A forrásokat a /etc/apt könyvtárban a sources.list névvel kezdődő fájlok és könyvtárak tartalmazzák, míg a kulcsokat apt-key paranccsal exportáljuk ki. (Meg kell említeni, hogy az apt-key használatát lassan kivezetik a csomagkezelésből.)

mkdir ~/sources
cp -R /etc/apt/sources.list* ~/sources

apt-key exportall > ~/trusted_keys.txt

Ezután a biztonsági mentésbe a packages_list.txt és a trusted_keys.txt fájlokat, valamint a sources könyvtárat kell elmentenünk, illetve ha egy másik gépen ugyanezt az állapotot akarjuk elérni, akkor arra ezeket át kell másolni. Tegyük fel, hogy ez a másolás megtörtént. (Legegyszerűbb összetömöríteni a fájlokat, majd scp-vel átmásolni a másik gépre.) Lépjünk át a másik gépre (vagy helyreállítás esetén maradunk az eredetin), és először a kulcsokat importáljuk be, majd a forrásokat másoljuk a helyükre. (Amennyiben nincsen még fent, a kulcsok hozzáadásához a gnupg csomagot telepítenünk kell.)

apt-key add ~/trusted_keys.txt
cp -R ~sources/* /etc/apt/

Mielőtt a csomaglistát is helyreállítanánk, a rendszerhez nem szorosan kapcsolódó csomagok állapotát deinstall-ra kell állítani a –clear-selections kapcsoló segítségével. Majd a visszaállítás közben a másik gép csomagjainak az állapotával fogjuk ezt felülírni.

dpkg --clear-selections

A helyreállítást a dselect programmal végezzük, amelyet fel kell installálnunk. Ez a program saját adatbázist tart fent a csomagokról, így ezt is frissíteni kell:

apt update
apt install dselect
dselect update

Írjuk most felül a csomagok állapotát az átmásolt csomaglista szerint, majd a dselect programmal frissítsük a csomagokat az új lista szerint. Érdekes, hogy az én Ubuntu rendszeremen ez a művelet csak akkor sikeres, ha az apt helyett az apt-get-et használjuk.

dpkg --set-selections < packages_list.txt
apt-get dselect-upgrade

A frissítés eredményeként azok a csomagok, amelyek deinstall állapotúak voltak, törlésre, a többiek pedig vagy frissítésre, vagy felinstallálásra kerülnek. (Érdemes ezt a folyamatot úgy kipróbálni, hogy felhúzunk két linux konténert, az egyikre felinstalláljuk például a Midnight Commander-t, majd a másikat a fent leírt lépéseket követve az első csomaglistája szerint frissítjük. Végeredményben fogjuk látni, hogy a másodikon is megjelenik a fájlkezelő.)

Az eddigiekből is kiderült, milyen hasznos eszköz a kezünkben az apt csomagkezelő. A bemutatott lehetőségeken felül de mindig ügyeljünk arra, hogy csak ellenőrzött forrásokból kerülhessenek programok a rendszerünkbe.

Post Views: 162