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
