Re: xinetd feature: daemons that listen on multiple ports

Steve G <[email protected]> writes:

> Writing new requirements has also been educational. I've
> found several areas that xinetd's behavior is different
> that other inetd's. Then there's IPsec and SASL. I don't
> like the idea of squeezing that into xinetd as it stands.

Interesting _new_ points are SSL and particularly TLS (the latter is
dependent on the protocol, SMTP vs. POP3 vs. IMAP vs. ...)

> IPsec and SASL and other things should be designed in from
> the ground up. Each module should have its own unit test
> that exercises it. Each module can be swung in and out at
> compile time. People that want a lean inetd can compile
> just the pieces they need. Vendors can compile the whole
> thing.

While modular approaches are very smooth to test and are aesthetic and
have some advantages if the new inetd is considered by itself, this view
is way too narrow when evaluating the system at large, inetd + daemons.

The problem shows when it comes to documenting daemons, section
installation instructions. If you're going to give inetd sample lines,
even in the simplest setup you'll have to take four cases into account:
your inetd is stupid (no libwrap), your inetd runs with libwrap by
default (FreeBSD); tcpd was compiled without PROCESS_OPTIONS, tcpd was
compiled with PROCESS_OPTIONS. Now some distros (Red Hat) install xinetd
rather than inetd by default, so you add more stuff, and differentiate
libwrap again. Makes eight cases already.

The more modules the user or a vendor can remove, the more cases "if
$INETD was compiled with $OPTION, use this, if $OPTION was left out, use
that line" -- someone documenting his ftpd/nntpd/whateverd has to take
all this into account.

If you need to give simple yet water proof installation instructions,
there's nothing short of recommending that the user installs daemontools
and ipsvd or ucspi-tcp (see http://cr.yp.to/ and
http://smarden.org/pape/).

IF you are designing a new inetd, then please do make sure that there
are absolutely no switches that disable important features. It must be
possible that a _SINGLE_ example of my nntpd or ftpd installation
instructions covers $NEW_INETD configuration once and for good -- and do
integrate socket_wrappers with -DPROCESS_OPTIONS.

(I'd also recommend looking at ipsvd, it has some quite nifty access
control features.)

-- 
Matthias Andree