How UNIX Services Work



In Unix, there are essentially two ways of providing a network
service, for eg, on a port:

First, write a deamon that listens on a specific port, and deals with
everything itself. This is the approach that tends to be used with,
for example, apache; you start the apache server using your chosen
method [probably "/etc/rc.d/init.d/apache start"], and it starts
listening on [usually] port 80.

Whenever you try and point a web browser at the web server on that
machine, apache "deals with stuff".

This is the approach more commonly used when startup times are very
long, and daemons are big & complex.


For things that take less time to start up, or where you don't want
the service continuously running, [it uses up a noticable amount of
memory or CPU or something], or... or... or..., There's a much simpler
way of writing a service, commonly used when you have tiny
programs/whatever where you don't want to deal with all the usual
daemon functionality.

What happens is you run a completely different daemon. You tell it what
ALL the services that you want are, and it sits there listening on all
the required ports.

Whenever you try to connect to, say, port 21, it would be able to
start an ftp daemon, connect up the person on the other end & the daemon,
and then let ftpd do the rest.


Great. That second method uses something called "inetd". Commonly,
"Internet superserver" or some such.

You'll find it needs two files, /etc/services and /etc/inetd.conf
/etc/services is a mondo catch-all file, used to map port numbers to
services. For example, a lot of programs allow you to name a service
instead of a port number:
"telnet localhost http", would in fact telnet to port 80. Saves you
having to remember all those pesky numbers...

inetd.conf is then used to tell inetd "this service requires your
attention", and includes things like "when someone connects to this
port, start this daemon".

Great.

inetd.conf has some problems. xinetd is the solution that nobody asked
for, and sucks hairy goat balls. Unfortunately, RedHat think it's a
good thing.

What happens with xinetd is you get a load of bonus functionality
[non-root users can start their own listeners, for example], and an
"easier" config file; basically, in /etc/xinetd.d/, you find a list of
files, each one is sensibly named, with an easy-to-use format, and you
get one-file-per-service.


Before we do a die-cast example, let me just say; xinetd is NOT, IMHO,
a very good solution to the problem. inetd.conf is used on ALL
non-Linux unices, and most of the Linuxy ones. You cannot rely on
either being used or not being used.


Finally, an example, swat [the Samba Web Admin Tool].

From /etc/services:
swat            901/tcp

Means that on port 901, TCP [as opposed to UDP], there's a service
named "swat".

From /etc/inetd.conf:
swat           stream  tcp     nowait.400 root /usr/sbin/swat  swat

Lots of voodoo you don't need to grasp. Salient points are the first
word, the name of the service, matching the one in /etc/services
"tcp", matching the "tcp" in /etc/services [you're allowed to have both
a UDP and a TCP service named the same in /etc/services]
There's also a path and options to the binary that gets run.
If it's not commented out in /etc/inetd.conf, it's running.

Finally, the oh-so-very-easy xinetd variant:
service swat
{
        port            = 901
        socket_type     = stream
        wait            = no
        only_from       = 127.0.0.1
        user            = root
        server          = /usr/sbin/swat
        log_on_failure  += USERID
        disable         = no
}

Guh. So much verbage, for so little return [there are other, better,
mechanisms to do everything in that]

When you change a bit of inetd/xinetd, you need to send the program a
SIGHUP [hangup signal]

ps -aef | grep inet

Look for the PID of the relevant process, then:
kill -HUP pid-of-inet-or-xinet


Enjoy yosselves,
Gary (-;