From owner-freebsd-rc@FreeBSD.ORG Mon Nov 28 11:02:49 2005 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 CAA9416A41F for ; Mon, 28 Nov 2005 11:02:49 +0000 (GMT) (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 003A943D75 for ; Mon, 28 Nov 2005 11:02:17 +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.3/8.13.3) with ESMTP id jASB2Bx5088282 for ; Mon, 28 Nov 2005 11:02:11 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jASB2BKY088276 for freebsd-rc@freebsd.org; Mon, 28 Nov 2005 11:02:11 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Nov 2005 11:02:11 GMT Message-Id: <200511281102.jASB2BKY088276@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, 28 Nov 2005 11:02:49 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/02/10] conf/77340 rc awk used in /etc/rc.d/nsswitch when not a 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/06/30] conf/68525 rc Loader's verbose boot mode has rc.d/local o [2004/07/07] conf/68745 rc /etc/rc.d/devfs runs after ntpd so links o [2005/05/14] kern/81006 rc ipnat not working with tunnel interfaces 3 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon Nov 28 14:08:13 2005 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 E3A8616A41F for ; Mon, 28 Nov 2005 14:08:13 +0000 (GMT) (envelope-from spawk@acm.poly.edu) Received: from exodus.poly.edu (exodus.poly.edu [128.238.9.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 91AF243D58 for ; Mon, 28 Nov 2005 14:08:13 +0000 (GMT) (envelope-from spawk@acm.poly.edu) Received: (qmail 7614 invoked from network); 28 Nov 2005 14:08:21 -0000 Received: from unknown (HELO ?10.0.0.155?) (128.238.64.31) by exodus.poly.edu with SMTP; 28 Nov 2005 14:08:21 -0000 Message-ID: <438B0F2D.2050106@acm.poly.edu> Date: Mon, 28 Nov 2005 09:07:41 -0500 From: Boris Kochergin User-Agent: Thunderbird 1.5 (X11/20051117) MIME-Version: 1.0 To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: GRE tunnel on startup with rc.conf 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, 28 Nov 2005 14:08:14 -0000 Hi, Is there a way to configure GRE tunnels on startup via rc.conf? I didn't find anything in the man page or in /etc/defaults/rc.conf. -Boris From owner-freebsd-rc@FreeBSD.ORG Wed Nov 30 07:26:26 2005 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 3BBE616A41F for ; Wed, 30 Nov 2005 07:26:26 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 352AE43D66 for ; Wed, 30 Nov 2005 07:26:25 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 19448 invoked by uid 399); 30 Nov 2005 07:24:24 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 30 Nov 2005 07:24:24 -0000 Message-ID: <438D53A7.60507@FreeBSD.org> Date: Tue, 29 Nov 2005 23:24:23 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Adding /usr/local/etc/rc.d to the base rcorder 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: Wed, 30 Nov 2005 07:26:26 -0000 Howdy, The idea to incorporate the scripts in the local startup directories (currently defined as /usr/local/etc/rc.d /usr/X11R6/etc/rc.d, or substitute whatever your PREFIX/LOCALBASE/X11BASE is), into the overall rcorder that the scripts in /etc/rc.d follow has been around basically since the new rc.d framework was introduced, but has been very difficult to implement. A thread on the freebsd-rc list back in June discussed the ramifications of this change, and how it might possibly be implemented safely. Since then, I've put together a set of patches that implement one approach to this change. Now that 6.0-RELEASE is done, I'd like to move fairly quickly in implementing this in HEAD, and once the bogons are shaken out, I'd like to MFC it to RELENG_6 prior to 6.1-RELEASE. I want to point out several things at the outset. This is _one_ possible approach to this problem. One that I believe will work well, and minimizes the pain of the transition. However, I am not necessarily tied into every detail of my patch, or even the approach generally. However, we need to move forward on this, and without compelling reasons to do things differently, I am confident that this approach will work. 1. In order for this to work, we need to first get the disks mounted. (Thanks to Brooks for this, and other important insights). Therefore I'm proposing that we split the rcorder function into two parts, one "early" stage that takes care of everything up to mountcritremote; then redo rcorder, skipping the scripts that were done in the early stage, and incorporating the scripts in /usr/local/etc/rc.d, etc. This is not a "perfect" approach, as theoretically some cases where a local package might want to insert itself into rcorder before mountcritremote, however given the various tradeoffs we have to make (for example, diskless booting), this is at least a reasonable place to start. Compare http://people.freebsd.org/~dougb/rcorder.all and http://people.freebsd.org/~dougb/rcorder.early to see how the ordering as it exists in HEAD at the moment would be affected. Of 127 scripts, 52 would be in the early stage. (/etc/rc.d/tmp is being forced into the early stage by my patch in order to avoid non-deterministic behavior when local scripts are added to rcorder. This could just as easily be forced into the late stage.) My method for implementing the distinction between the early boot stage and the later is derived from an idea suggested by J.R. Oldroyd. It stops processing in the early stage once mountcritremote is done. The "late" stage first finds scripts in the local directories, then runs rcorder again over both lists. It starts processing after mountcritremote is reached. 2. The next aspect of this plan is how to manage the transition for the ports. There are two phases to this. First, adding code to /etc/rc (and rc.subr) to pick up those scripts in local_startup that are ready to be added to rcorder. This is done by grep'ing for '^# PROVIDE:' in the script. This method is not entirely foolproof, as for example the cups.sh startup script is (from our perspective) an "old style" script, however it contains the PROVIDE line for NetBSD's purposes. Thus, some care will have to be taken during the transition period to avoid problems. By my count, there are roughly 640 ports that install some sort of startup script. Of these, roughly 345 have transitioned to the new style of rc.d scripts (based on the presence of USE_RCORDER/USE_RC_SUBR in the Makefile). Thus, there are roughly 300 ports with scripts that would _potentially_ have problems. Of these, I'm confident that the vast majority would work without modification, as the number of possibly fatal error conditions are very small. The situation with cups.sh above is the only one I've encountered, but there may be others. There are two more potential problems with the new style scripts that are already in the ports tree. First, there are probably some scripts that have errors in them that will not be exposed until they are run within the rcorder context. The other problems that are almost sure to arise are scripts whose ordering needs to be adjusted (via REQUIRE/BEFORE, etc.). These things will need to happen in order for the transition to be successful in any case, so although it is sure to be a non-zero amount of work, it's work that will have to be done regardless of what method is chosen to incorporate the local_startup scripts into rcorder. The other part of this transition is to modify the localpkg script. This is done using some ideas and code from J.R. Oldroyd. Brooks, and myself. First we sort out the scripts that start with a number (like 000.foo.sh) and run them in numerical order, as a lot of work has gone into this style of ordering already. Then we run the scripts that start with a letter. The original idea here was to use rcorder in localpkg, however in my testing I found that it's simpler to just run the new style scripts in the base rcorder, and run everything else in localpkg. Therefore, the function that searches for these scripts eliminates any that use the new rc.d style first. These changes dramatically simplify the localpkg script. 3. The last part of this proposal is to apply the same changes to how we pick up local scripts in rc to the shutdown process, both in rc.shutdown and in localpkg. My patch to implement all this is at http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-rc@FreeBSD.ORG Wed Nov 30 08:04:49 2005 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 42D7F16A420 for ; Wed, 30 Nov 2005 08:04:49 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 8457343D53 for ; Wed, 30 Nov 2005 08:04:48 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 54404 invoked by uid 399); 30 Nov 2005 08:04:47 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 30 Nov 2005 08:04:47 -0000 Message-ID: <438D5D1E.1030502@FreeBSD.org> Date: Wed, 30 Nov 2005 00:04:46 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org References: <438D53A7.60507@FreeBSD.org> In-Reply-To: <438D53A7.60507@FreeBSD.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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: Wed, 30 Nov 2005 08:04:49 -0000 My apologies if this is a duplicate, I seem to be having some mail problems, and I wasn't sure that this message was delivered to the list (mostly because I thought if it had been, I'd have heard a response by now). :) Doug -- This .signature sanitized for your protection From owner-freebsd-rc@FreeBSD.ORG Wed Nov 30 09:00:59 2005 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 4B2DE16A420 for ; Wed, 30 Nov 2005 09:00:59 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id B381743D64 for ; Wed, 30 Nov 2005 09:00:21 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 10920 invoked by uid 399); 29 Nov 2005 11:13:38 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 29 Nov 2005 11:13:38 -0000 Message-ID: <438C37E1.6010600@FreeBSD.org> Date: Tue, 29 Nov 2005 03:13:37 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-rc@FreeBSD.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Adding /usr/local/etc/rc.d to the base rcorder 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: Wed, 30 Nov 2005 09:00:59 -0000 Howdy, The idea to incorporate the scripts in the local startup directories (currently defined as /usr/local/etc/rc.d /usr/X11R6/etc/rc.d, or substitute whatever your PREFIX/LOCALBASE/X11BASE is), into the overall rcorder that the scripts in /etc/rc.d follow has been around basically since the new rc.d framework was introduced, but has been very difficult to implement. A thread on the freebsd-rc list back in June discussed the ramifications of this change, and how it might possibly be implemented safely. Since then, I've put together a set of patches that implement one approach to this change. Now that 6.0-RELEASE is done, I'd like to move fairly quickly in implementing this in HEAD, and once the bogons are shaken out, I'd like to MFC it to RELENG_6 prior to 6.1-RELEASE. I want to point out several things at the outset. This is _one_ possible approach to this problem. One that I believe will work well, and minimizes the pain of the transition. However, I am not necessarily tied into every detail of my patch, or even the approach generally. However, we need to move forward on this, and without compelling reasons to do things differently, I am confident that this approach will work. 1. In order for this to work, we need to first get the disks mounted. (Thanks to Brooks for this, and other important insights). Therefore I'm proposing that we split the rcorder function into two parts, one "early" stage that takes care of everything up to mountcritremote; then redo rcorder, skipping the scripts that were done in the early stage, and incorporating the scripts in /usr/local/etc/rc.d, etc. This is not a "perfect" approach, as theoretically some cases where a local package might want to insert itself into rcorder before mountcritremote, however given the various tradeoffs we have to make (for example, diskless booting), this is at least a reasonable place to start. Compare http://people.freebsd.org/~dougb/rcorder.all and http://people.freebsd.org/~dougb/rcorder.early to see how the ordering as it exists in HEAD at the moment would be affected. Of 127 scripts, 52 would be in the early stage. (/etc/rc.d/tmp is being forced into the early stage by my patch in order to avoid non-deterministic behavior when local scripts are added to rcorder. This could just as easily be forced into the late stage.) My method for implementing the distinction between the early boot stage and the later is derived from an idea suggested by J.R. Oldroyd. It stops processing in the early stage once mountcritremote is done. The "late" stage first finds scripts in the local directories, then runs rcorder again over both lists. It starts processing after mountcritremote is reached. 2. The next aspect of this plan is how to manage the transition for the ports. There are two phases to this. First, adding code to /etc/rc (and rc.subr) to pick up those scripts in local_startup that are ready to be added to rcorder. This is done by grep'ing for '^# PROVIDE:' in the script. This method is not entirely foolproof, as for example the cups.sh startup script is (from our perspective) an "old style" script, however it contains the PROVIDE line for NetBSD's purposes. Thus, some care will have to be taken during the transition period to avoid problems. By my count, there are roughly 640 ports that install some sort of startup script. Of these, roughly 345 have transitioned to the new style of rc.d scripts (based on the presence of USE_RCORDER/USE_RC_SUBR in the Makefile). Thus, there are roughly 300 ports with scripts that would _potentially_ have problems. Of these, I'm confident that the vast majority would work without modification, as the number of possibly fatal error conditions are very small. The situation with cups.sh above is the only one I've encountered, but there may be others. There are two more potential problems with the new style scripts that are already in the ports tree. First, there are probably some scripts that have errors in them that will not be exposed until they are run within the rcorder context. The other problems that are almost sure to arise are scripts whose ordering needs to be adjusted (via REQUIRE/BEFORE, etc.). These things will need to happen in order for the transition to be successful in any case, so although it is sure to be a non-zero amount of work, it's work that will have to be done regardless of what method is chosen to incorporate the local_startup scripts into rcorder. The other part of this transition is to modify the localpkg script. This is done using some ideas and code from J.R. Oldroyd. Brooks, and myself. First we sort out the scripts that start with a number (like 000.foo.sh) and run them in numerical order, as a lot of work has gone into this style of ordering already. Then we run the scripts that start with a letter. The original idea here was to use rcorder in localpkg, however in my testing I found that it's simpler to just run the new style scripts in the base rcorder, and run everything else in localpkg. Therefore, the function that searches for these scripts eliminates any that use the new rc.d style first. These changes dramatically simplify the localpkg script. 3. The last part of this proposal is to apply the same changes to how we pick up local scripts in rc to the shutdown process, both in rc.shutdown and in localpkg. My patch to implement all this is at http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-rc@FreeBSD.ORG Thu Dec 1 00:35:26 2005 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 48F5016A41F; Thu, 1 Dec 2005 00:35:26 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B88FD43D6B; Thu, 1 Dec 2005 00:35:25 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id jB10ZPEW000787; Wed, 30 Nov 2005 16:35:25 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jB10ZPdY000785; Wed, 30 Nov 2005 16:35:25 -0800 Date: Wed, 30 Nov 2005 16:35:25 -0800 From: Brooks Davis To: Doug Barton Message-ID: <20051201003525.GB21393@odin.ac.hmc.edu> References: <438C37E1.6010600@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <438C37E1.6010600@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-rc@freebsd.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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, 01 Dec 2005 00:35:26 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: > My patch to implement all this is at > http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. This looks pretty good to me. Thanks for working on this. A few comments: - I have this vague feeling that we should replace most dependencies on mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. This isn't important. :) - Is the exclusion of *.sample sufficient? We obviously don't want to be too broad, but I'd be inclined to include .bak, .orig, and maybe .sav for now. - I'm worried about including .sh scripts in the new list during the transition period. It seems likely that is going to cause significant pain. - When do we want to start complaining about old scripts? One idea is to first ban them in ports and have Kris add a check for them on the ports cluster followed by enabling a warning in the startup scripts. Other policies are possible. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDjkVLXY6L6fI4GtQRAgTkAJ9HDmT3fgLM5LUZMKQl0W+6mIjIrACgz2sN 7TaaSoq5aoTrU3g+4AvRRhA= =qqcP -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-rc@FreeBSD.ORG Thu Dec 1 01:20:14 2005 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 57A9E16A44A for ; Thu, 1 Dec 2005 01:20:14 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id C82B743D55 for ; Thu, 1 Dec 2005 01:20:13 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 4988 invoked by uid 399); 1 Dec 2005 01:20:12 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 1 Dec 2005 01:20:12 -0000 Message-ID: <438E4FCB.8060806@FreeBSD.org> Date: Wed, 30 Nov 2005 17:20:11 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> In-Reply-To: <20051201003525.GB21393@odin.ac.hmc.edu> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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, 01 Dec 2005 01:20:14 -0000 Brooks Davis wrote: > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: > >>My patch to implement all this is at >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. > > > This looks pretty good to me. Thanks for working on this. No problem. I had a feeling you'd like the fact that I dropped all that keyword stuff. :) > A few comments: > > - I have this vague feeling that we should replace most dependencies on > mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. > This isn't important. :) Right, this can be revisited later if needed. The more I thought about this the more I liked the concept of what JR suggested, although obviously I implemented it in a slightly different manner. I'm hesitant to add more pseudo-targets, as I think using mountcritremote is a good "clear bright line" for this purpose. I also have a fantasy down the road (not sure how to implement it yet) of making the point to split early/late configurable. For example, I can imagine a scenario where someone might want to put the split at mountcritlocal. However, this is a good safe place to start. > - Is the exclusion of *.sample sufficient? We obviously don't want to > be too broad, but I'd be inclined to include .bak, .orig, and maybe > .sav for now. Heh, that's the opposite of what you said last time. :) I actually decided to take your advice and take all the pain up front. I think if we start with this in HEAD, and give people sufficient warning, we can handle the problem cases pretty easily. And of course, if I'm wrong, this is also easily fixed. > - I'm worried about including .sh scripts in the new list during the > transition period. It seems likely that is going to cause significant > pain. Once again, I hope not, but this is the area where I have the most concern. My post was pretty long already, so I cut the section where I discussed the relative virtues of foo vs. foo.sh, but one thing I do plan to offer port authors is help with installing their scripts as foo instead of foo.sh if OSVERSION is > N, where we can slide N down through 610000 at least. At some point (years down the road obviously) when we've dropped support for RELENG_5 in ports, this can all be removed. I'm still ambivalent about whether to backport this into RELENG_5 btw. On the one hand it wouldn't be too hard to do, but on the other hand I'd like to do everything I can to convince people of the value of moving to RELENG_6 asap. Thoughts on this topic are welcome. > - When do we want to start complaining about old scripts? One idea is > to first ban them in ports and have Kris add a check for them on the > ports cluster followed by enabling a warning in the startup scripts. My feeling is that we probably want to deprecate them in 7-Stable, and stop supporting them in 8-Stable, but I'm open to suggestions here too. Doug -- This .signature sanitized for your protection From owner-freebsd-rc@FreeBSD.ORG Fri Dec 2 08:06:19 2005 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 BC97316A41F; Fri, 2 Dec 2005 08:06:19 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A8B743D83; Fri, 2 Dec 2005 08:06:13 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jB2868kT012804; Fri, 2 Dec 2005 11:06:08 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jB2865tK012803; Fri, 2 Dec 2005 11:06:05 +0300 (MSK) (envelope-from yar) Date: Fri, 2 Dec 2005 11:06:05 +0300 From: Yar Tikhiy To: Doug Barton Message-ID: <20051202080604.GA12291@comp.chem.msu.su> References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> <438E4FCB.8060806@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438E4FCB.8060806@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-rc@freebsd.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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, 02 Dec 2005 08:06:19 -0000 On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote: > > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: > > > >>My patch to implement all this is at > >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. > > > > > > This looks pretty good to me. Thanks for working on this. Please accept my appreciation of your efforts, too! > > A few comments: > > > > - I have this vague feeling that we should replace most dependencies on > > mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. > > This isn't important. :) > > Right, this can be revisited later if needed. The more I thought about this > the more I liked the concept of what JR suggested, although obviously I > implemented it in a slightly different manner. I'm hesitant to add more > pseudo-targets, as I think using mountcritremote is a good "clear bright > line" for this purpose. I also have a fantasy down the road (not sure how to > implement it yet) of making the point to split early/late configurable. For > example, I can imagine a scenario where someone might want to put the split > at mountcritlocal. However, this is a good safe place to start. With a pseudo-target for filesystems, will we still need the split hardcoded in /etc/rc? Using a single run of rcorder should be sufficient if all our rc.d scripts specify correct interdependencies between each other. Using the pseudo-target would be a natural way of doing so while keeping the possibility to move the split up and down the boot sequence. -- Yar From owner-freebsd-rc@FreeBSD.ORG Fri Dec 2 08:15:17 2005 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 DA21916A41F for ; Fri, 2 Dec 2005 08:15:17 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D57943D62 for ; Fri, 2 Dec 2005 08:15:14 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id jB28ErNj013354; Fri, 2 Dec 2005 11:14:53 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id jB28Ertn013353; Fri, 2 Dec 2005 11:14:53 +0300 (MSK) (envelope-from yar) Date: Fri, 2 Dec 2005 11:14:53 +0300 From: Yar Tikhiy To: Boris Kochergin Message-ID: <20051202081452.GB12291@comp.chem.msu.su> References: <438B0F2D.2050106@acm.poly.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438B0F2D.2050106@acm.poly.edu> User-Agent: Mutt/1.5.9i Cc: freebsd-rc@freebsd.org Subject: Re: GRE tunnel on startup with rc.conf 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, 02 Dec 2005 08:15:18 -0000 On Mon, Nov 28, 2005 at 09:07:41AM -0500, Boris Kochergin wrote: > > Is there a way to configure GRE tunnels on startup via rc.conf? I didn't > find anything in the man page or in /etc/defaults/rc.conf. gre(4) is just another pseudo interface, cloneable and configurable with ifconfig(8): # begin rc.conf snippet cloned_interfaces="gre0" ifconfig_gre0="inet 1.1.1.1 2.2.2.2 tunnel 3.3.3.3 4.4.4.4 up" # end rc.conf snippet See gre(4) for some implementation caveats. -- Yar From owner-freebsd-rc@FreeBSD.ORG Fri Dec 2 16:41:20 2005 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 98CFD16A41F; Fri, 2 Dec 2005 16:41:20 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E955E43D5E; Fri, 2 Dec 2005 16:41:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id jB2GZeVt023577; Fri, 2 Dec 2005 08:35:40 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jB2GZdLQ023576; Fri, 2 Dec 2005 08:35:39 -0800 Date: Fri, 2 Dec 2005 08:35:39 -0800 From: Brooks Davis To: Yar Tikhiy Message-ID: <20051202163539.GA22464@odin.ac.hmc.edu> References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> <438E4FCB.8060806@FreeBSD.org> <20051202080604.GA12291@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20051202080604.GA12291@comp.chem.msu.su> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-rc@freebsd.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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, 02 Dec 2005 16:41:20 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2005 at 11:06:05AM +0300, Yar Tikhiy wrote: > On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote: > > > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: > > >=20 > > >>My patch to implement all this is at > > >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are wel= come. > > >=20 > > >=20 > > > This looks pretty good to me. Thanks for working on this.=20 >=20 > Please accept my appreciation of your efforts, too! >=20 > > > A few comments: > > >=20 > > > - I have this vague feeling that we should replace most dependencies = on > > > mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. > > > This isn't important. :) > >=20 > > Right, this can be revisited later if needed. The more I thought about = this > > the more I liked the concept of what JR suggested, although obviously I > > implemented it in a slightly different manner. I'm hesitant to add more > > pseudo-targets, as I think using mountcritremote is a good "clear bright > > line" for this purpose. I also have a fantasy down the road (not sure h= ow to > > implement it yet) of making the point to split early/late configurable.= For > > example, I can imagine a scenario where someone might want to put the s= plit > > at mountcritlocal. However, this is a good safe place to start. >=20 > With a pseudo-target for filesystems, will we still need the split > hardcoded in /etc/rc? Using a single run of rcorder should be > sufficient if all our rc.d scripts specify correct interdependencies > between each other. Using the pseudo-target would be a natural way > of doing so while keeping the possibility to move the split up and > down the boot sequence. You have to run rccorder twice because until mountcritremote (or an equivalent pseudo target) you aren't garenteed to have access to all the files rcorder needs to parse. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDkHfYXY6L6fI4GtQRApflAJ41qHUEghnbPbxFqybcBjSrCFv68wCgnrQk zraBHpofzYOSRTt6qI4QHys= =nEaA -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-freebsd-rc@FreeBSD.ORG Fri Dec 2 17:22:17 2005 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 A46F016A41F; Fri, 2 Dec 2005 17:22:17 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C46A243D66; Fri, 2 Dec 2005 17:22:07 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id jB2HM62x028912; Fri, 2 Dec 2005 09:22:06 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jB2HM6WG028911; Fri, 2 Dec 2005 09:22:06 -0800 Date: Fri, 2 Dec 2005 09:22:06 -0800 From: Brooks Davis To: Doug Barton Message-ID: <20051202172206.GC22464@odin.ac.hmc.edu> References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> <438E4FCB.8060806@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <438E4FCB.8060806@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-rc@FreeBSD.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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, 02 Dec 2005 17:22:17 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote: > Brooks Davis wrote: > > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: > >=20 > >>My patch to implement all this is at > >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welco= me. > >=20 > >=20 > > This looks pretty good to me. Thanks for working on this.=20 >=20 > No problem. I had a feeling you'd like the fact that I dropped all that > keyword stuff. :) >=20 > > A few comments: > >=20 > > - I have this vague feeling that we should replace most dependencies on > > mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. > > This isn't important. :) >=20 > Right, this can be revisited later if needed. The more I thought about th= is > the more I liked the concept of what JR suggested, although obviously I > implemented it in a slightly different manner. I'm hesitant to add more > pseudo-targets, as I think using mountcritremote is a good "clear bright > line" for this purpose. I also have a fantasy down the road (not sure how= to > implement it yet) of making the point to split early/late configurable. F= or > example, I can imagine a scenario where someone might want to put the spl= it > at mountcritlocal. However, this is a good safe place to start. Ah, that makes sense. I do have to say that the names for the mount bit are misleading. mountcritlocal mounts everything local, not just important things and mountcritremote does the same. I like the idea of being able to start at mountcritlocal. That will actually be possible on almost all systems including all the diskless systems I build. > > - Is the exclusion of *.sample sufficient? We obviously don't want to > > be too broad, but I'd be inclined to include .bak, .orig, and maybe > > .sav for now. >=20 > Heh, that's the opposite of what you said last time. :) I actually decid= ed > to take your advice and take all the pain up front. I think if we start w= ith > this in HEAD, and give people sufficient warning, we can handle the probl= em > cases pretty easily. And of course, if I'm wrong, this is also easily fix= ed. >=20 > > - I'm worried about including .sh scripts in the new list during the > > transition period. It seems likely that is going to cause significant > > pain. >=20 > Once again, I hope not, but this is the area where I have the most concer= n. > My post was pretty long already, so I cut the section where I discussed t= he > relative virtues of foo vs. foo.sh, but one thing I do plan to offer port > authors is help with installing their scripts as foo instead of foo.sh if > OSVERSION is > N, where we can slide N down through 610000 at least. At s= ome > point (years down the road obviously) when we've dropped support for > RELENG_5 in ports, this can all be removed. My concern isn't switching port over, that's a fairly easy task. Instead, it's dealing with the transition period where every halfbaked already installed script in /usr/local/etc/rc.d has the opportunity to royally screw up the entire boot process by stomping on global variable since it's run as a .sh script. My concern is that we may end up having to require a "portupgrade -af" and that's going to be unacceptable on 6-STABLE. > I'm still ambivalent about whether to backport this into RELENG_5 btw. On > the one hand it wouldn't be too hard to do, but on the other hand I'd like > to do everything I can to convince people of the value of moving to RELEN= G_6 > asap. Thoughts on this topic are welcome. I agree that it's worth not doing the MFC just to push people toward RELENG_6. =20 > > - When do we want to start complaining about old scripts? One idea is > > to first ban them in ports and have Kris add a check for them on the > > ports cluster followed by enabling a warning in the startup scripts. >=20 > My feeling is that we probably want to deprecate them in 7-Stable, and st= op > supporting them in 8-Stable, but I'm open to suggestions here too. That sounds reasonable. My thought would be to MFC to 6 and then start griping about old style scripts in HEAD pretty much immediately. The real issue in my mind is actually not so much the transition in the base system as the transition in ports. That's really a policy question for portmgr. I'd personally like to see an immediate ban on non rc.subr scripts enforced by a test on the ports cluster and a round of marking problem ports BROKEN. That would probably fix things in a matter of weeks. After all, rc.subr scripts are easy to write and if there's a hugely complicated script that the maintainer doesn't want to convert, they can always install in over in libexec and wrap it with a simple rc.subr script. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --E13BgyNx05feLLmH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDkIK9XY6L6fI4GtQRAvX+AJ9XsaWDb69lxb703NT+29k4NKT3XgCgr3ph CeuM1nXreSMlIS/vRei5CU8= =2/VD -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From owner-freebsd-rc@FreeBSD.ORG Sat Dec 3 01:23:52 2005 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 20C6716A422 for ; Sat, 3 Dec 2005 01:23:52 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F0B043D46 for ; Sat, 3 Dec 2005 01:23:51 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 91441 invoked by uid 399); 3 Dec 2005 01:23:50 -0000 Received: from unknown (HELO ?192.168.0.5?) (dougb@dougbarton.net@127.0.0.1) by 127.0.0.1 with SMTP; 3 Dec 2005 01:23:50 -0000 Message-ID: <4390F3A5.2000300@FreeBSD.org> Date: Fri, 02 Dec 2005 17:23:49 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Brooks Davis References: <438C37E1.6010600@FreeBSD.org> <20051201003525.GB21393@odin.ac.hmc.edu> <438E4FCB.8060806@FreeBSD.org> <20051202172206.GC22464@odin.ac.hmc.edu> In-Reply-To: <20051202172206.GC22464@odin.ac.hmc.edu> X-Enigmail-Version: 0.93.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org Subject: Re: Adding /usr/local/etc/rc.d to the base rcorder 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, 03 Dec 2005 01:23:52 -0000 Brooks Davis wrote: > On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote: >> Brooks Davis wrote: >>> On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote: >>> >>>> My patch to implement all this is at >>>> http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome. >>> >>> This looks pretty good to me. Thanks for working on this. >> No problem. I had a feeling you'd like the fact that I dropped all that >> keyword stuff. :) >> >>> A few comments: >>> >>> - I have this vague feeling that we should replace most dependencies on >>> mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS. >>> This isn't important. :) >> Right, this can be revisited later if needed. The more I thought about this >> the more I liked the concept of what JR suggested, although obviously I >> implemented it in a slightly different manner. I'm hesitant to add more >> pseudo-targets, as I think using mountcritremote is a good "clear bright >> line" for this purpose. I also have a fantasy down the road (not sure how to >> implement it yet) of making the point to split early/late configurable. For >> example, I can imagine a scenario where someone might want to put the split >> at mountcritlocal. However, this is a good safe place to start. > > Ah, that makes sense. I do have to say that the names for the mount > bit are misleading. mountcritlocal mounts everything local, not just > important things and mountcritremote does the same. I like the idea of > being able to start at mountcritlocal. That will actually be possible > on almost all systems including all the diskless systems I build. I considered making mountcritlocal the starting point initially, however when looking at what gets started between it and mountcritremote, I decided that there weren't going to be a whole lot of ports that would want to insert themselves in between. As with all things, this can be revisited down the road if necessary. >>> - Is the exclusion of *.sample sufficient? We obviously don't want to >>> be too broad, but I'd be inclined to include .bak, .orig, and maybe >>> .sav for now. >> Heh, that's the opposite of what you said last time. :) I actually decided >> to take your advice and take all the pain up front. I think if we start with >> this in HEAD, and give people sufficient warning, we can handle the problem >> cases pretty easily. And of course, if I'm wrong, this is also easily fixed. I should also point out the rc.subr also excludes '*[~#]|*.OLD|*.orig|*,v', so I figured anything that was left was worth carping about. >>> - I'm worried about including .sh scripts in the new list during the >>> transition period. It seems likely that is going to cause significant >>> pain. >> Once again, I hope not, but this is the area where I have the most concern. >> My post was pretty long already, so I cut the section where I discussed the >> relative virtues of foo vs. foo.sh, but one thing I do plan to offer port >> authors is help with installing their scripts as foo instead of foo.sh if >> OSVERSION is > N, where we can slide N down through 610000 at least. At some >> point (years down the road obviously) when we've dropped support for >> RELENG_5 in ports, this can all be removed. > > My concern isn't switching port over, that's a fairly easy task. > Instead, it's dealing with the transition period where every halfbaked > already installed script in /usr/local/etc/rc.d has the opportunity to > royally screw up the entire boot process by stomping on global variable > since it's run as a .sh script. Yep, that's a big concern, but it's pain that is inevitable if we're ever going to make this transition. > My concern is that we may end up having > to require a "portupgrade -af" and that's going to be unacceptable on > 6-STABLE. Well, keep in mind that there are only about 650 ports that install startup scripts (by my count). If we get the ones that need fixing done, and versions rolled forward sooner rather than later, the RELENG_6 folks shouldn't feel too much of the pain, it will mostly have been worked out in HEAD. > The real issue in my mind is actually not so much the transition in the > base system as the transition in ports. That's really a policy question > for portmgr. I'd personally like to see an immediate ban on non rc.subr > scripts enforced by a test on the ports cluster and a round of marking > problem ports BROKEN. That would probably fix things in a matter of > weeks. After all, rc.subr scripts are easy to write and if there's a > hugely complicated script that the maintainer doesn't want to convert, > they can always install in over in libexec and wrap it with a simple > rc.subr script. Feel free to bring that suggestion up on the -ports list. :) I am hesitant to go that route simply because I don't like telling other developers, "Here is a whole big bunch o' work for you, have a nice day." I'm actually interested to see what will happen with the existing scripts that are named *.sh. I have 8 *.sh scripts in /usr/local/etc.rc.d, and only 1 failed. Assuming that this 12.5% failure rate is representative (and there is no evidence that it is), that's only 81.25 ports that need fixing, which leads me to believe that the transition can be gradual rather than abrupt, but at this point I think we'll just have to wait and see. Doug