rc.d/jail and jail.conf

[army.of.root]

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