What do admintools need? (was: Linuxconf again and again)
vanco@sonic.net said:
> I know many of you will not like what I have to say here, but I've
> looked at the problem extensively, and *know* that any linuxconf (or
> other configuration system currently out there) based system will not
> cut it for debian.
> A much more aggressive strategy must be taken, possibly involving
> usurping the way dpkg does things right now. Simply put, linuxconf is
> *not* acceptable for networked installation profiles and remote
> configuration management, but this is what 75% of end users will want
> an admintool for. And no, --(get|set)-selections with some tcp hack
> and batch config with linuxconf wouldn't tie it together well enough
> either.
Where do you get "75%" from? I believe a lot of users just want to have
some tool to support system configuration (instead of editing files in
/etc and restarting daemons). Others might want to have other tools.
Well, why not.
You don't have to use linuxconf, even if it came with Debian. Linuxconf
is basically nothing else than vi, emacs, sed, perl or other tools. Just
choose the right tool for the right job, but please don't say "vi will
not cut it for Debian" just because sed is better for some purposes.
Anyway - /etc/init.d/network as it is now, is a mess. *No* admin-tool
should need to parse or write a shellscript. Something has to be done.
And no init-script supplies *any* information about the location of the
configuration files of its particular daemon. Either any admin-tool has
to hardcode this information (which is bad) or there has to be some
policy to tie this together. This would allow a lot of simplification
(linuxconf or other tools could then just check if a file has been
changed and use this to restart the daemon it configures or
cause it to reload the file).
Could we forget about linuxconf for now and concentrate on necessary
requisites for such admintools? Everything linuxconf needs is also
needed by other tools. If we use this list to discuss what tool Joe
Admin should use, we won't get very far.
crow@debian.org said:
> I was thinking some sort of system where a packages communicate with a
> frontend, they tell it what variables the package has available and
> provides hints on how the configuration is presented to the user.
> The frontend should be completely unaware of the details of the
> configuration files for each package.
> If we could agree on some sort of protocol to transmit configuration
> settings it would be a step in the right direction.
IMHO even a protocol is too much for now. If there where some formal
description what file(s) configures what package/daemon/program and how
to cause this changes to take effect, this could be a step forward. A
single file with such a description in every package would be quite
useful.
Sorry for changing the subject forth and back ;-)
Jochem
--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Rettet diese Lebensform!
Reply to: