[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: A method to use Admin tools, like linuxconf

On 20 Feb 1997, Manoj Srivastava wrote:

> Hi,
> [this is getting to be fun]
> >>"Shaya" == Shaya Potter <spotter@itd.nrl.navy.mil> writes:
> Shaya> Let me start off fresh with the plain idea no fancy language.
> Shaya> right now a packafe includes the init scripts and puts them in
> Shaya> /etc/init.d/ it then tells SysV init when to launch them by
> Shaya> running update-rc.d.  This installs links into the rc*.d tree.
> Shaya> This is limiting in the fact, that if someone wants to use
> Shaya> linuxconf, it is almost totally incompatable with debian.
> 	Right. Of course, I'd say (putting the emphasis the other
>  way), Linuxconf is totally incompatible with debian, and that limits
>  Linuxconf (can we get it to change? ;-)

see my previous message about meeting half way.

> Shaya> What I tried to propose is, 1. we give a little abstraction
> Shaya> layer to update-rc.d, what I called "configure".  This
> Shaya> abstraction layer is the database file.  The database file
> Shaya> should never be consulted after dpkg configures the package,
> Shaya> unless perhaps we want to reconfigure the system.  What my
> Shaya> modified version of update-rc.d, or the "configure" program
> Shaya> each package installs, does is to parse the database file and
> Shaya> creates what files that package needs, such as linuxconf's
> Shaya> dropins.
> 	Do not store the same information in two lpaces, unless you
>  are willing to invest a great deal of effort in synchronization and
>  coherency tools. Second, all the data that you want to put into the
>  database already exists on the file system.  Is there a technocal
>  reason to require a formal database, with the added opacity, to this
>  situation? Do we need formal database advantages? 

The database file, will be in /var/lib/dpkg/info, under 
package_name.database.  This file will be removed when a package is 
removed.  The only reason it will be kept around is for use in 
reconfiguring packages.  The database will not be used for anything 
except configurations. AGH haven't I said this already.  The file system 
will be constructed from the databse file I am proposing.  The database 
shouldn't be any more opaque b/c it should never be seen.

> Shaya> I don't want to get rid of init.  I believe we can live with
> Shaya> SysV init.  We might not even include Linuxconf in the main
> Shaya> distribution at first, put it into contrib, but at least put
> Shaya> more hooks into the release so that it is easier to use it.
> 	I vote we put more hooks into Linuxconf to make it easier to
>  use on Debian systems ;-) ;-) ;-) (I *am* trying to make a point
>  here).

I agree, bu twe can do out best to meet them half way.

> Shaya> Now that I have digressed a little, let me get back to what I
> Shaya> was saying, what I am proposing does not involve putting
> Shaya> anything in any proprietary database that is looked up at boot
> Shaya> time, configuration is done at package configuration time, just
> Shaya> like we run update-rc.d.  Instead of update-rc.d putting
> Shaya> symlinks into the rc*.d tree, it does whatever is neccesary for
> Shaya> the init manager.  Is this clear.  I am not proposing a
> Shaya> structure for this database file, that is a topic for another
> Shaya> discussion, hopefully once we get over this hump.
> 	My question is, why? Is there a technical requirement for
>  this?  Remember, we have to invest time and effort, which may be
>  spent better elsewhere. This new method will also have to be tested,
>  and the glitches worked out. I need to be convinced of the
>  superiority of your methos before I vouchsafe it. 

So we can put it in experimental or contrib for a little bit b/4 we allow 
it into the standard distribution, we may even design a stress test for 
it, see what it can handle and what we can do to make it break.

> 	Also, I think that symlinks in directories are simpler.	Never
>  under estimate the value of the KISS principle. 

I agree, but then there is the ADA approach, hey its hard to start a 
project, but look what happens when the military has to upgrade weapons 
in the field, much easier.  This isn't about ADA though, don;t bring in 
ADA, my father was one of the people that helped design it so I don;t 
want to hear anything about it :-).

> Shaya> To answer the question of Linuxconf storing configuration data
> Shaya> in proprietary places, IT DOESNT.  It uses the standard tools,
> Shaya> so it must store their configuration files in their standard
> Shaya> places.  Some of the other data, which doesn't have a standard
> Shaya> place to put the configuration data, like ethernet stuff, it
> Shaya> puts in its own configuration file (at least from my
> Shaya> understanding of linuxconf's docs.)  It actually detected many
> Shaya> of my setting automatically on a test Debian system I installed
> Shaya> it on, by reading the standard files, and it would write
> Shaya> changes to those files.
> 	And it reads data from the standard locations as well? (so my
>  changes are not lost). If this is so, why are we having this
>  discussion? Seems to me that Linuxconf can be put into place
>  transparently, and requires no action from the general developer
>  community. 
> 	Oh, sorry. It puts *Standard* data in the usual place, but
>  everything else goines in a non-standard place determined by
>  Linuxconf. Hmm. Hmm. Could you tell us what the file is, please? (I
>  don't have access to LinuxConf). And what format the data is kept in?

I havent been able to play around with Linuxconf as much as I want to, 
but I would think it something like linuconf.conf, I'll have to check, I 
think it is also a text file.  Its hard to play around with it b/c I 
don;t use Slackware anymore, only Debian :-), and since we don't support 
it, I don't want to delve into it to much.

> Shaya> Now if you don't like the fact that linuxconf puts all the non
> Shaya> standard data in one file, we can probably work with its
> Shaya> developers to split that data up, and maybe put it into files
> Shaya> which make more sense, (Hey we may even be able to publish a
> Shaya> standard which other Distributions can follow).  More examples
> Shaya> of this data which doesn't have a standard place, is the Linux
> Shaya> firewall rules.  Usually you would just call ipfwadm by hand,
> Shaya> linuxconf will set the rules for you.  Since their is no
> Shaya> standard place of putting this data, linuxconf stores it in its
> Shaya> own file, which as I said b/4 I think is plain text.
> 	I wholeheartedly agree! Yes!


> Shaya> Well, please respond.
> 	You got it.

Well how do you like my response. ;-)


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: