Mike Hunter wrote:
Hi,
I'm hoping to get into the spirit of the new rc.d script specs (REQUIRES,
PROVIDES, command=, etc) on a new server I'm building. The old script I
was using looked like this:
I have several questions about how to replicate this behavior. I'm still
deciding whether I'm willing to split out the 10 or so instances into
separate scripts...if I didn't want to do that, is the best way to handle
it to create a script with all 10 command and then have the rc script run
that script?
How do I replicate the su stuff? I could say command=su and
foo_flags="foo-role -c ..." but that doesn't seem very good.
Well, you try to suggest rc scripts patches to implement such a beholder...
For example, implement new rc-script variable ${${name}_effective_user}
or like that... (sh syntax doesn't allow you to make such an expression)
Tried to play with and found that:
You may try to add a parameter to rc.conf:
for example, if cupsd.sh sets 'name=cupsd', then you should set
cupsd_effective_user in rc.conf (so, in sh-syntax it sounds like
${name}_effective_user )
The most terrible thing is than you can't extract a value from a
variable, which you name by some dynamic sting (you can't extract a
variable by name set in other variable partly or the whole)
So, some workaround is to use world's tools (may not work in minimal
installation distribution set):
if ! /bin/test -z $(set | /usr/bin/grep
"${name}${variable_common_suffix}" | /usr/bin/cut -d "=" -f 2); then
some_tricks();
fi;
Here I've just checked a nonzero length of such a 'dynamically' named
variable. If you can - try to implement such a beholder into rc.subr and
give us patches. If I have time I'll try to do that myself.
As a bonus, foo would like to make pid files, but /var/run isn't writable to
foo-role. What's the standard way to handle where to put the pid files?
/var/run/${progname}/ - directory for pidfiles of progs (ex. clamav's
clamd).
Directory is chowned by `prog' effective UID, or GID and set the
appropriate permissions to allow that UID/GID make changes in it.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
