cvs commit: src/etc/rc.d jail src/share/man/man5 rc.conf.5
ru at freebsd.org
Thu Sep 25 06:00:22 UTC 2008
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 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 255.255.255.255, 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 192.168.0.13 we have to
waste one more address from 192.168.0, e.g. 192.168.0.1, for the host
to be able to route packets between 192.168.0.13 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
> 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_alias2="192.0.2.2 netmask 255.255.255.255"
> and then have a single knob
> 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
> 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
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.
ru at FreeBSD.org
More information about the cvs-all