xinetd

package: xinetd

title: xinetd(8)

summary: the extended Internet services daemon

text:
# xinetd(8)

## NAME
xinetd - the extended Internet services daemon

## SYNOPSIS
xinetd [options]

## DESCRIPTION
xinetd performs the same function as inetd: it starts programs that provide Internet services. Instead of having such servers started at system initialization time, and be dormant until a connection request arrives, xinetd is the only daemon process started and it listens on all service ports for the services listed in its configuration file. When a request comes in, xinetd starts the appropriate server. Because of the way it operates, xinetd (as well as inetd) is also referred to as a super-server.

The services listed in xinetd's configuration file can be separated into two groups. Services in the first group are called multi-threaded and they require the forking of a new server process for each new connection request. The new server then handles that connection. For such services, xinetd keeps listening for new requests so that it can spawn new servers. On the other hand, the second group includes services for which the service daemon is responsible for handling all new connection requests. Such services are called single-threaded and xinetd will stop handling new requests for them until the server dies. Services in this group are usually datagram-based.

So far, the only reason for the existence of a super-server was to conserve system resources by avoiding to fork a lot of processes which might be dormant for most of their lifetime. While fulfilling this function, xinetd takes advantage of the idea of a super-server to provide features such as access control and logging. Furthermore, xinetd is not limited to services listed in /etc/services. Therefore, anybody can use xinetd to start special-purpose servers.

## OPTIONS
-d

Enables debug mode. This produces a lot of debugging output, and it makes it possible to use a debugger on xinetd.

-syslog syslog_facility

This option enables syslog logging of xinetd-produced messages using the specified syslog facility. The following facility names are supported: daemon, auth, user, local[0-7] (check syslog.conf(5) for their meanings). This option is ineffective in debug mode since all relevant messages are sent to the terminal.

-filelog logfile

xinetd-produced messages will be placed in the specified file. Messages are always appended to the file. If the file does not exist, it will be created. This option is ineffective in debug mode since all relevant messages are sent to the terminal.

-f config_file

Determines the file that xinetd uses for configuration. The default is /etc/xinetd.conf.

-pidfile pid_file

The process ID is written to the file. This option is ineffective in debug mode.

-dontfork

Tells xinetd to stay in the foreground rather than detaching itself, to support being run from init or daemontools. This option automatically sets -stayalive (see below).

-stayalive

Tells xinetd to stay running even if no services are specified.

-remlock

Tells xinetd to remove lockfile (/var/lock/subsys/xinetd by default) on exit.

-limit proc_limit

This option places a limit on the number of concurrently running processes that can be started by xinetd. Its purpose is to prevent process table overflows.

-logprocs limit

This option places a limit on the number of concurrently running servers for remote userid acquisition.

-version

This option causes xinetd to print out its version information.

-inetd_compat

This option causes xinetd to read /etc/inetd.conf in addition to the standard xinetd config files. /etc/inetd.conf is read after the standard xinetd config files.

-cc interval

This option instructs xinetd to perform periodic consistency checks on its internal state every interval seconds.

The syslog and filelog options are mutually exclusive. If none is specified, the default is syslog using the daemon facility. You should not confuse xinetd messages with messages related to service logging. The latter are logged only if this is specified via the configuration file.

## CONTROLLING XINETD
xinetd performs certain actions when it receives certain signals. The actions associated with the specific signals can be redefined by editing config.h and recompiling.

SIGHUP

causes a hard reconfiguration, which means that xinetd re-reads the configuration file and terminates the servers for services that are no longer available. Access control is performed again on running servers by checking the remote location, access times and server instances. If the number of server instances is lowered, some arbitrarily picked servers will be killed to satisfy the limit; this will happen after any servers are terminated because of failing the remote location or access time checks. Also, if the INTERCEPT flag was clear and is set, any running servers for that service will be terminated; the purpose of this is to ensure that after a hard reconfiguration there will be no running servers that can accept packets from addresses that do not meet the access control criteria.

SIGQUIT

causes program termination.

SIGTERM

terminates all running servers before terminating xinetd.

SIGUSR1

causes an internal state dump (the default dump file is /var/run/xinetd.dump; to change the filename, edit config.h and recompile).

SIGIOT

causes an internal consistency check to verify that the data structures used by the program have not been corrupted. When the check is completed xinetd will generate a message that says if the check was successful or not.

On reconfiguration the log files are closed and reopened. This allows removal of old log files.

## FILES
/etc/xinetd.conf

default configuration file

/var/run/xinetd.dump

default dump file

## SEE ALSO
inetd(8),

xinetd.conf(5),

xinetd.log(5)

http://cr.yp.to/daemontools.html

## AUTHORS
Panos Tsirigotis, CS Dept, University of Colorado, Boulder

Rob Braun

## PRONUNCIATION
zy-net-d


title: xl2tpd(8)

summary: Layer 2 Tunneling Protocol Daemon.

text:
# xl2tpd(8)

## NAME
xl2tpd - Layer 2 Tunneling Protocol Daemon.

## DESCRIPTION
xl2tpd is an implementation of the Layer 2 Tunneling Protocol (RFC 2661). L2TP allows to tunnel PPP over UDP. Some ISPs use L2TP to tunnel user sessions from dial-in servers (modem banks, ADSL DSLAMs) to back-end PPP servers. Another important application is Virtual Private Networks (VPN) where the IPsec protocol is used to secure the L2TP connection (L2TP/IPsec, RFC 3193).

xl2tpd works by opening a pseudo-tty for communicating with pppd. It runs completely in userspace but supports kernel mode L2TP.

xl2tpd supports IPsec SA Reference tracking to enable overlapping internak NAT'ed IP's by different clients (eg all clients connecting from their linksys internal IP 192.168.1.101) as well as multiple clients behind the same NAT router.

This implementation is based on L2TPd 0.61 from http://www.marko.net/l2tp and patches collected by Jacco de Leeuw at http://www.jacco2.dds.nl/networking/openswan-l2tp.html.

## OPTIONS
-D

This option prevents xl2tpd from detaching from the terminal and daemonizing.

-l

This option tells xl2tpd to use syslog for logging even when -D was specified.

-c <config_file>

Set an alternate config file. Fallback configuration file is /etc/l2tpd/l2tpd.conf.

-s <secret_file>

Tells xl2tpd to use an alternate "secrets" file.

-p <pid_file>

Set an alternate pid file. Default is /var/run/xl2tpd/xl2tpd.pid.

-C <control_file>

Set an alternate control file.

## FILES
/etc/xl2tpd/xl2tpd.conf

Configuration file of xl2tpd, used by default.

/etc/xl2tpd/l2tp-secrets

Secrets file, used by default.

/var/run/l2tp-control

Control file, used by default.

## BUGS
Please use the github project page https://github.com/xelerance/xl2tpd to send bugreports, issues and any other feedback.

## SEE ALSO
xl2tpd.conf(5), xl2tpd-control(8), pppd(8)

## COPYLEFT
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program (see the file LICENSE); if not, see https://www.gnu.org/licenses/, or contact Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

## CONTRIBUTORS
Alexander Dorokhov <alex.dorokhov@gmail.com>

Alexander Naumov <alexander_naumov@opensuse.org>

## AUTHORS
Forked from l2tpd by Xelerance: https://github.com/xelerance/xl2tpd

Michael Richardson <mcr@xelerance.com>

Paul Wouters <paul@xelerance.com>

Samir Hussain <shussain@xelerance.com>

Previous development was hosted at sourceforge (http://www.sourceforge.net/projects/l2tpd) by:

Scott Balmos <sbalmos@iglou.com>

David Stipp <dstipp@one.net>

Jeff McAdams <jeffm@iglou.com>

Based off of l2tpd version 0.61. Many thanks to Jacco de Leeuw <jacco2@dds.nl> for maintaining l2tpd.

Copyright (C)1998 Adtran, Inc.

Mark Spencer <markster@marko.net>


title: xl2tpd-control(8)

summary: xl2tpd control utility.

text:
# xl2tpd-control(8)

## NAME
xl2tpd-control - xl2tpd control utility.

## DESCRIPTION
xl2tpd is an implementation of the Layer 2 Tunneling Protocol (RFC 2661). L2TP allows to tunnel PPP over UDP. Some ISPs use L2TP to tunnel user sessions from dial-in servers (modem banks, ADSL DSLAMs) to back-end PPP servers. Another important application is Virtual Private Networks where the IPsec protocol is used to secure the L2TP connection (L2TP/IPsec, RFC 3193).

xl2tpd works by opening a pseudo-tty for communicating with pppd. It runs completely in userspace but supports kernel mode L2TP.

xl2tpd supports IPsec SA Reference tracking to enable overlapping internak NAT'ed IP's by different clients (eg all clients connecting from their linksys internal IP 192.168.1.101) as well as multiple clients behind the same NAT router.

## SYNOPSIS
xl2tpd-control [-c PATH] <COMMAND> <TUNNEL_NAME> [OPTIONS]

## OPTIONS
-c

This option specifies xl2tpd control file.

-d

This option enables debugging mode.

## COMMANDS
add-lac

Adds new or modify existing LAC (L2TP Access Concentrator) configuration. Configuration should be specified as a command options in <key>=<value> pairs format. See available options in xl2tpd.conf(5).

connect-lac

Establish new connection to LAC. Username and secret for tunnel can be passed as a command options.

disconnect-lac

Disconnects tunnel.

remove-lac

Removes existing LAC configuration. xl2tpd disconnects the tunnel before removing.

add-lns

Adds new or modify existing LNS (L2TP Network Server) configuration.

remove-lns

Removes existing LNS configuration.

status-lns

Check the status of LNS.

available

Check availability.

## BUGS
Please use the github project page https://github.com/xelerance/xl2tpd to send bugreports, issues and any other feedback.

## SEE ALSO
xl2tpd.conf(5), xl2tpd(8), pppd(8)

## COPYLEFT
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program (see the file LICENSE); if not, see https://www.gnu.org/licenses/, or contact Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

## CONTRIBUTORS
Alexander Dorokhov <alex.dorokhov@gmail.com>

Alexander Naumov <alexander_naumov@opensuse.org>

## AUTHORS
Forked from l2tpd by Xelerance: https://github.com/xelerance/xl2tpd

Michael Richardson <mcr@xelerance.com>

Paul Wouters <paul@xelerance.com>

Samir Hussain <shussain@xelerance.com>

Previous development was hosted at sourceforge (http://www.sourceforge.net/projects/l2tpd) by:

Scott Balmos <sbalmos@iglou.com>

David Stipp <dstipp@one.net>

Jeff McAdams <jeffm@iglou.com>

Based off of l2tpd version 0.61. Many thanks to Jacco de Leeuw <jacco2@dds.nl> for maintaining l2tpd.

Copyright (C)1998 Adtran, Inc.

Mark Spencer <markster@marko.net>


xrdp

package: xrdp

title: xrdp(8)

summary: a Remote Desktop Protocol (RDP) server

text:
# xrdp(8)

## NAME
xrdp - a Remote Desktop Protocol (RDP) server

## SYNTAX
xrdp --kill

xrdp --help

xrdp --version

xrdp [--nodaemon] [--port port] [--fork] [--dump-config] [--config /path/to/xrdp.ini]

## DESCRIPTION
xrdp is a Remote Desktop Protocol (RDP) Server.

Unlike Windows NT/2000/2003 server, xrdp will not display a Windows desktop but an X window desktop to the user.

It can also be used as a VNC->RDP bridge.

## OPTIONS
-k, --kill

Kill running xrdp daemon.

-h, --help

Output help information and exit.

-v, --version

Output version information and exit.

-n, --nodaemon

Start xrdp in foreground instead of starting it as a daemon.

-p, --port

Specify TCP port to listen to. This overrides port setting in xrdp.ini file.

-f, --fork

Fork a new process on a new connection. If not enabled, use a new thread for every connection. This overrides fork setting in xrdp.ini file.

--dump-config

Print the configuration on stdout before starting the daemon. The default is not to do this.

-c, --config

Specify a path to a different xrdp.ini file. This option is intended to be used primarily for testing or for unusual configurations.

## FILES
/usr/sbin/xrdp

/etc/xrdp/xrdp.ini

/var/log/xrdp.log

/var/run/xrdp.pid

## AUTHORS
Jay Sorg <jsorg71@users.sourceforge.net>

Simone Fedele <ilsimo@users.sourceforge.net>

## SEE ALSO
xrdp.ini(5), xrdp-sesman(8), sesman.ini(5), xrdp-sesrun(8)

for more info on xrdp see http://www.xrdp.org/


xrdp-chansrv

title: xrdp-chansrv(8)

summary: xrdp channel server

text:
# xrdp-chansrv(8)

## NAME
xrdp-chansrv - xrdp channel server

## SYNTAX
xrdp-chansrv

## DESCRIPTION
xrdp-chansrv is the xrdp(8) channel server, which manages the Remote Desktop Protocol (RDP) sub-channels.

This program is only forked internally by xrdp-sesman(8).

Currently xrdp-chansrv knows about the following channels:

cliprdr

Clipboard Redirection

rdpsnd

Remote Desktop Protocol Sound

rdpdr

Remote Desktop Protocol Device Redirection

rail

Remote Applications Integrated Locally

drdynvc

Dynamic Virtual Channel

## ENVIRONMENT
CHANSRV_LOG_PATH

Path to the location where the log file is stored. If not specified, $XDG_DATA_HOME/xrdp or $HOME/.local/share/xrdp is used instead.

DISPLAY

X11 display number. Must be specified.

## FILES
/etc/xrdp/sesman.ini

Contains some settings for this program.

/var/run/xrdp/xrdp_chansrv_socket_*

UNIX socket used by external programs to implement channels.

/var/run/xrdp/xrdp_api_*

UNIX socket used by xrdp-chansrv to communicate with xrdp-sesman.

xrdp-chansrv.%s.log

Log file used by xrdp-chansrv(8). %s is display number. See the description of CHANSRV_LOG_PATH above for the file's location.

## SEE ALSO
xrdp-sesman(8), sesman.ini(5).

For more info on xrdp see http://www.xrdp.org/


title: xrdp-dumpfv1(8)

summary: Display content of .fv1 font files

text:
# xrdp-dumpfv1(8)

## NAME
xrdp-dumpfv1 - Display content of .fv1 font files

## SYNOPSIS
xrdp-dumpfv1 [ options ] fv1_file

## DESCRIPTION
xrdp-dumpfv1 can be used to display the contents of an fv1 file.

## OPTIONS
A summary of options is included below.

One of -i, -t, or -c must be specified.

-i

Displays general information about the fv1 file.

-t

Displays a CSV table of all the glyphs in the font. This table can be imported into a spreadsheet program for further manipulation.

-c <character>

Displays detailed information about a particular glyph in the font, including a representation of the bitmap for the glyph. Specify the character using one of the following strings:

U+<hex> - Unicode character, e.g. U+25 for a percentage symbol (%).

@<char> - Unicode character, e.g. @% for a percentage symbol.

number - Unicode value as an integer, e.g. 37 for a percentage symbol

Note that the row numbers shown in the font data are relative to the natural font baseline. If comparing two fonts, be aware that when the glyph is drawn, the row number may be affected by the global descender value for the font (displayed with -i).

## EXAMPLES
xrdp-dumpfv1 -i /usr/share/xrdp/sans-10.fv1

Displays global information about the sans 10 font file distributed with xrdp.

xrdp-dumpfv1 -c @'*' /usr/share/xrdp/sans-10.fv1

Displays information about the asterisk symbol in the sans 10 font file distributed with xrdp.

## SEE ALSO
xrdp-mkfv1(8).

More info on xrdp can be found on the xrdp homepage


xrdp-genkeymap

title: xrdp-genkeymap(8)

summary: key map generator for XRDP

text:
# xrdp-genkeymap(8)

## NAME
xrdp-genkeymap - key map generator for XRDP

## SYNTAX
xrdp-genkeymap file

## DESCRIPTION
xrdp-genkeymap extracts the key map used by the currently running X session to generated a mapping from Remote Desktop Protocol (RDP) key codes to X keysyms and Unicode code points.

## OPTIONS
outfile

The key map information is stored in the file named outfile.

## FILES
/etc/xrdp/km-XXXXXXXX.ini

Files containing the keyboard mapping for language XXXXXXXX, which is a 8 digit hexadecimal number identifying the country and language code.

00000405

cs Czech

00000407

de German

00000409

en-us US English

0000040c

fr French

00000410

it Italian

00000416

br Portuguese (Brazil)

00000419

ru Russian

0000041d

se Swedish

00000809

en-uk UK English

## AUTHORS
Jay Sorg <jsorg71@users.sourceforge.net>

Simone Fedele <ilsimo@users.sourceforge.net>

## SEE ALSO
xrdp(8), setxkbmap(1), unicode(7)

Description of Keyboard Input mapping on the FreeRDP wiki

For more info on xrdp see http://www.xrdp.org/


xrdp-keygen

title: xrdp-keygen(8)

summary: xrdp RSA key generation utility

text:
# xrdp-keygen(8)

## NAME
xrdp-keygen - xrdp RSA key generation utility

## SYNOPSIS
xrdp-keygen xrdp < outfile | auto >

xrdp-keygen test

## DESCRIPTION
xrdp-keygen generates the file /etc/xrdp/rsakeys.ini which contains the RSA key pair used to perform authentication to remote clients. The public key is self-signed.

## OPTIONS
This program takes one of the following options:

xrdp outfile

Generate a new key pair. The key data is stored in the file named outfile.

If auto is used as outfile, the default file /etc/xrdp/rsakeys.ini gets created if it does not yet exists.

test

Generate a test key pair and print information to standard output.

## FILES
/etc/xrdp/rsakeys.ini

RSA public and private key pair used to identify this XRDP server.

## SEE ALSO
xrdp(8), xrdp-sesman(8).

## AUTHOR
This manual page was originally written by Vincent Bernat <bernat@luffy.cx>.


title: xrdp-mkfv1(8)

text:
# xrdp-mkfv1(8)

## NAME
xrdp-mkfv1 - Create .fv1 font files from other font files

## SYNOPSIS
xrdp-mkfv1 [ options ] font_file fv1_file

## DESCRIPTION
xrdp-mkfv1 can be used to convert a font file such as a TrueType font to a fv1 file.

## OPTIONS
A summary of options is included below.

-n <font_name>

Give the font a name, which is stored in the font header. The default is to use the font family name from the source font.

-p <number>

Set the point size of the font. A fixed DPI value of 96 is used for converting this value into a pixel size. The default value for this option is '10'.

-m <glyph>

Set the limit on the glyphs stored in the font file. The argument is the last glyph stored in the font file. Specify the glyph using one of the following strings:

U+<hex> - Unicode character, e.g. U+25 for a percentage symbol (%).

@<char> - Unicode character, e.g. @% for a percentage symbol.

number - Unicode value as an integer, e.g. 37 for a percentage symbol

The default value for this option is 'U+4DFF'.

-C

When used with the "DejaVu Sans" font at a point-size of 10, a small number of glyphs are assigned a different x-offset than they have when the original Windows font generation program is used. This switch can be used to preserve the original x-offsets for glyphs in the range U+0020 - U+00FF when a 10 point DajaVu Sans font is generated.

Use one of the following arguments to this option:-

auto - Automatic mode. Offsets are preserved if a "DajaVu Sans" 10-point font is converted.

on / true / yes - Preserve offsets if automatic font detection does not work.

off / false / no - Do not tamper with the offsets generated by the program.

The default value of this switch is auto.

To see the effects of this switch, set the MKFV1_LOG_LEVEL environment variable to info before running the program.

## EXAMPLES
xrdp-mkfv1 -p18 /path/to/DejaVuSans.ttf ./sans-18.fv1

Generate an 18-point Deja Sans font.

xrdp-mkfv1 -C off -p10 /path/to/DejaVuSans.ttf ./sans-10.fv1

Generate a 10-point DajaVu Sans font using natural offsets.

## SEE ALSO
xrdp-dumpfv1(8).

More info on xrdp can be found on the xrdp homepage


xrdp-sesadmin

title: xrdp-sesadmin(8)

text:
# xrdp-sesadmin(8)

## NAME
xrdp-sesadmin - console XRDP sessions administration tool

## SYNOPSIS
xrdp-sesadmin [options] -c=command

## DESCRIPTION
This manual page documents briefly the xrdp-sesadmin command.

xrdp-sesadmin is a console program to administer running XRDP sessions.

## OPTIONS
A summary of options is included below.

-u=username

Retained for compatibility, but ignored.

-p=password

Retained for compatibility, but ignored.

-i=port

The sesman UNIX domain socket to connect to. Defaults to sesman.socket. If no path is specified for the socket, a default of /var/run/xrdp is used.

-c=command

Specifies the command to execute on the server. Valid commands are:

list

List active sessions for the current user.

kill:sid

Kills the session specified the given session id. (not yet implemented).

## FILES
xrdp-sesadmin.log

## SEE ALSO
xrdp(8).

More info on xrdp can be found on the xrdp homepage


xrdp-sesman

title: xrdp-sesman(8)

summary: xrdp(8) session manager

text:
# xrdp-sesman(8)

## NAME
xrdp-sesman - xrdp(8) session manager

## SYNTAX
xrdp-sesman --kill

xrdp-sesman --reload

xrdp-sesman --help

xrdp-sesman --version

xrdp-sesman [--nodaemon] [--dump-config] [--config /path/to/sesman.ini]

## DESCRIPTION
xrdp-sesman is xrdp(8) session manager.

It manages user sessions by authenticating the user and starting the appropriate Xserver.

## OPTIONS
-k, --kill

Kills running xrdp-sesman daemon.

-r, --reload

Reloads running xrdp-sesman daemon.

-h, --help

Output help information and exit.

-v, --version

Output version information and exit.

-n, --nodaemon

Starts xrdp-sesman in foreground instead of starting it as a daemon.

--dump-config

Print the configuration on stdout before starting the daemon. The default is not to do this.

-c, --config

Specify a path to a different sesman.ini file. This option is intended to be used primarily for testing or for unusual configurations.

If you use this option, be aware that you will have to have a /etc/xrdp/sesman.ini in place too, as a few elements of the system (notably xrdp(8) and xrdp-chansrv(8)) will want to read it.

## SIGNALS
SIGHUP

Causes xrdp-sesman to reload its configuration. Needed if you're not running xrdp-sesman as a daemon.

## FILES
/usr/sbin/xrdp-sesman

/usr/bin/xrdp-sesrun

/etc/sysconfsubdir@/sesman.ini

/var/log/xrdp-sesman.log

/var/run/xrdp-sesman.pid

/var/run/xrdp/sesman.socket

## AUTHORS
Jay Sorg <jsorg71@users.sourceforge.net>

Simone Fedele <ilsimo@users.sourceforge.net>

## SEE ALSO
sesman.ini(5), xrdp-sesrun(8), xrdp(8), xrdp.ini(5)

for more info on xrdp see http://www.xrdp.org/


xrdp-sesrun

title: xrdp-sesrun(8)

summary: xrdp\-sesman(8) session launcher

text:
# xrdp-sesrun(8)

## NAME
xrdp-sesrun - xrdp-sesman(8) session launcher

## SYNTAX
xrdp-sesrun --help

xrdp-sesrun [ options ] [ username ]

## DESCRIPTION
xrdp-sesrun starts a session using xrdp-sesman(8).

This is a tool useful for testing. It simply behaves like xrdp when some user logs in a new session and authenticates, thus starting a new session.

Default values for the options are set at compile-time. Run the utility with the '--help' option to see what the defaults are for your installation.

If no username is used, the current username is used, and no password needs to be provided. In this instance, it is important that any necessary authentication tokens for a GUI session (e.g. a Kerberos ticket) have already been acquired.

If a username is provided, a password must also be provided. In this instance the utility prompts for a password if neither -p or -F is used.

## OPTIONS
-g <width>x<height>

Set session geometry.

Note that most configurations will resize the session on connection, so this option may not do what you expect.

-b <bits-per-pixel>

Set session bits-per-pixel (colour depth). Some session types (i.e. Xorg) will ignore this setting.

-t <session-type>

Session type - one of Xorg or Xvnc. Alternatively, for testing only, use the numeric session code.

-D <directory>

Directory to run the new session in. Defaults to $HOME for the specified user.

-S <shell>

Specify an alternate shell to run, instead of the default window manager.

-p <password>

Password for user. USE FOR TESTING ONLY - the password will be visible in the output of the ps command.

-F <file-descriptor>

Specify a file descriptor (normally 0) to read the password in from. This is a secure way to pass the password in to the utility.

-c <sesman-ini>

Specify a different sesman.ini file. This file is used to find out how to connect to xrdp-sesman.

## ENVIRONMENT
SESRUN_LOG_LEVEL

Override the default logging level. One of "error", "warn", "info", "debug", "trace" or a number 1-5.

## EXAMPLES
xrdp-sesrun

Create a default session for the current user.

xrdp-sesrun -F 0 user1 <passwd.txt

Create a default session for user user1 with a password from a file

xrdp-sesrun -t Xvnc -S /usr/bin/xterm user1

Create an extremely minimal Xvnc session for user user1. This could be useful for debugging why the standard session is not starting properly. Note you would need to install the xterm utility first. The gnome-terminal utility probably won't work here.

## FILES
/usr/sbin/xrdp-sesman

/usr/bin/xrdp-sesrun

/etc/xrdp/sesman.ini

## AUTHORS
Jay Sorg <jsorg71@users.sourceforge.net>

Simone Fedele <ilsimo@users.sourceforge.net>

## SEE ALSO
xrdp-sesman(8), sesman.ini(5), xrdp(8), xrdp.ini(5)

For more info on xrdp see http://www.xrdp.org/


XrdCnsd

package: xrootd

title: XrdCnsd(8)

text:
# XrdCnsd(8)

## NAME
XrdCnsd - Cluster Name Space daemon

## SYNOPSIS

```
XrdCnsd [options]
```

## DESCRIPTION
The XrdCnsd daemon creates and maintains a file inventory for a data server. This is known as a server-side inventory (ssi) service. The daemon can also be run as a one-time command to repair inventory problems. Complete HTML documentation can be found at

http://xrootd.org/doc/prod/cms_config.htm

## NOTES
The cns_ssi utility is used to display a server's inventory of files. Documentation for all components associated with XrdCnsd can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status. The daemon is normally started as piped command via an xrootd daemon configuration directive.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The XrdCnsd daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


cmsd

title: cmsd(8)

text:
# cmsd(8)

## NAME
cmsd - Cluster Management Services daemon

## SYNOPSIS

```
cmsd [options] -c configfile
```

## DESCRIPTION
The cmsd daemon provides cluster services to xrootd data servers. Usage synopsis can be displayed by typing "cmsd -h". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/cms_config.htm

## NOTES
Documentation for all components associated with cmsd can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status. The program never exits upon success. Use the kill command or "/etc/init.d/cmsd stop" to terminate the program.

## LICENSE
License terms can be displayed by typing "cmsd -H".

## SUPPORT LEVEL
The cmsd daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


title: cns_ssi(8)

text:
# cns_ssi(8)

## NAME
cns_ssi - administer a server side inventory

## SYNOPSIS

```
cns_ssi command [options] dirpath
```

## DESCRIPTION
The cns_ssi utility displays and maintains server side inventory files created by the XrdCnsd daemon. Complete HTML documentation can be found at

http://xrootd.org/doc/prod/cms_config.htm

## NOTES
Documentation for all components associated with cns_ssi can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Errors yield an error message and a non-zero exit status.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The cns_ssi command is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


title: frm_admin(8)

text:
# frm_admin(8)

## NAME
frm_admin - administer file residency parameters

## SYNOPSIS

```
frm_admin [options] [command [cmdopts]]
```

## DESCRIPTION
The frm_admin utility displays and alters data server space attributes associated with file residency. These attributes are used by the frm_purged, frm_xfrd, and xrootd daemons to manage file residency. Usage synopsis can be displayed by typing "frm_admin -h". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/frm_config.htm

## NOTES
Documentation for all components associated with frm_admin can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The frm_admin command is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


title: frm_purged(8)

text:
# frm_purged(8)

## NAME
frm_purged - File Residency Manager purge daemon

## SYNOPSIS

```
frm_purged [options] [parameters]
```

## DESCRIPTION
The frm_purged daemon automatically removes disk resident files based on a set of local rules. It is part of the File Residency Manager software suite. Usage synopsis can be displayed by typing "frm_purged -h". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/frm_config.htm

## NOTES
Documentation for all components associated with frm_purged can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status. The program never exits upon success. Use the kill command or "/etc/init.d/frm_purged stop" to terminate the program.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The frm_purged daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


title: frm_xfragent(8)

text:
# frm_xfragent(8)

## NAME
frm_xfragent - File Residency Manager Transfer agent

## SYNOPSIS

```
frm_xfragent [options]
```

## DESCRIPTION
The frm_xfragent utility sends file transfer requests to the frm_xfrd daemon. It is part of the File Residency Manager software suite. Usage synopsis can be displayed by typing "frm_xfragent -h". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/frm_config.htm

## NOTES
Documentation for all components associated with frm_xfragent can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The frm_xfragent daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


title: frm_xfrd(8)

text:
# frm_xfrd(8)

## NAME
frm_xfrd - File Residency Manager transfer daemon

## SYNOPSIS

```
frm_xfrd [options]
```

## DESCRIPTION
The frm_xfrd daemon automatically copies files in and out of the data server. It is part of the File Residency Manager software suite. Usage synopsis can be displayed by typing "frm_xfrd -h". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/frm_config.htm

## NOTES
Documentation for all components associated with frm_xfrd can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status. The program never exits upon success. Use the kill command or "/etc/init.d/frm_xfrd stop" to terminate the program.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The frm_xfrd daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


mpxstats

title: mpxstats(8)

text:
# mpxstats(8)

## NAME
mpxstats - Multiplexing Monitor Statistics daemon

## SYNOPSIS

```
mpxstats [options] -p port
```

## DESCRIPTION
The mpxstats daemon multiplexes xrootd and cmsd monitoring data streams into a single sequential format suitable for ingestion by a monitoring agent (e.g. ganglia, MonaLisa, nagios, etc.). Usage synopsis can be displayed by typing "mpxstats". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/xrd_monitoring.htm

## NOTES
Documentation for all components associated with mpxstats can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Errors yield an error message and a non-zero exit status. The program never exits upon success. Use the kill command to terminate the program.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The mpxstats daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


title: xrdpfc_print(8)

text:
# xrdpfc_print(8)

## NAME
xrdpfc_print - print content of ProxyFileCache meta data

## SYNOPSIS

```
xrdpfc_print [options] path ...
options: [--config args] [--verbose] [--help]
```

## DESCRIPTION
The xrdpfc_print prints status of downloaded file blocks and access statistics of cached files

## OPTIONS
-c | --config

xrootd configuration file. Used to load non-default file system (directive ofs.osslib) and prefix for the location of cached files (directive oss.localroot)

-v | --verbose prints additional info for each downloaded file block

-h | --help displays usage information.

## OPERANDS
path

Path to a file or directory for which the information is to be printed. Path can be relative or absoulte. If the path begins with root:/ the path is assumed to be a LFN and gets translated via the standard OSS rules (in the least, it gets prefixed by the oss.localroot). In this case --config option is mandatory.

## NOTES
Documentation for all components associated with xrdpfc_print can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Errors yield an error message and a non-zero exit status.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The xrdpfc_print command is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


xrdpwdadmin

title: xrdpwdadmin(8)

text:
# xrdpwdadmin(8)

## NAME
xrdpwdadmin - administer pwd security protocol passwords

## SYNOPSIS

```
xrdpwdadmin [-m mode] command [options]
```

## DESCRIPTION
The xrdpwdadmin utility displays and maintains password and auto-login files used by the password (pwd) security protocol. Complete HTML documentation can be found at

http://xrootd.org/doc/prod/sec_config.htm

## NOTES
Documentation for all components associated with xrdpwdadmin can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Errors yield an error message and a non-zero exit status.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The xrdpwdadmin command is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


xrdsssadmin

title: xrdsssadmin(8)

text:
# xrdsssadmin(8)

## NAME
xrdsssadmin - administer simple shared secret keytables

## SYNOPSIS

```
xrdsssadmin [options] command [file]
```

## DESCRIPTION
The xrdsssadmin utility displays and maintains keytables for the simple shared secret (sss) security protocol. Complete HTML documentation can be found at

http://xrootd.org/doc/prod/sec_config.htm

## NOTES
Documentation for all components associated with xrdsssadmin can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Errors yield an error message and a non-zero exit status.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The xrdsssadmin command is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


xrootd

title: xrootd(8)

text:
# xrootd(8)

## NAME
xrootd - eXtended ROOT daemon

## SYNOPSIS

```
xrootd [options] [exports]
```

## DESCRIPTION
The xrootd daemon provides LAN/WAN access to data in stand-alone nodes, clustered nodes, as well as globally federated clusters. Usage synopsis can be displayed by typing "xrootd -h". Complete HTML documentation can be found at

http://xrootd.org/doc/prod/xrd_config.htm

## NOTES
Documentation for all components associated with xrootd can be found at http://xrootd.org/docs.html

## DIAGNOSTICS
Configuration errors yield an error message and a non-zero exit status. The program never exits upon success. Use the kill command or "/etc/init.d/xrootd stop" to terminate the program.

## LICENSE
License terms can be displayed by typing "xrootd -H".

## SUPPORT LEVEL
The xrootd daemon is supported by the xrootd collaboration. Contact information can be found at

http://xrootd.org/contact.html


iptaccount

package: xtables-addons

title: iptaccount(8)

text:
# iptaccount(8)

## Name
iptaccount — administrative utility to access xt_ACCOUNT statistics

## Syntax
iptaccount [-acfhu] [-l name]

## Options
-a List all (accounting) table names.

-c Loop every second (abort with CTRL+C).

-f Flush data after display.

-h Free all kernel handles. (Experts only!)

-l name Show data in accounting table called by name.

-u

Show kernel handle usage.

## See also
xtables-addons(8)


pknlusr

title: pknlusr(8)

text:
# pknlusr(8)

## NAME
pknlusr — userspace monitor for successful xt_pknock matches

## Synopsis
pknlusr [group-id]

## Description
xt_pknock is an xtables match extension that implements so-called port knocking. It can be configured to send information about each successful match via a netlink socket to userspace. pknluser listens for these notifications.

By default, pknlusr listens for messages sent to netlink multicast group 1. Another group ID may be passed as a command-line argument.

## See also
xtables-addons(8)


xtables-addons

title: xtables-addons(8)

text:
# xtables-addons(8)

## Name
Xtables-addons — additional extensions for iptables, ip6tables, etc.

## Targets

### ACCOUNT
The ACCOUNT target is a high performance accounting system for large local networks. It allows per-IP accounting in whole prefixes of IPv4 addresses with size of up to /8 without the need to add individual accounting rule for each IP address.

The ACCOUNT is designed to be queried for data every second or at least every ten seconds. It is written as kernel module to handle high bandwidths without packet loss.

The largest possible subnet size is 24 bit, meaning for example 10.0.0.0/8 network. ACCOUNT uses fixed internal data structures which speeds up the processing of each packet. Furthermore, accounting data for one complete 192.168.1.X/24 network takes 4 KB of memory. Memory for 16 or 24 bit networks is only allocated when needed.

To optimize the kernel<->userspace data transfer a bit more, the kernel module only transfers information about IPs, where the src/dst packet counter is not 0. This saves precious kernel time.

There is no /proc interface as it would be too slow for continuous access. The read-and-flush query operation is the fastest, as no internal data snapshot needs to be created&copied for all data. Use the "read" operation without flush only for debugging purposes!

Usage:

ACCOUNT takes two mandatory parameters:

--addr network/netmask

where network/netmask is the subnet to account for, in CIDR syntax

--tname NAME

where NAME is the name of the table where the accounting information should be stored

The subnet 0.0.0.0/0 is a special case: all data are then stored in the src_bytes and src_packets structure of slot "0". This is useful if you want to account the overall traffic to/from your internet provider.

The data can be queried using the userspace libxt_ACCOUNT_cl library, and by the reference implementation to show usage of this library, the iptaccount(8) tool.

Here is an example of use:

iptables -A FORWARD -j ACCOUNT --addr 0.0.0.0/0 --tname all_outgoing; iptables -A FORWARD -j ACCOUNT --addr 192.168.1.0/24 --tname sales;

This creates two tables called "all_outgoing" and "sales" which can be queried using the userspace library/iptaccount tool.

Note that this target is non-terminating — the packet destined to it will continue traversing the chain in which it has been used.

Also note that once a table has been defined for specific CIDR address/netmask block, it can be referenced multiple times using -j ACCOUNT, provided that both the original table name and address/netmask block are specified.

For more information go to http://www.intra2net.com/en/developer/ipt_ACCOUNT/

### CHAOS
Causes confusion on the other end by doing odd things with incoming packets. CHAOS will randomly reply (or not) with one of its configurable subtargets:

--delude

Use the REJECT and DELUDE targets as a base to do a sudden or deferred connection reset, fooling some network scanners to return non-deterministic (randomly open/closed) results, and in case it is deemed open, it is actually closed/filtered.

--tarpit

Use the REJECT and TARPIT target as a base to hold the connection until it times out. This consumes conntrack entries when connection tracking is loaded (which usually is on most machines), and routers inbetween you and the Internet may fail to do their connection tracking if they have to handle more connections than they can.

The randomness factor of not replying vs. replying can be set during load-time of the xt_CHAOS module or during runtime in /sys/modules/xt_CHAOS/parameters.

See http://inai.de/projects/chaostables/ for more information about CHAOS, DELUDE and lscan.

### DELUDE
The DELUDE target will reply to a SYN packet with SYN-ACK, and to all other packets with an RST. This will terminate the connection much like REJECT, but network scanners doing TCP half-open discovery can be spoofed to make them believe the port is open rather than closed/filtered.

### DHCPMAC
In conjunction with ebtables, DHCPMAC can be used to completely change all MAC addresses from and to a VMware-based virtual machine. This is needed because VMware does not allow one to set a non-VMware MAC address before an operating system is booted (and the MAC be changed with `ip link set eth0 address aa:bb..`).

--set-mac aa:bb:cc:dd:ee:ff[/mask]

Replace the client host MAC address field in the DHCP message with the given MAC address. This option is mandatory. The mask parameter specifies the prefix length of bits to change.

EXAMPLE, replacing all addresses from one of VMware's assigned vendor IDs (00:50:56) addresses with something else:

iptables -t mangle -A FORWARD -p udp --dport 67 -m physdev --physdev-in vmnet1 -m dhcpmac --mac 00:50:56:00:00:00/24 -j DHCPMAC --set-mac ab:cd:ef:00:00:00/24

iptables -t mangle -A FORWARD -p udp --dport 68 -m physdev --physdev-out vmnet1 -m dhcpmac --mac ab:cd:ef:00:00:00/24 -j DHCPMAC --set-mac 00:50:56:00:00:00/24

(This assumes there is a bridge interface that has vmnet1 as a port. You will also need to add appropriate ebtables rules to change the MAC address of the Ethernet headers.)

### DNETMAP
The DNETMAP target allows dynamic two-way 1:1 mapping of IPv4 subnets. A single rule can map a private subnet to a shorter public subnet, creating and maintaining unambiguous private-public IP address bindings. The second rule can be used to map new flows to a private subnet according to maintained bindings. The target allows efficient public IPv4 space usage and unambiguous NAT at the same time.

The target can be used only in the nat table in POSTROUTING or OUTPUT chains for SNAT, and in PREROUTING for DNAT. Only flows directed to bound addresses will be DNATed. The packet continues chain traversal if there is no free postnat address to be assigned to the prenat address. The default binding TTL is 10 minutes and can be changed using the default_ttl module option. The default address hash size is 256 and can be changed using the hash_size module option.

--prefix addr/mask

The network subnet to map to. If not specified, all existing prefixes are used.

--reuse

Reuse the entry for a given prenat address from any prefix even if the binding's TTL is < 0.

--persistent

Set the prefix to be persistent. It will not be removed after deleting the last iptables rule. The option is effective only in the first rule for a given prefix. If you need to change persistency for an existing prefix, please use the procfs interface described below.

--static

Do not create dynamic mappings using this rule. Use static mappings only. Note that you need to create static mappings via the procfs interface for this rule for this option to have any effect.

--ttl seconds

Reset the binding's TTL value to seconds. If a negative value is specified, the binding's TTL is kept unchanged. If this option is not specified, then the default TTL value (600s) is used.

* /proc interface

The module creates the following entries for each new specified subnet:

/proc/net/xt_DNETMAP/subnet_mask

Contains the binding table for the given subnet/mask. Each line contains prenat address, postnat address, ttl (seconds until the entry times out), lasthit (last hit to the entry in seconds relative to system boot time). Please note that the ttl and lasthit entries contain an ‘S’ in case of a static binding.

/proc/net/xt_DNETMAP/subnet_mask_stat

Contains statistics for a given subnet/mask. The line contains four numerical values separated by spaces. The first one is the number of currently used dynamic addresses (bindings with negative TTL excluded), the second one is the number of static assignments, the third one is the number of all usable addresses in the subnet, and the fourth one is the mean TTL value for all active entries. If the prefix has the persistent flag set, it will be noted as fifth entry.

The following write operations are supported via the procfs interface:

echo "+prenat-address:postnat-address" >/proc/net/xt_DNETMAP/subnet_mask

Adds a static binding between the prenat and postnap address. If postnat_address is already bound, any previous binding will be timed out immediately. A static binding is never timed out.

echo "-address" >/proc/net/xt_DNETMAP/subnet_mask

Removes the binding with address as prenat or postnat address. If the removed binding is currently static, it will make the entry available for dynamic allocation.

echo "+persistent" >/proc/net/xt_DNETMAP/subnet_mask

Sets the persistent flag for the prefix. It is useful if you do not want bindings to get flushed when the firewall is restarted. You can check if the prefix is persistent by printing the contents of /proc/net/xt_DNETMAP/subnet_mask_stat.

echo "-persistent" >/proc/net/xt_DNETMAP/subnet_mask

Unsets the persistent flag for the prefix. In this mode, the prefix will be deleted if the last iptables rule for that prefix is removed.

echo "flush" >/proc/net/xt_DNETMAP/subnet_mask

Flushes all bindings for the specific prefix. All static entries are also flushed and become available for dynamic bindings.

Note! Entries are removed if the last iptables rule for a specific prefix is deleted unless the persistent flag is set.

* Logging

The module logs binding add/timeout events to klog. This behaviour can be disabled using the disable_log module parameter.

* Examples

1. Map subnet 192.168.0.0/24 to subnets 20.0.0.0/26. SNAT only:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26

Active hosts from the 192.168.0.0/24 subnet are mapped to 20.0.0.0/26. If the packet from a not yet bound prenat address hits the rule and there are no free or timed-out (TTL<0) entries in prefix 20.0.0.0/28, then a notice is logged to klog and chain traversal continues. If packet from an already-bound prenat address hits the rule, the binding's TTL value is reset to default_ttl and SNAT is performed.

2. Use of --reuse and --ttl switches, multiple rule interaction:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26 --reuse --ttl 200

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 30.0.0.0/26

Active hosts from 192.168.0.0/24 subnet are mapped to 20.0.0.0/26 with TTL = 200 seconds. If there are no free addresses in first prefix, the next one (30.0.0.0/26) is used with the default TTL. It is important to note that the first rule SNATs all flows whose source address is already actively bound (TTL>0) to ANY prefix. The --reuse parameter makes this functionality work even for inactive (TTL<0) entries.

If both subnets are exhausted, then chain traversal continues.

3. Map 192.168.0.0/24 to subnets 20.0.0.0/26 in a bidirectional way:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26

iptables -t nat -A PREROUTING -j DNETMAP

If the host 192.168.0.10 generates some traffic, it gets bound to first free address in the subnet — 20.0.0.0. Now, any traffic directed to 20.0.0.0 gets DNATed to 192.168.0.10 as long as there is an active (TTL>0) binding. There is no need to specify --prefix parameter in a PREROUTING rule, because this way, it DNATs traffic to all active prefixes. You could specify the prefix you would like to make DNAT work for a specific prefix only.

4. Map 192.168.0.0/24 to subnets 20.0.0.0/26 with static assignments only:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26 --static

echo "+192.168.0.10:20.0.0.1" >/proc/net/xt_DNETMAP/20.0.0.0_26

echo "+192.168.0.11:20.0.0.2" >/proc/net/xt_DNETMAP/20.0.0.0_26

echo "+192.168.0.51:20.0.0.3" >/proc/net/xt_DNETMAP/20.0.0.0_26

This configuration will allow only preconfigured static bindings to work due to the static rule option. Without this flag, dynamic bindings would be created using non-static entries.

5. Persistent prefix:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26 --persistent

or

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26

echo "+persistent" >/proc/net/xt_DNETMAP/20.0.0.0_26

Now, we can check the persistent flag of the prefix:

cat /proc/net/xt_DNETMAP/20.0.0.0_26

0 0 64 0 persistent

Flush the iptables nat table and see that prefix is still in existence:

iptables -F -t nat

ls -l /proc/net/xt_DNETMAP

-rw-r--r-- 1 root root 0 06-10 09:01 20.0.0.0_26

-rw-r--r-- 1 root root 0 06-10 09:01 20.0.0.0_26_stat

### ECHO
The ECHO target will send back all packets it received. It serves as an examples for an Xtables target.

ECHO takes no options.

### IPMARK
Allows you to mark a received packet basing on its IP address. This can replace many mangle/mark entries with only one, if you use firewall based classifier.

This target is to be used inside the mangle table.

--addr {src|dst}

Select source or destination IP address as a basis for the mark.

--and-mask mask

Perform bitwise AND on the IP address and this bitmask.

--or-mask mask

Perform bitwise OR on the IP address and this bitmask.

--shift value

Shift addresses to the right by the given number of bits before taking it as a mark. (This is done before ANDing or ORing it.) This option is needed to select part of an IPv6 address, because marks are only 32 bits in size.

The order of IP address bytes is reversed to meet "human order of bytes": 192.168.0.1 is 0xc0a80001. At first the "AND" operation is performed, then "OR".

Examples:

We create a queue for each user, the queue number is adequate to the IP address of the user, e.g.: all packets going to/from 192.168.5.2 are directed to 1:0502 queue, 192.168.5.12 -> 1:050c etc.

We have one classifier rule:

tc filter add dev eth3 parent 1:0 protocol ip fw

Earlier we had many rules just like below:

iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.2 -j MARK --set-mark 0x10502

iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.3 -j MARK --set-mark 0x10503

Using IPMARK target we can replace all the mangle/mark rules with only one:

iptables -t mangle -A POSTROUTING -o eth3 -j IPMARK --addr dst --and-mask 0xffff --or-mask 0x10000

On the routers with hundreds of users there should be significant load decrease (e.g. twice).

(IPv6 example) If the source address is of the form 2001:db8:45:1d:20d:93ff:fe9b:e443 and the resulting mark should be 0x93ff, then a right-shift of 16 is needed first:

-t mangle -A PREROUTING -s 2001:db8::/32 -j IPMARK --addr src --shift 16 --and-mask 0xFFFF

### LOGMARK
The LOGMARK target will log packet and connection marks to syslog.

--log-level level

A logging level between 0 and 8 (inclusive).

--log-prefix string

Prefix log messages with the specified prefix; up to 29 bytes long, and useful for distinguishing messages in the logs.

### PROTO
The PROTO target modifies the protocol number in IP packet header.

--proto-set proto_num

This option is mandatory. proto_num is the protocol number to which you want to modify the packets.

--stop-at-frag

This option is only valid for IPv6 rules. When specifying this option, the fragment extension header will be seen as a non-extension header.

--stop-at-auth

This option is only valid for IPv6 rules. When specifying this option, the authentication extension header will be seen as a non-extension header.

For IPv4 packets, the Protocol field is modified and the checksum is re-calculated.

For IPv6 packets, the scenario can be more complex due to the introduction of the extension headers mechanism. By default, the PROTO target will scan the IPv6 packet, finding the last extension header and modify its Next-header field. Normally, the following headers will be seen as an extension header: NEXTHDR_HOP, NEXTHDR_ROUTING, NEXTHDR_FRAGMENT, NEXTHDR_AUTH, NEXTHDR_DEST.

For fragmented packets, only the first fragment is processed and other fragments are not touched.

### SYSRQ
The SYSRQ target allows one to remotely trigger sysrq on the local machine over the network. This can be useful when vital parts of the machine hang, for example an oops in a filesystem causing locks to be not released and processes to get stuck as a result — if still possible, use /proc/sysrq-trigger. Even when processes are stuck, interrupts are likely to be still processed, and as such, sysrq can be triggered through incoming network packets.

The xt_SYSRQ implementation uses a salted hash and a sequence number to prevent network sniffers from either guessing the password or replaying earlier requests. The initial sequence number comes from the time of day so you will have a small window of vulnerability should time go backwards at a reboot. However, the file /sys/module/xt_SYSREQ/seqno can be used to both query and update the current sequence number. Also, you should limit as to who can issue commands using -s and/or -m mac, and also that the destination is correct using -d (to protect against potential broadcast packets), noting that it is still short of MAC/IP spoofing:

-A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d 10.10.25.7 -p udp --dport 9 -j SYSRQ

(with IPsec) -A INPUT -s 10.10.25.1 -d 10.10.25.7 -m policy --dir in --pol ipsec --proto esp --tunnel-src 10.10.25.1 --tunnel-dst 10.10.25.7 -p udp --dport 9 -j SYSRQ

You should also limit the rate at which connections can be received to limit the CPU time taken by illegal requests, for example:

-A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d 10.10.25.7 -p udp --dport 9 -m limit --limit 5/minute -j SYSRQ

This extension does not take any options. The -p udp options are required.

The SYSRQ password can be changed through /sys/module/xt_SYSRQ/parameters/password, for example:

echo -n "password" >/sys/module/xt_SYSRQ/parameters/password

The module will not respond to sysrq requests until a password has been set.

Alternatively, the password may be specified at modprobe time, but this is insecure as people can possible see it through ps(1). You can use an option line in e.g. /etc/modprobe.d/xt_sysrq if it is properly guarded, that is, only readable by root.

options xt_SYSRQ password=cookies

The hash algorithm can also be specified as a module option, for example, to use SHA-256 instead of the default SHA-1:

options xt_SYSRQ hash=sha256

The xt_SYSRQ module is normally silent unless a successful request is received, but the debug module parameter can be used to find exactly why a seemingly correct request is not being processed.

To trigger SYSRQ from a remote host, just use socat:

```
sysrq_key="s"  # the SysRq key(s)
password="password"
seqno="$(date +%s)"
salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null |

    openssl enc -base64)"
ipaddr="2001:0db8:0000:0000:0000:ff00:0042:8329"
req="$sysrq_key,$seqno,$salt"
req="$req,$(echo -n "$req,$ipaddr,$password" | sha1sum | cut -c1-40)"
echo "$req" | socat stdin udp-sendto:$ipaddr:9
```

See the Linux docs for possible sysrq keys. Important ones are: re(b)oot, power(o)ff, (s)ync filesystems, (u)mount and remount readonly. More than one sysrq key can be used at once, but bear in mind that, for example, a sync may not complete before a subsequent reboot or poweroff.

An IPv4 address should have no leading zeros, an IPv6 address should be in the full expanded form (as shown above). The debug option will cause output to be emitted in the same form.

The hashing scheme should be enough to prevent mis-use of SYSRQ in many environments, but it is not perfect: take reasonable precautions to protect your machines.

### TARPIT
Captures and holds incoming TCP connections using no local per-connection resources.

TARPIT only works at the TCP level, and is totally application agnostic. This module will answer a TCP request and play along like a listening server, but aside from sending an ACK or RST, no data is sent. Incoming packets are ignored and dropped. The attacker will terminate the session eventually. This module allows the initial packets of an attack to be captured by other software for inspection. In most cases this is sufficient to determine the nature of the attack.

This offers similar functionality to LaBrea <http://www.hackbusters.net/LaBrea/> but does not require dedicated hardware or IPs. Any TCP port that you would normally DROP or REJECT can instead become a tarpit.

--tarpit

This mode completes a connection with the attacker but limits the window size to 0, thus keeping the attacker waiting long periods of time. While he is maintaining state of the connection and trying to continue every 60-240 seconds, we keep none, so it is very lightweight. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes. This mode is the default.

--honeypot

This mode completes a connection with the attacker, but signals a normal window size, so that the remote side will attempt to send data, often with some very nasty exploit attempts. We can capture these packets for decoding and further analysis. The module does not send any data, so if the remote expects an application level response, the game is up.

--reset

This mode is handy because we can send an inline RST (reset). It has no other function.

To tarpit connections to TCP port 80 destined for the current machine:

-A INPUT -p tcp -m tcp --dport 80 -j TARPIT

To significantly slow down Code Red/Nimda-style scans of unused address space, forward unused ip addresses to a Linux box not acting as a router (e.g. "ip route 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP forwarding on the Linux box, and add:

-A FORWARD -p tcp -j TARPIT

-A FORWARD -j DROP

NOTE: If you use the conntrack module while you are using TARPIT, you should also use unset tracking on the packet, or the kernel will unnecessarily allocate resources for each TARPITted connection. To TARPIT incoming connections to the standard IRC port while using conntrack, you could:

-t raw -A PREROUTING -p tcp --dport 6667 -j CT --notrack

-A INPUT -p tcp --dport 6667 -j NFLOG

-A INPUT -p tcp --dport 6667 -j TARPIT

## Matches

### asn
Match a packet by its source or destination autonomous system number (ASN).

[!] --src-asn, --source-number number[,number...]

Match packet coming from (one of) the specified ASN(s)

[!] --dst-asn, --destination-number country[,country...]

Match packet going to (one of) the specified ASN(s)

The extra files you will need are the binary database files. They are generated from a ASN-subnet database with the asn_build_db.pl tool that is shipped with the source package, and which should be available in compiled packages in /usr/lib(exec)/xtables-addons/. The first command retrieves CSV files from MaxMind, while the other two build packed bisectable range files:

mkdir -p /usr/share/xt_asn; cd /tmp; $path/to/xt_asn_dl;

$path/to/xt_asn_build -D /usr/share/xt_asn

The shared library is hardcoded to look in these paths, so use them.

### condition
This matches if a specific condition variable is (un)set.

[!] --condition name

Match on boolean value stored in /proc/net/nf_condition/name.

### dhcpmac
--mac aa:bb:cc:dd:ee:ff[/mask]

Matches the DHCP "Client Host" address (a MAC address) in a DHCP message. mask specifies the prefix length of the initial portion to match.

### fuzzy
This module matches a rate limit based on a fuzzy logic controller (FLC).

--lower-limit number

Specifies the lower limit, in packets per second.

--upper-limit number

Specifies the upper limit, also in packets per second.

### geoip
Match a packet by its source or destination country.

[!] --src-cc, --source-country country[,country...]

Match packet coming from (one of) the specified country(ies)

[!] --dst-cc, --destination-country country[,country...]

Match packet going to (one of) the specified country(ies)

NOTE:

The country is inputed by its ISO-3166 code.

The extra files you will need is the binary database files. They are generated from a country-subnet database with the geoip_build_db.pl tool that is shipped with the source package, and which should be available in compiled packages in /usr/lib(exec)/xtables-addons/. The first command retrieves CSV files from MaxMind, while the other two build packed bisectable range files:

mkdir -p /usr/share/xt_geoip; cd /tmp; $path/to/xt_geoip_dl;

$path/to/xt_geoip_build -D /usr/share/xt_geoip GeoIP*.csv;

The shared library is hardcoded to look in these paths, so use them.

### gradm
This module matches packets based on grsecurity RBAC status.

[!] --enabled

Matches packets if grsecurity RBAC is enabled.

[!] --disabled

Matches packets if grsecurity RBAC is disabled.

### iface
Allows you to check interface states. First, an interface needs to be selected for comparison. Exactly one option of the following three must be specified:

--iface name

Check the states on the given interface.

--dev-in

Check the states on the interface on which the packet came in. If the input device is not set, because for example you are using -m iface in the OUTPUT chain, this submatch returns false.

--dev-out

Check the states on the interface on which the packet will go out. If the output device is not set, because for example you are using -m iface in the INPUT chain, this submatch returns false.

Following that, one can select the interface properties to check for:

[!] --up, [!] --down

Check the UP flag.

[!] --broadcast

Check the BROADCAST flag.

[!] --loopback

Check the LOOPBACK flag.

[!] --pointtopoint

Check the POINTTOPOINT flag.

[!] --running

Check the RUNNING flag. Do NOT rely on it!

[!] --noarp, [!] --arp

Check the NOARP flag.

[!] --promisc

Check the PROMISC flag.

[!] --multicast

Check the MULTICAST flag.

[!] --dynamic

Check the DYNAMIC flag.

[!] --lower-up

Check the LOWER_UP flag.

[!] --dormant

Check the DORMANT flag.

### ipp2p
This module matches certain packets in P2P flows. It is not designed to match all packets belonging to a P2P connection — use IPP2P together with CONNMARK for this purpose.

Use it together with -p tcp or -p udp to search these protocols only or without -p switch to search packets of both protocols.

IPP2P provides the following options, of which one or more may be specified on the command line:

--edk

Matches as many eDonkey/eMule packets as possible.

--kazaa

Matches as many KaZaA packets as possible.

--gnu

Matches as many Gnutella packets as possible.

--dc

Matches as many Direct Connect packets as possible.

--bit

Matches BitTorrent packets.

--apple

Matches AppleJuice packets.

--soul

Matches some SoulSeek packets. Considered as beta, use careful!

--winmx

Matches some WinMX packets. Considered as beta, use careful!

--ares

Matches Ares and AresLite packets. Use together with -j DROP only.

--debug

Prints some information about each hit into kernel logfile. May produce huge logfiles so beware!

Note that ipp2p may not (and often, does not) identify all packets that are exchanged as a result of running filesharing programs.

There is more information on http://ipp2p.org/ , but it has not been updated since September 2006, and the syntax there is different from the ipp2p.c provided in Xtables-addons; most importantly, the --ipp2p flag was removed due to its ambiguity to match "all known" protocols.

### ipv4options
The "ipv4options" module allows one to match against a set of IPv4 header options.

--flags [!]symbol[,[!]symbol...]

Specify the options that shall appear or not appear in the header. Each symbol specification is delimited by a comma, and a '!' can be prefixed to a symbol to negate its presence. Symbols are either the name of an IPv4 option or its number. See examples below.

--any

By default, all of the flags specified must be present/absent, that is, they form an AND condition. Use the --any flag instead to use an OR condition where only at least one symbol spec must be true.

Known symbol names (and their number):

1 — nop

2 — security — RFC 1108

3 — lsrr — Loose Source Routing, RFC 791

4 — timestamp — RFC 781, 791

7 — record-route — RFC 791

9 — ssrr — Strict Source Routing, RFC 791

11 — mtu-probe — RFC 1063

12 — mtu-reply — RFC 1063

18 — traceroute — RFC 1393

20 — router-alert — RFC 2113

Examples:

Match packets that have both Timestamp and NOP: -m ipv4options --flags nop,timestamp

~ that have either of Timestamp or NOP, or both: --flags nop,timestamp --any

~ that have Timestamp and no NOP: --flags '!nop,timestamp'

~ that have either no NOP or a timestamp (or both conditions): --flags '!nop,timestamp' --any

### length2
This module matches the length of a packet against a specific value or range of values.

[!] --length length[:length]

Match exact length or length range.

--layer3

Match the layer3 frame size (e.g. IPv4/v6 header plus payload).

--layer4

Match the layer4 frame size (e.g. TCP/UDP header plus payload).

--layer5

Match the layer5 frame size (e.g. TCP/UDP payload, often called layer7).

If no --layer* option is given, --layer3 is assumed by default. Note that using --layer5 may not match a packet if it is not one of the recognized types (currently TCP, UDP, UDPLite, ICMP, AH and ESP) or which has no 5th layer.

### lscan
Detects simple low-level scan attempts based upon the packet's contents. (This is different from other implementations, which also try to match the rate of new connections.) Note that an attempt is only discovered after it has been carried out, but this information can be used in conjunction with other rules to block the remote host's future connections. So this match module will match on the (probably) last packet the remote side will send to your machine.

--stealth

Match if the packet did not belong to any known TCP connection (Stealth/FIN/XMAS/NULL scan).

--synscan

Match if the connection was a TCP half-open discovery (SYN scan), i.e. the connection was torn down after the 2nd packet in the 3-way handshake.

--cnscan

Match if the connection was a TCP full open discovery (connect scan), i.e. the connection was torn down after completion of the 3-way handshake.

--grscan

Match if data in the connection only flew in the direction of the remote side, e.g. if the connection was terminated after a locally running daemon sent its identification. (E.g. openssh, smtp, ftpd.) This may falsely trigger on warranted single-direction data flows, usually bulk data transfers such as FTP DATA connections or IRC DCC. Grab Scan Detection should only be used on ports where a protocol runs that is guaranteed to do a bidirectional exchange of bytes.

--mirai

Match if the TCP ISN is equal to the IPv4 destination address; this is used by the devices in the Mirai botnet as a form of TCP SYN scan, so you will have to explicitly specify --syn for the rule.

NOTE: Some clients (Windows XP for example) may do what looks like a SYN scan, so be advised to carefully use xt_lscan in conjunction with blocking rules, as it may lock out your very own internal network.

### psd
Attempt to detect TCP and UDP port scans. This match was derived from Solar Designer's scanlogd.

--psd-weight-threshold threshold

Total weight of the latest TCP/UDP packets with different destination ports coming from the same host to be treated as port scan sequence.

--psd-delay-threshold delay

Delay (in hundredths of second) for the packets with different destination ports coming from the same host to be treated as possible port scan subsequence.

--psd-lo-ports-weight weight

Weight of the packet with privileged (<=1024) destination port.

--psd-hi-ports-weight weight

Weight of the packet with non-privileged destination port.

### quota2
The "quota2" implements a named counter which can be increased or decreased on a per-match basis. Available modes are packet counting or byte counting. The value of the counter can be read and reset through procfs, thereby making this match a minimalist accounting tool.

When counting down from the initial quota, the counter will stop at 0 and the match will return false, just like the original "quota" match. In growing (upcounting) mode, it will always return true.

--grow

Count upwards instead of downwards.

--no-change

Makes it so the counter or quota amount is never changed by packets matching this rule. This is only really useful in "quota" mode, as it will allow you to use complex prerouting rules in association with the quota system, without counting a packet twice.

--name name

Assign the counter a specific name. This option must be present, as an empty name is not allowed. Names starting with a dot or names containing a slash are prohibited.

[!] --quota iq

Specify the initial quota for this counter. If the counter already exists, it is not reset. An "!" may be used to invert the result of the match. The negation has no effect when --grow is used.

--packets

Count packets instead of bytes that passed the quota2 match.

Because counters in quota2 can be shared, you can combine them for various purposes, for example, a bytebucket filter that only lets as much traffic go out as has come in:

-A INPUT -p tcp --dport 6881 -m quota --name bt --grow; -A OUTPUT -p tcp --sport 6881 -m quota --name bt;

### pknock
Pknock match implements so-called "port knocking", a stealthy system for network authentication: a client sends packets to selected ports in a specific sequence (= simple mode, see example 1 below), or a HMAC payload to a single port (= complex mode, see example 2 below), to a target machine that has pknock rule(s) installed. The target machine then decides whether to unblock or block (again) the pknock-protected port(s). This can be used, for instance, to avoid brute force attacks on ssh or ftp services.

Example prerequisites:

modprobe cn

modprobe xt_pknock

Example 1 (TCP mode, manual closing of opened port not possible):

iptables -P INPUT DROP

iptables -A INPUT -p tcp -m pknock --knockports 4002,4001,4004 --strict --name SSH --time 10 --autoclose 60 --dport 22 -j ACCEPT

The rule will allow tcp port 22 for the attempting IP address after the successful reception of TCP SYN packets to ports 4002, 4001 and 4004, in this order (a.k.a. port-knocking). Port numbers in the connect sequence must follow the exact specification, no other ports may be "knocked" inbetween. The rule is named 'SSH' — a file of the same name for tracking port knocking states will be created in /proc/net/xt_pknock . Successive port knocks must occur with delay of at most 10 seconds. Port 22 (from the example) will be automatiaclly dropped after 60 minutes after it was previously allowed.

Example 2 (UDP mode — non-replayable and non-spoofable, manual closing of opened port possible, secure, also called "SPA" = Secure Port Authorization):

iptables -A INPUT -p udp -m pknock --knockports 4000 --name FTP --opensecret foo --closesecret bar --autoclose 240 -j DROP

iptables -A INPUT -p tcp -m pknock --checkip --name FTP --dport 21 -j ACCEPT

The first rule will create an "ALLOWED" record in /proc/net/xt_pknock/FTP after the successful reception of an UDP packet to port 4000. The packet payload must be constructed as a HMAC256 using "foo" as a key. The HMAC content is the particular client's IP address as a 32-bit network byteorder quantity, plus the number of minutes since the Unix epoch, also as a 32-bit value. (This is known as Simple Packet Authorization, also called "SPA".) In such case, any subsequent attempt to connect to port 21 from the client's IP address will cause such packets to be accepted in the second rule.

Similarly, upon reception of an UDP packet constructed the same way, but with the key "bar", the first rule will remove a previously installed "ALLOWED" state record from /proc/net/xt_pknock/FTP, which means that the second rule will stop matching for subsequent connection attempts to port 21. In case no close-secret packet is received within 4 hours, the first rule will remove "ALLOWED" record from /proc/net/xt_pknock/FTP itself.

Things worth noting:

General:

Specifying --autoclose 0 means that no automatic close will be performed at all.

xt_pknock is capable of sending information about successful matches via a netlink socket to userspace, should you need to implement your own way of receiving and handling portknock notifications.

TCP mode:

This mode is not immune against eavesdropping, spoofing and replaying of the port knock sequence by someone else (but its use may still be sufficient for scenarios where these factors are not necessarily this important, such as bare shielding of the SSH port from brute-force attacks). However, if you need these features, you should use UDP mode.

It is always wise to specify three or more ports that are not monotonically increasing or decreasing with a small stepsize (e.g. 1024,1025,1026) to avoid accidentally triggering the rule by a portscan.

Specifying the inter-knock timeout with --time is mandatory in TCP mode, to avoid permanent denial of services by clogging up the peer knock-state tracking table that xt_pknock internally keeps, should there be a DDoS on the first-in-row knock port from more hostile IP addresses than what the actual size of this table is (defaults to 16, can be changed via the "peer_hasht_ents" module parameter). It is also wise to use as short a time as possible (1 second) for --time for this very reason. You may also consider increasing the size of the peer knock-state tracking table. Using --strict also helps, as it requires the knock sequence to be exact. This means that if the hostile client sends more knocks to the same port, xt_pknock will mark such attempt as failed knock sequence and will forget it immediately. To completely thwart this kind of DDoS, knock-ports would need to have an additional rate-limit protection. Or you may consider using UDP mode.

UDP mode:

This mode is immune against eavesdropping, replaying and spoofing attacks. It is also immune against DDoS attack on the knockport.

For this mode to work, the clock difference on the client and on the server must be below 1 minute. Synchronizing time on both ends by means of NTP or rdate is strongly suggested.

There is a rate limiter built into xt_pknock which blocks any subsequent open attempt in UDP mode should the request arrive within less than one minute since the first successful open. This is intentional; it thwarts eventual spoofing attacks.

Because the payload value of an UDP knock packet is influenced by client's IP address, UDP mode cannot be used across NAT.

For sending UDP "SPA" packets, you may use either knock.sh or knock-orig.sh. These may be found in doc/pknock/util.

## See also
iptables(8), ip6tables(8), iptables-extensions(8), iptaccount(8)

For developers, the book "Writing Netfilter modules" at http://inai.de/documents/Netfilter_Modules.pdf provides detailed information on how to write such modules/extensions.


enadis.cgi

package: xymon-man

title: enadis.cgi(8)

text:
# enadis.cgi(8)

## NAME
enadis.cgi - CGI program to enable/disable Xymon tests

## SYNOPSIS
enadis.cgi (invoked via CGI from webserver)

## DESCRIPTION
enadis.cgi is a CGI tool for disabling and enabling hosts and tests monitored by Xymon. You can disable monitoring of a single test, all tests for a host, or multiple hosts - immediately or at a future point in time.

enadis.cgi runs as a CGI program, invoked by your webserver. It is normally run via a wrapper shell-script in the secured CGI directory for Xymon.

enadis.cgi is the back-end script for the enable/disable form present on the "info" status-pages. It can also run in "stand-alone" mode, in which case it displays a web form allowing users to select what to enable or disable.

## OPTIONS
--no-cookies

Normally, enadis.cgi uses a cookie sent by the browser to initially filter the list of hosts presented. If this is not desired, you can turn off this behaviour by calling acknowledge.cgi with the --no-cookies option. This would normally be placed in the CGI_ENADIS_OPTS setting in cgioptions.cfg(5)

--env=FILENAME

Load the environment from FILENAME before executing the CGI.

--area=NAME

Load environment variables for a specific area. NB: if used, this option must appear before any --env=FILENAME option.

## FILES
$XYMONHOME/web/maint_{header,form,footer}

HTML template header

## BUGS
When using alternate pagesets, hosts will only show up on the Enable/Disable page if this is accessed from the primary page in which they are defined. So if you have hosts on multiple pages, they will only be visible for disabling from their main page which is not what you would expect.

## SEE ALSO
xymon(7)


msgcache

title: msgcache(8)

text:
# msgcache(8)

## NAME
msgcache - Cache client messages for later pickup by xymonfetch

## SYNOPSIS
msgcache [options]

## DESCRIPTION
msgcache implements a Xymon message cache. It is intended for use with clients which cannot deliver their data to the Xymon server in the normal way. Instead of having the client tools connect to the Xymon server, msgcache runs locally and the client tools then deliver their data to the msgcache daemon. The msgcache daemon is then polled regularly by the xymonfetch(8) utility, which collects the client messages stored by msgcache and forwards them to the Xymon server.

NOTE: When using msgcache, the XYMSRV setting for the clients should be XYMSRV=127.0.0.1 instead of pointing at the real Xymon server.

## RESTRICTIONS
Clients delivering their data to msgcache instead of the real Xymon server will in general not notice this. Specifically, the client configuration data provided by the Xymon server when a client delivers its data is forwarded through the xymonfetch / msgcache chain, so the normal centralized client configuration works.

However, other commands which rely on clients communicating directly with the Xymon server will not work. This includes the config and query commands which clients may use to fetch configuration files and query the Xymon server for a current status.

The download command also does not work with msgcache. This means that the automatic client update facility will not work for clients communicating via msgcache.

## OPTIONS
--listen=IPADDRESS[:PORT]

Defines the IP-address and portnumber where msgcache listens for incoming connections. By default, msgcache listens for connections on all network interfaces, port 1984.

--server=IPADDRESS[,IPADDRESS]

Restricts which servers are allowed to pick up the cached messages. By default anyone can contact the msgcache utility and request all of the cached messages. This option allows only the listed servers to request the cached messages.

--max-age=N

Defines how long cached messages are kept. If the message has not been picked up with N seconds after being delivered to msgcache, it is silently discarded. Default: N=600 seconds (10 minutes).

--daemon

Run as a daemon, i.e. msgcache will detach from the terminal and run as a background task

--no-daemon

Run as a foreground task. This option must be used when msgcache is started by xymonlaunch(8) which is the normal way of running msgcache.

--pidfile=FILENAME

Store the process ID of the msgcache task in FILENAME.

--logfile=FILENAME

Log msgcache output to FILENAME.

--debug

Enable debugging output.

## SEE ALSO
xymonfetch(8), xymon(7)


trimhistory

title: trimhistory(8)

summary: Remove old Xymon history-log entries

text:
# trimhistory(8)

## NAME
trimhistory - Remove old Xymon history-log entries

## SYNOPSIS
trimhistory --cutoff=TIME [options]

## DESCRIPTION
The trimhistory tool is used to purge old entries from the Xymon history logs. These logfiles accumulate information about all status changes that have occurred for any given service, host, or the entire Xymon system, and is used to generate the event- and history-log webpages.

Purging old entries can be done while Xymon is running, since the tool takes care not to commit updates to a file if it changes mid-way through the operation. In that case, the update is aborted and the existing logfile is left untouched.

Optionally, this tool will also remove logfiles from hosts that are no longer defined in the Xymon hosts.cfg(5) file. As an extension, even logfiles from services can be removed, if the service no longer has a valid status-report logged in the current Xymon status.

## OPTIONS
--cutoff=TIME

This defines the cutoff-time when processing the history logs. Entries dated before this time are discarded. TIME is specified as the number of seconds since the beginning of the Epoch. This is easily generated by the GNU date(1) utility, e.g. the following command will trim history logs of all entries prior to Oct. 1st 2004:

trimhistory --cutoff=`date +%s --date="1 Oct 2004"`

--outdir=DIRECTORY

Normally, files in the XYMONHISTDIR directory are replaced. This option causes trimhistory to save the shortened history logfiles to another directory, so you can verify that the operation works as intended. The output directory must exist.

--drop

Causes trimhistory to delete files from hosts that are not listed in the hosts.cfg(5) file.

--dropsvcs

Causes trimhistory to delete files from services that are not currently tracked by Xymon. Normally these files would be left untouched if only the host exists.

--droplogs

Process the XYMONHISTLOGS directory also, and delete status-logs from events prior to the cut-off time. Note that this can dramatically increase the processing time, since there are often lots and lots of files to process.

--progress[=N]

This will cause trimhistory to output a status line for every N history logs or status-log collections it processes, to indicate how far it has progressed. The default setting for N is 100.

--env=FILENAME

Loads the environment from FILENAME before executing trimhistory.

--debug

Enable debugging output.

## FILES
$XYMONHISTDIR/allevents

The eventlog of all events that have happened in Xymon.

$XYMONHISTDIR/HOSTNAME

The per-host eventlogs.

$XYMONHISTDIR/HOSTNAME.SERVICE

The per-service eventlogs.

$XYMONHISTLOGS/*/*

The historical status-logs.

## ENVIRONMENT VARIABLES
XYMONHISTDIR

The directory holding all history logs.

XYMONHISTLOGS

The top-level directory for the historical status-log collections.

HOSTSCFG

The location of the hosts.cfg file, holding the list of currently known hosts in Xymon.

## SEE ALSO
xymon(7), hosts.cfg(5)


xymon-mailack

title: xymon-mailack(8)

summary: permit acknowledging alerts via e-mail

text:
# xymon-mailack(8)

## NAME
xymon-mailack - permit acknowledging alerts via e-mail

## SYNOPSIS
xymon-mailack --env=FILENAME [--debug]

## DESCRIPTION
xymon-mailack normally runs as an input mail-filter for the xymon user, e.g. by being called from the xymon users' procmailrc(5) file. xymon-mailack recognizes e-mails that are replies to xymond_alert(8) mail alerts, and converts the reply mail into an acknowledge message that is sent to the Xymon system. This permits an administrator to acknowledge an alert via e-mail.

## ADDING INFORMATION TO THE REPLY MAIL
By default, an acknowledgment is valid for 1 hour. If you know in advance that solving the problem is going to take longer, you can change this by adding delay=DURATION to the subject of your mail reply or on a line in the reply message. Duration is in minutes, unless you add a trailing 'h' (for 'hours'), 'd' (for 'days') or 'w' (for 'weeks').

You can also include a message that will show up on the status-page together with the acknowledgment, e.g. to provide an explanation for the issue or some other information to the users. You can either put it at the end of the subject line as msg=Some random text, or you can just enter it in the e-mail as the first non-blank line of text in the mail (a "delay=N" line is ignored when looking for the message text).

## USE WITH PROCMAIL
To setup xymon-mailack, create a .procmailrc file in the xymon-users home-directory with the following contents:

```
DEFAULT=$HOME/Mailbox
LOGFILE=$HOME/procmail.log
:0
| $HOME/server/bin/xymon-mailack --env=$HOME/server/etc/xymonserver.cfg
```

## USE WITH QMAIL
If you are using Qmail to deliver mail locally, you can run xymon-mailack directly from a .qmail file. Setup the xymon-users .qmail file like this:

```
| $HOME/server/bin/xymon-mailack --env=$HOME/server/etc/xymonserver.cfg
```

## OPTIONS
--env=FILENAME

Load environment from FILENAME, usually xymonserver.cfg.

--debug

Don't send a message to xymond, but dump the message to stdout.

## SEE ALSO
xymond_alert(8), xymond(8), xymon(7)


xymoncgimsg.cgi

title: xymoncgimsg.cgi(8)

text:
# xymoncgimsg.cgi(8)

## NAME
xymoncgimsg.cgi - CGI utility used for proxying Xymon data over HTTP

## SYNOPSIS
xymoncgimsg.cgi

## DESCRIPTION
xymoncgimsg.cgi(8) is the server-side utility receiving Xymon messages sent by the xymon(1) utility over an HTTP transport. The xymon utility normally sends data over a dedicated TCP protocol, but it may use HTTP to go through proxies or through restrictive firewalls. In that case, the webserver must have this CGI utility installed, which takes care of receiving the message via HTTP, and forwards it to a local Xymon server through the normal Xymon transport.

The CGI expects to be invoked from an HTTP "POST" request, with the POST-data being the status-message. xymoncgimsg.cgi simply collects all of the POST data, and send it off as a message to the Xymon daemon running on IP 127.0.0.1. This destination IP currently cannot be changed.

The CGI will return any output provided by the Xymon daemon back to the requestor as the response to the HTTP POST, so this allows for all normal Xymon commands to work.

## SECURITY
xymoncgimsg.cgi will only send data to a Xymon server through the loopback interface, i.e. IP-address 127.0.0.1.

Access to the CGI should be restricted through webserver access controls, since the CGI provides no authentication at all to validate incoming messages.

If possible, consider using the xymonproxy(8) utility instead for native proxying of Xymon data between networks.

## SEE ALSO
xymon(1), xymonproxy(8), xymon(7)