Date: Mon, 9 May 2011 19:28:25 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Devin Teske <dteske@vicor.com> Cc: freebsd-rc@freebsd.org, 'Gordon Tetlow' <gordon@tetlows.org> Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace. Message-ID: <20110509232825.GA2558@DataIX.net> In-Reply-To: <006801cc0e79$ec6f98b0$c54eca10$@vicor.com> References: <20110508191336.GC3527@DataIX.net> <BANLkTi=hozQBLUC15NsF2rky2OfFW=t_RQ@mail.gmail.com> <20110509134617.GA28036@DataIX.net> <BANLkTin%2BtgJqM8OmH%2BtiFsiUKPsdOj921w@mail.gmail.com> <20110509180243.GA82456@DataIX.net> <006801cc0e79$ec6f98b0$c54eca10$@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Devin, On Mon, May 09, 2011 at 11:50:06AM -0700, Devin Teske wrote: > > -----Original Message----- > > From: owner-freebsd-rc@freebsd.org [mailto:owner-freebsd-rc@freebsd.org] > > On Behalf Of Jason Hellenthal > > Sent: Monday, May 09, 2011 11:03 AM > > To: Gordon Tetlow > > Cc: freebsd-rc@freebsd.org > > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr > > etc/rc.conf.d/*.conf namespace. > >=20 > >=20 > > Gordon, > >=20 > > On Mon, May 09, 2011 at 10:19:50AM -0700, Gordon Tetlow wrote: > > > On Mon, May 9, 2011 at 6:46 AM, Jason Hellenthal <jhell@dataix.net> w= rote: > > > > Dump you rc.conf to two place. home-lan.conf and away-lan.conf and > > > > use chmod to turn one or the other off. You can still have a global > > > > set of services enabled in rc.conf but still be able to choose a way > > > > for them to act by adding the _flags or even _enable rc_vars to eac= h. > > > > > > > > Since this processes after rc.conf* you could treat those config's > > > > as just modifiers to get a certain behavior as they override what is > > > > in rc.conf* in the same way that rc.conf overrides > > > > etc/defaults/rc.conf. How you name them can clearly depict what it > > > > does as well. This is one reason why I mainly went with adding the > > > > -x bit because these can coexist with a full rc.conf but be changed > quickly > > when you want a certain behavior. > > > > > > For everything else in the proposal, I feel the use of the execute bit > > > is incorrect. Nowhere else in the system is there a precedent of using > > > the execute bit to toggle on and off a configuration file. You can no > > > longer do a simple 'grep foo_enable *.conf' and see which active files > > > have that set. I would prefer to use the pattern established by many > > > 3rd parties and use the convention that you may mv the file out of the > > > way so it no longer matches the *.conf glob. Something like 'mv > > > foo.conf foo.conf.disable' is unambiguous and can easily be searched > > > with a simple ls or grep command. Using the execute bit is less > > > transparent, unprecedented, and confusing. > > > > >=20 > > Ok, I do agree with you on this. There is another route that I propose = the > same > > type of thing but in the style or sense of a lockfile. Not that it actu= ally > locks > > anything but would make it visable enough to where it can be disabled i= n-place > > rather than moved around. > >=20 > > It would act similiar to this in shell: > >=20 > > if [ -f $_modular_conf -a ! -f $_modular_conf.disable ]; then [...] > >=20 > > Then to disable one config someone can still do so without cp/mv and ju= st > touch > > or rm /etc/rc.conf.d/my-conf.conf.disable > >=20 > > How does that sound to you ? and everyone else ? >=20 > You could achieve what you want with symlinks, like Linux (ducks for flyi= ng > fruit). > E.g., putting your scripts somewhere like /etc/rc.conf.d-all and then cre= ating > symbolic links in /etc/rc.conf.d). >=20 Devin! you have hit a very good point here "archiving". Usually when I=20 want to turn a file off from being parsed I already use gzip(1) on the=20 file so its still pretty much in-place without having to be moved. Not=20 that I would expect everyone to follow that behavior but it gets rid of=20 the need in my case to use the -x bit or even a similiar type of lockfile= =20 semantic, mv(1). > Seriously... _don't_ do that (we're joking). >=20 After all it is really "what works for you" right ? ;)=20 > Meanwhile, regarding your latest suggestion... it didn't take too well at= the > office (and unfortunately there weren't any alternative suggestions worth > mentioning). >=20 Yeah I didn't think that would go over well ;) for the record I don't=20 really care for it either. > What is so horrible about mv(1)? Nothing. in-place files are nice though because you dont have to mv them=20 around but if it is general consensus I have no problem shifting direction= =20 and going with changeset 64:dcc5d3cb0d13 that gets rid of the -x bit. Still at the same location: http://patches.jhell.googlecode.com/hg/rc.subr_modular_conf.patch Anyway if anyone has some suggestions on the final patch that or some=20 other concerns please bring them up. I do have other idea's based around=20 this one that could make the configuration process straight forward=20 but I would like to fix what has partly broken functionality first. Thank you Devin --=20 Regards, (jhell) Jason Hellenthal --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyHiYAAoJEJBXh4mJ2FR++9UH/09GKYTt3fqXwCv67pkWFUur falnAQkxbJBVZkZq03qPIE635ph1yJr4BLygIm7QyJiH4aGv9HZvEHepBW4Co8E5 buoZh43rUqWRUtWgon6bN0WsdTY8q2mMfPV93HSyN3bsyOnzkYqkIkyCor7/5piL ojhswNLmkJdciGRiX7RjTVFM1h4zhnXINmfQ3VRJtFiri8k3qcXUmpBeepdTAdIQ ZnOTGJ+kBoA4TilpOggXkJ38F7BmWG0nvm1i3aLla64KJEQzJBDnahkoepc7eqQ0 nUwQpyGbqKi75GVZ+z5IJX0Byuxm8RYZE+kTmbhtBqhdoTKuyJ+OyZmiaR+7MJ4= =mBDH -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110509232825.GA2558>