Unifier les scripts personnalisés à l’échelle du système avec rpm sur Red Hat/CentOS

Objectif

Notre objectif est de créer des packages rpm avec un contenu personnalisé, en unifiant les scripts sur n’importe quel nombre de systèmes, y compris la gestion des versions, le déploiement et le dédéploiement.

Système d’exploitation et versions logicielles

Système d’exploitation: Red Hat Enterprise Linux 7.5
Logiciel : rpm-build 4.11.3+

Exigences

Accès privilégié au système pour l’installation, accès normal pour la construction.

Difficulté

DOULEUR MOYENNE

Conventions

# – nécessite que les commandes Linux données soient exécutées avec les privilèges root, soit directement en tant qu’utilisateur root, soit en utilisant la commande sudo
$ – commandes linux données à exécuter en tant qu’utilisateur régulier non privilégié

Introduction

L’une des principales caractéristiques de tout système Linux est qu’il est conçu pour l’automatisation. Si une tâche doit être exécutée plus d’une fois – même si une partie de celle-ci change lors de la prochaine exécution – un administrateur système dispose d’innombrables outils pour l’automatiser, des simples scripts shell exécutés à la main à la demande (éliminant ainsi les fautes de frappe, ou n’enregistrant que quelques coups de clavier) aux systèmes de script complexes où les tâches s’exécutent à partir de cron à un moment précis, en interagissant les uns avec les autres, en travaillant avec le résultat d’un autre script, éventuellement contrôlé par un système de gestion central, etc.

Bien que cette liberté et cet ensemble d’outils riches contribuent effectivement à la productivité, il y a un hic : en tant qu’administrateur système, vous écrivez un script utile sur un système, qui s’avère utile sur un autre, et vous copiez donc le script. Sur un troisième système, le script est également utile, mais avec des modifications mineures – peut-être une nouvelle fonctionnalité utile uniquement dans ce système, accessible avec un nouveau paramètre. Généralisation à l’esprit, vous étendez le script pour fournir la nouvelle fonctionnalité et terminez également la tâche pour laquelle il a été écrit. Vous avez maintenant deux versions du script, la première sur les deux premiers systèmes, la seconde sur le troisième système.

Vous avez 1024 ordinateurs en cours d’exécution dans le centre de données, et 256 d’entre eux auront besoin de certaines des fonctionnalités fournies par ce script. Avec le temps, vous aurez 64 versions du script partout, chaque version faisant son travail. Lors du prochain déploiement du système, vous avez besoin d’une fonctionnalité que vous vous souvenez avoir codée à une certaine version, mais laquelle ? Et sur quels systèmes se trouvent-ils ?

Sur les systèmes basés sur RPM, tels que les versions Red Hat, un administrateur système peut tirer parti du gestionnaire de paquets pour créer de l’ordre dans le contenu personnalisé, y compris des scripts shell simples qui peuvent ne pas fournir d’autre que les outils que l’administrateur a écrits pour plus de commodité.

Dans ce tutoriel, nous allons créer un rpm personnalisé pour Red Hat Enterprise Linux 7.5 contenant deux scripts bash, parselogs.sh et pullnews.sh pour permettre à tous les systèmes d’avoir la dernière version de ces scripts dans le répertoire /usr/local/sbin, et donc sur le chemin de tout utilisateur qui se connecte au système.

Distributions, versions majeures et mineures

En général, la version mineure et la version majeure de la machine de compilation doivent être les mêmes que les systèmes sur lesquels le paquet doit être déployé, ainsi que la distribution pour assurer la compatibilité. S’il existe différentes versions d’une distribution donnée, ou même différentes distributions avec de nombreuses versions dans votre environnement (oh, joie !), vous devez configurer des machines de compilation pour chacune. Pour écourter le travail, vous pouvez simplement configurer l’environnement de génération pour chaque distribution et chaque version majeure, et les avoir sur la version mineure la plus basse existant dans votre environnement pour la version majeure donnée. En effet, ils n’ont pas besoin d’être des machines physiques, et doivent seulement s’exécuter au moment de la génération, vous pouvez donc utiliser des machines virtuelles ou des conteneurs.

Dans ce tutoriel, notre travail est beaucoup plus facile, nous ne déployons que deux scripts qui n’ont aucune dépendance du tout (sauf bash), nous allons donc construire des paquets noarch qui signifient « non dépendant de l’architecture », nous ne spécifierons pas non plus pour quelle distribution le paquet est construit. De cette façon, nous pouvons les installer et les mettre à jour sur n’importe quelle distribution qui utilise rpm, et vers n’importe quelle version - nous devons seulement nous assurer que le paquet rpm-build de la machine de compilation est sur la version la plus ancienne de l’environnement.

Mise en place de l’environnement du bâtiment

Pour construire des packages rpm personnalisés, nous devons installer le package rpm-build :

yum install rpm-build

Désormais, nous n’utilisons plus l’utilisateur root, et pour une bonne raison. La création de packages ne nécessite pas de privilège root et vous ne voulez pas casser votre machine de construction.

Génération de la première version du package

Créons la structure de répertoire nécessaire à la construction :

mkdir -p rpmbuild/SPECS

Notre package s’appelle admin-scripts, version 1.0. Nous créons un fichier specfile qui spécifie les métadonnées, le contenu et les tâches effectuées par le package. Il s’agit d’un simple fichier texte que nous pouvons créer avec notre éditeur de texte préféré, tel que vi. Le paquet rpmbuild précédemment installé remplira votre fichier specfile vide avec des données de modèle si vous utilisez vi pour en créer un vide, mais pour ce tutoriel, considérez la spécification ci-dessous appelée 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

Placez le fichier spec dans le répertoire rpmbuild/SPEC que nous avons créé précédemment.

Nous avons besoin des sources référencées dans le fichier spec – dans ce cas, les deux scripts shell. Créons le répertoire des sources (appelé nom de paquet ajouté à la version principale) :

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

Et copiez/déplacez les scripts dedans :

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

Comme ce tutoriel ne concerne pas les scripts shell, le contenu de ces scripts n’est pas pertinent. Comme nous allons créer une nouvelle version du paquet, et que la pullnews.sh est le script avec lequel nous allons faire la démonstration, sa source dans la première version est comme ci-dessous :

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

N’oubliez pas d’ajouter les droits appropriés aux fichiers dans la source – dans notre cas, le droit d’exécution :

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

Maintenant, nous créons une archive tar.gz à partir de la source dans le même répertoire :

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

Nous sommes prêts à construire le package :

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

Nous obtiendrons une sortie sur la construction, et si quelque chose ne va pas, des erreurs seront affichées (par exemple, un fichier ou un chemin manquant). Si tout se passe bien, notre nouveau paquet apparaîtra dans le répertoire RPMS généré par défaut sous le répertoire rpmbuild (trié en sous-répertoires par architecture) :

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

Nous avons créé un package rpm simple mais entièrement fonctionnel. Nous pouvons l’interroger pour toutes les métadonnées que nous avons fournies précédemment :

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.

Et bien sûr, nous pouvons l’installer (avec les privilèges root) :

Installation de scripts personnalisés avec rpm

Comme nous avons installé les scripts dans un répertoire qui se trouve sur le ` PATH de chaque utilisateur, vous pouvez les exécuter comme n’importe quel utilisateur du système, à partir de n’importe quel répertoire :

pullnews.sh 
news pulled

Le paquet peut être distribué tel quel et peut être poussé dans des dépôts disponibles pour n’importe quel nombre de systèmes. Le faire n’entre pas dans le cadre de ce tutoriel – cependant, la construction d’une autre version du paquet ne l’est certainement pas.

Construire une autre version du package

Notre paquet et les scripts extrêmement utiles qu’il contient deviennent populaires en un rien de temps, étant donné qu’ils sont accessibles n’importe où avec une simple installation de scripts d’administration dans l’environnement. Il y aura bientôt de nombreuses demandes d’améliorations – dans cet exemple, de nombreux votes proviennent d’utilisateurs satisfaits que le pullnews.sh devrait imprimer une autre ligne lors de l’exécution, cette fonctionnalité sauverait toute l’entreprise. Nous devons construire une autre version du package, car nous ne voulons pas installer un autre script, mais une nouvelle version de celui-ci avec le même nom et le même chemin, car les administrateurs système de notre organisation s’y fient déjà beaucoup.

Tout d’abord, nous changeons la source du pullnews.sh dans les SOURCES en quelque chose d’encore plus complexe :

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

Nous devons recréer le tar.gz avec le nouveau contenu source - nous pouvons utiliser le même nom de fichier que la première fois, car nous ne changeons pas de version, seulement release (et donc la référence Source0 sera toujours valide). Notez que nous supprimons d’abord l’archive précédente :

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

Maintenant, nous créons un autre specfile avec un numéro de version plus élevé :

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

Nous ne changeons pas grand-chose sur le paquet lui-même, nous administrons donc simplement la nouvelle version comme indiqué ci-dessous :

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

Une fois terminé, nous pouvons construire une autre version de notre package contenant le script mis à jour. Notez que nous référençons le fichier spec avec la version supérieure comme source de la compilation :

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

Si la compilation réussit, nous avons maintenant deux versions du paquet sous notre répertoire RPMS :

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

Et maintenant, nous pouvons installer le script « avancé », ou le mettre à jour s’il est déjà installé.

Mise à niveau des scripts personnalisés avec rpm

Et nos administrateurs système peuvent voir que la demande de fonctionnalité est atterrie dans cette version :

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

Conclusion

Nous avons encapsulé notre contenu personnalisé dans des packages rpm versionnés. Cela signifie qu’il n’y a pas d’anciennes versions éparpillées sur les systèmes, tout est à sa place, sur la version que nous avons installée ou mise à niveau. RPM donne la possibilité de remplacer d’anciens éléments nécessaires uniquement dans les versions précédentes, peut ajouter des dépendances personnalisées ou fournir des outils ou des services sur lesquels nos autres packages s’appuient. Avec des efforts, nous pouvons emballer presque n’importe quel contenu personnalisé dans des packages rpm et le distribuer dans notre environnement, non seulement avec facilité, mais aussi avec cohérence.