Date: Sat, 28 Apr 2012 19:30:31 -0400 From: Jason Hellenthal <jhellenthal@dataix.net> To: Jamie Gritton <jamie@freebsd.org> Cc: FreeBSD-Jail <freebsd-jail@freebsd.org> Subject: Re: New jail(8) committed Message-ID: <20120428233031.GB34324@DataIX.net> In-Reply-To: <4F9C7667.8030907@FreeBSD.org> References: <4F99AB0E.4090805@FreeBSD.org> <4F9B6E8F.8070708@erdgeist.org> <20120428060830.GA47982@DataIX.net> <4F9C7667.8030907@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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))
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120428233031.GB34324>