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

RFC: new update-inetd



Hello world,

So it's a fairly well know fact that update-inetd kind-of sucks [0],
and probably needs to be rewritten. It doesn't work with inetd's that
don't use the same format for their inetd.conf, and it has a number of
infelicities even dealing with inetd.conf. So a rewrite's probably in
order.

So. What I'm thinking of doing is reorgansing netbase again, along the
lines of:

	Package: net-common
	Priority: important
	Description: Provides basic networking infrastructure

	Package: netbase
	Depends: net-common, portmap, netkit-inetd, ...
	Description: Dummy package for upgrades

	Package: netkit-inetd
	Priority: optional
	Depends: net-common
	Provides: internet-superserver
	Conflicts: internet-superserver

	Package: xinetd
	Priority: extra
	Depends: net-common
	Provides: internet-superserver
	Conflicts: internet-superserver

Packages that expect the old update-inetd interface to work will
continue to Depend: on netbase, and it'll continue to work for
them. Packages that are updated to use the new update-inetd will depend
on internet-superserver instead.

Yes, Aaron (and all the other people who've whined about it), this will
mean you don't have to have any sort of inetd on your system.

At the moment, the split is looking like being:

	net-common:
		/usr/sbin/update-inetd

	netbase:
		/usr/lib/perl5/DebianNet.pm
		/usr/lib/netbase/update-inetd.old

	netkit-inetd:
		/usr/lib/net-common/update-inetd-backend.pl
		/etc/inetd.conf

	xinetd:
		/usr/lib/net-common/update-inetd-backend.pl
		/etc/xinetd.conf

If no inetd is available (and hence /u/l/n-c/update-inetd-backend.pl
doesn't exist), then update-inetd will just store the commands in
a temporary config file (/etc/update-inetd.store) until an inetd is
installed, at which point they'll be rerun and take effect. Similarly,
when the internet-superserver package is removed, the current settings
will be dumped to the same temporary config file, and will be converted
to the new inetd's format when/if a new inetd is installed.

People using update-inetd will need to switch to doing something like:

postinst:
    if [ "$1" = "configure" -a "$2" = "" ]; then
        update-inetd add cvspserver tcp /usr/sbin/cvs-pserver --hint=tcpd
    elif [ "$1" = "configure" ]; then
        update-inetd enable cvspserver tcp /usr/sbin/cvs-pserver remove-cvs
    fi

prerm:
    if [ "$1" = "remove" ]; then
        update-inetd disable cvspserver tcp /usr/sbin/cvs-pserver remove-cvs
    fi

postrm:
    if [ "$1" = "purge" ]; then
        update-inetd remove cvspserver tcp /usr/sbin/cvs-pserver remove-cvs
    fi


Services that need to be disabled during upgrades would also want to run:
    update-inetd disable cvspserver tcp /usr/sbin/cvs-pserver upgrade-cvs
    update-inetd enable cvspserver tcp /usr/sbin/cvs-pserver upgrade-cvs
at the appropriate times.

Multiple packages that offer the same service will need to either
conflict with each other or avoid stepping on each others toes with some
alternatives mechanism of their own. The basic rules are:

	* you can only have one enable service on a particular port at
	  any one time (duh)

	* each command belongs to a package, so if you have two packages
	  trying to provide "smtp/tcp /usr/sbin/sendmail", at least one of
	  them has to be removed, and thus disabled with remove-foo as the
	  reason.

So, it's quite okay to do something like:
	update-inetd disable finger tcp /usr/sbin/in.cfingerd alt-fingerd
	update-inetd enable finger tcp /usr/sbin/in.mfingerd alt-fingerd
to manage alternatives.

You can disable a service multiple times; they stack right up until you
remove the package: you can't disable a service further after you've
disabled it for a remove-* reason. You can then re-enable in any order,
with the exception that you have to re-install it first if you removed it.

People with packages like samba or exim which will happily run either
standalone or via inetd will have to be a little cleverer, since they
won't be able to rely on an inetd being present. The most reasonable
thing I can think of would be doing something like:

	if [ -e /usr/lib/net-common/update-inetd-backend.pl ]; then
		default=inetd
		pri=medium
	else
		default=standalone
		pri=low
	fi

	db_subst exim/standalone-or-inetd default $default
	db_input $pri exim/standalone-or-inetd || true

For people packaging inetd-replacements, you'll need to write an
update-inetd-backend that can cope with the format of your inetd.conf
replacement (or steal netkit-inetd's if they're the same) and add the
appropriate stuff to make upgrades reasonably smooth. Something like:

postinst:
	if [ "$1" = "configure" -a -e "/etc/update-inetd.store" ]; then 
		/bin/sh -c /etc/update-inetd.store
		rm -f /etc/update-inetd.store
	fi

prerm:
	if [ "$1" = "remove" ]; then
		update-inetd dump >/etc/update-inetd.store
		chown root.root /etc/update-inetd.store
		chmod 644 /etc/update-inetd.store
	fi

The full syntax is:

        # update-inetd add <service> <type> <executable> <arguments..> 
        #                  [--netgroup=<group>] [--user=<user>[.<group>]] 
        #                  [--wait|--nowait[=<n>]] [--hint=ipv6|ipv4|tcpd]
        #                  [--disable[=<reason>]]

        # update-inetd remove <service> <type> <executable> <reason>
        # (must already be disabled for reason <reason>, <reason> must
	# match remove-*)

        # update-inetd disable <service> <type> <executable> [<reason>]

        # update-inetd enable <service> <type> <executable> [<reason>]

--netgroup defaults to OTHER, and can be set to MAIL or whatever.
--hint isn't guaranteed to do anything, but if you've got a program that
only works with ipv4 or ipv6, you can try to pass that along to inetds that
can handle such things.
You can also add a service that's initially disabled.

Anyway, I think that should mostly work and make sense and so forth, and
should fix most of the outstanding problems with update-inetd.

It's mostly coded, so pending any comments, I'll probably upload some test
.debs to experimental soonish.

Cheers,
aj
 
[0] 8927, 24043, 24543, 33797, 45334, 53396, 63210, 63504, 64874, 74339,
    82875, 87240, 90676, 91316

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgptVRnMw0rBY.pgp
Description: PGP signature


Reply to: