Unificazione degli script personalizzati a livello di sistema con rpm su Red Hat/CentOS

Obiettivo

Il nostro obiettivo è creare pacchetti rpm con contenuto personalizzato, unificando gli script su qualsiasi numero di sistemi, inclusi il controllo delle versioni, la distribuzione e l'annullamento della distribuzione.

Sistema operativo e versioni software

• Sistema operativo: Red Hat Enterprise Linux 7.5
• Software: rpm-build 4.11.3+

Requisiti

Accesso privilegiato al sistema per l'installazione, accesso normale per la compilazione.

Difficoltà

MEDIO

Convenzioni

• # – richiede che i comandi linux dati vengano eseguiti con i privilegi di root direttamente come utente root o usando sudo comando
• $ – dati comandi linux da eseguire come un normale utente non privilegiato

Introduzione

Una delle caratteristiche principali di qualsiasi sistema Linux è che sono costruiti per l'automazione. Se un'attività potrebbe dover essere eseguita più di una volta, anche con una parte di essa che cambia alla prossima esecuzione, un amministratore di sistema viene fornito con innumerevoli strumenti per automatizzarla, da una semplice shell script eseguiti manualmente su richiesta (eliminando così gli errori di battitura o salvando solo alcuni tasti della tastiera) su sistemi complessi con script in cui le attività vengono eseguite da cron in un determinato momento, interagendo tra loro, lavorando con il risultato di un altro script, magari controllato da un sistema di gestione centrale ecc.

Sebbene questa libertà e questo ricco set di strumenti aumentino effettivamente la produttività, c'è un problema:come amministratore di sistema, scrivi uno script utile su un sistema, che si rivela utile su un altro, quindi copi lo script. Anche su un terzo sistema lo script è utile, ma con piccole modifiche – forse una nuova funzionalità utile solo in quel sistema, raggiungibile con un nuovo parametro. Considerando la generalizzazione, estendi lo script per fornire la nuova funzionalità e completa anche l'attività per cui è stato scritto. Ora hai due versioni dello script, la prima è sui primi due sistemi, la seconda sul terzo sistema.

Hai 1024 computer in esecuzione nel data center e 256 di loro avranno bisogno di alcune delle funzionalità fornite da quello script. Col tempo avrai 64 versioni dello script dappertutto, ogni versione fa il suo lavoro. Nella prossima distribuzione del sistema è necessaria una funzionalità che ricordi di aver codificato in alcune versioni, ma quale? E su quali sistemi sono?

Sui sistemi basati su RPM, come le versioni Red Hat, un amministratore di sistema può sfruttare il gestore di pacchetti per creare ordine nel contenuto personalizzato, inclusi semplici script di shell che potrebbero non fornire altro se non gli strumenti che l'amministratore ha scritto per comodità.

In questo tutorial creeremo un rpm personalizzato per Red Hat Enterprise Linux 7.5 contenente due bash script, parselogs.sh e pullnews.sh per fornire un modo in cui tutti i sistemi dispongano dell'ultima versione di questi script in /usr/local/sbin directory, e quindi sul percorso di qualsiasi utente che accede al sistema.

Distribuzioni, versioni maggiori e minori

In generale, la versione minore e maggiore della macchina di compilazione dovrebbe essere la stessa dei sistemi in cui deve essere distribuito il pacchetto, così come la distribuzione per garantire la compatibilità. Se ci sono varie versioni di una data distribuzione, o anche distribuzioni diverse con molte versioni nel tuo ambiente (oh, gioia!), dovresti configurare macchine di compilazione per ciascuna. Per ridurre il lavoro, puoi semplicemente impostare l'ambiente di compilazione per ogni distribuzione e ogni versione principale e averli sulla versione minore più bassa esistente nel tuo ambiente per la versione principale data. Perché non devono essere macchine fisiche e devono essere in esecuzione solo in fase di compilazione, quindi puoi utilizzare macchine virtuali o container.

In questo tutorial il nostro lavoro è molto più semplice, distribuiamo solo due script che non hanno alcuna dipendenza (tranne bash ), quindi costruiremo noarch pacchetti che stanno per "non dipendenti dall'architettura", inoltre non specificheremo la distribuzione per cui è stato creato il pacchetto. In questo modo possiamo installarli e aggiornarli su qualsiasi distribuzione che utilizza rpm e a qualsiasi versione:dobbiamo solo assicurarci che rpm-build della macchina di compilazione il pacchetto è sulla versione più vecchia nell'ambiente.

Configurazione dell'ambiente edilizio

