Updating Trusted CAs and gLite

In addition to updating QWG templates to the last version to take advantages of new features and fixes, there are 2 occasions where you may need to update templates based on operation constraints driven by EGEE announcements:

  • Update the list of trusted CAs: this happens in average every 2 months and a site must update in the 8 days after the announcement before being in CRITICAL state in SAM tests.
  • Update to a new gLite update: for most of the updates, there is no need to upgrade urgently (except for security fixes). The easiest is generally to update the templates to the last version available in the corresponding branch but if this is convenient, it is generally possible to include the relevant templates only.

These operations are described in more details in the following sections.

List of Trusted CAs

The list of trusted certification authorities (CA), also known as the CA trust policy, is made of 2 components:

  • The template describing the CA trust policy
  • The RPMs providing the informaton about each trusted CA

Both are normally maintained centrally by a grid organization, for example EGI or a specific NGI. They are updated regullarly and each update needs to be deployed in a timely fashion on every site.

The EGI default policy is provided in QWG templates. This template is maintained by EGI and new versions are announced trough EGI broadcast. At the time of this writing (10/2/2011), the official source is but look at precise URL in announcements. It is also available from QWG repository which contains one directory for each version of the IGTF trusted CA releases. This template must be placed in directory standard/security.

In addition to downloading the template, it is necessary to download the new CA RPMs from the location indicated in the announcement. In QWG templates, these RPMs are generally stored in a specific RPM repository for easier management. It is a good practice to rename the corresponding directory, create a new one with the same name and download the new RPMs in this empty directory. For example, for CA 1.38 (replace the directory in the example by the directory corresponding to CA RPMs repository) :

cd /your/scdb/top/level/dir
mv /www/htdocs/packages/ca /www/htdocs/packages/ca.old
mkdir /www/htdocs/packages/ca
# Look at URL mentionned in the announcemet
utils/misc/ /www/htdocs/packages/ca

WARNING: there dummy-ca-certs rpm which is usually not in the official release of the CA and it is needed to workaround an Apache issue. Have a look to see if the rpm is in your new CA directory. If not, copy it from the old one.

After downloading the appropriate template and the corresponding RPMs, if you are using SCDB, you need to update the template associated with the RPM repository and deploy the updated information with:

ant update.rep.templates
ant deploy

As an alternative to renaming CA repository, you may have one directory per version of the CA trust policy (eg. ca-1.37, ca-1.38...) and define a symlink (eg. ca) pointing to the version currently in production. This may reduce the risk of mistake. In this case, ensure your Apache configuration allows the use of symlinks for the URL/directory corresponding to the symlink. You may need to update your Apache configuration with something like:

<Directory "/dir/to/packages/ca">
    options +FollowSymlinks

For details about how to configure an alternative CA trust policy, look at gLite customization page.

gLite Updates

Look to wiki:Download/QWGTemplates/Install.

Keep in mind that the normal and easiest procedure to install a gLite update is to get the last version of the templates from the appropriate branch.

Last modified 11 years ago Last modified on May 15, 2013, 5:36:40 PM