Date: Fri, 29 Jan 1999 09:06:19 -0500 From: Robert Withrow <witr@rwwa.com> To: Konstantin Chuguev <joy@urc.ac.ru> Cc: Brandon Gillespie <brandon@roguetrader.com>, freebsd-hackers@FreeBSD.ORG, witr@spooky.rwwa.com Subject: Re: more modular rc/init/uninit system... Message-ID: <199901291406.JAA27108@spooky.rwwa.com> In-Reply-To: Your message of "Fri, 29 Jan 1999 13:38:55 %2B0500." <36B1739E.1A22A983@urc.ac.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
joy@urc.ac.ru said:
:- I prefer to see all variables WITH their values (read "system
:- configuration") in the one file.
I absolutely agree. I've used (and developed) both systems for
a long time, and I think there are some strong plusses and minuses
for both systems:
BSD plusses: All configuration variables are in one place. This is
a *HUGE* plus for newbies (they need only look in one place and understand
how to edit) and for installations with *lots* of systems (because
bulk configuration is *just* a sed script on *one* file. Additionally,
a systems configuration can be documented by printing out this *one* file.
Doing basic things like enabling/disabling subsystems is simple.
BSD minuses: Relationships between installed components is hard-coded
in the rc files by the placement of code. Installation of packages
is complicated by the need to edit rc files to insert code. Installation
of a new package can cause old packages to break. In a word, it is
unmodular.
SYSV plusses: It is much more modular. Installation of new packages is
very simple: just put your config script in the correct directory. Also,
there is an enforced regularity of the configuration scripts that makes
them *individuall* more understandable.
SYSV minuses: Configuration variables are scattered across the many
confugration scripts. Altering confiuration is harder both for newbies
(they have to be taught where to look and often how to alter shell
scripts and not just change values in assignments) and for installations
with lots of systems (you have to do lots of seds and directory walking,
and linkining/unlinking. Documentation of system configuration is harder
because there isn't just one file to print out. Basic operations like
enabling/disabling a subsystem are harder (because deleting or renaming
a link is less "obvious" than changing something to say DISABLED. A
*huge* minus with the SYSV system is that relationships between installed
components is *still* hardcoded due to the links in the rc.n directories.
This creates lots of problems. For example if you disable component X
that is needed by components Y and Z, Y and Z will still try to start
and will fail, with possible negative consequenses. The SYSV method
still sufferes from unmodularity.
In the past I suggested a scheme (which many didn't understand, and which
I didn't [and still don't] have time to implement) that I'll suggest again.
I think this overcomes the minuses above and keeps the plusses.
1) a packages boot-time configuratnio script is packaged in a seperate file
and placed in an init.d directory, as in the SYSV system. These scripts,
however, define shell functions with conventional names, instead of being
a case statment as in SYSV. Each <package> file would contain:
a) a ini_<package>_start function -- Starts the subsystem.
b) a ini_<package>_stop function -- Stops the subsystem.
c) a ini_<package>_requires function -- Declares the "requires"
relationships with other packages by calling the "ini_requires"
function for each package required by this package.
d) a ini_<package>_conf function -- Declares the configuration variables
*and* their defaults by calling the "ini_confvar" function for
each configuration variable (arguments are variable name, default
value, and comment). There would be a minimal set of *required*
configuration variables, like "ini_<package>_enabled",
"ini_<package>_path", and the like. The goal would be to
have *nothing* hardcoded in the _start and _stop scripts.
2) At package installation time the package installation script executes
the "ini_register" script with the <package> name. The ini_register
script sources the <package> init script *and* the rc.conf script. If
the symbol "ini_package_<package>" is defined it does nothing. Otherwise
it calls the ini_<package>_conf function, and for each configuration
variable, it appends a line to the rc.conf file with the variable, the
default, and the comment. At the beginning and end of this section
would be a easily recognizable marker, like
"#====Begin <package> configuration" and "#====End <package> configuration".
3) At start-up time the master start-up script would source *all* of these
scripts, thus defining all the functions. It then sources the rc.conf
script. It calls all of the ini_<package>_conf function which will define
a value for each configuratin variable that is *not* defined in the
rc.conf file, with its default value. It would then call the
ini_<package>_requires function for each of the packages to gather the
requirements, and would topologically sort the *enabled* ones. Then, in
this sorted order, it would call each of the "ini_<package>_start functions".
Of course, if a package required another package that was missing or
disabled, an error would be produced and that package would be ignored.
4) And shut-down time, a similar process would be followed, except that
the _stop functions would be called in *reverse* topological order.
5) When removing a package the ini_unregister script would be called.
It would remove the configuration section (or perhaps just comment it out)
from the rc.conf file.
---------------------------------------------------------------------
Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901291406.JAA27108>