Services in xinetd and /etc/rc.d/init.d

[SGK]

Hi,

For some services( httpd & mysqd ), we are using /etc/rc.d/init.d/httpd & /etc/rc.d/init.d/mysqld.

For others( telnet & ftp ), we are using /etc/xinetd.d/telnetd & /etc/xinetd.d/wu-ftpd.

Why these difference? And when to use /etc/rc.d/init.d/ and /etc/xinetd.d/ for servies?

[Alexander Chuzhoy]

You can get your answer from reading the man of xinetd.
"xinetd performs the same function as inetd: it starts programs that provide Internet services. Instead of having such servers started at system initialization time, and be dormant until a connection request arrives, xinetd is the only daemon process started and it listens on all service ports for the services listed in its configuration file.

So far, the only reason for the existence of a super-server was to conserve system resources by avoiding to fork a lot of processes which might be dormant for most of their lifetime."

[Stuart Browne · Accepted solution]

'xinetd' is what's called a super-server. It handles the incoming TCP and UDP connections for a number of 'trivial' services.

Others, such as 'httpd' and 'mysqld' are stand-aline services. They handle their own socket connections.

Each service is different, though some can be used in both manners (Samba can be used both ways, but is much more efficient as a stand-alone).

Generally, things with high-volume connection rates (mail, web, database) will be stand-alone, whilst things which only have occasional connections (telnet, time, etc) are launched from the super-server.

To find out what's running as what on a RedHat (or Fedora or SuSE) machine, you can use the 'chkconfig --list' command.

If it has a run-level beside it, it is launched from '/etc/init.d/ [start|stop|status]' (or using the 'service' command).

If it only has the one column of on/off, it's launched from 'xinetd' (and can be controlled using 'chkconfig on/off').

Hope this helps.

[Matti_Kurkela]

If xinetd is used to start a service, xinetd will listen on the service's network port. When someone tries to connect to that service, xinetd starts the real service process and forwards the incoming connection to it. At the same time, xinetd can offer some extra functionality: TCPwrapper/libwrap access control, limiting the number of simultaneous connections and a standard logging for connection attempts.

If a service is started using a script in /etc/rc.d/init.d/, it will start immediately. There is no "helper" for access control, logging and connection limiting functions: the service process must handle all these things as necessary.

If a service starts up through xinetd, it must be able to service requests almost immediately after the real service process starts up. If the service process needs to do a lot of preparation after startup before it can service the client's request, startup through xinetd is unsuitable.

Mysqld needs to open the database(s) and check its validity before it can service requests. Httpd may need some time to generate random numbers for SSL session keys and/or HTTP digest authentication. Sshd requires some time at startup to generate SSH session keys.

For httpd, response time is critical: at worst case, each page element (each frame, each individual image...) may be requested through a separate connection, so the number of connections per unit of time can easily grow large. If all the startup work was done separately for each request, the user would think "this server is slow".

For telnet and FTP, a bit of slowness at the beginning of the connection does not matter so much.

[Stuart Browne]

Actually, OpenSSH is one of those daemons that can be set up both as a stand-alone daemon, or using xinetd.

It's just not as efficient to do it via xinetd.

[SGK]

Can I use TcpWrapper without xinetd? i.e) I am going to use the /etc/rc.d/init.d/ for service and control the access of the service using Tcpwrapper?

If I can able to use TcpWrapper with /etc/rc.d/init.d/ and without xinetd means, then whats the important of xinetd in this case?

[Matti_Kurkela]

Without xinetd (or some other kind of inetd) you cannot use tcpwrapper, because the "wrapping" mechanism is built around the functionality of *inetd.

(*inetd = any kind of inetd, meaning a traditional inetd, xinetd or any other replacement for the traditional inetd)

If your service has support for libwrap built-in, it can use the same access control mechanism as tcpwrapper does. However, tcpwrapper can be added without no changes to the service program's source code; adding libwrap support always requires source code changes.

Neither tcpwrapper nor libwrap can limit the number of simultaneous connections. Xinetd can do that, and some services that are designed to be used without xinetd have their own facilities for doing that.

The original point of *inetd is that it simplifies network service programming: in fact, you don't need to know anything about network socket programming to build a simple unicast TCP server using *inetd: you just need to make a program that uses the required protocol in stdin/stdout. You can test it on the command line, and when you plug it into *inetd, it handles the forwarding of the server program's stdin/stdout to the connected network socket... and there you have a network server program.

This also means you can upgrade most TCP/IP services that use *inetd to IPv6 simply by plugging the services to an IPv6-aware *inetd.

(There are exceptions, though: tcpwrapper and identd would need to be upgraded because they needs to access information *about* network sockets, but services like POP and IMAP should handle the transition just fine.)

[Stuart Browne]

No, that's not entirely true.

Some stand-alone services use TCP wrappers, if it is compiled into them.

For instance, SSHd and Sendmail have TCP Wrapper support built into them on most systems.

MySQL and Apacye do not however, as they have their own way of allowing or denying services.

Read the documentation for each service to find out more

[Stuart Browne]

My apologies, please ignore last message. Didn't read all of the other post :)