Date: Tue, 08 Nov 2011 16:49:01 +0100 From: Martin Matuska <mm@FreeBSD.org> To: Jamie Gritton <jamie@FreeBSD.org> Cc: FreeBSD Current <freebsd-current@FreeBSD.org> Subject: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features) Message-ID: <4EB94F6D.3020100@FreeBSD.org> In-Reply-To: <4E348673.6080406@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> >> -- Martin Matuska FreeBSD committer http://blog.vx.sk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EB94F6D.3020100>