Re: [PATCH] updated /etc/rc.d/jail and added ZFS support

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