Hi Bjoern,

On Wed, Sep 24, 2008 at 06:34:53PM +0000, Bjoern A. Zeeb wrote:
> On Wed, 24 Sep 2008, Ruslan Ermilov wrote:
> > ru          2008-09-24 15:18:27 UTC
> >
> >  FreeBSD src repository
> >
> >  Modified files:
> >    etc/rc.d             jail
> >    share/man/man5       rc.conf.5
> >  Log:
> >  SVN rev 183325 on 2008-09-24 15:18:27Z by ru
> >
> >  Allow a jail's IP alias to be created with an arbitrary netmask.
> So I had been talking with various people during the last weeks/months
> about this feature of configuring an interface from rc.d/jail and I
> had been >< close to remove it a lot of times but it seems people
> prefer to actually mix network configuration, management and jail
> startup/teardown in a single script, which I think is a very
> questionable thing especially considering that we already had an
> SA for[1] that script for other means.
> So you now I have v4/v6/multi/no-IP jails and once the next vimage
> step is in I plan to have it hit the tree and I am currently
> integrating a patch that would even have allow the ifconfig to work with
> multiple IPv4/v6 addresses because up to now I decided to leave this
> feature in.
> Now adding a netmask only makes sense for exactly one use case to my
> understanding and this is not going to play well with whatever will
> hit the tree.
At work, we use ezjail as a management tool for jails.  We want our
jails to be moveable between a set of hosts, so a jail's IP doesn't
necessarily belong to host X at any given time.  With the netmask in
rc.d/jail hardcoded to, we have to configure a host's
interface with IP addresses/netmasks corresponding to jails' IPs (and
we have different IP networks).  In practice this means we waste real
IPs for nothing -- for a host with a single jail we waste one real
IP address.  To picture it: on a host that's not otherwise configured
with 192.168.0 addresses, to up a jail with we have to
waste one more address from 192.168.0, e.g., for the host
to be able to route packets between and 192.168.0.*.

> Adding yet another variable to rc.conf to control another question
> knob is something, as I hate to say, I am no longer going to be ok
> with (this has nothhing to do with you or that it might be needed in a
> setup).
> My suggestion would be, that if we want thos features to add
> them separately doing a superset of the startup script or something
> just for this and actualy use network.subr or the like to set it up
> but keep the list of IP/Netmasks kind of separated from options for
> the jail(8) command.
> In worst case stomething like this (read the BUT later) and have a
> jail_example_ipv4_alias0=""
> jail_example_ipv4_alias1=""
> jail_example_ipv4_alias2=" netmask"
> jail_example_ipv6_alias0="2001:dbe::1"
> jail_example_ipv6_alias1="2001:dbe::2/128"
> and then have a single knob
> jail_example_configure_ips_on_interfaces="NO"
> and still use the above list create the jail(8) argument if you want
> it like that.
> BUT wait the above is not going to work out as I am missing the
> interface for each alias instance.
> We need a full interface X af X address X netmask tupple with each
> entry and a defined order per AF as the first IP will be specially
> treated.
> That's why I am saying networking is networking and jails are jails
> and to combine both you need a management app/script/... as it is
> too many options/knobs/...
> FYI for the multi-IP jails (without this feature) I didn't even have
> to think about the startup script as it would just have continued to
> work. Adding no-IP support I had to change an exit case to _foo="\"\""
> in rc.d/jail.
> With supporting the ifconfig you need to a a few more lines.
> With the netmasks I still have no idea where we'll end up.
> I suggest we once and for all discuss this on freebsd-jail, decide
> how to continue with this feature. I am Cc:ing and setting Reply-to:
> >  MFC after:      3 days
> I would kindly ask you to hold back an MFC into 7 until there is a
> conclusion.
I'd be happy with anything that allowed us NOT to waste IP addresses,
preferably in FreeBSD 7.1.  I have a solution that involves having
static routes (in the example above, I'd add a route to 192.168.0/24
over some Ethernet interface that's equivalent to saying to resolve
these IPs using ARP on this interface), but it's not ideal as I don't
want these addresses to be accessible/resolvable when a host doesn't
have configured IPs in this range.

Ruslan Ermilov
FreeBSD committer
freebsd-jail@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to