From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Sat 22 Nov 2003 - 15:31:33 GMT
On Fri, 21 Nov 2003 05:53:02 -0500, Herbert Poetzl wrote
> 0.1 Variables
>
> the vserver script knows and uses the following shell
> variables when it comes to deciding how to set up
> network interfaces and ipv4root:
>
> IPROOT, IPROOTDEV, IPROOTMASK, IPROOTBCAST, and NODEV
>
> while you might already know the first four, the last
> probably will sound unfamiliar, as it can't be specified
> in the <vserver>.conf file yet[1].
> NODEV is set by the --nodev option passed to the script
> and basically disables the network alias setup, but not
> the chbind, which might give unexpected results.
As explained in the man page, the purpose of --nodev is to enter a vserver
context without enabling the aliases, so without making it active on the
network. For example, you may have two copy of a vserver, one running and not
the other and you wish to enter the second to check something. If the second
is located on a different physical server, enabling the network aliases
would cause problem to the first one.
Is there any other usage to --nodev
> 1. The Network Aliases
>
> 1.1 Basic Requirements
>
> basically the following is required to execute the code
> creating an alias of an existing interface:
>
> - NODEV is not set (--nodev option not given)
> - IPROOT is not empty and does not have the values
> IPROOT="0.0.0.0" or IPROOT="ALL"
We need a vservers.conf manpage...
> 1.3 Is there a Device?
>
> now the script checks whether <device> is non empty
> (which means either IPROOTDEV or the device part for
> this entry wasn't empty), and if found so, does the
> following (if not, continue with the next entry):
>
> - if a vlan device was specified (<name>.<vlan>)
> some vlan setup (vconfig add ...) is done and
> a fake base address (127.0.0.1) is assigned.
>
> anyway, the next step is very interesting, as it
> introduces some indeterministic components, due to
> an uninitialized pair of variables[2] ...
I initialised them to 0xffffffff
Is this fine ?
> 1.4 Determinism? Sometimes!
>
> the up to now collected values for <device>, <ip>,
> <netmask> are completed by a <broadcast> which is
> set to IPROOTBCAST (which can be empty) and fed
> into a (C++/C) tool called 'ifspec' which aims to
> give the 'device specification' in a 'shell usable'
> way ...
>
> called like this
>
> # ifspec <device> <ipaddr> <netmask> <broadcast>
>
> it basically does the following:
>
> - if <ipaddr> is non empty, output ADDR=<ipaddr>
> - otherwise try to get the ipaddr from the
> interface <device> (via SIOCGIFADDR), and if
> successful, output that in the same format.
>
> now the same is done for <netmask> with
> NETMASK=<netmask>/SIOCGIFNETMASK and for
> <broadcast> with BCAST=<broadcast>/SIOCGIFBRDADDR
> except for the detail, that if the <broadcast>
> isn't specified, and can't be retrieved from the
> kernel, the tool tries to compute that value in
> the following manner:
>
> <broadcast> = (<ipaddr> & <netmask>) | ~<netmask>
>
> which is perfectly right, if both, <ipaddr> and
> <netmask> either have been specified or returned
> by the kernel, and interesting[2] if not ...
Is this correct. I mean, if we specified only the ip address and netmask, the
broadcast should be setupa accordingly.
I suggest we use the computation above in all case. Comments ?
> 1.6 Summary so far
>
> - a specified device/mask in an entry has priority
> over the 'defaults' IPROOTDEV/IPROOTMASK.
>
> - the mask/bcast is 'calculated' or 'retrieved'
> from the kernel if not specified via entry or
> IPROOTMASK/IPROOTBCAST
>
> - an entry has this format:
> [<device>:]<ipaddr>[/<netmask>]
> where <ipaddr> and <netmask> have to be in
> Dotted Quad Octet (aaa.bbb.ccc.ddd)
I modified ifspec so a netmask or network size (/XX) syntax is also supported.
This will go in vserver-0.28
> 3. Dirty Tricks (Examples)
>
> 3.1 The existing Interface
>
> eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
> inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> a) you want to allow one IP, for example 192.168.0.1
> for a vserver, but don't want the script to setup
> an alias ...
>
> IPROOT="192.168.0.1"
>
> - because IPROOTDEV isn't specified, and the
> entry doesn't contain an interface, <device> is
> empty and no alias is created.
Nothing dirty.
There is another issue. For each vserver, there is a script called /etc/vservers/vserver.sh
and sometime, people are setting the IP aliases from there. So they simply
set IPROOTDEV to nothing and sets the IPS in IPROOT, but let the .sh script
handle the network initialisation.
> 4.2 From chbind
>
> a) Segmentation fault
>
> - you managed to call 'chbind --ip' please share
> the knowledge how you did it?
I fixed chbind so it better checks its arguments. Will be in 0.28
> 5. And the Future?
>
> 5.1 Useful Enhancements
>
> - extend the script to actually understand
> /XX netmasks, and convert them for ifconfig
Done. Just in ifspec. No need to change the vserver script
> - add an option to display the actual ifconfig
> statements and IPOPT lists
> (would avoid a lot of questions)
Done. I added the --verbose option to the /usr/sbin/vserver script
> - fix the ifspec bug, and do some sanity checks
> regarding netmasks and interfaces ...
done
> - add a 'cleanup' option to 'remove' the aliases
> and mounts done by an 'enter' on a stopped
> vserver.
This is always done. a vserver xxx stop always does this even if the vserver
is not running.
> [1] it could be useful to specify this on a 'profile'
> basis, this way, a test profile could leave out
> the network stuff ...
Such a profile could have a different set of IP or no IP at all then. Why nodev ?
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver