When it comes to configuring your own superdaemon, you might be much more fussy than just accepting the defaults. The first thing you need to do is determine which services you want to configure, because what the service is and does will tell you what statements you must include, and what statements won't work at all.

Once you've got a list of what you want to custom configure, decide if you want to alter xinetd.conf itself, or to create a separate file in the xinetd.d directory. I typically recommend that if it's not global, to use the separate files. It just keeps things neater.

Now you have to choose what you want to set for this particular service. There are forty-four available parameters, but only two that must be set for any service. These two are:

• socket_type This entry is determined by whether the underlying protocol used is TCP (which yields a socket type of stream) or UDP (which yields a socket type of "dgram").
• wait This entry is also determined by whether you're using TCP (not) or UDP (yes).

The other required parameters depend on the type of service you're setting up. For the services that xinetd does not handle for you, such as incoming FTP and web requests, you must also have:

• server The path to the program that xinetd needs to start.
• server_args Only required if you need to pass flags, options, or values to the server when it's started.
• user The user that this program should run as. More often than not, this user is root, but never just blindly use root if you can help it.

Another pair of services are referred to as RPC services, and unlisted services. An RPC (Remote Procedure Call) service is a C programming library that supports client/server architecture, allowing a machine to send a command to another machine, which executes the command and then sends back the results. An unlisted service is one that isn't included in /etc/services or /etc/rpcthe file that contains the list of all RPC services.

Keeping the RPC and unlisted services in mind, the remaining required statements (if appropriate for the service you're setting up) are:

• port The port to accept communications for this service on. Only required for unlisted services that don't use RPC.
• protocol The protocol from /etc/protocols that this service requires. Only absolutely necessary for RPC and unlisted services.
• rpc_number The number from /etc/rpc for this services. Only absolutely necessary for RPC and unlisted services.
• rpc_version The version number of RPC that this service requires, either a single number or a range separated by dashes. Only required for RPC services.

From here, everything is optional. Rather than putting you to sleep covering all of the items in the xinetd.conf man page, here are the ones you are most likely to want to use or to run into when editing existing filessee the xinetd.conf man page for in depth specifics on exact syntax and options:

• banner_fail A banner to print for the user who tries to access this service but isn't allowed.
• banner_success A banner to print for the user who successfully accesses this service.
• bind Only accept accesses for this service through a particular network device.
• cps The threshold of connections per second that push xinetd to temporarily disable the service.
• disable A no if you want xinetd to pick up the phone when someone tries to access this service, and a yes if you don't. Often distributions that utilize xinetd will install software such as FTP servers with disable = yes so that they will not be available until you've fully configured the server and then enable it.
• env Ensures that the specified environment variables are in this service's environment.
• group The group that this program should run as.
• instances The number of simultaneous accesses xinetd should allow for this service. UNLIMITED is the default.
• log_on_success What information to log when the service starts and when it stops.
• log_on_failure What information to log when a service can't start due to an error or someone trying to get in who shouldn't.
• log_type Whether to use the syslog daemon or log to a file.
• max_load The threshold of the one minute load average that causes xinetd to refuse connections for this service.
• nice The priority this particular service should have in taking up CPU cycles. See the nice man page for details.
• no_access Expressly forbids access from the specified location to this service. Uses the same formats as only_from.
• only_from Which hosts outside of this server are allowed to access this service.
• per_source Limits how many times someone can access this service from the same location at the same time.
• redirect Whenever someone tries to access this service, point the request to another location and forward it along.

Most of these entries are used in the format:

statement = item1 item2 ...

So, once you know what service you want to configure, where you want to configure it (what file), and what portions you want to configure, you create an entry that looks like this whether you're doing it in the main file or in one of the separate files:

servicename

        statement1 = item1 item2 ...
        statement2 = item1 item2 ...
        ...
}

Once you're finished making these configuration changes, be sure to restart xinetd so it can load the new setup. It's typically a good idea to use the control scripts if your distribution supports them. For example, in Red Hat Linux you would type:

/etc/rc.d/init.d/xinetd restart

Hopefully you've found here that xinetd deserves further investigation. If you're used to inetd then this more secure superdaemon can give you a few headaches at first, but the better control over who's accessing your system, and when, makes up for it.

Sites of interest:
http://www.faqs.org/rfcs/
http://www.networksorcery.com/enp/topic/ipsuite.htm

Dee-Ann LeBlanc has written over 10 computer books, over sixty articles, taught classes, and more, mostly involving the Linux operating system and its programs. You can follow her work and share your input through her new mailing list at http://www.dee-annleblanc.com/mailman/listinfo/general, or find out more in general at http://www.Dee-AnnLeBlanc.com/.

« Back: Creatures of the Linux Underworld