Comment créer des paquets rpm

J'ai utilisé des gestionnaires de paquets basés sur rpm pour installer des logiciels sur Red Hat et Fedora Linux depuis que j'ai commencé à utiliser Linux il y a plus de 20 ans. J'ai utilisé le rpm programme lui-même, miam , et DNF , qui est un proche descendant de yum, pour installer et mettre à jour des packages sur mes hôtes Linux. Les outils yum et DNF sont des wrappers autour de l'utilitaire rpm qui fournissent des fonctionnalités supplémentaires, telles que la possibilité de rechercher et d'installer des dépendances de packages.

Plus de ressources Linux

• Aide-mémoire des commandes Linux
• Aide-mémoire des commandes Linux avancées
• Cours en ligne gratuit :Présentation technique de RHEL
• Aide-mémoire sur le réseau Linux
• Aide-mémoire SELinux
• Aide-mémoire sur les commandes courantes de Linux
• Que sont les conteneurs Linux ?
• Nos derniers articles Linux

Au fil des ans, j'ai créé un certain nombre de scripts Bash, dont certains ont des fichiers de configuration distincts, que j'aime installer sur la plupart de mes nouveaux ordinateurs et machines virtuelles. L'installation de tous ces packages a pris beaucoup de temps. J'ai donc décidé d'automatiser ce processus en créant un package rpm que je pourrais copier sur les hôtes cibles et installer tous ces fichiers à leur emplacement approprié. Bien que le tr/min était auparavant utilisé pour créer des packages rpm, cette fonction a été supprimée et un nouvel outil, rpmbuild, a été créé pour créer de nouveaux RPM.

Quand j'ai commencé ce projet, j'ai trouvé très peu d'informations sur la création de packages rpm, mais j'ai réussi à trouver un livre, Maximum RPM , ça m'a aidé à comprendre. Ce livre est maintenant quelque peu dépassé, tout comme la grande majorité des informations que j'ai trouvées. Il est également épuisé et les exemplaires usagés coûtent des centaines de dollars. La version en ligne de Maximum RPM est disponible gratuitement et est tenue à jour. Le site Web de RPM contient également des liens vers d'autres sites Web contenant de nombreuses documentations sur RPM. Les autres informations disponibles ont tendance à être brèves et supposent apparemment que vous avez déjà une bonne connaissance du processus.

De plus, chacun des documents que j'ai trouvé suppose que le code doit être compilé à partir des sources comme dans un environnement de développement. Je ne suis pas développeur. Je suis un administrateur système et nous, les administrateurs système, avons des besoins différents car nous ne compilons pas - ou nous ne devrions pas - compiler le code à utiliser pour les tâches administratives ; nous devrions utiliser des scripts shell. Nous n'avons donc pas de code source dans le sens où c'est quelque chose qui doit être compilé en exécutables binaires. Ce que nous avons est une source qui est aussi l'exécutable.

Dans la plupart des cas, ce projet doit être réalisé en tant qu'étudiant utilisateur non root. Les Rpms ne doivent jamais être construits par root, mais uniquement par des utilisateurs non privilégiés. J'indiquerai quelles parties doivent être exécutées en tant que root et lesquelles par un utilisateur non root et non privilégié.

Préparation

Tout d'abord, ouvrez une session de terminal et su enraciner. Assurez-vous d'utiliser le - pour vous assurer que l'environnement racine complet est activé. Je ne crois pas que les administrateurs système devraient utiliser sudo pour toutes tâches administratives. Découvrez pourquoi dans mon article de blog personnel :Les vrais administrateurs système ne font pas sudo .

[student@testvm1 ~]$ su -
Mot de passe :
[root@testvm1 ~]#

Créez un utilisateur étudiant qui peut être utilisé pour ce projet et définissez un mot de passe pour cet utilisateur.

[root@testvm1 ~]# useradd -c "Student User" student 
[root@testvm1 ~]# passwd student
Modification du mot de passe de l'utilisateur student.
Nouveau mot de passe :
Retapez le nouveau mot de passe :
passwd :tous les jetons d'authentification ont été mis à jour avec succès.
[root@testvm1 ~]#

La construction de packages rpm nécessite le rpm-build package, qui n'est probablement pas déjà installé. Installez-le maintenant en tant que root. Notez que cette commande installera également plusieurs dépendances. Le nombre peut varier en fonction des packages déjà installés sur votre hôte; il a installé un total de 17 packages sur ma machine virtuelle de test, ce qui est assez minime.

dnf install -y rpm-build 

