connect to each role in an (chef) environment and show all available package updates (with new version and current installed version)
for each node ask the user if all updates should be applied and if ‘no’, step through the list of updates and ask for each single update. if ENV[PACKAGES] (string with package names, seperated by ‘,’) is applied to the rake task, those packages will be updated without confirmation.
To avoid critical application updates (like postgresql), we set those packages ‘on hold’ (dpkg --set-selections) by a cookbook, so that they don’t get touched or listed by ‘apt-get dist-upgrade’ (which is executed in that rake task). In this combination keeping our ~50 (debian) nodes up to date is now a very simple and controllable task without much effort.
If there’s any interest, I could start to write a knife plugin for it.
Or how do you manage package updates? Are there better ways?
–
Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin
connect to each role in an (chef) environment and show all available package updates (with new version and current installed version)
for each node ask the user if all updates should be applied and if 'no', step through the list of updates and ask for each single update. if ENV[PACKAGES] (string with package names, seperated by ',') is applied to the rake task, those packages will be updated without confirmation.
To avoid critical application updates (like postgresql), we set those packages 'on hold' (dpkg --set-selections) by a cookbook, so that they don't get touched or listed by 'apt-get dist-upgrade' (which is executed in that rake task). In this combination keeping our ~50 (debian) nodes up to date is now a very simple and controllable task without much effort.
If there's any interest, I could start to write a knife plugin for it.
Or how do you manage package updates? Are there better ways?
--
Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin
I think we mentioned at ChefConf this year that we wrote a cookbook to try
to handle this. A knife plugin seems like an interesting alternative, but
we were thinking in terms of patching many servers at once ... in which
case you really don't want a human to answer a series of yes-or-no
questions even once to say which packages should or shouldn't be upgraded.
By moving those decisions into a version-controlled Chef object, it's at
least subject to your change control processes.
Has anyone else done anything like this in OSS Chef for patching, BTW?
On Fri, Oct 11, 2013 at 10:07 AM, Steffen Gebert st+gmane@st-g.de wrote:
Hi Holger,
yes, I'd like to use that!
Steffen
On 10/11/13 7:40 AM, Holger Amann wrote:
Hi!
I wrote a rake task which does the following:
connect to each role in an (chef) environment and show all available
package updates (with new version and current installed version)
for each node ask the user if all updates should be applied and if
'no', step through the list of updates and ask for each single update. if
ENV[PACKAGES] (string with package names, seperated by ',') is applied to
the rake task, those packages will be updated without confirmation.
To avoid critical application updates (like postgresql), we set those
packages 'on hold' (dpkg --set-selections) by a cookbook, so that they
don't get touched or listed by 'apt-get dist-upgrade' (which is executed in
that rake task). In this combination keeping our ~50 (debian) nodes up to
date is now a very simple and controllable task without much effort.
If there's any interest, I could start to write a knife plugin for it.
Or how do you manage package updates? Are there better ways?
--
Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin
