Date: Tue, 08 Nov 2011 09:13:10 -0700 From: Jamie Gritton <jamie@FreeBSD.org> To: Martin Matuska <mm@FreeBSD.org> Cc: FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features) Message-ID: <4EB95516.7030408@FreeBSD.org> In-Reply-To: <4EB94F6D.3020100@FreeBSD.org> References: <4E316E19.9040309@FreeBSD.org> <4E318D75.608@FreeBSD.org> <4E31A3CD.60500@FreeBSD.org> <4E31AEC6.8080106@FreeBSD.org> <4E331DC1.5000108@FreeBSD.org> <4E348673.6080406@FreeBSD.org> <4EB94F6D.3020100@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>> >>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EB95516.7030408>