Le reste de ce projet doit être exécuté en tant qu'étudiant utilisateur, sauf indication contraire explicite. Ouvrez une autre session de terminal et utilisez su pour basculer vers cet utilisateur pour effectuer le reste de ces étapes. Téléchargez une archive que j'ai préparée d'une structure de répertoires de développement, utils.tar, à partir de GitHub à l'aide de la commande suivante :

wget https://github.com/opensourceway/how-to-rpm/raw/master/utils.tar 

Cette archive comprend tous les fichiers et les scripts Bash qui seront installés par le RPM final. Il existe également un fichier de spécifications complet, que vous pouvez utiliser pour créer le rpm. Nous détaillerons chaque section du fichier de spécifications.

En tant qu'utilisateur étudiant, en utilisant votre répertoire personnel comme répertoire de travail actuel (pwd), décompressez l'archive tar.

[student@testvm1 ~]$ cd ; tar -xvf utils.tar  

Utilisez l'tree pour vérifier que la structure du répertoire de ~/development et les fichiers contenus ressemblent à la sortie suivante :

[student@testvm1 ~]$ tree development/
development/
├── license
│   ├── Copyright.and.GPL.Notice.txt
│   └ ── GPL_LICENSE.txt
├── scripts
│   ├── create_motd
│   ├── die
│   ├── mymotd
│   └── sysdata
└── spec
    └── utils.spec

3 répertoires, 7 fichiers
[student@testvm1 ~]$

Le mymotd Le script crée un flux de données "Message du jour" qui est envoyé à stdout. Le create_motd le script exécute le mymotd scripts et redirige la sortie vers le fichier /etc/motd. Ce fichier est utilisé pour afficher un message quotidien aux utilisateurs qui se connectent à distance en utilisant SSH.

Le die script est mon propre script qui enveloppe le kill commande dans un morceau de code qui peut trouver des programmes en cours d'exécution qui correspondent à une chaîne spécifiée et les tuer. Il utilise kill -9 pour s'assurer qu'ils ne peuvent pas ignorer le message de mise à mort.

Les sysdata peut générer des dizaines de milliers de lignes de données sur votre matériel informatique, la version installée de Linux, tous les packages installés et les métadonnées de vos disques durs. Je l'utilise pour documenter l'état d'un hôte à un moment donné. Je peux l'utiliser plus tard comme référence. J'avais l'habitude de le faire pour conserver un enregistrement des hôtes que j'installais pour les clients.

Vous devrez peut-être changer la propriété de ces fichiers et répertoires en étudiant.étudiant. Faites-le, si nécessaire, en utilisant la commande suivante :

chown -R student.student development 

La plupart des fichiers et répertoires de cette arborescence seront installés sur les systèmes Fedora par le rpm que vous créez au cours de ce projet.

Création de la structure du répertoire de construction

Le rpmbuild La commande nécessite une structure de répertoire très spécifique. Vous devez créer vous-même cette structure de répertoire car aucun moyen automatisé n'est fourni. Créez la structure de répertoires suivante dans votre répertoire personnel :

~ ─ rpmbuild
    ├── RPMS
    │   └── noarch
    ├── SOURCES
    ├── SPECS
    └── SRPMS

Nous ne créerons pas le répertoire rpmbuild/RPMS/X86_64 car cela serait spécifique à l'architecture des binaires compilés 64 bits. Nous avons des scripts shell qui ne sont pas spécifiques à l'architecture. En réalité, nous n'utiliserons pas non plus le répertoire SRPMS, qui contiendrait les fichiers source du compilateur.

Examiner le fichier de spécifications

Chaque fichier de spécification comporte un certain nombre de sections, dont certaines peuvent être ignorées ou omises, selon les circonstances spécifiques de la construction rpm. Ce fichier de spécification particulier n'est pas un exemple de fichier minimal requis pour fonctionner, mais c'est un bon exemple de fichier de spécification modérément complexe qui regroupe des fichiers qui n'ont pas besoin d'être compilés. Si une compilation était nécessaire, elle serait effectuée dans le %build section, qui est omise de ce fichier de spécifications car elle n'est pas requise.

Préambule

C'est la seule section du fichier de spécifications qui n'a pas d'étiquette. Il se compose d'une grande partie des informations que vous voyez lorsque la commande rpm -qi [Package Name] est exécuté. Chaque donnée est une ligne unique composée d'une balise qui l'identifie et de données textuelles pour la valeur de la balise.

