table of contents
RLINETD.CONF(5) | rlinetd 0.8.2 | RLINETD.CONF(5) |
NAME¶
rlinetd.conf - rlinetd configuration fileDESCRIPTION¶
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....
}
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
log "name" {
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:
port
enabled no;
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:
interface
port "telnet", "rcmd",
56, 99;
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
unspecified, this defaults to INADDR_ANY and will bind to all available
interfaces.
Example:
exec
interface 192.168.1.1,
192.168.1.2;
This specifies the invocation of the service.
A number of substitutions can be made within the string; please see String
Modifiers below.
Example:
server
exec "/usr/sbin/in.telnetd
-d";
This specifies the binary to be executed, if
different to exec.
Example:
protocol
server
"/usr/sbin/tcpd";
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:
user
protocol tcp;
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:
group
user "nobody";
This specifies the groupid under which this
service should run. It will accept an argument in either symbolic or numeric
form.
Example:
backlog
group "system";
This is the backlog argument which will be
passed to the listen(2) system call.
Example:
instances
backlog 30;
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:
wait
instances 50;
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:
nice
wait yes;
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:
rpc
nice -5;
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 {
chroot
name "string"; version
3,6,9-15,22;
}
The name parameter is optional, and defaults to the service name.This specifies the root directory for the
service. The string argument can accept modifiers as detailed in String
Modifiers below.
Example:
log
chroot "/tftpboot/%O";
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:
tcpd
log syslog "Service from %O
complete";
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:
exit
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; }
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:
capability
exit;
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:
rlimit
capability
"cap_setuid=ep";
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 {
initgroups
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;
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:
family
initgroups yes;
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:
banner
family ipv6;
This directive lets you dump a file as output
to a connection.
Example:
echo
banner "/etc/nologin";
This directive allows you to output a
dynamically generated line to the connection.
Example:
filter
echo "500 Service denied from your IP
(%O)";
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:
chargen
filter
"/usr/local/lib/rlinetd/filters/privport";
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";
...
}
This construct describes a logging target. The
name parameter is used as an argument to the log directive in
service configurations.
path
defaults {
This specifies the filename for this logfile.
Example:
mode
path
"/var/log/service.log";
This specifies the file permissions for the
logfile. The argument is required to be numeric, and defaults to 0640 if not
specified.
Example:
user
mode 0600;
This specifies the uid of the logfile, and can
be specified as either a numeric uid, or username.
Example:
group
user "adm";
This specifies the gid of the logfile, and can
be specified as either a numeric gid, or groupname.
Example:
group "adm";
...
}
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>.February 21st, 2009 | Debian |