On Sat, Oct 03, 2009 at 11:48:11PM +0200, Joerg Sonnenberger wrote: > I am consider to make the RC script support in pkgsrc a bit more useful > out of the box with the following changes: To avoid confusing, this is about NetBSD and PREFIX=/usr/pkg, other cases for left for the reader :) Joerg
On Oct 3, 2009, at 5:48 PM, Joerg Sonnenberger wrote: > Hi all, > I am consider to make the RC script support in pkgsrc a bit more > useful > out of the box with the following changes: > > (1) Install pkgsrc RC scripts by default into /etc/rc.pkg.d, not > /etc/rc.d and adjust the default value for rc_directories accordingly. > This keeps the logical separation between base and pkgsrc RC scripts > and still allows /usr (or /usr/pkg) to be on a separate filesystem. > > (2) Provide a default value of NO for the control variables. This > ensures that no stupid "Missing variable $foo" clutters up the boot > messages. > Both parts strike me as excellent ideas. However -- where will you put the default "NO" information? What about /etc/defaults/rc.pkg.conf? Thinking further -- perhaps we should have /etc/pkg, and under it rc.d, rc.conf, mk.conf, defaults/rc.conf, etc. --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Sat, Oct 03, 2009 at 06:13:03PM -0400, Steven Bellovin wrote:
> Both parts strike me as excellent ideas. However -- where will you
> put the default "NO" information? What about
> /etc/defaults/rc.pkg.conf?
Just inside the script, e.g.
gdm=${gdm:=NO}
after sourcing /etc/rc.subr.
That part is useful on all platforms and independent of the prefix.
Joerg
Robert Elz wrote: > | (1) Install pkgsrc RC scripts by default into /etc/rc.pkg.d, not > | /etc/rc.d and adjust the default value for rc_directories accordingly. > | This keeps the logical separation between base and pkgsrc RC scripts > > That's not a desirable goal. One directory of rc scripts makes sense, > multiple directories of rc scripts just leads to even more directories of > rc scripts, so as to "keep logical separation" - I agree completely. If I tried telling some of my colleagues that there were now two directories that rc scripts might be in, and there is no way to tell which scripts belong in which directory, they would tell me exactly where to go. Not only do you need a complete knowledge of either pkgsrc packages or the base rc scripts to know where the quagga startup script is installed, but for some software such as web servers you have to know whether it's the NetBSD httpd, or one of the many pkgsrc httpds. Many people on these mailing lists won't have a problem with this, but you shouldn't have to be a genius to administer NetBSD. You also run the risk of people thinking that the directories of rc scripts are run at different points in time just like SVR4 rc directories. The first thing I thought when the /etc/rc.d directory was created was "Good. Now we have the rc order calculated at boot time and everything is in one place. None of this crazy mess like SVR4 and Linux." Nice and simple. The pkgsrc system manages adding and removing shells, users and groups well. It can handle rc scripts in /etc/rc.d just as well. > | (2) Provide a default value of NO for the control variables. This > | ensures that no stupid "Missing variable $foo" clutters up the boot(Continue reading)
On Sat, 3 Oct 2009, Joerg Sonnenberger wrote: > (1) Install pkgsrc RC scripts by default into /etc/rc.pkg.d, not > /etc/rc.d and adjust the default value for rc_directories accordingly. > This keeps the logical separation between base and pkgsrc RC scripts > and still allows /usr (or /usr/pkg) to be on a separate filesystem. Sounds like your talking about changeing the default value of RCD_SCRIPTS_DIR. Personaly I would like config variables that are used by the +INSTALL +DEINSTALL script set in pkg_install.conf and passed to the scripts when thay get run. I know this would mean writing extra code in pkg_install but it would mean that the +INSTALL +DEINSTALL behaviour is defined when a binary package is installed not built. -- -- Steven
On Sun, 04 Oct 2009, Robert Elz wrote:
> | (2) Provide a default value of NO for the control variables. This
> | ensures that no stupid "Missing variable $foo" clutters up the
> | boot messages.
[...]
> After all, all the base system scripts have (or should have) their
> control variables in /etc/defaults/rc.conf so the test can really only
> be for add on scripts, which is mostly pkgsrc added scripts, if pkgsrc
> then defeats that by always defining the variables, the test has no
> purpose left, and may as well be rmeoved.
That test appeared in rc.subr revision 1.1 dated 1997-08-29.
/etc/default/rc.conf apepared on 2000-08-22, and moved to
/etc/defaults/rc.conf on 2000-10-01.
The test might have made sense for the base system back in the time
before /etc/defaults/rc.conf existed, when variables had to be set
excplicitly in /etc/rc.conf, but I don't think it makes sense for
the base system today, and the warnings for pkgsrc scripts annoyed
me enough that I removed the warning from my own rc.subr a long
time ago. I suggest that the warning
warn "\$${1} is not set properly - see ${rcvar_manpage}."
should be removed from the checkyesno function in the base system's
/etc.rc.subr.
Whether or not pkgsrc-supplied scripts leave their variables
undefined by default is a separate issue from whether or not rc.subr
warns about undefined variables. I don't care either way about
(Continue reading)
On Sun, 04 Oct 2009, Joerg Sonnenberger wrote: > One of the often voiced complains about installing the scripts > automatically is that it is hard to distinguish between components > from base and from pkgsrc. A comment at the top of the pkgsrc-supplied script could help. > In fact, using a separate directory for local additions makes a > lot of sense. The main point you seemed to have missed is that > mixing different management domains is not necessarily a good > idea. /etc/rc.d is normally managed by postinstall. The pkgsrc RC > scripts by pkgsrc. The local additions by yourself. A clean separation > makes the process easier. A clean separation makes the process easier in some ways, and more difficult in other ways; it also raises questions about how many separate directories to have. My preference is to leave them all in one directory. > > | ensures that no stupid "Missing variable $foo" clutters up the boot > > | messages. > > Changing rc.subr won't help on any system already released. The trivial > one line change to the RC scripts is self-contained. That argument works both ways: Changing pkgsrc RC scripts won't help systems that have already installed old packages. The trivial change to rc.subr is self-contained and benefits both old and new packages.(Continue reading)
At 19:56 Uhr +0700 4.10.2009, Robert Elz wrote:
> | (1) Install pkgsrc RC scripts by default into /etc/rc.pkg.d, not
> | /etc/rc.d and adjust the default value for rc_directories accordingly.
> | This keeps the logical separation between base and pkgsrc RC scripts
>
>That's not a desirable goal.
I'll have to second this. What applies to one /var and one /etc ("system
{state,config} in one place") applies to rc.d scripts. Spreading out start
scripts by arbitrary criteria violates POLA, and is not helpful for systems
maintenance.
At least, please make the new directory optional.
hauke
--
"It's never straight up and down" (DEVO)
On Sat, 3 Oct 2009, Joerg Sonnenberger wrote: > (2) Provide a default value of NO for the control variables. This > ensures that no stupid "Missing variable $foo" clutters up the boot > messages. Am I the only one that appreciates these messages? It seems like a simple reminder that I have a rc.d script that I should consider looking at.
On Mon, 5 Oct 2009 08:46:20 -0500 (CDT) "Jeremy C. Reed" <reed <at> reedmedia.net> wrote: > On Sat, 3 Oct 2009, Joerg Sonnenberger wrote: > > > (2) Provide a default value of NO for the control variables. This > > ensures that no stupid "Missing variable $foo" clutters up the boot > > messages. > > Am I the only one that appreciates these messages? It seems like a > simple reminder that I have a rc.d script that I should consider > looking at. > I agree. If I mistype the variable name for package foobar: FOOVAR=YES it will silently fail to start. Does it check now to see if it's "YES" or "NO"? If not, it should.
RSS Feed50 | |
|---|---|
158 | |
177 | |
130 | |
203 | |
111 | |
43 | |
104 | |
52 | |
125 | |
75 | |
72 | |
75 | |
64 | |
107 | |
140 | |
132 | |
34 | |
158 | |
170 | |
69 | |
108 | |
104 | |
64 | |
160 | |
115 | |
192 | |
133 | |
148 | |
179 | |
17 | |
142 | |
87 | |
88 | |
87 | |
81 | |
57 | |
136 | |
106 | |
94 | |
190 | |
48 | |
122 | |
196 | |
55 | |
114 | |
122 | |
201 | |
48 | |
94 | |
243 | |
177 | |
74 | |
66 | |
68 | |
81 | |
180 | |
191 | |
91 | |
159 | |
170 | |
178 | |
131 | |
77 | |
121 | |
129 | |
43 | |
145 | |
99 | |
84 | |
152 | |
76 | |
40 | |
39 | |
79 | |
147 | |
86 | |
138 | |
96 | |
240 | |
147 | |
112 | |
118 | |
55 | |
54 | |
72 | |
73 | |
17 | |
87 | |
96 | |
23 | |
64 | |
58 | |
89 | |
69 | |
280 | |
82 | |
82 | |
182 | |
99 | |
237 | |
46 | |
121 | |
145 | |
149 | |
64 | |
145 | |
178 | |
151 | |
93 | |
117 | |
51 | |
232 | |
194 | |
108 | |
123 | |
287 | |
45 | |
125 | |
172 | |
106 | |
140 | |
211 | |
220 | |
199 | |
213 | |
130 | |
221 | |
258 | |
105 | |
208 | |
256 | |
83 | |
209 | |
51 |
