[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

[Devin Teske]

> -----Original Message-----
> From: Doug Barton [mailto:dougb at FreeBSD.org]
> Sent: Monday, May 09, 2011 4:28 PM
> To: Devin Teske
> Cc: freebsd-rc at freebsd.org; 'Jason Hellenthal'
> Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr
> etc/rc.conf.d/*.conf namespace.
> 
> On 05/09/2011 16:01, Devin Teske wrote:
> > Hi Doug,
> >
> > First, let me say that we're on the same page,
> 
> We're not, actually.

In my locale, the phrase "we're on the same page" actually means "I agree with
your last statements." Your response is taken as if you mean to say that I was
wrong in agreeing with you. Wait, what? That doesn't rightly make much sense.

I frankly don't understand the origin of this perceived hostility.


> > but I'd like to take a shot at a worthwhile use-case.
> >
> > Also, I know you were addressing jhell but I thought I'd chime-in
> > because we
> > (VICOR) feel that this feature would be very useful to us (envisioned
> > use-case described below).
> >
> > Use Case:
> >
> > 1. One of many customers runs a site with, say, 35 servers and 89
workstations.
> > 2. Each/every machine has a "role" which requires certain services to
> > be enabled 3. Server "roles" enable NFS, SSH, FTP, as well as other
> > services 4. Workstation "roles" have a wholly separate set of services
> > (with some
> > in-common)
> > 5. Pedestals are yet another "role"
> > 6. Machines can satisfy multiple roles 7. The roles are additive 8.
> > There are separate roles for different products
> >
> > So if we need hardware-A to run products A and B in roles "A-Server"
> > and "B-Server", we'd install "/etc/rc.conf.d/product-A-server.conf"
> > and "/etc/rc.conf.d/product-B-server.conf".
> 
> You can already do this at least 2 different ways. The first is the method I
outlined
> in my previous post.

If by that you mean your suggestion to add ". /path/file" to rc.conf(5) et. al.,
that's non-copacetic as I forgot to mention that we (as a product vendor) do not
control rc.conf(5), rather our customers do.

In fact, we have an rc.d script that uses sup(1)/cvsup(1) to pull down
rc.conf(5) from a central server, allowing central management of all machines.

Currently, as it stands, rc.conf(5) is standardized across all hosts, and
rc.conf.local is where we put the per-machine configurations. However, we'd
really really like to instead relinquish rc.conf.local to the customers, instead
moving our productized configs to rc.conf.d with role-specific filenames. Thus
completing the trifecta that would allow:

a. Our customers to maintain a site-wide rc.conf(5)
b. Our customers to maintain a per-machine rc.conf.local
c. Have rc.conf.d as the landing zone for our productized configs

Where your suggestion of "just put ``. /path/file'' to rc.conf(5)" assumes that
we control rc.conf(5), which as explained above, we assume that the customer has
complete control over that file (and with JHell's addition, we can then also
assume that the customer has complete control over rc.conf.local).


> The second would be to have wrapper rc.d scripts in
> /usr/local/etc/rc.d that start the required services for either product; with
or
> without correspondingly named config files in /etc/rc.conf.d. (Personally I
would
> set the right values in the scripts themselves.)

I find this suggestion to be a gross perversion of the boot process.

In the case where JHell's patch is put through and we're allowed
/etc/rc.conf.d/*.conf, all that is needed is to add "*_enable=YES" to a file to
effect whether that system is loaded. Contrast that with a /usr/local/etc/rc.d
script which will have to do a lot more heavy lifting to accomplish the same
task:

a. Check if the daemon was started (this can range from simple to difficult,
depending on the service details)
b. If the daemon did not start, start it (again, this can be simple or
difficult; if the service has a corresponding rc.d script, then simple,
otherwise perhaps difficult)

Compare the act of setting an environment variable at the appropriate
point-in-time during the boot process with the act of performing checks and
creating conditions in which you fire have to perform some action to bring up
the service.

It seems almost obvious that the [hypothetical] one-liner addition to
/etc/rc.conf.d/product.conf is more efficient than the dozens-or-more lines
required to achieve the same thing in an rc.d script which is running
after-the-fact in which the [presumed] prior-executed rc.d script could have
done the job for you had the "*_enable=YES" variable been set.


> So, there are at least 2 different ways that you can achieve the same effect
that
> already exist, and I strongly suspect that if I thought about it long enough I
could
> come up with a couple more. I'm still willing to listen to a use case that
can't be
> achieved without this change, but to be honest I'm dubious.

I'd like to hear more suggestions, but remain dubious that anything is going to
top JHell's proposition.
-- 
Devin

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________