Date: Mon, 9 May 2011 19:38:25 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Devin Teske <dteske@vicor.com> Cc: 'Doug Barton' <dougb@FreeBSD.org>, freebsd-rc@FreeBSD.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <20110509233825.GB2558@DataIX.net> In-Reply-To: <007d01cc0e9d$00301ff0$00905fd0$@vicor.com> References: <20110508191336.GC3527@DataIX.net> <4DC84E68.1000203@FreeBSD.org> <007d01cc0e9d$00301ff0$00905fd0$@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509233825.GB2558>