From owner-freebsd-current@FreeBSD.ORG Sun May 30 14:44:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5932816A4CE; Sun, 30 May 2004 14:44:26 -0700 (PDT) Received: from cakebox.homeunix.net (stgt-d9bb3842.pool.mediaWays.net [217.187.56.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EF3343D49; Sun, 30 May 2004 14:44:24 -0700 (PDT) (envelope-from freebsd@nagilum.org) Received: from localhost (localhost [127.0.0.1]) by cakebox.homeunix.net (Postfix) with ESMTP id CB40C3F9E5B; Sun, 30 May 2004 17:26:15 +0200 (CEST) Received: from cakebox.homeunix.net ([127.0.0.1]) by localhost (cakebox.tis [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23968-06; Sun, 30 May 2004 17:26:07 +0200 (CEST) Received: from nagilum.org (scorpio.tis [10.1.1.4]) by cakebox.homeunix.net (Postfix) with ESMTP id 7A0FA3F9D53; Sun, 30 May 2004 17:26:04 +0200 (CEST) Message-ID: <40B9FD0F.1070304@nagilum.org> Date: Sun, 30 May 2004 17:26:07 +0200 From: Nagilum User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5.1) Gecko/20031120 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: <20040530120314.BB9CF43D31@mx1.FreeBSD.org> In-Reply-To: <20040530120314.BB9CF43D31@mx1.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at tis X-Mailman-Approved-At: Mon, 31 May 2004 05:08:50 -0700 cc: ports@freebsd.org cc: current@freebsd.org Subject: Re: /usr/local/etc/rc.conf & rcorder X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2004 21:44:26 -0000 Danny Braniss wrote: >>On Sat, 29 May 2004, Patrick Tracanelli wrote: >> >> >>>I remember it has been discussed before, but the terms were a little bit >>>different, so tell me, isn't it appropriate rc.subr to suck the >>>configuration parameters from /usr/local/etc/rc.conf instead of >>>/etc/rc.conf when running startupscripts for third party applications >>>(/usr/local/etc/rc.d/)? >>> >>>To keep the organization principles, I dislike putting those >>>instructions into /etc/rc.conf when it should be read by 3rd party apps, >>>since I consider /etc/ to be used by the base system. Altho' old style >>>.sh scripts are still usefull under ${local_startup} dirs, ports >>>maintainers tend to write new style rc scripts that uses rc.subr to read >>>the user defined options (usually via /etc/rc.conf). >>> >>>Easy solution would be >>> >>>rc_conf_files="/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.conf" >>> >>>into /etc/rc.conf, but it seems to be ignored by rc.subr when it's not >>>at /etc/defaults/rc.conf; >>> >>>Some 3rd party startupscripts read rc.subr from /usr/local/etc/, so if >>>it suck only ${PREFIX}/etc/rc.conf options, would force users to >>>configure it in the right place, but it would break POLA and since some >>>scripts read /etc/rc.subr instead if ${PREFIX}/etc/rc.subr, would also >>>break some ports (very very bad idea). >>> >>>So, to allow ports startupscript to be configured from >>>/usr/local/etc/rc.conf but also prevent people who are today used to mix >>>everything in /etc/rc.conf from having their app. not starting, defining >>> >>>rc_conf_files="/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.conf" >>> >>>into /etc/defaults/rc.conf would just do it, nothing would break and >>>port's pkg-message could start trying to educate users to populate >>>/usr/local/etc/rc.conf for ports startup options and leaving >>>/etc/rc.conf only for the base system... >>> >>> >>Having multiple locations for system startup parameters (A là Windows) is >>a maintenance headache even when there's a logical method to the >>madness. I'm saying this as the admin of 6 racks packed with 1U and 2U >>machines. Be gentle... ;) >> >> >> > >and some of us (i hope more than one), have /usr/local shared among many. > >danny > > > > Hi, I strongly support Patricks original proposal, as for the replies, this would not interfere with your usual way of doing things, you could still keep your ports startup options in /etc/rc.conf it would make no difference. But give (optionally) a better separation of base and ports. The settings may or may not be exported throught /usr/local/ to other hosts, the decision would be up to the admin as changes to rc.conf are (nearly) always made manually. However while we're at it I also would like to propose the use of rcorder for /usr/local/etc/rc.d/. There are certain ports that use number prefixes to try to ensure proper startup order (e.g. mysql-client or pkgtools, see the discussion prio the introduction of rcorder for why this is suboptimal) however as we already have a working solution for this problem it is only matter of using it, the required change would be minimal: bash-2.05b# diff -Naur bash-2.05b# diff -Naur \ /usr/src/etc/rc.d/localdaemons /etc/rc.d/localdaemons --- /usr/src/etc/rc.d/localdaemons Mon May 5 17:38:41 2003 +++ localdaemons Sat Nov 1 17:11:57 2003 @@ -29,7 +29,7 @@ fi for dir in ${local_startup}; do if [ -d "${dir}" ]; then - for script in ${dir}/*.sh; do + for script in `rcorder ${dir}/*.sh 2>/dev/null`; do slist="${slist}${script_name_sep}${script}" done fi (Replace localdaemons with localpkg for newer system.) There are certain ports (such as bacula) that would definatly profit from this (e.g. all ports that require mysql/pgsql to be running, while beeing started) Kind regards, Alex.