Difference between revisions of "EGI IGTF Release Process"

From EGIWiki
Jump to: navigation, search
(Created page with ''''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 distribut…')
 
Line 17: Line 17:
 
* Regional follow-up: NGI contacts
 
* Regional follow-up: NGI contacts
 
* Security oversight and determination of grace period: EGI CSIRT/Mingchao Ma and Sven Gabriel
 
* Security oversight and determination of grace period: EGI CSIRT/Mingchao Ma and Sven Gabriel
 +
 +
= Procedure =
 +
 +
# New CA release is announced by David Groep via the EUGridPMA-Announce list to
 +
* the EGI CSIRT via csirt@mailman.egi.eu
 +
* the EGI MW unit via david@lip.pt, jorge@lip.pt
 +
* the monitoring teams via James.Casey@cern.ch, project-egee-roc-managers@cern.ch
 +
Either the EGI CSIRT, the EGI Operational Security Coordinators, or the MW unit can declare this update as urgent.
 +
 +
# David Groep (under EGI contract O-E-15/SA1) will also build the entire trust anchor package, currently called 'lcg-CA', and make that available on a special site only intended for INTERNAL use by the deployment process. This "special" distribution would contain:
 +
* the IGTF "classic", "mics", and "slcs" CAs (following the Policy on Accepted CAs)
 +
* the "lcg-CA" meta package
 +
* any other EGI specific CAs or exception as decided by EGI
 +
This distribution will be unit tested before being released. These RPMs would be made available on a pretty obscure web site (not on production sites at that step). The MW Unit should download their local copy from this location. To download, you may need to instruct wget to ignore the robots.txt file:
 +
wget -e robots=off -r http://obscure-site.example.org/cadist/lcgpreview-X.YY-R/RPMS.lcg/
 +
or even
 +
wget -nd -r -np -i index.html -F --base=http://www.cern.ch/groep/cadist/lcgpreview-X.YY-R/RPMS.lcg/ http://www.cern.ch/groep/cadist/lcgpreview-X.YY-R/RPMS.lcg/
 +
 +
* David will create a GGUS ticket, with with a standard subject: "CA update, version X.Y.Z-R" And with a comment inside saying: "please, assign this ticket to the SAME/SFT support unit". The integration team will also be involved in the ticket to start preparing the repository ("Involve others:" in GGUS), as both changes are independent. The ticket will contain
 +
* the URL, e.g.:
 +
** http://www.cern.ch/groep/cadist/lcgpreview-X.Y-Z/
 +
** the EGI specific change log in the body of the ticket. 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 GGUS 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.

Revision as of 13:47, 2 June 2010

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.

For historical reasons, the name of the meta-package that enshrines the EGI policy on approved CAs is called 'lcg-CA'. This will change in a subsequent release, but meanwhile no meaning should be inferred from the meta-package name.

Teams involved

  • IGTF/EUGridPMA Liaison: David Groep
  • Central monitoring config centre: CERN/James Casey
  • Distribution Repository: GRNET/?
  • Configuration, integration and staged roll-out coordination: LIP/Mario David
  • Regional follow-up: NGI contacts
  • Security oversight and determination of grace period: EGI CSIRT/Mingchao Ma and Sven Gabriel

Procedure

  1. New CA release is announced by David Groep via the EUGridPMA-Announce list to
  • the EGI CSIRT via csirt@mailman.egi.eu
  • the EGI MW unit via david@lip.pt, jorge@lip.pt
  • the monitoring teams via James.Casey@cern.ch, project-egee-roc-managers@cern.ch

Either the EGI CSIRT, the EGI Operational Security Coordinators, or the MW unit can declare this update as urgent.

  1. David Groep (under EGI contract O-E-15/SA1) will also build the entire trust anchor package, currently called 'lcg-CA', and make that available on a special site only intended for INTERNAL use by the deployment process. This "special" distribution would contain:
  • the IGTF "classic", "mics", and "slcs" CAs (following the Policy on Accepted CAs)
  • the "lcg-CA" meta package
  • any other EGI specific CAs or exception as decided by EGI

This distribution will be unit tested before being released. These RPMs would be made available on a pretty obscure web site (not on production sites at that step). The MW Unit should download their local copy from this location. To download, you may need to instruct wget to ignore the robots.txt file:

wget -e robots=off -r http://obscure-site.example.org/cadist/lcgpreview-X.YY-R/RPMS.lcg/ 

or even

wget -nd -r -np -i index.html -F --base=http://www.cern.ch/groep/cadist/lcgpreview-X.YY-R/RPMS.lcg/ http://www.cern.ch/groep/cadist/lcgpreview-X.YY-R/RPMS.lcg/ 
  • David will create a GGUS ticket, with with a standard subject: "CA update, version X.Y.Z-R" And with a comment inside saying: "please, assign this ticket to the SAME/SFT support unit". The integration team will also be involved in the ticket to start preparing the repository ("Involve others:" in GGUS), as both changes are independent. The ticket will contain
  • the URL, e.g.:

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 GGUS 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.