Steve Langasek <firstname.lastname@example.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.
Description: PGP signature