Unification des 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 un nombre illimité de systèmes, y compris la gestion des versions, le déploiement et l'annulation du déploiement.

Versions du système d'exploitation et du logiciel

• 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é

MOYEN

Congrès

• # - 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 sudo commande
• $ – commandes linux données à exécuter en tant qu'utilisateur normal non privilégié

Présentation

L'une des principales caractéristiques de tout système Linux est qu'il est conçu pour l'automatisation. Si une tâche peut avoir besoin d'ê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, à partir d'un simple shell des scripts exécutés à la main à la demande (éliminant ainsi les erreurs de frappe ou n'enregistrant que quelques frappes au clavier) vers des systèmes scriptés complexes où les tâches s'exécutent à partir de cron à un moment précis, interagissant les uns avec les autres, travaillant avec le résultat d'un autre script, peut-être contrôlé par un système de gestion central, etc.

Bien que cette liberté et cet ensemble d'outils riches augmentent 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, 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 est 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 rappelez avoir codée dans une version, mais laquelle ? Et sur quels systèmes sont-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 packages pour créer un ordre dans le contenu personnalisé, y compris de simples scripts shell qui ne fournissent peut-être pas d'autres outils que les outils que l'administrateur a écrits pour plus de commodité.

Dans ce didacticiel, nous allons créer un RPM personnalisé pour Red Hat Enterprise Linux 7.5 contenant deux bash scripts, parselogs.sh et pullnews.sh pour fournir un moyen pour que tous les systèmes aient la dernière version de ces scripts dans le /usr/local/sbin répertoire, 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 majeure de la machine de construction doit être la même 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 construction pour chacune. Pour raccourcir le travail, vous pouvez simplement configurer l'environnement de construction 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. Bien sûr, ils n'ont pas besoin d'être des machines physiques et ne doivent être exécutés qu'au moment de la construction, 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 (sauf bash ), nous allons donc construire noarch packages qui signifient "non dépendant de l'architecture", nous ne spécifierons pas non plus la distribution pour laquelle le package est construit. De cette façon, nous pouvons les installer et les mettre à jour sur n'importe quelle distribution qui utilise rpm , et à n'importe quelle version - nous devons seulement nous assurer que le rpm-build de la machine de construction le package est sur la version la plus ancienne de l'environnement.

Configuration de l'environnement du bâtiment

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

# yum install rpm-build

A partir de maintenant, nous n'utilisons plus root utilisateur, et pour une bonne raison. La création de packages ne nécessite pas root privilège, et vous ne voulez pas casser votre machine de construction.

Construire la première version du package

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

$ mkdir -p rpmbuild/SPECS

Notre package s'appelle admin-scripts, version 1.0. Nous créons un 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 rpmbuild précédemment installé package remplira votre fichier de spécifications 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 rpmbuild/SPEC répertoire que nous avons créé précédemment.

Nous avons besoin des sources référencées dans le specfile – dans ce cas les deux scripts shell. Créons le répertoire pour les sources (appelé comme le nom du package 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 didacticiel ne concerne pas les scripts shell, le contenu de ces scripts n'est pas pertinent. Comme nous allons créer une nouvelle version du package, et le pullnews.sh est le script avec lequel nous allons démontrer, 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 un tar.gz archive depuis 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 à créer 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, fichier ou 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 rpmbuild répertoire (classé 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 on peut l'installer (avec root privilèges):

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 en tant que n'importe quel utilisateur du système, à partir de n'importe quel répertoire :

$ pullnews.sh 
news pulled




Le package peut être distribué tel quel et peut être poussé dans des référentiels disponibles pour n'importe quel nombre de systèmes. Cela n'entre pas dans le cadre de ce didacticiel - cependant, la construction d'une autre version du package ne l'est certainement pas.

Construire une autre version du package

Notre package 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 un simple yum install admin-scripts au sein de 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 à l'exécution, cette fonctionnalité sauverait toute l'entreprise. Nous devons créer une autre version du package, car nous ne voulons pas installer un autre script, mais une nouvelle version avec le même nom et le même chemin, car les administrateurs système de notre organisation en dépendent déjà beaucoup.

Nous changeons d'abord la source du pullnews.sh dans les SOURCES à 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 la version (et donc le Source0 référence 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

Nous créons maintenant un autre fichier de spécifications 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 au package 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 créer une autre version de notre package contenant le script mis à jour. Notez que nous référençons le fichier de spécifications avec la version supérieure comme source de la construction :

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

Si la construction réussit, nous avons maintenant deux versions du package dans 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 mettre à niveau s'il est déjà installé.

Mise à jour de scripts personnalisés avec rpm

Et nos administrateurs système peuvent voir que la demande de fonctionnalité est arrivée 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 intégré notre contenu personnalisé dans des packages RPM versionnés. Cela signifie qu'aucune version plus ancienne n'est éparpillée 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 les anciens éléments nécessaires uniquement dans les versions précédentes, peut ajouter des dépendances personnalisées ou fournir certains outils ou services sur lesquels reposent nos autres packages. Avec des efforts, nous pouvons emballer presque n'importe quel contenu personnalisé dans des packages rpm et le distribuer dans notre environnement, non seulement facilement, mais avec cohérence.