Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
yes I could install them from the net, but most of my boxes have internet access disabled to them. Also, I unpackaged and edited most of the config files to some of the packages (no need to edit config file after installation). –  luckytaxi Apr 10 '10 at 22:48
    
In most cases, you won't have conflicting RPMs, correct? In your example above, it's unlikely that the Nagios RPMs ever conflict with the Puppet RPMs? –  Stefan Lasiewski Sep 24 '10 at 19:10

4 Answers 4

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.