Re: system-config-dns?

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Sat, 2005-07-23 at 00:55 +0800, John Summerfied wrote:
> Chester R. Hosey wrote:

> >>>that the plugins would have to be able to parse and make changes to the
> >>>original configuration files; obviously this is a fun problem and one
> >>>that many people find more appealing than, say, working on new
> >>>functionality or bug fixes or taking out the trash.
> >>
> >>Use a directory:
> >>/etc/configurator.d/
> >>
> >>Nothing to parse/edit. Lots of tools do that sort of thing already, it's 
> >>an established standard way of doing it.
> > 
> > 
> > I'm not sure what you mean by that. I typically use something
> > like /etc/apache/vhosts/ to store broken-out configuration snippets for
> > individual virtual hosts. This doesn't remove the requirement that
> > current tools be able to parse the configuration files -- what if I want
> > to change the serverroot for www.example.com? How does splitting a
> > configuration file up suddenly remove the need to be able to parse or
> > edit the configuration file?
> 
> The overall configuration tool reads stuff in /etc/configurator.d/ to 
> find all the configuation tools available. It may provide an means to 
> communicate with the user, providing maybe a text console interface, an 
> GUI interface or three and a web interface.
> 
> Someone who wnats a tool to configure Apache writes to the defined API 
> to discover what the user wants to do.
> 
> Like putting environment settings into /etc/profile.d, it would provide 
> a standard means for folk to write and run configuration tools, but 
> those developing the high-level tools don't need to be concerned with 
> the format of individual configuration file or where they might be.
> 
> Gnome, KDE and other DTEs use the same means to connect applications to 
> our menus: all the KDE and Gnome application developers need to know 
> about it is the information to provide and where to put it.
> 
> <snip>

I'll not comment because I'm still not clear on how the implementation
would work, and I don't grok the high-level description. It's very hard
for me to imagine a mechanism which describes a general configuration
interface which will allow any program to interact with any
configuration tool without any specific glue for each program or
interface layer.

> >>It has the ability to run in text-only environment (dialog), X-Windows 
> >>(xdialog) and I think there's a Gnome front-end for it too. It can also 
> >>use text editor as its front end, and it can be turned off.
> >>
> >>Debian has the problem that, like RH*L, there's no central repository to 
> >>show what can/should be configured. /etc/configurator.d would provide that.
> > 
> > 
> > I'm not sure I understand /etc/configurator.d.
> > 
> > I believe that you're mistaken about the role of Debconf. Debconf is
> > meant to provide integration into the current environment and to let the
> > package configuration tools know about things that might affect it. It's
> > meant to configure the _package_ more than the program within the
> > package.
> 
> I think I don't understand you, or alternatively that in this you're 
> mistaken. Here is a question taken from a Ubuntu package:
> Name: postfix/mailbox_limit
> Default: 0
> Description: Mailbox size limit
> Description-de.iso-8859-15: Maximale Mailbox-Gr�e
> Description-es.iso-8859-15: L�ite de tama� de buz� de correo
> Description-fr.iso-8859-15: Taille maximale des bo�es aux lettres:
> Description-it.iso-8859-15: Limite di dimensione delle mailbox
> Description-ja.euc-jp: ᡼�åΥ��
>                               Description-nl.iso-8859-15: Grootte limiet 
> voor postvak
> Description-pt_br.iso-8859-1: Tamanho m�imo das caixas de mensagem
> Description-ru.koi8-r: ������������������
>                                           Extended_description: What 
> limit should Postfix place on mailbox files to prevent runaway software 
> errors.  A value of zero (0) means no limit.  (The upstream default is 
> 51200000.)

Does it also configure your virtual host setup? What about the myriad of
other configuration options? For example, does debconf attempt to set up
Apache beyond setting a few system defaults?

Can you provide a single example of a highly configurable program for
which debconf is intended to provide post-installation configuration?

In fact, apt-cache show debconf includes the following description:

	Debconf is a configuration management system for debian (sic)
	packages. Packages use Debconf to ask questions when they are
	installed.

It says nothing of configuration beyond the initial installation.

Am I missing something? You provide a few examples of questions, but
nothing has yet convinced me that debconf is intended to provide
anything on the level of full package configuration.

> > For instance, do you want to run Samba as a daemon or from inetd? It
> > affects whether the postinst script will send a -HUP to inetd. It makes
> > NO attempt to help you configure Samba itself.
> 
> Here's a Samba question:
> 
> Name: samba-common/dhcp
> Default: false
> Description: Modify smb.conf to use WINS settings from DHCP?
> D

That deals with the interoperation between two packages, and thus might
be a valid meta-question about installation. I don't know details, but a
single example isn't conclusive.

> > Another example is asking whether to install a program as setuid root.
> > It's an installation question, not a configuration option.
> :-)
> That's a Q should never be asked. Few users are competant to answer it. 
> The packager needs to make an executive decision that will work.

That's why debconf allows priority levels, to allow administrators to
indicate how much they want to be bothered by the more mundane
decisions. However, it's an appropriate question to ask if the verbosity
is set sufficiently high. It's also a great question to ask, because it
will allow debconf to remember your preference across upgrades. I didn't
say that it was a good question to ask EVERYONE, but it is an
appropriate type of question to be asking at install time if the user
has requested such a level of choice to be presented, which is
orthogonal to the question of configuration mechanism.

Chet