Archive for No name

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.

You may disagree with this statement I made earlier today:

Linux on the desktop will never be as polished as OS X, or even Windows, until some company pours hundreds of thousands of dollars (if not more) into building a usable UI on top of it. However, any company that dumps that much into it isn't likely to make those contributions open source.

It is very possible to make Linux desktop-ready. OS X is fundamentally a BSD-clone with a lot of money and time poured into the user interface. So given some vast amount of time and money, it should be possible to do the same thing with Linux.

I could be wrong but: Most organizations that focus on the open source aspects of Linux (well, properly, GNU/Linux and other stuff) tend to not have a lot of money. So providing the required amount of money will probably fall to a company. And a company that is making a such a significant investment is going to want to capitalize on that. Pouring vast amounts of time and money into something and then giving it away is a losing strategy.

It is possible for the software foundations to fund the development but it will take significantly longer. The added time will ensure that desktop Linux UI would always trail the corporate offerings (Windows, OS X, etc.) because it will have never caught up (assuming the corporate offerings do not stagnate).

Cobbler has the ability to run triggers at specific times. Two of those times include before installing a new machine ("pre-install triggers") and after installing a new machine ("post-install triggers").

"Old-style" triggers involve running executable binaries or scripts (e.g. shell scripts) in specific locations. Pre-install triggers are placed in the directory /var/lib/cobbler/triggers/install/pre/ and post-install triggers are placed in the directory /var/lib/cobbler/triggers/install/post/. The trigger will be passed three pieces of information: the object type, e.g. "system," the name of the object, and the object's IP. (A comment in the run_install_triggers method in remote.py says this passes the name, MAC, and IP but this does not appear to match the name of the variables.) If the trigger requires more information, it will need to pull it from elsewhere or parse cobbler's output. For all but simple tasks, this is probably not a convenient way to go.

Note: There is a bug in cobbler 2.0.3.1 which prevents running "old-style" triggers. See ticket #530 for more information and a possible fix.

"New-style" triggers are written in Python as modules. They reside in cobbler's module directory. (On my system, this is /usr/lib/python2.4/site-packages/cobbler/modules/.) Each module is required to define at least the functions register and run.

The register function takes no arguments and returns a string corresponding to the directory the module would reside in if it were an "old-style" trigger. For a pre-install trigger, it would be:

For a post-install trigger, it would be:

The run function is where the actual code for the trigger should reside. It takes three arguments: A cobbler API reference, an array containing arguments, and a logger reference. The argument array contains the same three values as for "old-style" triggers, i.e. the object type, the name, and the IP address. The logger reference may be set to None and the code should handle that. (In cobbler 2.0.3.1, this will be set to None. This may be fixed when the issue for "old-style" install triggers is.)

For an example of a run function, let's look at one I wrote (based on the trigger in install_post_report.py that is included with cobbler) to automatically sign Puppet certificates:

This starts the method. Note the signature.

This retrieves the settings from /etc/cobbler/settings. To control the trigger, I added another option there named sign_puppet_certs_automatically. If this value either does not exist or is not set to one of the required values showing its enabled, the trigger returns a success code (since it's not supposed to run, it shouldn't return a failure code) and exits.

I also added another option to the cobbler settings called puppetca_path which contains the path to the puppetca command.

This retrieves the object type and name from the argument array. If the object type is not a system, it returns a success code and exits.

This finds the system in the cobbler API and then flattens it to a dictionary. I'm pretty sure this could be improved upon.

This retrieves the path for puppetca and sets up the command to be run to sign the certificate.

This runs the command and logs a warning if either the command fails to be executed or does not succeed. Finally, at the end, it returns a success code.

According to the cobbler documentation, the return code of post-install triggers is ignored so there's no reason not to return anything other than value. Pre-install triggers apparently can halt the process if they return a non-zero value.

Note: The above code will not run correctly if logger is set to None. This is because utils.subprocess_call tries to call logger without verifying that it is not None and throws an exception. To use this with cobbler 2.0.3.1, you must either edit change the call to utils.run_triggers in remote.py's run_install_triggers method or you must change utils.subprocess_call to properly check for logger being set to None.

Also note: Since the original code is under the GPL, the code above is also under the GPL.