Automatic updates to pSPT Installations

[arlake228]

Original issue 853 created by arlake228 on 2014-02-26T17:13:18.000Z:

This is more of an exploratory bug, because it has the potential to change behavior and community expectations. During ESCC it was revealed that many DOE facilities appreciate the 'appliance' aspect of the toolkit (either as a Live instance or a netinstall) and may not be following best practices for servers. To fully migrate toward 'appliance' behavior, automatic updates need to be considered via the yumd process (which we normally disable). Some things we need to suss out:

a) which sorts of updates can be applied hot vs require a reboot? Could we set the daemon to apply hot updates only?

b) the kernels come out of a seperate repo - could we make that be something the user has control over versus the update daemon?

c) do we see any downsides to this? Comment if you think so.

[arlake228]

Comment #1 originally posted by arlake228 on 2014-02-28T16:12:40.000Z:

One thing we would need to do if we do this is to have the RPM upgrade script run the "discover_external_addresses" so that it re-populates the various daemon.conf's. Theoretically, we may be able to get away from this with the new MA.

The only thing that could get weird would be major upgrades (e.g. changing to regular testing daemon, or changing to the new MA). Minor upgrades theoretically shouldn't be a problem. The kernel thing might be weird though since kernel upgrades can come from two repositories (standard CentOS upgrade, and ours).

[arlake228]

Comment #2 originally posted by arlake228 on 2014-03-23T17:27:57.000Z:

<empty>

[arlake228]

Comment #3 originally posted by arlake228 on 2014-05-06T18:16:52.000Z:

See these two FAQ items:

http://psps.perfsonar.net/toolkit/FAQs.html#Q73

http://psps.perfsonar.net/toolkit/FAQs.html#Q74

I believe we should implement some portion of this (excluding kernel updates), and just bite the bullet on automatic updates.

[arlake228]

Comment #4 originally posted by arlake228 on 2014-05-30T19:01:34.000Z:

My feeling is that Q74 should be expanded to mention excluding the kernel packages, and we leave it be. I think everything should work with autoupdate now (modulo various packages would need restarted since they don't restart automatically). However, that's a very different system administration concept than folks are used to, so I'd rather that be opt-in vs. opt-out.

To exclude kernel packages, edit /etc/sysconfig/yum-cron and change the YUM_PARAMETER line:

YUM_PARAMETER="-x kernel*"

[arlake228]

Comment #5 originally posted by arlake228 on 2014-05-30T19:50:25.000Z:

Added your suggested text to the FAQ item.

I would still like to explore the idea of allowing 3.4 (or 3.5) to have the autoupdate features on by default, will add something to the face to face agenda.

[arlake228]

Comment #6 originally posted by arlake228 on 2014-08-13T18:11:11.000Z:

pushing this to 3.4.1, pending more community input.

[arlake228]

Comment #7 originally posted by arlake228 on 2014-09-29T18:20:08.000Z:

Couple of FYIs:

• New FAQ item on the new web site: http://www.perfsonar.net/about/faq/#Q53
• Shellshock was a bash RPM that could/should have been autoupdated (as was heartbleed)

May want to re-consider the stance on this before we call 3.4 final.

[arlake228]

Comment #8 originally posted by arlake228 on 2014-09-30T21:17:25.000Z:

From the mailing list discussion, a summary:

• For 3.4: An entry in 'enabled services' named 'automatic software updates'. Help window can note it will download all (or a limited list?) of things from yum, but it won't reboot the machine. We make this 'on' by default
• Documentation of the above occurs in several places: 1) release notes, 2) release email, 3) special email on a different day than the release mail, 4) web/FAQs, etc
• Create (or augment?) a security BCP. Document should clearly state expectations for the project, and operator. Ensures that everyone is aware that auto-updates are not a panacea. It is a way to assist with machine maintenance, just as IPTables and the Host IDS are a way to assist with security. Proper CI maintenance is larger than just the protections and help the pS box can give.

[arlake228]

Comment #9 originally posted by arlake228 on 2014-10-01T16:05:02.000Z:

<empty>

[arlake228]

Comment #10 originally posted by arlake228 on 2014-10-01T20:57:23.000Z:

Fixed by adding checkbox to enabled services page. Also added script to enable on auto-updates if this is the first time using a version of the toolkit that supports controlling yum-cron through GUI.

[arlake228]

Comment #11 originally posted by arlake228 on 2014-10-06T16:19:52.000Z:

<empty>