Re: proposal: inetd improvements.

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Wed, 02 Jun 2010 11:16:40 +0100
elric%imrryr.org@localhost wrote:

> I am thinking of using inetd to run a few services in a production
> environment and in order to make it robust and featureful enough to
> do so, I would like to make the following list of changes to it:
> 
>       1.  maximum connexions per unit time is not a terribly
>           useful feature and in fact makes the use of inetd in
>           an enterprise unusable as it is a built-in denial of
>           service.  I propose that we keep track of the number
>           of outstanding children and place a maximum on that
>           rather than connexions per second.  Perhaps we can
>           leave connexions per unit time in the code but strongly
>           discourage its use,

Per-client address connection limits and/or throttling are more useful
than global throttling, IMO.

>       2.  inetd should be able to optionally signal kids of wait
>           services when it is HUPed or stopped,
> 
>       3.  for wait services for which inetd fails to bind, it should
>           retry later as it is possible that a daemon that it HUPed
>           earlier is taking a while to exit,
> 
>       4.  % should be defined as an address type and it should expand
>           into a list of IP addresses which is periodically regenerated
>           by iterating over the interfaces,
> 
>       5.  it should be possible to configure multiple kids on a wait
>           service to give the ability to trivially run pre-forked services,
> 
>       6.  put in some interpolation in args so that we can tell the daemon
>           a few things.

Some of those points I don't fully follow, but others remind me of when
I had to write a general purpose spawnd server resembling inetd but
allowing me extra flexibility; this has served me well for specific
services (i.e. chrooted anoncvs pserver, etc).  It's not exactly
distribution-ready, but in case it can serve for inspiration or for
your uses, it can be found at:

http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/mmspawnd2/

which internally uses mmserver2 library at:
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/mmlib/

mmspawnd2.5 shows the various supported options such as limits.

I'm not sure if inetd could really be this configurable and still serve
easily for older less complex configurations, that's probably a
challenge to find balance there.  The one-line per service
configuration is easy yet also limited; perhaps you'd end up with
something similar to xinetd configuration files.  That said, perhaps
this would also be eventually useful, as it could allow packages to
install configuration files for newly installed services.

>       7.  add a few extra socket options here and there,

That's a good idea

>       8.  maybe a chroot option, maybe unnecessary given that you can
>           already do this via chroot(1), and

chroot is useful in some setups, but also requires knowledge about the
specific services, i.e. the device and local socket files it expects,
config files, etc so it's a bit more complex; not that supporting this
is necessarily a bad idea however, mmspawnd2 also supports chroot.

>       9.  convert it to libevent for portability and provide autoconf
>           so that it can be built on other OSes (not used on NetBSD of
>           course).

I have no opinion on this, but I think that it would follow existing
efforts to support other projects via NetBSD software (i.e. pkgsrc),
and ash, ftpd have portable package editions; I think that one of
Pooka's intentions is also to eventually use some NetBSD FS code in
userland FS tools on various OSs, not only on NetBSD)...  so if our
inetd is useful enough and can compete with xinetd, I don't doubt that
some third party distributions would want to use it if they could
easily build it...

Thanks,
-- 
Matt