La meilleure façon de nettoyer le référentiel Yum?


10

Nous avons un dépôt Yum personnalisé sur lequel nos développeurs téléchargent des builds.

Le problème est qu'après un certain temps, il devient encombré d'anciennes versions.

Supprimer les anciennes versions manuellement est assez ennuyeux, donc avant d'essayer de l'automatiser nous-mêmes, je me demande s'il existe un script qui nettoierait les anciens RPM en fonction de la version (préférée) ou de l'heure de téléchargement.

Le mieux serait de pouvoir spécifier de sauvegarder simplement les dernières versions de X et d'effacer tout le reste. Ensuite, nous pourrions le cron et le laisser fonctionner quotidiennement.

Merci pour toute idée.


S'il n'y a pas de script, il devrait y en avoir. Nous en avons écrit un pour notre propre usage dans notre entreprise, mais je verrai si possible de le diffuser dans la nature.
Andrew M.

Super - j'apprécierai s'il peut être open source. La publication sur github serait une excellente idée.
SyRenity

Réponses:


13

La manière "simple" consiste à simplement vider tout dans un répertoire et à exécuter:

rm $(repomanage --keep=2 --old /path/to/repo)
createrepo /path/to/repo

... la manière la plus compliquée est de configurer koji / etc. pour faire vos builds et créer les repos.


Cool - c'est exactement ce dont j'avais besoin.
SyRenity

super truc, n'était pas au courant de celui-ci
dyasny

Techniquement, vous devriez l'utiliser avec à la xargsplace, sinon vous pourriez en avoir rm: missing operand(s'il n'y a pas d'anciens RPM à supprimer). Donc:repomanage --keep=2 --old /path/to/repo | xargs rm -f
Danila Vershinin

La raison d'utiliser xargs est qu'elle rm $(repomanage --keep=2 --old /path/to/repo)pourrait facilement dépasser la longueur de commande maximale. xargss'occupera d'une énorme liste d'arguments. Voir: offbytwo.com/2011/06/26/things-you-didnt-know-about-xargs.html
shrewmouse

1

Découvrez l'utilitaire "repomanage" du RPM yum-utils. Il fait exactement ce que vous recherchez.

[root ~]# repomanage --help
usage:
  repomanage: manage a directory of rpm packages. returns lists of newest
            or oldest packages in a directory for easy piping to xargs
            or similar programs.
  repomanage [--old] [--new] path.


  options:
    -h, --help            show this help message and exit
    -o, --old             print the older packages
    -n, --new             print the newest packages
    -s, --space           space separated output, not newline
    -k KEEP, --keep=KEEP  newest N packages to keep - defaults to 1
    -c, --nocheck         do not check package payload signatures/digests
[root ~]#

0

Je tirerais parti du système de gestion des versions ou d'étiquetage que vous utilisez pour identifier les versions. Vous pouvez également identifier les packages par date avec un script exécuté sur le serveur hébergeant le référentiel.


Vous voulez dire en vérifiant la version dans les noms de fichiers? C'est aussi mon point de vue, mais ce serait bien d'avoir un script automatisé pour cela.
SyRenity

1
N'oubliez pas non plus que le nom de fichier n'est pas nécessairement indicatif de la version. C'est-à-dire que je peux renommer un RPM en tout ce que je veux; yum utilisera à la place les métadonnées du RPM.
Andrew M.

0

Si les téléchargements se produisent tous les jours, pourquoi ne pas envisager de supprimer les anciens fichiers qui sont plus anciens au-delà d'un certain nombre de jours (en termes de temps d'accès / de modification)? Trouvez-les et supprimez-les. Si vous pouviez demander à vos développeurs de télécharger des builds de telle sorte qu'ils mettent le nom du mois en cours dans le nom de fichier lors du téléchargement, il serait logique, à partir du nom de fichier directement, que le fichier ait été téléchargé pendant ce que l'on appelle le mois de l'année et il est logique de supprimer simplement par la base de la recherche du nom de fichier. Il serait facile pour votre automatisation de script d'envisager simplement de supprimer ces fichiers ou de simplement conserver les fichiers qui correspondent au mois précédent et au mois en cours. Juste une pensée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.