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

[Devin Teske]

> -----Original Message-----
> From: owner-freebsd-rc at freebsd.org [mailto:owner-freebsd-rc at freebsd.org]
> On Behalf Of Doug Barton
> Sent: Monday, May 09, 2011 1:28 PM
> To: freebsd-rc at freebsd.org
> Cc: Jason Hellenthal
> Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr
> etc/rc.conf.d/*.conf namespace.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> I agree with Gordon's analysis that this proposal adds a lot of potential for
> confusion with very little real benefit. Your post describes _what_ you want
to
> do, but I'm confused about _why_ you would want to do it. Can you give a use
> case example?
> 
> I also feel compelled to point out that if the functionality you want is
"break
> certain common knobs for a subset of services out into their own configuration
> file" then this can already be achieved without any code changes by placing ".
> /path/file" in your rc.conf[.local] file(s). You can even put the code snippet
you
> posted in there if you really feel that it's the right solution. And yes, I
heard you
> say elsewhere in the thread that you don't like to put anything other than
> variables in rc.conf, but there is nothing actually wrong with doing it, and
it works.
> 
> In short, I've reviewed this whole thread to date and haven't yet seen a
> compelling reason to make this change.

Hi Doug,

First, let me say that we're on the same page, 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".

Meanwhile, if we need hardware-B to run products A and B but in workstation
roles, we'd install "/etc/rc.conf.d/product-A-workstation.conf" and
"/etc/rc.conf.d/product-B-workstation.conf".

Currently the way we solve this is by having a bootstrap script that determines
what needs to be added to /etc/rc.conf by-way of reading the hostname (which of
course can be overridden with a command-line argument).

JHell's proposed idea of allowing one to place any number of well-named "*.conf"
files to /etc/rc.conf.d would allow us to separate the roles into different
files rather than having to augment them into a single file (or worse, have the
directives scattered throughout /etc/rc.conf.d/${_name}).

This is especially nice because we (as the makers of "Product-A" and
"Product-B") are not the ones that maintain the system. The customers purchase
equipment, use our bootstrap scripts to configure things like /etc/rc.conf et.
al., and then proceed to run our software in the configured manner. One of the
largest contentions in this scenario is that our product-based rc.conf(5)
settings end up in the same file as the customer-based rc.conf(5) settings.
Things that have nothing to do with our product are indistinguishable from
others.

I fully support JHells addition because it would immediately allow us to
maintain static configs required to operate our product separately from the
dynamic configs created by the customer.
-- 
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.
_____________