Re: [DISCUSS] Keeping system vms up to date

2016-02-23 Thread Erik Weber 
On Mon, Feb 22, 2016 at 8:58 PM, Rene Moser  wrote:

> Erik
>
> On 02/22/2016 01:50 PM, Erik Weber wrote:
> > Adding a boilerplate in the install/admin docs that says "If you have no
> > other tools in place to handle system vm updates, consider enabling this
> > option: x.y.z" is good enough for me.
> > This is supposed to be a way for all those who don't have any
> other/better
> > means of doing this, not a mandatory/forced way of doing it for everyone
> > else.
>
> Sounds good. :)
>
>
> >> I would like to see an api for download and update latest system-vm
> >> template. AFAIK this is still not solved (without touching DB) to update
> >> system-vm templates having same version.
>
> What do you think about security updating system VM templates?
> Up-to-date system vm templates would be needed anyway.
>
> >> This way it would be up to the user to handle the upgrade and to think a
> >> bit further we could also define a rollback scenario (use previous
> >> template).
> >>
> >>
> > This thread is ment to discuss varies ways to achieve the goal, I did not
> > mean to propose a single way of doing it.
> > Pushing an ansible inventory script (that works with all major ACS
> > hypervisors) and a playbook is another option.
>
> It is a shame but I have no experience with "other hypervisors" with
> ACS, just VMware. :( How are KVM/XEN different in VRs then VMware, isn't
> there a VR accessible by SSH (by so called "linklocal" IP) from ACS
> management node?
>

No, with vmware you use a routable network that is directly accessible from
the mgmt server, but for xenserver and kvm we use a link local network
(169.254.x.x), that is not wired to any physical interface.

Connection to system vms is done by using the actual hypervisor as a SSH
jumpstation.
I think I actually hacked your dynamic inventory script at one time to
support this, I can see if I can find it again.

-- 
Erik

RE: [DISCUSS] Keeping system vms up to date

2016-02-23 Thread Nuno Tavares 
Paul,

+1 for the upload a template as SYSTEM.
At least in 4.2 we have a global setting to specify which template is to be 
used, but indeed there is no way to upload or change a template into SYSTEM. 
This has to be done by means of DB change.

-NT



Kind regards,

Nuno Tavares
Senior DevOps Infra Specialist
LeaseWeb Technologies B.V.

T: +31 20 316 0235

E: n.tava...@tech.leaseweb.com
W: www.leaseweb.com<http://www.leaseweb.com>

Luttenbergweg 8,1101 EC Amsterdam,  Netherlands



From: Paul Angus [paul.an...@shapeblue.com]
Sent: Monday, February 22, 2016 1:39 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Keeping system vms up to date

I think that there are two parts to this - creating system VMs and installing 
them.

The systemvms need to have the automated build with versioning 4.5.2-1234 (I'd 
like to see that shown in log on screen of all system vms)

+ we should have some direct control available in CloudStack of which template 
is the system VM template. And be able to upload a template as 'SYSTEM'.


<http://www.shapeblue.com>
Paul Angus
VP Technology   ,   ShapeBlue


d:  +44 203 617 0528 | s: +44 203 603 
0540<tel:+44%20203%20617%200528%20|%20s:%20+44%20203%20603%200540> |  
m:  +44 7711 418784<tel:+44%207711%20418784>

e:  paul.an...@shapeblue.com | t: 
@cloudyangus<mailto:paul.an...@shapeblue.com%20|%20t:%20@cloudyangus>  |
  w:  www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK





Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services 
India LLP is a company incorporated in India and is operated under license from 
Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in 
Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd 
is a company registered by The Republic of South Africa and is traded under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error.




-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Monday, February 22, 2016 9:37 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Keeping system vms up to date

Hi Erik,

Legit worry point.

IMHO the updates of the VR and so on should be the job of whoever runs the 
cloud, just like it's the same person's job to keep the HVs up to date.

I'm sure it's possible to get all the VRs registered in some sort of 
ansible/puppet thingy and keep track of them this way.

Regarding up to date VM templates, I think part of the problem is solved as 
Jenkins is building 4.6 frequently:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

It might just be a matter of uploading those to cloudstack.apt-get.eu.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Erik Weber" <terbol...@gmail.com>
> To: "dev" <dev@cloudstack.apache.org>
> Sent: Monday, 22 February, 2016 08:53:48
> Subject: [DISCUSS] Keeping system vms up to date

> 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

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Rene Moser 
Erik

On 02/22/2016 01:50 PM, Erik Weber wrote:
> Adding a boilerplate in the install/admin docs that says "If you have no
> other tools in place to handle system vm updates, consider enabling this
> option: x.y.z" is good enough for me.
> This is supposed to be a way for all those who don't have any other/better
> means of doing this, not a mandatory/forced way of doing it for everyone
> else.

Sounds good. :)


>> I would like to see an api for download and update latest system-vm
>> template. AFAIK this is still not solved (without touching DB) to update
>> system-vm templates having same version.

What do you think about security updating system VM templates?
Up-to-date system vm templates would be needed anyway.

>> This way it would be up to the user to handle the upgrade and to think a
>> bit further we could also define a rollback scenario (use previous
>> template).
>>
>>
> This thread is ment to discuss varies ways to achieve the goal, I did not
> mean to propose a single way of doing it.
> Pushing an ansible inventory script (that works with all major ACS
> hypervisors) and a playbook is another option.

It is a shame but I have no experience with "other hypervisors" with
ACS, just VMware. :( How are KVM/XEN different in VRs then VMware, isn't
there a VR accessible by SSH (by so called "linklocal" IP) from ACS
management node?

René

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Erik Weber 
On Mon, Feb 22, 2016 at 1:18 PM, Rene Moser  wrote:

> Hi
>
> I don't like the idea cloudstack management handles the "apt-get update
> && apt-get upgrade" (I am -1 for this solution) or at least I would like
> to disable it by configuration, if we go this direction.
>

It should by no means be mandatory, and wether or not it should be default
on is up for debate.
I have no strong opinion about the latter.

Adding a boilerplate in the install/admin docs that says "If you have no
other tools in place to handle system vm updates, consider enabling this
option: x.y.z" is good enough for me.

This is supposed to be a way for all those who don't have any other/better
means of doing this, not a mandatory/forced way of doing it for everyone
else.


We use ansible (what a surprise) to update the VR and also add some
> custom patches to it. We have a dynamic inventory getting all the VR
> with linklocal IP as ssh host and regulary run playbooks to these VRs
> running by a jenkins job.
>
> This sounds a bit kind of a hack at the beginning but it has the
> advantage that we are able to run the very same playbooks also against
> our test and stage cloud. Which gives a good feeling.
>
> I would like to see an api for download and update latest system-vm
> template. AFAIK this is still not solved (without touching DB) to update
> system-vm templates having same version.
>
> This way it would be up to the user to handle the upgrade and to think a
> bit further we could also define a rollback scenario (use previous
> template).
>
>
This thread is ment to discuss varies ways to achieve the goal, I did not
mean to propose a single way of doing it.
Pushing an ansible inventory script (that works with all major ACS
hypervisors) and a playbook is another option.

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Erik Weber 
We are comparing different sources, I was comparing the 'official' e.g. the
documented template, not the one regularely built by jenkins.

-- 
Erik


On Mon, Feb 22, 2016 at 1:11 PM, Remi Bergsma 
wrote:

> It _must_ be lying :-)
>
> When I install a systemvm from this last build:
>
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-xen.vhd.bz2
>
>
> It has 4.6.0 version, but /etc/cloudstack-version shows it was built today.
>
> cat /etc/cloudstack-release
> Cloudstack Release 4.6.0 Mon Feb 22 09:33:04 UTC 2016
>
> Regards,
>
> Remi
>
>
>
>
>
>
> On 22/02/16 12:23, "Erik Weber"  wrote:
>
> >On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma <
> rberg...@schubergphilis.com>
> >wrote:
> >
> >> 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.
> >>
> >>
> >If they aren't accessible from the internet then securing them isn't as
> >important either.
> >You still have to factor in the internal risk, but that is generally far
> >lower than the external risk.
> >
> >In cases where it is accessible from the internet, but does not have
> >outgoing access to the internet you're up for a treat.
> >
> >
> >
> >> Option 2) I think we already do that?
> >>
> >>
> >
> >Unless the web server is lying to me, then no:
> >eriweb@eriweb:~$ curl -Is
> >
> http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
> >| grep Last-Modified
> >Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT
> >
> >
> >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.
> >>
> >>
> >Sure I know that, but to replace the whole system vm just to update glibc,
> >haproxy or what have you seems a bit extreme.
> >
> >My intention for this thread was to figure out if we can provide
> cloudstack
> >users a way to ensure their system vms are kept up to date.
> >It should be optional so that more advanced users or those without
> internet
> >etc. don't run into issues because of it, while still keeping all those
> >small clouds that 'just works' safe and secure.
> >
> >--
> >Erik
>

RE: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Paul Angus 
I think that there are two parts to this - creating system VMs and installing 
them.

The systemvms need to have the automated build with versioning 4.5.2-1234 (I'd 
like to see that shown in log on screen of all system vms)

+ we should have some direct control available in CloudStack of which template 
is the system VM template. And be able to upload a template as 'SYSTEM'.


[ShapeBlue]<http://www.shapeblue.com>
Paul Angus
VP Technology   ,   ShapeBlue


d:  +44 203 617 0528 | s: +44 203 603 
0540<tel:+44%20203%20617%200528%20|%20s:%20+44%20203%20603%200540> |  
m:  +44 7711 418784<tel:+44%207711%20418784>

e:  paul.an...@shapeblue.com | t: 
@cloudyangus<mailto:paul.an...@shapeblue.com%20|%20t:%20@cloudyangus>  |
  w:  www.shapeblue.com<http://www.shapeblue.com>

a:  53 Chandos Place, Covent Garden London WC2N 4HS UK


[cid:imagef433a4.png@a42641b9.4cba1c4d]


Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services 
India LLP is a company incorporated in India and is operated under license from 
Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in 
Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd 
is a company registered by The Republic of South Africa and is traded under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error.




-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Monday, February 22, 2016 9:37 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Keeping system vms up to date

Hi Erik,

Legit worry point.

IMHO the updates of the VR and so on should be the job of whoever runs the 
cloud, just like it's the same person's job to keep the HVs up to date.

I'm sure it's possible to get all the VRs registered in some sort of 
ansible/puppet thingy and keep track of them this way.

Regarding up to date VM templates, I think part of the problem is solved as 
Jenkins is building 4.6 frequently:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

It might just be a matter of uploading those to cloudstack.apt-get.eu.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Erik Weber" <terbol...@gmail.com>
> To: "dev" <dev@cloudstack.apache.org>
> Sent: Monday, 22 February, 2016 08:53:48
> Subject: [DISCUSS] Keeping system vms up to date

> 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
Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | 
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | 
CloudStack Software 
Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure 
Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack 
Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Rene Moser 
Hi

I don't like the idea cloudstack management handles the "apt-get update
&& apt-get upgrade" (I am -1 for this solution) or at least I would like
to disable it by configuration, if we go this direction.

We use ansible (what a surprise) to update the VR and also add some
custom patches to it. We have a dynamic inventory getting all the VR
with linklocal IP as ssh host and regulary run playbooks to these VRs
running by a jenkins job.

This sounds a bit kind of a hack at the beginning but it has the
advantage that we are able to run the very same playbooks also against
our test and stage cloud. Which gives a good feeling.

I would like to see an api for download and update latest system-vm
template. AFAIK this is still not solved (without touching DB) to update
system-vm templates having same version.

This way it would be up to the user to handle the upgrade and to think a
bit further we could also define a rollback scenario (use previous
template).

Regards
René



On 02/22/2016 09:53 AM, Erik Weber 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.

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Remi Bergsma 
It _must_ be lying :-)

When I install a systemvm from this last build:
http://jenkins.buildacloud.org/job/build-systemvm64-master/lastBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-xen.vhd.bz2


It has 4.6.0 version, but /etc/cloudstack-version shows it was built today.

cat /etc/cloudstack-release
Cloudstack Release 4.6.0 Mon Feb 22 09:33:04 UTC 2016

Regards,

Remi






On 22/02/16 12:23, "Erik Weber"  wrote:

>On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma 
>wrote:
>
>> 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.
>>
>>
>If they aren't accessible from the internet then securing them isn't as
>important either.
>You still have to factor in the internal risk, but that is generally far
>lower than the external risk.
>
>In cases where it is accessible from the internet, but does not have
>outgoing access to the internet you're up for a treat.
>
>
>
>> Option 2) I think we already do that?
>>
>>
>
>Unless the web server is lying to me, then no:
>eriweb@eriweb:~$ curl -Is
>http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
>| grep Last-Modified
>Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT
>
>
>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.
>>
>>
>Sure I know that, but to replace the whole system vm just to update glibc,
>haproxy or what have you seems a bit extreme.
>
>My intention for this thread was to figure out if we can provide cloudstack
>users a way to ensure their system vms are kept up to date.
>It should be optional so that more advanced users or those without internet
>etc. don't run into issues because of it, while still keeping all those
>small clouds that 'just works' safe and secure.
>
>-- 
>Erik

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Erik Weber 
On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma 
wrote:

> 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.
>
>
If they aren't accessible from the internet then securing them isn't as
important either.
You still have to factor in the internal risk, but that is generally far
lower than the external risk.

In cases where it is accessible from the internet, but does not have
outgoing access to the internet you're up for a treat.



> Option 2) I think we already do that?
>
>

Unless the web server is lying to me, then no:
eriweb@eriweb:~$ curl -Is
http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
| grep Last-Modified
Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT


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.
>
>
Sure I know that, but to replace the whole system vm just to update glibc,
haproxy or what have you seems a bit extreme.

My intention for this thread was to figure out if we can provide cloudstack
users a way to ensure their system vms are kept up to date.
It should be optional so that more advanced users or those without internet
etc. don't run into issues because of it, while still keeping all those
small clouds that 'just works' safe and secure.

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Erik Weber 
On Mon, Feb 22, 2016 at 10:36 AM, Nux!  wrote:

> Hi Erik,
>
> Legit worry point.
>
> IMHO the updates of the VR and so on should be the job of whoever runs the
> cloud, just like it's the same person's job to keep the HVs up to date.
>

Well, to some point I agree, but we should do our best to reduce that need
IMHO. The hypervisor is under your control and is something you supply to
CloudStack.
The only reference a lot of people have to the system vm is that they do
the initial seeding (from a provided template in most cases), and that is
that.

In general you don't need to do much inside the system vms, and I fear that
there are a lot of clouds out there with uber old system vms because people
don't generally think about how they are exposed.

At minimum we should write something about it, e.g. "How to make sure your
system vm is up to date and secure" and possibly provide some options on
how to achieve that. Currently I don't think there's a single sign that you
have to worry about it at all.



>

I'm sure it's possible to get all the VRs registered in some sort of
> ansible/puppet thingy and keep track of them this way.
>
>
Sure, atleast ansible support dynamic inventory.


> Regarding up to date VM templates, I think part of the problem is solved
> as Jenkins is building 4.6 frequently:
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>
> It might just be a matter of uploading those to cloudstack.apt-get.eu.
>

That would solve 2)

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Remi Bergsma 
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"  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

Re: [DISCUSS] Keeping system vms up to date

2016-02-22 Thread Nux! 
Hi Erik,

Legit worry point.

IMHO the updates of the VR and so on should be the job of whoever runs the 
cloud, just like it's the same person's job to keep the HVs up to date.

I'm sure it's possible to get all the VRs registered in some sort of 
ansible/puppet thingy and keep track of them this way.

Regarding up to date VM templates, I think part of the problem is solved as 
Jenkins is building 4.6 frequently:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

It might just be a matter of uploading those to cloudstack.apt-get.eu.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Erik Weber" 
> To: "dev" 
> Sent: Monday, 22 February, 2016 08:53:48
> Subject: [DISCUSS] Keeping system vms up to date

> 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