From owner-freebsd-jail@FreeBSD.ORG Sun Mar 31 17:09:32 2013 Return-Path: Delivered-To: freebsd-jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D610FC; Sun, 31 Mar 2013 17:09:32 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4BC6AE; Sun, 31 Mar 2013 17:09:32 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6523F28431; Sun, 31 Mar 2013 19:09:30 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3A8B52842D; Sun, 31 Mar 2013 19:09:29 +0200 (CEST) Message-ID: <51586DC8.7030500@quip.cz> Date: Sun, 31 Mar 2013 19:09:28 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Jamie Gritton Subject: Re: rc.d/jail and jail.conf References: <515721F8.9090202@erdgeist.org> <515847AF.8070808@FreeBSD.org> <5158526A.4020400@quip.cz> <51586419.5090207@FreeBSD.org> In-Reply-To: <51586419.5090207@FreeBSD.org> 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: Sun, 31 Mar 2013 17:09:32 -0000 Jamie Gritton wrote: > On 03/31/13 09:12, Miroslav Lachman wrote: >> Jamie Gritton wrote: >>> On 03/30/13 14:59, Dirk Engling wrote: >>>> On Sat, 30 Mar 2013, Nicolas de Bari Embriz Garcia Rojas wrote: >>>> >>>>> If I am right you can define the order of start for jails in the >>>>> jail2_list (rc.conf), something like: >>>>> >>>>> jail2_list="jail1 jail2" >>>> >>>> Thanks, I suppose it mimicks the way rc.d/jail has handled it. I just >>>> wondered if there's a way to have this order automatically >>>> determined by >>>> a dependency graph, it's a minor request, though. >>> >>> jail(8) itself does the dependency graph. So the jail2 startup needs to >>> run a single jail command instead of one for each jail. >> >> So it means jail2 should be fixed, because it runs >> jail -c -i -J /var/run/jail_${_j}.id ${_j} >> for each jail from jail2_list="jailA jailB" > > Yes it does. > >> Is there a way to disable jail defined in jail.conf? (to avoid >> jail2_list in rc.conf) > > I'm not sure what you're asking. You want a jail in jail.conf that's not > started up? Yes, I am asking if there can be some variable or parametr in jail.conf for jail which we don't want to start by jail command, but leave its configuration in jail.conf. I am not saying I need it right now, but I can imagine a scenario where it can be useful. In the old style with rc.conf, we can have defined for example 5 jails (jailA to jailE) and then enabled only some of them to start at boot time by defining jail_list="jailA jailB jailC". With syntax of new jail.conf one must delete or comment out the whole jailD and jailE definitions to stop loading them at boot time. Am I right? So is it possible to add some keyword to jail.conf jails definition? Something like "disabled" or "noautostart" or anything else... foo { disabled; host.hostname = "foo.com"; ip4.addr = 10.1.1.1, 10.1.1.2, 10.1.1.3; } Then one can easily disable jail "foo" without a need to remove its configuration. >> And what happens if there is jail2_list="jailA jailB" in rc.conf and >> jailB is defined in jail.conf as dependency of jailA? I guess rc.d/jail2 >> will try to start jailB again. >> It will be started as dependency of jailA by first jail command starting >> jailA. >> Or new jail(8) doesn't start the "depend" jail automatically and just >> check its existence? >> I didn't try it yet. > > It will start jailB as part of starting jailA, and then it will try to > start jailB again on its own. So yes, it needs work. Thank you for explanation. Miroslav Lachman