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

[Doug Barton]

On 05/09/2011 18:38, Devin Teske wrote:
>> -----Original Message-----
>> From: Doug Barton [mailto:dougb at FreeBSD.org]

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

I'm not going to debate the meaning of "on the same page" with you, so 
let be more clear. You and I do not agree. Oh, and there is no 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.

Do you control /etc/defaults/rc.conf? If so, you can change 
rc_conf_files. (See?, I told you I could come up with more ways to do 
the same thing.)

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

I haven't seen anything yet which eliminates the idea of sourcing the 
additional conf files from rc.conf[.local]. You just add something like:

# Vicor product configuration:
. /path/product-a-file

I realize that you'd like to give the users full control over both of 
those files though, which is why I suggested /etc/defaults/rc.conf might 
be another solution.

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

So don't use it. My feelings won't be hurt. :)


-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/