[Bug 592079] New: Procedure: reboots for new kernels

[sysadmin (bugzilla.gnome.org) <bugzilla gnome org>]

http://bugzilla.gnome.org/show_bug.cgi?id=592079

           Summary: Procedure: reboots for new kernels
    Classification: Infrastructure
           Product: sysadmin
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: Packages
        AssignedTo: sysadmin-maint gnome bugs
        ReportedBy: otaylor redhat com
         QAContact: sysadmin-maint gnome bugs
      GNOME target: ---
     GNOME version: ---


--- Comment #0 from Owen Taylor <otaylor redhat com> 2009-08-17 13:28:58 UTC ---
Application of security fixes for the kernel does not typically cause the
machine to be automatically rebooted. For optimum security, we should try to
ensure that all machines are rebooted into the latest installed kernel on a
regular basis. It's not worth trying to figure out what kernel security fixes
are important or not.

There may be some exceptions to this - for example, a virtualization container
machine like VBox will typically have:

 - No non-sysadmin login access
 - No open ports other than ssh

And is considerably more of a nuisance to reboot, so we may want to consider
not rebooting such machines except for identified critical kernel fixes.

Our record recently in having machines come up properly after a reboot is very
good. Even so, reboots should typically happen during working hours at the
relevant colo unless the GNOME sysadmin team has remote console/power access
itself.

Possible procedure:

 - Automate collection of running kernel and latest installed kernel across all
machines into a single report
 - Send a daily nag-mail if there are any systems that need reboots
 - Check-off at the monthly team meeting that the report is currently clean,
and if necessary assign a volunteer to deal with scheduling reboots.

The low tech-form of this is to send per-system nag mails; I'm not quite sure
how the collection of data across all systems would work, though we need
similar things for a lot of montoring (e.g., disk usage). The disadvantage of
per-system nag messages is that it contributes to the general white-noise that
gets ignored.

-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the QA contact of the bug.
You are watching the assignee of the bug.