You are here

April 2011

Error message

Deprecated function: Function create_function() is deprecated in GeSHi->_optimize_regexp_list_tokens_to_string() (line 4716 of /home/web/ithiriel.com/www/web/sites/all/libraries/geshi/geshi.php).

Creating a yum repository

Now that you have signed RPMs, you have to find a way to make these available for installation.1 If you want to make these available for public use, that means a yum repository. If you're going to use them for private systems only, a yum repository is likely to be the best way to make these available and to handle updates later.

Creating a repository is easy to do: Copy your RPMs to a web-accessible directory and run the createrepo command.

It's traditional to have a separate repository for each combination of OS and architecture. EPEL shows a good example of this.

After creating the repository, you have to tell yum about it. To do this, you need to create a file in /etc/yum.repos.d/ with the .repo extension2 that contains the information for it. For an example repository, you would create a file named example.repo with these contents:

[example]
name=Example Repository for Enterprise Linux 5 - $basearch
baseurl=http://repository.example.cpm/el5/$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EXAMPLE

You can define multiple repositories in a repo file. Each repository definition needs its own section with a unique name. The name of the section is how yum will refer to the repository.

Note that this file says that the GPG key is on the local filesystem. You can use a URL instead like seen here.

After you add this repository file (and put the GPG key in place if you want to keep it on the local filesystem), you should be able to see the RPMs in your repository when you run yum install.

The problem with this approach is that you (or your users) then have to manually maintain the repository files. For example, what if you want to move your repository? If you have the luxury of using a configuration management system, e.g. puppet, this may not be a big deal. However, if you don't or you don't have the access to the systems, there's no easy way to do this.3

How does EPEL deal with this? To make distributing the repo and GPG key easy for the users and to allow for easily updating information later, they package this information in the epel-release RPM. You can do something similar to distribute information for your repository and allow for updating it later.

The easiest place to start will be to download the epel-release SRPM, install it into your RPM build environment, and then make changes to the spec file. For the example repository above, you would end up with this spec file:4

Name:           example-release
Version:        5
Release:        5
Summary:      Example repository for Enterprise Linux configuration
 
Group:          System Environment/Base
License:        GPL
URL:            http://www.example.org
 
Source0:        http://repository.example.org/RPM-GPG-KEY-EXAMPLE
Source1:        GPL
Source2:        example.repo
 
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
BuildArch:     noarch
Requires:      redhat-release >=  %{version}
Conflicts:     fedora-release
 
%description
This package contains the Example repository for Enterprise Linux
GPG key as well as configuration for yum.
 
 
%prep
%setup -q  -c -T
install -pm 644 %{SOURCE0} .
install -pm 644 %{SOURCE1} .
 
%build
 
 
%install
rm -rf $RPM_BUILD_ROOT
 
#GPG Key
install -Dpm 644 %{SOURCE0} \
    $RPM_BUILD_ROOT%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-OBERONPROJECT
 
# yum
install -dm 755 $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
install -pm 644 %{SOURCE2} \
    $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
 
%clean
rm -rf $RPM_BUILD_ROOT
 
%files
%defattr(-,root,root,-)
%doc GPL
%config(noreplace) /etc/yum.repos.d/*
/etc/pki/rpm-gpg/*
 
 
%changelog
* Wed Apr 06 2011 Chris Ess <caess@ithiriel.com> - 5-5
- Modified epel-release package for the example repository
 
 Tue Aug 10 2010 Seth Vidal <skvidal at fedoraproject.org> - 5-4
- conflict fedora-release so people don't indadvertently do something silly
 
* Fri Apr 25 2008 Matt Domsch <Matt_Domsch@dell.com> - 5-3
- use mirrorlists in epel-testing.repo
- use download.fedoraproject.org in (commented out) baseurls
 
* Mon Apr 02 2007 Michael Stahnke <mastahnke@gmail.com> - 5-2
- Missed a syntax correction in epel-testing.repo
 
* Mon Apr 02 2007 Michael Stahnke <mastahnke@gmail.com> - 5-1
- Hard coded version '5' in epel yum repo files.
 
* Mon Apr 02 2007 Michael Stahnke <mastahnke@gmail.com> - 5-0
- Initial Package for RHEL 5

(Please note that this SPEC file is covered under the GPL and I am not the original copyright holder. As a result, I don't think I can remove the changelog for epel-release since it's the only way I see to attribute previous work. I might (and, therefore, you might) be able to do without this by adding a comment that says that this is based on version 5-4 of the epel-release SRPM. I'm not a lawyer and, as such, am not clear on the legal requirements here.)

Once you have the spec file, build (and sign!) the RPM. You can now distribute the RPM to your systems (or your users). To allow for updating this later, add it to your repository as well. Don't forget to add the SRPM to your SRPM repository as well. (If you're making this repository public, you need to have an SRPM repository! It also doesn't hurt to keep one since if your local source trees go away and your version control system5 explodes in a magnificent burst of flame.)

Having this RPM makes provisioning the repository on new machines even easier when using kickstart. Just add a repo line for your repository and add the RPM to the %packages section and it'll get installed automatically.6 You can use this trick to install other RPMs in the repository too.

This covers just about everything I can tell you about building RPMs and making a yum repository. In the future, I'll cover how I'm currently updating the repository I've been setting up. If you have a lot of packages to build, it might make your life easier.

  • 1. If you don't have signed RPMs yet, you might want to read my previous post.
  • 2. I'm not certain that this is required but I've never looked into it.
  • 3. If you're running a public repo, you probably don't want to change the URL if at all possible.
  • 4. Well, not quite. You might be building for a different version of RHEL. If nothing else, the changelog entry is going to be different.
  • 5. You are using version control for your RPM builds, right?
  • 6. Kickstart doesn't check to see if RPMs are signed so you can get away with this.