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