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:
pgpb2Ni1dkWdY.pgp
Description: PGP signature