red hat chkconfig to manage logical booleans?

[David Alban]

Greetings,

This is more of a developer-in-general/sysadmin-in-general type of
question...

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, since we're a red hat shop, why not use red hat's
chkconfig for this, instead?  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 thought that using red hat's chkconfig to
manage logical booleans (or, "features") was a particularly bad
idea.  Could anyone think of a situation where this could affect us
negatively down the road?  Or do you think could be 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.  We're not worried about
that.

Thanks,
David
-- 
Live in a world of your own, but always welcome visitors.