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

I've been waiting for 9.0 to get fully released before I started in with
the new conf-based jail(8). While this patch has a bunch of good stuff,
some of it goes at cross purposes with the new jail program. I haven't
worked at all on the rc script part of things, so I think I'd want to
use a lot of this, but I want to make it all fit together. So how about
sitting on it for a while longer until it can be part of a unified effort?

- Jamie


On 11/08/11 08:49, Martin Matuska wrote:
> 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
>>>
>>>