Using xinetd

You can edit the xinetd.conf file while xinetd is running. To get it to reconfigure, send the signal SIGUSR1 to the xinetd process:

# ps -ax | grep xinetd
   50  ?  S    5:47 /usr/sbin/xinetd -filelog /var/adm/xinetd.log -f /etc/xinetd.conf
# kill -SIGUSR1 50

Tail the -filelog you are using to make sure that it restarted and adjusted the changes you made. Definitely do this before you log out and make sure you can log back in if this is a remote connection.

Note that using -HUP, as one does for inetd to reconfigure it, will actually cause xinetd to cease operation. This is, by design, to thwart hackers who reconfigure your xinetd and attempt to reload it without understanding the documentation.

Personally, I use xinetd for almost all of my services; the only one that sees a significant performance hit is my web dæmon Apache. Too many processes have to start too fast for it to be time efficient. DNS services should also not be loaded into xinetd; the performance hit is too large.

I do, however, run sendmail out of xinetd, allowing fine-grained control over who can connect. My configuration for sendmail looks like this:

service smtp
{
        socket_type   = stream
        protocol      = tcp
        wait          = no
        user          = root
        server        = /usr/sbin/sendmail
        server_args   = -bs
        instances     = 20
        nice          = 10
        only_from     += 0.0.0.0
        no_access     += 129.22.122.84 204.0.224.254
}

Even on a high-traffic mail server the performance hit is negligible. I have also loaded sshd into xinetd to prevent a process table attack on it.

I hope this article has been helpful to you in getting xinetd configured and tweaked for your needs. As you can see, the features it offers are tremendously more than inetd, even with tcp_wrappers in place. Solar Designer (http://www.openwall.com/) has a patch available for a slightly older version of xinetd, version 2.2.1, that allows for instance control on a per IP basis, which helps stop simple process table attacks. Note, however, that simple forgery can get around this. I do not know if this patch has been applied to later versions of xinetd or if it can be.