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, >>> mmReceived on Thu Jul 28 2011 - 16:47:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC