[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

[Jason Hellenthal]

Devin,

On Mon, May 09, 2011 at 11:50:06AM -0700, Devin Teske wrote:
> > -----Original Message-----
> > From: owner-freebsd-rc at freebsd.org [mailto:owner-freebsd-rc at freebsd.org]
> > On Behalf Of Jason Hellenthal
> > Sent: Monday, May 09, 2011 11:03 AM
> > To: Gordon Tetlow
> > Cc: freebsd-rc at freebsd.org
> > Subject: Re: [RFC][Change-Request] Create usefulness in rc.subr
> > etc/rc.conf.d/*.conf namespace.
> > 
> > 
> > Gordon,
> > 
> > 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 at dataix.net> wrote:
> > > > 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 each.
> > > >
> > > > 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.
> > >
> > 
> > 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 actually
> locks
> > anything but would make it visable enough to where it can be disabled in-place
> > rather than moved around.
> > 
> > It would act similiar to this in shell:
> > 
> > if [ -f $_modular_conf -a ! -f $_modular_conf.disable ]; then [...]
> > 
> > Then to disable one config someone can still do so without cp/mv and just
> touch
> > or rm /etc/rc.conf.d/my-conf.conf.disable
> > 
> > How does that sound to you ? and everyone else ?
> 
> You could achieve what you want with symlinks, like Linux (ducks for flying
> fruit).
> E.g., putting your scripts somewhere like /etc/rc.conf.d-all and then creating
> symbolic links in /etc/rc.conf.d).
> 

Devin! you have hit a very good point here "archiving". Usually when I 
want to turn a file off from being parsed I already use gzip(1) on the 
file so its still pretty much in-place without having to be moved. Not 
that I would expect everyone to follow that behavior but it gets rid of 
the need in my case to use the -x bit or even a similiar type of lockfile 
semantic, mv(1).

> Seriously... _don't_ do that (we're joking).
> 
After all it is really "what works for you" right ? ;) 

> Meanwhile, regarding your latest suggestion... it didn't take too well at the
> office (and unfortunately there weren't any alternative suggestions worth
> mentioning).
> 

Yeah I didn't think that would go over well ;) for the record I don't 
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 
around but if it is general consensus I have no problem shifting direction 
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 
other concerns please bring them up. I do have other idea's based around 
this one that could make the configuration process straight forward 
but I would like to fix what has partly broken functionality first.


Thank you Devin

-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20110509/f85403cf/attachment.pgp