About using Linuxconf
I know a few months ago people were saying that linuxconf wouldn't work
with debian b/c of the upgradability issue. I have been talking to the
developer and he has as new system called dropins. There 'dropins' are
each like a rc.d script (from what I can tell) except linuxconf has more
control over them. I am including his web page that explains 'dropins'
vs. SysV type rc.d scripts.
Hope this assuages all your fears and maybe convinces you that linuxconf
is a good idea.
Linuxconf VS init scripts
---------------------------------------------------------------------------
Unix System V (SysV) init scripts are often seen as a
sophisticated configuration mechanism. Yet Linuxconf does not use
them. What's good and what's wrong with them.
---------------------------------------------------------------------------
The appeal of SysV scripts
Sysv scripts were created to solve a growing problem in Unix. Mostly, old
Unix systems were configured at boot time by running a set of scripts
generally named rc.something. Each software package had to hook itself in
the script, at the proper place. For example, some network services had to
hook themselves after the initialization of the basic network subsystems.
There were different problems associated with this:
* It was almost impossible to automate. Each new package had to be
installed almost by hand.
* The RC scripts were growing and growing, making them very difficult to
maintain.
* Updating or removing a package was almost impossible to do
automatically.
The solution was pretty simple to implement without breaking much. Just
change the main RC script and break it into a bunch of subscripts and place
them into a subdirectory. The main RC script will be simply a dispatcher
which will lookup all the scripts in the subdirectory and execute them one
after the other. To install a new service, just copy its own configuration
script(s). Different tricks were invented to enhance this further.
* Use the name of each script as a sort key. This provide a simple
scheme to control the order of initialization of each system. Systems
that have to be configure last give name such as S99mysystem to their
configuration script.
* One configuration script is use to start a system, another to kill it.
Scripts name starting with the letter S are used to start systems.
Scripts name starting with letter K are use to terminate systems.
* One directory is created for each runlevel.
The problem with SysV scripts
They are scripts!!!!
One of the key feature of SysV scripts is simplicity. Here are some things
which are lacking from those scripts. This is the price of too much
simplicity.
* They hides some configuration informations. To change some
configuration parameters, one has to edit manually the proper scripts.
This is not to user friendly.
* They are only used to start and stop the different systems. They are
useless (because too simple) to update a system after a configuration
change.
* They are primitive. When something goes hairy, they spits out a bunch
of errors and left most end user in the dark. All this looks pretty
bad. Or they blocks waiting for some events, doing some time-outs.
The current state of Linuxconf
As of Linuxconf 1.7, it is still pretty monolithic. Mostly because it knows
how to manage standard components of a Linux system. With more and more
packages (server package) appearing, Linuxconf has to introduce something
in the line of SysV scripts. Mostly something that support the concept of
independent add-ons. Here is how it will work.
Goals
Linuxconf can be enhanced easily to support a concept similar to the SysV
init scripts, but with a much better control and level of quality.
Linuxconf already support a concept of module which was planned to support
add-ons. What do we expect from those add-ons management components ?
* Easy to add. Just drop the file in a specific directory and Linuxconf
will take note.
* Easy to remove. Just remove some files and Linuxconf will forget about
those add-ons.
* May be logically removed or disabled.
* Must be write protected. Linuxconf should never modify the file. This
allows for safe upgrade without losing any configuration changes.
* Most of the job to create those dropin files should be handled by
Linuxconf user interface to help developers define proper
configuration/add-on file for Linuxconf.
>From now on, we will talk about dropins.
Principles
The dropins will be organized in several files and potentially in several
categories.
Basic dropin definition
A dropin must inform Linuxconf on the recipes needed to start it, stop it
and so on. Further, it must tell Linuxconf when this must happen. A dropin
is an ASCII file which is copied (dropped) in /etc/rc.linuxconf/crontrol.
Each line hold a field in the form
keyword value
Here are the field common to all dropins.
Keyword Description
progname Name of the main process so Linuxconf can monitor the
process age and compare to the revision date of the
configuration file it monitors.
title Free form one line text. This will be used in dialogs
when presenting the dropin.
Linuxconf's modules dropins
A dropin file is normally used to provide information about an optional
Linuxconf's module. Those modules are created to manage a system. They know
how to activate it, how to manage it (Configuration) and so on. Those
modules are tightly hooked into Linuxconf API so module behavior can't be
differentiate from Linuxconf built-in controls.
For Linuxconf's module, the following lines are added to the dropin control
file.
Keyword Description
module Path of the module.
The simple dropins
Dropin are extended a little bit to support a concept of simple dropins.
This mechanism should be used for the following tasks.
* Adding package activation on site. This should make the rc.local file
obsolete. A menu in Linuxconf with let the administrator define new
dropins. The same menu will be used by package maintainer to create
the needed dropin for their packages.
* Create dropin to make Linuxconf compatible with a given distribution
(not originally Linuxconf aware). These dropins would be distributed
with Linuxconf but installed separately. They will be simple hook
pointing to the different RC script for components not managed by
Linuxconf.
In its simpler form, a dropin is only use to activate/control a system. It
does not carry information to configure this system. This is the cheap way
to get it going. Creating a complete Linuxconf module is by fare the
prefered way which will help user taking full advantage of your package.
Ultimately, the dropin provide enhanced information for a standard SysV
init script. Here are the fields added to a dropin control file.
Keyword Description
startlevel Network mode where the dropin should be activated. It
can be any of the word local, client, or server.
Further, the word boot is allowed for tasks which must
be done once at boot time.
stoplevel Network mode where the dropin should be stopped. A
dropin may be activated in server mode, but terminated
only when the station is brought to local (no network
mode) for example.
startafter Activate this dropin after an other dropin. All
Linuxconf's built-in control may be considered also as
dropin, so a dropin may be started right after a
Linuxconf built-in one.
If a dropin must be started after a dropin which is
disable, Linuxconf will issue a warning about the
"depending" dropin which won't start also.
start command to start the service.
stop Command to stop the service.
reload Command to restart or reload the configuration file.
monitor Files to monitor to know if the service must be
reload/restart.
pidfile Path of the ASCII file containing the process id (PID)
of the main program.
One will note that the simple dropin has much more detail than the previous
one. This is so because a Linuxconf's module implement all these features
using the Linuxconf API. It has much more intelligence than a simple
scripts.
A simple dropin for inetd
progname inetd
start /usr/sbin/inetd
stop killall inetd
reload killall -HUP inetd
monitor /etc/services
monitor /etc/inetd.conf
Directory structure
The dropin component will be store in /etc/rc.linuxconf/control. The
modules will be store in /etc/rc.linuxconf/modules.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: