Installation Best Practices
This document covers best practices to be used in installing software packages or security certificates on large numbers of hosts. It assumes you understand YUM/RPM Basics
and YUM Repositories
priorities to ensure that we get the right packages from the OSG repositories. Please install it:
[root@client ~]$ yum install yum-priorities
There is good documentation
in the wild about yum priorities, but we'll summarize the essential bits for you.
The basic idea of yum priorities is that if a package is found in two repositories, priorities will influence how yum chooses which package to install. We want the OSG software repository to be chosen instead of the EPEL repository so software, such as Globus, comes from our repository instead of the EPEL repository. (This is important because you will have installation errors if you get the EPEL Globus.)
Yum priorities is a yum plugin
. Once enabled, you can set the priority of each repository (located in /etc/yum.repos.d) The lower the numerical priority, the better the priority. The default priority for a repository when it's not specified is 99. We set the priority for the OSG repository to be 98, as you can see here:
% cat /etc/yum.repos.d/osg.repo
name=OSG Software for Enterprise Linux 5 - $basearch
You can adjust these priorities if you have special needs at your site.
We strongly recommend against automatic updates for production services. You want to only change software versions during a controlled downtime (or, at least, while a human is watching); we strive to thoroughly test software updates, but cannot guarantee new version of software will not be problematic for your site.
For testbeds, automatic updates are suggested
Sometimes when installing, you will get an error like this:
http://ftp1.scientificlinux.org/linux/scientific/54/x86_64/updates/security/repodata/filelists.sqlite.bz2: [Errno -1] Metadata file does not match checksum
This often indicates that you have out of date information, cached by
. The following command will clear the out of date information, and you can try again:
yum --enablerepo='*' clean all
is a wonderful tool for installing software on a single server, it's a poor tool to install the same version of the software on many hosts. We strongly
recommend a cluster management tool; as far as we know, all cluster management tools provide a mechanism to create a local yum repository and have all your worker nodes use that.
If you have more than 20 worker nodes, we have the following advice:
- Do not use one of the OSG repositories directly for worker node installations; build a local mirror instead. (See below).
- Distribute CRLs to the worker nodes using an HTTP proxy.
Both items are covered in this document.
In the future, we will be providing a mechanism for distributing CAs and CRLs via a shared file system; this is not quite finished. If you choose to do this, remember that your security infrastructure will only be as safe and reliable as the shared filesystem!
A local yum mirror allows you to reduce the amount of external bandwidth used when updating or installing packages.
Add the following to a file in
RANDOM * * * * root rsync -aH rsync://repo.grid.iu.edu/osg/ /var/www/html/osg/
Or, to mirror only a single repository:
RANDOM * * * * root rsync -aH rsync://repo.grid.iu.edu/osg/3.1/el6/development /var/www/html/osg/3.1/el6
with a number between 0 and 59.
On your worker node, you can replace the
with the appropriate URL for your mirror.
If your osg*.repo files still point to the legacy 3.0 repo layout (eg,
/3.0/el5/osg-release/ instead of the new /osg/3.1/el5/release/), they
can be updated to point to the new 3.1 layout by installing the latest version of
the 'osg-release' package:
yum update --enablerepo=osg-testing osg-release
If you are interested in having your mirror be part of the OSG's default set of mirrors, please file a GOC ticket
CAs are distributed in two ways:
- As an RPM that contains the set of CAs. There are several such RPMs corresponding to different sets of CAs.
- Through direct downloads from GOC with the
osg-update-certs tool (provided by the
As long as you use one of these two mechanisms, the OSG software will install successfully.
CRLs are not distributed via
. Instead, we provide the
tool that downloads CRLs to the CA directory.
connects directly to the remote CA; this is inefficient and potentially harmful if done simultaneously by many nodes (e.g. all the worker nodes of a big cluster). We recommend you provide a HTTP proxy (such as squid) the worker nodes can connect to. Here
are instructions to install a squid proxy.
To configure fetch-crl to use an HTTP proxy server:
Note that the
option in the configuration files refers to ignoring links within the certificates directory (e.g. two different names for the same file). It is perfectly fine if the path of the CA certificates directory itself (
) is a link to a directory.
Any modifications to the configuration file will be preserved during an RPM update.
For more details, please see our fetch-crl documentation
Note that, in general, there is no mechanism to reverse a
command in RHEL5. Plan accordingly.
We have prepared a special yum plugin
, to assist in removing OSG RPMs.
To re-iterate: just because it removes most/all of the OSG RPMs,
is not guaranteed to be a perfect reversal of
(things like post-scripts have side-effects that must be taken into account; these are not in general reversible). On the upside, removal of the RPMs will be "good enough" for many sites.
If you need a bit-for-bit, exact replica of your system prior to the upgrade, you'll want to use a backup strategy and restore from backup.
- 29 Aug 2011