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

[Devin Teske]

> -----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).

Seriously... _don't_ do that (we're joking).

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

What is so horrible about mv(1)?
-- 
Devin

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________