xinetd is a powerful replacement for inetd.
xinetd has access control machanisms, extensive logging capabilities,
the ability to make services available based on time, and can place
limits on the number of servers that can be started, among other things.

I have added the ability for xinetd to redirect TCP streams to a remote
host and port.  This is useful for those of that use ip masquerading,
or NAT, and want to be able to reach your internal hosts.

I have also added the ability for xinetd to bind specific services to 
specific interfaces.  This is useful when you want to make services
available for your internal network, but not the rest of the world.
Or to have a different service running on the same port, but different 
interfaces.

xinetd now has a simple interactive administration service you can
run.  In your xinetd.conf file, if you have a service named "xadmin"
it will be an internal service.  You should specify a port number for
it to listen on, and preferably, some access control based on IP, since
it currently does not have access control its self.  
You can then telnet to that port, and xinetd will tell you some
simple information about its self, but it is still somewhat useful.

xinetd also now sets $REMOTE_HOST environment variable (assuming your
OS supports setenv()) to the name of the remote host.

A "banner" directive has been added.  It take the name of the banner
file as an arguement.  This file is splatted at the remote host when
a connection to that service is denied.

A note on the use of itox:  itox reads in the standard inetd.conf file
from stdin and writes the generated xinetd.conf to stdout.  You can use
something like: "itox < /etc/inetd.conf > xinetd.conf".  If your inetd.conf
doesn't have explicit paths, you may have to use the -daemon_dir option,
that will tell itox where the default diretory for your daemons is.
"itox -daemon_dir=/usr/sbin < /etc/inetd.conf > xinetd.conf"
I have not been updating itox.  It should generate valid xinetd.conf files,
but they will not take advantage of many of xinetd's features.  You
really should learn the config file anyway.  I'm assuming that if you're
running xinetd, you are somewhat interested in security.  If you're just
going to blindly trust an automatically generated config file for a program
that runs as root, allowing others to access your machine, you probably
do not need to be running xinetd.
I will continue to keep itox in the distribution, and fix any bugs or
compatibility issues that come to my attention, but I probably won't
get around to adding features.  If someone else would like to pick this
up, let me know and I'd be happy to incorperate changes.

I have added support for libwrap.  It is a compile time option, and
you should configure xinetd with --with-libwrap.  When xinetd does
access checking, it will first ask libwrap to check /etc/hosts.allow
and /etc/hosts.deny, then if libwrap accepts the connection, xinetd
will consult its own access control mechanism.

xinetd was originally written by panos@cs.colorado.edu.  At least one other
version of xinetd has been seen floating around the net.  This version is
being maintained by Rob Braun (bbraun@synack.net) and bug reports for this
version should be directed there.

Bug reports/comments/suggestions/flames for this version should be sent
to bbraun@synack.net
