[PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features)

I have improved the jail etc script significantly (in addition to ZFS
support and other improvements).

- you can now set a jail_name="" parameter to set the name for your jail
- the jails are still searched by "name", so you cannot manage the jail
with the script if "name" in /etc/rc.conf changes while running.
- the "status" subcommand now also shows the number of running
processes, this way you can identify an empty jail
- there are also two new subcommands - "create" and "remove", intended
for persistent jail operation
- if a jail is set to persistent, you can do the following sequence:
create start stop remove.
- non-persistent jails may also be created (won't be started) but will
be removed on a "stop"

http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch
http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch

On 31. 7. 2011 0:32, Jamie Gritton wrote:
> Yes, that looks good.  It keeps what I'd call expected behavior for
> persist (at least on the startup side).
>
> - Jamie
>
>
> On 07/29/11 14:53, Martin Matuska wrote:
>> So what do you think about this updated patch (attached)?
>> Here we leave everything possible for jail_example_params.
>> Btw. you can also set jid=xxx in params to have a "static" jail id for
>> this jail.
>>
>> Also stopping a persistent jail doesn't delete it (but you cannot start
>> it again).
>>
>> Dňa 28. 7. 2011 20:47, Jamie Gritton  wrote / napísal(a):
>>> Yes, it was intentional to move away from the global sysctls and to
>>> the per-jail parameters instead.  It makes more sense once config
>>> files come into play, which can do a better job of providing global
>>> defaults as well as per-jail parameters.
>>>
>>> The connection between ZFS and persist makes sense.  So for ZFS-based
>>> jail you'd want to set (and then reset) persist.  For others, this
>>> could be left to the user.  The changes to jail(8) for config files
>>> also sets persist when creating jails, and then clears it at a later
>>> stage unless the user specifies to keep it set.  It looks like I might
>>> want to add some ZFS support to the new jail(8).
>>>
>>> I would prefer to keep things simpler regarding create/start and
>>> remove/stop, and keep them tied together.
>>>
>>> - Jamie
>>>
>>>
>>> On 07/28/11 12:00, Martin Matuska wrote:
>>>> If you start jail(8) witth "-c" (the new "param" way,) the values
>>>> of the
>>>> actual security.jail. variables are not initialized inside the jail,
>>>> default values are used instead. I don't know if this is intentional,
>>>> but probably yes. Default enforce_statfs=2, allow.mount=0.
>>>> As of me we can leave everything for ${_params}, but then ${_zfs}
>>>> makes
>>>> sense only if enforce_statfs<2 and allow.mount=1.
>>>>
>>>> Regarding zfs, if you want to operate zfs from the very start of a
>>>> jail
>>>> (and e.g. make use of /etc/rc.d/zfs which has jail support), you
>>>> have to
>>>> pair datasets with an existing jail. In simple words, you have to
>>>> create
>>>> a process-less jail (persist=1), attach zfs datasets and then run the
>>>> command. The persist option can be made optional - but we always start
>>>> with persist=1, then we can set (or not) persist=0 depending on user
>>>> setting.
>>>>
>>>> The question that opens, should we remove a persisting jail on "stop"?
>>>> Or should we support new commands "create" and "remove" in addition to
>>>> "start" and "stop"? Create would just make a processless jail, remove
>>>> would wipe out a jail and start/stop would just deal with the
>>>> processes
>>>> (if persist=0 the old way, of course)?
>>>>
>>>> Cheers,
>>>> mm
>>>>
>>>> Dňa 28. 7. 2011 18:25, Jamie Gritton wrote / napísal(a):
>>>>> Since I missed the 9.0 boat with jail config file capability,
>>>>> something
>>>>> like this seems necessary; rc.d/jail has long been unable to
>>>>> handle the
>>>>> full scale of what jail(8) can do.
>>>>>
>>>>> I gather that setting persist is necessary for the ZFS operation. As
>>>>> long as we're making the parameter setting more generic from rc, we
>>>>> should handle the case where persist is specified in ${_params}, and
>>>>> not
>>>>> always set/reset it around the jail creation unless ZFS is used.
>>>>>
>>>>> Also, why the specific inclusion of the security-related parameters?
>>>>> They could just be folded into ${_params}, and if left unspecified
>>>>> then
>>>>> jail(8) should by default do the right thing.
>>>>>
>>>>> - Jamie
>>>>>
>>>>>
>>>>> On 07/28/11 08:11, Martin Matuska wrote:
>>>>>> The attached patch allows better fine-tuning of jails started via
>>>>>> /etc/rc.d, uses the new jail(8) flags (-c -m), the persist
>>>>>> parameter and
>>>>>> adds ZFS support.
>>>>>> Patch is fully backward compatible.
>>>>>>
>>>>>> Please review, comment and/or test my attached patch.
>>>>>>
>>>>>> Cheers,
>>>>>> mm
>>
>>
-- 
Martin Matuska
FreeBSD committer
http://blog.vx.sk