Provided by: rlinetd_0.9.1-1_amd64 bug

NAME

       rlinetd.conf - rlinetd configuration file

DESCRIPTION

       rlinetd.conf  holds configuration information for rlinetd.  There are a small number of similar top level
       constructs, differing chiefly in which options can be meaningfully used with them.

       All strings are quoted with the "  character.  In  some  situations  (e.g.  the  log,  exec,  and  chroot
       directives), there are a number of variables that can be substituted into the string.
       Unless stated otherwise, all numbers must be positive.

       service "name" {
              ...
       }

              This  construct describes a service. The name parameter is for naming convenience alone, it simply
              serves to distinguish logging messages and provides a default  for  options  which  can  logically
              accept a name as an argument.

              enabled
                     This construct allows easily enabling or disabling service.  The argument can be either yes
                     or no.  The default value is yes.  Setting this to no disables service.

                     Example:
                       enabled no;

              port
                     This lists the ports that the service should be made available on. The ports can be  listed
                     in  either  string  or  numeric  format.  If  unspecified, this defaults to the name of the
                     service unless the service is an RPC  service,  in  which  case  the  port  value  will  be
                     dynamically assigned by the system.

                     Example:
                       port "telnet", "rcmd", 56, 99;

              interface
                     This  specifies which interfaces the listed ports should be bound on. It takes a list of IP
                     addresses as an argument, corresponding to  the  configured  addresses  of  the  interfaces
                     required.  If  this keyword is not given or when a special value any is assigned to it, the
                     service will bind to all available interfaces.

                     Examples:
                       interface 192.168.1.1, 192.168.1.2;

                       interface any;

              exec
                     This specifies the invocation of the service. A number of substitutions can be made  within
                     the string; please see String Modifiers below.

                     Example:
                       exec "/usr/sbin/in.telnetd -d";

              server
                     This specifies the binary to be executed, if different to exec.

                     Example:
                       server "/usr/sbin/tcpd";

              protocol
                     This  specifies  the  socket  protocol  to use when listening on ports for the service. The
                     argument can be either tcp or udp.  The default setting for this variable is tcp.

                     Example:
                       protocol tcp;

              user
                     This specifies the userid under which this service should run. It will accept  an  argument
                     in  either symbolic or numeric form. Unless group (see below) is given, the groupid is also
                     set to the user's primary group.

                     Example:
                       user "nobody";

              group
                     This specifies the groupid under which this service should run. It will accept an  argument
                     in either symbolic or numeric form.

                     Example:
                       group "system";

              backlog
                     This is the backlog argument which will be passed to the listen(2) system call.

                     Example:
                       backlog 30;

              instances
                     This specifies the maximum number of service instances that can be running at any one time.
                     The default setting for this variable is 40.

                     Example:
                       instances 50;

              wait
                     This directive emulates the inetd(8) wait behaviour.  The argument can be either yes or no.
                     The  default value is no.  Setting this to yes also resets the value of instances option to
                     1.

                     Example:
                       wait yes;

              nice
                     This specifies the process priority to run this service at. The argument is passed directly
                     to the setpriority(2) system call. The value may be negative.

                     Example:
                       nice -5;

              rpc
                     This specifies that the service should be registered with the system's portmap(8) mapper as
                     an RPC service. It accepts a list of arguments as follows.

                     rpc {
                            name "string"; version 3,6,9-15,22;
                     }

                     The name parameter is optional, and defaults to the service name.

              chroot
                     This specifies the root directory for the service. The string argument can accept modifiers
                     as detailed in String Modifiers below.

                     Example:
                       chroot "/tftpboot/%O";

              log
                     This  directive  takes  two  arguments.  The  first  must  be either the symbolic name of a
                     previously specified log directive (see below),  or  the  unquoted  word  syslog.   If  the
                     latter,  the  message  will  be  logged  via the syslog(3) call. The second argument is the
                     message that will be logged, subject to the modifiers detailed in String Modifiers below.

                     Example:
                       log syslog "Service from %O complete";

              tcpd
                     This  directive causes access controls as specified by tcp_wrappers to be applied. This has
                     the same effect as invoking a service with a server argument of /usr/sbin/tcpd (or wherever
                     your tcpd(8) program is kept), but saves the additional step of starting  the  program.  It
                     will  accept  up  to two additional arguments. The first is a service name to apply against
                     its rules, and the second is a block of instructions to execute if matched. If no  name  is
                     specified,  it  defaults  to  the  name  of  the  service.  If the instruction block is not
                     specified, it defaults to 'exit;'.

                     Examples:
                       tcpd "in.telnetd";

                       tcpd { exec "/usr/local/bin/winnuke %O"; }

                       tcpd "pointless" { echo "Hi guys, come on in."; }

                       tcpd "defiant" { echo "500 Access denied from %O."; exit; }

              exit
                     This directive is only useful in an instruction block argument to the tcpd directive.  Note
                     well  -  not  using  it (and not specifying some other terminating directive, such as exec)
                     will result in the service being run forever.

                     Example:
                       exit;

              capability
                     This directive specifies the capabilities that this service should have when  running.  The
                     argument  is a string that is passed directly to cap_from_text(3).  I know, that's a pretty
                     lousy description, but this feature is of limited utility until and  unless  you  read  the
                     README.capabilities file anyway.

                     Example:
                       capability "cap_setuid=ep";

              rlimit
                     This  directive  takes  two  arguments.  The first is a symbol specifying the type of limit
                     required. These are listed below. The second argument takes one of two forms. It can either
                     be  a  single numeric value, in which case both of the soft and hard limits of the resource
                     in question will be set to this value. Alternatively, it can be a list in the form:

                     rlimit type {
                            soft x; hard y;
                     }

                     In which case the hard and soft limits will be set appropriately. In either case, the  word
                     unlimited  can  be specified instead of a numeric value, thus removing any restriction. The
                     values are passed directly to the setrlimit(2) syscall, and should  be  specified  in  that
                     context.

                     Types:
                       cpu, fsize, data, stack, core, rss, nproc, nofile, memlock

                     Example:
                       rlimit cpu 15;

              initgroups
                     The  argument can be either yes or no.  This directive causes initgroups(3) to be called at
                     service startup, which sets the supplementary  groups  of  the  service  according  to  the
                     /etc/group file.

                     Example:
                       initgroups yes;

              family
                     This  directive  specifies the protocol family that rlinetd should bind sockets on for this
                     service. Currently, this can be either ipv4 or ipv6.   If  unspecified,  this  defaults  to
                     something appropriate for the system.

                     Example:
                       family ipv6;

              banner
                     This directive lets you dump a file as output to a connection.

                     Example:
                       banner "/etc/nologin";

              echo
                     This directive allows you to output a dynamically generated line to the connection.

                     Example:
                       echo "500 Service denied from your IP (%O)";

              filter
                     This  directive  allows  you to specify a Linux Socket Filter program to be associated with
                     the listening socket. These can be generated with a tool such as lsfcc(1).

                     Example:
                       filter "/usr/local/lib/rlinetd/filters/privport";

              chargen
                     This directive loops eternally, outputting data to any connection. If no argument is given,
                     it  echoes  a subset of the printable characters. However, a filename can be supplied as an
                     argument, in which case the contents of that file are output in a loop.

                     Example:
                       chargen "/usr/local/lib/spam";

       log "name" {
              ...
       }

              This construct describes a logging target. The name parameter is used as an argument  to  the  log
              directive in service configurations.

              path
                     This specifies the filename for this logfile.

                     Example:
                       path "/var/log/service.log";

              mode
                     This  specifies  the  file  permissions  for  the  logfile.  The argument is required to be
                     numeric, and defaults to 0640 if not specified.

                     Example:
                       mode 0600;

              user
                     This specifies the uid of the logfile, and can be specified as either  a  numeric  uid,  or
                     username.

                     Example:
                       user "adm";

              group
                     This  specifies  the  gid  of the logfile, and can be specified as either a numeric gid, or
                     groupname.

                     Example:
                       group "adm";

       defaults {
              ...
       }

              This construct takes the same parameters as a service declaration, but  instead  of  specifying  a
              service sets defaults for all services specified subsequently.

       directory "path" "match" "ignore";
              This  construct  specifies a directory which contains additional configuration files to be parsed.
              Parsing of these additional files does not commence until the current file is complete. The  match
              and  ignore  arguments  are  optional,  and  if  specified,  are  used  to filter the files in the
              directory. Filenames must match the match regexp, if given, and must not match the ignore  regexp,
              if  given.  Filenames  beginning with a period ('.') are skipped in all cases. Directories are not
              recursed into.

   String Modifiers
       There are a number of variables which can be substituted into arguments to some directives. Although they
       can all be used in the same places, the information accessed by some is unavailable in certain cases.

       %O     The source IP address of the connection.

       %P     The source port of the connection.

       %C     The total CPU time used.

       %U     The user CPU time used.

       %S     The system CPU time.

       %r     Maximum resident set size.

       %m     Shared memory size.

       %d     Unshared data size.

       %s     Unshared stack size.

       %f     Page reclaims.

       %F     Page faults.

       %p     Swaps.

       %i     Block input operations.

       %o     Block output operations.

       %n     Messages sent.

       %c     Messages received.

       %k     Signals received.

       %w     Voluntary context switches.

       %w     Involuntary context switches.

       %e     Exit code.

       %t     Running time.

       %M     The  current  time  expressed  as seconds since epoch 1980, dumped as a network order 32 bit word.
              This has absolutely no use other than in implementing the inetd-like time functionality.

       %I     The current time and date, in pretty-printed ctime(3) format.

SEE ALSO

       rlinetd(8), hosts_access(5)

AUTHOR

       This manual page was written by Mikolaj J.  Habryn  <dichro-doc@rcpt.to>.   Modified  by  Robert  Luberda
       <robert@debian.org>.