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
[-- Attachment #1 --] 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 > > + 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 > > with a small change > - . $_modular_conf > + . "$_modular_conf" Updated in changeset: 63:bf83c2313376, I missed that. Thanks for catching it. I actually thought about adding another check just to be sure the variable wasnt empty and adding some text to the debug line like "Sourcing modular config $_modular_conf" in case for some reason it was NULL but I don't believe that will happen and if it did there is probably more serious 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. > > 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. > > 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. > > 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. > Just to note, using if statements and such within what is normally to be determined as a config file can be quite unclean or messy or hard to navigate for most that look for a way to shift configurations around. The original idea behind this for the motivation is jail,nfs,rpcbind etc. Where example: /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 quickly chmod(1) one of them and yet still have rpcbind enabled for the other or chmod both and nolonger need rpcbind enabled. This can become even more extensive for jail use and ifconfig configuration but that is 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 since it requires working knowledge of the names exported by each rc.d script in order to place the _enable values in the same name file under the rc.conf.d directory and yet while some scripts may not always get that value if it is only available under the jail name config. Thats a really rought way of handling it. Though I do see that exact facility as being useful if a user wanted to dump in some type of shell script to do some extra parsing or prestart work for a single instance that runs out of rc.d 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 modification made is solely that of myself and my view as I have witnessed it in the current configuration. And as which needs proper feedback from the community & developers before action is taken. This in-turn though is an addition/contribution that doesnt impede or change the way configuration is already done but to extend the options that are available to the end-user in a minimal constructive way. Thank you Jilles I appreciate the feedback and I look forward to hearing back from everyone. -- Regards, (jhell) Jason Hellenthal [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509013317.GJ3527>