Date: Thu, 28 Jul 2011 12:47:34 -0600 From: Jamie Gritton <jamie@FreeBSD.org> To: FreeBSD Current <freebsd-current@FreeBSD.org> Cc: Martin Matuska <mm@FreeBSD.org> Subject: Re: [PATCH] updated /etc/rc.d/jail and added ZFS support Message-ID: <4E31AEC6.8080106@FreeBSD.org> In-Reply-To: <4E31A3CD.60500@FreeBSD.org> References: <4E316E19.9040309@FreeBSD.org> <4E318D75.608@FreeBSD.org> <4E31A3CD.60500@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E31AEC6.8080106>