Date: Mon, 9 May 2011 20:57:57 -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: <DFB68666-D71A-45EF-8253-AA79652021DB@vicor.com> In-Reply-To: <4DC8A887.6060806@FreeBSD.org> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> <4DC8787A.9070003@FreeBSD.org> <00df01cc0eb2$f9837010$ec8a5030$@vicor.com> <4DC8A887.6060806@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 9, 2011, at 7:52 PM, Doug Barton wrote: > On 05/09/2011 18:38, Devin Teske wrote: >>> -----Original Message----- >>> From: Doug Barton [mailto:dougb@FreeBSD.org] >>>=20 >>>> but I'd like to take a shot at a worthwhile use-case. >>>>=20 >>>> 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). >>>>=20 >>>> Use Case: >>>>=20 >>>> 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 >>>>=20 >>>> 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". >>>=20 >>> You can already do this at least 2 different ways. The first is the met= hod I >> outlined >>> in my previous post. >>=20 >> 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. >=20 > Do you control /etc/defaults/rc.conf? If so, you can change rc_conf_files= . (See?, I told you I could come up with more ways to do the same thing.) If anything, we'd implement the patch to source_rc_confs to source /etc/rc.= conf.d/*.conf before rc_conf_files, which (if I understand correctly) is wh= at JHell's patch proposes to do. >=20 >> 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 mac= hines. >=20 > I haven't seen anything yet which eliminates the idea of sourcing the add= itional conf files from rc.conf[.local]. You just add something like: >=20 > # Vicor product configuration: > . /path/product-a-file >=20 > I realize that you'd like to give the users full control over both of tho= se files though, which is why I suggested /etc/defaults/rc.conf might be an= other solution. Relinquishing control means not requiring them to have anything. The above = proposed solution requires at least a single line containing aforementioned= ". /path/product-a-file". Whether you inject it into their files with boot= strap scripts, mandate that someone add it with a text-editor, or if it get= s there by magic, any way you've not truly relinquished control, have you? Another argument is that if you instruct your customers to add ". /path/pro= duct-a-file" to their rc.conf[.local] file, then you'll inevitably be asked= what "." does (approximately 10 minutes after the first person forgets sai= d "."), at which point you've now opened a bag full of cats. Never would I = deny that rc.conf(5) accepts full sh(1) syntax, but also would I never go a= round advertising it to every person that touches a command-line within our= organization. It's often best left to have the majority think of it as a p= lain KEY=3DVALUE text file, rather than go about advertising with lines of = ". /path/product-a-file" allusions of grandeur to budding sh(1) enthusiasts. A view askew. Your mileage may vary. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w 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?DFB68666-D71A-45EF-8253-AA79652021DB>