Re: Proposal: A config file for runlevels (DRAFT)
At 09:34 PM 1/1/97 +0100, Winfried Truemper wrote:
>Shaya Potter <spotter@itd.nrl.navy.mil> wrote:
>
>> What I mean is, we have a package for netstd. This package's "database"
>> file (someone think of a better name) will contain information such as
>>
>> SCRIPT: (what script to figure out start and stop commands)
>> MONITOR: (files to monitor for changes, for automatic restart [a linuxconf
>> feature])
>>
>> and there can be many more items.
>
>In the history of Debian such information was hidden in the
>init.d-script. For example behind the "reload" and "restart" options,
>in the future there may be "startlog" and "stoplog". "start" and
>"stop" are an existing standard that is extended by those options.
>I like these options because they are _simple_ and quite comfortable if
>you administer your box manually (for whatever reason).
I don't mean that there should be a file that is sourced every time you
boot, but that on configure, just like we run update-rc.d now, we would run
a similar command later and each tool could provide a utility that makes
the files it needs. The reason I proposed this is b/c this enables us to
use linuxconf or any other tool (If you want to, but can stick with plain
SysV init if that's what you want). On configure, what ever package you
have installed will run "configure" and the appropriate drop-in's or
whatever the program needs will be made. We can achieve the same thing by
just overwriting update-rc.d with the version we have for our program.
>
>Admintools like "linuxconf" should take advantage of such options
>instead introducing a new scheme. The same is true for most
>information in the "dropins": they could be obtained from the current
>links in /etc/rc?..d/ and could be written there, too. What would be
>left in those dropins would be the "monitor" and the "startafter"
>information. I doubt that both are useful and so I would drop this
>implementation of dropins completly.
>[ "monitor" is restricted to files and don't catch the cases where
>there is runtime information to monitor; beside this I don't _want_ an
>admintool to restart any daemon automatically if I modify a file (if
>this would be a good thing, most daemons would have built this
>function in). ]
In a way they do use these same options. What I proposed was that the
start command would be /etc/init.d/(program name) start and etc. for stop.
The extra fields would just be there if there is a certain file that it
would be "safe" to restart automatically after it has been edited.
>
>Maybe this is the reason why "linuxconf" was not adopted by any Linux
>distribution over the past 2 years. A nice GUI for the clueless
>sysadmin is nice but it's not sufficient to make a program interesting.
>
>[..]
>> This method can be extended to any other admin tool that comes around b/c
>> all that would have to be done is write a "configure" script for it, and
>> perhaps add new fields to the database to use its features.
>
>In my opinion it's the wrong policy to support admintools which can't
>get the information themselves. Otherwise they are broken by design.
>I mean, there are some standards upon Unix is built and we should
>conform to these standard or extend them.
>To rectify and establish a complete a new standard there should be a
>_very_ good reason and a promissing goal.
The admintool is getting the info the same way we are getting init to know
about new init scripts, There is now way for an admin program to
automatically learn about new services automatically, if you have any ideas
I'll forward them to the upstream maintainer.
Right now this is the only way I can think of implementing it in a simple
fashion, and this method also seems to conform nicely with what Bruce was
mentioning about a single database for configuration data.
Shaya
--
Shaya Potter
spotter@itd.nrl.navy.mil
--
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: