using redhat chkconfig for logical booleans

[cerise at armory.com]

Hi David:

I thought a long time ago about implementing a lightweight filesystem
mounted at /etc for a similar idea.  The idea isn't necessarily a bad
one, but I think you'll spend a great deal of time trying to hack 
every program's reading of an /etc config file into your scheme --
that's eventually what prompted me to give up on it.

Incidentally, this is essentially what Microsoft did with the system
registry.  It mostly works.  OS X implemented a similar thing in 
netinfo (IIRC).  I'm not sure if the source for that is open, but 
that may help you out some.

Ultimately though, I think you'd be better served writing your own
library and utility for those changes than trying to hack it into
Red Hat's chkconfig.  It'll save you some maintenance headaches
the next time Red Hat releases a new version.

-Phil

On Wed, Nov 07, 2007 at 12:15:49PM -0800, David Alban wrote:
> Greetings,
> 
> Many of you may remember the irix implementation of chkconfig.
> Basically, it managed a set of "features".  Each feature could be "on"
> or "off".  The chkconfig command could add a feature to the set,
> delete a feature from the set, display the current status (on vs. off)
> of one, several, or all features in the set, and change the status of
> features in the set.
> 
> Many irix init.d scripts would check the state of a feature and act
> accordingly.  But any other program could at any time, also query the
> state of a feature.
> 
> So you ended up with an implementation of a set of arbitrary logical
> booleans.  The state of each of these booleans was kept in a file:
> 
>   /etc/config/$FEATURE_NAME
> 
> which contained, literally the word 'on' or the word 'off''.
> 
> Red Hat took this and modified it so that adding a new feature
> essentially created hard links from rcN.d directories to /etc/init.d/
> scripts.  Removing a feature would delete the rcN.d links.  You could
> add/delete features from different run levels
> 
> At my company, developers have started using *.flag files.  Processes
> test whether a flag file related to a logical boolean exists, and act
> accordingly.  This seems to me to indicate they have requirements to
> manage a set of logical booleans.  But they're not using a single
> program to manage/report on states.  This sounds like trouble to me.
> 
> I got to thinking, why not use red hat's chkconfig for this, instead
> (we're a red hat shop)?  While not specifically tied to startup,
> startup processes could indeed use chkconfig to determine system
> behavior at startup, but other non-startup processes could check
> states this way as well.  Of course, we'd have to be mindful of red
> hat chkconfig's additional capability of keeping a set of logical
> booleans per runlevel.
> 
> I wanted to ask if anyone on the list thought that using red hat's
> chkconfig to manage logical booleans (or, "features") was a bad idea.
> Could anyone think of a situation where this could affect us
> negatively down the road?  Or do you think it's generally a good way
> to manage these "features".
> 
> In the unlikely event that we change platforms to a different unix, we
> could easily implement an irix-like chkconfig to perform this
> functionality.  Would not be a large effort.
> 
> Thanks,
> David
> -- 
> Live in a world of your own, but always welcome visitors.