Date: Sun, 8 May 2011 21:33:17 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Jilles Tjoelker <jilles@stack.nl> Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-rc@freebsd.org Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <20110509013317.GJ3527@DataIX.net> In-Reply-To: <20110508221129.GA89657@stack.nl> References: <20110508191336.GC3527@DataIX.net> <C7EC90A2-936C-44E1-BC5E-E249399AF9AB@gmail.com> <20110508202636.GF3527@DataIX.net> <D1670EA4-437A-4D79-A5FC-8EE4D05466BA@gmail.com> <20110508221129.GA89657@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--RwGu8mu1E+uYXPWP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jilles, & anyone in general, cherry-pick as needed. On Mon, May 09, 2011 at 12:11:29AM +0200, Jilles Tjoelker wrote: > I would say the opposite. jhell's original loop >=20 > + for _modular_conf in /etc/rc.conf.d/*.conf; do > + if [ -f "$_modular_conf" -a -x "$_modular_conf" ]; then > + debug "Sourcing $_modular_conf" > + . $_modular_conf > + fi > + done >=20 > with a small change > - . $_modular_conf > + . "$_modular_conf" Updated in changeset: 63:bf83c2313376, I missed that. Thanks for catching= =20 it. I actually thought about adding another check just to be sure the variable= =20 wasnt empty and adding some text to the debug line like "Sourcing modular= =20 config $_modular_conf" in case for some reason it was NULL but I don't=20 believe that will happen and if it did there is probably more serious=20 problems with the system before it even gets to this point. [ ! -n "$_modular_conf" ] && . "$_modular_conf" Just to be sure but have not updated it in that way yet. >=20 > does not have any E2BIG problems, and also no problems with special > characters. This is because the list of pathnames stays within sh; it is > not passed to another program. If there is no matching file, the loop > runs once for /etc/rc.conf.d/*.conf which does not exist and is > therefore not sourced. >=20 > Any 'while read...' loop will handle pathnames with newlines > incorrectly, and the simple ones also handle backslashes and certain > whitespace incorrectly. Also, the proposed pipeline does not even work > as the while loop is executed in a subshell, so the assignments in the > sourced files are lost. >=20 > This post is not an endorsement of jhell's idea. I am not really > convinced it is useful. For experimenting, the for command can be placed > in /etc/rc.conf. >=20 Just to note, using if statements and such within what is normally to be=20 determined as a config file can be quite unclean or messy or hard to=20 navigate for most that look for a way to shift configurations around. The= =20 original idea behind this for the motivation is jail,nfs,rpcbind etc. Where example:=20 /etc/rc.conf.d/nfsserver.conf can contain: * rpcbind_enable * nfsexample_enable * nfs_lockd_enable * nfs_statd_enable And: /etc/rc.conf.d/nfsserver_nolocking.conf can contain: * rpcbind_enable * nfsexample_enable And this is where the executable bit becomes handy that allows you to=20 quickly chmod(1) one of them and yet still have rpcbind enabled for the=20 other or chmod both and nolonger need rpcbind enabled. This can become=20 even more extensive for jail use and ifconfig configuration but that is=20 byond what could really be summed up on this thread. The current use of rc.conf.d is nearly broken from the users point of view= =20 since it requires working knowledge of the names exported by each rc.d=20 script in order to place the _enable values in the same name file under=20 the rc.conf.d directory and yet while some scripts may not always get that= =20 value if it is only available under the jail name config. Thats a really=20 rought way of handling it. Though I do see that exact facility as being=20 useful if a user wanted to dump in some type of shell script to do some=20 extra parsing or prestart work for a single instance that runs out of rc.d= =20 but this is not what rc.conf(5) suggests so it is quite misleading. And yes I agree! This is the FreeBSD Project and as of this thread the=20 modification made is solely that of myself and my view as I have witnessed= =20 it in the current configuration. And as which needs proper feedback from=20 the community & developers before action is taken. This in-turn though is= =20 an addition/contribution that doesnt impede or change the way=20 configuration is already done but to extend the options that are available= =20 to the end-user in a minimal constructive way.=20 Thank you Jilles I appreciate the feedback and I look forward to hearing=20 back from everyone. --=20 Regards, (jhell) Jason Hellenthal --RwGu8mu1E+uYXPWP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNx0RdAAoJEJBXh4mJ2FR+vc0IAIwvMGAVIRp+NwSp76TFiHbQ /YMwXMefuxc1oF8yE3Sec+bk/BpAvi3P+OZYK1wGcDOVaCCjOO6Cw0XFc7vULQpv oqoLegYtGbBn/Fgvb5Z+k+mGs6kgX9AqfC+mLWDSPLqHm3IxKbcob+gdoxnhallR dF2/mM0FqnabvRSttC7RFdBeQskBDMchhr3PDEMXS/y03l1tZMJ+Pfk3xVwCeWPE LHqpa63xlewmf/1Dcz33qH8lK5JZGaw0DoalRzFAu9OCzpKa6hm1BvRW2W47Vukx V9lFQsM65QaYmkNSlzE0YzEHdAiu7uAxh+hUGnT7UGYwZQ27Wy2gc3afKmby5CQ= =dbDp -----END PGP SIGNATURE----- --RwGu8mu1E+uYXPWP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509013317.GJ3527>