From owner-freebsd-jail@FreeBSD.ORG Mon Apr 1 03:23:46 2013 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A4AB3DB for ; Mon, 1 Apr 2013 03:23:46 +0000 (UTC) (envelope-from army.of.root@gmail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id D03031F9 for ; Mon, 1 Apr 2013 03:23:45 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id jc3so776456bkc.1 for ; Sun, 31 Mar 2013 20:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7ti74Ns1ONFWfiXXpMJSas4FMok5MaotrHJ0Ci+5lmw=; b=CxHoMW3VUgWRW/k/JXv4kDd1q08FaCQQcJZ+QFS7baBsMu3GpZNTu+l6+SiioEEv8w ZtmtoTM3S+a7VLCrnTnqQIu0RdJ+KuS9Sc9qxlt/ZTbcw+B8zhqpNrpU7ZGfhernfZP0 7yqxf1o8mjFTPMA1PK0A4hPLtYqk1PM1oYitPjqGgs6v7+staOk/w2u/8rg52UGNyhBA V+XcGRkEVOXtFlH4k8Fpge1nD4iX3zJeUTEjOwGv3SrMZGO+2+WUJIzb2qU2srf409Cb qGJY6X8z6cKaIOkbWtLGeZFiLV9Ldn6QZLkYKufnq9Xk6XzQwq4CLhikwNiStCUa8a1h ZJfg== X-Received: by 10.205.122.80 with SMTP id gf16mr4313964bkc.130.1364786624908; Sun, 31 Mar 2013 20:23:44 -0700 (PDT) Received: from titanium-2.local (p4FFFEA41.dip.t-dialin.net. [79.255.234.65]) by mx.google.com with ESMTPS id fs20sm2556174bkc.8.2013.03.31.20.23.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Mar 2013 20:23:43 -0700 (PDT) Message-ID: <5158FDBD.4020803@googlemail.com> Date: Mon, 01 Apr 2013 05:23:41 +0200 From: "army.of.root" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Paul Schenkeveld Subject: Re: rc.d/jail and jail.conf References: <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> <20130401020158.GA5500@psconsult.nl> In-Reply-To: <20130401020158.GA5500@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jail@freebsd.org X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 03:23:46 -0000 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