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 on the CC list for the bug.Received on Tue Apr 25 2017 - 21:23:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC