From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 22 Sep 2003 - 20:59:22 BST
On Mon, Sep 22, 2003 at 02:53:23PM -0400, Rik van Riel wrote:
> Hi,
>
> I'm wondering how much of the 2.4 vserver infrastructure
> is really needed to achieve the same functionality in 2.6.
guess we need some central syscall switch, as proposed
by yourself, and a nice (working) concept for context
creation, manipulation and destruction ...
> I suspect that we need to look at reimplementing some of
> the vserver functionality with other components of the
> kernel, so the vserver patch becomes smaller and could
> even be merged into the main line kernel.
would be nice, although I doubt that it could/will be
merged soon ...
> Ideally vserver would be standard functionality and not
> a separate fork.
agreed, but that is a long way ...
> For the various components of vserver, I could envision
> using these technologies:
>
> - unbreakable chroot
> --> filesystem namespaces, CLONE_NS, recursive bind mount
> (already in 2.4 and 2.6 kernels, needs userspace helper)
did that some time ago, seemed to work reasonably well,
(see http://www.13thfloor.at/VServer/Virtual/)
> - separated out /proc namespaces
> --> cannot be done yet, needs vserver implementation
> reuse same implementation for selinux ?
maybe separating out some lists will do a major part
of the /proc virtualization, /proc/mount can be done
with the namespace virtualization, resources should be
done by the CKRM, processes will be done by vserver ...
> - firewalling, probably IP address binding
> --> netfilter & selinux framework
I would prefer a virtual network device like that Alex?
does, so you can create it from outside, and configure
it from inside ... where iptables & co do the security
on both sides ...
> - cpu & memory resource use of vservers
> --> CKRM, see http://ckrm.sourceforge.net/
we'll see ...
I currently doubt that class and context fit well
> - network resource use of vservers
> --> reuse normal traffic control infrastructure,
> maybe selinux infrastructure
>
> - per-vserver disk quota
> --> maybe the selinux people are interested in this too ?
> make this something generic, beyond just vserver
guess this will not make it into selinux, because the
per context tagging of files/dirs is a requirement, but
nobody would do that without good reason.
same goes for the per context disk limits ...
> This leaves one, maybe two, components of vserver that need a
> special vserver specific implementation. The rest can be done
> using already existing or generic-but-still-in-development
> infrastructure.
>
> Having vserver as small as possible should not only make it
> easier to maintain, but also to get it merged upstream.
>
> What do you think?
good idea ... 8-)
best,
Herbert
> Rik
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan