cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <LSim...@schubergphilis.com>
Subject Re: Shellshock
Date Mon, 06 Oct 2014 17:03:51 GMT
On Oct 3, 2014, at 4:03 PM, Alex Brett <alex.brett@citrix.com> wrote:
> On 03 October 2014 13:52, Adrian Lewis [adrian@alsiconsulting.co.uk] wrote:
>> The only solution I can think of is to 'apt-get update bash' on every
>> system VM but clearly these get fired up dynamically. Is it possible to
>> boot the template, make modifications and then use as a replacement system
>> VM? Are there processes that happen on boot that only happen once and
>> therefore need resetting to recreate the template?
> 
> This isn't a quick fix, so not suitable for this specific issue, but something I've wondered
for a while is rather than keep having to build new system VM templates for every small change,
would we be better integrating a tool such as Puppet / Chef, so we can bring a system VM 'up
to date' when it boots, as long as it's the right 'base'.
> 
> What I'm thinking here (using Puppet terminology as that's what I'm familiar with, but
could be any similar mechanism or even just a simple script) is when the system VM loads up,
it connects to the management server and retrieves a manifest, which it then applies. That
manifest would specify:
> - Packages to update (including if necessary any apt/yum repo information)
> - Config files to put in place
> - Anything else required like starting any services etc
> 
> While it would slightly delay the boot process, it would ensure that on e.g. upgrade,
you don't have to immediately replace your system VM template unless a substantial change
(e.g. base system VM distro / partition layout) has been made. You could still bring in an
updated template to speed things up, but it would be far less urgent to do so...
> 
> Any thoughts on this anybody?

We've had the same thoughts and investigated it in some detail, 78f21166c10f291fca395c6ab8d67b7137e0ea86
is about the last point before we abandoned that approach.

https://github.com/schubergphilis/cloudstack/blob/78f21166c10f291fca395c6ab8d67b7137e0ea86/systemvm/patches/debian/config/opt/cloud/bin/merge.py
https://github.com/schubergphilis/cloudstack/tree/78f21166c10f291fca395c6ab8d67b7137e0ea86/tools/vagrant/systemvm

the idea was that all systemvm configuration would take the shape of chef data bags passed
along from the management server, that would then be used to configure chef cookbooks that
would be executed using chef-solo.

We abandoned this approach because running chef-solo took too long and used too many resources;
I think a similar argument would hold against ‘puppet apply’. The systemvm when deployed
as a router is a network device and I guess in general that having heavy processes running
periodically on active network devices is a bit scary.

So now the "persistent config" part of our redundant vpc router branch is still using the
configuration management model of converging to a desired state, but written using a less
fancy but more efficient and predictable custom python script.

https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/systemvm/patches/debian/config/opt/cloud/bin/configure.py

Having said all that, I agree with Logan that

On Oct 3, 2014, at 5:30 PM, Logan Barfield <lbarfield@tqhosting.com> wrote:
> In the long term I think the better option would be to allow
> the templates to be patched more easily (i.e. make changes and save the
> template).

Right now we resort to custom template builds a times, as well as various bits of cloudmonkey
or marvin scripting to find and iterate over system vms and do things to them (like apply
bash patches). It’s possible to do this stuff but it isn’t easy, and it would definitely
be good to have a well-beaten path for operators to wander down.

I’m not sure having the management server assume responsibility over some of the systemvm
patching would be good: it could get into conflict with operators wanting to do their own
/ slightly different patching. It’d have to be an appropriately ‘open’ design which
then brings with it its own set of security considerations.


cheers,


Leo


Mime
View raw message