############################################## ################################
# Fichier de spécifications pour les utilitaires
##### ################################################# #########################
# Configuré pour être construit par l'utilisateur student ou un autre utilisateur non root
### ################################################# ###########################
#
Résumé :Scripts utilitaires pour tester la création de RPM
Nom :utils
Version :1.0.0
Version :1
Licence :GPL
URL :http://www.both.org
Groupe :Système
 Conditionneur :David Both
Nécessite :bash
Nécessite :screen
Nécessite :mc
Nécessite :dmidecode
BuildRoot :~/rpmbuild/

 # Compilez avec la syntaxe suivante :
# rpmbuild --target noarch -bb utils.spec

Les lignes de commentaires sont ignorées par le rpmbuild programme. J'aime toujours ajouter un commentaire à cette section qui contient la syntaxe exacte du rpmbuild commande requise pour créer le package. La balise Summary est une brève description du package. Les balises Name, Version et Release sont utilisées pour créer le nom du fichier rpm, comme dans utils-1.00-1.rpm. L'incrémentation des numéros de release et de version vous permet de créer des RPM qui peuvent être utilisés pour mettre à jour les plus anciens.

La balise License définit la licence sous laquelle le package est publié. J'utilise toujours une variante de la GPL. La spécification de la licence est importante pour clarifier le fait que le logiciel contenu dans le package est open source. C'est aussi pourquoi j'ai inclus la licence et la déclaration GPL dans les fichiers qui seront installés.

L'URL est généralement la page Web du projet ou du propriétaire du projet. Dans ce cas, il s'agit de ma page Web personnelle.

La balise Group est intéressante et est généralement utilisée pour les applications GUI. La valeur de la balise Group détermine quel groupe d'icônes dans le menu des applications contiendra l'icône de l'exécutable dans ce package. Utilisé conjointement avec la balise Icon (que nous n'utilisons pas ici), la balise Group permet d'ajouter l'icône et les informations requises pour lancer un programme dans la structure du menu des applications.

La balise Packager est utilisée pour spécifier la personne ou l'organisation responsable de la maintenance et de la création du package.

Les instructions Requires définissent les dépendances pour ce rpm. Chacun est un nom de package. Si l'un des packages spécifiés n'est pas présent, l'utilitaire d'installation DNF essaiera de le localiser dans l'un des référentiels définis dans /etc/yum.repos.d et de l'installer s'il existe. Si DNF ne peut pas trouver un ou plusieurs des packages requis, il génère une erreur indiquant quels packages sont manquants et se termine.

La ligne BuildRoot spécifie le répertoire de niveau supérieur dans lequel le rpmbuild trouvera le fichier spec et dans lequel il créera des répertoires temporaires pendant qu'il construit le paquet. Le package fini sera stocké dans le sous-répertoire noarch que nous avons spécifié précédemment. Le commentaire montrant la syntaxe de commande utilisée pour construire ce paquet inclut l'option –target noarch , qui définit l'architecture cible. Comme il s'agit de scripts Bash, ils ne sont pas associés à une architecture CPU spécifique. Si cette option était omise, la construction serait ciblée sur l'architecture du processeur sur lequel la construction est effectuée.

Le rpmbuild programme peut cibler de nombreuses architectures différentes, et en utilisant le --target L'option nous permet de construire des packages spécifiques à l'architecture sur un hôte avec une architecture différente de celle sur laquelle la construction est effectuée. Je pourrais donc créer un package destiné à être utilisé sur une architecture i686 sur un hôte x86_64, et vice versa.

Remplacez le nom du packager par le vôtre et l'URL de votre propre site Web si vous en avez un.

%description

Le %description section du fichier spec contient une description du package rpm. Il peut être très court ou contenir de nombreuses lignes d'informations. Notre %description section est plutôt laconique.

%description
Une collection de scripts utilitaires pour tester la création de RPM.

%prep

Le %prep section est le premier script exécuté pendant le processus de génération. Ce script n'est pas exécuté lors de l'installation du package.

Ce script est juste un script shell Bash. Il prépare le répertoire de construction, en créant les répertoires utilisés pour la construction selon les besoins et en copiant les fichiers appropriés dans leurs répertoires respectifs. Cela inclurait les sources requises pour une compilation complète dans le cadre de la construction.

Le répertoire $RPM_BUILD_ROOT représente le répertoire racine d'un système installé. Les répertoires créés dans le répertoire $RPM_BUILD_ROOT sont des chemins complets, tels que /user/local/share/utils, /usr/local/bin, etc., dans un système de fichiers actif.

Dans le cas de notre package, nous n'avons pas de sources de pré-compilation car tous nos programmes sont des scripts Bash. Nous copions donc simplement ces scripts et autres fichiers dans les répertoires auxquels ils appartiennent dans le système installé.

%prep
######################################## #######################################
# Créez l'arbre de construction et copiez les fichiers des répertoires de développement    #
# dans l'arborescence de construction. #
############################################ ###################################
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

sortie

Notez que l'instruction de sortie à la fin de cette section est obligatoire.

%fichiers

Cette section du fichier spec définit les fichiers à installer et leur emplacement dans l'arborescence des répertoires. Il spécifie également les attributs de fichier et le propriétaire et le propriétaire du groupe pour chaque fichier à installer. Les autorisations et les propriétés des fichiers sont facultatives, mais je recommande qu'elles soient explicitement définies pour éliminer tout risque que ces attributs soient incorrects ou ambigus lors de l'installation. Les répertoires sont créés au besoin lors de l'installation s'ils n'existent pas déjà.

%files
%attr(0744, root, root) /usr/local/bin/*
%attr(0644, root, root) /usr/local/share/utils/* 
%pre
 

 Cette section est vide dans le fichier de spécifications de notre projet de laboratoire. Ce serait l'endroit où placer tous les scripts qui doivent s'exécuter pendant l'installation du rpm mais avant l'installation des fichiers.
 
%post
 

 Cette section du fichier spec est un autre script Bash. Celui-ci s'exécute après l'installation des fichiers. Cette section peut contenir à peu près tout ce dont vous avez besoin ou que vous souhaitez, y compris la création de fichiers, l'exécution de commandes système et le redémarrage des services pour les réinitialiser après avoir apporté des modifications à la configuration. Le %post le script de notre package rpm effectue certaines de ces tâches.
 
%post
######################################## ######################################## Configurer les scripts MOTD br />############################################## ################################
cd /etc
# Enregistrez l'ancien MOTD si il existe
if [ -e motd ]
then
   cp motd motd.orig
fi
# Si ce n'est déjà fait, ajoutez le lien vers create_motd à cron.daily
cd /etc/cron.daily
si [ ! -e create_motd ]
then
   ln -s /usr/local/bin/create_motd
fi
# crée le MOTD pour la première fois
/usr/local/ bin/mymotd> /etc/motd
 

 Les commentaires inclus dans ce script doivent clarifier son objectif.
 
%postun
 

 Cette section contient un script qui sera exécuté après la désinstallation du package rpm. L'utilisation de rpm ou DNF pour supprimer un paquet supprime tous les fichiers répertoriés dans le %files section, mais cela ne supprime pas les fichiers ou les liens créés par le %post section, nous devons donc gérer cela dans cette section.
 

 Ce script consiste généralement en des tâches de nettoyage que le simple fait d'effacer les fichiers précédemment installés par le rpm ne peut pas accomplir. Dans le cas de notre forfait, cela inclut la suppression du lien créé par le %post script et restauration de l'original enregistré du fichier motd.
 
%postun
# supprimer les fichiers et les liens installés
rm /etc/cron.daily/create_motd

# Restaurer le MOTD d'origine s'il a été sauvegardé
 si [ -e /etc/motd.orig ]
alors
   mv -f /etc/motd.orig /etc/motd
fi
 
%propre
 

 Ce script Bash effectue un nettoyage après le processus de construction rpm. Les deux lignes dans le %clean la section ci-dessous supprime les répertoires de construction créés par rpm-build commande. Dans de nombreux cas, un nettoyage supplémentaire peut également être nécessaire.
 
%clean
rm -rf $RPM_BUILD_ROOT/usr/local/bin
rm -rf $RPM_BUILD_ROOT/usr/local/share/utils
 
%changelog
 

 Cette section de texte facultative contient une liste des modifications apportées au rpm et aux fichiers qu'il contient. Les modifications les plus récentes sont enregistrées en haut de cette section.
 
%changelog
* Mer 29 août 2018 Votre nom 
  - Le package d'origine comprend plusieurs scripts utiles. il est
    principalement destiné à illustrer le processus de
    création d'un RPM.
 

 Remplacez les données de la ligne d'en-tête par votre propre nom et adresse e-mail.
 
Construire le rpm
 

 Le fichier spec doit se trouver dans le répertoire SPECS de l'arborescence rpmbuild. Je trouve plus simple de créer un lien vers le fichier de spécification réel dans ce répertoire afin qu'il puisse être modifié dans le répertoire de développement et qu'il ne soit pas nécessaire de le copier dans le répertoire SPECS. Faites du répertoire SPECS votre pwd, puis créez le lien.
 
cd ~/rpmbuild/SPECS/
ln -s ~/development/spec/utils.spec
 

 Exécutez la commande suivante pour créer le rpm. La création du rpm ne devrait prendre qu'un instant si aucune erreur ne se produit.
 
rpmbuild --target noarch -bb utils.spec 
 

 Vérifiez dans le répertoire ~/rpmbuild/RPMS/noarch pour vérifier que le nouveau rpm y existe.
 
[student@testvm1 ~]$ cd rpmbuild/RPMS/noarch/
[student@testvm1 noarch]$ ll
total 24
-rw-rw-r--. 1 étudiant étudiant 24364 30 août 10:00 utils-1.0.0-1.noarch.rpm
[student@testvm1 noarch]$
 
Tester le régime
 

 En tant que root, installez le rpm pour vérifier qu'il s'installe correctement et que les fichiers sont installés dans les bons répertoires. Le nom exact du rpm dépendra des valeurs que vous avez utilisées pour les balises dans la section Préambule, mais si vous avez utilisé celles de l'exemple, le nom du rpm sera comme indiqué dans l'exemple de commande ci-dessous :
 
[root@testvm1 ~]# cd /home/student/rpmbuild/RPMS/noarch/
[root@testvm1 noarch]# ll
total 24
-rw-rw-r --. 1 étudiant étudiant 24364 30 août 10:00 utils-1.0.0-1.noarch.rpm
[root@testvm1 noarch]# rpm -ivh utils-1.0.0-1.noarch.rpm
Préparation ...                        ################################ [100 %]
Mise à jour / installation... 
   1:utils-1.0.0-1                    ################################# [100 %] 
 

 Vérifiez /usr/local/bin pour vous assurer que les nouveaux fichiers sont là. Vous devez également vérifier que le lien create_motd dans /etc/cron.daily a été créé.
 

 Utilisez les utilitaires rpm -q --changelog utils commande pour afficher le journal des modifications. Affichez les fichiers installés par le package à l'aide des rpm -ql utils commande (c'est-à-dire un L minuscule dans ql .)
 
[root@testvm1 noarch]# rpm -q --changelog utils
* Mer 29 août 2018 Votre nom 
- Le package d'origine comprend plusieurs scripts utiles. il est
    principalement destiné à être utilisé pour illustrer le processus de
    construction d'un 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]#
 

 Supprimez le paquet.
 
rpm -e utils 
 
Expérimentation
 

 Vous allez maintenant modifier le fichier de spécification pour exiger un package qui n'existe pas. Cela simulera une dépendance qui ne peut pas être satisfaite. Ajoutez la ligne suivante immédiatement sous la ligne Requires existante :
 
Requires: badrequire 
 

 Générez le package et essayez de l'installer. Quel message est affiché ?
 

 Nous avons utilisé le rpm commande pour installer et supprimer les utils emballer. Essayez d'installer le package avec yum ou DNF. Vous devez être dans le même répertoire que le package ou spécifier le chemin d'accès complet au package pour que cela fonctionne.
 
Conclusion
 

 Il existe de nombreuses balises et quelques sections que nous n'avons pas couvertes dans cet aperçu des bases de la création d'un package rpm. Les ressources listées ci-dessous peuvent fournir plus d'informations. Construire des paquets rpm n'est pas difficile; vous avez juste besoin des bonnes informations. J'espère que cela vous aidera ; il m'a fallu des mois pour comprendre les choses par moi-même.
 

 Nous n'avons pas couvert la construction à partir du code source, mais si vous êtes un développeur, cela devrait être une étape simple à partir de ce point.
 

 La création de packages rpm est un autre bon moyen d'être un administrateur système paresseux et d'économiser du temps et des efforts. Il fournit une méthode simple pour distribuer et installer les scripts et autres fichiers que nous, en tant qu'administrateurs système, devons installer sur de nombreux hôtes.
 
Ressources
 
 
 

 Edward C. Baily, Régime maximal , Sams Publishing, 2000, ISBN 0-672-31105-4
 
 
 

 Edward C. Baily, Régime maximal , version en ligne mise à jour
 
 
 

 Documentation RPM :Cette page Web répertorie la plupart de la documentation en ligne disponible pour rpm. Il comprend de nombreux liens vers d'autres sites Web et des informations sur rpm.