Date: Mon, 28 Jun 2010 16:24:26 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Jamie Gritton <jamie@FreeBSD.org> Cc: freebsd-jail@FreeBSD.org Subject: Re: Thoughts on jail.config Message-ID: <20100628162426.21226ds0q116ljks@webmail.leidinger.net> In-Reply-To: <4C238832.2050803@FreeBSD.org> References: <4C22650C.40309@FreeBSD.org> <20100624144312.00003d9f@unknown> <4C238832.2050803@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Jamie Gritton <jamie@FreeBSD.org> (from Thu, 24 Jun 2010 10:30:42 -0600): > On 06/24/10 06:43, Alexander Leidinger wrote: > >> On Wed, 23 Jun 2010 13:48:28 -0600 Jamie Gritton<jamie@FreeBSD.org> >> wrote: >> >>> The rc system is becoming increasingly unable to handle the newer jail >>> features. We've held off patching /etc/rc.d/jail for new parameters, >>> with the promise of something better. Here's my outline of what I >>> hope will be in fact better than what we have now. >> >> I'm not sure from your explanation if your new setup allows ezjail to >> mangage jails as easy as it is now. If the new jail command will have >> an option to specify a config file, and the jail command only operates >> on the jails of this config file and ignores other jails which are >> already running (e.g. on a shutdown request), your new system looks >> like it is easy to use with ezjail. > > Yes, you'll be able to specify a config file via the command line, with > a default of /etc/jail.conf. Great. > Jails that exist outside of the config file's knowledge are a tricky > point, and the problems are really only on a shutdown request. While I > haven't coded this part of things yet, I've considered that I'll need > two different kinds of blanket shutdowns: one for all the jails in the > config file, and another for all jails in the system. The latter would > be the most sensible to use during system shutdown, when it doesn't make > sense to leave any jails running. But orderly shutdown is part of the > config spec (e.g. running "/bin/sh /etc/rc.shutdown"), and it may be > best to assume that if the jails were created outside of the rc system, > they'll be removed in the same way. There are two additional sides: 1) For jails which are created by example via ezjail I agree that it is within the responsability of the ezjail to shut them down. 2) For jails which are created/started by hand from a custom config file for testing purposes, I think a "shutdown all remeaining jails even if there is not entry in the config file" would be good. The problem with this is, that you need to make assumptions how to do a shutdown, or record this info in the kernel on creation time (and use this only if no config with appropriate info is available). > So in short, I think it will be compatible with ezjail. > >> Another point which interests me is how your new way of doing things >> will handle things like allow.raw_sockets. Assume I have some kernel >> modification which adds allow.XXX, do I need to modify the parsing of >> the jail command to handle this, or will this work transparently >> without userland modifications? > > That will work transparently, as does the current jail(8) command line. > The only time you'd need to modify userland tools for a new jail > parameter is if that parameter has a data type the tools don't > understand. Most parameters operate on numbers or strings, but for > example IP addresses are passed in binary and userland needs to know how > to convert them to/from strings. That's easy enough for my purposes. :) Bye, Alexander. -- Hitchcock's Staple Principle: The stapler runs out of staples only while you are trying to staple something. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100628162426.21226ds0q116ljks>