tinc.conf

package: tinc

title: tinc.conf(5)

summary: tinc daemon configuration

text:
# tinc.conf(5)

## NAME
tinc.conf — tinc daemon configuration

## DESCRIPTION
The files in the /etc/tinc/ directory contain runtime and security information for the tinc daemon.

## NETWORKS
It is perfectly ok for you to run more than one tinc daemon. However, in its default form, you will soon notice that you can't use two different configuration files without the -c option.

We have thought of another way of dealing with this: network names. This means that you call tinc.conf with the -n option, which will assign a name to this daemon.

The effect of this is that the daemon will set its configuration root to /etc/tinc/NETNAME/, where NETNAME is your argument to the -n option. You'll notice that messages appear in syslog as coming from tincd.NETNAME.

However, it is not strictly necessary that you call tinc with the -n option. In this case, the network name would just be empty, and it will be used as such. tinc now looks for files in /etc/tinc/, instead of /etc/tinc/NETNAME/; the configuration file should be /etc/tinc/tinc.conf, and the host configuration files are now expected to be in /etc/tinc/hosts/.

But it is highly recommended that you use this feature of tinc, because it will be so much clearer whom your daemon talks to. Hence, we will assume that you use it.

## NAMES
Each tinc daemon must have a name that is unique in the network which it will be part of. The name will be used by other tinc daemons for identification. The name has to be declared in the /etc/tinc/NETNAME/tinc.conf file.

To make things easy, choose something that will give unique and easy to remember names to your tinc daemon(s). You could try things like hostnames, owner surnames or location names.

## PUBLIC/PRIVATE KEYS
You should use tincd -K to generate public/private keypairs. It will generate two keys. The private key should be stored in a separate file /etc/tinc/NETNAME/rsa_key.priv -- where NETNAME stands for the network (see NETWORKS) above. The public key should be stored in the host configuration file /etc/tinc/NETNAME/hosts/NAME -- where NAME stands for the name of the local tinc daemon (see NAMES).

## SERVER CONFIGURATION
The server configuration of the daemon is done in the file /etc/tinc/NETNAME/tinc.conf. This file consists of comments (lines started with a #) or assignments in the form of:

Variable = Value.

The variable names are case insensitive, and any spaces, tabs, newlines and carriage returns are ignored. Note: it is not required that you put in the = sign, but doing so improves readability. If you leave it out, remember to replace it with at least one space character.

The server configuration is complemented with host specific configuration (see the next section). Although all configuration options for the local host listed in this document can also be put in /etc/tinc/NETNAME/tinc.conf, it is recommended to put host specific configuration options in the host configuration file, as this makes it easy to exchange with other nodes.

Here are all valid variables, listed in alphabetical order. The default value is given between parentheses.

AddressFamily = ipv4 | ipv6 | any (any)

This option affects the address family of listening and outgoing sockets. If "any" is selected, then depending on the operating system both IPv4 and IPv6 or just IPv6 listening sockets will be created.

BindToAddress = address [port] [experimental]

If your computer has more than one IPv4 or IPv6 address, tinc will by default listen on all of them for incoming connections. Multiple BindToAddress variables may be specified, in which case listening sockets for each specified address are made. If no port is specified, the socket will be bound to the port specified by the Port option, or to port 655 if neither is given. To only bind to a specific port but not to a specific address, use * for the address.

This option may not work on all platforms.

BindToInterface = interface [experimental]

If your computer has more than one network interface, tinc will by default listen on all of them for incoming connections. It is possible to bind only to a single interface with this variable. This option may not work on all platforms. Also, on some platforms it will not actually bind to an interface, but rather to the address that the interface has at the moment a socket is created.

Broadcast = no | mst | direct (mst) [experimental]

This option selects the way broadcast packets are sent to other daemons. NOTE: all nodes in a VPN must use the same Broadcast mode, otherwise routing loops can form. no

Broadcast packets are never sent to other nodes.

mst

Broadcast packets are sent and forwarded via the VPN's Minimum Spanning Tree. This ensures broadcast packets reach all nodes.

direct

Broadcast packets are sent directly to all nodes that can be reached directly. Broadcast packets received from other nodes are never forwarded. If the IndirectData option is also set, broadcast packets will only be sent to nodes which we have a meta connection to.

ConnectTo = name

Specifies which other tinc daemon to connect to on startup. Multiple ConnectTo variables may be specified, in which case outgoing connections to each specified tinc daemon are made. The names should be known to this tinc daemon (i.e., there should be a host configuration file for the name on the ConnectTo line). If you don't specify a host with ConnectTo, tinc won't try to connect to other daemons at all, and will instead just listen for incoming connections.

DecrementTTL = yes | no (no) [experimental]

When enabled, tinc will decrement the Time To Live field in IPv4 packets, or the Hop Limit field in IPv6 packets, before forwarding a received packet to the virtual network device or to another node, and will drop packets that have a TTL value of zero, in which case it will send an ICMP Time Exceeded packet back. Do not use this option if you use switch mode and want to use IPv6.

Device = device (/dev/tap0, /dev/net/tun or other depending on platform)

The virtual network device to use. tinc will automatically detect what kind of device it is. Note that you can only use one device per daemon. Under Windows, use Interface instead of Device. The info pages of the tinc package contain more information about configuring the virtual network device.

DeviceType = type (platform dependent)

The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in. dummy

Use a dummy interface. No packets are ever read or written to a virtual network device. Useful for testing, or when setting up a node that only forwards packets for other nodes.

raw_socket

Open a raw socket, and bind it to a pre-existing Interface (eth0 by default). All packets are read from this interface. Packets received for the local node are written to the raw socket. However, at least on Linux, the operating system does not process IP packets destined for the local host.

multicast

Open a multicast UDP socket and bind it to the address and port (separated by spaces) and optionally a TTL value specified using Device. Packets are read from and written to this multicast socket. This can be used to connect to UML, QEMU or KVM instances listening on the same multicast address. Do NOT connect multiple tinc daemons to the same multicast address, this will very likely cause routing loops. Also note that this can cause decrypted VPN packets to be sent out on a real network if misconfigured.

uml (not compiled in by default)

Create a UNIX socket with the filename specified by Device, or /var/run/NETNAME.umlsocket if not specified. tinc will wait for a User Mode Linux instance to connect to this socket.

vde (not compiled in by default)

Uses the libvdeplug library to connect to a Virtual Distributed Ethernet switch, using the UNIX socket specified by Device, or /var/run/vde.ctl if not specified.

Also, in case tinc does not seem to correctly interpret packets received from the virtual network device, it can be used to change the way packets are interpreted: tun (BSD and Linux)

Set type to tun. Depending on the platform, this can either be with or without an address family header (see below).

tunnohead (BSD)

Set type to tun without an address family header. Tinc will expect packets read from the virtual network device to start with an IP header. On some platforms IPv6 packets cannot be read from or written to the device in this mode.

tunifhead (BSD)

Set type to tun with an address family header. Tinc will expect packets read from the virtual network device to start with a four byte header containing the address family, followed by an IP header. This mode should support both IPv4 and IPv6 packets.

utun (OS X)

Set type to utun. This is only supported on OS X version 10.6.8 and higher, but doesn't require the tuntaposx module. This mode should support both IPv4 and IPv6 packets.

tap (BSD and Linux)

Set type to tap. Tinc will expect packets read from the virtual network device to start with an Ethernet header.

DirectOnly = yes | no (no) [experimental]

When this option is enabled, packets that cannot be sent directly to the destination node, but which would have to be forwarded by an intermediate node, are dropped instead. When combined with the IndirectData option, packets for nodes for which we do not have a meta connection with are also dropped.

Forwarding = off | internal | kernel (internal) [experimental]

This option selects the way indirect packets are forwarded. off

Incoming packets that are not meant for the local node, but which should be forwarded to another node, are dropped.

internal

Incoming packets that are meant for another node are forwarded by tinc internally. This is the default mode, and unless you really know you need another forwarding mode, don't change it.

kernel

Incoming packets are always sent to the TUN/TAP device, even if the packets are not for the local node. This is less efficient, but allows the kernel to apply its routing and firewall rules on them, and can also help debugging.

GraphDumpFile = filename [experimental]

If this option is present, tinc will dump the current network graph to the file filename every minute, unless there were no changes to the graph. The file is in a format that can be read by graphviz tools. If filename starts with a pipe symbol |, then the rest of the filename is interpreted as a shell command that is executed, the graph is then sent to stdin.

Hostnames = yes | no (no)

This option selects whether IP addresses (both real and on the VPN) should be resolved. Since DNS lookups are blocking, it might affect tinc's efficiency, even stopping the daemon for a few seconds every time it does a lookup if your DNS server is not responding. This does not affect resolving hostnames to IP addresses from the host configuration files, but whether hostnames should be resolved while logging.

IffOneQueue = yes | no (no) [experimental]

(Linux only) Set IFF_ONE_QUEUE flag on TUN/TAP devices.

Interface = interface

Defines the name of the interface corresponding to the virtual network device. Depending on the operating system and the type of device this may or may not actually set the name of the interface. Under Windows, this variable is used to select which network interface will be used. If you specified a Device, this variable is almost always already correctly set.

KeyExpire = seconds (3600)

This option controls the period the encryption keys used to encrypt the data are valid. It is common practice to change keys at regular intervals to make it even harder for crackers, even though it is thought to be nearly impossible to crack a single key.

LocalDiscovery = yes | no (no) [experimental]

When enabled, tinc will try to detect peers that are on the same local network. This will allow direct communication using LAN addresses, even if both peers are behind a NAT and they only ConnectTo a third node outside the NAT, which normally would prevent the peers from learning each other's LAN address. Currently, local discovery is implemented by sending broadcast packets to the LAN during path MTU discovery. This feature may not work in all possible situations.

MACExpire = seconds (600)

This option controls the amount of time MAC addresses are kept before they are removed. This only has effect when Mode is set to "switch".

MaxTimeout = seconds (900)

This is the maximum delay before trying to reconnect to other tinc daemons.

Mode = router | switch | hub (router)

This option selects the way packets are routed to other daemons. router

In this mode Subnet variables in the host configuration files will be used to form a routing table. Only unicast packets of routable protocols (IPv4 and IPv6) are supported in this mode. This is the default mode, and unless you really know you need another mode, don't change it.

switch

In this mode the MAC addresses of the packets on the VPN will be used to dynamically create a routing table just like an Ethernet switch does. Unicast, multicast and broadcast packets of every protocol that runs over Ethernet are supported in this mode at the cost of frequent broadcast ARP requests and routing table updates. This mode is primarily useful if you want to bridge Ethernet segments.

hub

This mode is almost the same as the switch mode, but instead every packet will be broadcast to the other daemons while no routing table is managed.

Name = name [required]

This is the name which identifies this tinc daemon. It must be unique for the virtual private network this daemon will connect to. The Name may only consist of alphanumeric and underscore characters. If Name starts with a $, then the contents of the environment variable that follows will be used. In that case, invalid characters will be converted to underscores. If Name is $HOST, but no such environment variable exist, the hostname will be read using the gethostname() system call.

PingInterval = seconds (60)

The number of seconds of inactivity that tinc will wait before sending a probe to the other end.

PingTimeout = seconds (5)

The number of seconds to wait for a response to pings or to allow meta connections to block. If the other end doesn't respond within this time, the connection is terminated, and the others will be notified of this.

PriorityInheritance = yes | no (no) [experimental]

When this option is enabled the value of the TOS field of tunneled IPv4 packets will be inherited by the UDP packets that are sent out.

PrivateKey = key [obsolete]

The private RSA key of this tinc daemon. It will allow this tinc daemon to authenticate itself to other daemons.

PrivateKeyFile = filename (/etc/tinc/NETNAME/rsa_key.priv)

The file in which the private RSA key of this tinc daemon resides.

ProcessPriority = low | normal | high

When this option is used the priority of the tincd process will be adjusted. Increasing the priority may help to reduce latency and packet loss on the VPN.

Proxy = socks4 | socks5 | http | exec ... [experimental]

Use a proxy when making outgoing connections. The following proxy types are currently supported: socks4 address port [username]

Connects to the proxy using the SOCKS version 4 protocol. Optionally, a username can be supplied which will be passed on to the proxy server. Only IPv4 connections can be proxied using SOCKS 4.

socks5 address port [username password]

Connect to the proxy using the SOCKS version 5 protocol. If a username and password are given, basic username/password authentication will be used, otherwise no authentication will be used.

http address port

Connects to the proxy and sends a HTTP CONNECT request.

exec command

Executes the given command which should set up the outgoing connection. The environment variables NAME, NODE, REMOTEADDRES and REMOTEPORT are available.

ReplayWindow = bytes (16)

This is the size of the replay tracking window for each remote node, in bytes. The window is a bitfield which tracks 1 packet per bit, so for example the default setting of 16 will track up to 128 packets in the window. In high bandwidth scenarios, setting this to a higher value can reduce packet loss from the interaction of replay tracking with underlying real packet loss and/or reordering. Setting this to zero will disable replay tracking completely and pass all traffic, but leaves tinc vulnerable to replay-based attacks on your traffic.

StrictSubnets = yes | no (no) [experimental]

When this option is enabled tinc will only use Subnet statements which are present in the host config files in the local /etc/tinc/NETNAME/hosts/ directory. Subnets learned via connections to other nodes and which are not present in the local host config files are ignored.

TunnelServer = yes | no (no) [experimental]

When this option is enabled tinc will no longer forward information between other tinc daemons, and will only allow connections with nodes for which host config files are present in the local /etc/tinc/NETNAME/hosts/ directory. Setting this options also implicitly sets StrictSubnets.

UDPRcvBuf = bytes (OS default)

Sets the socket receive buffer size for the UDP socket, in bytes. If unset, the default buffer size will be used by the operating system.

UDPSndBuf = bytes (OS default)

Sets the socket send buffer size for the UDP socket, in bytes. If unset, the default buffer size will be used by the operating system.

## HOST CONFIGURATION FILES
The host configuration files contain all information needed to establish a connection to those hosts. A host configuration file is also required for the local tinc daemon, it will use it to read in it's listen port, public key and subnets.

The idea is that these files are portable. You can safely mail your own host configuration file to someone else. That other person can then copy it to his own hosts directory, and now his tinc daemon will be able to connect to your tinc daemon. Since host configuration files only contain public keys, no secrets are revealed by sending out this information.

Address = address [port] [recommended]

The IP address or hostname of this tinc daemon on the real network. This will only be used when trying to make an outgoing connection to this tinc daemon. Optionally, a port can be specified to use for this address. Multiple Address variables can be specified, in which case each address will be tried until a working connection has been established.

Cipher = cipher (aes-256-cbc)

The symmetric cipher algorithm used to encrypt UDP packets. Any cipher supported by LibreSSL or OpenSSL is recognised. Furthermore, specifying "none" will turn off packet encryption. It is best to use only those ciphers which support CBC mode.

ClampMSS = yes | no (yes)

This option specifies whether tinc should clamp the maximum segment size (MSS) of TCP packets to the path MTU. This helps in situations where ICMP Fragmentation Needed or Packet too Big messages are dropped by firewalls.

Compression = level (0)

This option sets the level of compression used for UDP packets. Possible values are 0 (off), 1 (fast zlib) and any integer up to 9 (best zlib), 10 (fast lzo) and 11 (best lzo).

Digest = digest (sha256)

The digest algorithm used to authenticate UDP packets. Any digest supported by LibreSSL or OpenSSL is recognised. Furthermore, specifying "none" will turn off packet authentication.

IndirectData = yes | no (no)

When set to yes, only nodes which already have a meta connection to you will try to establish direct communication with you. It is best to leave this option out or set it to no.

MACLength = length (4)

The length of the message authentication code used to authenticate UDP packets. Can be anything from "0" up to the length of the digest produced by the digest algorithm.

PMTU = mtu (1514)

This option controls the initial path MTU to this node.

PMTUDiscovery = yes | no (yes)

When this option is enabled, tinc will try to discover the path MTU to this node. After the path MTU has been discovered, it will be enforced on the VPN.

Port = port (655)

The port number on which this tinc daemon is listening for incoming connections, which is used if no port number is specified in an Address statement.

PublicKey = key [obsolete]

The public RSA key of this tinc daemon. It will be used to cryptographically verify it's identity and to set up a secure connection.

PublicKeyFile = filename [obsolete]

The file in which the public RSA key of this tinc daemon resides. From version 1.0pre4 on tinc will store the public key directly into the host configuration file in PEM format, the above two options then are not necessary. Either the PEM format is used, or exactly one of the above two options must be specified in each host configuration file, if you want to be able to establish a connection with that host.

Subnet = address[/prefixlength[#weight]]

The subnet which this tinc daemon will serve. tinc tries to look up which other daemon it should send a packet to by searching the appropriate subnet. If the packet matches a subnet, it will be sent to the daemon who has this subnet in his host configuration file. Multiple Subnet variables can be specified. Subnets can either be single MAC, IPv4 or IPv6 addresses, in which case a subnet consisting of only that single address is assumed, or they can be a IPv4 or IPv6 network address with a prefixlength. For example, IPv4 subnets must be in a form like 192.168.1.0/24, where 192.168.1.0 is the network address and 24 is the number of bits set in the netmask. Note that subnets like 192.168.1.1/24 are invalid! Read a networking HOWTO/FAQ/guide if you don't understand this. IPv6 subnets are notated like fec0:0:0:1::/64. MAC addresses are notated like 0:1a:2b:3c:4d:5e.

A Subnet can be given a weight to indicate its priority over identical Subnets owned by different nodes. The default weight is 10. Lower values indicate higher priority. Packets will be sent to the node with the highest priority, unless that node is not reachable, in which case the node with the next highest priority will be tried, and so on.

TCPOnly = yes | no (no [obsolete])

If this variable is set to yes, then the packets are tunnelled over the TCP connection instead of a UDP connection. This is especially useful for those who want to run a tinc daemon from behind a masquerading firewall, or if UDP packet routing is disabled somehow. Setting this options also implicitly sets IndirectData. Since version 1.0.10, tinc will automatically detect whether communication via UDP is possible or not.

## SCRIPTS
Apart from reading the server and host configuration files, tinc can also run scripts at certain moments. Below is a list of filenames of scripts and a description of when they are run. A script is only run if it exists and if it is executable.

Scripts are run synchronously; this means that tinc will temporarily stop processing packets until the called script finishes executing. This guarantees that scripts will execute in the exact same order as the events that trigger them. If you need to run commands asynchronously, you have to ensure yourself that they are being run in the background.

Under Windows (not Cygwin), the scripts must have the extension .bat.

/etc/tinc/NETNAME/tinc-up

This is the most important script. If it is present it will be executed right after the tinc daemon has been started and has connected to the virtual network device. It should be used to set up the corresponding network interface, but can also be used to start other things. Under Windows you can use the Network Connections control panel instead of creating this script.

/etc/tinc/NETNAME/tinc-down

This script is started right before the tinc daemon quits.

/etc/tinc/NETNAME/hosts/HOST-up

This script is started when the tinc daemon with name HOST becomes reachable.

/etc/tinc/NETNAME/hosts/HOST-down

This script is started when the tinc daemon with name HOST becomes unreachable.

/etc/tinc/NETNAME/host-up

This script is started when any host becomes reachable.

/etc/tinc/NETNAME/host-down

This script is started when any host becomes unreachable.

/etc/tinc/NETNAME/subnet-up

This script is started when a Subnet becomes reachable. The Subnet and the node it belongs to are passed in environment variables.

/etc/tinc/NETNAME/subnet-down

This script is started when a Subnet becomes unreachable.

The scripts are started without command line arguments, but can make use of certain environment variables. Under UNIX like operating systems the names of environment variables must be preceded by a $ in scripts. Under Windows, in .bat files, they have to be put between % signs.

NETNAME

If a netname was specified, this environment variable contains it.

NAME

Contains the name of this tinc daemon.

DEVICE

Contains the name of the virtual network device that tinc uses.

INTERFACE

Contains the name of the virtual network interface that tinc uses. This should be used for commands like ifconfig.

NODE

When a host becomes (un)reachable, this is set to its name. If a subnet becomes (un)reachable, this is set to the owner of that subnet.

REMOTEADDRESS

When a host becomes (un)reachable, this is set to its real address.

REMOTEPORT

When a host becomes (un)reachable, this is set to the port number it uses for communication with other tinc daemons.

SUBNET

When a subnet becomes (un)reachable, this is set to the subnet.

WEIGHT

When a subnet becomes (un)reachable, this is set to the subnet weight.

Do not forget that under UNIX operating systems, you have to make the scripts executable, using the command chmod a+x script.

## FILES
The most important files are:

/etc/tinc/

The top directory for configuration files.

/etc/tinc/NETNAME/tinc.conf

The default name of the server configuration file for net NETNAME.

/etc/tinc/NETNAME/conf.d/

Optional directory from which any *.conf file will be loaded

/etc/tinc/NETNAME/hosts/

Host configuration files are kept in this directory.

/etc/tinc/NETNAME/tinc-up

If an executable file with this name exists, it will be executed right after the tinc daemon has connected to the virtual network device. It can be used to set up the corresponding network interface.

/etc/tinc/NETNAME/tinc-down

If an executable file with this name exists, it will be executed right before the tinc daemon is going to close its connection to the virtual network device.

## SEE ALSO
tincd(8), https://www.tinc-vpn.org/, http://www.tldp.org/LDP/nag2/.

The full documentation for tinc is maintained as a Texinfo manual. If the info and tinc programs are properly installed at your site, the command info tinc should give you access to the complete manual.

tinc comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details.


tinyproxy.conf

package: tinyproxy

title: tinyproxy.conf(5)

text:
# tinyproxy.conf(5)

## NAME
tinyproxy.conf - Tinyproxy HTTP proxy daemon configuration file

## SYNOPSIS
tinyproxy.conf

## DESCRIPTION
tinyproxy(8) reads its configuration file, typically stored in `/etc/tinyproxy/tinyproxy.conf` (or passed to Tinyproxy with -c on the command line). This manpage describes the syntax and contents of the configuration file.

The Tinyproxy configuration file contains key-value pairs, one per line. Lines starting with `#` and empty lines are comments and are ignored. Keywords are case-insensitive, whereas values are case-sensitive. Some string values must be enclosed in double quotes (") as noted below.

The possible keywords and their descriptions are as follows:

User

The user which the Tinyproxy process should run as, after the initial port-binding has been done as the `root` user. Either the user name or the UID may be specified.

Group

The group which the Tinyproxy process should run as, after the initial port-binding has been done as the `root` user. Either the group name or the GID may be specified.

Port

The port which the Tinyproxy service will listen on. If the port is less than 1024, you will need to start the Tinyproxy process as the `root` user.

Listen

By default, Tinyproxy listens for connections on all available interfaces (i.e. it listens on the wildcard address `0.0.0.0`). With this configuration parameter, Tinyproxy can be told to listen only on one specific address.

Bind

This allows you to specify which address Tinyproxy will bind to for outgoing connections. This parameter may be specified multiple times, then Tinyproxy will try all the specified addresses in order.

BindSame

If this boolean parameter is set to `yes`, then Tinyproxy will bind the outgoing connection to the IP address of the incoming connection that triggered the outgoing request.

Timeout

The maximum number of seconds of inactivity a connection is allowed to have before it is closed by Tinyproxy.

ErrorFile

This parameter controls which HTML file Tinyproxy returns when a given HTTP error occurs. It takes two arguments, the error number and the location of the HTML error file. Enclose the file location in double quotes.

DefaultErrorFile

The HTML template file returned when an error occurs for which no specific error file has been set. Enclose in double quotes.

StatHost

The host name or IP address that is treated as the `stat host`. Enclose in double quotes. Whenever Tinyproxy receives a request for the `stat host` it returns an internal statistics page instead of forwarding the request to that host. The template for this page can be configured with the `StatFile` configuration option. The default value of `StatHost` is `tinyproxy.stats`.

StatFile

The HTML file that Tinyproxy sends in response to a request for the `stat host`. Enclose in double quotes. If this parameter is not set, Tinyproxy returns a hard-coded basic statistics page. See the STATHOST section in the tinyproxy(8) manual page for details. Note that the StatFile and the error files configured with ErrorFile and DefaultErrorFile are template files that can contain a few template variables that Tinyproxy expands prior to delivery. Examples are "{cause}" for an abbreviated error description and "{detail}" for a detailed error message. The tinyproxy(8) manual page contains a description of all template variables.

LogFile

The location of the file to which Tinyproxy writes its debug output. Enclose in double quotes. Alternatively, Tinyproxy can log to syslog -- see the Syslog option.

Syslog

When set to `On`, this option tells Tinyproxy to write its debug messages to syslog instead of to a log file configured with `LogFile`. These two options are mutually exclusive.

LogLevel

Sets the log level. Messages from the set level and above are logged. For example, if the LogLevel was set to Warning, then all log messages from Warning to Critical would be output, but Notice and below would be suppressed. Allowed values are:

- Critical (least verbose)

- Error

- Warning

- Notice

- Connect (log connections without Info's noise)

- Info (most verbose)

PidFile

The location of the file where the main Tinyproxy process stores its process ID for signaling purposes. Enclose in double quotes.

XTinyproxy

Setting this option to `Yes` tells Tinyproxy to add a header `X-Tinyproxy` containing the client's IP address to the request.

Upstream

This option allows you to set up a set of rules for deciding whether an upstream proxy server is to be used, based on the host or domain of the site being accessed. The rules are stored in the order encountered in the configuration file and the LAST matching rule wins. The following forms for specifying upstream rules exist:

- upstream type host:port turns proxy upstream support on generally.

- upstream type user:pass@host:port does the same, but uses the supplied credentials for authentication.

- upstream type host:port "site_spec" turns on the upstream proxy for the sites matching `site_spec`. `type` can be one of `http`, `socks4`, `socks5`, `none`.

- upstream none "site_spec" turns off upstream support for sites matching `site_spec`, that means the connection is done directly.

It's recommended to use raw IP addresses to specify the upstream host, so no costly DNS lookup has to be done everytime it is used. IPv6 addresses need to be enclosed in square brackets.

The site can be specified in various forms as a hostname, domain name or as an IP range:

- name matches host exactly

- .name matches any host in domain "name"

- . matches any host with no domain (in 'empty' domain)

- IP/bits matches network/mask

- IP/mask matches network/mask

Note that the upstream directive can also be used to null-route a specific target domain/host, e.g.: `upstream http 0.0.0.0:0 ".adserver.com"`

MaxClients

Tinyproxy creates one thread for each connected client. This options specifies the absolute highest number processes that will be created. With other words, only MaxClients clients can be connected to Tinyproxy simultaneously.

Allow

Deny

The `Allow` and `Deny` options provide a means to customize which clients are allowed to access Tinyproxy. `Allow` and `Deny` lines can be specified multiple times to build the access control list for Tinyproxy. The order in the config file is important. If there are no `Allow` or `Deny` lines, then all clients are allowed. Otherwise, the default action is to deny access. The argument to `Allow` or `Deny` can be a single IP address of a client host, like `127.0.0.1`, an IP address range, like `192.168.0.1/24` or a string that will be matched against the end of the client host name, i.e, this can be a full host name like `host.example.com` or a domain name like `.example.com` or even a top level domain name like `.com`. Note that by adding a rule using a host or domain name, a costly name lookup has to be done for every new connection, which could slow down the service considerably.

BasicAuth

Configure HTTP "Basic Authentication" username and password for accessing the proxy. If there are any entries specified, access is only granted for authenticated users.

```
    BasicAuth user password

```

AddHeader

Configure one or more HTTP request headers to be added to outgoing HTTP requests that Tinyproxy makes. Note that this option will not work for HTTPS traffic, as Tinyproxy has no control over what headers are exchanged.

```
    AddHeader "X-My-Header" "Powered by Tinyproxy"

```

ViaProxyName

RFC 2616 requires proxies to add a `Via` header to the HTTP requests, but using the real host name can be a security concern. If the `ViaProxyname` option is present, then its string value will be used as the host name in the Via header. Otherwise, the server's host name will be used. Enclose in double quotes.

DisableViaHeader

When this is set to yes, Tinyproxy does NOT add the `Via` header to the requests. This virtually puts Tinyproxy into stealth mode. Note that RFC 2616 requires proxies to set the `Via` header, so by enabling this option, you break compliance. Don't disable the `Via` header unless you know what you are doing...

Filter

Tinyproxy supports filtering of web sites based on URLs or domains. This option specifies the location of the file containing the filter rules, one rule per line. Rules are specified as POSIX basic regular expressions (BRE), unless another FilterType is specified. Comment lines start with a `#` character.

Example filter file contents:

```
 # filter exactly cnn.com
 ^cnn\.com$

 # filter all subdomains of cnn.com, but not cnn.com itself
 .*\.cnn.com$

 # filter any domain that has cnn.com in it, like xcnn.comfy.org
 cnn\.com

 # filter any domain that ends in cnn.com
 cnn\.com$

 # filter any domain that starts with adserver
 ^adserver

```

FilterType

This option can be set to one of `bre`, `ere`, or `fnmatch`. If `bre` is set, the rules specified in the filter file are matched using POSIX basic regular expressions, when set to `ere`, using POSIX extended regular expressions, and when set to `fnmatch` using the `fnmatch` function as specified in the manpage `man 3p fnmatch`. `fnmatch` matching is identical to what's used in the shell to match filenames, so for example `*.google.com` matches everything that ends with `.google.com`. If you don't know what regular expressions are or you're using filter lists from 3rd party sources, `fnmatch` is probably what you want. It's also the fastest matching method of the three.

FilterURLs

If this boolean option is set to `Yes` or `On`, filtering is performed for URLs rather than for domains. The default is to filter based on domains. Note that filtering for URLs works only in plain HTTP scenarios. Since HTTPS has become ubiquitous during the last years, this will only work on a tiny fraction of websites, so it is recommended not to use this option.

FilterExtended

Deprecated. Use `FilterType ere` instead. If this boolean option is set to `Yes`, then extended POSIX regular expressions are used for matching the filter rules. The default is to use basic POSIX regular expressions.

FilterCaseSensitive

If this boolean option is set to `Yes`, then the filter rules are matched in a case sensitive manner. The default is to match case-insensitively, unfortunately. If you set this to `Yes`, then your matching will be almost twice as fast. This setting affects only `bre` and `ere` FilterTypes, fnmatch is always case sensitive.

FilterDefaultDeny

The default filtering policy is to allow everything that is not matched by a filtering rule. Setting `FilterDefaultDeny` to `Yes` changes the policy do deny everything but the domains or URLs matched by the filtering rules. In other words, if set to `No` the Filter list acts as a blacklist, if set to `Yes` as a whitelist.

Anonymous

If an `Anonymous` keyword is present, then anonymous proxying is enabled. The headers listed with `Anonymous` are allowed through, while all others are denied. If no Anonymous keyword is present, then all headers are allowed through. You must include double quotes around the headers. Most sites require cookies to be enabled for them to work correctly, so you will need to allow cookies through if you access those sites.

Example:

```
    Anonymous "Host"
    Anonymous "Authorization"
    Anonymous "Cookie"

```

ConnectPort

This option can be used to specify the ports allowed for the CONNECT method. If no `ConnectPort` line is found, then all ports are allowed. To disable CONNECT altogether, include a single ConnectPort line with a value of `0`.

ReversePath

Configure one or more ReversePath directives to enable reverse proxy support. With reverse proxying it's possible to make a number of sites appear as if they were part of a single site. If you uncomment the following two directives and run Tinyproxy on your own computer at port 8888, you can access example.com, using http://localhost:8888/example/.

```
    ReversePath "/example/" "http://www.example.com/"

```

ReverseOnly

When using Tinyproxy as a reverse proxy, it is STRONGLY recommended that the normal proxy is turned off by setting this boolean option to `Yes`.

ReverseMagic

Setting this option to `Yes`, makes Tinyproxy use a cookie to track reverse proxy mappings. If you need to reverse proxy sites which have absolute links you must use this option.

ReverseBaseURL

The URL that is used to access this reverse proxy. The URL is used to rewrite HTTP redirects so that they won't escape the proxy. If you have a chain of reverse proxies, you'll need to put the outermost URL here (the address which the end user types into his/her browser). If this option is not set then no rewriting of redirects occurs.

## BUGS
To report bugs in Tinyproxy, please visit <https://tinyproxy.github.io/>.

## SEE ALSO
tinyproxy(8)

## AUTHOR
This manpage was written by the Tinyproxy project team.

## COPYRIGHT
Copyright (c) 1998-2020 the Tinyproxy authors.

This program is distributed under the terms of the GNU General Public License version 2 or above. See the COPYING file for additional information.


torsocks.conf

package: torsocks

title: torsocks.conf(5)

summary: Configuration file for torsocks(8)

text:
# torsocks.conf(5)

## NAME
torsocks.conf — Configuration file for torsocks(8)

## SUMMARY
By default, torsocks will assume that it should connect to the Tor SOCKS proxy running at 127.0.0.1 on port 9050. This is the default address and port for Tor's socks server on most installations. If you are running a normal Tor installation and have no special requirements, then you should not need to create, edit or invoke a configuration file when using torsocks.

Your installation of torsocks includes a default configuration file that contains values sensible for use with most Tor installations. The installation location for your default configuration file is:

/etc/tor/torsocks.conf

In order to use a configuration file, you must set the environment variable TORSOCKS_CONF_FILE with the location of the file.

If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration file at /etc/tor/torsocks.conf. If that file cannot be read, torsocks will use sensible defaults for most Tor installations, i.e. it will assume that you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050.

## CONFIGURATION

### SYNTAX
The basic structure of all lines in the configuration file is:

<directive> <parameters>

Empty lines are ignored and all input on a line after a '#' character is ignored.

### DIRECTIVES
The following directives are used in the torsocks configuration file:

TorAddress ip_addr

The IP address of the Tor SOCKS server (e.g "server = 10.1.4.253"). Only one server may be specified. Currently, torsocks does NOT support hostname. (default: 127.0.0.1)

TorPort port

The port on which the Tor SOCKS server receives requests. (default: 9050)

OnionAddrRange subnet/mask

Tor hidden sites do not have real IP addresses. This specifies what range of IP addresses will be handed to the application as "cookies" for .onion names. Of course, you should pick a block of addresses which you aren't going to ever need to actually connect to. This is similar to the MapAddress feature of the main tor daemon. (default: 127.42.42.0/24)

SOCKS5Username username

Username to use for SOCKS5 authentication method that makes the connections to Tor to use a different circuit from other existing streams. If set, the SOCKS5Password must be specified also. (Default: none).

SOCKS5Password password

Password to use for SOCKS5 authentication method that makes the connections to Tor to use a different circuit from other existing streams. If set, the SOCKS5Username must be specified also. (Default: none).

AllowInbound 0|1

Allow inbound connections meaning that listen() and accept()/accept4() will be allowed for non localhost address so the applicaton can handle incoming connection. Note that Unix socket are allowed. (Default: 0)

AllowOutboundLocalhost 0|1|2

Allow outbound connections to the loopback interface meaning that connect() will be allowed to connect to localhost addresses bypassing Tor. If set to 1, TCP connections will be allowed. If set to 2, both TCP/IP and UDP connections will be allowed. This option should not be used by most users. (Default: 0)

IsolatePID 0|1

Set Torsocks to use an automatically generated SOCKS5 username/password based on the process ID and current time, that makes the connections to Tor use a different circuit from other existing streams in Tor on a per-process basis. If set, the SOCKS5Username and SOCKS5Password options must not be set. (Default: 0)

## EXAMPLE

$ export TORSOCKS_CONF_FILE=$PWD/torsocks.conf

$ torsocks ssh account@sshserver.com

## SEE ALSO
torsocks(1), torsocks(8),

## AUTHOR
David Goulet <dgoulet@ev0ke.net>


package: trace-cmd

title: trace-cmd.dat.v6(5)

summary: trace\-cmd version 6 file format

text:
# trace-cmd.dat.v6(5)

## NAME
trace-cmd.dat.v6 - trace-cmd version 6 file format

## SYNOPSIS
trace-cmd.dat ignore

## DESCRIPTION
The trace-cmd(1) utility produces a "trace.dat" file. The file may also be named anything depending if the user specifies a different output name, but it must have a certain binary format. The file is used by trace-cmd to save kernel traces into it and be able to extract the trace from it at a later point (see trace-cmd-report(1)).

## INITIAL FORMAT

```
The first three bytes contain the magic value:
```

```
0x17 0x08  0x44
```

```
The next 7 bytes contain the characters:
```

```
"tracing"
```

```
The next set of characters contain a null '\0' terminated string
that contains the version of the file:
```

```
"6\0"
```

```
The next 1 byte contains the flags for the file endianess:
```

```
0 = little endian
1 = big endian
```

```
The next byte contains the number of bytes per "long" value:
```

```
4 - 32-bit long values
8 - 64-bit long values
```

```
Note: This is the long size of the target's userspace. Not the
kernel space size.
```

```
[ Now all numbers are written in file defined endianess. ]
```

```
The next 4 bytes are a 32-bit word that defines what the traced
host machine page size was.
```

## HEADER INFO FORMAT

```
Directly after the initial format comes information about the
trace headers recorded from the target box.
```

```
The next 12 bytes contain the string:
```

```
"header_page\0"
```

```
The next 8 bytes are a 64-bit word containing the size of the
page header information stored next.
```

```
The next set of data is of the size read from the previous 8 bytes,
and contains the data retrieved from debugfs/tracing/events/header_page.
```

```
Note: The size of the second field \fBcommit\fR contains the target
kernel long size. For example:
```

```
field: local_t commit;        offset:8;       \fBsize:8;\fR   signed:1;
```

```
shows the kernel has a 64-bit long.
```

```
The next 13 bytes contain the string:
```

```
"header_event\0"
```

```
The next 8 bytes are a 64-bit word containing the size of the
event header information stored next.
```

```
The next set of data is of the size read from the previous 8 bytes
and contains the data retrieved from debugfs/tracing/events/header_event.
```

```
This data allows the trace-cmd tool to know if the ring buffer format
of the kernel made any changes.
```

## FTRACE EVENT FORMATS

```
Directly after the header information comes the information about
the Ftrace specific events. These are the events used by the Ftrace plugins
and are not enabled by the event tracing.
```

```
The next 4 bytes contain a 32-bit word of the number of Ftrace event
format files that are stored in the file.
```

```
For the number of times defined by the previous 4 bytes is the
following:
```

```
8 bytes for the size of the Ftrace event format file.
```

```
The Ftrace event format file copied from the target machine:
debugfs/tracing/events/ftrace/<event>/format
```

## EVENT FORMATS

```
Directly after the Ftrace formats comes the information about
the event layout.
```

```
The next 4 bytes are a 32-bit word containing the number of
event systems that are stored in the file. These are the
directories in debugfs/tracing/events excluding the \fBftrace\fR
directory.
```

```
For the number of times defined by the previous 4 bytes is the
following:
```

```
A null-terminated string containing the system name.
```

```
4 bytes containing a 32-bit word containing the number
of events within the system.
```

```
For the number of times defined in the previous 4 bytes is the
following:
```

```
8 bytes for the size of the event format file.
```

```
The event format file copied from the target machine:
debugfs/tracing/events/<system>/<event>/format
```

## KALLSYMS INFORMATION

```
Directly after the event formats comes the information of the mapping
of function addresses to the function names.
```

```
The next 4 bytes are a 32-bit word containing the size of the
data holding the function mappings.
```

```
The next set of data is of the size defined by the previous 4 bytes
and contains the information from the target machine's file:
/proc/kallsyms
```

## TRACE_PRINTK INFORMATION

```
If a developer used trace_printk() within the kernel, it may
store the format string outside the ring buffer.
This information can be found in:
debugfs/tracing/printk_formats
```

```
The next 4 bytes are a 32-bit word containing the size of the
data holding the printk formats.
```

```
The next set of data is of the size defined by the previous 4 bytes
and contains the information from debugfs/tracing/printk_formats.
```

## PROCESS INFORMATION

```
Directly after the trace_printk formats comes the information mapping
a PID to a process name.
```

```
The next 8 bytes contain a 64-bit word that holds the size of the
data mapping the PID to a process name.
```

```
The next set of data is of the size defined by the previous 8 bytes
and contains the information from debugfs/tracing/saved_cmdlines.
```

## REST OF TRACE-CMD HEADER

```
Directly after the process information comes the last bit of the
trace.dat file header.
```

```
The next 4 bytes are a 32-bit word defining the number of CPUs that
were discovered on the target machine (and has matching trace data
for it).
```

```
The next 10 bytes are one of the following:
```

```
"options  \0"
```

```
"latency  \0"
```

```
"flyrecord\0"
```

```
If it is "options  \0" then:
```

```
The next 2 bytes are a 16-bit word defining the current option.
If the the value is zero then there are no more options.
```

```
Otherwise, the next 4 bytes contain a 32-bit word containing the
option size. If the reader does not know how to handle the option
it can simply skip it. Currently there are no options defined,
but this is here to extend the data.
```

```
The next option will be directly after the previous option, and
the options ends with a zero in the option type field.
```

```
The next 10 bytes after the options are one of the following:
```

```
"latency  \0"
```

```
"flyrecord\0"
```

```
which would follow the same as if options were not present.
```

```
If the value is "latency  \0", then the rest of the file is
simply ASCII text that was taken from the target's:
debugfs/tracing/trace
```

```
If the value is "flyrecord\0", the following is present:
```

```
For the number of CPUs that were read earlier, the
following is present:
```

```
8 bytes that are a 64-bit word containing the offset into the file
that holds the data for the CPU.
```

```
8 bytes that are a 64-bit word containing the size of the CPU
data at that offset.
```

## CPU DATA

```
The CPU data is located in the part of the file that is specified
in the end of the header. Padding is placed between the header and
the CPU data, placing the CPU data at a page aligned (target page) position
in the file.
```

```
This data is copied directly from the Ftrace ring buffer and is of the
same format as the ring buffer specified by the event header files
loaded in the header format file.
```

```
The trace-cmd tool will try to \fBmmap(2)\fR the data page by page with the
target's page size if possible. If it fails to mmap, it will just read the
data instead.
```

## SEE ALSO
trace-cmd(1), trace-cmd-record(1), trace-cmd-report(1), trace-cmd-start(1), trace-cmd-stop(1), trace-cmd-extract(1), trace-cmd-reset(1), trace-cmd-split(1), trace-cmd-list(1), trace-cmd-listen(1), trace-cmd.dat(5)

## AUTHOR
Written by Steven Rostedt, <rostedt@goodmis.org[1]>

## RESOURCES
https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/

## COPYING
Copyright (C) 2010 Red Hat, Inc. Free use of this software is granted under the terms of the GNU Public License (GPL).

## NOTES
1.

rostedt@goodmis.org

mailto:rostedt@goodmis.org


title: trace-cmd.dat.v7(5)

summary: trace\-cmd version 7 file format

text:
# trace-cmd.dat.v7(5)

## NAME
trace-cmd.dat.v7 - trace-cmd version 7 file format

## SYNOPSIS
trace-cmd.dat ignore

## DESCRIPTION
The trace-cmd(1) utility produces a "trace.dat" file. The file may also be named anything depending if the user specifies a different output name, but it must have a certain binary format. The file is used by trace-cmd to save kernel traces into it and be able to extract the trace from it at a later point (see trace-cmd-report(1)).

## INITIAL FORMAT

```
The first three bytes contain the magic value:
```

```
0x17 0x08  0x44
```

```
The next 7 bytes contain the characters:
```

```
"tracing"
```

```
The next set of characters contain a null '\0' terminated string
that contains the version of the file:
```

```
"7\0"
```

```
The next 1 byte contains the flags for the file endianess:
```

```
0 = little endian
1 = big endian
```

```
The next byte contains the number of bytes per "long" value:
```

```
4 - 32-bit long values
8 - 64-bit long values
```

```
Note: This is the long size of the target's user space. Not the
kernel space size.
```

```
[ Now all numbers are written in file defined endianess. ]
```

```
The next 4 bytes are a 32-bit word that defines what the traced
host machine page size was.
```

```
The compression algorithm header is written next:

   "name\0version\0"
where "name" and "version" are strings, name and version of the
compression algorithm used to compress the trace file. If the name
is "none", the data in the file is not compressed.
```

```
The next 8 bytes are 64-bit integer, the offset within the file where
the first OPTIONS section is located.
```

```
The rest of the file consists of different sections. The only mandatory
is the first OPTIONS section, all others are optional. The location and
the order of the sections is not strict. Each section starts with a header:
```

## FORMAT OF THE SECTION HEADER

```
<2 bytes> unsigned short integer, ID of the section.
<2 bytes> unsigned short integer, section flags:

  1 = the section is compressed.
<4 bytes> ID of a string, description of the section.
<8 bytes> long long unsigned integer, size of the section in the file.
```

```
If the section is compressed, the above is the compressed size.
The section must be uncompressed on reading. The described format of
the sections refers to the uncompressed data.
```

## COMPRESSION FORMAT OF THE FILE SECTIONS

```
Some of the sections in the file may be compressed with the compression algorithm,
specified in the compression algorithm header. Compressed sections have a compression
header, written after the section header and right before the compressed data:

  <4 bytes> unsigned int, size of compressed data in this section.

  <4 bytes> unsigned int, size of uncompressed data.

  <data> binary compressed data, with the specified size.
```

## COMPRESSION FORMAT OF THE TRACE DATA

```
There are two special sections, BUFFER FLYRECORD and BUFFER LATENCY, containing
trace data. These sections may be compressed with the compression algorithm, specified
in the compression header. Usually the size of these sections is huge, that's why its
compression format is different from the other sections. The trace data is compressed
in chunks The size of one chunk is specified in the file creation time. The format
of compressed trace data is:

   <4 bytes> unsigned int, count of chunks.

   Follows the compressed chunks of given count. For each chunk:

      <4 bytes> unsigned int, size of compressed data in this chunk.

      <4 bytes> unsigned int, size of uncompressed data, aligned with the trace page size.

      <data> binary compressed data, with the specified size.
These chunks must be uncompressed on reading. The described format of
trace data refers to the uncompressed data.
```

## OPTIONS SECTION

```
Section ID: 0
```

```
This is the the only mandatory section in the file. There can be multiple
options sections, the first one is located at the offset specified right
after the compression algorithm header. The section consists of multiple
trace options, each option has the following format:

  <2 bytes> unsigned short integer, ID of the option.

  <4 bytes> unsigned integer, size of the option's data.

  <binary data> bytes of the size specified above, data of the option.
```

```
Options, supported by the trace file version 7:
```

```
DONE: id 0, size 8

  This option indicates the end of the options section, it is written

  always as last option. The DONE option data is:

     <8 bytes> long long unsigned integer, offset in the trace file where

     the next options section is located. If this offset is 0, then there

     are no more options sections.
```

```
DATE: id 1, size vary

  The DATE option data is a null terminated ASCII string, which represents

  the time difference between trace events timestamps and the Generic Time

  of Day of the system.
```

```
CPUSTAT: id 2, size vary

  The CPUSTAT option data is a null terminated ASCII string, the content of the

  "per_cpu/cpu<id>/stats" file from the trace directory. There is a CPUSTAT option

  for each CPU.
```

```
BUFFER: id 3, size vary

  The BUFFER option describes the flyrecord trace data saved in the file, collected

  from one trace instance. There is BUFFER option for each trace instance. The format

  of the BUFFER data is:

    <8 bytes> long long unsigned integer, offset in the trace file where the

    BUFFER FLYRECORD section is located, containing flyrecord trace data.

    <string> a null terminated ASCII string, name of the trace instance. Empty string ""

    is saved as name of the top instance.

    <string> a null terminated ASCII string, trace clock used for events timestamps in

    this trace instance.

    <4 bytes> unsigned integer, size of the trace buffer page.

    <4 bytes> unsigned integer, count of the CPUs with trace data.

    For each CPU of the above count:

       <4 bytes> unsigned integer, ID of the CPU.

       <8 bytes> long long unsigned integer, offset in the trace file where the trace data

       for this CPU is located.

       <8 bytes> long long unsigned integer, size of the trace data for this CPU.
```

```
TRACECLOCK: id 4, size vary

  The TRACECLOCK option data is a null terminated ASCII string, the content of the

  "trace_clock" file from the trace directory.
```

```
UNAME: id 5, size vary

  The UNAME option data is a null terminated ASCII string, identifying the system where

  the trace data is collected. The string is retrieved by the uname() system call.
```

```
HOOK: id 6, size vary

  The HOOK option data is a null terminated ASCII string, describing event hooks: custom

  event matching to connect any two events together.
```

```
OFFSET: id 7, size vary

  The OFFSET option data is a null terminated ASCII string, representing a fixed time that

  is added to each event timestamp on reading.
```

```
CPUCOUNT: id 8, size 4

  The CPUCOUNT option data is:

    <4 bytes> unsigned integer, number of CPUs in the system.
```

```
VERSION: id 9, size vary

  The VERSION option data is a null terminated ASCII string, representing the version of

  the trace-cmd application, used to collect these trace logs.
```

```
PROCMAPS: id 10, size vary

  The PROCMAPS option data is a null terminated ASCII string, representing the memory map

  of each traced filtered process. The format of the string is, for each filtered process:

    <procss ID> <libraries count> <process command> \n

      <memory start address> <memory end address> <full path of the mapped library file> \n

      ...

       separate line for each library, used by this process

      ...

    ...
```

```
TRACEID: id 11, size 8

  The TRACEID option data is a unique identifier of this tracing session:

    <8 bytes> long long unsigned integer, trace session identifier.
```

```
TIME_SHIFT: id 12, size vary

  The TIME_SHIFT option stores time synchronization information, collected during host and guest

  tracing session. Usually it is saved in the guest trace file. This information is used to

  synchronize guest with host events timestamps, when displaying all files from this tracing

  session. The format of the TIME_SHIFT option data is:

    <8 bytes> long long unsigned integer, trace identifier of the peer (usually the host).

    <4 bytes> unsigned integer, flags specific to the time synchronization protocol, used in this

    trace session.

    <4 bytes> unsigned integer, number of traced CPUs. For each CPU, timestamps corrections

    are recorded:

       <4 bytes> unsigned integer, count of the recorded timestamps corrections for this CPU.

       <array of unsigned long long integers of the above count>, times when the corrections are calculated

       <array of unsigned long long integers of the above count>, corrections offsets

       <array of unsigned long long integers of the above count>, corrections scaling ratio
```

```
GUEST: id 13, size vary

  The GUEST option stores information about traced guests in this tracing session. Usually it is

  saved in the host trace file. There is a separate GUEST option for each traced guest.

  The information is used when displaying all files from this tracing session. The format of

  the GUEST option data is:

     <string> a null terminated ASCII string, name of the guest.

     <8 bytes> long long unsigned integer, trace identifier of the guest for this session.

     <4 bytes> unsigned integer, number of guest's CPUs. For each CPU:

        <4 bytes> unsigned integer, ID of the CPU.

        <4 bytes> unsigned integer, PID of the host task, emulating this guest CPU.
```

```
TSC2NSEC: id 14, size 16

  The TSC2NSEC option stores information, used to convert TSC events timestamps to nanoseconds.

  The format of the TSC2NSEC option data is:

     <4 bytes> unsigned integer, time multiplier.

     <4 bytes> unsigned integer, time shift.

     <8 bytes> unsigned long long integer, time offset.
```

```
HEADER_INFO: id 16, size 8

  The HEADER_INFO option data is:

    <8 bytes> long long unsigned integer, offset into the trace file where the HEADER INFO

    section is located
```

```
FTRACE_EVENTS: id 17, size 8

  The FTRACE_EVENTS option data is:

    <8 bytes> long long unsigned integer, offset into the trace file where the

    FTRACE EVENT FORMATS section is located.
```

```
EVENT_FORMATS: id 18, size 8

  The EVENT_FORMATS option data is:

    <8 bytes> long long unsigned integer, offset into the trace file where the EVENT FORMATS

    section is located.
```

```
KALLSYMS: id 19, size 8

  The KALLSYMS option data is:

    <8 bytes> long long unsigned integer, offset into the trace file where the KALLSYMS

    section is located.
```

```
PRINTK: id 20, size 8

  The PRINTK option data is:

    <8 bytes> long long unsigned integer, offset into the trace file where the TRACE_PRINTK

    section is located.
```

```
CMDLINES: id 21, size 8

  The CMDLINES option data is:

    <8 bytes> long long unsigned integer, offset into the trace file where the

    SAVED COMMAND LINES section is located.
```

```
BUFFER_TEXT: id 22, size

  The BUFFER_LAT option describes the latency trace data saved in the file. The format

  of the BUFFER_LAT data is:

    <8 bytes> long long unsigned integer, offset in the trace file where the

    BUFFER LATENCY section is located, containing latency trace data.

    <string> a null terminated ASCII string, name of the trace instance. Empty string ""

    is saved as name of the top instance.

    <string> a null terminated ASCII string, trace clock used for events timestamps in

    this trace instance.
```

## HEADER INFO SECTION

```
Section ID: 16
```

```
The first 12 bytes of the section, after the section header, contain the string:
```

```
"header_page\0"
```

```
The next 8 bytes are a 64-bit word containing the size of the
page header information stored next.
```

```
The next set of data is of the size read from the previous 8 bytes,
and contains the data retrieved from debugfs/tracing/events/header_page.
```

```
Note: The size of the second field \fBcommit\fR contains the target
kernel long size. For example:
```

```
field: local_t commit;        offset:8;       \fBsize:8;\fR   signed:1;
```

```
shows the kernel has a 64-bit long.
```

```
The next 13 bytes contain the string:
```

```
"header_event\0"
```

```
The next 8 bytes are a 64-bit word containing the size of the
event header information stored next.
```

```
The next set of data is of the size read from the previous 8 bytes
and contains the data retrieved from debugfs/tracing/events/header_event.
```

```
This data allows the trace-cmd tool to know if the ring buffer format
of the kernel made any changes.
```

## FTRACE EVENT FORMATS SECTION

```
Section ID: 17
```

```
Directly after the section header comes the information about
the Ftrace specific events. These are the events used by the Ftrace plugins
and are not enabled by the event tracing.
```

```
The next 4 bytes contain a 32-bit word of the number of Ftrace event
format files that are stored in the file.
```

```
For the number of times defined by the previous 4 bytes is the
following:
```

```
8 bytes for the size of the Ftrace event format file.
```

```
The Ftrace event format file copied from the target machine:
debugfs/tracing/events/ftrace/<event>/format
```

## EVENT FORMATS SECTION

```
Section ID: 18
```

```
Directly after the section header comes the information about
the event layout.
```

```
The next 4 bytes are a 32-bit word containing the number of
event systems that are stored in the file. These are the
directories in debugfs/tracing/events excluding the \fBftrace\fR
directory.
```

```
For the number of times defined by the previous 4 bytes is the
following:
```

```
A null-terminated string containing the system name.
```

```
4 bytes containing a 32-bit word containing the number
of events within the system.
```

```
For the number of times defined in the previous 4 bytes is the
following:
```

```
8 bytes for the size of the event format file.
```

```
The event format file copied from the target machine:
debugfs/tracing/events/<system>/<event>/format
```

## KALLSYMS SECTION

```
Section ID: 19
```

```
Directly after the section header comes the information of the mapping
of function addresses to the function names.
```

```
The next 4 bytes are a 32-bit word containing the size of the
data holding the function mappings.
```

```
The next set of data is of the size defined by the previous 4 bytes
and contains the information from the target machine's file:
/proc/kallsyms
```

## TRACE_PRINTK SECTION

```
Section ID: 20
```

```
If a developer used trace_printk() within the kernel, it may
store the format string outside the ring buffer.
This information can be found in:
debugfs/tracing/printk_formats
```

```
The next 4 bytes are a 32-bit word containing the size of the
data holding the printk formats.
```

```
The next set of data is of the size defined by the previous 4 bytes
and contains the information from debugfs/tracing/printk_formats.
```

## SAVED COMMAND LINES SECTION

```
Section ID: 21
```

```
Directly after the section header comes the information mapping
a PID to a process name.
```

```
The next 8 bytes contain a 64-bit word that holds the size of the
data mapping the PID to a process name.
```

```
The next set of data is of the size defined by the previous 8 bytes
and contains the information from debugfs/tracing/saved_cmdlines.
```

## BUFFER FLYRECORD SECTION

```
This section contains flyrecord tracing data, collected in one trace instance.
The data is saved per CPU. Each BUFFER FLYRECORD section has a corresponding BUFFER
option, containing information about saved CPU's trace data. Padding is placed between
the section header and the CPU data, placing the CPU data at a page aligned (target page)
position in the file.
```

```
This data is copied directly from the Ftrace ring buffer and is of the
same format as the ring buffer specified by the event header files
loaded in the header format file.
```

```
The trace-cmd tool will try to \fBmmap(2)\fR the data page by page with the
target's page size if possible. If it fails to mmap, it will just read the
data instead.
```

BUFFER TEXT SECTION

```
.ft C

  This section contains latency tracing data, ASCII text taken from the

  target's debugfs/tracing/trace file.
STRINGS SECTION
.ft
```

```
All strings from trace file metadata are stored in string section in the file. The section
contains a list of NULL terminated ASCII strings. An ID of the string is used in the file
meta data, which is the offset of the actual string into the string section. Strings can be stored
into multiple string sections in the file.
```

## SEE ALSO
trace-cmd(1), trace-cmd-record(1), trace-cmd-report(1), trace-cmd-start(1), trace-cmd-stop(1), trace-cmd-extract(1), trace-cmd-reset(1), trace-cmd-split(1), trace-cmd-list(1), trace-cmd-listen(1), trace-cmd.dat(5)

## AUTHOR
Written by Steven Rostedt, <rostedt@goodmis.org[1]>

## RESOURCES
https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/

## COPYING
Copyright (C) 2010 Red Hat, Inc. Free use of this software is granted under the terms of the GNU Public License (GPL).

## NOTES
1.

rostedt@goodmis.org

mailto:rostedt@goodmis.org


trickled.conf

package: trickle

title: trickled.conf(5)

text:
# trickled.conf(5)

## NAME
trickled.conf — format of the configuration file used by trickled(8).

## DESCRIPTION
The configuration file format is quite simple. Sections are delimited by square brackets:

[Section]

And options within brackets sections are simple key value pairs:

Option = Value

## OPTIONS
Per-application customizable variables are specified within sections with section names matching the application name. The options are:

Priority

Sets the priority of the application, see trickled(8) for details.

Time-Smoothing

Sets the time smoothing parameter of the application, see trickled(8) for an details.

Length-Smoothing

Sets the length smoothing parameter of the application, see trickled(8) for details.

## EXAMPLES

```
[ssh]
Priority = 1
Time-Smoothing = 0.1
Length-Smoothing = 2
[ftp]
Priority = 8
Time-Smoothing = 5
Length-Smoothing = 20
```

## SEE ALSO
trickle(1), syslog(3), netintro(4)

## AUTHORS
trickled.conf has been developed by Marius Aamodt Eriksen ⟨marius@monkey.org⟩.


tcsd.conf

package: trousers

title: tcsd.conf(5)

text:
# tcsd.conf(5)

TCG Software Stack

## NAME
tcsd.conf - configuration file for the trousers TCS daemon.

## DESCRIPTION
This file, by default /etc/tcsd.conf is read by the trousers TCSD daemon, tcsd (see tcsd(8)). The tcsd.conf file that is installed by trousers contains all the default options, commented out.

## OPTIONS
port The port that TCSD will listen on for connections, local and remote, from applications.

num_threads The maximum number of threads that the TCSD will spawn simultaneously to service applications. After num_threads threads have been spawned, any application that attempts to connect to the TCSD will receive an error.

system_ps_file The location of the system persistent storage file. The system persistent storage file holds keys and data across restarts of the TCSD and system reboots.

firmware_log_file Path to the file containing the current firmware PCR event log data. The interface to this log is usually provided by the TPM device driver.

kernel_log_file Path to the file containing the current kernel PCR event log data. By default, this data will be parsed in the format provided by the Integrity Measurement Architecture LSM.

firmware_pcrs A list of PCR indices that are manipulated only by the system firmware and therefore are not extended or logged by the TCSD. Applications that call Tcsi_PcrExtend on PCRs listed here will receive an error.

kernel_pcrs A list of PCR indices that are manipulated only by the kernel and therefore are not extended or logged by the TCSD. Applications that call Tcsi_PcrExtend on PCRs listed here will receive an error.

platform_cred Path to the platform credential for your TPM. Your TPM manufacturer may have provided you with a set of credentials (certificates) that should be used when creating identities using your TPM. When a user of your TPM makes an identity, this credential will be encrypted as part of that process. See the 1.1b TPM Main specification section 9.3 for information on this process.

conformance_cred Path to the conformance credential for your TPM. Your TPM manufacturer may have provided you with a set of credentials (certificates) that should be used when creating identities using your TPM. When a user of your TPM makes an identity, this credential will be encrypted as part of that process. See the 1.1b TPM Main specification section 9.3 for information on this process.

endorsement_cred Path to the endorsement credential for your TPM. Your TPM manufacturer may have provided you with a set of credentials (certificates) that should be used when creating identities using your TPM. When a user of your TPM makes an identity, this credential will be encrypted as part of that process. See the 1.1b TPM Main specification section 9.3 for information on this process.

remote_ops A list of TCS commands which will be allowed to be executed on this machine's TCSD by TSP's on non-local hosts (over the internet). By default, access to all operations is denied.

host_platform_class Determines the TCG specification of the host's platform class. This refers to one of the specifications contained in the TCG web site. The default is PC specification version 1.2 .

all_platform_classes Specifies all the TCG defined platforms associated with the host platform. The host_platform_class must not be defined here. By default, all platforms but the host platform are associated.

## EXAMPLE

```
port = 30003
num_threads = 10
system_ps_file = /usr/local/var/tpm/system.data
firmware_log_file = /proc/tpm/firmware_events
kernel_log_file = /proc/tcg/measurement_events
firmware_pcrs = 0,1,2,3,4,5,6,7
kernel_pcrs = 10,11
platform_cred = /usr/local/var/lib/tpm/platform.cert
conformance_cred = /usr/local/var/lib/tpm/conformance.cert
endorsement_cred = /usr/local/var/lib/tpm/endorsement.cert
remote_ops = create_key,random
host_platform_class = server_12
all_platform_classes = pc_11,pc_12,mobile_12
```

## SEE ALSO
tcsd(8)

## AUTHOR
Kent Yoder

## REPORTING BUGS
Report bugs to <trousers-tech@lists.sf.net>


tqsl

package: trustedqsl

title: tqsl(5)

text:
# tqsl(5)

## NAME
TQSL - digitally sign amateur radio contact logs

## SYNOPSIS
tqsl -i [certificate-file]...

tqsl [OPTIONS] [log-file]...

## DESCRIPTION
TrustedQSL is a file format and set of procedures that is used to send digitally signed QSL information (logs of contacts between amateur radio operators). One notable service that makes use of TrustedQSL is ARRL's Logbook of the World.

The tqsl program is used to digitally sign contact log files using a digital certificate. It is also used to generate requests for digital certificates and to store the resulting received digital certificates. (Certificates used to be handled by a separate program, tqslcert, but all functions are now handled by tqsl).

This manual page briefly documents the tqsl program. Complete documentation is also available:

tqsl: file:///usr/share/TrustedQSL/help/tqslapp/main.htm

## OPTIONS
tqsl accepts these command line options:

-b begin_date and -e end_date

Supply a start date and end date for QSOs to be signed. If present, any QSOs before the begin date will be ignored, and any after the end date will be ignored. If either begin or end are omitted, then the corresponding limit is ignored. You should specify -d with this option to suppress the normal date range dialog as these options will override the user-specified dates if given.

-d

Suppress date-range dialog. If present, the QSO date-range dialog will not be shown for files that follow this option on the command line.

-l location_name

Selects an existing station location. This location will be used for the commands that follow. If the station location doesn't exist, tqsl will just exit.

-o output_file

Writes the resulting signed log file to output_file instead of a default name based on the input log-file name.

-s

Add or edit station location. If there is a preceding -l option the specified location will be edited. If there is no preceding -l option, a new station location is being added.

-x (or) -q

Exit tqsl. If this argument is used it should be the last one on the command line. If this argument is not present, tqsl will begin normal operation after successfully processing all command-line arguments.

-u

Upload log file. If this argument is used, the input files will be signed then automatically uploaded to the Logbook of the World web site for processing.

-v

Display the version number of tqsl and exit.

-i filename

Import a certificate - either a signed response (.tq6) or a certificate stored with a private key in PKCS#12 format (.p12).

-t filename

Open a diagnostic trace file at startup. This file will log internal TQSL function calls for debugging purposes.

log-files

Any command-line parameter that is not an option or an option's argument will be treated as the name of a log file (ADIF or Cabrillo) to be signed. The resulting signed file (.tq8) will be placed in the same directory as the log file, overwriting any existing .tq8 file of the same name. (Note: If this option is not preceded by a -l option that selects the station location to be used for signing, the Select Station Location for Signing dialog will be presented.) File names that contain spaces or other shell-special characters should be quoted in a manner suitable for the operating system and shell that's being used. If -u is used, the signed log is not saved to disk but is instead uploaded and submitted to Logbook of the World. N.B.: If the private key needed to sign a log is protected by a password, the user will be prompted to supply that password for each file being signed.

## AUTHOR
trustedqsl was written by "American Radio Relay League, Inc." and the TrustedQSL authors. Please see the AUTHORS.txt file in the source distribution for a list of contributors.

This manual page was originally prepared by Kamal Mostafa <kamal@whence.com>, for the Debian project (and may be used by others).


ts.conf

package: tslib

title: ts.conf(5)

text:
# ts.conf(5)

## NAME
ts.conf - Configuration file for tslib, controlling touch screens for embedded devices.

## DESCRIPTION
The idea of tslib is to have a core library that provides standard services, and a set of plugins to manage the conversion and filtering as needed.

The plugins for a particular touchscreen are loaded automatically by the library under the control of a static configuration file, /etc/ts.conf. /etc/ts.conf gives the library basic configuration information. Each line specifies one module, and the parameters for that module. The modules are loaded in order, with the first one processing the touchscreen data first. For example:

```
  module_raw input

  module variance delta=30

  module dejitter delta=100

  module linear

```

## ENVIRONMENT VARIABLES
Latest versions of the Xorg tslib input driver use hal to configure the touchscreen within Xorg. Environment variables are only needed for the tslib commands.

TSLIB_TSDEVICE

If the default touchscreen device cannot be found, set the TSLIB_TSDEVICE environment variable to the touchscreen device to use. Default when using ts_setup(): We try to open /dev/input/ts, /dev/input/touchscreen and /dev/touchscreen/ucb1x00 and on Linux, we then scan /dev/input/event* for the first device with property INPUT_PROP_DIRECT.

TSLIB_CONSOLEDEVICE

Tslib default console device. Default: /dev/tty

TSLIB_CALIBFILE

Stores calibration data obtained using ts_calibrate. Default: /etc/pointercal

TSLIB_CONFFILE

Set a different location for the ts.conf configuration file itself. Default; /etc/ts.conf.

TSLIB_FBDEVICE

Framebuffer device to use for the touchscreen support. Default: /dev/fb0.

TSLIB_PLUGINDIR

Plugin directory for tslib. Default: /usr/lib/$triplet/ts0/ where triplet is the MultiArch path, e.g. arm-linux-gnueabi.

## MODULE PARAMETERS
dejitter

Removes jitter on the X and Y co-ordinates. This is achieved by applying a weighted smoothing filter. The latest samples have most weight; earlier samples have less weight. This allows one to achieve 1:1 input->output rate.

•delta Squared distance between two samples ((X2-X1)^2 + (Y2-Y1)^2) that defines the quick motion threshold. If the pen moves quick, it is not feasible to smooth pen motion, besides quick motion is not precise anyway; so if quick motion is detected the module just discards the backlog and simply copies input to output.

linear

Linear scaling module, primarily used for conversion of touch screen co-ordinates to screen co-ordinates.

•rot Rotation of touch coorinates. 0=no, 1=CW, 2=UD, 3=CCW. Default: the screen-rotation that was used with ts_calibrate (-r option).

•xyswap Interchange the X and Y co-ordinates -- no longer used or needed if the new linear calibration utility ts_calibrate is used.

•pressure_offset Offset applied to the pressure value. Default: 0.

•pressure_mul Factor to multiply the pressure value with. Default: 1.

•pressure_div Value to divide the pressure value by. Default: 1.

iir

Infinite impulse response filter. Similar to dejitter, this is a smoothing filter to remove low-level noise. There is a trade-off between noise removal (smoothing) and responsiveness. The parameters N and D specify the level of smoothing in the form of a fraction (N/D).

•N numerator of the smoothing fraction. Default: 0.

•D denominator of the smoothing fraction. Default: 1.

pthres

Pressure threshold filter. Given a release is always pressure 0 and a press is always >= 1, this discards samples below / above the specified pressure threshold.

•pmin Minimum pressure value for a sample to be valid. Default: 1.

•pmax Maximum pressure value for a sample to be valid. Default: INT_MAX.

debounce

Simple debounce mechanism that drops input events for the specified time after a touch gesture stopped.

•drop_threshold drop events up to this number of milliseconds after the last release event. Default: 0.

skip

Skip nhead samples after press and ntail samples before release. This should help if for the device the first or last samples are unreliable.

•nhead Number of events to drop after pressure. Default: 1.

•ntail Number of events to drop before release. Default: 1.

median

Similar to what the variance filter does, the median filter suppresses spikes in the gesture.

•depth Number of samples to apply the median filter to. Default: 3.

invert

Invert values in X and/or Y direction around a given value.

•x0 X-axis (horizontal) value around which to invert. Default: 0.

•y0 Y-axis (horizontal) value around which to invert. Default: 0.

lowpass

simple exponential averaging lowpass filter

•factor floating point values betwenn 0 and 1. Default: 0.4.

•threshold x or y minimum distance between two samples to start applying the filter. Default: 2.

evthres

Number of samples needed from the device after considered a valid touch. This filter will drop a tapping when too little samples are between "down" and "up".

•N Minimum number of events needed between "down" and "up". Default: 5.

variance

Tries to do it's best in order to filter out random noise coming from touchscreen ADCs. This is achieved by limiting the sample movement speed to some value (e.g. the pen is not supposed to move quicker than some threshold). This is a greedy filter, e.g. it gives less samples on output than receives on input. There is no multitouch support for this filter.

•delta Set the squared distance in touchscreen units between previous and current pen position (e.g. (X2-X1)^2 + (Y2-Y1)^2). This defines the criteria for determining whenever two samples are near or far to each other.

If the distance between previous and current sample is far, the sample is marked as potential noise. This doesn't mean yet that it will be discarded; if the next reading will be close to it, this will be considered just a regular quick motion event, and it will sneak to the next layer. Also, if the sample after the potential noise is far from both previously discussed samples, this is also considered a quick motion event and the sample sneaks into the output stream.

hardware support

On Linux, use the module_raw input if you can. The other raw access modules are device specific userspace drivers. If you need one of those, enable it explicitly when building tslib. The list of modules enabled by default might shrink in the future. module_raw input supports multitouch (MT) too.

module_raw

supported devices

interface

platforms

MT

how to enable

input

all with Linux evdev drivers

any (driver) /dev/input/

Linux, FreeBSD

yes

enabled by default

arctic2

IBM Arctic II

.

Linux, BSD, Hurd, Haiku

no

--enable-arctic2

collie

Sharp Zaurus SL-5000d/SL-5500

.

Linux, BSD, Hurd, Haiku

no

--enable-collie

corgi

Sharp Zaurus SL-C700

.

Linux, BSD, Hurd, Haiku

no

--enable-corgi

dmc_dus3000

DMC DUS Series (DUS3000, ...)

UART

Linux

no

--enable-dmc_dus3000

dmc

DMC (others)

.

Linux, BSD, Hurd, Haiku

no

--enable-dmc

galax

eGalax 100, 112, 210

any (driver)

Linux, BSD

no

--enable-galax

h3600

Compaq IPAQ

.

Linux, BSD, Hurd, Haiku

no

--enable-h3600

mk712

Hitachi Webpad

.

Linux, BSD, Hurd, Haiku

no

--enable-mk712

tatung

Tatung Webpad

.

Linux, BSD, Hurd, Haiku

no

--enable-tatung

touchkit

Touchkit SAT4000UR

RS232

Linux, BSD, Hurd

no

enabled by default

ucb1x00

UCB1x00 Touchscreens

.

Linux, BSD, Hurd, Haiku

no

--enable-ucb1x00

waveshare

Waveshare Touchscreens

/dev/hidrawX

Linux

no

enabled by default

cy8mrln_palmpre

in Palm Pre/Pre Plus/Pre 2

.

Linux

no

--enable-cy8mrln-palmpre

one_wire_ts_input

FriendlyARM one-wire touch screen

.

Linux

no

--enable-one-wire-ts-input

input_evdev

Linux evdev drivers (libevdev)

.

Linux

yes

--enable-input-evdev

## SEE ALSO
ts_calibrate(1), ts_test(1), ts_test_mt(1)


tsocks.conf

package: tsocks

title: tsocks.conf(5)

summary: configuration file for tsocks(8)

text:
# tsocks.conf(5)

## NAME
tsocks.conf - configuration file for tsocks(8)

## OVERVIEW
The configuration for tsocks can be anything from two lines to hundreds of lines based on the needs at any particular site. The basic idea is to define any networks the machine can access directly (i.e without the use of a SOCKS server) and define one or many SOCKS servers to be used to access other networks (including a 'default' server).

Local networks are declared using the 'local' keyword in the configuration file. When applications attempt to connect to machines in networks marked as local tsocks will not attempt to use a SOCKS server to negotiate the connection.

Obviously if a connection is not to a locally accessible network it will need to be proxied over a SOCKS server. However, many installations have several different SOCKS servers to be used to access different internal (and external) networks. For this reason the configuration file allows the definition of

Paths are declared as blocks in the configuration file. That is, they begin with a 'path {' line in the configuration file and end with a '}' line. Inside this block directives should be used to declare a SOCKS server (as documented later in this manual page) and 'reaches' directives should be used to declare networks and even destination ports in those networks that this server should be used to reach. N.B Each path MUST define a SOCKS server and contain one or more 'reaches' directives.

SOCKS server declaration directives that are not contained within a 'path' block define the default SOCKS server. If tsocks needs to connect to a machine via a SOCKS server (i.e it isn't a network declared as 'local') and no 'path' has declared it can reach that network via a 'reaches' directive this server is used to negotiate the connection.

## CONFIGURATION SYNTAX
The basic structure of all lines in the configuration file is:

<directive> = <parameters>

The exception to this is 'path' blocks which look like:

path { <directive> = <parameters>

}

Empty lines are ignored and all input on a line after a '#' character is ignored.

### DIRECTIVES
The following directives are used in the tsocks configuration file:

server

The IP address of the SOCKS server (e.g "server = 10.1.4.253"). Only one server may be specified per path block, or one outside a path block (to define the default server). Unless --disable-hostnames was specified to configure at compile time the server can be specified as a hostname (e.g "server = socks.nec.com")

server_port

The port on which the SOCKS server receives requests. Only one server_port may be specified per path block, or one outside a path (for the default server). This directive is not required if the server is on the standard port (1080).

server_type

SOCKS version used by the server. Versions 4 and 5 are supported (but both for only the connect operation). The default is 4. Only one server_type may be specified per path block, or one outside a path (for the default server). You can use the inspectsocks utility to determine the type of server, see the 'UTILITIES' section later in this manual page.

default_user

This specifies the default username to be used for username and password authentication in SOCKS version 5. In order to determine the username to use (if the socks server requires username and password authentication) tsocks first looks for the environment variable TSOCKS_USERNAME, then looks for this configuration option, then tries to get the local username. This option is not valid for SOCKS version 4 servers. Only one default_user may be specified per path block, or one outside a path (for the default server)

default_pass

This specified the default password to be used for username and password authentication in SOCKS version 5. In order to determine the password to use (if the socks server requires username and password authentication) tsocks first looks for the environment variable TSOCKS_PASSWORD, then looks for this configuration option. This option is not valid for SOCKS version 4 servers. Onle one default_pass may be specified per path block, or one outside a path (for the default server)

local

An IP/Subnet pair specifying a network which may be accessed directly without proxying through a SOCKS server (e.g "local = 10.0.0.0/255.0.0.0"). Obviously all SOCKS server IP addresses must be in networks specified as local, otherwise tsocks would need a SOCKS server to reach SOCKS servers.

reaches

This directive is only valid inside a path block. Its parameter is formed as IP[:startport[-endport]]/Subnet and it specifies a network (and a range of ports on that network) that can be accessed by the SOCKS server specified in this path block. For example, in a path block "reaches = 150.0.0.0:80-1024/255.0.0.0" indicates to tsocks that the SOCKS server specified in the current path block should be used to access any IPs in the range 150.0.0.0 to 150.255.255.255 when the connection request is for ports 80-1024.

## UTILITIES
tsocks comes with two utilities that can be useful in creating and verifying the tsocks configuration file.

inspectsocks

inspectsocks can be used to determine the SOCKS version that a server supports. Inspectsocks takes as its arguments the ip address/hostname of the SOCKS server and optionally the port number for socks (e.g 'inspectsocks socks.nec.com 1080'). It then inspects that server to attempt to determine the version that server supports.

validateconf

validateconf can be used to verify the configuration file. It checks the format of the file and also the contents for errors. Having read the file it dumps the configuration to the screen in a formatted, readable manner. This can be extremely useful in debugging problems. validateconf can read a configuration file from a location other than the location specified at compile time with the -f <filename> command line option.

Normally validateconf simply dumps the configuration read to the screen (in a nicely readable format), however it also has a useful 'test' mode. When passed a hostname/ip on the command line like -t <hostname/ip>, validateconf determines which of the SOCKS servers specified in the configuration file would be used by tsocks to access the specified host.

## SEE ALSO
tsocks(8)

## AUTHOR
Shaun Clowes (delius@progsoc.uts.edu.au)

## COPYRIGHT
Copyright 2000 Shaun Clowes

tsocks and its documentation may be freely copied under the terms and conditions of version 2 of the GNU General Public License, as published by the Free Software Foundation (Cambridge, Massachusetts, United States of America).

This documentation is based on the documentation for logwrites, another shared library interceptor. One line of code from it was used in tsocks and a lot of the documentation :) logwrites is by adam@yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com pub/dist/pkg


tuned-main.conf

package: tuned

title: tuned-main.conf(5)

text:
# tuned-main.conf(5)

## NAME
tuned-main.conf - TuneD global configuration file

## SYNOPSIS
/etc/tuned/tuned-main.conf

## DESCRIPTION
This man page documents format of the TuneD global configuration file. The tuned-main.conf file uses the ini-file format.

daemon=BOOL

This defines whether TuneD will use daemon or not. It is boolean value. It can be True or 1 if the daemon is enabled and False or 0 if disabled. It is not recommended to disable daemon, because many functions will not work without daemon, e.g. there will be no D-Bus, no settings rollback, no hotplug support, no dynamic tuning, ...

dynamic_tuning=BOOL

This defines whether the dynamic tuning is enabled. It is boolean value. It can be True or 1 if the dynamic tuning is enabled and False or 0 if disabled. In such case only the static tuning will be used. Please note if it is enabled here, it is still possible to individually disable it in plugins. It is only applicable if daemon is enabled.

sleep_interval=INT

TuneD daemon is periodically waken after INT seconds and checks for events. By default this is set to 1 second. If you have Python 2 interpreter with applied patch from Red Hat Bugzilla #917709 this controls responsiveness time of TuneD to commands (i.e. if you request profile switch, it may take up to 1 second until TuneD reacts). Increase this number for higher responsiveness times and more power savings (due to lower number of wakeups). In case you have unpatched Python 2 interpreter, this settings will have no visible effect, because the interpreter will poll 20 times per second. It is only applicable if daemon is enabled.

update_interval=INT

Update interval for dynamic tuning (in seconds). TuneD daemon is periodically waken after INT seconds, updates its monitors, calculates new tuning parameters for enabled plugins and applies the changes. Plugins that have disabled dynamic tuning are not processed. By default the INT is set to 10 seconds. TuneD daemon doesn't periodically wake if dynamic tuning is globally disabled (see dynamic_tuning) or this setting set to 0. This must be multiple of sleep_interval. It is only applicable if daemon is enabled.

recommend_command=BOOL

This controls whether recommend functionality will be enabled or not. It is boolean value. It can be True or 1 if the recommend command is enabled and False or 0 if disabled. If disabled recommend command will be not available in CLI, TuneD will not parse recommend.conf and will return one hardcoded profile (by default balanced). It is only applicable if daemon is enabled. By default it's set to True.

reapply_sysctl=BOOL

This controls whether to reapply sysctl settings from /run/sysctl.d/*.conf, /etc/sysctl.d/*.conf and /etc/sysctl.conf after TuneD sysctl settings are applied. These are locations supported by sysctl --system, excluding those that contain sysctl configuration files provided by system packages. So if reapply_sysctl is set to True or 1, TuneD sysctl settings will not override user-provided system sysctl settings. If set to False or 0, TuneD sysctl settings will override system sysctl settings. By default it's set to True.

default_instance_priority=INT

Default instance (unit) priority. By default it's 0. Each unit has a priority which is by default preset to the INT. It can be overridden in the TuneD profile by the priority option. TuneD units are processed in order defined by their priorities, i.e. unit with the lowest number is processed as the first.

## EXAMPLE

```
  no_daemon = 0

  dynamic_tuning = 1

  sleep_interval = 1

  update_interval = 10

  recommend_command = 0

  reapply_sysctl = 1

  default_instance_priority = 0
```

## FILES
/etc/tuned/tuned-main.conf

## SEE ALSO
tuned(8)

## AUTHOR
Written by Jaroslav Škarvada <jskarvad@redhat.com>.

## REPORTING BUGS
Report bugs to https://bugzilla.redhat.com/.


tuned.conf

title: tuned.conf(5)

text:
# tuned.conf(5)

## NAME
tuned.conf - TuneD profile definition

## DESCRIPTION
This man page documents format of TuneD 2.0 profile definition files. The profile definition is stored in /etc/tuned/<profile_name>/tuned.conf or in /usr/lib/tuned/<profile_name>/tuned.conf file where the /etc/tuned/ directory has higher priority.

The tuned.conf configures the profile and it is in ini-file format.

## MAIN SECTION
The main section is called "[main]" and can contain following options:

include=

Includes a profile with the given name. This allows you to base a new profile on an already existing profile. In case there are conflicting parameters in the new profile and the base profile, the parameters from the new profile are used.

## PLUGINS
Every other section defines one plugin. The name of the section is used as name for the plugin and is used in logs to identify the plugin. There can be only one plugin of particular type tuning particular device. Conflicts are by default fixed by merging the options of both plugins together. This can be changed by "replace" option.

Every plugin section can contain following sections:

type=

Plugin type. Currently there are following upstream plugins: audio, bootloader, cpu, disk, eeepc_she, modules, mounts, net, script, scsi_host, selinux, scheduler, sysctl, sysfs, systemd, usb, video, vm. This list may be incomplete. If you installed TuneD through RPM you can list upstream plugins by the following command: rpm -ql tuned | grep 'plugins/plugin_.*.py$' Check the plugins directory returned by this command to see all plugins (e.g. plugins provided by 3rd party packages).

devices=

Comma separated list of devices which should be tuned by this plugin instance. If you omit this option, all found devices will be tuned.

replace=1

If there is conflict between two plugins (meaning two plugins of the same type are trying to configure the same devices), then the plugin defined as last replaces all options defined by the previously defined plugin.

Plugins can also have plugin related options.

## EXAMPLE

```
[main]
# Includes plugins defined in "included" profile.
include=included
# Define my_sysctl plugin
[my_sysctl]
type=sysctl
# This plugin will replace any sysctl plugin defined in "included" profile
replace=1
# 256 KB default performs well experimentally.
net.core.rmem_default = 262144
net.core.wmem_default = 262144
# Define my_script plugin
# Both scripts (profile.sh from this profile and script from "included"
# profile) will be run, because if there is no "replace=1" option the
# default action is merge.
[my_script]
type=script
script=${i:PROFILE_DIR}/profile.sh
```

## SEE ALSO
tuned(8)

## AUTHOR
Written by Jan Kaluža <jkaluza@redhat.com>.

## REPORTING BUGS
Report bugs to https://bugzilla.redhat.com/.