RC keywords question

[Ion-Mihai Tetcu]

On Mon, 5 Dec 2005 08:16:56 -0800
Brooks Davis <brooks at one-eyed-alien.net> wrote:

> On Mon, Dec 05, 2005 at 02:58:05PM +0200, Ion-Mihai Tetcu wrote:
> > Hi,
> > 
> > 
> > I'm converting my ports to work with the new HEAD RC style and
> > while at it I also thought to check the keywords to make sure
> > they're OK. Read rcorder(8) and rc(8).
> > 
> > Let's take mail/dspam as an example. Obviously it PROVIDE: dspam
> > 
> > When run in --daemon mode dspam receives messages via LMTP and
> > deliver them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd
> > (which starts BEFORE: SERVERS).
> > 
> > Now things start getting interesting.
> > 
> > Since it's a content filter, it should start before the SMTP server.
> > 
> > If SMTP server = sendmail|courier it's easy: BEFORE: mail
> > 
> > If it's postfix it's:
> > - if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
> > postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough
> > (but see below); 
> > - if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in
> > rc.d as sendmail.sh then BEFORE: mail should be OK too since that's
> > before rc.d/localpkg (right ?)
> > 
> > How to interact with various ways to start qmail I have yet to
> > discover.
> > 
> > So until here I would have:
> > PROVIDE: dspam
> > REQUIRE: NETWORK syslogd
> > BEFORE: mail
> > and since mail REQUIRE: LOGIN this is actually:
> > REQUIRE: NETWORK syslogd LOGIN
> >
> > Q: should I write all the REQUIRE keywords or just the last one
> > (LOGIN) ?
> > 
> > 
> > OK, now dspam could also use mysql or pgsql; if the dependency is
> > set at compile time, it's easy to have the right REQUIRE; but dspam
> > can also use either or none, as instructed in dspam.conf so this is
> > also settable at run-time. How can I write the REQUIRE: line in
> > this case ?
> 
> 
> "BEFORE: mail" acts for most intents and purposes like all mail
> scripts contained "REQUIRE: dspam" so dspam does not depend on
> LOGIN.  As a rule, there's no point in depending on syslogd, just

I think it's better if I make sure dspam starts before its potential
consumers that the other way around; and this for one reason: I know
that my port's consumers are mail servers, but making each mail server
OPTIONally depend of each content filter is obviously unfeasible (of
course I counld ask the user to modify his server's rc script by hand).
Please correct me if I'm wrong.

> depend on SERVERS instead.  This is actually what DAEMON is.  I'd say
> that virtually all ports should "REQUIRE: DAEMON" unless they have
> more specific requirements.

So I should have REQUIRE: DAEMON and that's all ?
Do I understand this right: BEFORE is for approximately selecting when
the server should start while REQUIRE actually asks for something to be
running ?

> For the database support, I'd suggest
> setting the dependencies based on the ports configure options.  It's
> harmless to depend on something that doesn't actually run, but
> annoying to depend on something that doesn't exist.

In my case the user either select one database back-end and that is
statically compiled and then I e.g USE_MYSQL and I can write my BEFORE
line (that's what I'm doing now for mysql); 

Or select multiple WITH_DB_NAME OPTIONS and have support for loading
any of them at runtime. For this case what I'm asking is: is there any
way  to hook-in a script that would parse dspam.conf, see what DB is set
and REQUIERE the right thing ?

> The correct solution for databases is probably to add a new dummy
> script DATABASES which all the database startup scripts should declare
> they run BEFORE.  Then other startup scripts could REQUIRE that
> unconditionally even if they aren't currently configured to use a
> database and none are installed.

And what do I do until then ? Or I just let the script as it is (.sh)
on 7.x also ?

Thanks,

-- 
IOnut - Unregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"

BOFH excuse #406:
Bad cafeteria food landed all the sysadmins in the hospital