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