Date: Sun, 30 May 2004 17:26:07 +0200 From: Nagilum <freebsd@nagilum.org> To: Danny Braniss <danny@cs.huji.ac.il> Cc: current@freebsd.org Subject: Re: /usr/local/etc/rc.conf & rcorder Message-ID: <40B9FD0F.1070304@nagilum.org> In-Reply-To: <20040530120314.BB9CF43D31@mx1.FreeBSD.org> References: <20040530120314.BB9CF43D31@mx1.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40B9FD0F.1070304>