cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <RBerg...@schubergphilis.com>
Subject Re: [DISCUSS] Keeping system vms up to date
Date Mon, 22 Feb 2016 10:42:26 GMT
Hi Erik,

The version might not change, but Jenkins builds new ones every night with latest OS patches:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

Option 1) and 3) will work once we allow more space on the systemvm template for it to actually
handle installing stuff. You then also assume they have internet acces, which may not be true.

Option 2) I think we already do that?

You can always upload a new template and replace it (a global config like systemvm.minversion
or so exists). This will require to reboot all routers currently.

Regards,
Remi





On 22/02/16 09:53, "Erik Weber" <terbolous@gmail.com> wrote:

>As of 4.6 or so, we don't really need to distribute new system vm templates
>all that often, and that is great for upgrades, but less so from a security
>perspective.
>
>With the current approach we ship old system vm templates, with out of date
>packages, and there is currently no good out of the box way to handle that.
>
>There is a few ways to handle it, including, but not limited to:
>
>1) Introduce a configuration value that specifies if you want to run
>apt-get update && apt-get upgrade on boot. This slows down deployments and
>will only get worse as times passes and there are more packages to update.
>An alternative is to specify a list of packages we _HAVE_ to keep updated
>and only update those.
>
>2) Package new system vms for all releases, but not bump the version number
>(or introduce a patch version number). This is ment to ensure that new
>cloud deployments are somewhat up to date, but won't update existing ones
>nor ensure that the deployment is kept up to date.
>
>3) Add an optional? cronjob that does apt-get update && apt-get upgrade,
>the downside is that you risk having some downtime for certain services.
>
>4) A combination of the previous 3.
>
>And most likely other options I haven't thought of.
>
>I feel we need to address this somehow or else we risk ending up as a very
>negative headliner when the right (or wrong) bug/exploit gets out and takes
>down a bunch of clouds..
>
>-- 
>Erik
Mime
View raw message