Software update policy for SLC (for desktops and auto-updating machines)
Software updates get triggered by the following events:
- notification from T.U.V. (mail from enterprise-watch-list) - standard workflow, SRPMs available
- direct security notification from TAM, CERN security team, other mailing list or (occasionally) users - SRPMs typically not available.
- direct errata notification or update request from any add-on software provider
Assessment
Impact on CERN for all updates needs to be assessed. If available, input from TUV (or secunia advisories etc) can be taken as a base, and gets modified:
- local root exploits in a "CERN recommened setup" install have critical priority (even if TUV only labels these as "important") - provide advance warning to FIO SMOD in these cases.
- user-assisted attacks (user needs to perform some action - visit "evil" web page, read "evil" attachment) on the user account (this includes browsers, email clients, multimedia and other plugins such as PDF viewers) are not critical, unless there is reason to believe there is an ongoing attack (which is working against Linux machines).
Timeline/delay goals
(these are goal, with exceptions for
critical updates)
- standard workflow updates get pushed maximum once per week
- updates should be in the testing repository for at least 2 days (i.e. full day after the machines subscribed to that repository did an automatic update)
Implementation
Procedure is at
SoftwareUpdatesOnSLC.
Responsible
Person on duty for Linux 3rd-level REMEDY support needs to add all updates during their week to "testing" repository and performs weekly push to production. Anything not pushed during the week needs to be passed on to next support rota person, with an assessment whether the software in question should (or not) get pushed during the next week.
Software update policy for RHEL
Updates from RHEL are pushed whenever they come out of RHN, last step on our side is the announcement to project-elfms (after which the [[FIOgroup.FabricServicesSection#Intervention_planning][FIO-FS "monthly intervention"] should kick in). Some short (= days) delay on the Linux Support side is OK, in order to synchronize with matching SLC updates. See
SoftwareUpdatesOnRHE2 for the procedure.
Other policies
Updates on the FIO-centrally managed machines are governed by a different policy (roughly: monthly update after one week lock-off period, see
FsScheduledLinuxUpgradeTemplate). Emergency interventions can still be rushed.
Topic revision: r1 - 2008-07-21
- JanIven