[Bug 218849] Remove rc.conf jail configuration via jail_* variables

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849

--- Comment #16 from Joe Barbish <qjail1 at a1poweruser.com> ---
This is my objection to waiting for 12.0 before doing this. When 10.0 came out
the removal of the rc.conf method was scheduled to happen at 11.0. Now 3+ years
later 11.0 is out and the rc.conf method is still supported. Now your talking
about waiting for 12.0 to remove the the rc.conf method. In 3-4 years this same
problem will still not be fixed and again we will be talking about waiting for
13.0 to do it.

What you really talking about is holding up os deployment based on a 3rd-party
tool. That's just plain crazy.

I purpose this solution. 
I believe that the /etc/rc.d/jail script is the single place where the current
11.0 system issues that warning message and processes the rc.conf method from.
The removing of the rc.conf method will mean changing only that script. Someone
else should verify this.

Inspecting the current version of the ezjail-admin script shows the start/stop
commands launches a custom script /usr/local/etc/ezjail. After a bunch of
grinding it finally launches /etc/rc.d/jail which does the actual start/stop
work. This /etc/rc.d/jail script is part of the base os release.

Change the custom /usr/local/etc/ezjail script to launch
/usr/local/etc/ezjail-jail instead of /etc/rc.d/jail. This is a one line
change. Then populate the ezjail-jail script with the contents of the 11.0
/etc/rc.d/jail script. Make these changes to the port source and the
corresponding changes to the port makefiles and bingo you have given ezjail the
ability to internally use the rc.conf method for ever forward.

Now with this single show stopper fixed the removal of the rc.conf method can
proceed to be scheduled for 11.1.

-- 
You are receiving this mail because:
You are the assignee for the bug.