Re: RFC: A method to use Admin tools, like linuxconf
This is just a partial response, not feeling to good, so a better
response will follow.
On 19 Feb 1997, Manoj Srivastava wrote:
> 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.
If anything people should flame me, this RFC was my idea. :-)
>
> >>"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?
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.
>
> 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?
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.
>
> 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.
>
> ----------------------------------------------------------------------
>
> 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.
>
> I think we need to address configuration that goes beyond
> merely starting or stopping programs.
Linuxconf does that. I was playing around with it, and it is Awsome in
many respects. It can configure Sendmail, DNS, linux's firewalling, user
info, set up ppp, slip, create accounts for PPP, POP, almost anything.
It seems to be a very good thing. It seems easier than anything
Microsoft has come up to configure their operating systems. Oh, and it
supports 4 types of access, cmd line, ncurses, X, and by web. I think
Debian can really use a tool like this, it just matters how we can
integrate it with Debian in an appropriate fashion.
>
> 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.
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.
>
> 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.
>
> 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.
>
For an admin tool only, yes. But not for my main focus of a boot/init
manager. Actually init manager is better description than boot manager.
> 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.
That is just a backup, Linuxconf has extra features which I'll post a
fwd'd message from the maintainer of it, to the list soon. So we will
keep SysV init around, but won't use it, unless we want to, or in case of
emergancy
>
> 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
>
Shaya
--
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: