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

Re: Linuxconf



On Fri, 10 Jan 1997, Craig Sanders wrote:

> 
> On Thu, 9 Jan 1997, Shaya Potter wrote:
> 
> > > the biggest problem with linuxconf is that it replaces sysvinit.
> > > Linuxconf has some really nice features and seems like a
> > > comprehensive configuration system BUT even if it was 10 times as
> > > good it still wouldnt be worth losing sysvinit.
> >
> > What I was proposing on debian-devel would mean you can have both.    
> > The linuxconf dropins would point toward the /etc/init.d scripts and  
> > when each package configures itself just like it calls update-rc.d    
> > now it could call a "configure" program.                              
> 
> that's partly missing the point.  init and linuxconf fulfil two separate
> functions.
> 
> configuration of a system and/or it's applications is an almost
> completely separate function to controlling what daemons get started and
> when.

I would personally like that to be the case too, (and if I had the 
ability to write a program like linuxconf I would have written it that 
way).  However, I didn't write it, but I still think it is the best tool 
for configuring a linux system and with minimal work can be made to work 
with debian.

> 
> I really don't want my system automatically restarting some important
> daemon just because i've touched it's config file - if i want it
> restarted then it's up to me to take some action which forces it to
> happen.

I agree with that and that is why we don't need to have linuxconf use the 
monitor lines in the dropins.

> 
> here's a good example of why: squid. when it restarts, it can take
> literally hours (depending on the size of the object cache it's
> managing) for it to completely read in it's log file and know what
> objects are already cached. This isn't a big issue if you're only
> caching 50 or 100mb of web traffic, but is a huge issue if your proxy
> machine has 4 or 8 or 20 GB of disk space dedicated to the task. I need
> to be able to edit squid's conf file at any time and schedule a restart
> for a time that suits me and the users dependant on it.

I understand, but even if you wanted it to restart automatically, all it 
would take is editing a single line in the dropin

> 
> Also, there are other daemons and processes which rely on important
> state-dependant information which will be lost when they are terminated
> and restarted. Having that happen automatically whenever a config file
> is touched strikes me as being not only inflexible, but also potentially
> dangerous. i don't want my system second-guessing me.
> 

Again, don't have to have a monitor line.

> 
> i'd be a lot more inclined to like linuxconf if it confined itself to
> managing configuration information and left init's job to init....and
> left my job to me.

I agree with you first point, but we can easily make linuxconf let you do 
your job.

> 
> A configuration engine's job is to make it easier to configure and
> use EXISTING configuration methods, not to force everything into it's
> mold. In other words, it has to maintain continuity with established
> standards.
> 
It does mostly, however I do know the init issue is a big issue.  I might 
talk to the linuxconf developer to see if we can get it better 
intergrated with init.

Shaya


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: