Search Engine

Loading

Sallar

Sallar
RedhatEnterpriseLinux Blog

The xinetd Super Server



Not all services have their own initialization script for starting, stopping, and checking the status of the daemon. Some network services are controlled by xinetd, also known as the super server. Running services through xinetd allows the administrator to utilize xinetd features such as access control, custom logging, and the incoming connection rate. The xinetd service listens on all ports used by the daemons it controls. When a connection is requested, xinetd determines if the client is allowed access. If the client is allowed access, xinetd starts up the desired service and passes the client connection to it. The xinetd RPM package must be installed to use this super server. If it is not, install it via Red Hat Updates.
Configuring the xinetd Server
The xinetd super daemon uses the /etc/xinetd.conf file as the master configuration file and the /etc/xinetd.d/ directory for configuration files per service controlled by xinetd. This section discusses how to use these files to configure xinetd and its services.

Master xinetd Configuration File
Listing shows the default xinetd global configuration file, /etc/xinetd.conf. This file contains settings that apply to all services controlled by xinetd unless the file in /etc/xinetd.d/ for a specific service overrides these default values. If changes are made to this file, execute the service xinetd reload command to enable the changes.
LISTING:  xinetd Global Configuration File
#
# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.
defaults
{
# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
#
# enabled =
# disabled =
# Define general logging characteristics.
log_type = SYSLOG daemon info
log_on_failure = HOST
log_on_success = PID HOST DURATION EXIT
# Define access restriction defaults
#
# no_access =
# only_from =
# max_load = 0
cps = 50 10
instances = 50
per_source = 10
# Address and networking defaults
#
# bind =
# mdns = yes
v6only = no
# setup environmental attributes
#
# passenv =
groups = yes
umask = 002

# Generally, banners are not used. This sets up their global defaults
#
# banner =
# banner_fail =
# banner_success =
}
includedir /etc/xinetd.d
The first two options inside the default section of xinetd.conf are enabled and disabled. Enabling and disabling xinetd services should be done in the individual services files in the /etc/xinetd.d/ directory with the disable attribute set to yes or no as described in the next section “Individual xinetd Service Files.” Using the enabled and disabled options in xinetd.conf is only recommended for temporary situations such as testing or if you think your system has been compromised and need to turn off all the unnecessary services. To use one or both of these attributes, uncomment one or both of them first.
The enabled option can be used to list services that are allowed to accept connections. The services listed with this option still need to be enabled in their individual services files in /etc/xinetd.d/ by setting the disable attribute to no and making sure the DISABLE flag is not listed in the flags attribute. If the disabled option is not set, only the xinetd services in the enabled list are allowed to accept connections.
If the disabled option is set, only the xinetd services in the enabled list accept connections unless they are also in the disabled list. All services listed with the disabled option are not allowed to accept connection requests. Both attributes accept a space-separated list of service IDs. For both these options, the service ID must be used, not the service name. In the individual service files in /etc/xinetd.d/, the id attribute sets the service ID to a unique identifier. If an ID is not given, the ID defaults to the service name. Most service IDs are the same as the service names, but be sure to double-check when using them with the enabled and disabled attributes.
The next set of attributes in the default settings control logging. They are as follows:
. log_type: Set the log service. If set to SYSLOG <facility>, the syslog facility specified is used. If set to FILE <file>, logs are written to the specified file.
. log_on_failure: Set the log service. If set to SYSLOG <facility>, the syslog facility specified is used. If set to FILE <file>, logs are written to the specified file.
. log_on_success: Set what types of messages are logged when a xinetd service is started or when one of them exists. Refer to the man page for xinetd.conf for a complete list of values. With the default xinetd.conf settings, the remote host address and the service process ID are logged.
The next group of attributes sets the defaults for access control.
The next three attributes are address and network default values. The bind and mdns attributes are listed but commented out by default. The usage of these attributes is as follows:
. bind: To only listen for connections on a specific interface, set this value to the IP address of the interface.
. mdns: Set to yes to enable mdns registration, which is currently only available on Mac OS X. Set to no to disable mdns registration.
. v6only: Set to yes to use IPv6 only. Set to no by default to use both IPv4 and IPv6.
Three environmental attributes are listed as well:
. passenv: Commented out by default. If set to a list of environment variables, the values are passed to the service started by xinetd when a connection is requested and allowed to be passed on. If set to a blank value, no variables are passed on except those listed with the env attribute.
. groups: If set to yes, the server is executed with access to the groups accessible by the effective UID of the server. If set to no, the server does not have access to any additional groups. If set to a list of group names, the server is given access to the groups listed.
. umask: Set the default umask for the xinetd services. (The umask can be set for individual services in the individual service file in the /etc/xinetd.d/ directory.)
The very last line in xinetd.conf utilizes the includedir attribute. It tells the super daemon to use the individual service files in the /etc/xinetd.d/ directory.

Individual xinetd Service Files
Each xinetd service has a configuration file in the /etc/xinetd.d/ directory. For example, the xinetd configuration file for rsync is /etc/xinetd.d/rsync as shown.
xinetd Configuration File for rsync
# default: off
# description: The rsync server is a good addition to an ftp server, as it \
# allows crc checksumming etc.
service rsync
{
                disable = yes
                socket_type = stream
                wait = no
                user = root
                server = /usr/bin/rsync
                server_args = —daemon
                log_on_failure += USERID
}
Any of the default attributes from /etc/xinetd.conf can be overwritten in these individual service files. Refer to the xinetd.conf man page with the man xinetd.conf command for a complete list of attributes.
Important attributes listed in the configuration file for each xinetd service include disable, user, and server. The disable attribute determines whether or not the service is accepting incoming connections via xinetd. If set to no, xinetd will hand off connections to it if the client first passes through the xinetd access control. Setting it to yes disables the service. The user specified with the user attribute can be set to a username or a UID. If set to a username, it must be resolvable to a UID from /etc/passwd. This UID owns the server process for the individual xinetd service. The server attributes specifies the program executed if the service is enabled. To enable changes made to the configuration files in /etc/xinetd.d/, use the service xinetd reload command.

Starting and Stopping xinetd
To start, stop, and restart xinetd, use the following command as root:
service xinetd <command>
Replace <command> with one of the following:
. start: Start the xinetd service.
. stop: Stop the xinetd service.
. status: Show the status of xinetd.
. restart: Stop the service if it is running, then start xinetd. If the service is not already running, the stop action will fail, but the start action will still be called.
. condrestart: If the service is already running, and only if the service is already running, restart it.
. reload: Reload the server configuration to enable changes to the configuration files.
To have xinetd start at boot time, execute the following as root:
chkconfig xinetd on
Allowing xinetd Connections
Access control can be configured in the individual files in the /etc/xinetd.d/ directory. When a request is made, the TCP wrappers access control configuration is checked first. If the client is denied access from the TCP wrappers rules, the connection is denied. If the client is allowed access from the TCP wrappers rules, the attributes in the individual /etc/xinetd.d/ files and the /etc/xinetd.conf file are checked. Both forms of access control can be used in conjunction with each other.

0 comments:

Post a Comment

Powered by Blogger.

Ads

 
Copyright © Redhat Enterprise linux. Original Concept and Design by My Blogger Themes
My name is Abdul Razaq but people call me Raziq. Here is my home page: www.redhatenterpriselinux.blogspot.com I live in Quetta, Pakistan and work as an IT-Engineer.