>>>>> "EW" == Ed W <li...@wildgooses.com> writes:
>> The only real reason was that after upgrading the host to Debian
>> 6.0 OpenAFS access stopped to work in my VServer guests which was
>> a big trouble for me.
EW> Curious. It's not something I use, but is there a systemic
EW> reason why this doesn't work? In my experience vserver never
EW> stops you doing something, only stops you doing something if you
EW> don't want to give up the security of a full container?
I don't recall the details but considering my previous experience with
OpenAFS and VServer and what I had read about it from other people I
simply decided to choose a possibly easier way. It's not that important
whether something can be done _in theory_ (usually it can because
problems can be fixed), what matters more is how much and with how much
effort can be achieved using available tools and documentation. (*)
>> I couldn't find any quick solution and because Debian is going to
>> drop VServer support in the next major release anyway,
EW> I'm actually unsure what you mean by that since there has been
EW> no real "support" from debian in the past? I guess if you mean
EW> that the official debian project ships some antique kernels with
EW> patches some many years out of date, then yes I hear that might
EW> go away, but in any case a debian user would seem to be creating
EW> problems for themselves not to just use a modern kernel from
EW> Bristol Wireless or a self patched kernel?
I've abandoned the ritual of compiling Linux myself about ten years ago
and I don't regret it. It was fun when I was a student, but later it
has become better to use the results of work of others and spend my
limited resources (nobody pays me for compiling the kernel) on more
useful things. I can understand other people enjoy it or have to do it
for some reasons, but this is not my case anymore.
I don't understand what you mean by "antique kernel". 2.6.32 is a
pretty recent kernel in my view (considering Linux has been well usable
and stable for at least 17 years) and unless I buy new hardware or so it
should serve me well for the next few years.
With aufs2 it's different as it's new product, so it's possible the one
year old version was immature and I should really try the current
version instead.
EW> but given that you are apparently happy to add aufs2 patches
EW> yourself
I'm not but it seems I've got no choice in this case.
EW> (surely Debian doesn't patch these in?),
Apparently not as often as it should. At least one of the Debian kernel
maintainers classifies aufs2 as "dirty hack" (well, without providing
anything better right now) so I don't expect much support from there.
EW> I have heard others shape their plans based on whether Debian
EW> continued to ship a patched kernel with completely out of date
EW> vserver patches or not - to my mind debian kernels are just
EW> antique however you look at it and not worth the effort?
External patches always create problems. The primary problem is not
with Debian but with the fact that both VServer and aufs have been
rejected from inclusion into the official kernel (I don't judge the
decisions). When Debian includes unofficial patches, it in fact means
extra effort to overcome the decision of Linux maintainers and risking
various headaches.
EW> I don't see that LXC (yet) really secures the guest completely
EW> and if you don't do that then to some extent, what's the point?
I don't think LXC is the worst security problem in my environment. In
home environment it's much more about feature isolation, so that I don't
risk breaking unrelated things and so that I can revert unsuccessful
changes easily (with the exception of the host).
>> It provides better device and network isolation, e.g. `mknod
>> /dev/null'
EW> I think this can be allowed with vservers also? It's a security
EW> option to disallow it, but you can either have the host run the
EW> mknod in the guest, or give the guest the correct capabilities
EW> (disabled by default though)?
I don't now the current state in VServer, but with LXC you can
selectively define which devices mknod may create.
>> is easily possible and each container can have its own routing
>> and filtering rules.
EW> I believe this works with vservers also? The routing either
EW> needs to be done by the host with the default setup,
Not so good.
EW> OR you can enable the full network isolation as per LXC and use
EW> the virtualised network stuff in vservers?
Last time I tried I haven't found a way to do it (see (*)).
EW> I understand that most use the former because it's lighter
EW> weight, but the full network isolation can be useful for
EW> advanced situations where the extra virtualisation overhead is
EW> not important?
Yes.
>> I can run OpenVPN in a container (no previous success with
>> VServer),
EW> I don't believe this is a problem, other than assigning IPs to
EW> the guest (which is disallowed by default, but enabled by
EW> capabilities)?
Maybe but last time I tried it didn't work (see (*)).
>> X server works also fine (not considering security)
EW> Hmm, do you mean server or client?
Both.
EW> If you mean server then I guess that's a fairly unusual and
EW> specific setup? I think you need to giveup a lot of isolation
EW> to run X server in a vserver,
Only from the point of view of security, which doesn't matter much on a
desktop machine. Separating the client and the server troubles itself
as well as running the server on the host.
>> It's possible to run just a single application in an isolated
>> environment.
EW> Obviously you can do the same with vserver, so I suspect you
EW> mean something much more subtle? Is there some easy way to
EW> create a more functional "chroot" in LXC then?
I don't now as I don't use this feature although I should probably think
about it.
EW> I don't use Debian, but all I hear is "bugs", "old and stale",
EW> "source install"? I don't quite get why many users use Debian -
EW> seems like it excels in "stable",
Debian excels in several areas and I don't know any other distribution
satisfying my needs. That upstream software is often buggy, unfinished
and unstable is not a fault of Debian.
EW> but most users at some point want "latest and greatest", at
EW> which point you need to giveup Debian
No, you have choice between using "stable", "testing" or "unstable". I
usually prefer "stable" last years as the "latest and greatest" breaks
something all the time. It typically takes less effort to find a way to
live with known bugs for a few years untouched than to solve new
problems every week.
>> Generally, I could basically move my guests to LXC rather easily
>> and it solved some problems I had previously with VServer.
EW> Curious - what problems (apart from the above, ie AFS and
EW> XServer?)
I don't think there is anything else than what I've already mentioned.
EW> I guess the COW chunk of the vserver kernel patch could be
EW> broken out thought? I believe there are other COW
EW> implementations also?
This has been discussed on the LXC mailing list several times and I
couldn't find there anything better than aufs2 or possibly Union mounts.
Things like btrfs or LVM provide some copy-on-write support but it's not
clear how to utilize it for the purpose and btrfs is not yet finished
anyway.
EW> There used to be a Vserver+aufs howto? I never read it, but
EW> there are references to it on the aufs website? Presumably this
EW> would have some interesting clues if you could locate it?
Thanks for tip, I'll try to look at it.
EW> I suspect a sensible solution would be to reverse the hashify
EW> solution. Mount an aufs writeable root over a base filesystem.
EW> Then allow it to evolve. Next update the base filesystem in a
EW> way which should remove most of the changes in the clients.
EW> Finally stop the clients and use something like rsync to build a
EW> new client (new changes dir mounted over new base, make it match
EW> the old client)? Does that work?
If I understand you correctly this is something I thought about. It
might work although I don't like stopping the clients (maybe lxc-freeze
would be possible and acceptable). If I'm going to build a custom
kernel I should probably also look at what Union mounts offer.
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
