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

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
>
>