Per creare pacchetti rpm personalizzati, dobbiamo installare rpm-build pacchetto:

# yum install rpm-build

D'ora in poi, non utilizziamo root utente e per una buona ragione. La creazione di pacchetti non richiede root privilegio e non vuoi rompere la tua macchina da costruzione.

Creazione della prima versione del pacchetto

Creiamo la struttura di directory necessaria per la costruzione:

$ mkdir -p rpmbuild/SPECS

Il nostro pacchetto si chiama admin-scripts, versione 1.0. Creiamo un specfile che specifica i metadati, i contenuti e le attività svolte dal pacchetto. Questo è un semplice file di testo che possiamo creare con il nostro editor di testo preferito, come vi . Il rpmbuild precedentemente installato pacchetto riempirà il tuo specfile vuoto con i dati del modello se usi vi per crearne uno vuoto, ma per questo tutorial considera la specifica di seguito chiamata admin-scripts-1.0.spec :

Name:           admin-scripts
Version:        1
Release:        0
Summary:        FooBar Inc. IT dept. admin scripts
Packager:       John Doe 
Group:          Application/Other
License:        GPL
URL:            www.foobar.com/admin-scripts
Source0:        %{name}-%{version}.tar.gz
BuildArch:      noarch

%description
Package installing latest version the admin scripts used by the IT dept.

%prep
%setup -q


