On 10/14/13 11:45 AM, Gavin Atkinson wrote: > On Sat, 12 Oct 2013, Hiroki Sato wrote: >> Remko Lodder <[email protected]> wrote >> in <[email protected]>: >> >> re> Hi Hiroki, >> re> >> re> On Oct 10, 2013, at 11:32 AM, Hiroki Sato <[email protected]> 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> [email protected]:/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 - [email protected]; [email protected]; [email protected]; KI6FJV
signature.asc
Description: OpenPGP digital signature
