Ho usato gestori di pacchetti basati su rpm per installare software su Red Hat e Fedora Linux da quando ho iniziato a usare Linux più di 20 anni fa. Ho usato il rpm programma stesso, yum e DNF , che è uno stretto discendente di yum, per installare e aggiornare i pacchetti sui miei host Linux. Gli strumenti yum e DNF sono wrapper dell'utilità rpm che forniscono funzionalità aggiuntive, come la possibilità di trovare e installare le dipendenze dei pacchetti.
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Nel corso degli anni ho creato una serie di script Bash, alcuni dei quali hanno file di configurazione separati, che mi piace installare sulla maggior parte dei miei nuovi computer e macchine virtuali. È arrivato al punto che ci è voluto molto tempo per installare tutti questi pacchetti, quindi ho deciso di automatizzare quel processo creando un pacchetto rpm che potevo copiare sugli host di destinazione e installare tutti questi file nelle posizioni corrette. Sebbene il rpm strumento era precedentemente utilizzato per creare pacchetti rpm, quella funzione è stata rimossa e un nuovo strumento, rpmbuild, è stato creato per creare nuovi rpm.
Quando ho iniziato questo progetto, ho trovato pochissime informazioni sulla creazione di pacchetti rpm, ma sono riuscito a trovare un libro, Maximum RPM , che mi ha aiutato a capirlo. Quel libro ora è un po' antiquato, così come la stragrande maggioranza delle informazioni che ho trovato. È anche fuori stampa e le copie usate costano centinaia di dollari. La versione online di Maximum RPM è disponibile gratuitamente ed è sempre aggiornata. Il sito web RPM ha anche collegamenti ad altri siti web che hanno molta documentazione su rpm. Le altre informazioni disponibili tendono ad essere brevi e apparentemente presuppongono che tu abbia già una buona conoscenza del processo.
Inoltre, ognuno dei documenti che ho trovato presuppone che il codice debba essere compilato dai sorgenti come in un ambiente di sviluppo. Non sono uno sviluppatore. Sono un amministratore di sistema e noi amministratori di sistema abbiamo esigenze diverse perché non compiliamo o non dovremmo compilare codice da utilizzare per attività amministrative; dovremmo usare script di shell. Quindi non abbiamo codice sorgente nel senso che è qualcosa che deve essere compilato in eseguibili binari. Quello che abbiamo è una fonte che è anche l'eseguibile.
Per la maggior parte, questo progetto dovrebbe essere eseguito come studente utente non root. Rpms non dovrebbe mai essere compilato da root, ma solo da utenti non privilegiati. Indicherò quali parti devono essere eseguite come root e quali da un utente non root e senza privilegi.
Preparazione
Innanzitutto, apri una sessione terminale e su
radicare. Assicurati di utilizzare -
opzione per garantire che l'ambiente root completo sia abilitato. Non credo che gli amministratori di sistema debbano usare sudo
per eventuali compiti amministrativi. Scopri perché nel mio post sul blog personale:I veri amministratori di sistema non sudo .
[student@testvm1 ~]$ su -
Password:
[root@testvm1 ~]#
Crea un utente studente che può essere utilizzato per questo progetto e imposta una password per quell'utente.
[root@testvm1 ~]# useradd -c "Student User" student
[root@testvm1 ~]# passwd student
Changing password for user student.
New password: <Enter the password>
Retype new password: <Enter the password>
passwd: all authentication tokens updated successfully.
[root@testvm1 ~]#
La creazione di pacchetti rpm richiede rpm-build
pacchetto, che probabilmente non è già installato. Installalo ora come root. Nota che questo comando installerà anche diverse dipendenze. Il numero può variare, a seconda dei pacchetti già installati sul tuo host; ha installato un totale di 17 pacchetti sulla mia macchina virtuale di prova, il che è piuttosto minimo.
dnf install -y rpm-build
Il resto di questo progetto dovrebbe essere eseguito come studente utente se non diversamente indicato. Apri un'altra sessione del terminale e usa su
per passare a quell'utente per eseguire il resto di questi passaggi. Scarica un tarball che ho preparato di una struttura di directory di sviluppo, utils.tar, da GitHub usando il seguente comando:
wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tar
Questo tarball include tutti i file e gli script Bash che verranno installati dall'rpm finale. C'è anche un file di specifiche completo, che puoi usare per costruire il file rpm. Entreremo nel dettaglio di ogni sezione del file delle specifiche.
Come studente utente, usando la tua home directory come directory di lavoro attuale (pwd), decomprimi il tarball.
[student@testvm1 ~]$ cd ; tar -xvf utils.tar
Usa l'tree
comando per verificare che la struttura della directory di ~/development e i file contenuti assomigli al seguente output:
[student@testvm1 ~]$ tree development/
development/
├── license
│ ├── Copyright.and.GPL.Notice.txt
│ └── GPL_LICENSE.txt
├── scripts
│ ├── create_motd
│ ├── die
│ ├── mymotd
│ └── sysdata
└── spec
└── utils.spec
3 directories, 7 files
[student@testvm1 ~]$
Il mymotd
script crea un flusso di dati "Message Of The Day" che viene inviato a stdout. Il create_motd
lo script esegue mymotd
script e reindirizza l'output al file /etc/motd. Questo file viene utilizzato per visualizzare un messaggio giornaliero agli utenti che accedono in remoto utilizzando SSH.
Il die
script è il mio script che racchiude il kill
comando in un bit di codice che può trovare programmi in esecuzione che corrispondono a una stringa specificata e ucciderli. Usa kill -9
per assicurarsi che non possano ignorare il messaggio di kill.
I sysdata
script può generare decine di migliaia di righe di dati sull'hardware del tuo computer, la versione installata di Linux, tutti i pacchetti installati e i metadati dei tuoi dischi rigidi. Lo uso per documentare lo stato di un host in un determinato momento. In seguito posso usarlo come riferimento. Lo facevo per mantenere un registro degli host che avevo installato per i clienti.
Potrebbe essere necessario modificare la proprietà di questi file e directory in student.student. Fallo, se necessario, usando il seguente comando:
chown -R student.student development
La maggior parte dei file e delle directory in questo albero verranno installati sui sistemi Fedora dagli rpm che creerai durante questo progetto.
Creazione della struttura della directory build
Il rpmbuild
comando richiede una struttura di directory molto specifica. Devi creare tu stesso questa struttura di directory perché non viene fornito alcun modo automatizzato. Crea la seguente struttura di directory nella tua home directory:
~ ─ rpmbuild
├── RPMS
│ └── noarch
├── SOURCES
├── SPECS
└── SRPMS
Non creeremo la directory rpmbuild/RPMS/X86_64 perché sarebbe specifica dell'architettura per i binari compilati a 64 bit. Abbiamo script di shell che non sono specifici dell'architettura. In realtà, non utilizzeremo nemmeno la directory SRPMS, che conterrebbe i file di origine per il compilatore.
Esame del file delle specifiche
Ogni file di specifiche ha un numero di sezioni, alcune delle quali possono essere ignorate o omesse, a seconda delle circostanze specifiche della build rpm. Questo particolare file delle specifiche non è un esempio di un file minimo necessario per funzionare, ma è un buon esempio di un file delle specifiche moderatamente complesso che racchiude i file che non devono essere compilati. Se fosse richiesta una compilazione, verrebbe eseguita nel %build
sezione, che viene omessa da questo file di specifiche perché non è richiesta.
Preambolo
Questa è l'unica sezione del file delle specifiche che non ha un'etichetta. Consiste in gran parte delle informazioni che vedi quando il comando rpm -qi [Package Name]
è eseguito. Ogni dato è una singola riga che consiste in un tag, che lo identifica e dati di testo per il valore del tag.
###############################################################################
# Spec file for utils
################################################################################
# Configured to be built by user student or other non-root user
################################################################################
#
Summary: Utility scripts for testing RPM creation
Name: utils
Version: 1.0.0
Release: 1
License: GPL
URL: http://www.both.org
Group: System
Packager: David Both
Requires: bash
Requires: screen
Requires: mc
Requires: dmidecode
BuildRoot: ~/rpmbuild/
# Build with the following syntax:
# rpmbuild --target noarch -bb utils.spec
Le righe di commento vengono ignorate da rpmbuild
programma. Mi piace sempre aggiungere un commento a questa sezione che contenga l'esatta sintassi di rpmbuild
comando richiesto per creare il pacchetto. Il tag Summary è una breve descrizione del pacchetto. I tag Nome, Versione e Rilascio vengono utilizzati per creare il nome del file rpm, come in utils-1.00-1.rpm. L'aumento dei numeri di versione e versione ti consente di creare rpm che possono essere utilizzati per aggiornare quelli precedenti.
Il tag License definisce la licenza in base alla quale il pacchetto viene rilasciato. Uso sempre una variazione della GPL. Specificando la licenza è importante chiarire il fatto che il software contenuto nel pacchetto è open source. Questo è anche il motivo per cui ho incluso la licenza e la dichiarazione GPL nei file che verranno installati.
L'URL è solitamente la pagina Web del progetto o del proprietario del progetto. In questo caso, è la mia pagina web personale.
Il tag Group è interessante e viene solitamente utilizzato per le applicazioni GUI. Il valore del tag Gruppo determina quale gruppo di icone nel menu delle applicazioni conterrà l'icona dell'eseguibile in questo pacchetto. Usato insieme al tag Icona (che non stiamo usando qui), il tag Gruppo consente di aggiungere l'icona e le informazioni richieste per avviare un programma nella struttura del menu delle applicazioni.
Il tag Packager viene utilizzato per specificare la persona o l'organizzazione responsabile della manutenzione e della creazione del pacchetto.
Le istruzioni Requires definiscono le dipendenze per questo rpm. Ciascuno è un nome di pacchetto. Se uno dei pacchetti specificati non è presente, l'utilità di installazione DNF cercherà di localizzarlo in uno dei repository definiti definiti in /etc/yum.repos.d e di installarlo se esiste. Se DNF non riesce a trovare uno o più dei pacchetti richiesti, genererà un errore indicando quali pacchetti mancano e terminano.
La riga BuildRoot specifica la directory di primo livello in cui rpmbuild
lo strumento troverà il file delle specifiche e in cui creerà directory temporanee mentre crea il pacchetto. Il pacchetto finito verrà archiviato nella sottodirectory noarch specificata in precedenza. Il commento che mostra la sintassi dei comandi usata per costruire questo pacchetto include l'opzione –target noarch
, che definisce l'architettura di destinazione. Poiché si tratta di script Bash, non sono associati a un'architettura CPU specifica. Se questa opzione venisse omessa, la build verrebbe indirizzata all'architettura della CPU su cui viene eseguita la build.
Il rpmbuild
il programma può avere come target molte architetture diverse e usando il --target
l'opzione ci consente di costruire pacchetti specifici dell'architettura su un host con un'architettura diversa da quella su cui viene eseguita la compilazione. Quindi potrei creare un pacchetto destinato all'uso su un'architettura i686 su un host x86_64 e viceversa.
Cambia il nome del packager con il tuo e l'URL del tuo sito web, se ne hai uno.
%descrizione
Il %description
la sezione del file delle specifiche contiene una descrizione del pacchetto rpm. Può essere molto breve o può contenere molte righe di informazioni. Il nostro %description
la sezione è piuttosto concisa.
%description
A collection of utility scripts for testing RPM creation.
%prep
Il %prep
section è il primo script che viene eseguito durante il processo di compilazione. Questo script non viene eseguito durante l'installazione del pacchetto.
Questo script è solo uno script di shell Bash. Prepara la directory build, creando directory utilizzate per la build come richiesto e copiando i file appropriati nelle rispettive directory. Ciò includerebbe i sorgenti necessari per una compilazione completa come parte della build.
La directory $RPM_BUILD_ROOT rappresenta la directory principale di un sistema installato. Le directory create nella directory $RPM_BUILD_ROOT sono percorsi completi, come /user/local/share/utils, /usr/local/bin e così via, in un filesystem live.
Nel caso del nostro pacchetto, non abbiamo fonti di precompilazione poiché tutti i nostri programmi sono script Bash. Quindi copiamo semplicemente quegli script e altri file nelle directory a cui appartengono nel sistema installato.
%prep
################################################################################
# Create the build tree and copy the files from the development directories #
# into the build tree. #
################################################################################
echo "BUILDROOT = $RPM_BUILD_ROOT"
mkdir -p $RPM_BUILD_ROOT/usr/local/bin/
mkdir -p $RPM_BUILD_ROOT/usr/local/share/utils
cp /home/student/development/utils/scripts/* $RPM_BUILD_ROOT/usr/local/bin
cp /home/student/development/utils/license/* $RPM_BUILD_ROOT/usr/local/share/utils
cp /home/student/development/utils/spec/* $RPM_BUILD_ROOT/usr/local/share/utils
exit
Si noti che l'istruzione di uscita alla fine di questa sezione è obbligatoria.
%file
Questa sezione del file delle specifiche definisce i file da installare e le loro posizioni nell'albero delle directory. Specifica inoltre gli attributi del file e il proprietario e il proprietario del gruppo per ciascun file da installare. Le autorizzazioni e le proprietà dei file sono facoltative, ma consiglio di impostarle in modo esplicito per eliminare qualsiasi possibilità che tali attributi siano errati o ambigui una volta installati. Le directory vengono create come richiesto durante l'installazione se non esistono già.
%files
%attr(0744, root, root) /usr/local/bin/*
%attr(0644, root, root) /usr/local/share/utils/*
%pre
Questa sezione è vuota nel file delle specifiche del nostro progetto di laboratorio. Questo sarebbe il posto dove inserire tutti gli script che devono essere eseguiti durante l'installazione di rpm ma prima dell'installazione dei file.
%post
Questa sezione del file delle specifiche è un altro script Bash. Questo viene eseguito dopo l'installazione dei file. Questa sezione può essere praticamente tutto ciò di cui hai bisogno o desideri che sia, inclusa la creazione di file, l'esecuzione di comandi di sistema e il riavvio dei servizi per reinizializzarli dopo aver apportato modifiche alla configurazione. Il %post
script per il nostro pacchetto rpm esegue alcune di queste attività.
%post
################################################################################
# Set up MOTD scripts #
################################################################################
cd /etc
# Save the old MOTD if it exists
if [ -e motd ]
then
cp motd motd.orig
fi
# If not there already, Add link to create_motd to cron.daily
cd /etc/cron.daily
if [ ! -e create_motd ]
then
ln -s /usr/local/bin/create_motd
fi
# create the MOTD for the first time
/usr/local/bin/mymotd > /etc/motd
I commenti inclusi in questo script dovrebbero chiarire il suo scopo.
%postun
Questa sezione contiene uno script che verrebbe eseguito dopo la disinstallazione del pacchetto rpm. L'uso di rpm o DNF per rimuovere un pacchetto rimuove tutti i file elencati in %files
sezione, ma non rimuove i file o i collegamenti creati dal %post
sezione, quindi dobbiamo gestirlo in questa sezione.
Questo script di solito consiste in attività di pulizia che la semplice cancellazione dei file precedentemente installati da rpm non può eseguire. Nel caso del nostro pacchetto, include la rimozione del collegamento creato dal %post
script e ripristinare l'originale salvato del file motd.
%postun
# remove installed files and links
rm /etc/cron.daily/create_motd
# Restore the original MOTD if it was backed up
if [ -e /etc/motd.orig ]
then
mv -f /etc/motd.orig /etc/motd
fi
%clean
Questo script Bash esegue la pulizia dopo il processo di compilazione rpm. Le due righe nel %clean
la sezione seguente rimuove le directory di build create da rpm-build
comando. In molti casi, potrebbe essere necessaria anche una pulizia aggiuntiva.
%clean
rm -rf $RPM_BUILD_ROOT/usr/local/bin
rm -rf $RPM_BUILD_ROOT/usr/local/share/utils
%changelog
Questa sezione di testo opzionale contiene un elenco di modifiche a rpm e ai file in esso contenuti. Le modifiche più recenti vengono registrate nella parte superiore di questa sezione.
%changelog
* Wed Aug 29 2018 Your Name <[email protected]>
- The original package includes several useful scripts. it is
primarily intended to be used to illustrate the process of
building an RPM.
Sostituisci i dati nella riga di intestazione con il tuo nome e indirizzo email.
Costruire il numero di giri
Il file spec deve trovarsi nella directory SPECS dell'albero rpmbuild. Trovo più semplice creare un collegamento al file delle specifiche effettive in quella directory in modo che possa essere modificato nella directory di sviluppo e non è necessario copiarlo nella directory SPECS. Rendi la directory SPECS il tuo pwd, quindi crea il collegamento.
cd ~/rpmbuild/SPECS/
ln -s ~/development/spec/utils.spec
Eseguire il comando seguente per compilare il file rpm. La creazione degli rpm dovrebbe richiedere solo un momento se non si verificano errori.
rpmbuild --target noarch -bb utils.spec
Controlla nella directory ~/rpmbuild/RPMS/noarch per verificare che il nuovo rpm esista lì.
[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/
[student@testvm1 noarch]$ ll
total 24
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
[student@testvm1 noarch]$
Test del numero di giri
Come root, installa rpm per verificare che venga installato correttamente e che i file siano installati nelle directory corrette. Il nome esatto di rpm dipenderà dai valori che hai utilizzato per i tag nella sezione Preambolo, ma se hai utilizzato quelli nell'esempio, il nome rpm sarà come mostrato nel comando di esempio seguente:
[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/
[root@testvm1 noarch]# ll
total 24
-rw-rw-r--. 1 student student 24364 Aug 30 10:00 utils-1.0.0-1.noarch.rpm
[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm
Preparing... ################################# [100%]
Updating / installing...
1:utils-1.0.0-1 ################################# [100%]
Controlla /usr/local/bin per assicurarti che i nuovi file siano presenti. Dovresti anche verificare che il link create_motd in /etc/cron.daily sia stato creato.
Usa rpm -q --changelog utils
comando per visualizzare il changelog. Visualizza i file installati dal pacchetto utilizzando rpm -ql utils
comando (che è una L minuscola in ql
.)
[root@testvm1 noarch]# rpm -q --changelog utils
* Wed Aug 29 2018 Your Name <[email protected]>
- The original package includes several useful scripts. it is
primarily intended to be used to illustrate the process of
building an RPM.
[root@testvm1 noarch]# rpm -ql utils
/usr/local/bin/create_motd
/usr/local/bin/die
/usr/local/bin/mymotd
/usr/local/bin/sysdata
/usr/local/share/utils/Copyright.and.GPL.Notice.txt
/usr/local/share/utils/GPL_LICENSE.txt
/usr/local/share/utils/utils.spec
[root@testvm1 noarch]#
Rimuovi il pacco.
rpm -e utils
Sperimentazione
Ora cambierai il file delle specifiche per richiedere un pacchetto che non esiste. Questo simulerà una dipendenza che non può essere soddisfatta. Aggiungi la seguente riga immediatamente sotto la riga Richiede esistente:
Requires: badrequire
Compila il pacchetto e prova a installarlo. Quale messaggio viene visualizzato?
Abbiamo usato il rpm
comando per installare ed eliminare le utils
pacchetto. Prova a installare il pacchetto con yum o DNF. Devi trovarti nella stessa directory del pacchetto o specificare il percorso completo del pacchetto affinché funzioni.
Conclusione
Ci sono molti tag e un paio di sezioni che non abbiamo trattato in questo sguardo alle basi della creazione di un pacchetto rpm. Le risorse elencate di seguito possono fornire ulteriori informazioni. La creazione di pacchetti rpm non è difficile; hai solo bisogno delle informazioni giuste. Spero che questo ti aiuti:mi ci sono voluti mesi per capire le cose da solo.
Non abbiamo trattato la creazione dal codice sorgente, ma se sei uno sviluppatore, da questo punto dovrebbe essere un semplice passaggio.
La creazione di pacchetti rpm è un altro buon modo per essere un pigro amministratore di sistema e risparmiare tempo e fatica. Fornisce un metodo semplice per distribuire e installare gli script e altri file che noi amministratori di sistema dobbiamo installare su molti host.
Risorse
-
Edward C. Baily, RPM massimo , Sams Publishing, 2000, ISBN 0-672-31105-4
-
Edward C. Baily, RPM massimo , versione online aggiornata
-
Documentazione RPM :Questa pagina web elenca la maggior parte della documentazione in linea disponibile per rpm. Include molti collegamenti ad altri siti Web e informazioni su rpm.