Re: RFC: A method to use Admin tools, like linuxconf
On 20 Feb 1997, Manoj Srivastava wrote:
> Hi,
>
> Nice summary, Andreas. I agree about saving the values for
> variables used by the {pre,post}{inst,rm} scripts and runtime scripts
> somewhere. (I think that there is an overlap here -- data gathered
> from the human installer is often used by the run time scripts later,
> makes sense to have on consistent database). BTW, the database should
> be accessible by means other than a special tool -- just think
> windows registry.
I hope this isn't what you think Linuxconf does. It stores that data in
the normal text files that the linux programs use. It does have its
central config file (also text, I think) and that only contains the data
that there is no standard place to put.
>
> I don't understand why you mentioned the SysV init links, yes,
> a file will be easier to manually edit (all the data is in one
> place, one may use the one true editor, etc), but it becomes a
> nightmare for programs (install scripts as well as config/admin
> tools) to edit in place, the symlinks are well understood, and easy
> to manipulate.
Linuxconf doesn't put the info in one file. It has one file, which does
all the standard stuff Linuxconf does, but it also has many drop-in
files, which is what the "configure" program I was talking about would
create. These drop-ins are just text file, which have fields that tell
Linuxconf how to start the program, and other info. They are easily
understood by just looking at them, even though there can be a lot of
them, just like we have a lot of /etc/init.d scripts.
Oh we can also keep our start-stop daemon. instead of telling Linuxconf
to start the program directly, we can have it call the /etc/init.d
script, with the start/stop/reload options.
>
> You should decide what you want: a config admin tool (in which
> case use whatever backend is easier for programs to deal with; as
> long as there is a means of bypassing the program), or go for ease of
> use for the human, which is slightly subjective (this particular
> human likes using, ls, find, pushd etc, more than the nightmare
> rc.local had become on my ultrix boxes).
Linuxconf is mainly a config tool. You can use it with plain SysV init,
but it is much nicer to use it with its own starting mechanism. What I
am trying to say is that we should allow the user to choose whatever
"backend" they want, backend being an "activator"
>
> Believe you me, ``nice'' config files are a honey trap, they
> tend to grow more and more convoluted, and un manageable, as time
> goes on. (One of the reasons DEC moved to symlinks and removed
> rc.local with Digital Unix, good move, IMHO).
>
> I think that removing the separation we have achieved with
> SysV init and going back to giant rc.local is a big mistake, and will
> make it impossible for non unix experts to run a Debian system. I
> don't think it is as trivial to edit a file in place as you think,
> and one error will hose the system. (ever lost a rc.local on a
> network server, with the backups on a node across the town?)
> Aesthetically, init.d and symlinks may not be pretty, but they are
> robust.
Linuxconf is not like rc.local at all.
>
> A gui will take the tedium out of adding and removing link, a
> user friendly update-rc.? will make it accesible from the command
> line, or else there is always ln and rm. (IMHO, ease of editing a
> config file does not outweigh the greater fragility of the new
> system).
How does Linuxconf make the system more fragile?
>
> I do think, though, the points about less than perfect
> behaviour of scripts in init.d were valid: maybe we should have each
> script just start one daemon, unless the daemons are so closely
> related they won't function individually? (give finer granularity to
> tuning the site -- Policy manager?)
This would be good, but it is just fixing init, it wont give us more
configurability, and there are always programs that might violate our
standard.
>
> I disagree that we do away with scripts that merely call
> start-stop-daemon: don't break what is not broken.
I never said get rid of it, Linuxconf can use the /etc/init.d scripts
instead of calling hte program directly.
>
> Oh. I think that adding greater robustness to init such that a
> hung script does not kill init may be decent -- run all scripts in
> the child, and catch retuen status.
That would be nice for the people who want to stick with plain SysV init.
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: