Subject: Re: Managing identical multiple daemons with a single rc.d script?
To: None <email@example.com>
From: Marc Tooley <netbsdMLpostNO@spam.quake.ca>
Date: 01/19/2007 14:15:49
On Thursday 18 January 2007 23:58, Geert Hendrickx wrote:
> On Thu, Jan 18, 2007 at 10:53:01AM -0800, Marc Tooley wrote:
> > Comments much appreciated.
> Very interesting. A few questions though: where are the various
> instances (the testxyz in your case) defined? In the daemon's
If you mean the various instances from the rc.d script's perspective,
they are defined purely in the rc.conf.d file. The rc.subr paper
described the rc.conf.d as a better place to put configuration files if
the configuration requirements are extensive. (In this case, they're
If you are wondering how Perforce knows what instance it is--it doesn't.
The rc.d script itself configures the p4d instance on a per-instance
basis by telling it where to puts its db.* root files, journal file,
logfile, etc. So long as two instances don't share any filesystem
namespace (different directories) then there's no problem from
Perforce's perspective and it chugs along, blind to the fact that there
are 19 other copies of itself running on the system.
> configuration, or in rc.d (rc.conf.d) configuration? Can the various
> instances have different configuration files, or do they all use the
> same configuration file? I'd be interested in setting up multiple
The different instances are all defined in the same rc.conf.d file; I
don't see why there couldn't be additional logic installed to support
different files per-instance, but since there are only about 5-10 lines
per-instance in the rc.conf.d file the complexity by itself doesn't
necessarily warrant it except from a per-user standpoint as you are
> apache instances this way (listening on localhost, all proxied by one
> "master" instance listening on the public interface). Would it be
> possible to give non-root users permission to start/stop/restart
> "their" instance?
Neat. Since the rc.d scripts run as root themselves, I don't imagine
they'd have any difficulties su'ing to a particular user before
performing any actual operations on the daemon instances. The rc.d
script I presented in my last note would need to be pretty extensively
modified, however. Additionally, there'd need to be a way for a user
to "register" his instance first... perhaps an additional interactive:
/etc/rc.d/p4d register new_instance_name
... which could keep track of the username the instance belongs to and
only allow global operations on the instances if the calling user has a
uid of 0.
Now that's a really cool idea..!
Generic disclaimer, not necessarily directed at anyone in particular:
Please Reply-To: the list. My MX has trouble accepting email sometimes.