From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 02 Sep 2005 - 02:06:17 BST
On Thu, Sep 01, 2005 at 04:04:03PM +0200, Nicolas Costes wrote:
> Le Jeudi 1 Septembre 2005 02:48, Herbert Poetzl a écrit :
> > On Wed, Aug 31, 2005 at 04:59:00PM +0200, Nicolas Costes wrote:
> > > Le Mercredi 31 Août 2005 10:56, Nicolas Costes a écrit :
> > > > Hello, all, I'm still getting a few vserver hosts to production
> > > > ;-).. Everything goes fine (There are mainly Samba vservers, not
> > > > too hard)
> >
> > sounds good!
> >
> > but are you sure linux-vserver is the product you
> > were looking for? because it seems you might be
> > happier with Xen or UML ...
>
> Er.. Why do you say that ?
I just got the impression, glad that I'm wrong :)
> (Anyway, If it was only for Samba, I would not use vservers. It's mainly
> to host side services with spared ressources : DNS slave, Distcc
> farm, ... And for security and ease of maintenance)
>
> > > > I'm now trying to setup a Netatalk vserver, and the Appletalk
> > > > protocol seems not to be my friend :( . I only managed to run the
> > > > afpd service (Afp-over-tcp).
> > basically all kind of linux supported protocols
> > will work inside a guest, given that they:
> > a) that the host can use them quite fine
>
> I tried, it works on the host.
good, that _is_ half the way ...
> > b) the guest has the proper capabilities
>
> Well, I tried writing CAP_NET_ADMIN and CAP_NET_RAW in the vserver's
> bcapabilities file, and this does apparently nothing.
check with 'grep Cap /proc/self/status'
from inside the guest ...
(and don't forget to restart the guest)
> # cat /etc/vservers/filesrv/bcapabilities
> CAP_NET_ADMIN
> CAP_NET_RAW
>
> I tried too by writing there "NET_ADMIN" and "NET_RAW", there is no
> error nor success.
>
> > > > So, My question is : Are the linux-vservers able to host services
> > > > other than tcp-based ones ?
> >
> > yep, but udp, tcp and special icmp are the only
> > ones supported 'by default' ...
>
> Which means ?
which means, other protocoly, other requirements
(mostly capability wise)
> One has got to activate something to use another protocol ?
yes, the cap stuff and it might be a problem
with missing and/or too strict virtualization
(but as I said, we can look into that)
> > > One more thing : Netatalk tries to load the appletalk kernel
> > > module on startup, which apparently fails because being inside a
> > > vserver. Anyway, the module is actually loaded when I start or
> > > stop the service ! (There is no need for it in the host server,
> > > but it appears there to. "One kernel to rule the all", huh ?)
> >
> > yep, that's the main idea behind linux-vserver.
> > contrary to Xen or UML you have only one kernel
> > running on the host, no guest kernel, no guest
> > modules jsut pure 100% userspace there ...
>
> This is good ;-) ! But what is fun, is that when /etc/init.d/atalkd
> is run (From inside the vserver), it "fails" to load the module, but
> actually the kernel loads it at this very moment !!!
>
> Maybe the kernel detects an access to some devices and loads the
> module from the host ?
yes, that is possible and likely ...
(maybe we have to 'restrict' this ...
> > > But atalkd still fails to start arguing that it cannot find any
> > > net device.
> >
> > maybe it needs special devices and/or capabilities
> > don't know yet, never tried to get it working ...
> > but we can investigate this soon, if you find some
> > time ...
> >
> > > This means the appletalk module isn't working.
> >
> > not necessarily, but might be the cause, did you
> > load it on the host?
>
> I made many tests of that kind: manually load/Unload the module
> from the host (Successes), from the vserver (Fails), unload the
> module from the host the launch atalkd in the vserver (The modules
> is loaded automagically but atalkd fails), strace atalkd, lauch
> the vserver's atalkd from the host - Yes, you read it right ;-),
> "/vserver/filesrv/usr/sbin/atalkd" on the command line (This
> works :-O> !) - etc....
>
> > > As installing a kernel and modules in each of my Mandriva vservers
> > > is mandatory, due to dependencies, it may be the wrong module that
> > > is loaded... (The host kernel is not the same as the vservers's
> > > ones)
>
> > well, guest modules and/or kernels are, as I mentioned
> > before, not used/allowed in linux-vserver, did you
> > load the guest module on the host?
>
> No. I'll try, but it's bound to fail, no ?
>
> > > I'm stuck there, any idea ?
> >
> > did you compile your host kernel (the linux-vserver
> > patched one) with appletalk support?
>
> Yes ;-) !
>
> > did you load the proper module and 'configure'
> > whatever appletalk requires (on the host)?
>
> Er... Well nothing, but as said above, it works out-of-the box on the
> host, even when launching the vserver's atalkd binary on the command
> line in the host (I still don't understand how this worked) => So I
> guess that the host's default configuration is ok for Appletalk.
>
> > > How are the non-IP protocols handled but linux-vserver ?
> >
> > they are not handled at all, most likely you need
> > special capabilites (like CAP_NET_RAW) to bind non
> > IP sockets ...
>
> Tried this, did not work, but not sure about me doing it well : I
> read the Big Weed Page, and the exact syntax for bcapabilities is not
> given (And I read the there-linked source file). Moreover, I don't
> think "vserver ... start" outputs error message in case of bad config
> file...
maybe we should move that to the irc
channel sooner or later :)
> > > Are module loads really allowed ?
> >
> > no, they should not be allowed, are they allowed
> > for you (inside your guests)?
>
> [root_at_srvfile /]#
> insmod /lib/modules/2.6.11-6mdk/kernel/net/appletalk/appletalk.ko.gz
> insmod: error inserting
> '/lib/modules/2.6.11-6mdk/kernel/net/appletalk/appletalk.ko.gz': -1
> Operation not permitted
>
> [root_at_srvfile /]# uname -a
> Linux srvfile.foo.com 2.6.12.5 #5 SMP Mon Aug 22 17:33:59 CEST 2005 i686
> Intel(R) Pentium(R) III CPU family 1133MHz unknown GNU/Linux
>
> First, the kernel version is not the same that the host's (But that
> doesn't seem to be the blocking element here), and moreover, I think
> the kernel does its job here in blocking the call ;-)
good!
best,
Herbert
> --
> ,,
> (°> Nicolas Costes
> /|\ IUT de La Roche / Yon
> ( ^ ) Clé publique: http://www.keyserver.net/
> ^ ^ Musique libre: http://musique-legale.info/ -
> http://www.jamendo.com/?s=concept
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver