[Lxc-users] is 0.7.1 the last version? Is there a ppa (ubuntu) for it?

[Serge E. Hallyn]

Quoting Dave Manginelli (dmanginelli at comcast.net):
> On Thu, 2010-07-29 at 15:04 -0500, Serge E. Hallyn wrote:
> > Quoting Osvaldo Filho (arquivostcf at gmail.com):
> > > is 0.7.1 the last version? Is there a ppa (ubuntu) for it?
> > > 
> > > Any ubuntu package for new LXC
> > 
> > 0.7.1 is the default in maverick.
> > 
> > I have 0.7.0 in a private ppa for lucid - I could put 0.7.1 in there,
> > but much as I'd like to, merging 0.7.1 into lucid itself isn't likely
> > to happen.
> > 
> > -serge
> 
> Serge,
> 
> I dropped Linux Vserver for LXC because I wanted to get on board with
> the "official" Ubuntu virtualization for Lucid, having chosen Lucid
> itself because of it's LTS status.  
> 
> I understand the concept of freezing software for the sake of stability
> once the official release is made, however, I'm having a hard time
> squaring that with the concept of "Long Term Support" when the code as
> initially shipped seems to be in need of security and other fixes.

The mantra is: true security fixes will be back-ported.  Features will
not.

> Your reference to Maverick implies that you think one should migrate
> entirely to Maverick to get the latest LXC code (or is there a way that
> I can guarantee that the Maverick version of LXC will work on Lucid?).
> That puts me between a rock and a hard place in that I may either a)
> keep with Lucid and run a substandard version of a key piece of my
> server platform or b) abandon the concept of LTS and move to Maverick
> but then have to move again sooner because Maverick isn't an LTS
> release.

I understand the feeling, but I'm not sure that in this case you have
an option.  Consider that if you're going to be serious about using
LXC, you'll need other pieces updated as well - kernel, /sbin/ip,
perhaps others as well.  It wouldn't be an LTS release if all of those
kept changing.  And consider that a part of the point of an LTS is to
not require users to re-educate about usage.  And, of course, the
other part is that any back-ported feature is likely to introduce 3
new bugs and 1 security hole - and that's not a dig at myself or
Daniel or the lxc team :)

> I guess the final alternative is to compile my own up-to-date LXC, but
> there again I've strayed from the idea of committing to a "standardized"
> server platform that I can count on for an extended period without
> having to perform manual updates and recompiles whenever an LXC security
> fix is required.

I don't mind continuing to merge newer lxc in my own ppa for lucid.  At
some point, however, newer lxc will start requiring newer kernels, and
that's where we really get into trouble.  There is a maverick-to-lucid
backport kernel ppa, maybe we then say you need those as well?  That
could work I suppose.

For instance, if/when the 'drop ns cgroup' kernel patch gets accepted,
lxc will need a patch to have it create its own new cgroup.  That may
not play nice with older kernels.

> I know you don't set the policy, Serge, and you're one of the good guys
> since you've provided the 7.1 ppa version--I just hope the viewpoint
> I've expressed above is being considered somewhere at Cononical.
> 
> Thanks for your efforts and thanks especially to the folks here working
> on continually improving LXC.
> 
> PS. Maybe I'm just a paranoid LXC newcomer.  Tell me that the version of
> LXC in the official Lucid repositories is safe and secure (and will
> continue to be) and I'll just assume that the newer versions just add
> bells and whistles I shouldn't be worried about...

I'd love to, but

1. I never consider sw safe and secure

2. I never consider hw safe and secure

and, most of all

3. imo virtualization (even kvm etc) is "safe and secure" enough to be
useful for workload compartmentalization, but not for confining a hostile
root in a sensitive environment.

But I *will* backport security fixes to lucid, and I'll keep a reasonably
new lxc back-ported in my ppa.  Pls feel free to shoot me an email
whenever a new release is out that you want pulled there.  And if the
git changelog is getting too long without a new release, we'll start
bribing Daniel to tag a new release :)

-serge