Thoughts on jail.config

[Rodrigo Mosconi]

2010/6/28 Alexander Leidinger <Alexander at leidinger.net>:
> Quoting Jamie Gritton <jamie at 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 at 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.
>

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