New jail(8) committed

Jason Hellenthal jhellenthal at
Sat Apr 28 23:30:37 UTC 2012

On Sat, Apr 28, 2012 at 04:59:51PM -0600, Jamie Gritton wrote:
> On 04/28/12 00:08, Jason Hellenthal wrote:
> > On Sat, Apr 28, 2012 at 06:14:07AM +0200, Dirk Engling wrote:
> >> On 26.04.12 22:07, Jamie Gritton wrote:
> >>
> >>> I've finally put my jail(8) changes into HEAD.  This new version of jail
> >>> can create jails from a configuration file - see jail.conf(5) for the
> >>> format, as well as some additions to jail(8).  This doesn't mean you
> >>> *have* to use jail.conf, but it's a better way to manage jails than the
> >>> existing rc.conf method.
> >>
> >> Out of curiosity, why did you settle for a /etc/jail.conf instead of a
> >> /etc/jail.d/? Your config file format introduces the dependency into an
> >> expensive parser while adding little value. Even worse, the user now has
> >> to struggle with just another format describing the system.
> >>
> >> I can foresee that my automated jail management tool ezjail will not be
> >> able to support the jail.conf format due to the lack of a parser. A look
> >> into ezjails config directory structure can give you a hint of how to
> >> achieve some similar clean up with built in tools.
> >
> > Since when does a lack of a parser in "YOUR tool" become a problem for
> > FreeBSD ? just sayin!
> To be fair, ezjail is a tool is pretty wide use, and I had no intention
> of breaking it - but also no knowledge of its internals. This thing has
> been sitting around in the projects directory for a long time now, with
> requests for review and comments. It's kind of disheartening to only
> hear this the day I committed it to HEAD.

I could see how that could be. On one hand though tools like ezjail
enable people to create jails for which they do not know why they are
creating those jails and while creating those jails is already
(ez)enough but for the most part requires a understanding of the jail
technology and all that comes with it.

Moving in the direction of your committs, I believe is the right
direction to come to a happy medium and giving them the control over the
jails that they can easily find and understand within the base system.

Personally I create jails from cpio(1) base-sets that are as minimal as
are needed with a very simple script that runs after extraction to
change whatever tunables and enable the jail to run. I refuse to use
ezjail due to how easy I find jails already and seeing the current
changes in jail(8) with a configuration it will only make it better.

I consider HEAD to be test technology in which gives projects like
ezjail time to ramp-up and test the future. Some of those changes might
just be dropping features because they have been included in the base
system or changed so drasticly it calls for re-engineering.

I think a drawback with the new jail(8) configuration has been the way
toooooo long extended dependency on configuration through environment
variables and certainly can be seen through the use of large scripted
out administrator tools.


 - (2^(N-1))

More information about the freebsd-jail mailing list