Cíl
Naším cílem je zvyknout si na dostupné nástroje pro zjištění informací o závislostech balíčků na systému založeném na RPM.
Verze operačního systému a softwaru
- Operační systém: Red Hat Enterprise Linux 7.5
- Software: otáčky za minutu 4.11, yum 3.4.3
Požadavky
Privilegovaný přístup do systému.
Obtížnost
SNADNÉ
Konvence
- # – vyžaduje, aby dané linuxové příkazy byly spouštěny s právy root buď přímo jako uživatel root, nebo pomocí
sudopříkaz - $ – dané linuxové příkazy, které mají být spouštěny jako běžný neprivilegovaný uživatel
Úvod
RPM, což je zkratka pro Red Hat Package Manager, je dobře známý a vyspělý správce balíčků používaný všemi distribucemi chutí Red Hat, stejně jako SuSE. Pomocí RPM může balíčkovač definovat vztahy mezi balíčky a dokonce i s verzemi balíčků – například server Apache Tomcat potřebuje ke svému běhu vhodné prostředí Java.
Na druhou stranu, k instalaci prostředí Java nepotřebujete server Tomcat – můžete se rozhodnout spustit nějakou jinou aplikaci založenou na Javě, možná nějakou, kterou si sami napíšete a spustíte ručně, když je to potřeba. Jinými slovy, server Tomcat závisí na Javě.
RPM může systémovým administrátorům výrazně usnadnit život tím, že prezentuje tyto závislosti – a nástroje spoléhající na RPM, jako je rpm utility nebo yum může automaticky vyřešit tyto závislosti a nainstalovat všechny další balíčky potřebné pro správnou funkci nové komponenty.
Shromažďování informací
Chcete-li zjistit seznam balíčků, na kterých závisí balíček foo.bar, jednoduše spusťte:
# yum deplist foo.bar
Chcete-li najít seznam balíčků, které vyžadují (v závislosti na) balíček foo.bar:
rpm -q --whatrequires foo.bar
Skutečný příklad s obecným balíčkem:bash . Podívejme se, jaké balíčky potřebuje balíček bash:
# yum deplist bash
package: bash.x86_64 4.2.46-30.el7
dependency: libc.so.6()(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.11)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.14)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.15)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.3)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.3.4)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.4)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libc.so.6(GLIBC_2.8)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libdl.so.2()(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libdl.so.2(GLIBC_2.2.5)(64bit)
provider: glibc.x86_64 2.17-222.el7
dependency: libtinfo.so.5()(64bit)
provider: ncurses-libs.x86_64 5.9-14.20130511.el7_4
dependency: rtld(GNU_HASH)
provider: glibc.x86_64 2.17-222.el7
provider: glibc.i686 2.17-222.el7
Z pohledu balíčku bash je velmi obecný, a jak je vidět výše, závisí na několika základních balíčcích. Ale pokud bychom chtěli nainstalovat něco mnohem závislejšího, řekněme konzole Emulátor terminálu KDE na Red Hat Linuxu se správcem plochy Gnome, můžeme získat více než jednu stránku dlouhého seznamu závislostí. A pomocí konzole , případ je ještě komplikovanější, protože se spoléhá na balíčky QT a KDE, takže abyste jej mohli nainstalovat, budete muset nainstalovat celé prostředí KDE vedle Gnome (což jistě můžete udělat), abyste poskytli vše konzole potřeby.
Chcete-li získat lepší přehled o tom, jaké balíčky budou nainstalovány, zkontrolujte před zahájením instalace seznam poskytnutý yum:
# yum install konsole
Resolving Dependencies
--> Running transaction check
---> Package konsole.x86_64 0:4.10.5-4.el7 will be installed
--> Processing Dependency: konsole-part = [...]
V případě systému Red Hat s Gnome může poprvé trvat poměrně dlouho, než se vyřeší závislosti aplikace KDE, a když to skončí, yum představí jediný balíček, o který jsme požádali, s pěkně malou velikostí. . Následuje více než sto nainstalovaných balíčků pro závislosti:
[...]
--> Running transaction check
---> Package boost-system.x86_64 0:1.53.0-27.el7 will be installed
---> Package boost-thread.x86_64 0:1.53.0-27.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================
Installing:
konsole x86_64 4.10.5-4.el7 rhel-7-server-rpms 78 k
Installing for dependencies:
OpenEXR-libs
[...]
A v souhrnu vidíme, že instalace nakonec zabere mnohem více místa na disku, než velikost balíku, kterou potřebujeme:
[...]
Transaction Summary
==============================================================================================================================
Install 1 Package (+120 Dependent packages)
Total download size: 108 M
Installed size: 307 M
To je hodně, ale získali jsme užitečnou informaci o tom, kolik místa bude využito. To je zvláště užitečné, pokud instalujeme mnoho balíčků v jedné transakci.
Zatímco v tomto případě je transakce nehospodárná, cílem závislostí je v konečném důsledku úspora zdrojů:pokud někdo implementuje nějakou funkcionalitu do svého kódu, kterou lze zavolat do systému, další vývojář nemusí implementovat stejnou funkcionalitu. znovu, ale použijte již existující implementaci. Pro konzole například, pokud chcete nainstalovat akregator příště už bude mít systém mnoho závislostí vyřešených, jako kdepim balíček obsahující akregator také spoléhá na qt , kdelibs a podobně.
Můžeme použít rpm pomůcka the získat informace obráceně:uveďme seznam nainstalovaných balíčků, které vyžadují bash balíček:
# rpm -q --whatrequires bash
dracut-033-535.el7.x86_64
initscripts-9.49.41-1.el7.x86_64
autofs-5.0.7-83.el7.x86_64
lvm2-2.02.177-4.el7.x86_64
rsyslog-8.24.0-16.el7.x86_64
Čištění nepotřebných balíčků
Pokud budeme naše systémy aktualizovat a změníme nebo rozšíříme jejich role, nevyhnutelně se objeví „nevyžádané“ balíčky. V balíkovém smyslu znamená nevyžádané balíčky již nepotřebné a/nebo zastaralé balíčky. Abychom následovali výše uvedený příklad, již nepotřebujeme akregator , protože jsme přesunuli „službu“ zpracování RSS do hypotetického centrálního koncentrátoru RSS v rámci našeho systému, takže po migraci našich kanálů na centrální místo odinstalujeme místní aplikaci pro zpracování RSS. To neodstraní všechny balíčky KDE, protože na nich může záviset mnoho dalších balíčků. Ale pokud ne, jsou tyto balíčky nevyžádané a spotřebovávají zdroje, včetně delší doby aktualizace, jako yum ve výchozím nastavení slepě aktualizuje vše, pro co najde nové balíčky/errata.
Utrácení prostředků na upgrade několika nepotřebných balíčků na notebooku se širokopásmovým připojením a SSD se nemusí zdát jako problém, ale představte si datové centrum se stovkami nebo tisíci počítačů a získáte obrázek. Obecně je dobré udržovat všechny systémy jednoduché a správa zdrojů je pouze jedním bodem. Čím je systém složitější, tím je náchylnější k chybám. Více komponent znamená více možných chyb.
Abychom získali přehled o nepotřebných balíčcích nainstalovaných v systému, můžeme použít yum a package-cleanup stejným způsobem jako na CentOS nebo jinou funkci yum, autoremove :
yum autoremove
Balíčky, které tyto nástroje označí jako nepotřebné, nejsou totožné.
Při použití kteréhokoli z těchto nástrojů se doporučuje znovu zkontrolovat, co yum se chystá před čištěním produkčních systémů odstranit a případně otestovat, k čemu čištění dojde na testovacích strojích s identickým obsahem balení.
Tyto nástroje jsou skutečně chytré, ale ne vševědoucí:například v databázi rpm nebude žádný záznam o vlastní PHP aplikaci běžící nad webovým serverem, který volá cups vytisknout příchozí objednávky na tiskárně připojené k serveru. To znamená, že může být záznam, pokud je aplikace zabalena se správnými závislostmi a správně nainstalována pomocí rpm nebo yum – ale to vyžaduje úsilí a všechny služby musí být zabaleny stejným způsobem, pokud se chcete cítit bezpečně s automatickým čištěním založeným na yum.
Řešení problémů se závislostmi
Zejména ve velkých prostředích mohou při instalaci nebo upgradu systémů nastat problémy se závislostí.
Níže uvedený snímek obrazovky ukazuje jednoduchý problém:
Řešení závislostí pomocí rpm
Na výše uvedené obrazovce terminálu se pokusíme nainstalovat nrpe klient potřeboval monitorovat mnoho aspektů systému pomocí Nagios. Stáhli jsme klienta pro distribuci, ale oba rpm a yum selže se stejnou chybou:nrpe balíček vyžaduje (v závislosti na) nagios-common balík. V tomto příkladu můžeme získat potřebný balíček ze stejného zdroje a při instalaci obou z nich rpm obslužný program vidí, že závislost, na které jsme dříve selhali, bude uspokojena do konce transakce a nainstaluje oba balíčky a tiše se s úspěchem ukončí.
Závěr
Yum a rpm jsou základní nástroje při práci s distribucemi pomocí správce balíčků RPM. Díky znalosti sady nástrojů je mnohem jednodušší a obvykle bezpečnější řešit úlohy instalace, upgradu a úpravy v softwarovém prostředí daného systému.