lcfg-xinetd - the lcfg xinetd component. xinetd is the extended Internet services daemon.
This documentation refers to lcfg-xinetd version 0.99.15
This component starts, stops and configures the xinetd daemon. The configuration file used by xinetd is specified by the conffile resource (default is /etc/xinetd.conf). Services generally provide their own configuration file, located in the directory specified by the basedir resource (default is /etc/xinetd.d/). These values can be overridden or specified in their entirety by resources, to produce a final configuration file located in the directory specified by the confdir resource (default is /etc/xinetd.lcfg/).
The configuration file used by the xinetd daemon. Typically this file contains some default values and then specifically includes the directory containing individual service definitions. Default is /etc/xinetd.conf.
The base directory where vendor-provided service definition files can be found. The default is /etc/xinetd.d/. It is very unlikely that you will want to change this value.
The configuration directory that will be used by the xinetd daemon for service definition files - it will be included at the end of the main configuration file (see conffile above). The definitions in this directory can be a combination of files sourced from the directory specified by basedir, those specified entirely by resources (see below), or a combination of the two. Resources defined for a particular service will override the default configuration for that service at the attribute level. The component is responsible for producing the files in this directory.
A list of services to be enabled. Only items in this list will be enabled, regardless of any other factors. Important note: For services that provide their own definition file (in the directory specified by basedir, typically /etc/xinetd.d/), the name of the file should be used in enableservices and also in services (should any of its attributes require to be overridden). This is generally the same as the name of the actual service, but not always. The filename will always be unique, which is why it should be used.
A list of default attributes to be set in the main configuration file (see conffile above).
The assignment operator to be used in the configuration line for this default attribute. Default is =, but -= and += can also be used.
The value for the default attribute.
A list of services for which attributes and values will be defined through resources. Note that these services can be already defined (i.e. already have a configuration file in the directory specified by basedir) - in this case, attributes defined through resources will be added to the service definition and, in the event of conflicts, will override previously set values.
A list of attributes that will be defined for each service listed in services above.
The assignment operator to be used in the configuration line for this attribute. Default is =, but -= and += can also be used.
The value for the attribute.
Here are some examples of how to use resources to control xinetd.
To set the default values in the main configuration file (see conffile), use resources in this way:
xinetd.defaults instances log_type log_on_success \
log_on_failure cps
xinetd.defvalue_instances 60
xinetd.defvalue_log_type SYSLOG authpriv
xinetd.defvalue_log_on_success HOST PID
xinetd.defvalue_log_on_failure HOST
xinetd.defvalue_cps 25 30This would result in the following defaults section being written to the xinetd.conf file:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}To specify a service entirely using LCFG resources, you would need something like the following:
xinetd.services myservice
xinetd.attributes_myservice flags socket_type wait user \
server log_on_failure
xinetd.value_myservice_flags REUSE
xinetd.value_myservice_socket_type stream
xinetd.value_myservice_wait no
xinetd.value_myservice_user root
xinetd.value_myservice_server /usr/sbin/myserviced
xinetd.assignop_myservice_log_on_failure +=
xinetd.value_myservice_log_on_failure USERIDThis would result in a service definition file being created in the directory specified by the confdir resource. The file for the resources above would contain the following definition:
service myservice
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/myserviced
log_on_failure += USERID
}In addition to specifying a service in its entirety, it is possible to add new attributes to an existing service, or override values which have already been set, replacing the defaults in the service's configuration file. For example:
xinetd.services telnet
xinetd.attributes_telnet log_on_failure only_from
xinetd.assignop_telnet_log_on_success +=
xinetd.value_telnet_log_on_success USERID DURATION
xinetd.value_telnet_only_from .localdomain.comThse resources would result in a new attribute only_from being defined for the telnet service and the new value for log_on_success would override the value in /etc/xinetd.d/telnet (pathname here is dependent on basedir).
xinetd(8), xinetd.conf(5), xinetd.log(5)
This is the list of platforms on which we have tested this software. We expect this software to work on any Unix-like platform.
ScientificLinux5, ScientificLinux6
Toby Blake <toby@inf.ed.ac.uk>, Stephen Quinney <squinney@inf.ed.ac.uk>
Copyright (C) 2008 University of Edinburgh. All rights reserved.This library is free software; you can redistribute it and/or modify it under the terms of the GPL, version 2 or later.