etcnet-options

package: etcnet

title: etcnet-options(5)

text:
# etcnet-options(5)

## NAME
/etc/net interface options

## OPTIONS
Common options

TYPE

This option defines interface type. It is required, if interface type cannot be found from interface name and if DISABLED is not set.

DISABLED

Set to "yes" to ignore the interface. Note that setting DISABLED to "yes" in ifaces/default/options and having no "DISABLED=no" in interface-specific options file will effectively disable ALL interfaces.

BOOTPROTO

BOOTPROTO can be any of the following: static, dhcp, dhcp6, ipv4ll. static use ipv4address/ipv6address. It has the same meaning as 'none' in initscripts/net-scripts sense. If you don't want to assign any address to an interface, but still keep it up and running, you can just use 'static' and have no ipv4address file.

dhcp run DHCP client

ipv4ll run IPv4LL client, currently avahi-autoipd

dhcp6 run DHCPv6 client

Additional feature is multi-method configurations (methods can be delimited by ' ', ',' or '-':

dhcp-static try DHCP, if it fails, configure IPv4 static address(es). Implies static for IPv6.

dhcp6-static try DHCPv6, if it fails, configure IPv6 static address(es). Implies static for IPv4.

dhcp-ipv4ll same, but fallback to IPv4LL

dhcp-ipv4ll-static try DHCP, fallback to IPv4LL (very unlikely to fail), fallback to static

/etc/net will try to configure interface at the first succeeding method. Note that etcnet will process routes and rules despite of BOOTPROTO.

ONBOOT

Defines if the interface will be automatically brought up during system startup or 'service network start' invocation.

USE_HOTPLUG

If set to yes, iface will be skipped during boot. Note that standard hotplug calls /sbin/ifup and /sbin/ifdown. This should be changed to /etc/net/scripts/ifup-removable and /etc/net/scripts/ifdown-removable respectively, if you wish to use etcnet from hotplug.

USE_PCMCIA

Same for pcmcia_cs

CONFIG_IPV4, CONFIG_IPV6, CONFIG_IPX

These boolean options define, if you want to perform configuration of particular protocol or not.

CONFIG_QOS

This boolean function enables Linux QoS configuration. This topic is explained in etcnet-qos manpage.

CONFIG_DOT1X

This boolean option enables wired 802.1x authentication.

CONFIG_WIRELESS

This boolean option enables wireless extensions configuration.

CONFIG_FW

This boolean option enables firewall configuration. This topic is explained in README.firewall file.

KEEP_UP

If set to yes, an interface will not be set DOWN while ifdown is invoked. This can be suitable for loopback interfaces.

KEEP_DOWN

If set to yes, an interface will not be set UP, but configured. You are unlikely to need this option enabled.

DONT_FLUSH

IPv4/IPv6. Don't flush existing addresses from interface before assigning new ones. Also don't flush addresses on deconfiguration.

IFUP_CHILDREN

If set to yes, this variable will cause ifup call for all child (having current interface in their REQUIRES list) after the current interface is set up.

IFUP_PARENTS

If set to yes, this variable will cause ifup call for all parent (listed in current REQUIRES list) before the current interface is set up. Note: this will not work for ifplugd-controlled interfaces.

IFDOWN_CHILDREN

If set to yes, this variable will cause ifdown call for all child (having current interface in their REQUIRES list) before the current interface is shut down.

IFDOWN_PARENTS

If set to yes, this variable will cause ifdown call for all parent (listed in current REQUIRES list) after the current interface is shut down. Note: this will not work for ifplugd-controlled interfaces.

Ethernet options

MODULE

Kernel module name (or quoted list of names), which must be loaded before interface initialisation.

USE_IFPLUGD

A special configuration method. The interface will be created, but no configuration will be done until cable is plugged in. When ifplugd detects cable presence on the interface, it will run ifup-ifplugd to finish configuration. Values: no: don't use this feature yes: manage ifplugd for each such interface auto: same as 'yes', if ifplugd is available and the card supports link detection

PERSISTENT_IFPLUGD

Two operational modes are possible with USE_IFPLUGD=auto: persistent ifplugd (ifplugd will be run once and then only suspended/resumed when needed) and temporary ifplugd (ifplugd will be killed at ifdown and started at ifup each time). Default mode is to keep persistent ifplugd process.

IFPLUGD_EXTRA_ARGS

/etc/net will construct ifplugd arg list automatically, but you can add extra args with this option.

LINKDETECT

LINKDETECT option allows to avoid DHCP/IPv4LL timeout, if ethernet cable is not plugged in during startup. This feature requires ifplugstatus and is off by default, because not all network cards report correct link status. Possible values are: yes/no/auto. link status, LINKDETECT feature will take effect.

LINKDELAY

Some Ethernet interface modules require significant time to negotiate link parameters upon loading. Once the initial negitiation is complete, they indicate further link state changes correctly. This option specifies maximum number of seconds allowed for a module to report link absence before giving up and deciding, that the link is really absent. If the module reports link before timeout expires, it will be seen without spending all the time waiting.

MACADDR_WAITTIME

Some network card modules create network device first, then perform some initialization and after some time fill in MAC address data. Hotplug starts working immediately after the interface is created. If this variable is set to non-zero, /etc/net will wait for specified amount of 0.1 sec times for MAC address to become not 00:00:00:00:00:00. WARNING: THIS IS EXPERIMENTAL FEATURE !!!

IWCONFIG

Optional path to iwconfig.

WPA_SUPPLICANT

Optional path to wpa_supplicant.

WPA_DRIVER

Optional WPA driver name to pass to wpa_supplicant.

DHCP_CLIENT

Full path to DHCP client. Currently dhclient and dhcpcd are recognized and command-line options list built appropriately.

DHCP_TIMEOUT

Optional DHCP client timeout in seconds.

DHCP_ARGS

Optional additional DHCP client arguments.

DHCP_HOSTNAME

Possible values: 'localhost' (compute a valid hostname and send it to DHCP server with -h option); 'NONE' (don't send anything); any other string (send the string as a hostname with -h).

IP tunnels options

TUNTYPE

IP tunnel type: 'ipip' (default), 'gre' or 'sit'.

TUNLOCAL

Local tunnel endpoint.

TUNREMOTE

Remote tunnel endpoint.

TUNOPTIONS

Append whatever you want (TTL, GRE keys etc). Don't set 'dev' here.

HOST

Optional host interface. If set, this name will be used for 'dev' option.

IPSec tunnels options

At least one of cipher or digest must be configured.

CIPHERFILE and DIGESTFILE are searched in iface dir. If CIPHER is defined, CIPHERFILE must be defined too, same for DIGEST and DIGESTFILE.

IPSECADM

(Optional) location of ipsecadm.

TUNLOCAL

Local endpoint.

TUNREMOTE

Remote endpoint.

TUNSPI

SPI must be defined for an IPSec tunnel. SPI is a hexadecimal number, values less than 0x2000 are reserved.

CIPHER

Cipher name.

CIPHERFILE

Dipher file name.

DIGEST

Digest name.

DIGESTFILE

Digest file name.

HOST

"ipsecadm --nextdev" argument

VLAN options

HOST

Required parent iface name.

VID

Required VLAN ID.

VLAN_REORDER_HDR

This option allows changing the REORDER_HDR flag for each VLAN interface. The flag can be either "yes" or "no" and its meaning is described in vconfig manpage.

VXLAN options

HOST

Required parent iface name.

VNI

Required VXLAN Network Identifer (or VXLAN Segment Identifier).

LOCAL

Required source IP address to use in outgoing packets.

REMOTE

Specifies the unicast destination IP address to use in outgoing packets when the destination link layer address is not known in the VXLAN device forwarding database. This parameter cannot be specified with the group parameter.

GROUP

Specifies the multicast IP address to join. This parameter cannot be specified with the remote parameter.

DSTPORT

Specifies the UDP destination port to communicate to the remote VXLAN tunnel endpoint.

TTL

Specifies the TTL value to use in outgoing packets.

DVB options

DVBTYPE

This is a mandatory option. Currently supported values are: ss223 for SkyStar-2 rev. 2.3, ss226 for SkyStar-2 rev. 2.6, pentanet for Pent@NET, pentaval for Pent@VALUE

SkyStar-2 options

PID

SZAP

SZAP_ARGS

DVBNET

CHANNELS_CONF

For SkyStar cards you can override channels.conf location (default is channels.conf in the interface's configuration directory.

Pent@NET options

PENTANETT

pentanett location

PENTANET_CONF

Config file name.

Pent@VALUE options

PENTAVALT

pentavalt location

PENTAVAL_CONF

config file name

Bonding options

HOST

BONDMODE

Operation mode (optional). Possible values: 0 for round robin (default), 1 for active-backup, 2 for xor, 3 for broadcast, 4 for IEEE 802.3ad Dynamic link aggregation.

BONDOPTIONS

Additional options. This will have effect per interface. The list from modinfo bond is:

miimon:int: Link check interval in milliseconds

updelay:int: Delay before considering link up, in milliseconds

downdelay:int: Delay before considering link down, in milliseconds

use_carrier:int: Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default)

primary:string: Primary network device to use

lacp_rate:string: LACPDU tx rate to request from 802.3ad partner (slow/fast)

arp_interval:int: arp interval in milliseconds

arp_ip_target:string array (min = 1, max = 16): arp targets in n.n.n.n form

Bridge options

HOST

This variable must be defined for each bridge interface. This is a (quoted) space-separated list of slave ethernet interfaces combining the bridge. Don't forget to create configurations for the slave interfaces too.

BRIDGE_OPTIONS

Additional options. See ip-link(8) manpage for details.

PPP options

This section assumes knowledge of pppd(8) manpage.

PPPTYPE

PPP subtype. Valid types are: dialup, pptp, pppoe. pptp and pptp types will benefit from correctly set REQIURES and respectively HOST variables. dialup subtype will add 'modem' to pppd options list.

PPTP_SERVER

For "pptp" subtype you must specify hostname or IP address of PPtP server you connect to. Otherwise leave PPPTYPE=dialup.

HOST

pppoe client requires target interface name. You must specify it in the HOST variable, create-ppp will automatically construct correct pty option for pppd. This option is mandatory if PPPTYPE=pppoe.

PPPOE

Optional pppoe path.

PPPOE_EXTRA_OPTIONS

PPTP

Optional pptp-client path.

PPTP_EXTRA_OPTIONS

PPPD

pppd location, optional

PPPOPTIONS

Additional pppd args. Note that interface-specific options file will override PPPOPTIONS from options-ppp, not append. WARNING! NEVER set "persist maxfail 0" for an interface with ONBOOT=yes, otherwise your host risks hanging forever.

CHAT

chat location, optional

CHATOPTIONS

chat options (timeout, verbose mode etc)

PPPOPTIONSFILE

PPPINITCHAT

PPPCONNECTCHAT

PPPDISCONNECTCHAT

RESTORE_DEFAULTROUTE

pppd does not save default route for us. We could save and restore it with ip-up/ip-down, but this option will do the trick for us.

PPPTIMEOUT

Your PPP link will not hang for more seconds, than specified here. /etc/net will pass according lcp-echo-interval and lcp-echo-failure options to pppd, if this options is set.


title: euca2ools.ini(5)

summary: configuration for euca2ools

text:
# euca2ools.ini(5)

## NAME
euca2ools.ini — configuration for euca2ools

## DESCRIPTION
euca2ools.ini files are used to configure the euca2ools suite of command line tools. They store the locations of the services for the commands to contact, the security credentials to use to authenticate to them, and other configuration options as well.

## FILE FORMAT
euca2ools.ini is broken into a number of sections. Sections are denoted by section headers, which consist of section names surrounded by square braces. Within each section, an option is set by listing its name, an “=” sign, and its value. For example, the following enables debugging for all commands by setting the “debug” option in the “global” section to “true”:

```
[global]
debug = true
```

Most sections have user-defined names. Such a section's name is defined by a second word in its header. Named sections provide a means of choosing different configuration using the command line. For example, the following defines two regions with different URLs for their EC2 services that one can select using the --region command line option:

```
[region us-east-1]
ec2-url = https://ec2.us-east-1.amazonaws.com/

[region eu-west-1]
ec2-url = https://ec2.eu-west-1.amazonaws.com/
```

Named sections can contain “*” wildcards, which makes them act as fallbacks when options are not available in sections with more specific names that contain fewer wildcards. Sections with more specific names take precedence over those with less specific names. “*” sections function as defaults when the value for an option cannot be found anywhere else.

Named sections can also be organized into groups by choosing names for groups and prepending section names with them, separated by “:” characters. When combined with wildcards, this allows one to specify defaults for several sections at once and then override them as needed as in the following example:

```
[region aws:*]
certificate = /usr/share/euca2ools/certs/cert-ec2.pem
verify-ssl = true

[region aws:us-gov-west-1]
certificate = /usr/share/euca2ools/certs/cert-ec2-gov.pem
```

Finally, options in named sections may refer to other sections by using the use keyword followed by the section name to refer to. This differs from simply duplicating the option from the other section in that commands that are sensitive to the name of the section the option came from, such as those that use AWS signature version 4, will be able to determine which section an option originates from.

## REGION SELECTION
The --region option provided by most euca2ools commands allows one to control the user section and the region section those commands use to find configuration data by supplying it with a user name, a region name, or both in one of the following formats:

- --region REGION

- --region USER@

- --region USER@REGION

The EUCA_DEFAULT_REGION and AWS_DEFAULT_REGION environment variables work the same way, but with lower priority.

## OPTIONS

### Global section
The global section contains settings that affect all commands.

debug

When set to true, enable debugging for all commands. When set to color, enable debugging for all commands and additionally colorize debug output based on severity level.

default-region

The name of the region to use when no region is otherwise specified.

max-retries

The maximum number of times commands should retry their requests to the server before giving up. The default is 2.

timeout

The amount of time, in seconds, to wait for the server to respond to requests before giving up. The default is 30.

### User section
A user section contains information that is specific to an identity in the cloud, usually an IAM user.

account-id

The account's 12-digit ID number.

key-id

The user's access key ID to use for authentication. Access key IDs come paired with secret keys; the ID specified with this option must correspond to the secret key specified with the secret-key option.

secret-key

The user's secret key to use for authentication. Secret keys come paired with access key IDs; the secret key specified with this option must correspond to the access key ID specified with the key-id option.

certificate

The file name containing the user's signing certificate. This is used only by commands that bundle images: euca-bundle-and-upload-image(1), euca-bundle-image(1), euca-bundle-vol(1), euca-install-image(1), and euimage-install-pack(1).

private-key

The file name containing the private key for the user's signing certificate. This is used only by commands that bundle and unbundle images: euca-bundle-and-upload-image(1), euca-bundle-image(1), euca-bundle-vol(1), euca-download-and-unbundle(1), euca-install-image(1), euca-unbundle(1), and euimage-install-pack(1).

### Region section
A region section contains information that is specific to a cloud region, such as a Eucalyptus installation or an Amazon Web Services region.

SERVICE-url

The URL to use to contact the service with the name SERVICE. For a list of valid service names, see euca2ools(7).

user

The user section to use for this region when no other user is otherwise specified.

certificate

The file name containing the cloud's image-bundling certificate. This is used only by commands that bundle images: euca-bundle-and-upload-image(1), euca-bundle-image(1), euca-bundle-vol(1), euca-install-image(1), and euimage-install-pack(1).

s3-force-sigv4

Force commands that access the s3 service to use AWS signature version 4. The default is false.

s3-location-constraint

The location constraint needed to create buckets in the region's object storage service.

verify-ssl

Whether or not to verify the server's SSL certificates. The default is false.

vpn-stylesheet

The location of the XSLT stylesheet for euca-create-vpn-connection(1) or euca-describe-vpn-connections(1) to use to reformat VPN connection information. If the location is an HTTP or HTTPS URL it will be downloaded as needed. If it contains “{format}” that will be replaced with the desired format.

## NOTES
Commands that create access keys can format their output in the form of a euca2ools.ini file, simplifying the process of distributing access keys and URL information to users. This can replace the “eucarc” files generated by eucalyptus's ‘euca_conf --get-credentials’ command.

## FILES
euca2ools.ini configuration data are read from files in alphabetical order in the following locations:

- /etc/euca2ools/euca2ools.ini

- /etc/euca2ools/conf.d/*.ini

- ~/.euca/*.ini

In cases where the same option is defined in more than one file, the file that appears last in this list will take precedence.

## SEE ALSO
euca2ools(7)

## HISTORY
euca2ools.ini first appeared in euca2ools 3.0.


eudev-udev.conf

package: eudev

title: eudev-udev.conf(5)

text:
# eudev-udev.conf(5)

## NAME
udev.conf - Configuration for device event managing daemon

## SYNOPSIS
/etc/udev/udev.conf

## DESCRIPTION
udevd(8) expects its main configuration file at /etc/udev/udev.conf. It consists of a set of variables allowing the user to override default udev values. All empty lines or lines beginning with '#' are ignored. The following variables can be set:

udev_log

The log level. Valid values are the numerical syslog priorities or their textual representations: err, info and debug.

In addition, udevd can be configured by command-line options and the kernel command line (see udevd(8)).

## SEE ALSO
udevd(8), udev(7), udevadm(8)


exabgp.conf

package: exabgp

title: exabgp.conf(5)

text:
# exabgp.conf(5)

## NAME
exabgp.conf — Configuration file controlling the BGP configuration for exabgp(1).

## DESCRIPTION

### CONFIGURATION FILE SYNTAX

```
group <groupname> {
  // Most if not all the attributes under neighbor can be defined
  // at the group level as well, and the settings will be inherited
  // unless overridden in the neighbor section
  neighbor <ip-address> {
    description <text>;
    router-id <router-id>;
    local-address <ip-address>;
    local-as <asn>;
    peer-as <asn>;
    passive;
    hold-time <seconds>;
    md5-password <md5-secret>;
    ttl-security;
    group-updates;
    aigp <truthvalue>;
    route-refresh <truthvalue>;
    graceful-restart <...>;
    multi-session <truthvalue);
    add-path <path>;
    auto-flush <truthvalue>;
    adj-rib-out <truthvalue>;
    // Can also have the groups listed under group <gn> { } below:
    static {
    }
    flow {
    }
    l2vpn {
    }
    process {
    }
    family {
    }
    capability {
    }
    operational {
    }
  }
  static {
    route <ip-address>/<prefixlength> {
      next-hop <ip-address>; // only mandatory attribute
      origin ( IGP | EGP | INCOMPLETE );
      as-path [ <as-sequence-asn> | ( <as-set ) ];
      as-sequence
      med <med>;
      aigp <aigp>;
      local-preference <preference>;
      atomic-aggregate;
      aggregator <asn>:<ip-address>;
      path-information <ip-address>;
      community ( <community> | [ <community> <community> ... ] );
      large-community ( <large-community> | [ <large-community> <large-community> ... ] );
      originator-id <ip-address>;
      cluster-list ( <ip-address> | [ <ip-address> <ip-address> ... ] );
      extended-community ( <extended-community> |
			   [ <extended-community>
			     <extended-community> ... ] );
      split /<prefixlength>;
      label ( <label> | [ <label> <label> ... ] );
      rd  <route-distinguisher>;
      watchdog <watchdog-name>;
      bgp-prefix-sid ( [<label-index-value>] |
         [ <label-index-value>, [ ( <srgb-base_1>,<srgb-range_1> ), ... ] ]);
      withdraw;
    }
    // or alternatively
    route <ip-address>/<prefixlength> <attribute-sequence>;
    // where <attribute-sequence> is a sequence of
    // any of the attributes above
  }
  flow {
    route <route-name> {
      rd <route-distinguisher>;
      next-hop <ip-address>; // for redirect-to-nexthop
      match {
	// one or more match terms
        source <ip-address>/<prefixlength>;
        destination <ip-address>/<prefixlength>;
        port <portnumber>;
        source-port <portnumber>;
        destination-port <portnumber-expression>;
        protocol [ udp | tcp ]; // IPv4 only
        next-header [ udp | tcp ]; // IPv6 only
        tcp-flags [ fin | syn | rst | push | ack | urgent ];
        icmp-type [ echo-reply | echo-request | info-reply |
		    info-request | mask-reply | mask-request |
		    parameter-problem | redirect | router-advertisment |
		    router-solicit | source-quench | time-exceeded |
		    timestamp | timestamp-reply | unreachable ];
        icmp-code [ communication-prohibited-by-filtering |
		    destination-host-prohibited |
		    destination-host-unknown |
		    destination-network-unknown |
		    fragmentation-needed | host-precedence-violation |
		    ip-header-bad | network-unreachable |
		    network-unreachable-for-tos | port-unreachable |
		    redirect-for-host | redirect-for-network |
		    redirect-for-tos-and-host |
		    redirect-for-tos-and-net |
		    required-option-missing | source-host-isolated |
		    source-route-failed |
		    ttl-eq-zero-during-reassembly |
		    ttl-eq-zero-during-transit ];
        fragment [ not-a-fragment | dont-fragment | is-fragment |
		   first-fragment | last-fragment ];
	// fragment is IPv4 only, poorly tested
        dscp <dscp-value>;
        traffic-class <traffic-class>;
        packet-length <packet-length-expression>;
        flow-label <flow-label-expression>; // IPv6 only
      }
      then {
	// one action only
        accept;
        discard;
        rate-limit <ratelimit>;
        redirect ( <route-distinguisher> | <ip-address> );
        redirect-to-nexthop; // Ref. next-hop above
        redirect-to-nexthop-ietf <ip-address>;
        copy <ip-address>;
        mark <mark>;
        action ( sample | terminal | sample-terminal );
        community
        large-community
        extended-community
      }
    }
  }
  l2vpn {
    vpls <site-name> {
      next-hop <ip-address>;
      origin ( IGP | EGP | INCOMPLETE );
      as-path [ <as-sequence-asn> | ( <as-set ) ];
      med <med>;
      local-preference <preference>;
      community ( <community> | [ <community> <community> ... ] );
      large-community ( <large-community> | [ <large-community> <large-community> ... ] );
      originator-id <ip-address>;
      cluster-list [ <ip-address> <ip-address> ... ];
      extended-community ( <extended-community> |
			   [ <extended-community>
			     <extended-community> ... ] );
      rd <route-distinguisher>;
      withdraw;
      endpoint ( <vpls-endpoint> | <integer> );
      offset ( <block-offset> | <integer> );
      size ( <block-size> | <integer> );
      base ( <label-base> | <integer> );
      name <route-name>;
  }
  process {
    run <command> <args>;
  }
  family {
    all; // default, or a list of the below
    minimal; // use AFI/SAFI required to announce routes in config
    ipv4 unicast;
    ipv4 multicast;
    ipv4 nlri-mpls;
    ipv4 mpls-vpn;
    ipv4 flow;
    ipv4 flow-vpn;
    ipv6 unicast;
    ipv6 flow;
    ipv6 flow-vpn;
  }
  capability {
    graceful-restart <seconds>;
    asn4 ( enable | disable );
    add-path ( disable | send | receive | send/receive );
    multi-session ( enable | disable );
    operational ( enable | disable );
  }
  operational {
    // ??
  }
}
neighbor <ip-address> {
  // Attributes and sections as for under
  // group <groupname> { neighbor <neighbor> {
  // ref. above
}
```

Please note that multi-line sections really do need to be written as multiple lines: the first one ending in "{", and ending with a line with a "}" by itself.

## SEE ALSO
exabgp(1).


package: eza

title: eza_colors(5)

text:
# eza_colors(5)

## NAME
eza_colors — customising the file and UI colours of eza

## SYNOPSIS
The EZA_COLORS environment variable can be used to customise the colours that eza uses to highlight file names, file metadata, and parts of the UI.

You can use the dircolors program to generate a script that sets the variable from an input file, or if you don’t mind editing long strings of text, you can just type it out directly. These variables have the following structure:

•

A list of key-value pairs separated by `=', such as `*.txt=32'.

•

Multiple ANSI formatting codes are separated by `;', such as `*.txt=32;1;4'.

•

Finally, multiple pairs are separated by `:', such as `*.txt=32:*.mp3=1;35'.

The key half of the pair can either be a two-letter code or a file glob, and anything that’s not a valid code will be treated as a glob, including keys that happen to be two letters long.

For backwards compatibility EXA_COLORS environment variables is checked if EZA_COLORS is unset.

## EXAMPLES
EZA_COLORS="uu=0:gu=0"

Disable the “current user” highlighting

EZA_COLORS="da=32"

Turn the date column green

EZA_COLORS="Vagrantfile=1;4;33"

Highlight Vagrantfiles

EZA_COLORS="*.zip=38;5;125"

Override the existing zip colour

EZA_COLORS="*.md=38;5;121:*.log=38;5;248"

Markdown files a shade of green, log files a shade of grey

## LIST OF CODES
LS_COLORS can use these ten codes:

di

directories

ex

executable files

fi

regular files

pi

named pipes

so

sockets

bd

block devices

cd

character devices

ln

symlinks

or

symlinks with no target

EZA_COLORS can use many more:

oc

the permissions displayed as octal

ur

the user-read permission bit

uw

the user-write permission bit

ux

the user-execute permission bit for regular files

ue

the user-execute for other file kinds

gr

the group-read permission bit

gw

the group-write permission bit

gx

the group-execute permission bit

tr

the others-read permission bit

tw

the others-write permission bit

tx

the others-execute permission bit

su

setuid, setgid, and sticky permission bits for files

sf

setuid, setgid, and sticky for other file kinds

xa

the extended attribute indicator

sn

the numbers of a file’s size (sets nb, nk, nm, ng and nt)

nb

the numbers of a file’s size if it is lower than 1 KB/Kib

nk

the numbers of a file’s size if it is between 1 KB/KiB and 1 MB/MiB

nm

the numbers of a file’s size if it is between 1 MB/MiB and 1 GB/GiB

ng

the numbers of a file’s size if it is between 1 GB/GiB and 1 TB/TiB

nt

the numbers of a file’s size if it is 1 TB/TiB or higher

sb

the units of a file’s size (sets ub, uk, um, ug and ut)

ub

the units of a file’s size if it is lower than 1 KB/Kib

uk

the units of a file’s size if it is between 1 KB/KiB and 1 MB/MiB

um

the units of a file’s size if it is between 1 MB/MiB and 1 GB/GiB

ug

the units of a file’s size if it is between 1 GB/GiB and 1 TB/TiB

ut

the units of a file’s size if it is 1 TB/TiB or higher

df

a device’s major ID

ds

a device’s minor ID

uu

a user that’s you

uR

a user that’s root

un

a user that’s someone else

gu

a group that you belong to

gR

a group related to root

gn

a group you aren’t a member of

lc

a number of hard links

lm

a number of hard links for a regular file with at least two

ga

a new flag in Git

gm

a modified flag in Git

gd

a deleted flag in Git

gv

a renamed flag in Git

gt

a modified metadata flag in Git

gi

an ignored flag in Git

gc

a conflicted flag in Git

Gm

main branch of repo

Go

other branch of repo

Gc

clean branch of repo

Gd

dirty branch of repo

xx

“punctuation”, including many background UI elements

da

a file’s date

in

a file’s inode number

bl

a file’s number of blocks

hd

the header row of a table

lp

the path of a symlink

cc

an escaped character in a filename

bO

the overlay style for broken symlink paths

sp

special (not file, dir, mount, exec, pipe, socket, block device, char device, or link)

mp

a mount point

im

a regular file that is an image

vi

a regular file that is a video

mu

a regular file that is lossy music

lo

a regular file that is lossless music

cr

a regular file that is related to cryptography (ex: key or certificate)

do

a regular file that is a document (ex: office suite document or PDF)

co

a regular file that is compressed

tm

a regular file that is temporary (ex: a text editor’s backup file)

cm

a regular file that is a compilation artifact (ex: Java class file)

bu

a regular file that is used to build a project (ex: Makefile)

sc

a regular file that is source code

Sn

No security context on a file

Su

SELinux user

Sr

SELinux role

St

SELinux type

Sl

SELinux level

ff

BSD file flags

Values in EXA_COLORS override those given in LS_COLORS, so you don’t need to re-write an existing LS_COLORS variable with proprietary extensions.

## LIST OF STYLES
Unlike some versions of ls, the given ANSI values must be valid colour codes: eza won’t just print out whichever characters are given.

The codes accepted by eza are:

1

for bold

2

for dimmed

3

for italic

4

for underline

31

for red text

32

for green text

33

for yellow text

34

for blue text

35

for purple text

36

for cyan text

37

for white text

90

for dark gray text

91

for bright red text

92

for bright green text

93

for bright yellow text

94

for bright blue text

95

for bright purple text

96

for bright cyan text

97

for bright text

38;5;nnn

for a colour from 0 to 255 (replace the nnn part)

Many terminals will treat bolded text as a different colour, or at least provide the option to.

eza provides its own built-in set of file extension mappings that cover a large range of common file extensions, including documents, archives, media, and temporary files. Any mappings in the environment variables will override this default set: running eza with LS_COLORS="*.zip=32" will turn zip files green but leave the colours of other compressed files alone.

You can also disable this built-in set entirely by including a reset entry at the beginning of EZA_COLORS. So setting EZA_COLORS="reset:*.txt=31" will highlight only text files; setting EZA_COLORS="reset" will highlight nothing.

## AUTHOR
eza is maintained by Christina Sørensen and many other contributors.

Source code: https://github.com/eza-community/eza

Contributors: https://github.com/eza-community/eza/graphs/contributors

Our infinite thanks to Benjamin `ogham' Sago and all the other contributors of exa, from which eza was forked.

## SEE ALSO
•

eza.1.md

•

eza_colors-explanation.5.md


title: eza_colors-explanation(5)

text:
# eza_colors-explanation(5)

## Name
eza_colors-explanation — more details on customizing eza colors

## Eza Color Explanation
eza provides its own built-in set of file extension mappings that cover a large range of common file extensions, including documents, archives, media, and temporary files. Any mappings in the environment variables will override this default set: running eza with LS_COLORS="*.zip=32" will turn zip files green but leave the colours of other compressed files alone.

You can also disable this built-in set entirely by including a reset entry at the beginning of EZA_COLORS. So setting EZA_COLORS="reset:*.txt=31" will highlight only text files; setting EZA_COLORS="reset" will highlight nothing.

### Examples
•

Disable the “current user” highlighting: EZA_COLORS="uu=0:gu=0"

•

Turn the date column green: EZA_COLORS="da=32"

•

Highlight Vagrantfiles: EZA_COLORS="Vagrantfile=1;4;33"

•

Override the existing zip colour: EZA_COLORS="*.zip=38;5;125"

•

Markdown files a shade of green, log files a shade of grey: EZA_COLORS="*.md=38;5;121:*.log=38;5;248"

### BUILT-IN EXTENSIONS
•

eza now supports bright colours! As supported by most modern 256-colour terminals, you can now choose from bright colour codes when selecting your custom colours in your #EZA_COLORS environment variable.

•

Build (Makefile, Cargo.toml, package.json) are yellow and underlined.

•

Images (png, jpeg, gif) are purple.

•

Videos (mp4, ogv, m2ts) are a slightly purpler purple.

•

Music (mp3, m4a, ogg) is a deeper purple.

•

Lossless music (flac, alac, wav) is deeper than that purple. In general, most media files are some shade of purple.

•

Cryptographic files (asc, enc, p12) are a faint blue.

•

Documents (pdf, doc, dvi) are a less faint blue.

•

Compressed files (zip, tgz, Z) are red.

•

Temporary files (tmp, swp, ~) are grey.

•

Compiled files (class, o, pyc) are yellow. A file is also counted as compiled if it uses a common extension and is in the same directory as one of its source files: styles.css will count as compiled when next to styles.less or styles.sass, and scripts.js when next to scripts.ts or scripts.coffee.

•

Source files (cpp, js, java) are bright yellow.

### See also
•

eza.1.md

•

eza_colors.5.md


jail.conf

title: jail.conf(5)

summary: configuration for the fail2ban server

text:
# jail.conf(5)

## NAME
jail.conf - configuration for the fail2ban server

## SYNOPSIS
fail2ban.conf fail2ban.d/*.conf fail2ban.local fail2ban.d/*.local

jail.conf jail.d/*.conf jail.local jail.d/*.local

action.d/*.conf action.d/*.local action.d/*.py

filter.d/*.conf filter.d/*.local

## DESCRIPTION
Fail2ban has four configuration file types:

fail2ban.conf

Fail2Ban global configuration (such as logging)

filter.d/*.conf

Filters specifying how to detect authentication failures

action.d/*.conf

Actions defining the commands for banning and unbanning of IP address

jail.conf

Jails defining combinations of Filters with Actions.

## CONFIGURATION FILES FORMAT
*.conf files are distributed by Fail2Ban. It is recommended that *.conf files should remain unchanged to ease upgrades. If needed, customizations should be provided in *.local files. For example, if you would like to enable the [ssh-iptables-ipset] jail specified in jail.conf, create jail.local containing

jail.local

[ssh-iptables-ipset] enabled = true

In .local files specify only the settings you would like to change and the rest of the configuration will then come from the corresponding .conf file which is parsed first.

jail.d/ and fail2ban.d/

In addition to .local, for jail.conf or fail2ban.conf file there can be a corresponding .d/ directory containing additional .conf files. The order e.g. for jail configuration would be:

jail.conf

jail.d/*.conf (in alphabetical order)

jail.local

jail.d/*.local (in alphabetical order). i.e. all .local files are parsed after .conf files in the original configuration file and files under .d directory. Settings in the file parsed later take precedence over identical entries in previously parsed files. Files are ordered alphabetically, e.g.

fail2ban.d/01_custom_log.conf - to use a different log path

jail.d/01_enable.conf - to enable a specific jail

jail.d/02_custom_port.conf - to change the port(s) of a jail.

Configuration files have sections, those specified with [section name], and name = value pairs. For those name items that can accept multiple values, specify the values separated by spaces, or in separate lines space indented at the beginning of the line before the second value.

Configuration files can include other (defining common variables) configuration files, which is often used in Filters and Actions. Such inclusions are defined in a section called [INCLUDES]:

before

indicates that the specified file is to be parsed before the current file.

after

indicates that the specified file is to be parsed after the current file.

Using Python "string interpolation" mechanisms, other definitions are allowed and can later be used within other definitions as %(name)s.

Fail2ban has more advanced syntax (similar python extended interpolation). This extended interpolation is using %(section/parameter)s to denote a value from a foreign section.

Besides cross section interpolation the value of parameter in [DEFAULT] section can be retrieved with %(default/parameter)s.

Fail2ban supports also another feature named %(known/parameter)s (means last known option with name parameter). This interpolation makes possible to extend a stock filter or jail regexp in .local file (opposite to simply set failregex/ignoreregex that overwrites it), e.g.

```
baduseragents = IE|wget|%(my-settings/baduseragents)s
failregex = %(known/failregex)s

            useragent=%(baduseragents)s
```

Additionally to interpolation %(known/parameter)s, that does not works for filter/action init parameters, an interpolation tag <known/parameter> can be used (means last known init definition of filters or actions with name parameter). This interpolation makes possible to extend a parameters of stock filter or action directly in jail inside jail.conf/jail.local file without creating a separately filter.d/*.local file, e.g.

\# filter.d/test.conf:

```
[Init]
test.method = GET
baduseragents = IE|wget
[Definition]
failregex = ^%(__prefix_line)\s+"<test.method>"\s+test\s+regexp\s+-\s+useragent=(?:<baduseragents>)
# jail.local:
[test]
# use filter "test", overwrite method to "POST" and extend known bad agents with "badagent":
filter = test[test.method=POST, baduseragents="badagent|<known/baduseragents>"]
```

Comments: use '#' for comment lines and '; ' (space is important) for inline comments. When using Python2.X, '; ' can only be used on the first line due to an Python library bug.

## FAIL2BAN CONFIGURATION FILE(S) (fail2ban.conf)
The items that can be set in section [Definition] are:

loglevel

verbosity level of log output: CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG, TRACEDEBUG, HEAVYDEBUG or corresponding numeric value (50-5). Default: INFO (equal 20)

logtarget

log target: filename, SYSLOG, STDERR or STDOUT. Default: STDOUT if not set in fail2ban.conf/fail2ban.local

Note. If fail2ban running as systemd-service, for logging to the systemd-journal, the logtarget could be set to STDOUT

Only a single log target can be specified. If you change logtarget from the default value and you are using logrotate -- also adjust or disable rotation in the corresponding configuration file (e.g. /etc/logrotate.d/fail2ban on Debian systems).

socket

socket filename. Default: /var/run/fail2ban/fail2ban.sock

This is used for communication with the fail2ban server daemon. Do not remove this file when Fail2ban is running. It will not be possible to communicate with the server afterwards.

pidfile

PID filename. Default: /var/run/fail2ban/fail2ban.pid

This is used to store the process ID of the fail2ban server.

dbfile

Database filename. Default: /var/lib/fail2ban/fail2ban.sqlite3

This defines where the persistent data for fail2ban is stored. This persistent data allows bans to be reinstated and continue reading log files from the last read position when fail2ban is restarted. A value of None disables this feature.

dbmaxmatches

Max number of matches stored in database per ticket. Default: 10

This option sets the max number of matched log-lines could be stored per ticket in the database. This also affects values resolvable via tags <ipmatches> and <ipjailmatches> in actions.

dbpurgeage

Database purge age in seconds. Default: 86400 (24hours)

This sets the age at which bans should be purged from the database.

The config parameters of section [Thread] are:

stacksize

Stack size of each thread in fail2ban. Default: 0 (platform or configured default)

This specifies the stack size (in KiB) to be used for subsequently created threads, and must be 0 or a positive integer value of at least 32.

## JAIL CONFIGURATION FILE(S) (jail.conf)
The following options are applicable to any jail. They appear in a section specifying the jail name or in the [DEFAULT] section which defines default values to be used if not specified in the individual section.

filter

name of the filter -- filename of the filter in /etc/fail2ban/filter.d/ without the .conf/.local extension.

Only one filter can be specified.

logpath

filename(s) of the log files to be monitored, separated by new lines.

Globs -- paths containing * and ? or [0-9] -- can be used however only the files that exist at start up matching this glob pattern will be considered. Optional space separated option 'tail' can be added to the end of the path to cause the log file to be read from the end, else default 'head' option reads file from the beginning

Ensure syslog or the program that generates the log file isn't configured to compress repeated log messages to "*last message repeated 5 time*s" otherwise it will fail to detect. This is called RepeatedMsgReduction in rsyslog and should be Off.

logencoding

encoding of log files used for decoding. Default value of "auto" uses current system locale.

logtimezone

Force the time zone for log lines that don't have one. If this option is not specified, log lines from which no explicit time zone has been found are interpreted by fail2ban in its own system time zone, and that may turn to be inappropriate. While the best practice is to configure the monitored applications to include explicit offsets, this option is meant to handle cases where that is not possible.

The supported time zones in this option are those with fixed offset: Z, UTC[+-]hhmm (you can also use GMT as an alias to UTC).

This option has no effect on log lines on which an explicit time zone has been found. Examples:

```
        logtimezone = UTC

        logtimezone = UTC+0200

        logtimezone = GMT-0100
```

banaction

banning action (default iptables-multiport) typically specified in the [DEFAULT] section for all jails.

This parameter will be used by the standard substitution of action and can be redefined central in the [DEFAULT] section inside jail.local (to apply it to all jails at once) or separately in each jail, where this substitution will be used.

banaction_allports

the same as banaction but for some "allports" jails like "pam-generic" or "recidive" (default iptables-allports).

action

action(s) from /etc/fail2ban/action.d/ without the .conf/.local extension.

Arguments can be passed to actions to override the default values from the [Init] section in the action file. Arguments are specified by:

[name=value,name2=value,name3="values,values"]

Values can also be quoted (required when value includes a ","). More that one action can be specified (in separate lines).

ignoreself

boolean value (default true) indicates the banning of own IP addresses should be prevented

ignoreip

list of IPs not to ban. They can include a DNS resp. CIDR mask too. The option affects additionally to ignoreself (if true) and don't need to contain own DNS resp. IPs of the running host.

ignorecommand

command that is executed to determine if the current candidate IP for banning (or failure-ID for raw IDs) should not be banned. The option affects additionally to ignoreself and ignoreip and will be first executed if both don't hit.

IP will not be banned if command returns successfully (exit code 0). Like ACTION FILES, tags like <ip> are can be included in the ignorecommand value and will be substituted before execution.

ignorecache

provide cache parameters (default disabled) for ignore failure check (caching of the result from `ignoreip`, `ignoreself` and `ignorecommand`), syntax:

```
        ignorecache = key="<F-USER>@<ip-host>", max-count=100, max-time=5m

        ignorecommand = if [ "<F-USER>" = "technical" ] && [ "<ip-host>" = "my-host.example.com" ]; then exit 0; fi;

                        exit 1
```

This will cache the result of ignorecommand (does not call it repeatedly) for 5 minutes (cache time) for maximal 100 entries (cache size), using values substituted like "user@host" as cache-keys. Set option ignorecache to empty value disables the cache.

bantime

effective ban duration (in seconds or time abbreviation format).

findtime

time interval (in seconds or time abbreviation format) before the current time where failures will count towards a ban.

maxretry

number of failures that have to occur in the last findtime seconds to ban then IP.

backend

backend to be used to detect changes in the logpath.

It defaults to "auto" which will try "pyinotify", "gamin", "systemd" before "polling". Any of these can be specified. "pyinotify" is only valid on Linux systems with the "pyinotify" Python libraries. "gamin" requires the "gamin" libraries.

usedns

use DNS to resolve HOST names that appear in the logs. By default it is "warn" which will resolve hostnames to IPs however it will also log a warning. If you are using DNS here you could be blocking the wrong IPs due to the asymmetric nature of reverse DNS (that the application used to write the domain name to log) compared to forward DNS that fail2ban uses to resolve this back to an IP (but not necessarily the same one). Ideally you should configure your applications to log a real IP. This can be set to "yes" to prevent warnings in the log or "no" to disable DNS resolution altogether (thus ignoring entries where hostname, not an IP is logged)..

prefregex

regex (Python regular expression) to parse a common part containing in every message (see prefregex in section FILTER FILES for details).

failregex

regex (Python regular expression) to be added to the filter's failregexes (see failregex in section FILTER FILES for details). If this is useful for others using your application please share you regular expression with the fail2ban developers by reporting an issue (see REPORTING BUGS below).

ignoreregex

regex which, if the log line matches, would cause Fail2Ban not consider that line. This line will be ignored even if it matches a failregex of the jail or any of its filters.

maxmatches

max number of matched log-lines the jail would hold in memory per ticket. By default it is the same value as maxretry of jail (or default). This option also affects values resolvable via tag <matches> in actions.

### Backends
Available options are listed below.

pyinotify

requires pyinotify (a file alteration monitor) to be installed. If pyinotify is not installed, Fail2ban will use auto.

gamin

requires Gamin (a file alteration monitor) to be installed. If Gamin is not installed, Fail2ban will use auto.

polling

uses a polling algorithm which does not require external libraries.

systemd

uses systemd python library to access the systemd journal. Specifying logpath is not valid for this backend and instead utilises journalmatch from the jails associated filter config. Multiple systemd-specific flags can be passed to the backend, including journalpath and journalfiles, to explicitly set the path to a directory or set of files. journalflags, which by default is 4 and excludes user session files, can be set to include them with journalflags=1, see the python-systemd documentation for other settings and further details. Examples:

```
backend = systemd[journalpath=/run/log/journal/machine-1]
backend = systemd[journalfiles="/path/to/system.journal, /path/to/user.journal"]
backend = systemd[journalflags=1]
```

### Actions
Each jail can be configured with only a single filter, but may have multiple actions. By default, the name of a action is the action filename, and in the case of Python actions, the ".py" file extension is stripped. Where multiple of the same action are to be used, the actname option can be assigned to the action to avoid duplication e.g.:

```
[ssh-iptables-ipset]
enabled = true
action = smtp.py[dest=chris@example.com, actname=smtp-chris]

         smtp.py[dest=sally@example.com, actname=smtp-sally]
```

## TIME ABBREVIATION FORMAT
The time entries in fail2ban configuration (like findtime or bantime) can be provided as integer in seconds or as string using special abbreviation format (e. g. 600 is the same as 10m).

Abbreviation tokens:

```
years?, yea?, yy?
months?, mon?
weeks?, wee?, ww?
days?, da, dd?
hours?, hou?, hh?
minutes?, min?, mm?
seconds?, sec?, ss?
The question mark (?) means the optional character, so day as well as days can be used.
```

You can combine multiple tokens in format (separated with space resp. without separator), e. g.: 1y 6mo or 1d12h30m.

Note that tokens m as well as mm means minutes, for month use abbreviation mo or mon.

The time format can be tested using fail2ban-client:

```
fail2ban-client --str2sec 1d12h
```

## ACTION CONFIGURATION FILES (action.d/*.conf)
Action files specify which commands are executed to ban and unban an IP address.

Like with jail.conf files, if you desire local changes create an [actionname].local file in the /etc/fail2ban/action.d directory and override the required settings.

Action files have two sections, Definition and Init .

The [Init] section enables action-specific settings. In jail.conf/jail.local these can be overridden for a particular jail as options of the action's specification in that jail.

The following commands can be present in the [Definition] section.

actionstart

command(s) executed when the jail starts.

actionstop

command(s) executed when the jail stops.

actioncheck

command(s) ran before any other action. It aims to verify if the environment is still ok.

actionban

command(s) that bans the IP address after maxretry log lines matches within last findtime seconds.

actionunban

command(s) that unbans the IP address after bantime.

The [Init] section allows for action-specific settings. In jail.conf/jail.local these can be overwritten for a particular jail as options to the jail. The following are special tags which can be set in the [Init] section:

timeout

The maximum period of time in seconds that a command can executed, before being killed.

Commands specified in the [Definition] section are executed through a system shell so shell redirection and process control is allowed. The commands should return 0, otherwise error would be logged. Moreover if actioncheck exits with non-0 status, it is taken as indication that firewall status has changed and fail2ban needs to reinitialize itself (i.e. issue actionstop and actionstart commands). Tags are enclosed in <>. All the elements of [Init] are tags that are replaced in all action commands. Tags can be added by the fail2ban-client using the "set <JAIL> action <ACT>" command. <br> is a tag that is always a new line (\n).

More than a single command is allowed to be specified. Each command needs to be on a separate line and indented with whitespace(s) without blank lines. The following example defines two commands to be executed.

actionban = iptables -I fail2ban-<name> --source <ip> -j DROP

echo ip=<ip>, match=<match>, time=<time> >> /var/log/fail2ban.log

### Action Tags
The following tags are substituted in the actionban, actionunban and actioncheck (when called before actionban/actionunban) commands.

ip

IPv4 IP address to be banned. e.g. 192.168.0.2

failures

number of times the failure occurred in the log file. e.g. 3

ipfailures

As per failures, but total of all failures for that ip address across all jails from the fail2ban persistent database. Therefore the database must be set for this tag to function.

ipjailfailures

As per ipfailures, but total based on the IPs failures for the current jail.

time

UNIX (epoch) time of the ban. e.g. 1357508484

matches

concatenated string of the log file lines of the matches that generated the ban. Many characters interpreted by shell get escaped to prevent injection, nevertheless use with caution.

ipmatches

As per matches, but includes all lines for the IP which are contained with the fail2ban persistent database. Therefore the database must be set for this tag to function.

ipjailmatches

As per ipmatches, but matches are limited for the IP and for the current jail.

## PYTHON ACTION FILES
Python based actions can also be used, where the file name must be [actionname].py. The Python file must contain a variable Action which points to Python class. This class must implement a minimum interface as described by fail2ban.server.action.ActionBase, which can be inherited from to ease implementation.

## FILTER FILES (filter.d/*.conf)
Filter definitions are those in /etc/fail2ban/filter.d/*.conf and filter.d/*.local.

These are used to identify failed authentication attempts in log files and to extract the host IP address (or hostname if usedns is true).

Like action files, filter files are ini files. The main section is the [Definition] section.

There are several standard filter definitions used in the [Definition] section:

prefregex

is the regex (regular expression) to parse a common part containing in every message, which is applied after datepattern found a match, before the search for any failregex or ignoreregex would start.

If this regex doesn't match the process is starting immediately with next message and search for any failregex does not occur.

If prefregex contains <F-CONTENT>...</F-CONTENT>, the part of message enclosed between this tags will be extracted and herafter used as whole message for search with failregex or ignoreregex.

For example:

```
        prefregex = ^%(__prefix_line)s (?:ERROR|FAILURE) <F-CONTENT>.+</F-CONTENT>$

        failregex = ^user not found

                    ^authentication failed

                    ^unknown authentication method
```

You can use prefregex in order to:

- specify 1 common regex to match some common part present in every messages (do avoid unneeded match in every failregex if you have more as one);

- to cut some interesting part of message only (to simplify failregex) enclosed between tags <F-CONTENT> and </F-CONTENT>;

- to gather some failure identifier (e. g. some prefix matched by <F-MLFID>...<F-MLFID/> tag) to identify several messages belonging to same session, where a connect message containing IP followed by failure message(s) that are not contain IP; this provides a new multi-line parsing method as replacement for old (slow an ugly) multi-line parsing using buffering window (maxlines > 1 and <SKIPLINES>);

- to ignore some wrong, too long or even unneeded messages (a.k.a. parasite log traffic) which can be also present in journal, before failregex search would take place.

failregex

is the regex (regular expression) that will match failed attempts. The standard replacement tags can be used as part of the regex:

<HOST> - common regex for IP addresses and hostnames (if usedns is enabled). Fail2Ban will work out which one of these it actually is.

<ADDR> - regex for IP addresses (both families).

<IP4> - regex for IPv4 addresses.

<IP6> - regex for IPv6 addresses (also IP enclosed in brackets).

<DNS> - regex to match hostnames.

<CIDR> - helper regex to match CIDR (simple integer form of net-mask).

<SUBNET> - regex to match sub-net adresses (in form of IP/CIDR, also single IP is matched, so part /CIDR is optional).

NOTE: the failregex will be applied to the remaining part of message after prefregex processing (if specified), which in turn takes place after datepattern processing (whereby the string of timestamp matching the best pattern, cut out from the message).

For multiline regexs (parsing with maxlines greater that 1) the tag <SKIPLINES> can be used to separate lines. This allows lines between the matched lines to continue to be searched for other failures. The tag can be used multiple times.

This is an obsolete handling and if the lines contain some common identifier, better would be to use new handling (with tags <F-MLFID>...<F-MLFID/>).

ignoreregex

is the regex to identify log entries that should be ignored by Fail2Ban, even if they match failregex.

maxlines

specifies the maximum number of lines to buffer to match multi-line regexs. For some log formats this will not required to be changed. Other logs may require to increase this value if a particular log file is frequently written to.

datepattern

specifies a custom date pattern/regex as an alternative to the default date detectors e.g. %%Y-%%m-%%d %%H:%%M(?::%%S)?. For a list of valid format directives, see Python library documentation for strptime behaviour.

NOTE: due to config file string substitution, that %'s must be escaped by an % in config files.

Also, special values of Epoch (UNIX Timestamp), TAI64N and ISO8601 can be used as datepattern.

Normally the regexp generated for datepattern additionally gets word-start and word-end boundaries to avoid accidental match inside of some word in a message. There are several prefixes and words with special meaning that could be specified with custom datepattern to control resulting regex:

{DEFAULT} - can be used to add default date patterns of fail2ban.

{DATE} - can be used as part of regex that will be replaced with default date patterns.

{^LN-BEG} - prefix (similar to ^) changing word-start boundary to line-start boundary (ignoring up to 2 characters). If used as value (not as a prefix), it will also set all default date patterns (similar to {DEFAULT}), but anchored at begin of message line.

{UNB} - prefix to disable automatic word boundaries in regex.

{NONE} - value would allow to find failures totally without date-time in log message. Filter will use now as a timestamp (or last known timestamp from previous line with timestamp).

journalmatch

specifies the systemd journal match used to filter the journal entries. See journalctl(1) and systemd.journal-fields(7) for matches syntax and more details on special journal fields. This option is only valid for the systemd backend.

Similar to actions, filters may have an [Init] section also (optional since v.0.10). All parameters of both sections [Definition] and [Init] can be overridden (redefined or extended) in jail.conf or jail.local (or in related filter.d/filter-name.local). Every option supplied in the jail to the filter overwrites the value specified in [Init] section, which in turm would overwrite the value in [Definition] section. Besides the standard settings of filter both sections can be used to initialize filter-specific options.

Filters can also have a section called [INCLUDES]. This is used to read other configuration files.

before

indicates that this file is read before the [Definition] section.

after

indicates that this file is read after the [Definition] section.

## AUTHOR
Fail2ban was originally written by Cyril Jaquier <cyril.jaquier@fail2ban.org>. At the moment it is maintained and further developed by Yaroslav O. Halchenko <debian@onerussian.com>, Daniel Black <daniel.subs@internode.on.net> and Steven Hiscocks <steven-fail2ban@hiscocks.me.uk> along with a number of contributors. See THANKS file shipped with Fail2Ban for a full list. Manual page written by Daniel Black and Yaroslav Halchenko.

## REPORTING BUGS
Report bugs to https://github.com/fail2ban/fail2ban/issues

## COPYRIGHT
Copyright © 2013 the Fail2Ban Team

Copyright of modifications held by their respective authors.

Licensed under the GNU General Public License v2 (GPL) or (at your option) any later version.

## SEE ALSO
fail2ban-server(1)


fb.modes

package: fbset

title: fb.modes(5)

summary: frame buffer modes file

text:
# fb.modes(5)

## NAME
fb.modes - frame buffer modes file

## DESCRIPTION
/etc/fb.modes contains an unlimited number of video mode descriptions. The general format of a video mode is:

mode

geometry <xres> <yres> <vxres> <vyres> <depth>

timings <pixclock> <left> <right> <upper> <lower> <hslen> <vslen>

options <value>

rgba <red,green,blue,alpha>

endmode

## OPTIONS
geometry options:

xres

visible horizontal resolution (in pixels)

yres

visible vertical resolution (in pixels)

vxres

virtual horizontal resolution (in pixels)

vyres

virtual vertical resolution (in pixels)

depth

display depth (in bits per pixel)

timing options:

pixclock

length of one pixel (in picoseconds)

left

left margin (in pixels)

right

right margin (in pixels)

upper

upper margin (in pixel lines)

lower

lower margin (in pixel lines)

hslen

horizontal sync length (in pixels)

vslen

vertical sync length (in pixel lines)

rgba options (only valid with truecolor):

red

red color bitfields (in length or length/offset)

green

green color bitfields (in length or length/offset)

blue

blue color bitfields (in length or length/offset)

alpha

alpha color bitfields (in length or length/offset)

other options:

the first value of this options is the default hsync {low|high}

the horizontal sync polarity

vsync {low|high}

the vertical sync polarity

csync {low|high}

the composite sync polarity

gsync {low|high}

the sync on green polarity

bcast {false|true}

enable or disable broadcast modes. If enabled the frame buffer generates the exact timings fot several broadcast modes (e.g. PAL or NTSC). Note that this option may not be supported by every frame buffer

extsync {false|true}

enable or disable external resync. If enabled the sync timings are not generated by the frame buffer device and must be provided externally instead. Note that this option may not be supported by every frame buffer device

laced {false|true}

enable or disable interlace. If enabled the display will be split in two frames, each frame contains only even and odd lines respectively. These two frames will be displayed alternating, this way twice the lines can be displayed and the vertical frequency for monitor stays the same, but the visible vertical frequency gets halved

double {false|true}

enable or disable doublescan. If enabled every line will be displayed twice and this way the horizontal frequency can easily be doubled, so that the same resolution can be displayed on different monitors, even if the horizontal frequency specification differs. Note that this option may not be supported by every frame buffer device

nostd <number>

select nonstandard video mode

accel {false|true}

enable or disable hardware text acceleration

grayscale {false|true}

enable or disable graylevels instead of colors

## INTERNALS
Generally a frame buffer display is organized as follows:

+---+---------------+---+---+

| | ^ | | |

| | | 5 | | |

| | v | | |

+---#################---+---+

| # ^ # | |

| # | # | |

| # | # | |

| 1 # | 2 # 3 | 4 |

|<->#<------+------>#<->|<->|

| # | # | |

| # | 6 # | |

| # | # | |

| # v # | |

+---#################---+---+

| | ^ | | |

| | | 7 | | |

| | v | | |

+---+---------------+---+---+

| | ^ | | |

| | | 8 | | |

| | v | | |

+---+---------------+---+---+

1 left margin

2 xres

3 right margin

4 horizontal sync len

5 upper margin

6 yres

7 lower margin

8 vertical sync len

The area bordered with `#' is the visible display area. Horizontal and vertical frequencies can now easily be calculated, for this the sum of horizontal or vertical values are important

htotal = left + xres + right + hslen

vtotal = upper + yres + lower + vslen

The length of one line can now be calculated with pixclock line = pixclock * htotal

and we have the horizontal frequency hfreq = 1E12 / line = 1E12 / (pixclock * htotal)

To get the vertical frequency vtotal must eventually adjusted. If the display is laced, vtotal must be halved or if the display is a doublescan one, vtotal must be doubled. Now we can calculate the length of one frame if (lace) vtotal /= 2

if (double) vtotal *= 2

frame = vtotal * line

and we get also the vertical frequency vfreq = 1E12 / frame = hfreq / vtotal

## SEE ALSO
fbset(8), fbdev(4)


package: fence-virtd

title: fence_virt.conf(5)

text:
# fence_virt.conf(5)

## NAME
fence_virt.conf - configuration file for fence_virtd

## DESCRIPTION
The fence_virt.conf file contains configuration information for fence_virtd, a fencing request routing daemon for clusters of virtual machines.

The file is tree-structured. There are parent/child relationships and sibling relationships between the nodes.

foo {

bar {

baz = "1";

}

}

There are three primary sections of fence_virt.conf.

## SECTIONS

### fence_virtd
This section contains global information about how fence_virtd is to operate. The most important pieces of information are as follows:

listener

the listener plugin for receiving fencing requests from clients

backend

the plugin to be used to carry out fencing requests

foreground

do not fork into the background.

wait_for_init

wait for the frontend and backends to become available rather than giving up immediately. This replaces wait_for_backend in 0.2.x.

module_path

the module path to search for plugins

### listeners
This section contains listener-specific configuration information; see the section about listeners below.

### backends
This section contains listener-specific configuration information; see the section about listeners below.

### groups
This section contains static maps of which virtual machines may fence which other virtual machines; see the section about groups below.

## LISTENERS
There are various listeners available for fence_virtd, each one handles decoding and authentication of a given fencing request. The following configuration blocks belong in the listeners section of fence_virt.conf

### multicast
key_file

the shared key file to use (default: /etc/cluster/fence_xvm.key).

hash

the weakest hashing algorithm allowed for client requests. Clients may send packets with stronger hashes than the one specified, but not weaker ones. (default: sha256, but could be sha1, sha512, or none)

auth

the hashing algorithm to use for the simplistic challenge-response authentication (default: sha256, but could be sha1, sha512, or none)

family

the IP family to use (default: ipv4, but may be ipv6)

address

the multicast address to listen on (default: 225.0.0.12)

port

the multicast port to listen on (default: 1229)

interface

interface to listen on. By default, fence_virtd listens on all interfaces. However, this causes problems in some environments where the host computer is used as a gateway.

### serial
The serial listener plugin utilizes libvirt's serial (or VMChannel) mapping to listen for requests. When using the serial listener, it is necessary to add a serial port (preferably pointing to /dev/ttyS1) or a channel (preferably pointing to 10.0.2.179:1229) to the libvirt domain description. Note that only type unix , mode bind serial ports and channels are supported. Example libvirt XML:

<serial type='unix'>

<source mode='bind' path='/sandbox/guests/fence_socket_molly'/>

<target port='1'/>

</serial>

<channel type='unix'>

<source mode='bind' path='/sandbox/guests/fence_molly_vmchannel'/>

<target type='guestfwd' address='10.0.2.179' port='1229'/>

</channel>

uri

the URI to use when connecting to libvirt by the serial plugin.

path

The same directory that is defined for the domain serial port path (From example above: /sandbox/guests). Sockets must reside in this directory in order to be considered valid. This can be used to prevent fence_virtd from using the wrong sockets.

mode

This selects the type of sockets to register. Valid values are "serial" (default) and "vmchannel".

### tcp
The tcp listener operates similarly to the multicast listener but uses TCP sockets for communication instead of using multicast packets.

key_file

the shared key file to use (default: /etc/cluster/fence_xvm.key).

hash

the hashing algorithm to use for packet signing (default: sha256, but could be sha1, sha512, or none)

auth

the hashing algorithm to use for the simplistic challenge-response authentication (default: sha256, but could be sha1, sha512, or none)

family

the IP family to use (default: ipv4, but may be ipv6)

address

the IP address to listen on (default: 127.0.0.1 for IPv4, ::1 for IPv6)

port

the TCP port to listen on (default: 1229)

### vsock
The vsock listener operates similarly to the multicast listener but uses virtual machine sockets (AF_VSOCK) for communication instead of using multicast packets.

key_file

the shared key file to use (default: /etc/cluster/fence_xvm.key).

hash

the hashing algorithm to use for packet signing (default: sha256, but could be sha1, sha512, or none)

auth

the hashing algorithm to use for the simplistic challenge-response authentication (default: sha256, but could be sha1, sha512, or none)

port

the vsock port to listen on (default: 1229)

## BACKENDS
There are various backends available for fence_virtd, each one handles routing a fencing request to a hypervisor or management tool. The following configuration blocks belong in the backends section of fence_virt.conf

### libvirt
The libvirt plugin is the simplest plugin. It is used in environments where routing fencing requests between multiple hosts is not required, for example by a user running a cluster of virtual machines on a single desktop computer.

uri

the URI to use when connecting to libvirt.

### libvirt-qmf
The libvirt-qmf plugin acts as a QMFv2 Console to the libvirt-qmf daemon in order to route fencing requests over AMQP to the appropriate computer.

host

host or IP address of qpid broker. Defaults to 127.0.0.1.

port

IP port of qpid broker. Defaults to 5672.

username

Username for GSSAPI, if configured.

service

Qpid service to connect to.

gssapi

If set to 1, have fence_virtd use GSSAPI for authentication when communicating with the Qpid broker. Default is 0 (off).

### cpg
The cpg plugin uses corosync CPG and libvirt to track virtual machines and route fencing requests to the appropriate computer.

uri

the URI to use when connecting to libvirt by the cpg plugin.

name_mode

The cpg plugin, in order to retain compatibility with fence_xvm, stores virtual machines in a certain way. The default was to use 'name' when using fence_xvm and fence_xvmd, and so this is still the default. However, it is strongly recommended to use 'uuid' instead of 'name' in all cluster environments involving more than one physical host in order to avoid the potential for name collisions.

## GROUPS
Fence_virtd supports static maps which allow grouping of VMs. The groups are arbitrary and are checked at fence time. Any member of a group may fence any other member. Hosts may be assigned to multiple groups if desired.

### group
This defines a group.

uuid

defines UUID as a member of a group.

ip

defines an IP which is allowed to send fencing requests for members of this group (e.g. for multicast). It is highly recommended that this be used in conjunction with a key file.

## EXAMPLE

fence_virtd {

listener = "multicast";

backend = "cpg";

}

\# this is the listeners section

listeners {

multicast {

key_file = "/etc/cluster/fence_xvm.key";

}

}

backends {

libvirt {

uri = "qemu:///system";

}

}

groups {

group {

ip = "192.168.1.1";

uuid = "44179d3f-6c63-474f-a212-20c8b4b25b16";

uuid = "1ce02c4b-dfa1-42cb-b5b1-f0b1091ece60";

}

}

## SEE ALSO
fence_virtd(8), fence_virt(8), fence_xvm(8), fence(8)


fiaif.conf

package: fiaif

title: fiaif.conf(5)

text:
# fiaif.conf(5)

## NAME
fiaif.conf - fiaif global configuration file

## DESCRIPTION
fiaif.conf is the file that declares which zones should be set up in the firewall. A "zone" is a piece of the "IP universe" existing on the other side of a particular interface. A zone is defined in a file listing rules for the handling of IP traffic into, out of, and through the associated interface. The zonefile is described in zone.conf(8). General configuration parameters are also declared in this file.

fiaif.conf and the zonefiles are bash(1) scripts in which the values of variables used in the fiaif program are assigned. Although they are shell scripts, they should contain nothing but assignment statements.

Parameters in the configuration files are of three forms:

SIMPLE

These parameters take only a single value. The value may be a number or a string.

GROUP These parameters are treated as a group, and all members of the group are processed in the same way. There are two parts to these parameters´ names. The first part is the name of the group, and the second part is a mnemonic.

ARRAY Parameter values are declared in an array. Any number of values can be specified by incrementing the array index for each value.

## DEFINITIONS
bashcommand -> [a shell command line]

dirpath -> [path to a directory (no trailing ´/´)]

fname -> [filename with no path]

modulename -> [the name of an iptables module]

portspec -> [a port number | a service in /etc/services]

posint -> [an integer >= 0]

TOStype -> [a Type-of-service name | a Type-of-service number]

zonename -> [the zone identifier from a zone file]

byteint -> 0..255

cidrmask -> 0..32

nullstring -> [nothing]

string -> [char]<string>|<nullstring>

boolean -> 0|1

burstspec -> <posint>|<posint>/<timespec>

IP4addr -> <byteint>.<byteint>.<byteint>.<byteint>

iptablesprotocol -> [a protocol number | a protocol name from /etc/protocols]

modulelist -> <nullstring>|<modulename> <modulelist>

netaddr -> <IP4addr>/<cidrmask>

netlist -> <nullstring>|<netaddr> <netlist>

pathlist -> <dirpath>|<dirpath>:<pathlist>

plist -> <nullstring>|<iptablesprotocol> <plist>

tablelist -> mangle filter nat

timespec -> second|minute|hour|day

TOSportlist -> <nullstring> | any | <TOSportlistOpt>

TOSportlistOpt -> <portspec> | <portspec>,<TOSportlist>

ICMPtype -> <ICMP type string>

zonelist -> <nullstring>|<zonename> <zonelist>

## CONSTANT PARAMETERS
The values of these parameters should (almost certainly) not be altered.

### TABLES
Syntax: TABLES= "<tablelist>"

A list of the packet processing tables in the Linux kernel. As of version 2.4.18, only three tables are available: mangle, filter, and nat.

### RESERVED_NETWORKS
Syntax: RESERVED_NETWORKS= "<netlist>"|"<fname>"

A list of the reserved ipnumbers and masks, or a file containing this list, one <netaddr> per line. See http://www.iana.com for more information.

### PRIVATE_NETWORKS
Syntax: PRIVATE_NETWORKS= "<netlist>"|"<fname>"

A list of the private ipnumbers and masks, or a file containing this list, one <netaddr> per line. See http://www.iana.com and rfc1918 for more information.

### LOOPBACK_NET
Syntax: LOOPBACK_NET= "<netaddr>"

The network of the loopback interface. "127.0.0.1/8" in the distribution.

### BIN_PATH
Syntax: BIN_PATH= "<pathlist>"

The search path for the iptables and tc binaries.

## PARAMETERS
The values of these parameters should be altered. They define the firewall deployed by fiaif and customize it for local networks and security policy.

### DONT_START
Syntax: DONT_START= <boolean>

If set to one, the firewall will not be started. DONT_START is set to 1 in the distributed fiaf.conf to prevent the inadvertant deployment of an unconfigured firewall from a download. Set the value to zero or delete the line to enable the firewall.

### CONF_DIR
Syntax: CONF_DIR= "<directorypath>/"

The path to the configuration directory. CONF_DIR is set to "/etc/fiaif/" in the distribution.

### SET_PROC_ERRORS
Syntax: SET_PROC_ERRORS= <boolean>

### SET_PROC_WARNINGS
Syntax: SET_PROC_WARNINGS= <boolean>

When the command "fiaif test" is issued, a list of errors and warnings are displayed.

If SET_PROC_ERRORS is 1, FIAIF will attempt to correct the errors.

If SET_PROC_WARNINGS is 1, FIAIF will attempt to correct the warnings.

### SAVE_STATE
Syntax: SAVE_STATE= <boolean>

If enabled, FIAIF will save all iptables rules to a file after these have been applied, if no errors were encountered while generating the rules. When FIAIF is started again, this file is used if and only if no modifications have been made to any configuration files. Rules are saved to /var/lib/fiaif/iptables.

Enabling this option greatly improves start time of FIAIF, but may cause problems if, for example, the ipnumber of a static interface changes, in which case /etc/init.d/fiaif force-reload should be used to rebuild ruleset from configuration files.

### ZONES
Syntax: ZONES= "<zonelist>"

A list of the zones to be set up. There must be a zone file in the configuration directory matching each zone named in this list.

Example:

ZONES="INT EXT"

### CONF_[XXX]
Syntax: CONF_[XXX]= "<fname>"

A group (CONF) containing the names of the zone files. It should match closly the names listed in the ZONES parameter. The zone files must be in the directory specified in CONF_DIR.

Example:

CONF_INT="zone.internal"

CONT_EXT="zone.external"

### TEST_FILE
Syntax: TEST_FILE= "<dirpath>/<fname>"

The absolute pathname of the file to which commands are written when fiaif is run with the ´test´ option. Set to "/tmp/fiaif.out" in the distribution.

### DEBUG
Syntax: DEBUG= <boolean>

If set to 1, fiaif will not drop any packets, but all rules are still applied, and the results will be in the syslog. Use this as a debugging tool if you are experiencing problems while setting up the zones. Set to zero for fiaif to work normally.

### VERBOSE
Syntax: VERBOSE= <boolean>

Set this variable to 1 to have fiaif log all dropped or redirected packets in the syslog. If no logging is wanted, set it to 0. See LOG_LIMIT and LOG_BURST for details on when logging occurs.

### LOG_PREFIX
Syntax: FIAIF_ <string>

Specify the prefix to use when logging packets to system log or though ulogd.

### ENABLE_ULOGD
Syntax: ENABLE_ULOGD= <boolean>

If set to 1 (and the ulogd is running on the system), fiaif logs via a ulogd. If set to 0, fiaif logs through the standard syslog facility.

### LOG_LIMIT
Syntax: LOG_LIMIT= <posint>

### LOG_BURST
Syntax: LOG_BURST= "<burstspec>"

Specify how often dropped or rejected packets should be entered into the system log. Tune to avoid spamming of logs.

LOG_LIMIT is the maximum average matching rate. If no <timespec> is provided, ´/second´ is assumed.

LOG_BURST is the maximum initial number of packets to match; this number is incrememted by one every time the limit specified above is not reached, up to this number. Note the quotes around LOG_BURST´s value.

### LOG_LEVEL
Syntax: LOG_LEVEL= <byteint>

This specifies the loglevel, for logging to syslog or ulogd. When using syslog, the number specifies the priority, see syslog.conf(5). If ENABLE_ULOG is true, LOG_LEVEL number specifies the netlink group (1-32), to which the line to be logged is is sent.

### ENABLE_TC
Syntax: ENABLE_TC= <boolean>

Enable or disable traffic shaping system wide. Setting to 0 overrides the TC_ENABLE value in all zone configurations. To enable traffic shaping in a zone, TC_ENABLE must be set to 1 in fiaif.conf and in the zone configuration as well.

### MODULES
Syntax: MODULES= "<modulelist>"

Specifies iptables modules to be loaded upon starting the firewall. The modules remain loaded as long as the firewall is deployed.

### PRE_SCRIPT[N]
Syntax: PRE_SCRIPT[N]= "<bashcommand>"

### POST_SCRIPT[N]
Syntax: POST_SCRIPT[N]= "<bashcommand>"

This pair of array parameters may contain shell commands to be executed before/after fiaif creates the iptables rules. The lines are executed in array-index sequence.

Three chains per zone exists to support user-defined rules. The chain names are: USER_INPUT_<ZONE_NAME> USER_OUTPUT_<ZONE_NAME> USER_FORWARD_<ZONE_NAME> Where the zone name is the name of the zone. Packets will go though these chains before hitting rules generated by INPUT, OUTPUT and FORWARD rules in the zone configuration files. Remember that only packets in the NEW state will hit these chains, and hence there is no need to test the state of a packet in these chains.

### ALIASES
Points to a file with IP alias specifications. These aliases are available to all zone configuration files, and can be used in rules where the syntax [<ip>[/<mask>]=>[<ip>[/<mask>] is used, as replacement for either side. See IPSET in zone.conf(8) for more information.

### TOS_FILE
Syntax: TOS_FILE= "<fname>"

Specify the name of the Type-Of-Service configuration file located in the configuration directory. This file specifies manipulation of the TOS bits in TCP and UDP packets. Traffic control examines these fields to determine into which class a packet should fall.

The file contains a group (TOS) with values of the form:

TOS_[XXX]= "<TOS-type> <protocol> <TOSportlist|ICMPtype>"

Examples:

TOS_MIN_DLY_UDP= "Minimize-Delay udp" TOS_NORM_SRVC_TCP= "Normal-Service tcp www,https"

## FILES
/etc/fiaif/fiaif.conf

The configuration file for FIAIF

/etc/fiaif/private_networks A list of private networks as specified by RFC1918

/etc/fiaif/reserved_networks A list of reserved networks as specified by IANA.

/etc/fiaif/aliases Specifies IP aliases to be used for all configuration files.

## AUTHOR
Anders Fugmann <anders(at)fugmann.net>

## SEE ALSO
fiaif(8), zone.conf(8)


zone.conf

title: zone.conf(5)

summary: fiaif zone configuration files

text:
# zone.conf(5)

## NAME
zone.conf - fiaif zone configuration files

## DESCRIPTION
fiaif.conf is the file that determines how zones should be set up in the firewall. A zone describes how traffic from other zones are allowed into a zone, and what packets are allowed from the zone itself. Zones are based upon the interface and the network the interface is connected to. It is possible to have multiple zones per interface, if and only if the interface is not declared public. See the PUBLIC variable for more information.

The general syntax of a configuration file is the same as for a bash(1) script, in which only variables should be present.

The variables can be on three forms:

VARIABLE

This is a simple variable. It can only be assigned a single value.

VARIABLE_FOO The denotes a variable sequence. The FOO can be replaced by any keyword, allowing multiple values to be specified.

VARIABLE[N] A variable array. Any number of values can be specified by increasing N for each value.

## VARIABLES

### NAME
Syntax: <name>

Specify the name of the zone. This must be the same as specified in /etc/fiaif/fiaif.conf.

### DEV
Syntax: <interface-name>

Specifies the interface name in which this zone is connected.

### DYNAMIC
Syntax: 0|1

Specifies whether the IP of the interface is dynamic (e.g., obtained via DHCP or unknown when FIAIF is started) or not. Disabling this provides better security, but this is not always an option given from ISPs.

### GLOBAL
Syntax: 0|1

Is set to one, any packets originating from IANA reserved networks are discarded (except those specified in the NET and NET_EXTRA variables). This should be set on your internet connection. If this is set to true, the interface cannot have multible zone definitions.

### IP
Syntax: <IP address>

The IP of the interface. This is only necessary to specify if DYNAMIC=0.

### MASK
Syntax: <network mask>

The network mask of the network connected to this interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command.

### NET
Syntax: <ip address/networkmask>

The network mask for the interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command.

### BCAST
Syntax: <broadcast address>

The broadcast address of the interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command.

### IP_EXTRA
Syntax: [IP]*

Contains a list of additional IP addresses that the interface can receive. Extra IP's for an interface is usually created by using interface aliases (e.g. eth0:0).

### NET_EXTRA
Syntax: [IP/MASK]*

A list specifying any extra networks besides the NET variables that are connected to this zone (interface). The extra nets would normally be connected though other routers.

### DHCP_SERVER
Syntax: <0|1>

Set to '1' if the server should accept DHCP queries. Only one zone per interface should have this enabled, since DHCP packets do not hold any valid destination address.

### INPUT[N]
Syntax: <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol> [port<:port>[<,port>[:port]]*] ip/[mask]=>ip/[mask]

The INPUT variable describes how packets are handled through the input chain. Packets on the INPUT chain are packets coming from the zone to the firewall itself. The first argument is how a matched packet is treated. Protocol and ports and ip/mask are used to match packets (destination port, and source=>destination ip address). If none are specified, the rule matches all packets. The port argument must only be specified if the protocol is udp, tcp or icmp When using these rules, a rule of thumb is only to accept specific packets, and to drop any not matched. The following line 1 accepts HTTP-requests over the TCP protocol:

INPUT[0]="ACCEPT tcp 80 0.0.0.0/0=>0.0.0.0/0"

INPUT[1]="ACCEPT udp 1024:65535 0.0.0.0/0=>0.0.0.0/0"

INPUT[2]="DROP ALL 0.0.0.0=>0.0.0.0"

### OUTPUT[N]
Syntax: <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol> [port<:port>[<,port>[:port]]*] ip/[mask]=>ip/[mask]

Like the INPUT[N] rule. Packets on the OUTPUT chain are packets originating from the firewall itself going out into the zone itself. ports are destination ports, and ip/mask is the source and destination ip/mask (if '=>' is not given, the ip is assumed to be the destination ip). The port argument must only be specified if the protocol is udp, tcp or icmp The following example drops all telnet packets over the tcp protocol, drops any udp packets, and allows any other send from the firewall itself.

OUTPUT[0]="DROP tcp 21 0.0.0.0/0=>0.0.0.0/0"

OUTPUT[1]="DROP udp ALL 0.0.0.0/0=>0.0.0.0/0"

OUTPUT[2]="ACCEPT ALL 0.0.0.0/0=>0.0.0.0/0"

### FORWARD[N]
Syntax: <zone|ALL> <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol[port<:port>[<,port>[:port]]*]> <ip/[mask]=>ip/[mask]>

Use to specify how packets arriving from other zones are to be treated. If protocol or ports and ip/mask is not specified, then ALL is assumed. The port specifies the destination port, and ip specifies the source and destination ip. The port argument must only be specified if the protocol is udp, tcp or icmp An example: A demilitarized zone may only accept HTTP requests from the internet (zone EXT). This would be specified by:

FORWARD[0]="EXT ACCEPT tcp 80 0.0.0.0/0=>0.0.0.0/0"

FORWARD[1]="ALL DROP ALL 0.0.0.0/0=>0.0.0.0/0"

### MARK[N]
Syntax: <zone|ALL> <mark number> <protocol[port<:port>[<,port>[:port]]*]> <ip/[mask]=>ip/[mask]>

Use the MARK rules to set a MARK on packets passing through the firewall. This can then be used to determine how a packet is routed. FIAIF does not do traffic-shaping based on mark values. The port argument must only be specified if the protocol is udp, tcp or icmp If the source zone is ALL then all packets going into the zone are marked. If the source zone equals the zone-name of which the rule is in then only packets originating from the firewall are marked.

Otherwise, only packets routed through the firewall are marked. Example: Mark all tcp packets going into the zone with '1' and all udp packets with mark '2'.

MARK[0]="ALL 1 tcp ALL 0.0.0.0/0=>0.0.0.0/0"

MARK[1]="ALL 2 udp ALL 0.0.0.0/0=>0.0.0.0/0"

### REPLY_FOO
Syntax: <zone> <type> <protocol [port[:port][<,port>[:port]]*]> <ip[/mask]=>ip[/mask]>

Make special replies to packets. The type can be one of the following:

icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited or tcp-reset (Only valid for the TCP protocol).

The zone argument specifies the source of the packet.

This can be used, for example, to disallow authentication requests, but instead of dropping the packets, close the connection by sending a tcp-reset.

REPLY_AUTH="EXT tcp-reset tcp auth 0.0.0.0/0=>0.0.0.0/0"

### MAC_DROP
Syntax: [MAC_ADDRESS]*|[file]

Disallow any communication with specified MAC-addresses in this zone. Inserted on PREROUTING chain. If the value is a file, then each line in the file is treated as an MAC address. Anything after a '#' is regarded as a comment and is ignored.

### IP_DROP
Syntax: [IP/MASK]*|[file]

Disallow any communication with specified IP addresses in this zone. If the value is a file, then each line in the file is treated as an ip address. Anything after a '#' is regarded as a comment and is ignored.

### ECN_REMOVE
Syntax: [IP/MASK]*|[file]

Remove the ECN bit from all packets destined to the specified servers (located in the zone). If the value is a file, then each line in the file is treated as an ip address. Anything after a '#' is regarded as a comment and is ignored.

### REDIRECT_FOO
Syntax: <protocol[port[:port]]> <ip[/mask]=>ip[/mask]> <[ipaddr[,ipaddr]*]> [port]

Alter the destination of packets. The rule applies only for packets originating from this zone. Packets can be redirected to the firewall itself (127.0.0.1), to other zones or back into the zone itself (requires DYNAMIC==0 and GLOBAL==0). If packets are redirected to other zones, then remember to add a FORWARD rule in the configuration file for the destination zone, allowing the packets to pass through. Please note, that redirecting packets back into the zone may cause serious network degradation.

Example:

REDIRECT_PROXY="tcp 80 0.0.0.0/0=>0.0.0.0/0 127.0.0.1 3128"

All packets coming from the zone itself to port 80 are redirected to the firewall itself port 3128, and this line can be used to setup a transparent proxy.

### WATCH_IP
Syntax: [IP]*|[file]

Log every packet coming from or going to the specific IP addresses. If the value is a file, then each line in the file is treated as an IP address. Anything after a '#' is regarded as a comment and is ignored.

### SNAT[N]
Syntax: <ZONE|ip> <protocol[port[:port][<,port>[:port]]*]> <ip[/mask]=>ip[/mask]>

Change the source address of a packet coming from this zone. If a ZONE is specified, then all packets are masqueraded to all ip addresses for the specified zone, specified by the IP or IP_EXTRA directive, in a round robin fashion. The last options specifies the protocol, port and original source and destination of the packets to be SNAT'ed.

To use MASQUADING, where EXT is the zone for the internet use:

SNAT[0]="EXT ALL 0.0.0.0/0=>0.0.0.0/0"

### LIMIT_FOO
Syntax: <zone> <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <limit> <burt> <protocol[port<:port>[<,port>[:port]]*]> <ip[/mask]=>ip[/mask]>

Limit number of packets. A LIMIT rule specifies how many packets are acceptable within the specified period of time. If more packets arrive, policy specifies how to handle these.

zone: Is the zone from which the packet originates. This can be this zone itself.

limit: Maximum average matching rate: specified as a number, with an optional ´/second´, ´/minute´, ´/hour´, or ´/day´ suffix.

burst: Maximum initial number of packets to match: this number gets incremented by one every time the limit specified above is not reached, up to this number.

protocol: The protocol: TCP|UDP|ICMP|ALL. This parameter is optional. The port argument must only be specified if the protocol is udp, tcp or icmp

ports: If protocol is tcp|udp: A list of ports or a port range. icmp: A list of icmp types seperated by commas. This parameter is optional pending on the specified protocol.

ip[/mask]=>ip[/mask] Specifies source address and optional destination address. This can only be specified if protocol is also specified.

For example to limit number of echo requests (ping) from zone EXT, use:

LIMIT_PING="EXT DROP 1/second 3 ICMP echo-request 0.0.0.0/0=>0.0.0.0/0"

### TC_ENABLE
Syntax: <0|1>

Enable or disable Traffic Shaping for this zone (traffic going into the network card, or being sent from the network card.) TC is only enabled if ENABLE_TC is set in the global configuration as well.

### TC_DOWNLINK
Syntax: <kbit>

Specify maximum uplink and downlink speeds. The values are specifed in kilobits (1024 bits).

### TC_TYPE
Syntax: <HTB|HFSC>

Specify the type of traffic shaping to be used. htb is videly available, but the hfsc type shaping yields much better results. Choose hfsc if you have the nessesary modules.

### TC_VOIP
Syntax: <0|1>

Specify '1' to enable special VOIP traffic shaping classes. Currently only implemented for the HFSC type shaper. It reserves a minimum bandwidth for voip traffic, and creates a special high priority class for voip related traffic.

### IPSET_FOO
Syntax: <ip</mask>>[ip</mask>]*| <file>

Sepcify a set of ip's to be used in zone rules. Ip's specified can be either numbers, hostnames, networks or names of other ip sets (recursively). The name of the set will be the name occuring after IPSET_. Ip sets is bound to a zone, and cannot be used across zones. Currently, ip-sets can only be used in INPUT, OUTPUT, FORWARD, SNAT, REDIRECT and MARK rules. If the ipset points to a file, then the file is read (relative to CONF_PATH ). The name of IP sets must not conflict with aliases defined in the file pointed to by the ALIASES directive in fiaif global configuration file.

An example of the use of IP sets:

IPSET_NAMESERVERS="1.2.3.4 1.2.3.5"

INPUT[N]="ACCEPT tcp domain NAMESERVERS=>0.0.0.0/0"

Which is equivalent to:

INPUT[N]="ACCEPT tcp domain 1.2.3.4=>0.0.0.0/0"

INPUT[N+1]="ACCEPT tcp domain 1.2.3.5=>0.0.0.0/0"

## AUTHOR
Anders Fugmann <anders(at)fugmann.net>

## SEE ALSO
fiaif(8), fiaif.conf(8), iptables(8), ifconfig(8)