Servers exist to provide services which are implemented through software, typically referred to as daemons. These daemons, like all software, consume precious system resources. Throughout the history of computing, system resources have always been in short supply. While speeds increase, and storage costs decrease, the software beast just becomes more complex and requires even more feeding.

Inetd (pronounced eye-net-d) came about as one solution to this resource problem. Prior to inetd, the ability to provide multiple services on one host would require that each daemon be alive and running. This is an inefficient solution, since under most circumstances, the daemon's aren't doing real work, but rather waiting for a client to make a request.

Inetd solved this problem by being the head "listener" for the daemons under it's control. Inetd would bind itself to the necessary ports, and handle the initial client connection details. Once the connection was established, inetd would then spawn an instance of the appropriate daemon to handle the request.

As with everything, there's some trade-off. Inetd induces a small amount of overhead on each connection. For most systems, this overhead is more than offset by the resource savings afforded by inetd.

Inetd has been happily doing it's job for well over 7 years. Yes, that's 7 Internet years, which by anybody's standard is ancient. In that time, Inetd has seen some modifications, but has remained pretty constant.

Xinetd (pronounced zeye-net-d) was designed and promoted as a replacement for inetd. Xinetd's author claims that the following features make xinetd better than inetd:

• It can do additional access control on all services based on time of access

• Access control works on all services, whether multi-threaded or single-threaded and for both the TCP and UDP protocols. All UDP packets can be checked as well as all TCP connections.

• It provides for hard reconfiguration

• It can prevent denial-of-service

• Extensive logging abilities

• No limit on number of server arguments

• You can bind specifc services to specific IP's on your host machine

Wow, this sounds really cool. (It's Cool, not stability nor security that has the most cachet when living la vida Linux.) The above functionality does indeed improve upon inetd. I especially like the added DoS functionality. However, and this is the reason for this rant, xinetd breaks one of my cardinal rules of computing. Inetd is definitely such an application.

So what is the status of xinetd's compatibility with inetd? From xinetd's FAQ:

Q:	Is it compatible with inetd ?
A:	No, its configuration file has a different format than inetd's one and it understands different signals. However the signal-to-action assignment can be changed and a program has been included to convert inetd.conf to xinetd.conf.

WHAT???

Out of the box, xinetd can't replace inetd. This breaks the transparency rule. At first glance, the less experienced may not see this as a problem. I can hear them now, "Hey, what's the big deal?" Well the big deal my friend, is interoperability. I find it funny that the Linux community is one of the champions of interoperability, yet they don't appear to eat their own dog food.

Inetd is, by its very nature, a software program that interacts with other programs. Inetd hasn't been around for 7+ years because it sucked. It did what it was supposed to do, and quite well. Other software developers have come to rely upon Inetd and inetd.conf.

As an example, Veritas NetBackup uses inetd for it's client connectivity. When you install NetBackup, lines are added to inetd.conf by the installer. This behavior is reflected in many other installers as well. There are just certain things that are so entrenched that their presence is presumed.

Could you imagine trying to implement Unix account management with no references to /etc/passwd?

Ok, I'm getting a bit heated now... so please forgive me while i digress a bit...

      Yes this is about Microsoft...

Remember .ini files?

These were little plain text files which were used to save configuration information. win.ini was one of the more famous .ini files. This one held tons of configuration options. It was known by all, and as a simple text file, configured by many.

This was a problem for Microsoft. This wasn't so much a problem of control, but overall system stability. Back in the .ini days, applications would step on each others toes with .ini changes. Microsoft didn't want hardware or other configuration information in these .ini files, but rather somewhere a bit more organized. Microsoft's solution was to create the registry. I've never been a fan of some of the kung fu required to manage the registry, but I do like it's hierarchical structure.

Now put yourself in Microsoft's shoes. They want to release Windows95 which fully supports this new registry thingamajig. It's new, so therefore nobody uses it, and none of the old software has even the remotest clue about it. So how do you get thousands of hardware vendors to stop writing to .ini files and now use your new fangled registry?

The answer:

      You don't.

Microsoft knew it would be impossible to get 100% acceptance of the registry overnight. So Microsoft devised this little plan. At each boot, software would parse the .ini files looking for changes, and incorporate the changes into the registry.

I think this is a kludge, but hey, it's a kludgey world.

What did this accomplish?

This allowed Microsoft to roll out their new registry, yet maintain as much compatability as possible with older software. Microsoft also knew that given time, and the proper religious training, developers would adopt the registry.

So where does xinetd drop the ball? xinetd does have a script available to parse inetd.conf to xinetd.conf. However, because xinetd doesn't properly support RPC, it can't perform a complete conversion. Not only that, but this script is run manually, not automatically by xinetd.

So what do we have in xinetd? We have an application designed to replace inetd which can't.

Before xinetd is ready for primetime the following changes must be made:

• inetd.conf must still be used
  • If Microsoft can develop a .ini/registry solution, xinetd should be able as well.
  • During the .conf parsing xinetd must first parse inetd.conf. It should then continue on to parsing xinetd.conf. Conflicts should be resolved by deferring to the settings specified in xinetd.conf with a corresponding alert to the system logs.
• RPC support should be properly implemented
  • Inetd does a fine job handling RPC requests, and it's Open Source. xinetd should incorporate the necessary changes to handle RPC properly.

The big deal is that RedHat now includes xinetd by default with no option to use inetd instead. Xinetd isn't ready for production, and should certainly not be included as default. This is once again a clear reminder that ... wait for it...

Linux is for Bitches.