Ubuntu Manpage: reconf-inetd - utility to update /etc/inetd.conf and restart inetd

name
synopsis
description
options
files
fragment structure
fragment examples
bugs
history
author
see also

Provided by: reconf-inetd_1.120603_all

NAME

       reconf-inetd - utility to update /etc/inetd.conf and restart inetd

SYNOPSIS

       reconf-inetd [--verbose]
       reconf-inetd --sanity-check=fragment [... fragment]

DESCRIPTION

       reconf-inetd  is  a  maintainer  tool that updates inetd.conf. Such updates are based on xinetd.conf-like
       configuration fragments in /usr/share/reconf-inetd (where server packages install  their  fragments)  and
       /usr/lib/reconf-inetd  (where  reconf-inetd  keeps  track  of which inetd.conf entries have been added by
       itself).

       reconf-inetd identifies every inetd.conf entry based on the combination of three  fields:  service  name,
       protocol, and server path. This allows multiple inetd.conf entries for the same service, eg. for IPv4 and
       IPv6 versions, as well as for different upstreams (eg. proftpd versus ftpd-ssl).

       reconf-inetd will not add inetd.conf entries for services whose server path  is  non-existent,  or  whose
       combination of protocol, service name and server path matches an existing inetd.conf entry.

       reconf-inetd does not support internal services.

OPTIONS

       -h, --help
              show this help message and exit

       -c FRAGMENTS_TO_CHECK, --sanity-check=FRAGMENTS_TO_CHECK
              test   the   validity   of  the  xinetd.conf-like  configuration  fragments,  as  specified  by  a
              space-separated list of files

       -v, --verbose
              explain what happens

       -V, --version
              show version and exit

FILES

       reconf-inetd declares a file-based dpkg trigger on /usr/share/reconf-inetd.  Shadow  fragment  files  are
       stored in /var/lib/reconf-inetd.

       A log file is kept at /var/log/reconf-inetd.log

FRAGMENT STRUCTURE

reconf-inetd fragments are a much simplified version of xinetd.conf(5) fragments. They have this
structure:

service <service_name>
{
<attribute> = <value> <value> ...
...
}

Of the wide range of fields foreseen by xinetd.conf(5), reconf-inetd honors only these fields:

socket_type
protocol (optional, except for RPC and unlisted services)
port (optional, except for unlisted non-RPC services)
wait
user
server
server_args (optional)

If the protocol field is omitted and the service is listed, reconf-inetd will assume the protocol of the
first matching entry from /etc/services. That will be tcp or udp, which currently implies IPv4, so if the
intention is IPv6, then tcp6 or udp6 should be explicitly specified in the protocol field.

Unlike, regular xinetd fragment files, reconf-inetd fragment files must have only one service per file. A
package that provides more than one service must install a separate fragment file for each service. This
is the case to allow for removal of individual services, by simply removing the related file.

/usr/share/reconf-inetd fragments are not configuration files; they're just input to reconf-inetd. Local
admin configuration should be applied to inetd.conf

tcpd-configured service fragments will typically have server set to /usr/sbin/tcpd and server_args will
start with the path to the actual server executable.

Follows a reproduction of valid atrribute values from xinetd.conf(5):

socket_type Possible values for this attribute include:

stream stream-based service

dgram datagram-based service

raw service that requires direct access to IP

seqpacket service that requires reliable sequential datagram transmission

protocol
determines the protocol that is employed by the service. The protocol must exist in
/etc/protocols. If this attribute is not defined, the default protocol employed by the service
will be used.

port determines the service port.

wait This attribute determines if the service is single-threaded or multi-threaded and whether or not
xinetd accepts the connection or the server program accepts the connection. If its value is yes,
the service is single-threaded; this means that xinetd will start the server and then it will stop
handling requests for the service until the server dies and that the server software will accept
the connection. If the attribute value is no, the service is multi-threaded and xinetd will keep
handling new service requests and xinetd will accept the connection. It should be noted that
udp/dgram services normally expect the value to be yes since udp is not connection oriented, while
tcp/stream servers normally expect the value to be no.

user determines the uid for the server process. The user attribute can either be numeric or a name. If
a name is given (recommended), the user name must exist in /etc/passwd. This attribute is
ineffective if the effective user ID of xinetd is not super-user.

server determines the program to execute for this service.

server_args
determines the arguments passed to the server.

FRAGMENT EXAMPLES

       Here is an example fragment:

           service finger
           {
               socket_type = stream
               protocol = tcp6
               wait = no
               user = nobody
               server = /usr/sbin/fingerd
           }

       and it's tcpd-enabled version:

           service finger
           {
               socket_type = stream
               protocol = tcp6
               wait = no
               user = nobody
               server = /usr/sbin/tcpd
               server_args = /usr/sbin/fingerd
           }

BUGS

       Known issues and missing features are listed in /usr/share/doc/reconf-inetd/TODO

HISTORY

       reconf-inetd is a replacement for update-inetd. The motivation for and design of reconf-inetd is detailed
       at the Debian Enhancement Proposal 9, at http://dep.debian.net/deps/dep9/, a copy  of  which  is  locally
       available at /usr/share/doc/reconf-inetd/dep9.html

AUTHOR

       reconf-inetd was designed, documented and implemented by Serafeim Zanikolas <sez@debian.org>