1

I'm using Ubuntu 14.04

I'm currently using unattended-upgrades to apply security patches to my systems.

I've found that kernel patches are pretty frequent -- roughly 1 - 2 per week -- and of course a kernel patch requires a reboot. Except an unscheduled reboot is not acceptable in many cases.

What information is available that I can use to better determine if a kernel patch should be applied? Can this decisioning be automated?

For example, I found the Ubuntu kernel changelog, here: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_3.13.0-67.110/changelog

There is an "urgency=" flag! Great! Except no, not great, every patch in the changelog (except one) is set to "urgency=low" and I found an Ubuntu doc that says that "urgency" is not used in Ubuntu, so the flag should be set to "low" (Ref: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation )

I'm considering skipping the kernel patches in unattended-upgrades and just applying them manually in a scheduled change window.

Does anyone have a usable, automated procedure for this sort of thing?

JDS
  • 2,598
  • 4
  • 30
  • 49
  • You hardly can't automate this in a reasonable way because every system is different and what might be an extremely urgent fix on one system can be completely irrelevant on the next one if the affected subsystem is not used there. – Sven Nov 05 '15 at 15:18
  • Are there any low-traffic/low-activity windows during which you perhaps could in fact reboot? – JayMcTee Nov 05 '15 at 15:24
  • @JayMcTee - that's something we are figuring out. but i don't want to have patches applied in advance, latently sitting there until reboot, because it causes our security processes to complain that the system needs a reboot – JDS Nov 05 '15 at 16:13
  • @Sven - yeah, that's what I was noticing on the ubuntu kernel changelog. for example, one patch from the summer of 2015 had like 20 things for the synaptic trackpad driver. not critical on my cloud servers, for sure! – JDS Nov 05 '15 at 16:14

0 Answers0