Home / server / Questions / 131308
In Process
luckytaxi
Asked: 2010-04-11 14:46:10 +0800 CST

Working with a custom YUM repository

  • 772

I have a bunch of tools (nagios, munin, puppet, etc...) that gets installed on all my servers. I'm in the process of building a local yum repository. I know most folks just dump all the rpms into a single folder (broken down into the correct path) and then run createrepo inside the directory. However, what would happen if you had to update the rpms?

I ask because I was going to throw each software into its own folder.

Example one, put all packages inside one folder (custom_software)

/admin/software/custom_software/5.4/i386
/admin/software/custom_software/5.4/x86_64
/admin/software/custom_software/4.6/i386
/admin/software/custom_software/4.6/x86_64

What I'm thinking of ...

/admin/software/custom_software/nagios/5.4/i386
/admin/software/custom_software/nagios/5.4/x86_64
/admin/software/custom_software/nagios/4.6/i386
/admin/software/custom_software/nagios/4.6/x86_64
/admin/software/custom_software/puppet/5.4/i386
/admin/software/custom_software/puppet/5.4/x86_64
/admin/software/custom_software/puppet/4.6/i386
/admin/software/custom_software/puppet/4.6/x86_64

Ths way, if I had to update to the latest version of puppet, I can save manage the files accordingly. I wouldn't know which rpms belong to which software if I threw them into one big folder. Makes sense?

centos yum

4 Answers

  1. I believe you need a separate repository, with data generated by createrepo, for each distinct release that you are supporting. This is so you have a catalog that yum knows about via your .repo file. Your first proposed method would allow you this.

    Using your second method you'd end up having to create repository data for each package you were maintaining, which seems like a nightmare as far as you would have to have repository data for each package.

    Additionally, I wouldn't be building inside of your repository (which is the only reason I can think of for separating it out by software). Set up your build environment with rpmdev-setuptree(available in the rpmdevtoolspackage), build the rpms and copy/move them from the build structure to your repository structure (/<root_repo>/<release>/<arch>/<RPMS/SRPMS>), then generate your repository data via createrepo (or createrepo --update . ) in the release ( 5.4 / 4.6 ) directory.

    • 1

  2. I think throwing them all into one folder works fine. When you have a new version of a package, toss that in there to, and then use "repomanage" from the yum-utils package to trim out older versions.

    • 1

  3. Use a mix of both: Create Repos of different types und throw the relevant rpms into these.

    For every repo we use a "staging"-variant that contains the newest rpms. If these test out well on test machines thes rpms go to the live repos.

    The staging rpms can be automated.

    • 0

  4. I have everything lumped into one directory. When an update comes out I move the RPM into the directory and remove the old one. Then I run createrepo -v --update /PATH/TO/REPO.

    • 0