From owner-freebsd-rc@FreeBSD.ORG Mon May 15 11:02:59 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B854816A403 for ; Mon, 15 May 2006 11:02:59 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7D443D49 for ; Mon, 15 May 2006 11:02:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k4FB2x6q075330 for ; Mon, 15 May 2006 11:02:59 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k4FB2wpk075324 for freebsd-rc@freebsd.org; Mon, 15 May 2006 11:02:58 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 May 2006 11:02:58 GMT Message-Id: <200605151102.k4FB2wpk075324@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2006 11:02:59 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- p [2006/03/12] conf/94377 rc [patch] /etc/rc.d/sshd improperly tests r 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/11/12] conf/45226 rc Fix for rc.network, ppp-user annoyance p [2004/11/13] conf/73909 rc [patch] rc.d/sshd does not work with port o [2005/02/18] conf/77663 rc Suggestion: add /etc/rc.d/addnetswap afte o [2005/03/16] conf/78906 rc [patch] Allow mixer_enable="NO" in rc.con o [2005/05/14] kern/81006 rc ipnat not working with tunnel interfaces p [2005/06/28] conf/82738 rc [patch] add amd_program line to defaults/ o [2005/08/27] conf/85363 rc syntax error in /etc/rc.d/devfs o [2005/11/13] conf/88913 rc [patch] wrapper support for rc.subr o [2005/12/03] conf/89870 rc [patch] feature request to make netif ver o [2006/01/30] conf/92523 rc [patch] allow rc scripts to kill process o [2006/02/25] conf/93815 rc [patch] Adds in the ability to save ipfw o [2006/03/21] bin/94767 rc [patch] rcorder(8) dumps core when does n o [2006/05/04] conf/96766 rc run_rc_command doesn't work for Python sc 13 problems total. From owner-freebsd-rc@FreeBSD.ORG Tue May 16 17:35:54 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A51B116A5A2 for ; Tue, 16 May 2006 17:35:54 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mail.digitalfreaks.org (arbitor.digitalfreaks.org [216.151.95.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 309E643D6A for ; Tue, 16 May 2006 17:35:50 +0000 (GMT) (envelope-from lavalamp@spiritual-machines.org) Received: by mail.digitalfreaks.org (Postfix, from userid 1022) id 981AC170E1; Tue, 16 May 2006 13:35:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.digitalfreaks.org (Postfix) with ESMTP id 95BC4170CD; Tue, 16 May 2006 13:35:51 -0400 (EDT) Date: Tue, 16 May 2006 13:35:51 -0400 (EDT) From: "Brian A. Seklecki" X-X-Sender: lavalamp@arbitor.digitalfreaks.org To: ocf@lists.community.tummy.com, freebsd-rc@freebsd.org, tech-userlevel@netbsd.org Message-ID: <20060513015129.C95601@arbitor.digitalfreaks.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: General Linux-HA mailing list Subject: Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2006 17:35:56 -0000 What is OCF? The extensions required to make any RC script register a system service as a Cluster Resource in the Linux-HA infrastructure. For those of you unfamiliar with OCF, please refer to the draft standard at: http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD http://linux-ha.org/HeartbeatResourceAgent http://linux-ha.org/LSBResourceAgent http://linux-ha.org/OCFResourceAgent http://linux-ha.org/ResourceAgentSpecs Fortunately, our rc.d system infrastructure is sufficiently extensible in nature to easily mitigate the need for duplicate OCF script coding efforts by Port maintainers. Existing in-tree and Ports-provided rc.d/ compliant scripts can be extended with very little effort. However some discussion would be prudent as to how to best accomplish the task most conducive == *) Exit codes We deviate slightly from LSB, as so does LSB from OCF. Example: When we execute a "stop" command to run_rc_command() on an already stopped service, we return code "1", while OCF/LSB calls for code 3. We could put a conditional check around the return/exit statement, however OCF "compatibility mode" would need to be a variable we source in from the service's RC script. like 'checkyesno $ofc_compat' at line 691 in rc.subr There are other adjustments to exit codes that would so need to be made (see the standards doc) *) Environmental variables for per-instance services Currently we don't have a uniform method for dealing with multiple instances of services. The Apache2 method is nice ("Profiles"); -- "apache2.sh [instance] [argument]" syntax. OCF scripts expect to be differentiate using exported environmental variables from the calling application: OCF_RESKEY_*, which is not an issue. *) Additional arguments The spec calls for additional arguments "monitor" (to augment the existing "status") as well as "metadata" (to describe the service using an XML DTD) and an optional "validate-all". These can be very easily implemented using a $extra_commands="". extra_commands="monitor metadata" monitor_cmd="slapd_monitor" metadata_cmd="slapd_metadata" Note: commands with hyphens (or function names) in them do not seem to be honored. 'monitor' should hypothetically be an intelligent service check, more than just checking if a TCP socket is open but also if the service is healthy -- which implies calling/exec'ing an outside program, like a Nagios health check. Something that generates dynamic input and checks it against generated output. Note: None of the included OCF examples do truely objective testing yet! (Sorry guys, systems that don't permitted fragmented packets to the network broadcast address aren't going to run Apache's mod_status by default }:> ). We can leave the $servicename_monitor() symantics up to the port maintainer, plus the end user can always do more aggressive checking. However, our current "status" routine checks for the existence of a PID file and cross-references it against the process list (which is a more extensive than most other RC systems). Given that, as a temporary fix, "monitor" can be easily mapped to "status" using a small code snippit: slapd_monitor () { run_rc_command status case $? in 1) exit 7 ;; *) exit 0 ;; esac } -- As for the "metadata" and "validate-all" routines, the XML DTD simply helps describe the command line and environmental variable arguments valid for the OCF service script, so we might be able to develop a reusable set of routines for generating the output without any crazy dependencies on libXML. The trickier question arises when we want to start making in-tree rc.d/ scripts OFC compliant/compatible (nfsd, named, inetd, sendmail, ntpd, etc. come to mind) I'm interested in any discussion / thoughts on a strategy or apporach for coding OCF compatibility / integration into our rc.d/ system Thanks, ~BAS From owner-freebsd-rc@FreeBSD.ORG Thu May 18 05:14:38 2006 Return-Path: X-Original-To: freebsd-rc@hub.freebsd.org Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70DEA16A404; Thu, 18 May 2006 05:14:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C85043D48; Thu, 18 May 2006 05:14:38 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (dougb@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k4I5Eb1O054010; Thu, 18 May 2006 05:14:37 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k4I5EbXX054006; Thu, 18 May 2006 05:14:37 GMT (envelope-from dougb) Date: Thu, 18 May 2006 05:14:37 GMT From: Doug Barton Message-Id: <200605180514.k4I5EbXX054006@freefall.freebsd.org> To: dcrudy@pacbell.net, dougb@FreeBSD.org, dougb@FreeBSD.org, freebsd-rc@FreeBSD.org Cc: Subject: Re: conf/55916: [PATCH] ppp-user options X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 05:14:38 -0000 Old Synopsis: Change to /etc/rc.network & /etc/defaults/rc.conf New Synopsis: [PATCH] ppp-user options State-Changed-From-To: feedback->open State-Changed-By: dougb State-Changed-When: Thu May 18 05:12:01 UTC 2006 State-Changed-Why: Thank you for your feedback. I'm not able to address this change request in a timely manner, but hopefully someone on the list (who knows more about ppp than I do) will take an interest. Responsible-Changed-From-To: dougb->freebsd-rc Responsible-Changed-By: dougb Responsible-Changed-When: Thu May 18 05:12:01 UTC 2006 Responsible-Changed-Why: ENOTIME http://www.freebsd.org/cgi/query-pr.cgi?pr=55916 From owner-freebsd-rc@FreeBSD.ORG Thu May 18 15:38:02 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE7A16A449 for ; Thu, 18 May 2006 15:38:02 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mail.digitalfreaks.org (arbitor.digitalfreaks.org [216.151.95.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E39343D70 for ; Thu, 18 May 2006 15:38:00 +0000 (GMT) (envelope-from lavalamp@spiritual-machines.org) Received: by mail.digitalfreaks.org (Postfix, from userid 1022) id 46BB71702D; Thu, 18 May 2006 11:38:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.digitalfreaks.org (Postfix) with ESMTP id 4594F1702C; Thu, 18 May 2006 11:38:01 -0400 (EDT) Date: Thu, 18 May 2006 11:38:01 -0400 (EDT) From: "Brian A. Seklecki" X-X-Sender: lavalamp@arbitor.digitalfreaks.org To: freebsd-rc@freebsd.org Message-ID: <20060518113707.C82296@arbitor.digitalfreaks.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: General Linux-HA mailing list Subject: Re: Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 15:38:07 -0000 On Tue, 16 May 2006, joerg@britannica.bec.de wrote: > On Tue, May 16, 2006 at 01:35:51PM -0400, Brian A. Seklecki wrote: > [SNIP] >> >> I'm interested in any discussion / thoughts on a strategy or apporach for >> coding OCF compatibility / integration into our rc.d/ system > > Oh my god, another over-complicated Linux "standard" which uses the A lot of this goes without saying. However, Linux-HA is the only available, portable Failover Management Software (FMS) available for POSIX compliant systems. It's under active development and the 2.x branch has some game. I'm not talking about changing any default behavior, I'm asking what the best strategy would be to put hooks in place to easily enable "compatibility" mode. Adding new commands is easy with $extra_commands, but changing return codes requires some if[]'s in-tree. An extra couple of cycles blown isn't that bad of a tradeoff to bring high availability (HA) / failover features to *BSD. ~BAS > kitchen sink approach for system management. I'm strongly opposing > changing the current system to comply with this. From owner-freebsd-rc@FreeBSD.ORG Thu May 18 16:52:40 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0E9216A6CB for ; Thu, 18 May 2006 16:52:40 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55C6343D77 for ; Thu, 18 May 2006 16:52:33 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from localhost (monrovll-cuda1-24-53-251-44.pittpa.adelphia.net [24.53.251.44]) (AUTH: LOGIN wmoran, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Thu, 18 May 2006 12:52:32 -0400 id 00056410.446CA650.00017BD4 Date: Thu, 18 May 2006 12:52:31 -0400 From: Bill Moran To: "Brian A. Seklecki" Message-Id: <20060518125231.5a1f0fa8.wmoran@collaborativefusion.com> In-Reply-To: <20060518113707.C82296@arbitor.digitalfreaks.org> References: <20060518113707.C82296@arbitor.digitalfreaks.org> Organization: Collaborative Fusion X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-ha@lists.linux-ha.org, freebsd-rc@freebsd.org Subject: Re: Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2006 16:52:46 -0000 "Brian A. Seklecki" wrote: > > On Tue, 16 May 2006, joerg@britannica.bec.de wrote: > > > On Tue, May 16, 2006 at 01:35:51PM -0400, Brian A. Seklecki wrote: > > [SNIP] > >> > >> I'm interested in any discussion / thoughts on a strategy or apporach for > >> coding OCF compatibility / integration into our rc.d/ system > > > > Oh my god, another over-complicated Linux "standard" which uses the > > A lot of this goes without saying. However, Linux-HA is the only available, > portable Failover Management Software (FMS) available for POSIX compliant > systems. It's under active development and the 2.x branch has some game. > > I'm not talking about changing any default behavior, I'm asking what the best > strategy would be to put hooks in place to easily enable "compatibility" mode. > > Adding new commands is easy with $extra_commands, but changing return codes > requires some if[]'s in-tree. An extra couple of cycles blown isn't that bad > of a tradeoff to bring high availability (HA) / failover features to *BSD. There was a post to questions@freebsd.org regarding recommendations for HA setup of FreeBSD. The post got no responses. While overcomplicating the rc system is A Bad Thing(tm) in my opinion, I think there is some severe lacking in this area. i.e. _something_ needs to be implemented. Linux HA/OCF seems to share a lot with the existing rcng system, and seems to be the most logical system to try to use. I work with Brian. Knowing our requirements, we're going to set this stuff up, because we need it. Both Brian and I would like to contribute our improvements back to the community. If we could get a consensus on what approach to the problem is most likely to be accepted by the community, then we _will_ be doing work over the next few months that will benefit FreeBSD, and we _will_ be contributing it back to FreeBSD. So, the upshot of this discussion is that Collaborative Fusion is going to be throwing developer resources at FreeBSD HA. We'd like feedback from the FreeBSD community on how we can best do this so that it can be integrated back into the FreeBSD source tree. We've already done _some_ research and we're looking for input. -- Bill Moran Also, I can kill you with my brain. River Tam From owner-freebsd-rc@FreeBSD.ORG Fri May 19 03:28:53 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA2F016A41F for ; Fri, 19 May 2006 03:28:53 +0000 (UTC) (envelope-from alanr@unix.sh) Received: from robertsons.dyndns.org (robertsons.dyndns.org [71.39.23.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85C9443D48 for ; Fri, 19 May 2006 03:28:53 +0000 (GMT) (envelope-from alanr@unix.sh) Received: from linux.site (servidor [10.10.10.5]) by robertsons.dyndns.org (Postfix) with ESMTP id BD11D557A3; Thu, 18 May 2006 21:28:51 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by linux.site (Postfix) with ESMTP id 701DD1F1D9; Thu, 18 May 2006 21:28:51 -0600 (MDT) Message-ID: <446D3B73.3040202@unix.sh> Date: Thu, 18 May 2006 21:28:51 -0600 From: Alan Robertson Organization: IBM Linux Technology Center User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: General Linux-HA mailing list References: <20060513015129.C95601@arbitor.digitalfreaks.org> In-Reply-To: <20060513015129.C95601@arbitor.digitalfreaks.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, tech-userlevel@netbsd.org, ocf@lists.community.tummy.com Subject: Re: [Linux-HA] Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 03:28:54 -0000 Brian A. Seklecki wrote: > > What is OCF? The extensions required to make any RC script register a > system service as a Cluster Resource in the Linux-HA infrastructure. > > For those of you unfamiliar with OCF, please refer to the draft standard > at: > http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD > > http://linux-ha.org/HeartbeatResourceAgent > http://linux-ha.org/LSBResourceAgent > http://linux-ha.org/OCFResourceAgent > http://linux-ha.org/ResourceAgentSpecs > > Fortunately, our rc.d system infrastructure is sufficiently extensible > in nature to easily mitigate the need for duplicate OCF script coding > efforts by Port maintainers. Existing in-tree and Ports-provided rc.d/ > compliant scripts can be extended with very little effort. OK. You don't have to write OCF scripts if you don't want to. BUT, for R2, you really do want something equivalent to "status" operations. Is that available in *BSD rc.d scripts? -- Alan Robertson "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce From owner-freebsd-rc@FreeBSD.ORG Fri May 19 04:39:49 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 168C116A41F for ; Fri, 19 May 2006 04:39:49 +0000 (UTC) (envelope-from alanr@unix.sh) Received: from robertsons.dyndns.org (robertsons.dyndns.org [71.39.23.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73D3A43D45 for ; Fri, 19 May 2006 04:39:48 +0000 (GMT) (envelope-from alanr@unix.sh) Received: from linux.site (servidor [10.10.10.5]) by robertsons.dyndns.org (Postfix) with ESMTP id 6697B557A3; Thu, 18 May 2006 22:39:47 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by linux.site (Postfix) with ESMTP id 4A84F1F1D9; Thu, 18 May 2006 22:39:47 -0600 (MDT) Message-ID: <446D4C13.6010706@unix.sh> Date: Thu, 18 May 2006 22:39:47 -0600 From: Alan Robertson Organization: IBM Linux Technology Center User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: General Linux-HA mailing list References: <20060518113707.C82296@arbitor.digitalfreaks.org> In-Reply-To: <20060518113707.C82296@arbitor.digitalfreaks.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: [Linux-HA] Re: Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 04:39:49 -0000 Brian A. Seklecki wrote: > > On Tue, 16 May 2006, joerg@britannica.bec.de wrote: > >> On Tue, May 16, 2006 at 01:35:51PM -0400, Brian A. Seklecki wrote: >> [SNIP] >>> >>> I'm interested in any discussion / thoughts on a strategy or apporach >>> for >>> coding OCF compatibility / integration into our rc.d/ system >> >> Oh my god, another over-complicated Linux "standard" which uses the > > A lot of this goes without saying. However, Linux-HA is the only > available, portable Failover Management Software (FMS) available for > POSIX compliant systems. It's under active development and the 2.x > branch has some game. > > I'm not talking about changing any default behavior, I'm asking what the > best strategy would be to put hooks in place to easily enable > "compatibility" mode. > > Adding new commands is easy with $extra_commands, but changing return > codes requires some if[]'s in-tree. An extra couple of cycles blown > isn't that bad of a tradeoff to bring high availability (HA) / failover > features to *BSD. > > ~BAS > >> kitchen sink approach for system management. I'm strongly opposing >> changing the current system to comply with this. I can certainly understand this, but it's actually VERY similar to existing Linux init scripts. I understand that's not very interesting to you guys, but part of the design goal was to be able to write an /etc/init.d script which could ALSO be an OCF script. I understand about the exit code issues (believe me I do). But, you gotta start somewhere. We were not specifically designing OCF to replace init scripts, but to fill a very specific and necessary role in HA systems based on a good bit of experience, and input from multiple clueful people. It was based on some success we'd had in R1, and experience-based realizations of how to do things better. We could have made it completely different from init scripts, but we saw advantage to having it be straightforward to change an init script to be an OCF script. [LOTS of people know about init scripts - they've been around since shortly after the Beginning Of Time ;-)]. Here are the differences we HAD to provide over normal init scripts: 1) Support for multiple instances 2) Uniformity of everything (no special cases for filesystems and IP addresses) (this requires item (1) above) 3) Need to do monitoring - explicitly more powerful than "status" And, we wanted it to be completely upwards compatible from existing init scripts. We didn't want it to require that they be written in the shell (although that's likely most peoples' choice in practice). So, that meant no command line parameters. So, everything interesting gets passed in the environment. Now, once you have different instances and configuration parameters, you get into the need to configure it with some kind of configuration tool as a possibility. And, we needed to know things like timeout values, parameter descriptions in multiple languages and so on. The observant will notice that it's very very clumsy to put this into a flat namespace, but very natural (and extensible) to express in a hierarchy. To allow multiple languages, and support more metadata, we went from the "parse the comments in the shell script and get out a few name/value pairs" technique used by the LSB to something which could provide us a LOT more information - and in multiple languages, and could continue to grow without kludges. So, we went with XML. This isn't a wonderful choice, but there are no good choices for this, so it was by far the lesser of many evils. HOWEVER, no one needs an XML library in your init scripts. The strings in the metadata are constants. And, the nice thing is now anyone who writes an OCF resource agent automatically gets discovered by us and our GUI can prompt them for how to configure the instance. This is REALLY COOL (IMHO). PS: if you check the current CVS, our GUI is significantly improved over the 2.0-5 GUI. You just can't stop that Huang Zhen! Of course, you don't _have_ to use a GUI, but if you _want_ to, then having this support for it is essential. Since we were designing for HA systems and most of them have GUIs, it's not optional for the purpose of the standard. Of course, the metadata is also useful for a curses tool, or even a configuration validator. We have also extended the OCF spec ourselves in R2 for more powerful capabilities, and that was really easy and natural given how it was all put together. Some of those extensions will definitely get rolled back into the spec. Since it's a standard, we wanted to have various people provide scripts and NEVER have them overwritten by the next generation of system scripts, or have other name clashes between different vendors. So, we added in the "provider" level in the directory hierarchy. This was simple to do, and really goes a long way to making this long-standing and annoying problem go completely away. [The only piece missing would be an IANA type provider registration process - which is only necessary if we are an incredibly wild success ;-)]. To my knowledge, the only thing(s) we could have eliminated from what we did was: - not support multiple levels of monitoring - POSSIBLY eliminate the provider level in the directory hierarchy. The multiple levels of monitoring was a natural and simple thing for us to do on top of what else we were already doing. The provider idea was just trying to provide a simple solution to a long-standing problem. All things considered, I'm pretty pleased with how it came out. -- Alan Robertson "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce From owner-freebsd-rc@FreeBSD.ORG Fri May 19 04:44:10 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 607D716A426 for ; Fri, 19 May 2006 04:44:10 +0000 (UTC) (envelope-from alanr@unix.sh) Received: from robertsons.dyndns.org (robertsons.dyndns.org [71.39.23.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C678D43D46 for ; Fri, 19 May 2006 04:44:09 +0000 (GMT) (envelope-from alanr@unix.sh) Received: from linux.site (servidor [10.10.10.5]) by robertsons.dyndns.org (Postfix) with ESMTP id 40381557BA; Thu, 18 May 2006 22:44:09 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by linux.site (Postfix) with ESMTP id 043431F1D9; Thu, 18 May 2006 22:44:08 -0600 (MDT) Message-ID: <446D4D18.9000406@unix.sh> Date: Thu, 18 May 2006 22:44:08 -0600 From: Alan Robertson Organization: IBM Linux Technology Center User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: General Linux-HA mailing list References: <20060518113707.C82296@arbitor.digitalfreaks.org> In-Reply-To: <20060518113707.C82296@arbitor.digitalfreaks.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: [Linux-HA] Re: Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 04:44:10 -0000 Brian A. Seklecki wrote: > > On Tue, 16 May 2006, joerg@britannica.bec.de wrote: > >> On Tue, May 16, 2006 at 01:35:51PM -0400, Brian A. Seklecki wrote: >> [SNIP] >>> >>> I'm interested in any discussion / thoughts on a strategy or apporach >>> for >>> coding OCF compatibility / integration into our rc.d/ system >> >> Oh my god, another over-complicated Linux "standard" which uses the > > A lot of this goes without saying. However, Linux-HA is the only > available, portable Failover Management Software (FMS) available for > POSIX compliant systems. It's under active development and the 2.x > branch has some game. > > I'm not talking about changing any default behavior, I'm asking what the > best strategy would be to put hooks in place to easily enable > "compatibility" mode. > > Adding new commands is easy with $extra_commands, but changing return > codes requires some if[]'s in-tree. An extra couple of cycles blown > isn't that bad of a tradeoff to bring high availability (HA) / failover > features to *BSD. You could also provide a different plugin in lieu of lsb for the BSD systems. It wouldn't be that hard. Or we could even leave it the same, but change the return code mappings when compiled with some option or another... This is all done through plugins. -- Alan Robertson "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce From owner-freebsd-rc@FreeBSD.ORG Fri May 19 04:55:11 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D588216A41F for ; Fri, 19 May 2006 04:55:11 +0000 (UTC) (envelope-from alanr@unix.sh) Received: from robertsons.dyndns.org (robertsons.dyndns.org [71.39.23.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1588743D46 for ; Fri, 19 May 2006 04:55:10 +0000 (GMT) (envelope-from alanr@unix.sh) Received: from linux.site (servidor [10.10.10.5]) by robertsons.dyndns.org (Postfix) with ESMTP id 4DAE4557BF; Thu, 18 May 2006 22:55:10 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by linux.site (Postfix) with ESMTP id 346961F1D9; Thu, 18 May 2006 22:55:10 -0600 (MDT) Message-ID: <446D4FAE.3030301@unix.sh> Date: Thu, 18 May 2006 22:55:10 -0600 From: Alan Robertson Organization: IBM Linux Technology Center User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: General Linux-HA mailing list References: <20060518113707.C82296@arbitor.digitalfreaks.org> <20060518125231.5a1f0fa8.wmoran@collaborativefusion.com> In-Reply-To: <20060518125231.5a1f0fa8.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: [Linux-HA] Re: Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 04:55:12 -0000 Bill Moran wrote: > "Brian A. Seklecki" wrote: >> On Tue, 16 May 2006, joerg@britannica.bec.de wrote: >> >>> On Tue, May 16, 2006 at 01:35:51PM -0400, Brian A. Seklecki wrote: >>> [SNIP] >>>> I'm interested in any discussion / thoughts on a strategy or apporach for >>>> coding OCF compatibility / integration into our rc.d/ system >>> Oh my god, another over-complicated Linux "standard" which uses the >> A lot of this goes without saying. However, Linux-HA is the only available, >> portable Failover Management Software (FMS) available for POSIX compliant >> systems. It's under active development and the 2.x branch has some game. >> >> I'm not talking about changing any default behavior, I'm asking what the best >> strategy would be to put hooks in place to easily enable "compatibility" mode. >> >> Adding new commands is easy with $extra_commands, but changing return codes >> requires some if[]'s in-tree. An extra couple of cycles blown isn't that bad >> of a tradeoff to bring high availability (HA) / failover features to *BSD. > > There was a post to questions@freebsd.org regarding recommendations for > HA setup of FreeBSD. The post got no responses. > > While overcomplicating the rc system is A Bad Thing(tm) in my opinion, I think > there is some severe lacking in this area. i.e. _something_ needs to be > implemented. Linux HA/OCF seems to share a lot with the existing rcng > system, and seems to be the most logical system to try to use. We really did try to avoid overcomplicating it. In an earlier email I explained what our requirements were, and how we came to the decisions that we did. It is more complicated than the bare minimum required by an init system, but not that much more so - and it's upwards compatible. > I work with Brian. Knowing our requirements, we're going to set this stuff > up, because we need it. Both Brian and I would like to contribute our > improvements back to the community. If we could get a consensus on what > approach to the problem is most likely to be accepted by the community, > then we _will_ be doing work over the next few months that will benefit > FreeBSD, and we _will_ be contributing it back to FreeBSD. > > So, the upshot of this discussion is that Collaborative Fusion is going to > be throwing developer resources at FreeBSD HA. We'd like feedback from the > FreeBSD community on how we can best do this so that it can be integrated > back into the FreeBSD source tree. We've already done _some_ research and > we're looking for input. Let me say that we would find this a Very Good Thing too. Let us know how we can be of assistance. FYI: I even own the domain names openha.(org|com), etc ;-). I would have bought openha.net, but I had to draw the line somewhere... Non-Linux people seem to like to call it heartbeat. But, all those domain names are already taken :-( -- Alan Robertson "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce From owner-freebsd-rc@FreeBSD.ORG Fri May 19 05:10:10 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83F1816A422 for ; Fri, 19 May 2006 05:10:10 +0000 (UTC) (envelope-from alanr@unix.sh) Received: from robertsons.dyndns.org (robertsons.dyndns.org [71.39.23.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CEB843D48 for ; Fri, 19 May 2006 05:10:09 +0000 (GMT) (envelope-from alanr@unix.sh) Received: from linux.site (servidor [10.10.10.5]) by robertsons.dyndns.org (Postfix) with ESMTP id EE001557BF; Thu, 18 May 2006 23:10:08 -0600 (MDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by linux.site (Postfix) with ESMTP id DBE751F1D9; Thu, 18 May 2006 23:10:08 -0600 (MDT) Message-ID: <446D5330.6030402@unix.sh> Date: Thu, 18 May 2006 23:10:08 -0600 From: Alan Robertson Organization: IBM Linux Technology Center User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: General Linux-HA mailing list References: <20060513015129.C95601@arbitor.digitalfreaks.org> In-Reply-To: <20060513015129.C95601@arbitor.digitalfreaks.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, tech-userlevel@netbsd.org, ocf@lists.community.tummy.com Subject: Re: [Linux-HA] Integrating OCF framework w/ (Net|Free)BSD rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 05:10:10 -0000 Brian A. Seklecki wrote: > > What is OCF? The extensions required to make any RC script register a > system service as a Cluster Resource in the Linux-HA infrastructure. > > For those of you unfamiliar with OCF, please refer to the draft standard > at: > http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD > > http://linux-ha.org/HeartbeatResourceAgent > http://linux-ha.org/LSBResourceAgent > http://linux-ha.org/OCFResourceAgent > http://linux-ha.org/ResourceAgentSpecs > > Fortunately, our rc.d system infrastructure is sufficiently extensible > in nature to easily mitigate the need for duplicate OCF script coding > efforts by Port maintainers. Existing in-tree and Ports-provided rc.d/ > compliant scripts can be extended with very little effort. > > However some discussion would be prudent as to how to best accomplish > the task most conducive > > == > > *) Exit codes > > We deviate slightly from LSB, as so does LSB from OCF. > > Example: When we execute a "stop" command to run_rc_command() on an > already stopped service, we return code "1", while OCF/LSB calls for > code 3. Actually, both call for code 0. This is taken care of by some other language elsewhere for this specific case. There are no known cases where the LSB defines something that the OCF deviates from. This was a design goal. My guess it's a documentation problem - or other misunderstanding - or a bug. Can you point out a specific example? > We could put a conditional check around the return/exit > statement, however OCF "compatibility mode" would need to be a variable > we source in from the service's RC script. like 'checkyesno > $ofc_compat' at line 691 in rc.subr > > There are other adjustments to exit codes that would so need to be made > (see the standards doc) > > *) Environmental variables for per-instance services > > Currently we don't have a uniform method for dealing with multiple > instances of services. The Apache2 method is nice ("Profiles"); -- > "apache2.sh [instance] [argument]" syntax. OCF scripts expect to be > differentiate using exported environmental variables from the calling > application: OCF_RESKEY_*, which is not an issue. > > *) Additional arguments > > The spec calls for additional arguments "monitor" (to augment the > existing "status") as well as "metadata" (to describe the service using > an XML DTD) and an optional "validate-all". > > These can be very easily implemented using a $extra_commands="". > > extra_commands="monitor metadata" > > monitor_cmd="slapd_monitor" > metadata_cmd="slapd_metadata" > > Note: commands with hyphens (or function names) in them do not seem to > be honored. 'monitor' should hypothetically be an intelligent service > check, more than just checking if a TCP socket is open but also if the > service is healthy -- which implies calling/exec'ing an outside program, > like a Nagios health check. Something that generates dynamic input and > checks it against generated output. And OCF supports multiple levels of checks. You can define a "shallow" check and a deep check, and a really really deep check. With Linux-HA, you can schedule the shallow check every 5 seconds, the deep check every 5 minutes and the really really deep check once a day. > Note: None of the included OCF examples do truely objective testing yet! > (Sorry guys, systems that don't permitted fragmented packets to the > network broadcast address aren't going to run Apache's mod_status by > default }:> ). We can leave the $servicename_monitor() symantics up to > the port maintainer, plus the end user can always do more aggressive > checking. I'm missing something regarding apache here. You may have to help me in my ignorance. Maybe use single syllable words? ;-) [regarding doing things better: patches are being accepted ;-)] > However, our current "status" routine checks for the existence of a PID > file and cross-references it against the process list (which is a more > extensive than most other RC systems). Given that, as a temporary fix, > "monitor" can be easily mapped to "status" using a small code snippit: We already do this for the 'lsb' style init scripts. This is all done through plugins. Maybe you need a FreeBSD plugin (in lieu of the "lsb" plugin)? > As for the "metadata" and "validate-all" routines, the XML DTD simply > helps describe the command line and environmental variable arguments > valid for the OCF service script, so we might be able to develop a > reusable set of routines for generating the output without any crazy > dependencies on libXML. We just do cats from here documents. You certainly don't need libxml to generate fixed content (constant) XML. > The trickier question arises when we want to start making in-tree rc.d/ > scripts OFC compliant/compatible (nfsd, named, inetd, sendmail, ntpd, > etc. come to mind) > > I'm interested in any discussion / thoughts on a strategy or apporach > for coding OCF compatibility / integration into our rc.d/ system I like the idea that you're discussing this and taking it semi-seriously. I think your choices might include: a) write a "bsd" RA plugin (reasonably easy) b) adopt OCF for your scripting (moderately difficult - esp. politically) c) define Yet Another RC standard to make things better d) adopt LSB conventions for your scripts (very unlikely I would guess) -- Alan Robertson "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." - William Wilberforce From owner-freebsd-rc@FreeBSD.ORG Sat May 20 05:06:31 2006 Return-Path: X-Original-To: freebsd-rc@hub.freebsd.org Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E6F816A421; Sat, 20 May 2006 05:06:31 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 495FC43D48; Sat, 20 May 2006 05:06:31 +0000 (GMT) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (delphij@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k4K56VvV035348; Sat, 20 May 2006 05:06:31 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k4K56V7s035344; Sat, 20 May 2006 05:06:31 GMT (envelope-from delphij) Date: Sat, 20 May 2006 05:06:31 GMT From: Xin LI Message-Id: <200605200506.k4K56V7s035344@freefall.freebsd.org> To: delphij@FreeBSD.org, freebsd-rc@FreeBSD.org, delphij@FreeBSD.org Cc: Subject: Re: bin/94767: [patch] rcorder(8) dumps core when does not use a proper RCng script (dansguardian) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 05:06:32 -0000 Synopsis: [patch] rcorder(8) dumps core when does not use a proper RCng script (dansguardian) Responsible-Changed-From-To: freebsd-rc->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Sat May 20 05:06:22 UTC 2006 Responsible-Changed-Why: Take http://www.freebsd.org/cgi/query-pr.cgi?pr=94767 From owner-freebsd-rc@FreeBSD.ORG Sat May 20 07:21:18 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F56716A471; Sat, 20 May 2006 07:21:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC3F43D5E; Sat, 20 May 2006 07:21:16 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 0F240EB28E4; Sat, 20 May 2006 15:21:14 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id r0oO9NhdFy-U; Sat, 20 May 2006 15:21:09 +0800 (CST) Received: from [192.168.1.9] (unknown [221.216.126.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 09C17EB28CF; Sat, 20 May 2006 15:21:08 +0800 (CST) From: Xin LI To: freebsd-rc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-G8bjTm799TE2Zwvazs4l" Organization: The FreeBSD Project Date: Sat, 20 May 2006 15:21:00 +0800 Message-Id: <1148109661.952.26.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Cc: Ruslan Ermilov , "Simon L. Nielsen" Subject: [PATCH FOR REVIEW] Implementation of skeleton jail X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 07:21:18 -0000 --=-G8bjTm799TE2Zwvazs4l Content-Type: multipart/mixed; boundary="=-CvtWJFjMbskxW/CB0lDN" --=-CvtWJFjMbskxW/CB0lDN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, folks, Here is an implementation of what I call it "skeleton jail". The idea is that it is more or less to be common that we do not want to actually copy of the base system (sometimes even other stuff) across zillions of jails. The skeleton jail is an approach that makes management of such jails easier, by making use of mount_nullfs(8) to make read-only shadow or read-write shadow from the so-called "skeleton root". For instance, by default the skeleton jail would mount the following directories from the skeleton root (/) to the jail: bin -> ${_root}/bin sbin -> ${_root}/sbin lib -> ${_root}/lib libexec -> ${_root}/libexec usr/bin -> ${_root}/usr/bin usr/sbin -> ${_root}/usr/sbin usr/include -> ${_root}/usr/include usr/lib -> ${_root}/usr/lib usr/libdata -> ${_root}/usr/libdata usr/libexec -> ${_root}/usr/libexec usr/sbin -> ${_root}/sbin usr/share -> ${_root}/share In order to create the environment that is suitable for the skeleton jail (say, create the directory hierarchy, populate the /etc/ stuff, etc, but not the actual installworld), I have added a new target "installskel" to src/Makefile which will help the work. There are four variables that can be set in either system level default or per-jail way: - _skel_enable Whether to raise the jail from a skeleton root. The default is NO - _skel_root The place of skeleton root. The default is "/" - _skel_romounts Which directories (relative to the skeleton root) should be mounted read-only to the skeleton jail. The default is shown above. - _skel_rwmounts Which directories (relative to the skeleton root) should be mounted read-write to the skeleton jail. The default is nothing, but a potential useful option might be "/usr/ports", except for security concerns. To try out the patch: - Apply the patch. - Do a full "make buildworld" and potentially "make installworld" so that your system is fresh. - Install the patched jail script into /etc/rc.d/ (e.g. can be done with rm /etc/rc.d/jail && mergemaster -i) - Create a directory, i.e. "/vhosts/skeltest" - Do a "make installskel DESTDIR=3D/vhosts/skeltest" - Add the following stuff into /etc/rc.conf: jail_enable=3D"YES" jail_list=3D"skeltest" jail_skeltest_rootdir=3D"/vhosts/skeltest" jail_skeltest_hostname=3D"skeltest.example.com" jail_skeltest_ip=3D"127.0.0.1" jail_skeltest_devfs_enable=3D"YES" jail_skeltest_exec=3D"/bin/sh /etc/rc" - Do a "/etc/rc.d/jail start skeltest" or reboot to see the jail up. Comments? Cheers, --=20 Xin LI http://www.delphij.net/ --=-CvtWJFjMbskxW/CB0lDN Content-Disposition: attachment; filename=patch-skel Content-Type: text/x-patch; name=patch-skel; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SW5kZXg6IE1ha2VmaWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvTWFr ZWZpbGUsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMyOQ0KZGlmZiAtdSAtcjEuMzI5IE1ha2Vm aWxlDQotLS0gTWFrZWZpbGUJMTEgTWF5IDIwMDYgMTg6NTQ6MTYgLTAwMDAJMS4zMjkNCisrKyBN YWtlZmlsZQkxNSBNYXkgMjAwNiAwMjowNDoxMyAtMDAwMA0KQEAgLTcxLDcgKzcxLDcgQEANCiAJ Y2xlYW4gY2xlYW5kZXBlbmQgY2xlYW5kaXIgZGVsZXRlLW9sZCBkZWxldGUtb2xkLWxpYnMgZGVw ZW5kIFwNCiAJZGlzdHJpYnV0ZSBkaXN0cmlidXRld29ybGQgZGlzdHJpYi1kaXJzIGRpc3RyaWJ1 dGlvbiBldmVyeXRoaW5nIFwNCiAJaGllcmFyY2h5IGluc3RhbGwgaW5zdGFsbGNoZWNrIGluc3Rh bGxrZXJuZWwgaW5zdGFsbGtlcm5lbC5kZWJ1Z1wNCi0JcmVpbnN0YWxsa2VybmVsIHJlaW5zdGFs bGtlcm5lbC5kZWJ1ZyBpbnN0YWxsd29ybGQgXA0KKwlyZWluc3RhbGxrZXJuZWwgcmVpbnN0YWxs a2VybmVsLmRlYnVnIGluc3RhbGxza2VsIGluc3RhbGx3b3JsZCBcDQogCWtlcm5lbC10b29sY2hh aW4gbGlicmFyaWVzIGxpbnQgbWFuaW5zdGFsbCBcDQogCW9iaiBvYmpsaW5rIHJlZ3Jlc3MgcmVy ZWxlYXNlIHNob3djb25maWcgdGFncyB0b29sY2hhaW4gdXBkYXRlIFwNCiAJX3dvcmxkdG1wIF9s ZWdhY3kgX2Jvb3RzdHJhcC10b29scyBfY2xlYW5vYmogX29iaiBcDQpAQCAtODYsNiArODYsNyBA QA0KIC5PUkRFUjogYnVpbGR3b3JsZCBpbnN0YWxsd29ybGQNCiAuT1JERVI6IGJ1aWxkd29ybGQg ZGlzdHJpYnV0ZXdvcmxkDQogLk9SREVSOiBidWlsZHdvcmxkIGJ1aWxka2VybmVsDQorLk9SREVS OiBidWlsZHdvcmxkIGluc3RhbGxza2VsDQogLk9SREVSOiBidWlsZGtlcm5lbCBpbnN0YWxsa2Vy bmVsDQogLk9SREVSOiBidWlsZGtlcm5lbCBpbnN0YWxsa2VybmVsLmRlYnVnDQogLk9SREVSOiBi dWlsZGtlcm5lbCByZWluc3RhbGxrZXJuZWwNCkluZGV4OiBNYWtlZmlsZS5pbmMxDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvTWFrZWZpbGUuaW5jMSx2DQpyZXRyaWV2aW5n IHJldmlzaW9uIDEuNTQ2DQpkaWZmIC11IC1yMS41NDYgTWFrZWZpbGUuaW5jMQ0KLS0tIE1ha2Vm aWxlLmluYzEJMTcgTWF5IDIwMDYgMDk6MzM6MDUgLTAwMDAJMS41NDYNCisrKyBNYWtlZmlsZS5p bmMxCTE4IE1heSAyMDA2IDAzOjQ0OjIwIC0wMDAwDQpAQCAtNTQ1LDYgKzU0NSwxOCBAQA0KIAly bSAtcmYgJHtJTlNUQUxMVE1QfQ0KIA0KICMNCisjIGluc3RhbGxza2VsDQorIw0KKyMgSW5zdGFs bHMgYSBtaW5pbXVtIHNldCBvZiBmaWxlcyB0aGF0IGNhbiBzdXBwb3J0IGEgc2tlbC1qYWlsDQor Iw0KK2luc3RhbGxza2VsOg0KKwlAZWNobyAiLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0iDQorCUBlY2hvICI+Pj4gTWFraW5nIGlu c3RhbGxza2VsIg0KKwlAZWNobyAiLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0iDQorCSR7XytffWNkICR7LkNVUkRJUn07ICR7TUFL RX0gLWYgTWFrZWZpbGUuaW5jMSBoaWVyYXJjaHkNCisJJHtfK199Y2QgJHsuQ1VSRElSfS9ldGM7 ICR7TUFLRX0gZGlzdHJpYnV0aW9uDQorDQorIw0KICMgcmVpbnN0YWxsDQogIw0KICMgSWYgeW91 IGhhdmUgYSBidWlsZCBzZXJ2ZXIsIHlvdSBjYW4gTkZTIG1vdW50IHRoZSBzb3VyY2UgYW5kIG9i aiBkaXJlY3Rvcmllcw0KSW5kZXg6IGV0Yy9kZWZhdWx0cy9yYy5jb25mDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvZXRjL2RlZmF1bHRzL3JjLmNvbmYsdg0KcmV0cmlldmlu ZyByZXZpc2lvbiAxLjI4NA0KZGlmZiAtdSAtcjEuMjg0IHJjLmNvbmYNCi0tLSBldGMvZGVmYXVs dHMvcmMuY29uZgkxNyBNYXkgMjAwNiAwOTozMzowNSAtMDAwMAkxLjI4NA0KKysrIGV0Yy9kZWZh dWx0cy9yYy5jb25mCTIwIE1heSAyMDA2IDA2OjQyOjM1IC0wMDAwDQpAQCAtNTU0LDYgKzU1NCwx MCBAQA0KICNqYWlsX2V4YW1wbGVfZGV2ZnNfcnVsZXNldD0icnVsZXNldF9uYW1lIgkjIGRldmZz IHJ1bGVzZXQgdG8gYXBwbHkgdG8gamFpbA0KICNqYWlsX2V4YW1wbGVfZnN0YWI9IiIJCQkJIyBm c3RhYig1KSBmb3IgbW91bnQvdW1vdW50DQogI2phaWxfZXhhbXBsZV9mbGFncz0iLWwgLVUgcm9v dCIJCSMgZmxhZ3MgZm9yIGphaWwoOCkNCisjamFpbF9leGFtcGxlX3NrZWxfZW5hYmxlPSJOTyIJ CQkjIFN0YXJ0IGphaWwgZnJvbSBhIHNrZWxldG9uIChpLmUuIC8pDQorI2phaWxfZXhhbXBsZV9z a2VsX3Jvb3Q9Ii8iCQkJIyBUaGUgcm9vdCBvZiB0aGUgamFpbCBza2VsZXRvbg0KKyNqYWlsX2V4 YW1wbGVfc2tlbF9yb21vdW50cz0iIgkJCSMgTW91bnQgcmVhZC1vbmx5IGNvcHkgZnJvbSB0aGUg c2tlbGV0b24gcm9vdA0KKyNqYWlsX2V4YW1wbGVfc2tlbF9yd21vdW50cz0iL3Vzci9wb3J0cyIJ IyBNb3VudCByZWFkLXdyaXRlIGNvcHkgZnJvbSB0aGUgc2tlbGV0b24gcm9vdA0KIA0KICMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQogIyMjIERlZmluZSBzb3VyY2VfcmNfY29uZnMsIHRoZSBtZWNoYW5pc20gdXNlZCBieSAvZXRj L3JjLiogIyMNCkluZGV4OiBldGMvcmMuZC9qYWlsDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hv bWUvbmN2cy9zcmMvZXRjL3JjLmQvamFpbCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzINCmRp ZmYgLXUgLXIxLjMyIGphaWwNCi0tLSBldGMvcmMuZC9qYWlsCTExIE1heSAyMDA2IDE0OjIzOjQz IC0wMDAwCTEuMzINCisrKyBldGMvcmMuZC9qYWlsCTIwIE1heSAyMDA2IDA2OjUzOjEwIC0wMDAw DQpAQCAtNjgsNiArNjgsMTYgQEANCiAJZXZhbCBfZmxhZ3M9XCJcJHtqYWlsXyR7X2p9X2ZsYWdz Oi0ke2phaWxfZmxhZ3N9fVwiDQogCVsgLXogIiR7X2ZsYWdzfSIgXSAmJiBfZmxhZ3M9Ii1sIC1V IHJvb3QiDQogDQorCSMgRGVmYXVsdCBzZXR0aW5ncyBmb3Igc2tlbCBqYWlsDQorCWV2YWwgX3Nr ZWxfZW5hYmxlPVwiXCR7amFpbF8ke19qfV9za2VsX2VuYWJsZTotJHtqYWlsX3NrZWxfZW5hYmxl fX1cIg0KKwlbIC16ICIke19za2VsX2VuYWJsZX0iIF0gJiYgX3NrZWxfZW5hYmxlPSJOTyINCisJ ZXZhbCBfc2tlbF9yb290PVwiXCR7amFpbF8ke19qfV9za2VsX3Jvb3Q6LSR7amFpbF9za2VsX3Jv b3R9fVwiDQorCVsgLXogIiR7X3NrZWxfcm9vdH0iIF0gJiYgX3NrZWxfcm9vdD0iLyINCisJZXZh bCBfc2tlbF9yb21vdW50cz1cIlwke2phaWxfJHtfan1fc2tlbF9yb21vdW50czotJHtqYWlsX3Nr ZWxfcm9tb3VudHN9fVwiDQorCVsgLXogIiR7X3NrZWxfcm9tb3VudHN9IiBdICYmIF9za2VsX3Jv bW91bnRzPSJiaW4gc2JpbiBsaWIgbGliZXhlYyB1c3IvYmluIHVzci9zYmluIHVzci9pbmNsdWRl IHVzci9saWIgdXNyL2xpYmRhdGEgdXNyL2xpYmV4ZWMgdXNyL3NiaW4gdXNyL3NoYXJlIg0KKwll dmFsIF9za2VsX3J3bW91bnRzPVwiXCR7amFpbF8ke19qfV9za2VsX3J3bW91bnRzOi17amFpbF9z a2VsX3J3bW91bnRzfX1cIg0KKwlbIC16ICIke19za2VsX3J3bW91bnRzfSIgXSAmJiBfc2tlbF9y d21vdW50cz0iIg0KKw0KIAkjIERlYnVnZ2luZyBhaWQNCiAJIw0KIAlkZWJ1ZyAiJF9qIGRldmZz IGVuYWJsZTogJF9kZXZmcyINCkBAIC04Niw2ICs5NiwxMCBAQA0KIAlkZWJ1ZyAiJF9qIGV4ZWMg c3RhcnQ6ICRfZXhlY19zdGFydCINCiAJZGVidWcgIiRfaiBleGVjIHN0b3A6ICRfZXhlY19zdG9w Ig0KIAlkZWJ1ZyAiJF9qIGZsYWdzOiAkX2ZsYWdzIg0KKwlkZWJ1ZyAiJF9qIHNrZWwgZW5hYmxl OiAkX3NrZWxfZW5hYmxlIg0KKwlkZWJ1ZyAiJF9qIHNrZWwgbW91bnQtcmVhZG9ubHk6ICRfc2tl bF9yb21vdW50cyINCisJZGVidWcgIiRfaiBza2VsIG1vdW50LXJlYWR3cml0ZTogJF9za2VsX3J3 bW91bnRzIg0KKwlkZWJ1ZyAiJF9qIHNrZWwgbW91bnQgc2tlbGV0b24gZnJvbTogJF9za2VsX3Jv b3QiDQogDQogCWlmIFsgLXogIiR7X2hvc3RuYW1lfSIgXTsgdGhlbg0KIAkJZXJyIDMgIiRuYW1l OiBObyBob3N0bmFtZSBoYXMgYmVlbiBkZWZpbmVkIGZvciAke19qfSINCkBAIC0xNTIsNiArMTY2 LDIwIEBADQogCQlbIC1mICIke19mc3RhYn0iIF0gfHwgd2FybiAiJHtfZnN0YWJ9IGRvZXMgbm90 IGV4aXN0Ig0KIAkJdW1vdW50IC1hIC1GICIke19mc3RhYn0iID4vZGV2L251bGwgMj4mMQ0KIAlm aQ0KKwlpZiBjaGVja3llc25vIF9za2VsX2VuYWJsZTsgdGhlbg0KKwkJZm9yIF9tbnRwdCBpbiAk X3NrZWxfcm9tb3VudHMNCisJCWRvDQorCQkJaWYgWyAtZCAiJHtfcm9vdGRpcn0vJHtfbW50cHR9 IiBdIDsgdGhlbg0KKwkJCQl1bW91bnQgLWYgJHtfcm9vdGRpcn0vJHtfbW50cHR9ID4gL2Rldi9u dWxsIDI+JjENCisJCQlmaQ0KKwkJZG9uZQ0KKwkJZm9yIF9tbnRwdCBpbiAkX3NrZWxfcndtb3Vu dHMNCisJCWRvDQorCQkJaWYgWyAtZCAiJHtfcm9vdGRpcn0vJHtfbW50cHR9IiBdIDsgdGhlbg0K KwkJCQl1bW91bnQgLWYgJHtfcm9vdGRpcn0vJHtfbW50cHR9ID4gL2Rldi9udWxsIDI+JjENCisJ CQlmaQ0KKwkJZG9uZQ0KKwlmaQ0KIH0NCiANCiBqYWlsX3N0YXJ0KCkNCkBAIC0xODUsNiArMjEz LDI0IEBADQogCQkJZmkNCiAJCQltb3VudCAtYSAtRiAiJHtfZnN0YWJ9Ig0KIAkJZmkNCisJCWlm IGNoZWNreWVzbm8gX3NrZWxfZW5hYmxlOyB0aGVuDQorCQkJaW5mbyAiTW91bnRpbmcgc2tlbGV0 b24gZm9yIGphaWwgJHtfamFpbH0gZnJvbSAke19za2VsX3Jvb3R9Ig0KKwkJCWZvciBfbW50cHQg aW4gJHtfc2tlbF9yb21vdW50c30gJHtza2VsX3J3bW91bnRzfQ0KKwkJCWRvDQorCQkJCWlmIFsg ISAtZCAiJHtfcm9vdGRpcn0vJHtfbW50cHR9IiBdIDsgdGhlbg0KKwkJCQkJZGVidWcgQ3JlYXRp bmcgbWlzc2luZyBkaXJlY3RvcnkgJHtfcm9vdGRpcn0vJHtfbW50cHR9DQorCQkJCQlta2RpciAt cCAke19yb290ZGlyfS8ke19tbnRwdH0NCisJCQkJZmkNCisJCQlkb25lDQorCQkJZm9yIF9tbnRw dCBpbiAke19za2VsX3JvbW91bnRzfQ0KKwkJCWRvDQorCQkJCW1vdW50X251bGxmcyAtb3Jkb25s eSAke19za2VsX3Jvb3R9LyR7X21udHB0fSAke19yb290ZGlyfS8ke19tbnRwdH0gPiAvZGV2L251 bGwgMj4mMQ0KKwkJCWRvbmUNCisJCQlmb3IgX21udHB0IGluICR7X3NrZWxfcndtb3VudHN9DQor CQkJZG8NCisJCQkJbW91bnRfbnVsbGZzICR7X3NrZWxfcm9vdH0vJHtfbW50cHR9ICR7X3Jvb3Rk aXJ9LyR7X21udHB0fSA+IC9kZXYvbnVsbCAyPiYxDQorCQkJZG9uZQ0KKwkJZmkNCiAJCWlmIGNo ZWNreWVzbm8gX2RldmZzOyB0aGVuDQogCQkJIyBJZiBkZXZmcyBpcyBhbHJlYWR5IG1vdW50ZWQg aGVyZSwgc2tpcCBpdC4NCiAJCQlkZiAtdCBkZXZmcyAiJHtfZGV2ZGlyfSIgPi9kZXYvbnVsbA0K --=-CvtWJFjMbskxW/CB0lDN-- --=-G8bjTm799TE2Zwvazs4l Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEbsNchcUczkLqiksRAunoAJ9Jj/rn9m4dE5uXCaKml+DM8ieJegCfU3J2 d+NX/FgkCXlz9Oh5WD+6OFg= =fbK7 -----END PGP SIGNATURE----- --=-G8bjTm799TE2Zwvazs4l-- From owner-freebsd-rc@FreeBSD.ORG Sat May 20 08:01:50 2006 Return-Path: X-Original-To: freebsd-rc@FreeBSD.org Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D90416A425; Sat, 20 May 2006 08:01:50 +0000 (UTC) (envelope-from ru@ip.net.ua) Received: from cielago.ip.net.ua (cielago.ip.net.ua [82.193.96.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34CEA43D46; Sat, 20 May 2006 08:01:48 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by cielago.ip.net.ua (8.13.6/8.13.6) with ESMTP id k4K80QfQ084617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 May 2006 11:00:32 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.6/8.13.6) id k4K810YM071586; Sat, 20 May 2006 11:01:00 +0300 (EEST) (envelope-from ru) Date: Sat, 20 May 2006 11:01:00 +0300 From: Ruslan Ermilov To: Xin LI Message-ID: <20060520080100.GE84766@ip.net.ua> References: <1148109661.952.26.camel@spirit> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C94crkcyjafcjHxo" Content-Disposition: inline In-Reply-To: <1148109661.952.26.camel@spirit> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-rc , "Simon L. Nielsen" Subject: Re: [PATCH FOR REVIEW] Implementation of skeleton jail X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 08:01:50 -0000 --C94crkcyjafcjHxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 20, 2006 at 03:21:00PM +0800, Xin LI wrote: > Hi, folks, >=20 > Here is an implementation of what I call it "skeleton jail". The idea > is that it is more or less to be common that we do not want to actually > copy of the base system (sometimes even other stuff) across zillions of > jails. >=20 > The skeleton jail is an approach that makes management of such jails > easier, by making use of mount_nullfs(8) to make read-only shadow or > read-write shadow from the so-called "skeleton root". >=20 > For instance, by default the skeleton jail would mount the following > directories from the skeleton root (/) to the jail: >=20 > bin -> ${_root}/bin > sbin -> ${_root}/sbin > lib -> ${_root}/lib > libexec -> ${_root}/libexec > usr/bin -> ${_root}/usr/bin > usr/sbin -> ${_root}/usr/sbin > usr/include -> ${_root}/usr/include > usr/lib -> ${_root}/usr/lib > usr/libdata -> ${_root}/usr/libdata > usr/libexec -> ${_root}/usr/libexec > usr/sbin -> ${_root}/sbin > usr/share -> ${_root}/share >=20 > In order to create the environment that is suitable for the skeleton > jail (say, create the directory hierarchy, populate the /etc/ stuff, > etc, but not the actual installworld), I have added a new target > "installskel" to src/Makefile which will help the work. >=20 You really don't want the new "installskel" target, instead please use the existing "distrib-dirs" and "distribution" targets from src/Makefile. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --C94crkcyjafcjHxo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEbsy7qRfpzJluFF4RAiN+AJ90xZkiDgESzwFQiUyVU3CRZoW6sQCdFEMl 4LjqJaHN0K+4NhRwNGyxATc= =9roX -----END PGP SIGNATURE----- --C94crkcyjafcjHxo-- From owner-freebsd-rc@FreeBSD.ORG Sat May 20 15:01:13 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F184B16A436 for ; Sat, 20 May 2006 15:01:12 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [80.237.196.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CE0543D46 for ; Sat, 20 May 2006 15:01:09 +0000 (GMT) (envelope-from erdgeist@erdgeist.org) Received: (qmail 4771 invoked by uid 0); 20 May 2006 15:01:11 -0000 Received: from e178056118.adsl.alicedsl.de (HELO ?10.1.1.103?) (erdgeist@erdgeist.org@85.178.56.118) by elektropost.org with AES256-SHA encrypted SMTP; 20 May 2006 15:01:11 -0000 Message-ID: <446F2F35.9060901@erdgeist.org> Date: Sat, 20 May 2006 17:01:09 +0200 From: Dirk Engling User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Xin LI References: <1148109661.952.26.camel@spirit> In-Reply-To: <1148109661.952.26.camel@spirit> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc Subject: Re: [PATCH FOR REVIEW] Implementation of skeleton jail X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 15:01:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xin LI wrote: > Here is an implementation of what I call it "skeleton jail". The idea > is that it is more or less to be common that we do not want to actually > copy of the base system (sometimes even other stuff) across zillions of > jails. Nice idea, you might want to check my thoughts on that in the ezjail-project page [1]. > For instance, by default the skeleton jail would mount the following > directories from the skeleton root (/) to the jail: > > bin -> ${_root}/bin > sbin -> ${_root}/sbin > lib -> ${_root}/lib > libexec -> ${_root}/libexec > usr/bin -> ${_root}/usr/bin > usr/sbin -> ${_root}/usr/sbin > usr/include -> ${_root}/usr/include > usr/lib -> ${_root}/usr/lib > usr/libdata -> ${_root}/usr/libdata > usr/libexec -> ${_root}/usr/libexec > usr/sbin -> ${_root}/sbin > usr/share -> ${_root}/share The complete set of sharable files in a FreeBSD system is bin boot lib libexec rescue sbin usr/bin usr/games usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/src usr/share and probably usr/lib32 for amd64 machines. > There are four variables that can be set in either system level default > or per-jail way: > > - _skel_enable > Whether to raise the jail from a skeleton root. The default is NO > - _skel_root > The place of skeleton root. The default is "/" > - _skel_romounts > Which directories (relative to the skeleton root) should be mounted > read-only to the skeleton jail. The default is shown above. > - _skel_rwmounts > Which directories (relative to the skeleton root) should be mounted > read-write to the skeleton jail. The default is nothing, but a > potential useful option might be "/usr/ports", except for security > concerns. Why would you want to reinvent the wheel? What does this offer that /etc/fstab. wont offer you? You can simply add lines of the type /bin /JAILROOT/bin nullfs ro 0 0 /sbin /JAILROOT/sbin nullfs ro 0 0 ... there and /etc/rc.d/jail will take care of the rest. The problem with FreeBSD jails in the moment is not, that you can't automatically start them, rather that it is quite hard to manage them. Adding lots of lines to your /etc/rc.conf for each jail seems like a bad move. I'd rather suggest adding a /etc/jails directory (similar to ezjails /usr/local/etc/ezjail) containing configs for your jails to make them easier managable. Additionally a script to create and manage those configs, the fstabs and, of course, the JAILROOTs will be needed. Futher: there's no need to mount /usr/ports rw. If you alter your make.conf to contain WRKDIRPREFIX= /var/ports DISTDIR= /var/ports/distfiles PACKAGES= /var/ports/packages you can mount ports ro, if you want to share your distfiles through the jails, you can mount /var/ports/distfiles rw and still keep the checksums safe within /usr/ports/. However I implemented a lot of those ideas in the ezjail-project and if noone complains I might try to provide a patch to move it into the base system. Regards, erdgeist [1] http://erdgeist.org/arts/software/ezjail/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) iD8DBQFEby81ImmQdUyYEgkRApDKAJ42VsqA+UgS2I39syOtHMIvwW2KawCdFwWL P9RTxDX5ax/h/9UpTKL3xwY= =luon -----END PGP SIGNATURE----- From owner-freebsd-rc@FreeBSD.ORG Sat May 20 15:45:35 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBE4716A438 for ; Sat, 20 May 2006 15:45:35 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32A4D43D6D for ; Sat, 20 May 2006 15:45:25 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 454E4EB2AAB; Sat, 20 May 2006 23:45:23 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id smfNTQPYoo8p; Sat, 20 May 2006 23:45:20 +0800 (CST) Received: from [192.168.1.9] (unknown [221.216.129.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 23A11EB0ED5; Sat, 20 May 2006 23:45:19 +0800 (CST) From: Xin LI To: Dirk Engling In-Reply-To: <446F2F35.9060901@erdgeist.org> References: <1148109661.952.26.camel@spirit> <446F2F35.9060901@erdgeist.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KXuQ8iha82GtgLurfnMN" Organization: The FreeBSD Project Date: Sat, 20 May 2006 23:45:13 +0800 Message-Id: <1148139913.962.18.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Cc: freebsd-rc Subject: Re: [PATCH FOR REVIEW] Implementation of skeleton jail X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 15:45:36 -0000 --=-KXuQ8iha82GtgLurfnMN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Dirk, =E5=9C=A8 2006-05-20=E5=85=AD=E7=9A=84 17:01 +0200=EF=BC=8CDirk Engling=E5= =86=99=E9=81=93=EF=BC=9A [snip] > > usr/sbin -> ${_root}/sbin > > usr/share -> ${_root}/share >=20 > The complete set of sharable files in a FreeBSD system is >=20 > bin boot lib libexec rescue sbin usr/bin usr/games usr/include usr/lib > usr/libdata usr/libexec usr/sbin usr/src usr/share >=20 > and probably usr/lib32 for amd64 machines. I will take these into account. However, it looks like that having boot/ and rescue/ mounted is not useful for general use, though. > Why would you want to reinvent the wheel? What does this offer that > /etc/fstab. wont offer you? >=20 > You can simply add lines of the type >=20 > /bin /JAILROOT/bin nullfs ro 0 0 > /sbin /JAILROOT/sbin nullfs ro 0 0 > ... >=20 > there and /etc/rc.d/jail will take care of the rest. The story was long. The "skeljail" is actually being used at my company before _mount options appeared. While the per-jail fstab already gives a general way of mounting stuff into the jail, it would become a headache when you have to manage a hundred of jails that utilizes the same skel_fstab that is different only in the mountpoint, especially when you are upgrading the system which brings a new directory to the distribution. Moreover, IMHO, the configuration files should contain common settings as less as possible, and we should provide common mechanism to handle these, it is especially error-prone when you have more than a dozen of "system level settings" while only have 1 or 2 "user settings" in one single file. > The problem with FreeBSD jails in the moment is not, that you can't > automatically start them, rather that it is quite hard to manage them. > Adding lots of lines to your /etc/rc.conf for each jail seems like a bad > move. > > I'd rather suggest adding a /etc/jails directory (similar to ezjails > /usr/local/etc/ezjail) containing configs for your jails to make them > easier managable. Additionally a script to create and manage those > configs, the fstabs and, of course, the JAILROOTs will be needed. I think this is a good idea. > Futher: there's no need to mount /usr/ports rw. If you alter your > make.conf to contain >=20 > WRKDIRPREFIX=3D /var/ports > DISTDIR=3D /var/ports/distfiles > PACKAGES=3D /var/ports/packages >=20 > you can mount ports ro, if you want to share your distfiles through the > jails, you can mount /var/ports/distfiles rw and still keep the > checksums safe within /usr/ports/. Actually I am aware of this, perhaps the example provided is just not that well-thought :-) > However I implemented a lot of those ideas in the ezjail-project and if > noone complains I might try to provide a patch to move it into the base > system. I will take a closer look at your project and see if we can bring some part or the whole thing to FreeBSD. Thanks. Cheers, --=20 Xin LI http://www.delphij.net/ --=-KXuQ8iha82GtgLurfnMN Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEbzmJhcUczkLqiksRAp1rAJ4qQzL6db36jaLFwrgIqjWpWrCNrwCdHKpj /zY0gAbZ3l5SNKMKU0lhkDI= =Kk1v -----END PGP SIGNATURE----- --=-KXuQ8iha82GtgLurfnMN-- From owner-freebsd-rc@FreeBSD.ORG Sat May 20 17:38:32 2006 Return-Path: X-Original-To: freebsd-rc@freebsd.org Delivered-To: freebsd-rc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A55516A457; Sat, 20 May 2006 17:38:32 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5541343D46; Sat, 20 May 2006 17:38:30 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.18]) by mx.nitro.dk (Postfix) with ESMTP id 876052D4877; Sat, 20 May 2006 17:38:47 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 5D3C011433; Sat, 20 May 2006 19:38:29 +0200 (CEST) Date: Sat, 20 May 2006 19:38:29 +0200 From: "Simon L. Nielsen" To: Xin LI Message-ID: <20060520173829.GG1080@zaphod.nitro.dk> References: <1148109661.952.26.camel@spirit> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OZkY3AIuv2LYvjdk" Content-Disposition: inline In-Reply-To: <1148109661.952.26.camel@spirit> User-Agent: Mutt/1.5.11 Cc: Ruslan Ermilov , freebsd-rc Subject: Re: [PATCH FOR REVIEW] Implementation of skeleton jail X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 May 2006 17:38:34 -0000 --OZkY3AIuv2LYvjdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006.05.20 15:21:00 +0800, Xin LI wrote: > Here is an implementation of what I call it "skeleton jail". The idea > is that it is more or less to be common that we do not want to actually > copy of the base system (sometimes even other stuff) across zillions of > jails. Hey, Good to see more people thinking about this topic :-). Some time ago I "designed" a similar system [1] which I named Service Jails, though I did it the other way around wrt. the RO nullfs part (which you might be aware of since I was CC'ed :-) ). The big difference compared to what you describe, and to what ezjail uses, is that Service Jails has a shared directory mounted RO at the root of the jail and then a RW part mounted under /s inside the jail and the shared root had apropriate symlinks for directories which should be RW inside the jail. This turned out to have some drawbacks, since it really requires a raw partition per jail, which can be somewhat troublesome to manage. And probably more trouble than it's worth in most cases. Nullfs read-write or a vnode backed md(4) device could be use, but I'm not too keen on either of those if I can avoid them. (I mainly included this description to give a bit of thought to different ways to implement light weight jails.) [1] http://simon.nitro.dk/service-jails.html > The skeleton jail is an approach that makes management of such jails > easier, by making use of mount_nullfs(8) to make read-only shadow or > read-write shadow from the so-called "skeleton root". >=20 > For instance, by default the skeleton jail would mount the following > directories from the skeleton root (/) to the jail: What is the advantage to making that many mounts compared to making one mount and then symlinking, like ez-jail does? > In order to create the environment that is suitable for the skeleton > jail (say, create the directory hierarchy, populate the /etc/ stuff, > etc, but not the actual installworld), I have added a new target > "installskel" to src/Makefile which will help the work. As Ruslan noted, installskel seems a bit redundant compared to just using "make distribution". > There are four variables that can be set in either system level default > or per-jail way: >=20 > - _skel_enable > Whether to raise the jail from a skeleton root. The default is NO > - _skel_root > The place of skeleton root. The default is "/" > - _skel_romounts > Which directories (relative to the skeleton root) should be mounted > read-only to the skeleton jail. The default is shown above. > - _skel_rwmounts > Which directories (relative to the skeleton root) should be mounted > read-write to the skeleton jail. The default is nothing, but a > potential useful option might be "/usr/ports", except for security > concerns. As Dirk Engling noted there really isn't any reason to mount /usr/ports RW. > To try out the patch: >=20 > - Apply the patch. > - Do a full "make buildworld" and potentially "make installworld" so > that your system is fresh. > - Install the patched jail script into /etc/rc.d/ (e.g. can be done > with rm /etc/rc.d/jail && mergemaster -i) > - Create a directory, i.e. "/vhosts/skeltest" > - Do a "make installskel DESTDIR=3D/vhosts/skeltest" > - Add the following stuff into /etc/rc.conf: > jail_enable=3D"YES" > jail_list=3D"skeltest" >=20 > jail_skeltest_rootdir=3D"/vhosts/skeltest" > jail_skeltest_hostname=3D"skeltest.example.com" > jail_skeltest_ip=3D"127.0.0.1" > jail_skeltest_devfs_enable=3D"YES" > jail_skeltest_exec=3D"/bin/sh /etc/rc" >=20 > - Do a "/etc/rc.d/jail start skeltest" or reboot to see the jail up. >=20 > Comments? I would really like to see better support for light-weight jails in the base systems, especially since I'm using it more and more (this mail will bass through one such system :-) ). I think it would be better to simply use symlinks and then include a single RO mount like ez-jail does since you avoid having as many mount points. I think using symlinks could be created on demand like below, though it is of cause a bit more work since you need to handle creating /usr. What do you think of this approach? Personally I like the part of just including the list of magic shared directories in rc.conf since I think it's simpler to manager in the long term compared to a bunch of fstab.$jail files. This also makes it simpler to include per jail special mounts in fstab.$jail. [...] > --- etc/rc.d/jail 11 May 2006 14:23:43 -0000 1.32 > +++ etc/rc.d/jail 20 May 2006 06:53:10 -0000 > @@ -68,6 +68,16 @@ > eval _flags=3D\"\${jail_${_j}_flags:-${jail_flags}}\" > [ -z "${_flags}" ] && _flags=3D"-l -U root" > =20 > + # Default settings for skel jail > + eval _skel_enable=3D\"\${jail_${_j}_skel_enable:-${jail_skel_enable}}\" > + [ -z "${_skel_enable}" ] && _skel_enable=3D"NO" > + eval _skel_root=3D\"\${jail_${_j}_skel_root:-${jail_skel_root}}\" > + [ -z "${_skel_root}" ] && _skel_root=3D"/" > + eval _skel_romounts=3D\"\${jail_${_j}_skel_romounts:-${jail_skel_romoun= ts}}\" > + [ -z "${_skel_romounts}" ] && _skel_romounts=3D"bin sbin lib libexec us= r/bin usr/sbin usr/include usr/lib usr/libdata usr/libexec usr/sbin usr/sha= re" Shouldn't this rather be taken from defaults/rc.conf rather than being hardcoded? [...] > @@ -152,6 +166,20 @@ > [ -f "${_fstab}" ] || warn "${_fstab} does not exist" > umount -a -F "${_fstab}" >/dev/null 2>&1 > fi > + if checkyesno _skel_enable; then > + for _mntpt in $_skel_romounts > + do > + if [ -d "${_rootdir}/${_mntpt}" ] ; then > + umount -f ${_rootdir}/${_mntpt} > /dev/null 2>&1 > + fi > + done > + for _mntpt in $_skel_rwmounts > + do > + if [ -d "${_rootdir}/${_mntpt}" ] ; then > + umount -f ${_rootdir}/${_mntpt} > /dev/null 2>&1 > + fi > + done > + fi I think these two loops could just be merged like: for _mntpt in $_skel_romounts $_skel_rwmounts or? --=20 Simon L. Nielsen --OZkY3AIuv2LYvjdk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEb1QVh9pcDSc1mlERAglhAJoDoIUGtOl99kcBmzDN75tLo5ZUGQCglje5 wAct7635YwagYyV+oXoVzBE= =ylXr -----END PGP SIGNATURE----- --OZkY3AIuv2LYvjdk--