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

[Jason Hellenthal]

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 ?

-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20110509/e4461735/attachment.pgp