Steve Langasek <vorlon@debian.org> writes:
> On Thu, Nov 29, 2007 at 10:17:22PM +0000, Roger Leigh wrote:
>> The main problem (as I see it) is that the current update-inetd is too
>> complex, and can't migrate configurations between different inetd
>> config file formats.
>
> Why should that be the job of the current update-inetd?
My opinion here is that one should be able to install any package
Providing inet-superserver and expect the configuration to be carried
over in some working form and get a working system. The Provides
should be indicating some basic level of equivalence in functionality
between the packages.
>> And every maintainer script has to call update-inetd to make it write
>> package-specific information, which is fragile
>
> Fragile in what sense?
You can break the configuration of packages registering their services
with update-inetd depending upon the specific order of installation
and removal, particularly when combined with the replacement of one
inet-superserver package with another.
>> it only gets done when you install the package, and if you screw up
>> inetd.conf, too bad.
>
> Er? Screw it up how? Why would it not be fixable with dpkg-reconfigure
> $package?
Usually, yes. But, it shouldn't need that in the first place.
One major issue I have is how packages are using update-inetd:
[ /var/lib/dpkg/info/leafnode.postinst ]
update-inetd --comment-chars "#disabled#" --disable nntp
update-inetd --group MAIL --add --comment-chars "#disabled#" \
"nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/leafnode"
We are hardcoding a particular inetd.conf format as an argument,
rather than specifying the fields separately. Additionally, we are
not supporting IPv6--tcp4 is hardcoded, and this requires either
adding a second entry or amending the existing one. For proper IPv6
support we need to get inetd services using IPv6 services out of the
box.
>> Why don't we take a leaf out of how other packages manage things and
>> do this:
>
>> - create a /etc/inetd.d directory
>> - each package providing an inetd service can contain a
>> /etc/inetd.d/package file containing all the information about the
>> service; it could be a superset of the information xinetd and all
>> the other inet daemons require, and have a parameter to
>> enable/disable the service. This should be a conffile.
>> - update-inetd takes no arguments, it just reads all the files in
>> /etc/inetd.d/ and then writes out an inetd.conf, or xinetd configs,
>> whatever the daemon requires.
>
>> This has the big advantage of
>
>> - allowing the user-customisable bits to be in conffiles for
>> preservation across upgrades
>> - makes the whole thing much simpler, maintainable and extensible
>> - each inetd can provide a *trivial* update-inetd to read through the
>> config files
>
> Using conffiles is a big *DIS*advantage. Conffiles are only minimally
> appropriate when there's a stock config which is expected to work for most
> users, and in the best of cases are annoying for users who diverge even
> minimally. When we're potentially talking about a config file format that
> contains the information about whether a service is enabled or disabled,
> that's a Bad Idea.
But, the existing format is *already* doing this--with specially
marked up comment lines (as shown above, yech!). And in most cases
the user won't need to modify it; IMO each service as a conffile makes
as much sense as /etc/pam.d and similar.
It also makes updating by the package easier--currently update-inetd
either preserves the user modification or it does not; the user can't
later merge would /would/ have been updated as can be done with
.dpkg-new and friends--it's lost unless you dig through maintainer
scripts.
> You're also talking about a totally new config format that nothing actually
> *reads* today, so now instead of doing the right thing and teaching a tool
> to parse & output the existing formats, we instead have a tool that parses
> one format and outputs another with the result that there are two copies of
> the information stored on the system - one in the place where existing users
> expect to find it which is *not* authoritative, and one in a totally new
> format that is authoritative.
>
> This is also a Bad Idea.
Well, my implication was that a format such as the xinetd format would
itself be such a superset--we don't need to invent a new format. And,
incidentally, it also already has a "disable" parameter to do exactly
the above. update-inetd then need only translate one format. And,
this format supports global defaults such as IPv6 settings which the
existing scheme will never do; this can be translated into multiple
lines for the traditional inetd.conf, something the maintainer scripts
can not do currently.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
pgpyyvUzPxxa9.pgp
Description: PGP signature