Re: RFC: A method to use Admin tools, like linuxconf
Manoj Srivastava wrote:
> 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.
same for me. (and my english is still in 0.0.1beta1)
>
> >>"Shaya" == Shaya Potter <spotter@itd.nrl.navy.mil> writes:
>
> 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.
there are several things to do :
- move the config values in some scripts (like etc/init.d/boot) into a
database.
- there should be tool to access this database
- (maybe) change the current init method with /etc/rc?.d/* links to a
config file method
- the config values for {pre,post}{inst,rm} script should be saved and
re-used (or whatever you want to do with that).
- there should be a nice gui to configure everything, with help texts
etc.
to make live easier, we shouldn't mix theese things.
> 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.
you are talking about the /etc/{init.d,rc[0-6].d}/ boot mechanism, i
guess...
i like the idea to have a nice cfg file (and for newbies : a cfg util),
to change theese things. i don't like the links.
one of the key features to use unix are it's great editors. i like them.
but i hate to reorganize links with ln and rm (i know, it's the same
basic system, but editors are easier to use IMO).
this will be incompatible, but that's ok, if we have a better mechanism.
> 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?
if you store the answers to the config part of a debian package
installation - where will that help you ? i tried to find out, but i
found nothing. in most cases that script yust forces me to give a
default value, and that value will be storred int the run time
configuration.
> 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?)
if i understand shaya correctly, the database file will hold default
values for the run time configuration database (look at
/etc/init.d/boot). IMO the config scripts of debian packages only cover
the case, that there can not be a default value, and they force the
system admin to enter one. for this cases, the database will hold an
illegal, empty value, and the preinst script will force the system
administrator to enter a valid value).
> 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.
the database has nothing to do with the rc.d links, IMO.
they could be replaced with a nice config file. the database should not
hold any informations, e.g. uucp config will be storred in uucp config
files, not in a database. don't make the same mistackes like the german
suse distribution : it storres all informations in a file called
suseconfig, and generates everything from this file (including ifconfig
calls, isdncrtl calls, uucp config files etc). you can still edit the
normal config files no your own, but any time you start the admin tool,
all your changes will be lost/overwriten. you can also edit the file
suseconfig with and editor, but editing such a long file without
comments etc. is a pain.
> 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.
IMO the rc?.d structure should be moved into a config file, not into the
database (the database is IMO only a central deposit to get rid of
one-line config files and to seperate config values from scripts).
another point:
the database/textfile/rc?.d links are to configure which programs are
startet at boot time. but some of the scripts in /etc/init.d/ like
netbase and netstd_nfs are starting several daemons, so they are also
to configure which programms are startet at boot time. and if you look
at the scripts, most scripts only differ in the options to start-stop,
and they are a mix of code and config values.
IMO /etc/init.d is an ugly thing, any cleanup would be nice.
> 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.
in many cases it's faster to edit a cfg file, than to start a gui and
try to find the menu to configure something. of course we need a gui,
but i want the option to work without a gui.
we will need to change many things, to seperate code and scripts (that
will include many scripts in /etc/init.d), so IMO we should make a good
new system, rather than to have a half changed, half compatible system.
> 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.
if we have a config file instead of the symlinks, every package will
only add one more line / remove them. christoph hase some sort of a
mechanism for /etc/inittab and other files, it can include this file,
too. update-rc.d can be replaced by a small script to do this, untill
all packages are changed.
what do you mean with admintool ? the gui ? the database ? update-rc.d
replacement ? of course we can have several gui's, but having several
databases for system configs will confuse everyone.
for what do you need the configure ? will this be the interface to the
database, the gui, or what ?
> 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.
update-rc.d can be replaced by a wrapper - no packages will need to be
changed.
> 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.
IMO the rc.d system should be replaced by config file, and not storred
in the database. the "database" data shouldn't store everything, yust
the defaults for the config database. IMO dpkg should call the database
to import the "database" file, before it run's postinst... (or what did
you think - who should call "configure" ?).
maybe i or we yust mix the words "database" (like runtime database,
replacement for values currently storred in scripts like
/etc/init.d/boot), "database data" (default values a package provides to
be added to the database), "configure" (a interface to the database ? a
script provided by the package ? a script provided by dpkg ? (IMO: a
script to parse the "database data" and import it into the "database",
ask if one of the values in the "database" or "database data" is
undifined, and execute commands provided by a file called "configure
data". the configure should be called by dpkg (or should be a stand
alone program using dpkg's database). "configure data" will be a file
proviede by packages with commands to configure the package (like
GENERATE apache.conf FROM apache.dist USING DATABASE VALUES ...)
> 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.
if we change the rc.d methods, there are a lot of things we can improve :
a) some scripts are starting several daemons. do i have to configre
update-rc to start the script, and change the script to start the
daemons i want. ugly
b) some scripts still have config values. ugly.
c) most script are only start-stop calls. todo this we don't need scripts.
d) i would like to see start-stop or somethink like that whatch the
daemons started and put them into background if they don't do it on
their own (when i was new to the linux config mechanism, my boot
system hanged several times when i forgot a "&". other newbies make the
same mistakes. )
> 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.
there could be several gui's working with the same database. what do you
call admin-tool ? the gui ? the database ?
> 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.
a) change the rc.d mechanism or b) don't do it. but having both - a
database and links is an invitation for inconstistency - and that will
be fatal. thats not a good idea IMO.
> 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.)
as far as i read the database discussion we have several database tools,
but neither a result which one to use, nor how to store the data (in
text form, in binary form. one big files - mutliple files in a
directory), nor how to read the database (via database command call, via
bash source function to read the fragments), nor what to storre (only
values, descriptions, default values, dependencies (so we can get rid of
cfg data in the dataabe when uninstalling packages)).
but these problems will be solved be the one, who writes the tools.
discussion will not help.
regards andreas
--
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: