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 
pretty extensive.)

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 
looking at.

> 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..!

-Marc

Generic disclaimer, not necessarily directed at anyone in particular:
Please Reply-To: the list. My MX has trouble accepting email sometimes.