/usr/local/etc/rc.d and role accounts

Andrey V. Semyonov wilfre at mail.ru
Fri Apr 14 07:04:30 UTC 2006

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

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 

Directory is chowned by `prog' effective UID, or GID and set the 
appropriate permissions to allow that UID/GID make changes in it.

More information about the freebsd-questions mailing list