Date: Mon, 28 Jun 2010 11:41:19 -0300 From: Rodrigo Mosconi <freebsd@mosconi.mat.br> To: freebsd-jail@freebsd.org Subject: Re: Thoughts on jail.config Message-ID: <AANLkTinHqqi0h_lHuy7K8UBAtHmXJ88vb38IC-65SvxQ@mail.gmail.com> In-Reply-To: <20100628162426.21226ds0q116ljks@webmail.leidinger.net> References: <4C22650C.40309@FreeBSD.org> <20100624144312.00003d9f@unknown> <4C238832.2050803@FreeBSD.org> <20100628162426.21226ds0q116ljks@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/6/28 Alexander Leidinger <Alexander@leidinger.net>: > 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. =A0We've held off patching /etc/rc.d/jail for new parameters= , >>>> with the promise of something better. =A0Here'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, th= at > 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 appropri= ate > 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. > An idea: if it works like a "jaild"? A daemon management the start-up, shutdown, console redirection? All the admins task could be done by a "jailctl"? Just a comments
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinHqqi0h_lHuy7K8UBAtHmXJ88vb38IC-65SvxQ>