Obiettivo
Il nostro obiettivo è abituarci agli strumenti disponibili per trovare informazioni sulle dipendenze dei pacchetti su un sistema basato su RPM.
Sistema operativo e versioni software
- Sistema operativo: Red Hat Enterprise Linux 7.5
- Software: rpm 4.11, yum 3.4.3
Requisiti
Accesso privilegiato al sistema.
Difficoltà
FACILE
Convenzioni
- # – richiede che i comandi linux dati vengano eseguiti con i privilegi di root direttamente come utente root o usando
sudocomando - $ – dati comandi linux da eseguire come un normale utente non privilegiato
Introduzione
RPM, che sta per Red Hat Package Manager, è un noto e maturo gestore di pacchetti utilizzato da tutte le distribuzioni di Red Hat, così come SuSE. Con RPM il packager può definire le relazioni tra i pacchetti e anche con le versioni dei pacchetti, ad esempio, un server Apache Tomcat ha bisogno della presenza di un ambiente Java appropriato per poter essere eseguito.
D'altra parte, per installare un ambiente Java, non è necessario un server Tomcat:potresti decidere di eseguire qualche applicazione basata su Java diversa, magari una scritta da te avviata a mano quando necessario per fare il suo lavoro. In altre parole, il server Tomcat dipende su Java.
RPM può rendere la vita di un amministratore di sistema molto più semplice presentando queste dipendenze e strumenti che si basano su RPM come rpm utilità o yum può risolvere automaticamente queste dipendenze e installare tutti i pacchetti aggiuntivi necessari per il corretto funzionamento di un nuovo componente.
Raccolta di informazioni
Per scoprire l'elenco dei pacchetti da cui dipende il pacchetto foo.bar, esegui semplicemente:
# yum deplist foo.bar
E per trovare l'elenco dei pacchetti che richiedono (dipende da) il pacchetto foo.bar:
rpm -q --whatrequires foo.bar
Un esempio reale con un pacchetto generico:bash . Vediamo quali pacchetti sono necessari al pacchetto 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
Dal punto di vista del pacchetto, bash è molto generico e, come visto sopra, dipende da alcuni pacchetti core. Ma se vorremmo installare qualcosa di molto più dipendente, diciamo, il konzole Emulatore di terminale KDE su Red Hat Linux con un desktop manager Gnome, potremmo ottenere un elenco di dipendenze lungo più di una pagina. E con konzole , il caso è ancora più complicato, poiché si basa sui pacchetti QT e KDE, quindi per installarlo, dovrai installare l'intero ambiente KDE accanto a Gnome (cosa che puoi sicuramente fare) per fornire tutto konzole esigenze.
Per avere un'idea più precisa di quali pacchetti verranno installati, controlla l'elenco fornito da yum prima di avviare l'installazione:
# 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 = [...]
Nel caso di un sistema Red Hat con Gnome, potrebbe volerci un po' di tempo per risolvere le dipendenze di un'applicazione KDE per la prima volta, e quando questo sarà finito, yum presenterà l'unico pacchetto che abbiamo chiesto, con una piccola dimensione . Seguito da più di cento pacchetti installati per le dipendenze:
[...]
--> 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
[...]
E nel riepilogo possiamo vedere che l'installazione utilizzerà molto più spazio su disco alla fine, quindi la dimensione del pacchetto di cui abbiamo bisogno:
[...]
Transaction Summary
==============================================================================================================================
Install 1 Package (+120 Dependent packages)
Total download size: 108 M
Installed size: 307 M
Questo è molto, ma abbiamo informazioni utili su quanto spazio verrà utilizzato. Ciò è particolarmente utile se installiamo molti pacchetti in una transazione.
Mentre in questo caso la transazione è dispendiosa, l'obiettivo delle dipendenze è in definitiva il risparmio di risorse:se qualcuno implementa alcune funzionalità nel suo codice e queste possono essere richiamate sul sistema, lo sviluppatore successivo potrebbe non aver bisogno di implementare la stessa funzionalità di nuovo, ma utilizzare l'implementazione già esistente. Per il konzole ad esempio, se vuoi installare akregator la prossima volta, il sistema avrà già molte dipendenze risolte, come kdepim pacchetto contenente akregator si basa anche su qt , kdelibs , e così via.
Possiamo usare rpm utility per ottenere le informazioni al contrario:elenchiamo i pacchetti installati che richiedono bash pacchetto:
# 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
Pulizia dei pacchetti non necessari
Se manteniamo aggiornati i nostri sistemi e cambiamo o estendiamo i loro ruoli, i pacchetti "spazzatura" appariranno inevitabilmente. Nel senso del pacchetto, spazzatura significa pacchetti non più necessari e/o obsoleti. Per seguire l'esempio sopra, non abbiamo più bisogno di akregator , perché abbiamo spostato il "servizio" di gestione RSS in un ipotetico concentratore RSS centrale all'interno del nostro sistema, quindi dopo aver migrato i nostri feed nella posizione centrale, disinstalliamo l'applicazione di gestione RSS locale. Ciò non rimuoverà tutti i pacchetti di KDE, poiché molti altri pacchetti potrebbero dipendere da essi. In caso contrario, quei pacchetti sono spazzatura e consumeranno risorse, inclusi tempi di aggiornamento più lunghi, come yum per impostazione predefinita aggiornerà tutto alla cieca per cui trova nuovi pacchetti/errata.
Spendere risorse per aggiornare alcuni pacchetti non necessari su un laptop con connessione a banda larga e SSD potrebbe non sembrare un problema, ma immagina un data center con centinaia o migliaia di computer e avrai il quadro. In genere è una buona idea mantenere tutti i sistemi semplici e la gestione delle risorse è solo un punto. Più un sistema è complesso, più è soggetto a errori. Più componenti significano più possibili bug.
Per avere una panoramica sui pacchetti non necessari installati sul sistema, possiamo usare yum e la pulizia dei pacchetti allo stesso modo di CentOS, o un'altra funzionalità di yum, autoremove :
yum autoremove
I pacchetti che questi strumenti contrassegnano come non necessari non sono identici.
Quando si utilizza uno di questi strumenti si consiglia di ricontrollare cosa yum rimuoverà ed eventualmente verificherà il risultato della pulizia su macchine di prova con contenuto identico della confezione prima di pulire i sistemi di produzione.
Questi strumenti sono davvero intelligenti, ma non onnicomprensivi:ad esempio, non ci sarà alcuna voce nel database rpm su un'applicazione PHP personalizzata in esecuzione su un server web che chiama cups per stampare gli ordini in entrata su una stampante collegata al server. Cioè, ci può essere una voce se l'applicazione è inclusa nel pacchetto con le giuste dipendenze e installata correttamente con rpm o yum – ma questo richiede uno sforzo e tutti i servizi devono essere inclusi nello stesso modo se vuoi sentirti al sicuro con le pulizie automatiche basate su yum.
Risoluzione dei problemi di dipendenza
Soprattutto in ambienti di grandi dimensioni, possono verificarsi problemi di dipendenza durante l'installazione o l'aggiornamento dei sistemi.
Lo screenshot seguente mostra un semplice problema:
Risolvere le dipendenze con rpm
Nella schermata del terminale sopra, proviamo ad installare il nrpe pacchetto, il cliente doveva monitorare molti aspetti del sistema con Nagios. Abbiamo scaricato il client per la distribuzione, ma entrambi rpm e yum fallisce con lo stesso errore:il nrpe il pacchetto richiede (dipende da) il nagios-common pacchetto. In questo esempio possiamo ottenere il pacchetto necessario dalla stessa fonte, e quando installiamo entrambi il rpm l'utilità vede che la dipendenza su cui abbiamo fallito in precedenza sarà soddisfatta alla fine della transazione e installa entrambi i pacchetti, chiudendosi silenziosamente con successo.
Conclusione
Yum e rpm sono strumenti essenziali quando si lavora con le distribuzioni utilizzando il gestore di pacchetti RPM. Conoscendo il set di strumenti è molto più semplice e generalmente più sicuro risolvere attività di installazione, aggiornamento e modifica nell'ambiente software di un determinato sistema.