Date: Mon, 01 Apr 2013 05:23:41 +0200 From: "army.of.root" <army.of.root@gmail.com> To: Paul Schenkeveld <freebsd@psconsult.nl> Cc: freebsd-jail@freebsd.org Subject: Re: rc.d/jail and jail.conf Message-ID: <5158FDBD.4020803@googlemail.com> In-Reply-To: <20130401020158.GA5500@psconsult.nl> References: <AA7CA531-5197-4BBC-B260-A3EC8B7A1024@inbox.im> <alpine.BSF.2.00.1303302157010.85469@erdgeist.org> <515847AF.8070808@FreeBSD.org> <5158526A.4020400@quip.cz> <51586419.5090207@FreeBSD.org> <51586DC8.7030500@quip.cz> <515880F3.1050300@FreeBSD.org> <5158874C.2060701@erdgeist.org> <515888BA.8060804@FreeBSD.org> <alpine.BSF.2.00.1303312112370.85469@erdgeist.org> <20130401020158.GA5500@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-04-1 04:01 , Paul Schenkeveld wrote: > On Sun, Mar 31, 2013 at 09:14:23PM +0200, Dirk Engling wrote: >> >> On Sun, 31 Mar 2013, Jamie Gritton wrote: >> >>> If you don't mind some slightly difficult error messages, you can always >>> "disable" a jail with exec.prestart="false". jail(8) requires all >>> commands to succeed, and in particular won't even create a jail when one >>> of the prestart commands fails. >> >> This violates POLA, but failing with >> >> exec.prestart="echo skipping jail; exit 1" >> >> might work. Even though this is not a good marker from a scripting >> perspective. > > Will this prevent all preparations from happening, i.e. will filesystems > be mounted for jails disabled this way? I've been fooling around with the new-jails. I perceive lifecycle management of jails as a common need. External-to-jail state is often associated with the state of the jail, e.g. firewall rules, mounts, app level stuff, error handling, fail over etc. * if I have N operations as prestart and their equivalent N inverse operations as poststop, and prestart operation X (X>1) fails, the state produced by 1..X is maintained. The inverse operations for 1..X are *not* executed. ___ | This is not a criticism, the design is just quite simple. But the | use-cases often look like this (I imagine) * The same happens if the jail dies by it's own hand, the poststop operations are not executed. To alter this, it would require some kind of supervisor or event generation (devd?) to trigger the lifecycle hooks. This could become a bit tedious cleaning up on long running many-jail hosts as the number of stacked linprocfs/devfs/nullfs mounts raises :) Especially if the prestart operations are not idempotent. I assume the pre/post-start/stop exec's are not a core concern of this interface overhaul. I do a lot of automation and integration stuff and programmability-friendliness is much appreciated. (I am a non-Developer in the FreeBSD context) I find the new jail interface quite awesome! Thanks for the great work! Best regards > > Although this may work, I think that this looks dirty. I'd really prefer > a "disabled" or "noauto" keyword instead. Maybe the various init systems have some hints about this. They've been dealing with dependencies and starting thinks a lot longer. > > -- Paul Schenkeveld
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5158FDBD.4020803>