%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/sbin
cp scripts/* $RPM_BUILD_ROOT/usr/local/sbin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%dir /usr/local/sbin
/usr/local/sbin/parselogs.sh
/usr/local/sbin/pullnews.sh

%doc

%changelog
* Wed Aug 1 2018 John Doe 
- release 1.0 - initial release

Inserisci il file spec in rpmbuild/SPEC directory che abbiamo creato in precedenza.

Abbiamo bisogno delle fonti a cui si fa riferimento nel specfile – in questo caso i due script di shell. Creiamo la directory per i sorgenti (chiamata come il nome del pacchetto aggiunto alla versione principale):

$ mkdir -p rpmbuild/SOURCES/admin-scripts-1/scripts

E copia/sposta gli script al suo interno:

$ ls rpmbuild/SOURCES/admin-scripts-1/scripts/
parselogs.sh  pullnews.sh

Poiché questo tutorial non riguarda lo scripting della shell, il contenuto di questi script è irrilevante. Poiché creeremo una nuova versione del pacchetto e il pullnews.sh è lo script con cui dimostreremo, il suo sorgente nella prima versione è il seguente:

#!/bin/bash
echo "news pulled"
exit 0

Non dimenticare di aggiungere i diritti appropriati ai file nel sorgente, nel nostro caso, diritto di esecuzione:

chmod +x rpmbuild/SOURCES/admin-scripts-1/scripts/*.sh




Ora creiamo un tar.gz archivio dalla fonte nella stessa directory:

cd rpmbuild/SOURCES/ && tar -czf admin-scripts-1.tar.gz admin-scripts-1

Siamo pronti per costruire il pacchetto:

rpmbuild --bb rpmbuild/SPECS/admin-scripts-1.0.spec

Otterremo un output sulla build e, se qualcosa va storto, verranno visualizzati gli errori (ad esempio, file o percorso mancanti). Se tutto va bene, il nostro nuovo pacchetto apparirà nella directory RPMS generata per impostazione predefinita sotto rpmbuild directory (ordinata in sottodirectory per architettura):

$ ls rpmbuild/RPMS/noarch/
admin-scripts-1-0.noarch.rpm

Abbiamo creato un pacchetto rpm semplice ma completamente funzionale. Possiamo interrogarlo per tutti i metadati che abbiamo fornito in precedenza:

$ rpm -qpi rpmbuild/RPMS/noarch/admin-scripts-1-0.noarch.rpm 
Name        : admin-scripts
Version     : 1
Release     : 0
Architecture: noarch
Install Date: (not installed)
Group       : Application/Other
Size        : 78
License     : GPL
Signature   : (none)
Source RPM  : admin-scripts-1-0.src.rpm
Build Date  : 2018. aug.  1., Wed, 13.27.34 CEST
Build Host  : build01.foobar.com
Relocations : (not relocatable)
Packager    : John Doe 
URL         : www.foobar.com/admin-scripts
Summary     : FooBar Inc. IT dept. admin scripts
Description :
Package installing latest version the admin scripts used by the IT dept.




E per questo possiamo installarlo (con root privilegi):

Installazione di script personalizzati con rpm

Quando abbiamo installato gli script in una directory che si trova su $PATH di ogni utente , puoi eseguirli come qualsiasi utente nel sistema, da qualsiasi directory:

$ pullnews.sh 
news pulled




Il pacchetto può essere distribuito così com'è e può essere inserito in repository disponibili per un numero qualsiasi di sistemi. Fare ciò non rientra nell'ambito di questo tutorial, tuttavia, la creazione di un'altra versione del pacchetto non lo è certamente.

Creazione di un'altra versione del pacchetto

Il nostro pacchetto e gli utilissimi script in esso contenuti diventano popolari in pochissimo tempo, considerando che sono raggiungibili ovunque con un semplice yum install admin-scripts all'interno dell'ambiente. Presto ci saranno molte richieste per alcuni miglioramenti:in questo esempio, molti voti provengono da utenti felici che pullnews.sh dovrebbe stampare un'altra riga in esecuzione, questa funzione salverebbe l'intera azienda. Dobbiamo creare un'altra versione del pacchetto, poiché non vogliamo installare un altro script, ma una nuova versione con lo stesso nome e percorso, poiché gli amministratori di sistema della nostra organizzazione fanno già molto affidamento su di esso.

Per prima cosa cambiamo il sorgente di pullnews.sh nelle FONTI a qualcosa di ancora più complesso:

#!/bin/bash
echo "news pulled"
echo "another line printed"
exit 0

Dobbiamo ricreare tar.gz con il nuovo contenuto sorgente:possiamo usare lo stesso nome file della prima volta, poiché non cambiamo versione, solo release (e quindi il Source0 il riferimento sarà ancora valido). Nota che eliminiamo prima l'archivio precedente:

cd rpmbuild/SOURCES/ && rm -f admin-scripts-1.tar.gz && tar -czf admin-scripts-1.tar.gz admin-scripts-1

Ora creiamo un altro specfile con un numero di versione più alto:

cp rpmbuild/SPECS/admin-scripts-1.0.spec rpmbuild/SPECS/admin-scripts-1.1.spec

Non cambiamo molto sul pacchetto stesso, quindi amministriamo semplicemente la nuova versione come mostrato di seguito:

Name:           admin-scripts
Version:        1
Release:        1
Summary:        FooBar Inc. IT dept. admin scripts
Packager:       John Doe 
Group:          Application/Other
License:        GPL
URL:            www.foobar.com/admin-scripts
Source0:        %{name}-%{version}.tar.gz
BuildArch:      noarch

%description
Package installing latest version the admin scripts used by the IT dept.

%prep
%setup -q


%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/sbin
cp scripts/* $RPM_BUILD_ROOT/usr/local/sbin/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
%dir /usr/local/sbin
/usr/local/sbin/parselogs.sh
/usr/local/sbin/pullnews.sh

%doc

%changelog
* Wed Aug 22 2018 John Doe 
- release 1.1 - pullnews.sh v1.1 prints another line
* Wed Aug 1 2018 John Doe 
- release 1.0 - initial release

Fatto ciò, possiamo creare un'altra versione del nostro pacchetto contenente lo script aggiornato. Nota che facciamo riferimento allo specfile con la versione successiva come origine della build:

rpmbuild --bb rpmbuild/SPECS/admin-scripts-1.1.spec

Se la compilazione ha esito positivo, ora abbiamo due versioni del pacchetto nella nostra directory RPMS:

ls rpmbuild/RPMS/noarch/
admin-scripts-1-0.noarch.rpm  admin-scripts-1-1.noarch.rpm

E ora possiamo installare lo script "avanzato" o aggiornarlo se è già installato.

Aggiornamento degli script personalizzati con rpm

E i nostri amministratori di sistema possono vedere che la richiesta di funzionalità è arrivata in questa versione:

rpm -q --changelog admin-scripts
* Wed aug 22 2018 John Doe 
- release 1.1 - pullnews.sh v1.1 prints another line

* Wed aug 01 2018 John Doe 
- release 1.0 - initial release

Conclusione

Abbiamo racchiuso il nostro contenuto personalizzato in pacchetti rpm con versione. Ciò significa che non sono rimaste versioni precedenti sparse tra i sistemi, tutto è al suo posto, sulla versione che abbiamo installato o aggiornato. RPM offre la possibilità di sostituire le vecchie cose necessarie solo nelle versioni precedenti, può aggiungere dipendenze personalizzate o fornire alcuni strumenti o servizi su cui si basano gli altri nostri pacchetti. Con sforzo, possiamo impacchettare quasi tutti i nostri contenuti personalizzati in pacchetti rpm e distribuirli nel nostro ambiente, non solo con facilità, ma con coerenza.