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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
