Re: RFC: A method to use Admin tools, like linuxconf
Hi,
This is a long post, and it took some time for me to write
this, please bear with me and read this through before unslinging the
flame thrower.
>>"Shaya" == Shaya Potter <spotter@itd.nrl.navy.mil> writes:
Shaya> Pleae remember that this is my first stab at writing a document
Shaya> like this, they don't teach skills like this in my high school,
Shaya> so obviously I am lacking a little, any constructive criticism
Shaya> will be appreceated for writing documents like this.
Shaya> PURPOSE: This RFC proposes a method for linuxconf, or any
Shaya> future admin tool, to be plugable into Debian with a
Shaya> minimal amount of trouble.
Shaya> REASON: Many people, including myself, have asked "Is it
Shaya> possible that we can use Linuxconf with Debian."
Shaya> Linuxconf is a good thing, but for a person to use it
Shaya> under present conditions in Debian, would mean that he
Shaya> would have to give up any future upgradability. If we
Shaya> were to move to linuxconf, it would have the side
Shaya> effect of being incompatible with any future admin tool
Shaya> that comes around, and it most likely would even be
Shaya> incompatible with plain SysV init. There has to be a
Shaya> more elegant solution.
Why would it be incompatible? what does SysV init have to do
with most package's configuration? Or are you saying that apart from
allowing packages to be configured, we are also proposing to change
the startup or boot time process for Debian?
We could have a database of configuration key value pairs,
managed by an as yet undetermined admin tool, which allows packages
which look at initialization or "run control" scripts to modify their
behavior on user request (the package has to co-operate in any case).
I do not see a need to shelve SysV init just to have an
easy configurability on my machine. A solution should probably
incorporate the config database people are talking about w.r.t an
mostly unattended install/upgrade, where all packages ask questions
at the start, and the answers are kept in a database, to be used
later in installation. The same database, if persistent, can hold run
time configuration. Why duplicate such a database?
But maybe you are not talking about package configuration at
all, maybe you are talking about starting and stopping
processes. AHA!
----------------------------------------------------------------------
Shaya> ABSTRACT: Each package would contain a "database" file, in addition to
Shaya> the control, and {pre,post}{inst,rm} scripts. This
Shaya> "database" file will contain fields, that a
Shaya> "configure" program can use to create the appropriate
Shaya> files for the admin tool, so that the admin tool can
Shaya> know about these new packages.
This is unclear. I guess that the gist is that the package
contains information that is used by a configure program (whatever
that is -- is this install time configuration of the package, or a
configuration utility for the site, in which case what is the admin
program?) which massages it into a format understood by an admin tool
(what exactly is an admin tool supposed to do?)
I think we need to address configuration that goes beyond
merely starting or stopping programs.
Shaya> PROPOSAL: Right now every package that needs to install init scripts,
Shaya> call "update-rc.d" to "tell" SysV init about these
Shaya> packages and when it needs to run them. This idea
Shaya> can be taken further to include any admin tool that
Shaya> wants to take over the system. We can keep our
Shaya> start-stop daemon and the scripts in /etc/init.d for
Shaya> starting and stopping the programs and with the
Shaya> addition of the "database" file, we can provide all
Shaya> the information the admin tools will need to
Shaya> configure themselves.
I see. You wish to take the rc?.d structure of linked lists
which uses the file system as a database (and is easily visible by
standard commands like ls), and move it into another database that
does not use the file system (and is IMHO, more opaque), and have an
admin tool decide which script is run when.
Why? What's in it for us? Can't we write a simple pretty GUI
that looks at and manipulates symlinks? Which will then be compatible
with our current system? Why throw out a system that is known to
work, and is compatible with many other unices, for what seems to me
(again, IMO) marginal gains?
Methinks writing the gui admin tool is less work than rippping
out the guts of our boot sequence.
Shaya> Instead of each package calling "update-rc.d" in their postinst
Shaya> scripts, they will call a generic command, "configure" will
Shaya> call it. Each admin tool will provide their own version of
Shaya> "configure" and their "configure" will know how to build the
Shaya> appropriate files for the admin tool from the "database" file
Shaya> in the package. This can enable us to support many different
Shaya> admin tools without making the maintainer go through any more
Shaya> work.
As lomg as they support this new database. Wel,, I say that
we already have a database, implemented in the file system, and we
already are ready for admin tools to come in and do their work. And
we don't even need to change any packages.
Shaya> The "configure" program will take the "database" file contained
Shaya> in the package (which can possibly be folded into the central
Shaya> database idea) and by using fields in it such as STOP and START
Shaya> (which should be /etc/init.d/(script) {stop,start}). The
Shaya> "configure" program will take the database file, and use all
Shaya> the fields in it that it needs, and will build the appropriate
Shaya> files, "drop-ins" or whatever the admin tool needs, so that the
Shaya> admin tool will "know" about these new packages.
We already have this information in place, we even know which
order to start packages in, we know which package to start in
emergency mode, which to use in single user mode, and which ones to
kill as we go the reverse way.
Our configure tools happens to be distributed into various
packages postinst scripts calling the install rc.d script.
Don't reinvent the wheel. Get a better admin tool that will
work with us, and understand how our packages set up the database (by
calling install scripts in postinst), and how we keep the persistent
data around (symlinks in run level specific directories.)
Shaya> In order to ensure that only one admin tool is installed at a
Shaya> time, the packages that these admin tools will be part of
Shaya> should PROVIDE, CONFLICT, and REPLACE the virtual package
Shaya> "admin-tool". According to my limited knowledge of how the
Shaya> dependencies work, this should prevent two admin tools from
Shaya> being installed at once.
As long as our ``database'' is common to all these admin
tools, we may even have multiple ones on at once! Far better than all
these incompatibilities. Just make the admin tools work with our file
system based database, is all.
Shaya> In order to keep backwards compatibility with SysV init, in
Shaya> case anything goes wrong, each admin tools "configure" program
Shaya> would also perform the same function that "update-rc.d"
Shaya> performs now. It would install the appropriate links into the
Shaya> /etc/rc{1,2,3,4,5,6}.d tree. This would also provide us with
Shaya> the ability to remove an admin tool, and keep a perfectly
Shaya> usable system for keeps or until a new admin tool is installed.
Shaya> Each admin tool would also copy "default_configure" to
Shaya> "configure" in their prerm scripts. This program would act
Shaya> just like plain "update-rc.d" acts now, it will just install
Shaya> plain links into the /etc/rc{1,2,3,4,5,6}.d tree. This will
Shaya> ensure that SysV init will always be in working order.
In which case, why the database? what additional information
are we keeping in there? I see the need for admin tools, as you put
it, but no need to change packages and throw out SysV init.
Shaya> By having the capability in Debian, of having the ability to
Shaya> use different admin tools if you want, or none if that is your
Shaya> wish, we will in many ways leap far ahead other distributions
Shaya> in our configurability, while still retaining our ability to
Shaya> upgrade the system with ease. This would continue the
Shaya> tradition of packages like menu, which enable many packages to
Shaya> work in a harmonious way with our system installed
I agree. All we need is admin tools that understand our
current database implementation. (It should not be too hard to parse,
and change, the information encoded in the symlinks, the hard part is
designing and implementing the gui.)
manoj
--
A university faculty is 500 egotists with a common parking problem.
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
--
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: