From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 30 Mar 2004 - 22:58:23 BST
On Tue, Mar 30, 2004 at 09:46:14PM +0000, Liam Helmer wrote:
> On Tue, 2004-03-30 at 20:27, Enrico Scholz wrote:
> > Ok, I implemented the first part of your suggestion into util-vserver[1];
> > for the second one (iptables), I am not sure how to realize it (especially
> > the removal of the rules).
>
> I'll work on that one, 'cause it would be useful for me... I'll see if I
> can get something that works OK. Basically, to be useful, it would have
> to find ways of being very specific, and it would have to keep track of
> the state of each rule, as well as having a way to flush all rules in
> case of issues with it's state file, etc.
>
> So, you put the changes in CVS? I'm using my own hacked version of
> vserver right now, as I've been playing with some of my own designs.
>
> > The creation of the dummy devices is ugly and has races ('dummy0' is
> > used by every 'vserver ... start' instance which conflicts with the
> > parallel vserver startup). 'dummy<ctx>' would be ideally but is not
> > supported by the kernel.
actually it is, at least somewhat, 2.6 knows a numdummies=
argument, and some experimental patches of mine add enhanced
per chbind() dummy devices ... or allow to add 'another' one
on demand ...
> It is supported by the kernel -> that's what the nameif line that I put
> in there does. The only race state is before the dummy0 interface gets
> renamed... and that could be solved by having the script do some kind of
> interface locking while it changes the name, maybe?
>
> > > That offers better security, because it specifically allows any
> > > incoming traffic that may occur, as well as concealing the real IP
> > > from the vserver, which can be useful from a security standpoint.
> >
> > NAT (different external and internal IPs) is usually a pain when you are
> > working with UDP based services (Talk, Kerberos) since the "original" IP
> > will be often transmitted in the packet data.
>
> Agreed, there's some things that will simply never work in that
> scenario. Like I was saying, it's useful for security, but it's
> definitely not simpler for setup. What it is simpler for, however, is
> providing host-only services, as well as for dealing with boxes that
> have dynamic ips. And, it allows boxes with smaller numbers of IPs to
> still use ip layer security without the vserver's interfering with
> eachother's listeners.
>
>
> > I can imagine problems with the hostname checking of SSL too so that the
> > external IP must have a PTR record for the vserver's hostname (and vice
> > versa).
>
> I think the best way of dealing with this is either dynamically
> generated host records, or a host database (like ldap) that keeps track
> of everything.
>
> > I played a little bit with official IPs for the dummy devices and using
> > proxy-arp for it but run into some (unrelated) problems on my testmachine
> > (what means 'H' process-state under 2.6?). Currently, I do not have time
> > to investigate it further.
hmm, I'd suggest not to search for the 'H' on the net,
as probably noone ever wrote about it yet ;)
'H' means 'on hold' and is, to be honest, my creation.
a task, not scheduled because the context bucket is empty
is put on hold, and not scheduled, until the bucket has
reached tokens_min, then it is scheduled again ...
> Fair. I'll play around with it as my time permits.
keep us up to date, maybe we should chat a little on the
irc, tomorrow? ...
best,
Herbert
> Cheers,
> Liam
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver