On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote: > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the > proposal below to migrate it to dpkg triggers [0] > The Current Messy State of Affairs > update-inetd script is problematic (maintainer scripts use it to update the > /etc/inetd.conf conffile leading to local-policy overrides and confusion) inetd.conf is not a conffile. 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. > 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? > * 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? > * 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. > * 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. > The advantages of this proposal are, idempotency, respect of local policy, > ability to switch transparently between inetd and xinetd, and possibility to > support future inetds that might use a different configuration file syntax. The last shouldn't even be a consideration. xinetd is 17 years old. If nobody's found a need to break config file compatibility in that long, it's not going to happen. (Or if it does, whoever's doing it has too much time on their hands.) > 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? > * 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature