Home arrow Site Administration arrow Page 3 - Core System Services

Variables and Their Meanings - Administration

Every Linux system has five core services which perform fundamental functions. This article discusses each of these services. It is excerpted from chapter nine of Linux Administration A Beginner's Guide, Third Edition, written by Steven Graham and Steven Shah (McGraw-Hill/Osborne, 2004; ISBN: 0072225629).

  1. Core System Services
  2. CRITICAL SKILL 9.2 Learn the inetd and xinetd Processes
  3. Variables and Their Meanings
  4. Project 9-1 Enabling/Disabling the Telnet Service
  5. CRITICAL SKILL 9.4 Learn How to Use the cron Program
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 10
October 13, 2005

print this article



The variable names that are supported by xinetd are as follows:




This attribute is used to uniquely identify a service. This is useful because services


exist that can use different protocols and need to be described with different entries


in the configuration file. By default, the service ID is the same as the service name.





Any combination of the following values may be used: RPC if this is an RPC service, INTERNAL if this service is provided by xinetd, or UNLISTED if this is a service not listed in the /etc/services file.


This is either the value yes or no. A yes value means that although the service is defined, it is not available for use.


Valid values for this variable are stream to indicate that this service is a stream-based service, dgram to indicate that this service is a datagram, or raw to indicate that this service uses raw IP datagrams. The stream value refers to connection-oriented (TCP) data streams (for example, Telnet and FTP). The dgram value refers to datagram (UDP) streams (for example, the TFTP service is a datagram-based protocol). Other protocols outside the scope of TCP/IP do exist; however, youíll rarely encounter them.


Determines the type of protocol (either tcp or udp) for the connection type.


If this is set to yes, only one connection will be processed at a time. If this is set to no, multiple connections will be allowed by running the appropriate service daemon multiple times.


Specifies the username under which this service will run. The username must exist in the /etc/passwd file.


Specifies the group name under which this service will run. The group must exist in the /etc/group file.


Specifies the maximum number of concurrent connections this service is allowed to handle. The default is no limit if the wait variable is set to nowait.


The name of the program to run when this service is connected.


The arguments passed to the server. In contrast to inetd, the name of the server should not be included in server_args.


Specifies the networks from which a valid connection may arrive. (This is the built-in TCP Wrappers functionality.) You can specify this in one of three ways: a numeric address, a host name, or a network address with netmask. The numeric address can take the form of a complete IP address to indicate a specific host (such as However, if any of the ending octets are zeros, the address will be treated like a network where all of the octets that are zero are wildcards (such as means any host that starts with the numbers 192.168.1). Alternately, you can specify the number of bits in the netmask after a slash (for example, means a network address of with a netmask of




The opposite of only_from in that instead of specifying the addresses from which a connection is valid, this variable specifies the addresses from which a connection is invalid. It can take the same type of parameters as only_from.


Determines where logging information for that service will go. There are two valid values: SYSLOG and FILE. If SYSLOG is specified, you must specify to which syslog facility to log as well (see "Gain Knowledge of the syslogd Daemon," later in this module, for more information on facilities). For example, you can specify: log_type = SYSLOG local0 Optionally, you can include the log level, as well. For example: log_type = SYSLOG local0 info If FILE is specified, you must specify which filename to log. Optionally, you can also specify the soft limit on the file size. The soft limit on a file size is where an extra log message indicating that the file has gotten too large will be generated. If the soft limit is specified, a hard limit can also be specified. At the hard limit, no additional logging will be done. If the hard limit is not explicitly defined, it is set to be 1% higher than the soft limit. An example of the FILE option is as follows: log_type = FILE /var/log/mylog


Specifies which information is logged on a connection success. The options include PID to log the process ID of the service that processed the request, HOST to specify the remote host connecting to the service, USERID to log the remote username (if available), EXIT to log the exit status or termination signal of the process, or DURATION to log the length of the connection.


Specifies the network port under which the service will run. If the service is listed in /etc/services, this port number must equal the value specified there.


Allows a service to bind to a specific interface and only be available there. The value is the IP address of the interface that you wish this service to be bound to. An example of this is binding less secure services (such as Telnet) to an internal and physically secure interface on a firewall and not allowing it the external, more vulnerable interface outside the firewall.


The first argument specifies the maximum number of connections per second this service is allowed to handle. If the rate exceeds this value, the service is temporarily disabled for the second argument number of seconds. For example: cps=1030 This will disable a service for 30 seconds if the connection rate ever exceeds 10 connections per second.

You do not need to specify all of the variables in defining a service. The only required ones are:

  • socket_type
  • user
  • server
  • wait

An Example of a Simple Service Entry

Using the finger service as an example, letís take a look at one of the simplest entries possible with xinetd:

# default: on
# description: The finger server answers finger requests. Finger is \
#       a protocol that allows remote users to see information such \
#       as login name and last login time for local users.
service finger
       socket_type   = stream
       wait          = no
       user          = nobody
       server        = /usr/sbin/in.fingerd

  In Red Hat 7.3, you can find this file in   /etc/xinetd.d/finger.

----------------------------------------------------------------------Progress Check

  1. What is xinetd used for?
  2. What services are typically in the xinetd configuration files?


>>> More Site Administration Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: