From owner-freebsd-rc@FreeBSD.ORG Mon May 9 23:38:31 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAB8B1065678; Mon, 9 May 2011 23:38:31 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62DBA8FC0C; Mon, 9 May 2011 23:38:30 +0000 (UTC) Received: by iwn33 with SMTP id 33so6735532iwn.13 for ; Mon, 09 May 2011 16:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=FMRzYZ7SKqi039WV+YPRHNaxext/O5v7915wffYXd1c=; b=Exnt/Emtzonfxam8ObWTLL17pFD4+DS2QkQHCGrHgFUdGii0nSJNO1FTo+iH2JBL6c lqYYKqcO0Ig1skiqhUe89NjZqQ9FZ69ENCa7d94cx+Eoy8cSn6QR0UY6HmsrntQR3gJw LtY1bnE7XH0362vvbz/KVDq0yMEcsIkkOXqdE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=Tgc5DcU0yESv4pIR/r9nF18ZL27dKi8LEmAciIhJsk77kNJT+5y7nePf0F9s7C7zgU BKfBUKijpcg8Y+lQX5biKM0ylwiGUQFkB0vWhyOF39HojxBxr6DAbCWc4M85d76lPywd 6cbi0apnSXoKGSJMSMN6T2rDTxgS/IiDHL5h4= Received: by 10.42.132.66 with SMTP id c2mr6752107ict.194.1304984310589; Mon, 09 May 2011 16:38:30 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id i3sm2822592iby.57.2011.05.09.16.38.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 16:38:29 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p49NcQLH004447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 19:38:26 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p49NcPoA004446; Mon, 9 May 2011 19:38:25 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Mon, 9 May 2011 19:38:25 -0400 From: Jason Hellenthal To: Devin Teske Message-ID: <20110509233825.GB2558@DataIX.net> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E Cc: 'Doug Barton' , freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 23:38:31 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 04:01:14PM -0700, Devin Teske wrote: > > -----Original Message----- > > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > > On Behalf Of Doug Barton > > Sent: Monday, May 09, 2011 1:28 PM > > To: freebsd-rc@freebsd.org > > Cc: Jason Hellenthal > > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > > etc/rc.conf.d/*.conf namespace. > >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > >=20 > > I agree with Gordon's analysis that this proposal adds a lot of potenti= al 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? > >=20 > > 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 config= uration > > file" then this can already be achieved without any code changes by pla= cing ". > > /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 ye= s, I > heard you > > say elsewhere in the thread that you don't like to put anything other t= han > > variables in rc.conf, but there is nothing actually wrong with doing it= , and > it works. > >=20 > > In short, I've reviewed this whole thread to date and haven't yet seen a > > compelling reason to make this change. >=20 > Hi Doug, >=20 > First, let me say that we're on the same page, but I'd like to take a sho= t 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 worksta= tions. > 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 > Meanwhile, if we need hardware-B to run products A and B but in workstati= on > roles, we'd install "/etc/rc.conf.d/product-A-workstation.conf" and > "/etc/rc.conf.d/product-B-workstation.conf". >=20 > Currently the way we solve this is by having a bootstrap script that dete= rmines > what needs to be added to /etc/rc.conf by-way of reading the hostname (wh= ich of > course can be overridden with a command-line argument). >=20 > 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 differe= nt > files rather than having to augment them into a single file (or worse, ha= ve the > directives scattered throughout /etc/rc.conf.d/${_name}). >=20 > 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 pur= chase > equipment, use our bootstrap scripts to configure things like /etc/rc.con= f et. > al., and then proceed to run our software in the configured manner. One o= f 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) setting= s. > Things that have nothing to do with our product are indistinguishable from > others. >=20 > I fully support JHells addition because it would immediately allow us to > maintain static configs required to operate our product separately from t= he > dynamic configs created by the customer. Thank you again for reponding and calling more attention and adding some=20 more intuitive knowledge behind this. I would like to add a note to you on this though. I see one possible=20 problem with the way it is right now in the patch. It is procesed after=20 rc.conf, rc.conf.local so it does override those values. Should instead it= =20 be treated the opposite and process before rc.conf, rc.conf.local so it=20 can be overridden by a more centralized config ? I see a greater potential having it act as a user specified defaults than= =20 I do a rc.conf or rc.conf.local override. What do you think ? everyone=20 else ? Doug ? --=20 Regards, (jhell) Jason Hellenthal --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyHrxAAoJEJBXh4mJ2FR++LoH+gKzKTx7TWDKVOPKOYiqvAUS 91KVN4sqbdxBHNU0zV0XXuU2fRiJxYVoVqXxZOe50AHZbiBwxYKTzt5wSVoK4wYE Ga1ZvDuOXDAtmW3ZVuGFyrjGT/neA6ppnvMPTjX7+jZVUiS+2h72OceLRgf8AFmW vgzzWNLCsIvSXQLkwyAWKuZGRv1u1prG5YnHRMxQVcrsjAMqfWYJthRSSxVL2uA4 ww9Ng7Qkpn1uBO/8OC0gQvQyAClH+M+HNrnJBSpgTFyvy5uix06dAbdEU8Te7C2I dLWtrhPdwzrVOudV3cwpnbcX5UZlWlBN8VKQMqR8TSpTU/npDiS0qKKKhXngx6g= =TdGq -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ--