EGI IGTF Release Process

From EGIWiki
Revision as of 15:50, 22 October 2010 by Davidg (talk | contribs) (Procedure)
Jump to: navigation, search

This page is in draft

About this distribution

This page describe the procedure for the announcement and propagation of a new release of the EGI Trust Anchor distribution. The EGI Policy on Approved Certification Authorities describes the set of trust anchors accepted by EGI and put forward for consideration by the NGIs to install as the 'agreed set' of Identity Management trust anchors. For the time being, only PKI trust achors ('Certification Authorities') are included in this release.

The announcement and distribution of trust anchors within EGI and the NGIs should be done in a well defined order to ensure consistent deployment and to ensure that the monitoring of the NGIs and sites matches the currently recommended version of the trust anchors.

Transition process

For historical reasons, most of the EGI sites (i.e. all those that do not have their own local or national distribution already), use as the meta-package that enshrines the EGI policy on approved CAs one called 'lcg-CA'. In the future, this package will go away, probably at the same time that the distribution repository itself is changed from to the new EGI repositories. Since at that time sites need to change anyway, doing this extra step will hopefully be less intrusive.

As of release 1.35, the set of packages distributed via both the old as well as the new process have not only this legacy RPM, but also the newly named 'ca-policy-egi' RPM. For the time being, both policies are the same, i.e., the same dependencies are included in both RPMs and installing either one of them will trigger the installation of the same set of CAs. After that, the EGI set of endorsed CAs will be encoded in the 'ca-policy-egi' meta-package.

Of course, it is not guaranteed that, in the future, the EGI and wLCG policies will stay aligned, so sites that relied on the 'lcg-CA' package distributed by EGEE to also comply with the wLCG policies on accepted CAs should keep this in mind. Also, the acceptable CA policy for your organisation, country or region may be different from the EGI one: for example, your organsiation or NGI may have approved additional CAs to support training activities on your infrastructure, or have additional bridges between your countries research federation and your site! As a result, you may want to install additional CAs that are not on the central EGI list.

Teams involved

  • IGTF/EUGridPMA Liaison: David Groep (
  • Monitoring Team (central monitoring configuration centre): CERN/James Casey
  • Repository Team: GRNET (or CERN for a while?)
  • EGI-MW team (configuration, integration and staged roll-out): LIP/Mario David
  • Regional follow-up: NGI contacts and All Sites (via CIC portal)
  • Security oversight and determination of grace period: EGI CSIRT/Mingchao Ma and Sven Gabriel


  1. David Groep (under EGI contract O-E-15/SA1) will also build the entire trust anchor package, currently called 'ca-policy-egi-core', and make that available on a special site only intended for INTERNAL use by the deployment process (there is also a ca-policy-lcg package). This "special" distribution would contain:
    • the IGTF "classic", "mics", and "slcs" CAs (following the Policy on Accepted CAs)
    • the "ca-policy-egi-core" as well as the (equivalent legacy) "lcg-CA" and the ca-policy-lcg meta package
    • any other EGI specific CAs or exception as decided by EGI
    • any appropriate meta-data, the readme file and repo headers
    This distribution will be unit tested before being released. These RPMs are made available on the dedicated EGI-IGTF liaison web site (not on production sites at that step):
     wget -r
    or using rsync from rsync://
    • David will submit a GGUS ticket, including the NRMS meta-file that gets produced as part of the repository at
    this triggers the import of distribution to the EGI Repository "scratch" repository for starting the staged-rollout process via the RT link as explained in the NSRW New Software Release Workflow
  2. New CA release is announced by David Groep ( (following on or forwarding the EUGridPMA-Announce list) to
    • the EGI CSIRT via
    • the EGI MW unit via, (or later
    • the monitoring teams to update the SAM CE probes via (,
    • the NGI Operations managers (to update the Nagios instances) via
    • Mail paste list:,,,,,,,,,
    • Either the EGI CSIRT, the EGI Operational Security Coordinators, or the MW unit can declare this update as urgent.
  3. David will create a RT ticket in the sw-rel queue, with with a standard subject: "CA update, version X.Y.Z-R" And with a comment inside saying: "please, follow the EGI-IGTF release process at". The SW release team will take the process from there. In RT, the monitoring team should be involved via a CC to UNKNOWN@EXAMPLE.ORG to verify the status of the nagios probes if needed AND to update the legacy CE tests if those are still in production use, as both changes are independent. The ticket will contain the requirements as per Internal_TPs_Process_for_a_new_software_release:
    • the NRMS metadata "release.xml", including the URL of the repository, e.g.:
    • the EGI specific change log in the release file. This change log is intended for direct distribution to the EGI sites
    To ensure a smooth, parallel update of the repository and the monitoring/Nagios tests, the non-urgent updates should be be started prior to Wednesdays at mid-day. The RT ticket that triggers the updates (which can be sent anytime), should systematically include a reminder not to start after mid-week, and preferably on a Monday.
  4. The EGI sw-rel unit will put the release in staged roll-out for testing. This procedure should not take more than one day.
    • The sites that participate in the staged roll-out are: LIP
  5. If staged roll-out is successful:
    • the EGI sw-rel unit assigned the RT ticket to the Monitoring team, with a CC to the Repository, since the next two steps should be done in rapid succession. The monitoring team should act first (due to the structure of the CAdist-probe logic:
  6. The Monitoring team copies the old-style YUM headers/ file from the secret location to
  7. The Repository team copies the RPMs form the secret place to the repository and either
    • copies all of the secret directory to the release location. This structure supports new-style Yum3 and old-style Yum2 downloads; or
    • copies the RPMs into the repository and re-creates the headers locally
    • updates the CA related web page at
    • sends an announcement with changelog (from the GGUS ticket) to the NGI contacts that the repository contains new content through the Operations Portal (select "To ROC Managers", "To Production Site Admin"), with a CC to the gLite EMT. Template emails including email subjects can be found here. The change log to be included in the mail is part of the GGUS ticket, and can also be found at as file ca-policy-egi-core-readme-X.Y.txt(with X.Y the version number).
    • assigns the GGUS ticket to the EGI-CSIRT
  8. The ticket opened by David Groep at step 3 is closed by EGI-CSIRT Contact, only after verifying that the repository links and release notes of the CA related web pages have been updated, with the link for Quattor templates at the bottom of the page.
    of step 7 are updated containing reference to the new CA version:
    and that the relevant broadcast of step 8 is achieved by looking at (limit the dates to the last few days, and fill "Criterion 3" with "CA"). GGUS ticket subject should be "CA update, version X.Y.Z-R".

Notes on the CAdist probe

  • the list of required packages is based on parsing the old-style Yum file. Once yum-arch has been completely replaced, this file should be created by hand and contain at least this one line:
    where [\d.]+ contains a version number like "1.35"
  • the release date of the EGI distribution is taked from the Last-Modified header sent by the web server hosting the file
  • The latest IGTF version and release date are taken from the CHANGES file at, which the utility expects to be in a specific format (see sources)
  • the grace period is always 7 days -- there is no means to enforce critical updates from the 'outside' of a site

Notes on the SAM tests

  • SAM tests need to be updated, specifically the "lcg-sam-client-sensors" and "grid-monitoring-probes-org.sam" and these need to be installed in production
  • Only them, upload the new CA RPMs to the gLite middleware repository