Redhat / centos / almalinux

Unification des scripts personnalisés à l'échelle du système avec RPM sur Red Hat / CentOS

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 du contenu personnalisé, des scripts unificateurs sur un certain nombre de systèmes, y compris le versioning, le déploiement et le débit.

Système d'exploitation et versions logicielles

  • Système opérateur: Red Hat Enterprise Linux 7.5
  • Logiciel: rpm-build 4.11.3+

Exigences

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

Difficulté

MOYEN

Conventions

  • # - Exige que les commandes Linux soient exécutées avec des privilèges racine soit directement en tant qu'utilisateur racine, soit par l'utilisation de Sudo commande
  • $ - Étant donné les commandes Linux à exécuter en tant qu'utilisateur non privilégié régulier

Introduction

L'une des caractéristiques principales de tout système Linux est qu'ils sont conçus pour l'automatisation. Si une tâche peut avoir besoin d'être exécutée plus d'une fois - même avec une partie de celle-ci, il est en train de changer la prochaine exécution - un système est fourni d'innombrables outils pour l'automatiser, à partir de simple coquille Les scripts exécutés à la main sur demande (éliminant ainsi les erreurs de faute cron À un moment spécifié, en interagissant les uns avec les autres, en travaillant avec le résultat d'un autre script, peut-être contrôlé par un système de gestion central, etc.

Bien que cet ensemble de liberté et d'outils riches ajoute en effet à la productivité, il y a une prise: en tant que système, vous écrivez un script utile sur un système, qui s'avère utile sur un autre, donc vous copiez le script sur. Sur un troisième système, le script est également utile, mais avec une modification mineure - 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 complétez la tâche pour laquelle pour laquelle il a été écrite. Maintenant, vous avez deux versions du script, la première est sur les deux premiers systèmes, le deuxième 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. Sur le déploiement du système suivant, vous avez besoin d'une fonctionnalité que vous vous souvenez que vous avez codé dans une version, mais qui? Et sur quels systèmes sont-ils?

Sur les systèmes basés sur RPM, tels que les saveurs de Red Hat, un Sysadmin peut profiter du gestionnaire de packages pour créer une commande dans le contenu personnalisé, y compris des scripts de shell simples qui peuvent ne pas fournir d'autre que les outils que l'administrateur a écrits pour la commodité.

Dans ce tutoriel, nous créerons un régime personnalisé pour Red Hat Enterprise Linux 7.5 contenant deux frapper scripts, parlelogs.shot et pull.shot pour fournir un moyen 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 devrait être la même que les systèmes que le package 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 de différentes distributions avec de nombreuses versions dans votre environnement (oh, joie!), vous devez configurer des machines de construction pour chaque. Pour couper le travail court, vous pouvez simplement configurer un environnement de construction pour chaque distribution et chaque version principale, et les avoir sur la version mineure la plus basse existant dans votre environnement pour la version majeure donnée. Parce qu'ils n'ont pas besoin d'être des machines physiques et n'ont besoin que de fonctionner 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éploiez que deux scripts qui n'ont aucune dépendance (sauf frapper), donc nous allons construire noarch packages qui représentent «non l'architecture dépendante», nous ne spécifierons pas non plus la distribution pour laquelle le package est conçu pour. De cette façon, nous pouvons les installer et les mettre à niveau sur toute distribution utilise RPM, Et à n'importe quelle version - nous devons seulement nous assurer que la machine de construction rpm-build Le package est sur la version la plus ancienne de l'environnement.

Configuration de l'environnement de construction

Pour créer des packages RPM personnalisés, nous devons installer le rpm-build emballer:

# yum installer rpm-build

A partir de maintenant, nous ne pas utiliser racine utilisateur, et pour une bonne raison. Les forfaits de construction ne nécessitent pas racine privilège, et vous ne voulez pas casser votre machine de construction.

Construire la première version du package

Créons la structure du répertoire nécessaire pour la construction:

$ mkdir -p rpmbuild / spécifications

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 fichier texte simple que nous pouvons créer avec notre éditeur de texte préféré, comme vi. Le précédemment installé rpmbuild Le package remplira votre spécifile vide avec des données de modèle si vous utilisez vi Pour en créer un vide, mais pour ce tutoriel, considérez les spécifications ci-dessous appelées admin-scripts-1.0.spécifier:

Nom: Admin-Scripts Version: 1 version: 0 Résumé: Foobar Inc. Il dépasse. Admin Scripts Packager: John Doe Group: Application / autre Licence: GPL URL: www.foobar.com / admin-scripts source0:% name -% version.le goudron.GZ Buildarch: Noarch% Description Package Installation de la dernière version Les scripts d'administration utilisés par le département informatique. % prep% Configuration -Q% build% installer rm -rf $ rpm_build_root mkdir -p $ rpm_build_root / usr / local / sbin cp scripts / * $ rpm_build_build_root% fichiers%% defattr (-, racine, racine, -)% dir / usr / local / sbin / usr / local / sbin / parselogs.sh / usr / local / sbin / pullnews.sh% doc% changelog * mer 1 août 2018 John Doe - version 1.0 - version initiale
Copie

Placer le spécifile dans le rpmbuild / spec Répertoire que nous avons créé plus tôt.

Nous avons besoin des sources référencées dans le specfile - Dans ce cas, les deux scripts shell. Créons le répertoire des sources (appelé nom du package annexé avec la version principale):

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

Et copier / déplacer les scripts dedans:

$ ls rpmbuild / sources / admin-scripts-1 / scripts / parselogs.sh PullNews.shot
Copie

Comme ce tutoriel ne concerne pas les scripts de coquille, le contenu de ces scripts n'est pas pertinent. Comme nous créerons une nouvelle version du package et le pull.shot est le script avec lequel nous allons démontrer, sa source dans la première version est comme ci-dessous:

#!/ bin / bash echo "News tire" sortie 0
Copie

N'oubliez pas d'ajouter les droits appropriés aux fichiers dans la source - dans notre cas, correcte d'exécution:

chmod + x rpmbuild / sources / admin-scripts-1 / scripts / *.shot


Maintenant, nous créons un le goudron.gz Archives de la source dans le même répertoire:

CD RPMBUILD / SOURCES / && TAR -CZF Admin-Scripts-1.le goudron.GZ Admin-Scripts-1
Copie

Nous sommes prêts à construire le package:

RPMBUILD --BB RPMBUILD / Specs / Admin-Scripts-1.0.spécifier

Nous obtiendrons une certaine sortie sur la construction, et si quelque chose ne va pas, les erreurs seront affichées (par exemple, un fichier ou un chemin manquant). Si tout se passe bien, notre nouveau package apparaîtra dans le répertoire RPMS généré par défaut sous le rpmbuild Répertoire (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 plus tôt:

$ rpm -qpi rpmbuild / rpms / noarch / admin-scripts-1-0.noarch.RPM Nom: Admin-Scripts Version: 1 Release: 0 Architecture: Noarch Installation Date: (non installée) Groupe: Application / Autre taille: 78 Licence: GPL Signature: (Aucun) Source RPM: Admin-Scripts-1-0.SRC.RPM Date de construction: 2018. août. 1., Mer, 13.27.34 CEST Build Host: Build01.foobar.Com relocations: (non relocalisable) Packager: John Doe URL: www.foobar.com / admin-scripts Résumé: Foobar Inc. Il dépasse. Scripts d'administration Description: Package Installation de la dernière version Les scripts d'administration utilisés par le département informatique.
Copie


Et car nous pouvons l'installer (avec racine privilèges):

Installation de scripts personnalisés avec RPM

Comme nous avons installé les scripts dans un répertoire qui se trouve sur chaque utilisateur $ Chemin, Vous pouvez les exécuter comme n'importe quel utilisateur du système, à partir de n'importe quel répertoire:

$ pullnews.sh News tiré
Copie


Le package peut être distribué tel quel et peut être poussé dans des référentiels disponibles pour un certain nombre de systèmes. Pour ce faire, c'est hors de l'étendue de ce tutoriel - cependant, la construction d'une autre version du package n'est certainement pas.

Construire une autre version du package

Notre package et les scripts extrêmement utiles deviennent populaires en un rien de temps, étant donné qu'ils sont accessibles n'importe où avec un simple yum install admin-scripts dans l'environnement. Il y aura bientôt de nombreuses demandes d'améliorations - dans cet exemple, de nombreux votes proviennent des utilisateurs heureux que le pull.shot Si vous imprimez une autre ligne lors de l'exécution, cette fonctionnalité économiserait toute la société. Nous devons créer une autre version du package, car nous ne voulons pas installer un autre script, mais une nouvelle version de celle-ci avec le même nom et le même chemin, car les systèmes de notre organisation comptent déjà fortement sur celui-ci fortement.

Nous changeons d'abord la source du pull.shot Dans les sources de quelque chose de plus complexe:

#!/ bin / bash echo "News a tiré" echo "une autre ligne imprimée" sortie 0

Nous devons recréer le goudron.GZ avec le nouveau contenu de source - nous pouvons utiliser le même nom de fichier que la première fois, car nous ne changeons pas la version, seule (et donc le Source0 La référence sera toujours valide). Notez que nous supprimons d'abord les archives précédentes:

cd rpmbuild / sources / && rm -f admin-scripts-1.le goudron.gz && tar -czf admin-scripts-1.le goudron.GZ Admin-Scripts-1
Copie

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.spécifier
Copie

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

Nom: Admin-Scripts Version: 1 Libération: 1 Résumé: Foobar Inc. Il dépasse. Admin Scripts Packager: John Doe Group: Application / autre Licence: GPL URL: www.foobar.com / admin-scripts source0:% name -% version.le goudron.GZ Buildarch: Noarch% Description Package Installation de la dernière version Les scripts d'administration utilisés par le département informatique. % prep% Configuration -Q% build% installer rm -rf $ rpm_build_root mkdir -p $ rpm_build_root / usr / local / sbin cp scripts / * $ rpm_build_build_root% fichiers%% defattr (-, racine, racine, -)% dir / usr / local / sbin / usr / local / sbin / parselogs.sh / usr / local / sbin / pullnews.sh% doc% changelog * Mer 22 août 2018 John Doe  - version 1.1 - PullNews.SH V1.1 imprime une autre ligne * Mer 1 août 2018 John Doe - version 1.0 - version initiale

Tout fait, nous pouvons créer une autre version de notre package contenant le script mis à jour. Notez que nous faisons référence au SpecFile avec la version supérieure comme source de la construction:

RPMBUILD --BB RPMBUILD / Specs / Admin-Scripts-1.1.spécifier

Si la construction est réussie, 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.noarch.RPM
Copie

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

Mise à niveau des scripts personnalisés avec RPM

Et nos systèmes système peuvent voir que la demande de fonctionnalité est décrochée dans cette version:

RPM -Q - Changelog Admin-Scripts * mer 22 août 2018 John Doe - version 1.1 - PullNews.SH V1.1 Imprime une autre ligne * Mer 01 août 2018 John Doe - version 1.0 - version initiale

Conclusion

Nous avons enveloppé notre contenu personnalisé dans des packages RPM versés. Cela signifie qu'aucune ancienne versions laissées dispersées sur les systèmes, tout est à sa place, sur la version que nous avons installée ou mise à niveau pour. 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 des outils ou des services sur lesquels notre autre package reposait. Avec l'effort, nous pouvons emballer presque n'importe lequel de nos contenus personnalisés dans des packages RPM et le distribuer dans notre environnement, non seulement avec facilité, mais avec la cohérence.

Tutoriels Linux connexes:

  • Choses à installer sur Ubuntu 20.04
  • Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
  • Fichiers de configuration Linux: 30 premiers
  • Une introduction à l'automatisation Linux, des outils et des techniques
  • Téléchargement Linux
  • Linux peut-il obtenir des virus? Exploration de la vulnérabilité de Linux…
  • Choses à faire après l'installation d'Ubuntu 22.04 Jammy Jellyfish…
  • Meilleure distribution Linux pour les développeurs
  • Ubuntu 20.04 Guide
  • Comment migrer de Centos à Almaliux