4

I'm writing some RPMs which install YUM repo configuration files for various internal YUM repos, same structure and concept as the EPEL repo RPMs.

We will have multiple environments with equivalent repos, so we use yum priorities plugin to insure environment repos earlier in the deployment sequence (i.e. QA) have priority over those which come later (i.e. Production). We're also replicating the CentOS versions we use on an internal mirror. We have all of this working, including the publication of these repo configuration RPMs, but have one special case remaining where I'd like some advice on the best way to handle a design issue.

And that is: The CentOS base repo configuration file /etc/yum.repos.d/CentOS-Base.repo is owned by the centos-release RPM, so I can't overwrite this in my own RPM without replacing this system RPM, which I don't want to do. But, I need to make some changes to this file so that it works with the design described above. In each repo section,

I need to change these lines:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/

To these lines:
mirrorlist=http://mirrorlist.MYCOMPANY.com/?platform=centos&release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.MYCOMPANY.com/centos/$releasever/os/$basearch/
priority=2

I'm currently creating an RPM which installs /etc/yum.repos.d/CentOS-Base-pr.repo, then in the %post it renames the existing CentOS-Base.repo to CentOS-Base.repo.orig, then renames the new CentOS-Base-pr.repo to CentOS-Base.repo. In the %postun, it reverses this to restore the original file. I feel this works, but it's a bit of a kludge.

What I'd like to do instead, is install no files, but run a sed script to make these changes to the original CentOS-Base.repo file in the %post, and another sed script to reverse the changes in the %postun. This allows me to handle the install/uninstall of all of our custom repos in the same way, with a consistent result for both existing and new repos.

What I don't know is - is this a valid or recommended approach when you're trying to do this type of configuration "tweaks" to existing files installed by other RPMs?

Before I get answers to this effect, we're using Chef for most post RPM configuration similar to this, but don't want to use that in this case, as we don't want to have a special case on the repo config in just this one instance, and we're trying to use RPMs to encapsulate "heavy-lifting" install/upgrade logic inside of RPMs elsewhere. We want our own software to behave like other open source software in that it can install and run without a dependency on Chef for basic installation, and Chef is only used for customization (i.e. how Chef configures nginx or tomcat).

Thanks in advance for any advice...

mjcconsulting
  • 51
  • 4
  • 2
    I think some shops do use RPMs regularly for this sort of configuration management. In particular, if you want to install Puppet/Chef/CFEngine from an RPM or during kickstart, you often need the repo files file installed first-- but normally you would want to do this using your Configuration Management system. It can be a catch-22 situation. – Stefan Lasiewski Jun 22 '14 at 19:44
  • 1
    Is there a reason you don't want to build your own `centos-release` RPM with a higher epoch that would always get used? I was going to recommend creating a `centos-release-` and using the `Obsoletes` capability to "obsolete" `centos-release` and instead use your own. – Andy Shinn Jun 22 '14 at 19:51

1 Answers1

1

It is ok to use a script by itself or a script embedded in an rpm if that is your preference. I like the idea of using empty or meta rpm's for creating your own virtual groups or doing certain tasks. In this case I would be concerned that a later centos-release package would blow away my change. Tracking this would seem to be easier if your package had the file in it that you desired and you install it with the --replacefiles option.

chicks
  • 3,793
  • 10
  • 27
  • 36
  • The .repo file is marked as a configuration file by the packager; you can verify this with `rpm -qc centos-release`. If the file is edited, an updated package will save the new version as (filename).repo.rpmnew and will not overwrite your changes. – Brad Ackerman Mar 11 '15 at 02:01