Date: Mon, 9 May 2011 18:38:32 -0700 From: "Devin Teske" <dteske@vicor.com> To: "'Doug Barton'" <dougb@FreeBSD.org> Cc: 'Jason Hellenthal' <jhell@DataIX.net>, freebsd-rc@freebsd.org Subject: RE: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <00df01cc0eb2$f9837010$ec8a5030$@vicor.com> In-Reply-To: <4DC8787A.9070003@FreeBSD.org> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Doug Barton [mailto:dougb@FreeBSD.org] > Sent: Monday, May 09, 2011 4:28 PM > To: Devin Teske > Cc: freebsd-rc@freebsd.org; 'Jason Hellenthal' > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > etc/rc.conf.d/*.conf namespace. > > 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. In my locale, the phrase "we're on the same page" actually means "I agree with your last statements." Your response is taken as if you mean to say that I was wrong in agreeing with you. Wait, what? That doesn't rightly make much sense. I frankly don't understand the origin of this perceived hostility. > > 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. 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. Currently, as it stands, rc.conf(5) is standardized across all hosts, and rc.conf.local is where we put the per-machine configurations. However, we'd really really like to instead relinquish rc.conf.local to the customers, instead moving our productized configs to rc.conf.d with role-specific filenames. Thus completing the trifecta that would allow: a. Our customers to maintain a site-wide rc.conf(5) b. Our customers to maintain a per-machine rc.conf.local c. Have rc.conf.d as the landing zone for our productized configs Where your suggestion of "just put ``. /path/file'' to rc.conf(5)" assumes that we control rc.conf(5), which as explained above, we assume that the customer has complete control over that file (and with JHell's addition, we can then also assume that the customer has complete control over rc.conf.local). > 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.) I find this suggestion to be a gross perversion of the boot process. In the case where JHell's patch is put through and we're allowed /etc/rc.conf.d/*.conf, all that is needed is to add "*_enable=YES" to a file to effect whether that system is loaded. Contrast that with a /usr/local/etc/rc.d script which will have to do a lot more heavy lifting to accomplish the same task: a. Check if the daemon was started (this can range from simple to difficult, depending on the service details) b. If the daemon did not start, start it (again, this can be simple or difficult; if the service has a corresponding rc.d script, then simple, otherwise perhaps difficult) Compare the act of setting an environment variable at the appropriate point-in-time during the boot process with the act of performing checks and creating conditions in which you fire have to perform some action to bring up the service. It seems almost obvious that the [hypothetical] one-liner addition to /etc/rc.conf.d/product.conf is more efficient than the dozens-or-more lines required to achieve the same thing in an rc.d script which is running after-the-fact in which the [presumed] prior-executed rc.d script could have done the job for you had the "*_enable=YES" variable been set. > 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. I'd like to hear more suggestions, but remain dubious that anything is going to top JHell's proposition. -- 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. _____________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00df01cc0eb2$f9837010$ec8a5030$>