svn commit: r256256 - in head: . etc etc/defaults etc/rc.d share/man/man5 usr.sbin/jail

[Peter Wemm]

On 10/14/13 11:45 AM, Gavin Atkinson wrote:
> On Sat, 12 Oct 2013, Hiroki Sato wrote:
>> Remko Lodder <remko at FreeBSD.org> wrote
>>   in <04E9979E-1D97-4AA2-A7AE-F9D8457B3599 at FreeBSD.org>:
>>
>> re> Hi Hiroki,
>> re>
>> re> On Oct 10, 2013, at 11:32 AM, Hiroki Sato <hrs at FreeBSD.org> wrote:
>> re>
>> re> > Author: hrs
>> re> > Date: Thu Oct 10 09:32:27 2013
>> re> > New Revision: 256256
>> re> > URL: http://svnweb.freebsd.org/changeset/base/256256
>> re> >
>> re> > Log:
>> re> >  - Update rc.d/jail to use a jail(8) configuration file instead of
>> re> >    command line options.  The "jail_<jname>_*" rc.conf(5) variables for
>> re> >    per-jail configuration are automatically converted to
>> re> >    /var/run/jail.<jname>.conf before the jail(8) utility is invoked.
>> re> >    This is transparently backward compatible.
>> re> >
>> re> >  - Fix a minor bug in jail(8) which prevented it from returning false
>> re> >    when jail -r failed.
>> re> >
>> re>
>> re> Thanks for doing such a massive update. However it seems to break the
>> re> ezjail utility.
>> re> My jails didn't restart after I upgraded to the most recent -head
>> re> version
> 
> I'm also seeing issues with ezjail - in my case, the jails do start up 
> properly, but ezjail doesn't believe that they have.
> 
>> re> FreeBSD nakur.elvandar.org 10.0-ALPHA6 FreeBSD 10.0-ALPHA6 #7 r256311:
>> re> Fri Oct 11 13:27:54 CEST 2013
>> re> root at nakur.elvandar.org:/usr/obj/usr/src/sys/NAKUR amd64
>> re>
>> re> If I replace this with an older version, the utility starts and
>> re> complains about certain things not being done properly. The
>> re> system does not mount devfs nodes anylonger and thus is basically out
>> re> of function.
>> re>
>> re> I was not expecting this much fallout from this change, others that
>> re> will be upgrading will loose the ability to start their jails until
>> re> they can
>> re> resolve this by hand.
>>
>>  Can you send me your ezjail configuration and differences of the
>>  results (error messages, mount handling, etc) between old and new
>>  rc.d/jail?
> 
> The issue for me is that the /var/run/jail_${jailname}.id files are no 
> longer created, which ezzjail uses to keep track of jail state.
> 
> As a temporary workaround, for each jail I have on the host done
>    echo $jail_id > /var/run/jail_${jailname}.id
> and this allows me to manage that jail again from within ezjail.
> 
> Gavin
> 

It's actually far worse than I thought.  Given:

# grep jail /etc/rc.conf
jail_interface="bge0"
ezjail_enable="YES"

...
export jail_sab_ip="lo1|127.0.1.73,192.203.228.73,2001:470:67:39d::73"

we end up with:
# ifconfig bge0 | grep 73
	inet 127.0.1.73 netmask 0xffffffff broadcast 127.0.1.73
	inet 192.203.228.73 netmask 0xffffffff broadcast 192.203.228.73
	inet6 2001:470:67:39d::73 prefixlen 64

Note how they're all on bge0 and the lo1|127.x is ignored.

There's some other problems I haven't pinned down yet.  Something has
changed radically with source address selection and some standard setups
from 7.x through 10.x (as of a few months ago) don't work anymore.  I
haven't yet figured out how to do the per-jail lo1|127.x thing in the new
scheme even with an old rc.d/jail - anything attempting to bind to localhost
gets remapped to the public, fully exposed address.

I'm still looking.
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20131014/09e86ed1/attachment.sig>