On Tue, Sep 08, 2009 at 01:13:45AM +0200, Serafeim Zanikolas wrote: > On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]: > > On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote: > > > but the primary benefits are making inetd support in maintainer scripts > > > both robust and idempotent.
> > update-inetd in its present form can already be used to achieve this.
> I beg to differ. update-inetd assumes that a service name (``ftp'') is
> sufficient to enable, disable and remove a service, whereas to be certain of
> what service is selected, one has to additionally specify protocol and path to
> the server binary. This currently can be done with a little bit of imagination
> using the optional --pattern switch (which strangely though is not available
> in --remove mode)
The --remove option is specified to accept a regexp as its argument. Does
this not work?
Perhaps packages today aren't /using/ --remove in a way that's robust and
idempotent, but again, that seems to be a documentation problem.
(The issue you've highlighted here is one I wasn't aware of, thank you for
bringing it to my attention. The packages I maintain that use update-inetd
are the only things in the archive providing the service in question, so
I'd always considered using the service name to be unambiguous.)
> I'll keep improving update-inetd regardless of any migration but the problem
> remains: it provides too much flexibility that is naturally abused.
> And while we're at it, why does it even have the enable/disable switches?
Because inetd.conf is configuration data, and packages should not remove
these entries when the package is removed - only when the package is purged.
> Shouldn't maintainer scripts only use add and remove? (If you disagree, have a
> look at #168847)
Ah, another case that I hadn't considered because I don't have to deal with
multiple packages providing the same service.
Wouldn't it suffice to support an additional --pattern argument to
update-inetd --add? That way packages could specify the minimal match
needed for re-enabling instead of adding a new entry.
Alternatively, packages could use --comment-chars '#<removed># ' for
enabling/disabling as part of a package removal.
Again, the problem doesn't seem to be a limitation in update-inetd, but a
lack of policy/documentation around it.
Here's a rough cut at a robust set of update-inetd calls for maintainer
scripts to use. It's ugly, of course, and verbose - something that could
probably be remedied with only minor enhancements to update-inetd. And it
seems to run afoul of a bug in update-inetd --remove, in that you can't use
a regexp match against the whole line. But those issues can be solved
without redesigning the world.
package1.preinst:
if [ "x$1" = "xinstall" ] && [ -n "$2" ]; then
update-inetd --comment-chars '#<removed># ' \
--pattern 'tcp.*/usr/sbin/inetd-test\b' \
--enable inetd-test
update-inetd \
--pattern 'tcp.*/usr/sbin/inetd-test\b' \
--disable inetd-test
fi
package1.postinst:
update-inetd --group OTHER --add \
'inetd-test\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbin/inetd-test'
package1.postrm:
case $1 in
remove)
update-inetd --comment-chars '#<removed># ' \
--pattern 'tcp.*/usr/sbin/inetd-test\b' \
--disable inetd-test
;;
purge)
if [ -x /usr/sbin/update-inetd ]; then
# FIXME: why doesn't this regexp match?
update-inetd --remove \
'(#<removed># |#<off>#
)*inetd-test.*tcp.*/usr/sbin/inetd-test\b'
fi
;;
esac
package2.postinst:
update-inetd --group OTHER --add \
'inetd-test\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbin/inetd-test2'
--
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/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
