On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote [edited]: > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> Invocations of update-inetd that lead to local policy overrides are bugs in > the caller, not in update-inetd. There is an explicitly reserved comment > string (#<off>#) for the only case relevant for package use. Indeed, many maintainer scripts are buggy, largely because documentation is unhpelful on how update-inetd should be used by postinst and postrm scripts. Some scripts override the default comment string (or equally worse, add entries with service names like "## ftp"), some use --disable instead of --remove in postrm ... you get the idea :) > > and doesn't support xinetd (#8927) > > This is a bug, yes. > > > The Rosy Future > > > * update-inetd will drop its current switches to > > add/remove/enable/disable services; > > This doesn't sound like a good idea; it sounds like a transition that's > going to break a lot of packages (either silently or noisily, depending on > the implementation). How do you intend to transition away from this without > either a) dropping existing package-provided entries on the floor, or b) > leaving packages with no way to clean up those same entries? This is meant to be in squeeze+1, at which point all update-inetd using deamon packages must be modified to install a fragment in /etc/inetd.conf.d/ instead of using --add. In that mode of operation --remove will not be applicable (fragments will be left behind, as is the case with xinetd). As for enable/disable, they shouldn't be used by maintainer scripts in the first place. > > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate > > /var/lib/update-inetd/inetd.conf and auto-populate fragments in > > /var/lib/update-inetd/xinetd.d/ using xinetd fragments installed by deamon > > packages in /etc/inetd.conf.d/ > > Likewise, then, what happens to existing entries in /etc/xinetd.d? Just to clarify, this whole section refers to squeeze+1. As long as /etc/inetd.conf and /etc/xinetd.d/ exist, update-inetd will use them as input, along with /etc/inetd.conf.d/, to update /var/lib/update-inetd. update-inetd will print a warning asking the user to migrate all settings to /etc/inetd.conf.d and rename /etc/inetd.conf and /etc/xinetd.d (or have a --migrate switch to do so, but only to be invoked by the user) > > * document that local policy will live in /etc/inetd.conf.d/ and any manual > > changes will be made effective by running update-inetd > > I think this violates the principle of least surprise (restarting the daemon > after making your changes has been enough to make those changes take effect > since the inception of these daemons), and will be displeasing to many > admins as a result. This is a justified concern but I think it's a price we need to pay to be able to support both inetd and xinetd with a single source of policy. The need to run update-inetd will be remarked wherever we document that the new local policy has moved to /etc/inetd.conf.d. The number of steps remains the same though (instead of reloading inetd, one will have to run update-inetd) > > * all (4) superservers will lookup their config under /var/lib/update-inetd/ > > > * after deamon package installations, update-inetd will be invoked via a > > file > > trigger on /etc/inetd.conf.d/ to update the (x)inetd's actual > > configuration > > under /var/lib/ and reload (x)inetd > > This part seems reasonable. > > > How to Get There > > > The migration could(?) be done within one stable release, but I assume a > > more > > conservative approach over two releases. > > > * squeeze > > * all deamon packages that use update-inetd [1]: > > * should version-depend in the update-inetd version that is shipped > > in > > squeeze (so that /etc/inetd.conf.d/ is in place) > > * should install xinetd fragments in /etc/inetd.conf.d/ (and in > > /etc/xinetd.d/ if they did so already) > > * must continue calling update-inetd in postinst/prerm scripts as > > before > > * update-inetd will: > > * install /etc/inetd.conf.d/ and declare file-trigger interest in it > > * keep the old functionality, but additionally to updating > > /etc/inetd.conf, also update /var/lib/update-inetd/* using as > > input > > both /etc/inetd.conf and /etc/inetd.conf.d (and /etc/xinetd.d if > > installed) > > So with these packages that are calling update-inetd *and* installing a > snippet, what ends up being copied to /var/lib? The logic that combines /etc/inetd.conf and /etc/inetd.conf.d/ will have to filter out duplicates. On a second thought though, there's not much point in populating /var/lib in squeeze as it won't be used until inetds are patched (in squeeze+1). > > * update-inetd must: > > * sync effective inetd configurations based on /etc/inetd.conf.d/ > > and > > reload inetd when invoked without any arguments > > * only run as as result of being triggered by a deaemon > > (un)installation, or an explicit user invocation > > * drop the old functionality and print a warning but otherwise > > succeed > > when invoked with any of the old command line switches > > So: silent failure of update-inetd invocations. > > Noisy would be better. Silent failures hide bugs. By noisy you mean non-zero exit status? Isn't warning+success noisy enough? :-) Warning+success means that deamons from (pre)squeeze that have been dropped in squeeze+1 but are still installed, will succeed in uninstalling despite invoking update-inetd the old way. Thanks, Serafeim -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
