gerald06
Bonjour à tous,
depuis quelques mois, je me suis mis à comprendre et créer des RPMs. Après quelques galères, je commence à bien comprendre ce qu'il faut mettre dans le fichier .spec pour construire mon RPM.
J'y arrive très bien.
Maintenant, je souhaiterai créer des RPM de mise à jour. J'y arrive très bien également mais j'ai quelques soucis pour la gestion des maj. J'aimerai quelques conseils pour adopter la bonne méthode.
Voici un exemple basique sur lequel je travaille.
1- Voici ce que fait mon RPM:
- J'ai un fichier source.tar.gz qui contient des images et des fichiers
- Il contient des fichiers texte que je souhaite mettre dans un répertoire DOCs
- Il contient des images que je souhaite mettre dans un répertoire IMAGES
- Il contient un répertoire /appli2/
Le RPM créé permet à l'installation d'avoir l'arborescence:
/appli1/DOCs
/appli1/IMAGES
Les fichiers étant mis dans les répertoires respectifs
2- Voici ce que fait mon RPM en mise à jour:
- J'ai un fichier .mp3 que je souhaite mettre dans un répertoire MUSIQUES
- Le RPM aura l'arborescence /appli1/MUSIQUES
La mise à jour du second RPM, me permet d'avoir:/appli2/MUSIQUES
mais... /appli1/DOCs et /appli1/IMAGES disparaissent automatiquement
Voici mes questions, pour avoir les 3 répertoires MUSIQUES, IMAGES et DOCs
- Dois-je relivrer dans mon paquet de mise à jour, les fichiers du premier RPM?
- Dois-je prévoir des sauvegardes avant mise à jour?
- Dois-je déplacer les fichiers initial avant de les repositionner au bon endroit?
- Ne faut-il pas que je crée un script qui déplace, sauvegarde ou copie les fichiers du premier RPM?
Je vous remercie de l'aide apportée
Cordialement
gerald06
madko
Bonjour,
Et faire des rpms différents ce serait pas plus simple? un rpm qui s'occupe de appli1, un autre de appli2 etc. Tu peux en plus faire ça a partir d'un seul srpm. Sinon tu vas vraiment faire des cas complexes à gérer.
pingou
La mise à jour d'un RPM en général c'est juste mettre à jour la version, la release (éventuellement) et la liste de fichiers dans %files si elle a changé.
J'ai l'impression que tu fait un spec différent pour ce que tu appelles un RPM de mise à jour.
Si tu veux rajouter un fichier dans un RPM, tu prend le spec, change la release, ajoute la source, installe le fichier et ajuste %files et voila 🙂
gerald06
Merci pour vos réponses.
Pour préciser à Madko (que je remercie de sa réponse), mon exemple n'est qu'un cas pour expliquer ma problématique des mises à jour.
Donc, si j'analyse bien vos réponses, le principe d'une mise à jour de RPM s'est de reprendre le .spec de l'ancienne version en y ajoutant les nouveautés et en éventuellement en supprimer.
C'est un peu ce que je pensais mais je n'en étais pas 100% convaincu. Précédemment, je me disais qu'une mise à jour pourrait correspondre à simplement la livraison d'un fichier.
Maintenant, cela m'éclaire bien.
J'ai une question complémentaire concernant les mises à jour.
Conservons l'exemple précédent.
1- je fais l'installation du premier RPM
Les fichiers se déploient où le RPM le leur demande
Dans le répertoire DOCS j'ai un fichier toto.txt, que je vais modifier après installation soit manuellement, soit par script. Bref le fichier est personnalisé.
2- je fais ma mise à jour via le second RPM :
a- Si je reprends la réponse de Pingou, je dois relivrer le fichier toto.txt dans mon RPM de mise à jour. Celui-ci n'écrasera-t-il pas le fichier toto.txt contenant les modifications? et donc ne me retrouverais je pas avec un fichier toto.txt initial? Dois-je faire une sauvegarde au préalable pour qu'en post installation le fichier toto.txt soit recopié?
b- Si je ne relivre pas le fichier toto.txt dans le paquet de mise à jour, je ne vais le mettre dans la partie %file. Ma mise à jour du RPM ne risque-t-elle pas de supprimer automatiquement le fichier toto.txt?
Je site cet exemple, car si j'ai bien compris, dans le cas d'une mise à jour, la procédure d'installation s'effectue en premier.
La procédure de désinstallation de la version précédente s'effectue ensuite., et risque de supprimer des fichiers et/ou répertoire nécessaire
Merci pour vos réponses
Cordialment
Gérald
pingou
Tu peux marquer certain fichier dans ton fichier spec pour qu'il ne soit pas écraser lors de la mise à jour.
Pour cela tu mets devant le fichier dans la section %files
%config(noreplace)
Par exemple:
%config(noreplace)%{_sysconfdir}/gitweb.conf
gerald06
Effectivement, je viens de tester cette commande.
Cela est vraiment très intéressant
J'avance.
madko
%config(noreplace) te feras un .rpmnew du fichier du rpm
%config posera le fichier du rpm et te feras une copie du fichier déjà présent en .rpmsave
Tout ça si le fichier cible a été modifié. D'où l'intérêt d'avoir une liste bien propre des fichiers apportés par le RPM (il stock une somme de controle pour savoir si le fichier a été modifié)
RPMnoobs
Bonjour,
Je me permets de up cette discussion car j'ai le même problème que Gérald a rencontré en 2014.
Je comprends toutes vos réponses mais mon cas est un peu plus complexe.
L'application que je veux mettre en place et installer via RPM est très lourde.
C'est pour cela que j'aimerai distinguer 2 modes bien différents.
En mode première installation ou changement de version, l'arborescence entière de l'application est livrée.
En mode mise à jour, le nouveau fichier ou encore les fichiers modifiés sont livrés seuls.
Comme vous pouvez le voir cela pose problème lors des mises à jour, car RPM supprime l'ancienne version/release.
Je ne peux pas me permettre de faire différents .rpm (un pour mise à jour, un pour première install,...).
Je ne peux pas non plus utiliser les Deltas RPM car cela nécessiterai plusieurs manipulations côté clients.
Je veux éviter d'utiliser des patchs.
N'y a t-il aucune solution pour livrer LE fichier modifié, supprimé ou ajouté sans devoir livrer le paquet entier et sous les même RPM?
Je vous remercie d'avance pour vos réponses et je m'excuse si ma question est un peu floue..
Cordialement,
Théo
remi
> Je ne peux pas non plus utiliser les Deltas RPM car cela nécessiterai plusieurs manipulations côté clients.
Ben non, c'est automatique (c'est juste le dépôt qui doit fournir les drpm).
> L'application que je veux mettre en place et installer via RPM est très lourde.
Elle doit sans doute pouvoir être décomposée en différents composants, chacun distribué dans son RPM, et chacun ayant son cycle de vie.
Après... très lourde... ça veux dire quoi ? (j'ai du mal à comprendre où est vraiment le problème)
RPMnoobs
Merci remi pour ta réponse.
"L'application est très lourde", ce que je veux dire par là, c'est que son arborescence est assez importante.
En fait, pour simplifier le truc, je dois trouver une solution permettant de gérer les mises à jour en ne devant pas envoyer les sources complètes en .rpm à chaque fois.
Je me suis penché sur ces .drpm, à ce que j'ai compris, la seule manière de les installer est yum.
Mais certains clients ne dispose pas de distribution qui intègre yum (comme AIX par exemple), même si une install est toujours possible..
madko
Une arborescence assez importante ? Ce n'est toujours pas un soucis, regarde les appli complexes comme postgres, oracle etc elles sont pourtant packagées comme il faut en RPM.
Il faudrait voir version de RPM sur tes AIX car en fonction de celle-ci le payload (la taille max) du rpm peut varier. Depuis un moment on est autour des 5Go. C'est dans ce genre de grandeur que ton appli se situe ?
Ensuite a part faire comme remi l'a suggéré et découper ton appli en composant il n'y aura pas de solution miracle.
RPMnoobs
Bonjour,
Je reviens sur cette discussion car je m'étais mal exprimé sur mon besoin, je viens de relire la discussion.
En fait, je ne peux pas relivrer le paquet entier avec les fichiers non modifiés, tout simplement car RPM nettoie/supprime l'ancienne version, et cela dérange les clients.
Le fait d'écraser des fichiers non modifiés dérangent les clients et cela n'est pas possible, car il faudrait arrêter et redémarrer l'application.
Votre première solution a l'air d'être la meilleure : découper le RPM en plusieurs parties, ou bien gérer via les .drpm.
Merci pour vos réponses qui datent de maintenant 1 mois, je ne les avais pas tout à fait assimilé à l'époque. 😃
gerald06
Bonjour,
je reviens sur vos contributions... et oui cela fait longtemps et j'ai perdu un peu le fil.
Pour information, j'avais construit un RPM que j'ai installé dans divers environnements dont un de production.
Cela fonctionne parfaitement.
Entre temps des mises à jour ont été nécessaire afin de modifier des fichiers ou pour en ajouter.
Par contre, jusqu'à présent, ceci a été fait par ANSIBLE...
Donc, on n'est plus avec le contenu du paquet original.
Cela ne me plait pas trop, car si je devais déployer sur un nouveau serveur, je serais obligé d'installer le RPM puis passer le playbook ANSIBLE (sans en oublier). Bref, cela n'est pas très propre.
Comment pourrais-je procéder?
1- Je me dis que je pourrais RPM"isé" la partie réalisée par ANSIBLE tout en y ajoutant une dépendance au paquet RPM de base.
2- Je me dis que je pourrais faire évoluer le RPM original pour en faire une release supérieure.
Pour la solution 1:
Je la trouve intéressante, mais il faut savoir qu'il y a 2 RPMs à passer pour être en dernière version de l'environnement.
Pour la solution 2:
Je la trouve tout aussi intéressante, mais j'ai peur de flinguer des fichiers de la version 1 qui (par exemple) auraient évolués pour les besoins du cycle de vie de mon application. Exemple, j'ai un fichier "toto" qui contient une liste de prénoms à la base. Entre temps, l'application a vécu. Le fichier "toto" a évolué et contient maintenant des couleurs.
Si je fais un RPM pour une maj, j'ai peur d'avoir un fichier "toto" revenant à l'état initial cad avec uniquement des prénoms.
Que me conseilleriez vous
Merci
madko
N'oublie pas que 2 paquets RPMs ne peuvent apporter les mêmes fichiers. Si les évolutions par ansible n'apporte que des nouveaux fichiers tu peux en effet créer un nouveau.
Normalement la solution 2 est la solution la plus propre. Surtout si tu as bien listé dans %files les fichiers de conf (option config avec éventuellement replace ou noreplace), ceux-ci ne seront pas écrasés par les mises à jour du RPM (mais un fichier rpmnew ou rpmsave en fonction du replace/noreplace).
Après si d'autres fichiers sont écrasés, ce sera l'occasion de les tracer et de voir ce qu'il en est. Est-ce une modification normal à backporter dans le RPM, ou autre cas de figure. Donc bien faire un backup avant de tester les mises à jour, et comparer les fichiers avant/après pour voir tout ça. Au pire s'ils ont un ansible, il pourra être rejoué et refaire les modif ecrasées par le RPM ?
gerald06
Bonjour,
du coup, je pense partir sur la solution 2.
Par contre, si je décide d'utiliser la valeur %noreplace, je risque d'avoir beaucoup de fichiers .rpmnew présents dans mon environnement suite à une mise à jour?
Autre point, quelle procédure puis-je utiliser pour lister l'ensemble des fichiers dans le RPM que je vais construire?
Aujourd'hui, j'utilise ce paramétrage:
%files
%defattr(-,root,root,-)
%{DIRXX}/*
%{DIRCC}/*
C'est très pratique mais très générique.
Je n'ai pas obligatoirement la bonne méthode de travail... j'avoue
Merci
madko
L'ensemble des bonnes pratiques est plutôt bien référencées ici
https://docs.fedoraproject.org/en-US/packaging-guidelines/
Mais ta section %files me choque pas, on a rarement besoin d'être plus précis. Et lors de la construction du RPM lui listera de manière exhaustive l'ensemble des fichiers qu'il a trouvé lors de sa compilation. Le rpm -qpl ton_fichier.rpm est la résultat exhaustif de ta section %files.
Pour les .rpmnew oui c'est sûr que tu peux en avoir beaucoup. Pour chaque fichier de conf modifié hors du RPM. A l'admin/exploitant de voir ce qu'il en est.
gerald06
Bonjour,
pour compléter les propos, voici quelque chose d'assez intéressant, qui illustre vos propositions:
https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html
Cordialement