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

[Devin Teske]

On May 9, 2011, at 7:52 PM, Doug Barton wrote:

> On 05/09/2011 18:38, Devin Teske wrote:
>>> -----Original Message-----
>>> From: Doug Barton [mailto:dougb at FreeBSD.org]
>>> 
>>>> 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.)

If anything, we'd implement the patch to source_rc_confs to source /etc/rc.conf.d/*.conf before rc_conf_files, which (if I understand correctly) is what JHell's patch proposes to 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.
> 
> 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.

Relinquishing control means not requiring them to have anything. The above proposed solution requires at least a single line containing aforementioned ". /path/product-a-file". Whether you inject it into their files with bootstrap scripts, mandate that someone add it with a text-editor, or if it gets there by magic, any way you've not truly relinquished control, have you?

Another argument is that if you instruct your customers to add ". /path/product-a-file" to their rc.conf[.local] file, then you'll inevitably be asked what "." does (approximately 10 minutes after the first person forgets said "."), at which point you've now opened a bag full of cats. Never would I deny that rc.conf(5) accepts full sh(1) syntax, but also would I never go around advertising it to every person that touches a command-line within our organization. It's often best left to have the majority think of it as a plain KEY=VALUE text file, rather than go about advertising with lines of ". /path/product-a-file" allusions of grandeur to budding sh(1) enthusiasts.

A view askew. Your mileage may vary.
-- 
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.
_____________