Difference between revisions of "PROC16 Decommissioning of unsupported software"
Line 77: | Line 77: | ||
|- valign="top" | |- valign="top" | ||
| 1<br> | | 1<br> | ||
| Operations | | EGI Operations | ||
| | | | ||
Information is sent in Monthly broadcast to NGI operations managers, Site administrators, CSIRT, ROD teams: | Information is sent in Monthly broadcast to NGI operations managers, Site administrators, CSIRT, ROD teams: | ||
Line 97: | Line 97: | ||
|} | |} | ||
<br> | <br> | ||
== Escalation phase == | == Escalation phase == |
Revision as of 12:25, 8 June 2016
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
Documentation menu: | Home • | Manuals • | Procedures • | Training • | Other • | Contact ► | For: | VO managers • | Administrators |
Title | Decommissioning of unsupported software |
Document link | https://wiki.egi.eu/wiki/PROC16 |
Last modified | 8 June 2016 |
Policy Group Acronym | OMB |
Policy Group Name | Operations Management Board |
Contact Group | operations@egi.eu |
Document Status | Approved |
Approved Date | 20.11.2012 |
Procedure Statement | A procedure for removal of unsupported software from production infrastructure. |
Owner | Owner of procedure |
Overview
Unsupported software decommission procedure was created to define steps which have to be taken to remove unsupported software from the production infrastructure.
Policy
In compliance to the EGI Service Operations Security Policy (https://documents.egi.eu/document/669) (1), unsupported software SHOULD be decommissioned before its End of Security Updates and Support, and MUST be retired no later than 1 month after its End of Security Updates and Support. After this date, if a critical vulnerability were to emerge in the software, EGI CSIRT can request the service to be turned off immediately.
(1) a Resource Centre Administrator SHOULD follow IT security best practices that include pro-actively applying software patches, updates or configuration changes related to security.
Definitions
Please refer to the EGI Glossary for the definitions of the terms used in this procedure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Decommissioning start date
By this date NGIs and sites SHOULD start action to upgrade their services to supported software or retire them.
End of Security Updates and Support
By this date the software is unsupported. Resource Centres SHOULD NOT run unsupported software in their production infrastructure.
Decommissioning deadline
By this date unsupported software MUST BE retired from the production infrastructure (they must be decommissioned or in downtime). Failure to do so MAY ultimately lead to site suspension or the affected service-end points to be put in downtime by ROD/Operations Support teams. This is applicable to Resource Centres that do not respond to tickets, or for which no technical issue exists preventing them from retiring unsupported software. Status of Resource Centres will be examined by ROD/Operations Support on a case by case.
Steps
Preparation phase
Responsible | Action | |
---|---|---|
0 | EGI Operations | During an OMB meeting the Operations announces End of Security Updates and Support and Decommission deadline for service migration. |
1 |
EGI Operations |
Information is sent in Monthly broadcast to NGI operations managers, Site administrators, CSIRT, ROD teams:
|
2 | NGI managers |
Propagate the information about migration to their own sites. |
3 | Nagios team |
A new probe is developed for the MW SAM for deployment. It extracts information about deployed software versions from Information discovery service (e.g. BDII). |
Escalation phase
Timeline | Responsible | Action | |
---|---|---|---|
1 |
Decommissioning start date |
Nagios team | New probe is deployed into the MW SAM and starts returning WARNING. |
2 |
Decommissioning start date + 1 month |
Nagios team | The probe starts returning CRITICAL. |
ROD |
Follow up the service migration by creating operations ticket through Operations Dashboard until the decommissioning deadline. Escalation steps for problems with unsupported Middleware at site must be applied. | ||
3 |
within 10 working days from when ROD ticket is received |
Site admins |
Site admins must provide migration or decommission plan within 10 working days from when ROD ticket is received. The plan must take into account Decommissioning deadline and site plans to migrate before this date. Resource centres who fail to provide information about migration plans are subject to suspension by ROD. |
4 |
After10 working days |
ROD |
Follow up the migration:
|
5 | Decommissioning deadline | ROD and Site admins |
By this time service end-points which couldn't be upgraded should be put into downtime by site admin or ROD:
|
6 | After Decommissioning deadline | Operations Support | Follow up the status of migration and put in downtime affected end-points. |
7 | Decommissioning deadline + 1 month | Operations Support | Sites still deploying unsupported service end-points risk suspension, unless documented technical reasons prevent a Site Admin from updating these end-points. |
Revision history
Version | Authors | Date | Comments |
---|---|---|---|
M. Krakowian | 19 August 2014 | Change from COD to Operations Support team |