Re: RFC: new update-inetd
On Mon, 2 Apr 2001 15:25:18 +1000
Anthony Towns <aj@azure.humbug.org.au> wrote:
> 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.
Thank God someone is still sane. ;)
> 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.
What's preventing you from making the new update-inetd command-line compatible
with the old one?
> 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.
Hooray!
> 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.
Sounds like you're making a meta-format for {x,rl,}inetd configuration
files. In that case, why not make this meta-config-file the _master_
config file, and have some utility (update-inetd?) update the presently
installed inetd's configuration.
You could take this idea a step further and create a directory named
`/etc/inetd.d' or something, and have individual packages simply drop a
file into that directory and call update-inetd.
Take care to insure that this meta-config-file format accomodates all of
the features of the existing inetds (inetd, xinetd, rlinetd) -- that is,
the _highest_ common denominator rather than the _lowest_. This format must
also be extensible, so that if (when) a new feature comes along in one of
the inetds (or a new inetd altogether comes along), it will be a simple
matter of modifying a policy regarding the file format, rather than having
to halfway-rewrite the tools to understand this new format.
To this effect, I suggest using an RFC 822-like syntax, like this:
Service: telnet
Protocol: IPv4
Transport: TCP
Port: 23
Invocation-Mode: No-Wait, TCP-Wrappers
Run-As: root
X-Maximum-Connections: 10
X-Maximum-Connection-Rate: 1/s
Command: /usr/sbin/telnetd
Note the X- fields; these must be supported so that inetds that are not part
of Debian (or whose fields have not yet been added to policy) can still be
configured properly.
Note also the presence of a Protocol: field; in my opinion, introducing a lot
of optional, standard fields is a lot better than creating a situation where
3/4 of the fields in a service entry are X- fields. Besides, IPv6 is right
around the corner, and inetds will probably begin to support it very soon, if
they haven't done so already. Best to be prepared.
> 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.
That could be interesting in the context of the /etc/inetd.d idea above. Perhaps
adding a "Disabled: Yes/No" field to the specification for the field names would
suffice?
> 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.
Perhaps there should be "Provides" and "Conflicts" fields in my above example.
No need for "Depends" since services don't generally depend on each other, but
since they might provide the same service, "Provides" and "Conflicts" sounds
like a good idea.
> 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.
Oh dear, you've already coded this? Forgive me for suggesting you rewrite the
whole thing... :)
Regards,
Alex.
Reply to: