Date: Sun, 8 May 2011 17:54:32 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Devin Teske <dteske@vicor.com> 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: <20110508215432.GG3527@DataIX.net> In-Reply-To: <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com> References: <20110508191336.GC3527@DataIX.net> <C7EC90A2-936C-44E1-BC5E-E249399AF9AB@gmail.com> <5474DF9C-500A-4B51-948F-F56A66051476@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Devin, On Sun, May 08, 2011 at 01:59:40PM -0700, Devin Teske wrote: > > On May 8, 2011, at 1:13 PM, Garrett Cooper wrote: > > > On May 8, 2011, at 12:13 PM, Jason Hellenthal wrote: > > > >> > >> List, - Please reply-to freebsd-rc@freebsd.org > >> > >> Recently I have been going over some changes in the configurations that > >> are possible with the rc subsystem and to my dismay I have found some > >> inconsistencies with in particular the way rc.conf.d directory is > >> processed and the arguments that are supplied to load_rc_config so I have > >> patched it up... > >> > >> Let me explain: As determined by rc.subr load_rc_config, config's from > >> rc.conf.d are loaded by the scripts $name as an argument to load_rc_config > >> and thus only the name being parsed is is available to be used in the > >> rc.conf.d directory. Why is this bad ? Its not! but it is inconvenient as > >> the user has no direct way to know that a variable used by nfsd is also > >> needed by mountd or the same for various other scripts in the rc.d > >> directory. At this time these config's are explained to be available for > >> the user to utilize by rc.conf(5) but yet without much knowledge of the > >> inner workings of the rc subsystem it would be quite the feat to do. > >> > >> > >> The attachment[1] keeps this functionality the same while introducing a > >> more convenient approach for the user to modularize their configuration > >> however they see fit within a couple constraints that work very well. > >> > >> > >> What does it do ?: As stated above, current functionality is undisturbed > >> while allowing the user to create config's by any name they so desire as > >> long as it has an extension of ".conf", also introducing the ability to > >> turn a configuration file off by using chmod(1). You can turn nfsc1.conf > >> off/on by simply chmod [-/+]x etc/rc.conf.d/nfs1.conf > >> > >> > >> Why ? Simple. How many times have you been bitten by disabling something > >> in the rc.conf file and left to discover what you just disabled was also > >> used by another daemon but that daemon is now not starting ? This is a way > >> to virtualize your configuration allowing you to add multiple _enable= > >> lines to different configurations for different roles. For instance > >> rpcbind is used by both samba and nfs*. With this you can add > >> rpcbind_enable to both a configuration for samba and nfs and when you > >> disable one service you know that you have not disabled a dependent for > >> another. > >> > >> > >> This is a small addition that fixes currently broken undesirable aspects > >> of the configuration system that deals with the rc.conf.d directory with a > >> SysV style init approach that is just as flexible. This should apply > >> cleanly to current and stable/8 & 8.2-RELEASE systems. Once more feedback > >> has been received Ill update the manual page with any suggestions > >> regenerate the patch to accommodate and file a PR. > >> > >> > >> 1). http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch > > > > Doing: > > > > find /etc/rc.conf.d/ -type f -name '*.conf' -mindepth 1 -maxdepth 1 -perm +111 | while read _modular_conf; do > > debug "Sourcing $_modular_conf" > > . "$_modular_conf" > > done > > > > might be better. There's some more magic that could ultimately be done to make this more secure/robust using "-print0" | xargs, but it's up to you how you might want to go about solving that problem. > > Also, I don't know if depending on a .conf file to be executable is necessarily the best course of action. > > > > First, let me add that I really like the idea. This makes it akin to our /usr/local/apache2/conf.d/ directory where we place our various configs by many names, but always ending in `.conf'. > > I'm anticipating the day where I can have /etc/rc.d/foo.conf and /etc/rc.d/bar.conf, each configuring multiple (likely unrelated) services. > > Better still, /etc/rc.d/jail1.conf, /etc/rc.d/jail2.conf, etc. etc. (I think you just made my -- and everyone else whom uses jails -- day/week/month/year). > > However, I agree with GC that depending on a .conf file to be executable is a bit non-standard, even if it is sourced like a shell-script (though I can understand the historical heritage as /usr/local/etc/rc.d/ used to require both `.sh' suffix and executable bits; but that is not to condone treating `rc.conf.d' like `rc.d' in any way). > I do agree with the -x bit concern yes. But thinking of the users to enable disable a particular config without having to open a editor is mainly why I have put that in place. It allows a lot of flexibility without a lot of extra work while also introducing the ability to check if a particular configuration is enabled by checking the bit rather than sourcing for a _enable. Since these are only config files there will/should never be a config_enable for them as they are only config's, so providing a SysV init style way of enabling/disabling them at will is prime. using mv(1), rm(1) or possibly having to open a editor on multiple versions of the same config to disable a certain portion is far from ideal. I really don't want to see the rc system subjected to a find(1) every time it needs to do a load_rc_config since it can be done quicker with in-shell testing. I think a lot of people would agree with this. I would suggest at least for those that doubt the SysV style way of enabling disabling scripts give it a try for a couple weeks then report back. If feed back is strong discouraging it then we can probably come to common ground and find a way to work with both those who would like it and those who don't by default. I do have a pretty good idea what would work to make it happen both ways but I really would like to advocate this in place as it is now first. Thanks you again Devin, Appreciate the feedback. -- Regards, (jhell) Jason Hellenthal [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNxxEYAAoJEJBXh4mJ2FR+hSYH/2/h5KU+v/wqH46BKLqHDZbN iYygPjp4c3QI8ZDimL7t13XxCtg5zndvLEr09qsG5g085mvHuY3PMitPOlQ5rcX9 1Q0TH1+tlWl9X92qCEfRoSGDS3Rs3otvfsOzeeZbxMgBxy1bU5mNNdfylZ6l/A05 p80K+/gYZqN0U2BNOOeFy2bb1qCfBiVDuk3n0XaIKQJdUKs1vr4GMNKd54Ft5r/9 spr2R0FtDSgk2cFzH+s5tbuFmgH4Yyg3Z7n+0bL8mDr5vTNVVXZDTCEGdoGUihXp X6moaipShOBtXIew6oWt86lVNYUG2I80o40z/1Q59aGvKQ3Nt+JuPwDgxuFmCJM= =q7WR -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110508215432.GG3527>