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

[Jason Hellenthal]

Doug,

On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote:
> 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.
> 
> > 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. 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.)
> 
> So, there are at least 2 different ways that you can achieve the same 
> effect that already exist, and I strongly suspect that if I thought 
> about it long enough I could come up with a couple more. I'm still 
> willing to listen to a use case that can't be achieved without this 
> change, but to be honest I'm dubious.
> 
> 

Sorry Doug but rc.conf.d is already laid out for the user to use as 
mentioned by rc.conf(5) with a suggested use but unfortunately has quite a 
few side effects that I am not going to bother re-writing about again.

In reply to your previous email here is one exercise that should point 
out the broken functionality fairly clearly or at least I hope clearly 
enough that you realize how a normal user would look at it.

From scratch, no rc.conf. Setup a NFS server with lockd, statd, mountd, 
rpcbind using only rc.conf.d/${_name} namespace and then try starting 
these services using service(8) and /etc/rc.d/* files. Then read 
rc.conf(5) and tell me the suggestion for jail makes sense.

If you still disagree after doing this then please by all means eradicate 
rc.conf.d from rc.conf(5) and remove its functionality from rc.subr as it 
is less than adequate for anybody other than a developers natural use.


I do not quite understand why you take such an opposition against 
something that fixes this broken functionality but yet retains its 
original use.

-- 

 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/d7e06b0e/attachment.pgp