Controlling Access to Your Services with xinetd - page 2
Creatures of the Linux Underworld
Let's take a look at the real differences between xinetd and inetd before we get into using xinetd. Anyone who's dealt with the inetd superdaemon is likely familiar with its configuration file, inetd.conf. This file contains a list of all of the services the daemon controls, along with commented out items that it could control if you wanted to activate those services.
That's pretty much all there is to inetd. You can control these services using additional features of Linux itself, such as hosts.allow, hosts.deny, traffic filtering, and so on. But for many people that's not enoughmost of the files discussed in this article are in the /etc directory on most Linux distributions, but sometimes distributions like to utilize a different setup, so you might have to dig for them.
xinetd has a collection of configuration files. The base file is xinetd.conf, which allows for general configuration. Along with the main configuration file is the subdirectory xinetd.d, which contains a series of individual files pertaining to various applications. Each of these files is loaded by the xinetd.conf when xinetd loads its configuration data into memory.
Within each of the xinetd configuration files you have a wide range of choices to control where people can access a service from, what local accounts they can use to access the service, what remote accounts they can use, and much more.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.