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

[Devin Teske]

Jason,

> -----Original Message-----
> From: J. Hellenthal [mailto:jhellenthal at gmail.com] On Behalf Of Jason
Hellenthal
> Sent: Monday, May 09, 2011 4:38 PM
> To: Devin Teske
> Cc: 'Doug Barton'; freebsd-rc at FreeBSD.org
> Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr
> etc/rc.conf.d/*.conf namespace.
> 
> 
> Devin,
> 
> On Mon, May 09, 2011 at 04:01:14PM -0700, Devin Teske wrote:
> > > -----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.
> 
> Thank you again for reponding and calling more attention and adding some more
> intuitive knowledge behind this.
> 
> I would like to add a note to you on this though. I see one possible problem
with
> the way it is right now in the patch. It is procesed after rc.conf,
rc.conf.local so it
> does override those values. Should instead it be treated the opposite and
> process before rc.conf, rc.conf.local so it can be overridden by a more
centralized
> config ?
> 
> I see a greater potential having it act as a user specified defaults than I do
a
> rc.conf or rc.conf.local override. What do you think ? everyone else ? Doug ?

I talked about this with our lead developers and we think we came up with
something that has real significant potential.

We suggest that your source the rc.cond.d/*.conf files:

a. After /etc/rc.conf
b. Before /etc/rc.conf.local

Half our developers said that it would be nice if /etc/rc.conf.d/product.conf
could override rc.conf(5) and the other half said it would be nice if it was the
other way around. Then we thought about it for a moment, and we realized that if
you sourced them in-between the two files, that you could accommodate both
parties.

In this setup, we'd have /etc/rc.conf be the initial override file that
overrides /etc/defaults/rc.conf. Then /etc/rc.conf.d/product.conf would override
that. And finally, /etc/rc.conf.local would be end-all-be-all of overrides.
Nothing would be capable of overriding /etc/rc.conf.local (which seems to suit
the name -- "local" should indicate that the "non-local" can be inherited from a
master configuration, perhaps site-wide or pod-specific).

What do you think? I think it would be the "happy median."
-- 
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.
_____________