On 10/14/13 11:45 AM, Gavin Atkinson wrote: > On Sat, 12 Oct 2013, Hiroki Sato wrote: >> Remko Lodder <re...@freebsd.org> wrote >> in <04e9979e-1d97-4aa2-a7ae-f9d8457b3...@freebsd.org>: >> >> re> Hi Hiroki, >> re> >> re> On Oct 10, 2013, at 11:32 AM, Hiroki Sato <h...@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> r...@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 - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
signature.asc
Description: OpenPGP digital signature