[very long]Re: RFC: A method to use Admin tools, like linuxconf
On Wed, 19 Feb 1997, Shaya Potter wrote:
> What I am trying to propose is a way so that Linuxconf, which would like
> to take over the boot process, i.e. become an activator of programs. It
> would be called from /etc/boot and would take over the process of
> starting daemons from SysV init.
Shaya's idea of introducing a level of abstraction into the
system startup facility is a good one.
>
> >
> > 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 we have a database store configuration data about each package,
and an interface to that database to retrieve that data, we can
use these to write simple interfaces to such a system for any
arbitrary admin tool/ system startup mechanism. The problem is
determining the correct place to introduce the abstraction. It
needs to be done in such a way that it doesn't break anything,
and isn't required for system management. This is tricky.
> >
> > 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?
Every package should also come with defualt values defined for
everything requiring a definition, so that the user can just
instal it if she/he wants. These values could wear tags that say
"default". there could be otehr tags that say "snappy" and
"wacky". Changing from a default profile to a "snappy" profile
would then be as simple as changing the preffered value tag when
looking up the run time config values.
>
> We don't need to shelve it, I explicitly wrote this RFC to say that
> people can have a choice. In many respects Linuxconf's dropin's are
> better than SysV init scripts. Some people may want to keep SysV init
> that way it is, they can, and people who want Linuxconf can have it, and
> if any other tool that wants to take over the boot comes around, people
> can probably use that too.
Aha! The startup scripts installed by the packages are a good
place to look for a possible abstraction layer. The
start-stop-daemon was a good idea that helped to standardize the
way processes start and stop at start time. Without seeing
Linuxconf's dropins, it seems that it may be possible to create
start/stop scripts that check the (still totally vapor) database
to see how to start things. The linuxconf dropins, or any other
similar element, could do the same. Each piece of a startup
script should be associated with the package, and a flag (or set
of flags) be associated with it, to inform the possible tools of
how (or if) to run its startup routine.
The database format should allow for "on the fly" additions of
tools and associated flags. The flags that identify a tool for
control over a processes startup, etc. should be mutually
exclusive.
So far this is sounding pretty s l o w . . .
>
> >
> > But maybe you are not talking about package configuration at
> > all, maybe you are talking about starting and stopping
> > processes. AHA!
>
> Yes. It just happens that Linuxconf does both. I probably shouldn't of
> used the term "admin-tool" but that is what Linuxconf is.
Storing both sets of data in the same database makes sense. It
should be associated with the package though -- not the actuall
binary.
>
> >
> > ----------------------------------------------------------------------
> >
> > 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?)
>
> It is just like update-rc.d, it takes input and makes the appropriate
> files or links. This is so Linuxconf can know about the packages if you
> want it to stop/start the programs.
The interface to such a database should be generally useful so
that package maintainers could do as they wish "out of the box".
different packages' programs look for run time config data in
different ways, so the reliance on this database has to be
through a flexable interface -- and again it can't break anything
or be _required_. People should be able to administer systems
the way they've been doing it without having to change. Of
course, if we do a good job of implementing this, people will
want to change :-)
>
> >
> > I think we need to address configuration that goes beyond
> > merely starting or stopping programs.
agreed, and probably in the same databse, but not in the same
tool, necessarily -- or in the same place (within the system).
> >
> > 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.
>
> In a way yes, but I am not saying to get rid of SysV init. Also the
> database file wont be used by the (admin/booting) tool, it will only be
> used to created what files it needs. It can be the same file structure,
> if you are using SysV init, or it can be a more opaque database, or a
> collection of dropin files that Linuxconf uses, which are pretty easy to
> understand when viewed.
I think it would be better if the databse was used to store data
about a package such as which tool to use to start it up (i.e.
package inn has a binary called innd and innd has a flag
"startup=linuxconf"). This way, the system scripts stay inplacve
without needing to be changed. They just have a reference to
check the database to see if they should do anything or not. It
could even be done at a higher level (e.g. in rc) where
every package with a need to have run level start/stop management
gets looked up up front to find out its preferred method.
By the by, this same databse could easily be used to store run
level information as well. That would obsolete the need for
linking the start/stop script (or future possible replacement) to
every run level.
>
> >
> > 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?
>
> I am trying to propose a method where we don't just have to use SysV to
> start programs, we can use anything we want, if we can write a configure
> program for it.
Exactly. The point should be to be fully backward compatable
with the status quo. The system shoudn't be required, and should
probably take a back seat to conventional norms for run time
configuration type stuff. Having a flexable interface to all of
a packages associated data would simplify writing an interface to
_any_ admin/configuration tool. We, of course, would need to
define what data is or could be associated with a package.
>
> >
> > Methinks writing the gui admin tool is less work than rippping
> > out the guts of our boot sequence.
>
> Yes, but I don't want to rip the guts of our boot sequence out, just make
> it that we can use other boot sequences.
>
> >
> > 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.
>
> Yes, but writing the configure script should be pretty easy once you
> already have a tool. I am not saying that the database file will be used
> for anything after dpkg runs the postinst script. The database file is
> just to configure for whatever tool you want. It is trying to create an
> abstraction layer between the packages and the system. i.e. we will be
> able to use whatever tool we like, just like with the window managers we
> can use whatever window manager we like and get all the debian menu's as
> long as the window manager supports the menu package.
>
> >
> > 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.
>
> Yes, but not in an abstracted way. Yes if I were to install Linuxconf
> now, I could probably do something that made it know how to deal with our
> scripts, well maybe not me, my level of programming experience classifies
> me as a nincampoop (or however you spell that word :-) ).
>
> >
> > Our configure tools happens to be distributed into various
> > packages postinst scripts calling the install rc.d script.
>
> Yes, that was where I got my idea from.
>
> > > 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.)
>
> This is where I messed up, don't think of it as an admin tool, but as a
> boot manager, hey i like that description (thank you OS/2). Yes, all I
> am trying to propose is a way to use different boot managers, not of the
> LILO type, but of the SysV init type.
>
> >
> > 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.
> >
I agree.
Thanks
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
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: