[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: update-inetd migration to dpkp-triggers

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.

	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

	update-inetd --group OTHER --add \

	case $1 in
			update-inetd --comment-chars '#<removed># ' \
				--pattern 'tcp.*/usr/sbin/inetd-test\b' \
				--disable inetd-test
			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'

	update-inetd --group OTHER --add \

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

Reply to: