fdm.conf

package: fdm

title: fdm.conf(5)

summary: fdm configuration file

text:
# fdm.conf(5)

## NAME
fdm.conf — fdm configuration file

## DESCRIPTION
This manual page describes the fdm(1) configuration file. It defines accounts from which to fetch mail, a number of possible actions to take, and rules connecting a regexp with an action. The file is parsed once from top to bottom, so action and account definitions must appear before they are referenced in a rule. Rules are evaluated from first to last and (unless overridden by the continue keyword) evaluation stops at the first match.

The file has the following format:

Empty lines and lines beginning with the ‘#’ character are ignored.

Regexps and strings must be enclosed in double quotes. Special characters in regexps and strings (including passwords) must be escaped. Note that this may mean double-escaping in regexps.

Possible commands are covered in the following sections.

## OPTIONS
Options are configured using the set command. It may be followed by the following options, one per command:

maximum-size size

This is used to set the maximum size of a mail. Mails larger than this limit are dropped and, if applicable, not deleted from the server. The size may be specified as a plain number in bytes or with a suffix of ‘K’ for kilobytes, ‘M’ for megabytes or ‘G’ for gigabytes. The default is 32 megabytes and the maximum is one gigabyte.

delete-oversized

If this option is specified, fdm(1) attempts to delete messages which exceed maximum-size, and continue. If it is not specified, oversize messages are a fatal error and cause fdm(1) to abort. Note that fdm(1) may have a number of messages queued (up to the queue-high setting, doubled for rewrite, per account), so this setting and the queue-high option should be set after consideration of the space available in the temporary folder and the implications should fdm(1) abort due to the space becoming full.

queue-high number

This sets the maximum number of messages fdm(1) will hold simultaneously. fdm(1) will attempt to process previously queued messages as the next is being fetched. Once this limit is reached, no further messages will be fetched until the number of messages held drops to the queue-low value.

queue-low number

This is the length to which the message queue must drop before fetching continues after the queue-high limit has been reached.

ignore-errors

If set, fdm.conf will continue to process mail if a delivery fails rather than aborting.

allow-multiple

If this option is specified, fdm(1) does not attempt to create a lock file and allows multiple instances to run simultaneously.

lock-file path

This sets an alternative lock file. The default is ~/.fdm.lock for non-root users and /var/db/fdm.lock for root.

lock-timeout time

Sets how long fdm.conf will try a lock file before giving up.

lock-wait

If present, fdm.conf will wait for lock-file for lock-timeout rather than exiting immediately with an error.

command-user user

This specifies the user used to run exec and pipe actions. By default it is the user who invoked fdm.

default-user user

This sets the default user to change to before delivering mail, if fdm(1) is running as root and no alternative user is specified as part of the action or rule. This option may be overridden with the -u switch on the command line. A default user must be given if running as root.

lookup-order location ...

This specifies the order in which to do user lookup from left to right. Possible types are passwd to use the passwd(5) file, or courier to use Courier authlib (if support is compiled).

lock-types type ...

This specifies the locks to be used for mbox locking. Possible types are fcntl, flock, and dotlock. The flock and fcntl types are mutually exclusive. The default is flock.

proxy url

This instructs fdm(1) to proxy all connections through url. HTTP and SOCKS5 proxies are supported at present (URLs of the form http://host[:port] or socks://[user:pass@]host[:port]). No authentication is supported for HTTP.

unmatched-mail drop | keep

This option controls what fdm(1) does with mail that reaches the end of the ruleset (mail that matches no rules or matches only rules with the continue keyword). drop will cause such mail to be discarded, and keep will attempt to leave the mail on the server. The default is to keep the mail and log a warning that it reached the end of the ruleset.

purge-after count

The purge-after option makes fdm(1) attempt to purge deleted mail from the server (if supported) after count mails have been retrieved. This is useful on unreliable connections to limit the potential number of mails refetched if the connection drops, but note that it can incur a considerable speed penalty.

no-received

If this option is present, fdm(1) will not insert a ‘Received’ header into each mail.

no-create

If this option is set, fdm(1) will not attempt to create maildirs and mboxes or missing elements of their paths.

file-umask user | umask

This specifies the umask(2) to use when creating files. user means to use the umask set when fdm(1) is started, or umask may be specified as a three-digit octal number. The default is 077.

file-group user | group

This option allows the default group ownership of files and directories created by fdm(1) to be specified. group may be a group name string or a numeric gid. If user is used, or this option does not appear in the configuration file, fdm(1) does not attempt to set the group of new files and directories.

timeout time

This controls the maximum time to wait for a server to send data before closing a connection. The default is 900 seconds.

verify-certificates

Instructs fdm(1) to verify SSL certificates for all SSL connections.

## INCLUDING FILES
Further configuration files may be including using the include command:

include path

The file to include is searched for first as an absolute path and then relative to the directory containing the main configuration file.

## MACROS
Macros may be defined using the following syntax:

- $name = string

- %name = number

Macros are prefixed with $ to indicate a string value and % to indicate a numeric value. Once defined, a macro may be used in any place a string or number is expected. Macros may be embedded in strings by surrounding their name (after the $ or %) with {}s, like so:

"abc ${mymacro} %{anothermacro} def"

The ifdef, ifndef and endif keywords may be used to conditionally parse a section of the configuration file depending on whether or not the macro given exists or does not exist. ifdef and ifndef blocks may be nested.

## SHELL COMMANDS
The result of a shell command may be used at any point a string or number is expected by wrapping it in $() or %(). If the former is used, the command result is used as a string; if the latter, it is converted to an integer. Shell commands are executed when the configuration file is parsed.

## ACCOUNTS
The account command is used to instruct fdm(1) to fetch mail from an account. The syntax is:

account name [users] [disabled] type [args] [keep]

The name argument is a string specifying a name for the account. The optional users argument has the following form:

user user | users { user ... }

The first two options specify a user or list of users as which the mail should be delivered when an action is executed. If no users are specified, the default user (set with set default-user) is used. Users specified as part of the account definition may be overridden by similar arguments to action definitions or on match rules. If fdm(1) is run as non-root, it will still execute any actions once for each user, but will be unable to change to that user so the action will be executed multiple times as the current user.

The disabled keyword instructs fdm(1) to ignore this account unless it is explicitly enabled with a -a option on the command line. If the keep keyword is specified, all mail collected from this account is kept (not deleted) even if it matches a drop action.

Supported account types and arguments are:

stdin

This account type reads mail from stdin, if it is connected to a pipe. This may be used to deliver mail from sendmail(8), see fdm(1) for details.

pop3 server host [port port] [user user] [pass pass] [only] [no-apop] [no-uidl] [starttls] [insecure]

pop3s server host [port port] [userpass] [only] [no-apop] [no-verify] [no-uidl] [insecure]

These statements define a POP3 or POP3S account. The userpass element has the following form: [user user] [pass pass]

The host, user and pass arguments must be strings. If the user or pass is not provided, fdm(1) attempts to look it up in the ~/.netrc file (see ftp(1) for details of the file format). The port option may be either a string which will be looked up in the services(5) database, or a number. If it is omitted, the default port (110 for POP3, 995 for POP3S) is used.

The only option takes the form:

[new-only | old-only] cache path

new-only fetches only mail not previously fetched, and old-only is the inverse: it fetches only mail that has been fetched before. The cache file is used to save the state of the POP3 mailbox. The no-apop flag forces fdm(1) not to use the POP3 APOP command for authentication, and the no-verify keyword instructs fdm(1) to skip SSL certificate validation for this account. The no-uidl keyword makes fdm(1) not use the UIDL command to retrieve mails. This is mainly useful for broken POP3 servers.

starttls attempts to use STARTTLS after connection.

insecure allows the use of insecure protocols, which currently includes SSLv2, SSLv3 and TLS1.0.

pop3 pipe command [userpass] [only] [no-apop]

This account type uses the POP3 protocol piped through command, such as ssh(1). If the command produces any output to stderr, it is logged. For POP3 over a pipe, providing a user and password is not optional and it may not be read from ~/.netrc.

imap server host [port port] [userpass] [folder name] [only] [no-cram-md5] [no-plain] [no-login] [starttls] [insecure] [oauthbearer] [xoauth2]

imap server host [port port] [userpass] [folders] { name ... } [only]

imaps server host [port port] [userpass] [folders] [only] [no-verify] [no-cram-md5] [no-plain] [no-login] [insecure] [oauthbearer] [xoauth2]

These define an IMAP or IMAPS account. The parameters are as for a POP3 or POP3S account, aside from the additional folders option which sets the name of the folder or folders to use (the default is to fetch from the inbox). This has the form: folder name | folders { name ... }

The default ports used are 143 for IMAP and 993 for IMAPS. For IMAP, the only item consists only of one of the keywords new-only or old-only - a cache file is not required.

Options no-cram-md5, no-plain and no-login disable the given authentication method. The default is to use CRAM-MD5 if it is available, then PLAIN, and LOGIN otherwise.

starttls attempts to use STARTTLS after connection.

insecure allows the use of insecure protocols, which currently includes SSLv2, SSLv3 and TLS1.0.

oauthbearer attempts to use OAuth 2.0 bearer token as authentication method.

imap pipe command [userpass] [folders] [only]

As with pop3 pipe, this account type uses the IMAP protocol piped through command. If the optional IMAP user and pass are supplied, they will be used if necessary, but if one is provided, both must be – using ~/.netrc is not permitted. Mail fetched using the IMAP protocol is tagged with a folder tag containing the source folder name.

maildir path

maildirs { path ... }

These account types instruct fdm(1) to fetch mail from the maildir or maildirs specified. This allows fdm(1) to be used to filter mail, fetching from a maildir and deleting (dropping) unwanted mail, or delivering mail to another maildir or to an mbox. Mail fetched from a maildir is tagged with a maildir tag containing the basename of the mail file.

mbox path

mboxes { path ... }

These are similar to maildir and maildirs, but cause fdm(1) to fetch mail from an mbox or set of mboxes. Mail fetched from a mbox is tagged with a mbox tag containing the basename of the mbox file.

nntp server host [port port] [userpass] group group cache cache

nntp server host [port port] [userpass] groups { group ... } cache cache

nntps server host [port port] [userpass] group group cache cache

nntps server host [port port] [userpass] groups { group ... } cache cache

An NNTP account. Articles are fetched from the specified group or groups and delivered. The index and message-id of the last article fetched in each group is saved in the specified cache file. When fdm(1) is run again, fetching begins at the cached article. Note that the keep option is completely ignored for NNTP accounts – all mail is kept, and the cache is always updated.

## TAGGING
As mail is processed by fdm(1), it is tagged with a number of name/value pairs. Some tags are added automatically, and mail may also be tagged explicitly by the user using the tag action. Tags may be inserted in most strings in a similar manner to macros, except tags are processed at runtime rather than as the configuration file is parsed. A tag's value is inserted by wrapping its name in %[], for example:

abc%[account]def

%[hour]:%[minute]:%[second]

The default tags also have a single-letter shorthand. Including a nonexistent tag in a string is equivalent to including a tag with an empty value, so "abc%[nonexistent]def" will be translated to "abcdef".

The automatically added tags are:

account (%a)

The name of the account from which the mail was fetched.

home (%h)

The delivery user's home directory.

uid (%n)

The delivery user's uid.

action (%t)

The name of the last action executed for this mail.

user (%u)

The delivery user's username.

hour (%H)

The current hour (00–23).

minute (%M)

The current minute (00–59).

second (%S)

The current second (00–59).

day (%d)

The current day of the month (01–31).

month (%m)

The current month (01–12).

year (%y)

The current year.

year2

The current year as two digits.

dayofweek (%W)

The current day of the week (0–6, Sunday is 0).

dayofyear (%Y)

The current day of the year (001–366).

quarter (%Q)

The current quarter (1–4).

rfc822date

The current date in RFC822 format.

mail_hour

The hour from the mail's date header, if it exists and is valid, otherwise the current time.

mail_minute

The minute from the mail's date header.

mail_second

The second from the mail's date header.

mail_day

The day from the mail's date header.

mail_month

The month from the mail's date header.

mail_year

The year from the mail's date header.

mail_year2

The same as two digits.

mail_dayofweek

The day of the week from the mail's date header.

mail_dayofyear

The day of the year from the mail's date header.

mail_quarter

The quarter (1–4) from the mail's date header.

mail_rfc822date

The mail's date in RFC822 format.

lines

The total number of lines in the message.

body_lines

The number of lines in the body.

header_lines

The number of lines in the header.

message_id

The message id from the mail's header (if present).

hostname

The local hostname.

In addition, the shorthand %% is replaced with a literal %, and %0 to %9 are replaced with the result of any bracket expressions in the last regexp.

## CACHES
fdm(1) can maintain a cache file with a set of user-defined strings. In order to use caches, fdm(1) must have been compiled with them enabled. Caches are declared with the cache keyword:

cache path [expire age]

The path is the location of the cache file. If the expire keyword is specified, items in the cache are removed after they reach the age specified. age may be given unadorned in seconds, or followed by one of the modifiers: seconds, hours, minutes, days, months or years.

Caches must be declared before they are used. Items are added to caches using the add-to-cache action, removed using the remove-from-cache action, and searched for using the in-cache condition; see below for information on these.

## ACTIONS
The action command is used to define actions. These may be specified by name in rules (see below) to perform some action on a mail. The syntax is:

action name [users] action

action name [users] { action ... }

The name is a string defining a name for the action. The users argument has the same form as for an account definition. An action's user setting may be overridden in the matching rule.

The possible values for action are listed below. If multiple actions are specified they are executed once in the order specified, for each user.

drop

Discard the mail.

keep

Keep the mail, do not remove it from the account.

tag string [value value]

This tags mail with string, and optionally value, which may be matched using the tagged or string conditions.

maildir path

Save the mail to the maildir specified by path. If the maildir or any part of its path does not exist, it is created, unless the no-create option is set. Mail delivered to a maildir is tagged with a mail_file tag containing the full path of the mail file.

mbox path [compress]

Append the mail to the mbox at path. If compress is specified, fdm(1) will add ‘.gz’ to path and attempt to write mail using gzip(1) compression. If the mbox or any part of its path does not exist, it is created, unless the no-create option is set. Mail delivered to an mbox is tagged with a mbox_file tag containing the path of the mbox.

exec command

Execute command.

pipe command

Pipe the mail to command. exec and pipe commands are run as the command user.

write path

Write the mail to path.

append path

Append the mail to path.

smtp server host [port port] [from from] [to to]

Connect to an SMTP server and attempt to deliver the mail to it. If from or to is specified, they are passed to the server in the MAIL FROM or RCPT TO commands. If not, the current user and host names are used.

lmtp server path | host [port port] [from from] [to to]

Connect to an LMTP server and attempt to store the mail there. If a UNIX socket is to be used, path must be the absolute pathname. port defaults to 24. If from or to is specified, they are passed to the server in the MAIL FROM or RCPT TO commands. If not, the current user and host names are used.

rewrite command

Pipe the entire mail through command to generate a new mail and use that mail for any following actions or rules. An example of the rewrite action is:

```
action "cat" pipe "cat"
action "rewrite" rewrite "sed 's/bob/fred/g'"
# this rule will rewrite the message
match all action "rewrite" continue
# this rule will cat the rewritten message
match all action "cat"
```

add-header name value value

Add a header name with contents value.

remove-header name

remove-headers { name ... }

Remove all occurrences of headers matching the fnmatch(3) pattern name.

stdout

Write the mail to stdout.

add-to-cache path key key

This action adds the string key to the cache specified by path. If key already exists in the cache, it is replaced.

remove-from-cache path key key

Remove the string key from the cache path, if a matching key is present.

action name

This invokes another named action. A maximum of five actions may be called in a sequence.

## RULES
Rules are specified using the match keyword. It has the following basic form:

match condition [and | or condition ...] [users] actions [continue]

The condition argument may be one of:

all

Matches all mail.

matched

Matches only mail that has matched a previous rule and been passed on with continue.

unmatched

The opposite of matched: matches only mails which have matched no previous rules.

account name | accounts { name ... }

Matches only mail fetched from the named account or accounts. The account names may include shell glob wildcards to match multiple accounts, as with the -a and -x command line options.

tagged string

Matches mails tagged with string.

[case] regexp [in headers | in body]

Specifies a regexp against which each mail should be matched. The regexp matches may be restricted to either the headers or body of the message by specifying either in headers or in body. The case keyword forces the regexp to be matched case-sensitively: the default is case-insensitive matching.

exec command [user user] returns (return code, stdout regexp)

pipe command [user user] returns (return code, [case] stdout regexp)

These two conditions execute a command and test its return value and output. The return code argument is the numeric return code expected and stdout regexp is a regexp to be tested against the output of the command to stdout. Either of these two arguments may be omitted: if both are specified, both must match for the condition to be true. The pipe version will pipe the mail to the command's stdin when executing it. If a user is specified, fdm(1) will change to that user before executing the command, otherwise the current user (or root if started as root) is used.

size < number

size > number

Compare the mail size with number.

string string to [case] regexp

Match string against regexp.

age < time

age > time

The age condition examines the mail's date header to determine its age, and matches if the mail is older (>) or newer (<) than the time specified. The time may be given as a simple number in seconds, or followed by the word seconds, hours, minutes, days, months or years to specify a time in different units.

in-cache path key key

This condition evaluates to true if the string key is in the cache at path.

attachment count < number

attachment count > number

attachment count == number

attachment count != number

These conditions match if the mail possesses a number of attachments less than, greater than, equal to or not equal to number.

attachment total-size < size

attachment total-size > size

Matches if the total size of all attachments is smaller or larger than size.

attachment any-size < size

attachment any-size > size

Compare each individual attachment on a mail to size and match if any of them are smaller or larger.

attachment any-type string

attachment any-name string

Match true if any of a mail's attachments possesses a MIME type or filename that matches string. fnmatch(3) wildcards may be used.

Multiple conditions may be chained together using the and or or keywords. The conditions are tested from left to right. Any condition may be prefixed by the not keyword to invert it.

The optional users argument to the first form has the same syntax as for an action definition. A rule's user list overrides any users given as part of the actions.

The actions list specifies the actions to perform when the rule matches a mail. It is either of a similar form:

action name | actions { name ... }

Or may specify a number of actions inline (lambda actions):

action action

action { action ... }

In the latter case, action follows the same form as described in the ACTIONS section. The actions are performed from first to last in the order they are specified in the rule definition.

If the continue keyword is present, evaluation will not stop if this rule is matched. Instead, fdm(1) will continue to match further rules after performing any actions for this rule.

## NESTED RULES
Rules may be nested by specifying further rules in braces:

match condition [and | or condition ...] {

match ...

}

The inner rules will not be evaluated unless the outer one matches. Rules may be multiply nested. Note that the outer rule does not count as a match for the purposes of the matched and unmatched conditions.

## FILES
~/.fdm.conf

default fdm.conf configuration file

/etc/fdm.conf

default system-wide configuration file

~/.fdm.lock

default lock file

/var/db/fdm.lock

lock file for root user

## SEE ALSO
fdm(1), re_format(7)

## AUTHORS
Nicholas Marriott <nicholas.marriott@gmail.com>


feedback-themes

package: feedbackd

title: feedback-themes(5)

summary: Theme configuration for feedbackd

text:
# feedback-themes(5)

## Name
feedback-themes - Theme configuration for feedbackd

## DESCRIPTION
The feedback provided to the user for an event is determined by the currently active feedback theme.

Each theme consists of up to three profile sections named full, quiet and silent containing event names and their associated feedback. They can reference another theme via the parent-name element to avoid repetition. If an event received by the daemon is not present in the currently active theme or its parent theme it will be ignored.

Each event maps to at most one feedback in each profile. The events in the theme are named according to the Event Naming Specifiaction <https://gitlab.freedesktop.org/agx/feedbackd/-/blob/main/doc/Event-naming-spec-0.0.0.md>.

There are two types of themes: custom themes and device themes. They both use the same format but have different purpose. Custom themes are meant to tweak feebackd's output to the user's needs while device themes are meant to cater for hardware differences. Feedback themes use a JSON format that can be validated with fbd-theme-validate(1).

For details on how to create or modify feedback themes see feedbackd's documentation at <https://gitlab.freedesktop.org/agx/feedbackd#feedback-theme>.

## Feedback types
To build a theme you can use several different feedback types:

- Sound: Plays a sound from the installed sound theme

- VibraRumble: A single rumble using the haptic motor

- VibraPeriodic: A periodic rumble using the haptic motor

- VibraPattern: A pattern specifying the rumbling of the haptic motor

- Led: A LED blinking in a periodic pattern

### Sound feedback
Sound feedbacks specify an event name from a XDG sound theme. Sound themes are described in the Sound theme spec at <https://freedesktop.org/wiki/Specifications/sound-theme-spec/>

- event-name: The sound event name to use.

- media-role: The media role to set played audio stream. Defaults to event.

Sound feedback is usually used in the full profile section of the theme only.

### VibraRumble feedback
The VibraRumble feedback uses a single property

- count: The number of rumbles.

- pause: The pause between each rumble in ms.

- duration: The duration of the rumble in ms.

- mangitude: The relative magnitude of the rumble ([0, 1]).

VibraRumble feedback is usually used in the quiet profile section of the theme only.

### VibraPattern feedback
The VibraPattern feedback has these properties

- magnitudes: The relative magnitude of each rumble [0, 1] as array of doubles.

- durations: The durations of each rumble in ms as array of unsigned integers.

Both arrays must have the same length. VibraPattern feedback is usually used in the quiet profile section of the the theme only.

### Led feedback
The Led feedback type uses two properties to specify the way a LED blinks.

- color: This specifies the color a LED should blink with. It supports the fixed color names red, green, blue and white as well as values in the RGB HEX format (#RRGGBB) where RR, GG and BB are two digit hex value between 00 and FF specifying the value of each component. E.g. #00FFFF corresponds to cyan color.

- frequency: The LEDs blinkinig frequency in mHz.

Led feedback is usually used in the silent profile section of the theme only.

### See also
feedbackd(8) fbcli(1) fbd-theme-validate(1)

branch: sisyphus


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 and each VM should have a separate unique socket. 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 (optional).

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. All libvirt URIs are accepted and passed as-is.

See https://libvirt.org/uri.html#remote-uris for examples.

NOTE: When VMs are run as non-root user the socket path must be set as part of the URI.

Example: qemu:///session?socket=/run/user/<UID>/libvirt/virtqemud-sock

### 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.

name

Optionally define the name of the group. Useful only for configuration readability and debugging of configuration parsing.

uuid

Defines UUID as a member of a group. It can be used multiple times to specify both node name and UUID values that can be fenced. When using the serial listener, the vm uuid is required and it is recommended to add also the vm name.

ip

Defines an IP which is allowed to send fencing requests for members of this group (e.g. for multicast). It can be used multiple times to allow more than 1 IP to send fencing requests to the group. It is highly recommended that this be used in conjunction with a key file. When using the vsock listener, ip should contain the CID value assigned by libvirt to the vm. When using the serial listener, ip value is not used and can be omitted.

## 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 {

name = "cluster1";

ip = "192.168.1.1";

ip = "192.168.1.2";

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

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

uuid = "node1";

uuid = "node2";

}

}

## 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)


magic

package: file

title: magic(5)

summary: file command's magic pattern file

text:
# magic(5)

## NAME
magic — file command's magic pattern file

## DESCRIPTION
This manual page documents the format of magic files as used by the file(1) command, version 5.47. The file(1) command identifies the type of a file using, among other tests, a test for whether the file contains certain “magic patterns”. The database of these “magic patterns” is usually located in a binary file in /usr/share/file/magic.mgc or a directory of source text magic pattern fragment files in /usr/share/file/magic. The database specifies what patterns are to be tested for, what message or MIME type to print if a particular pattern is found, and additional information to extract from the file.

The format of the source fragment files that are used to build this database is as follows: Each line of a fragment file specifies a test to be performed. A test compares the data starting at a particular offset in the file with a byte value, a string or a numeric value. If the test succeeds, a message is printed. The line consists of the following fields:

offset

A number specifying the offset (in bytes) into the file of the data which is to be tested. This offset can be a negative number if it is:

- The first direct offset of the magic entry (at continuation level 0), in which case it is interpreted an offset from end end of the file going backwards. This works only when a file descriptor to the file is available and it is a regular file.

- A continuation offset relative to the end of the last up-level field (&).

If the offset starts with the symbol “+”, then all offsets are interpreted as from the beginning of the file (the default).

type

The type of the data to be tested. The possible values are: byte

A one-byte value.

short

A two-byte value in this machine's native byte order.

long

A four-byte value in this machine's native byte order.

quad

An eight-byte value in this machine's native byte order.

float

A 32-bit single precision IEEE floating point number in this machine's native byte order.

double

A 64-bit double precision IEEE floating point number in this machine's native byte order.

string

A string of bytes. The string type specification can be optionally followed by a /<width> option and optionally followed by a set of flags [bCcftTtWw]*. Slash characters can be used to separate options for readability. The width limits the number of characters to be copied. Zero means all characters. The following flags are supported: b

Force binary file test.

C

Use upper case insensitive matching: upper case characters in the magic match both lower and upper case characters in the target, whereas lower case characters in the magic only match upper case characters in the target. (not valid for regex)

c

Use lower case insensitive matching: lower case characters in the magic match both lower and upper case characters in the target, whereas upper case characters in the magic only match upper case characters in the target. (not valid for regex) To do a complete case insensitive match, specify both “c” and “C”.

f

Require that the matched string is a full word, not a partial word match.

s

Don't include the match length in the offset computation. (only valid for search and regex)

T

Trim the string, i.e. leading and trailing whitespace is deleted before the string is printed.

t

Force text file test.

W

Compact whitespace in the target, which must contain at least one whitespace character. (not valid for regex) If the magic has n consecutive blanks, the target needs at least n consecutive blanks to match.

w

Treat every blank in the magic as an optional blank. (not valid for regex)

pstring

A Pascal-style string where the first byte/short/int is interpreted as the unsigned length. The length defaults to byte and can be specified as a modifier. The following modifiers are supported: B

A byte length (default).

H

A 2 byte big endian length.

h

A 2 byte little endian length.

L

A 4 byte big endian length.

l

A 4 byte little endian length.

J

The length includes itself in its count.

The string is not NUL terminated. “J” is used rather than the more valuable “I” because this type of length is a feature of the JPEG format.

date

A four-byte value interpreted as a UNIX date.

qdate

An eight-byte value interpreted as a UNIX date.

ldate

A four-byte value interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

qldate

An eight-byte value interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

qwdate

An eight-byte value interpreted as a Windows-style date.

msdosdate

A two-byte value interpreted as FAT/DOS-style date.

msdostime

A two-byte value interpreted as FAT/DOS-style time.

beid3

A 32-bit ID3 length in big-endian byte order.

beshort

A two-byte value in big-endian byte order.

belong

A four-byte value in big-endian byte order.

bequad

An eight-byte value in big-endian byte order.

befloat

A 32-bit single precision IEEE floating point number in big-endian byte order.

bedouble

A 64-bit double precision IEEE floating point number in big-endian byte order.

bedate

A four-byte value in big-endian byte order, interpreted as a Unix date.

beqdate

An eight-byte value in big-endian byte order, interpreted as a Unix date.

beldate

A four-byte value in big-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

beqldate

An eight-byte value in big-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

beqwdate

An eight-byte value in big-endian byte order, interpreted as a Windows-style date.

bemsdosdate

A two-byte value in big-endian byte order, interpreted as FAT/DOS-style date.

bemsdostime

A two-byte value in big-endian byte order, interpreted as FAT/DOS-style time.

bestring16

A two-byte unicode (UCS16) string in big-endian byte order.

leid3

A 32-bit ID3 length in little-endian byte order.

leshort

A two-byte value in little-endian byte order.

lelong

A four-byte value in little-endian byte order.

lequad

An eight-byte value in little-endian byte order.

lefloat

A 32-bit single precision IEEE floating point number in little-endian byte order.

ledouble

A 64-bit double precision IEEE floating point number in little-endian byte order.

ledate

A four-byte value in little-endian byte order, interpreted as a UNIX date.

leqdate

An eight-byte value in little-endian byte order, interpreted as a UNIX date.

leldate

A four-byte value in little-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

leqldate

An eight-byte value in little-endian byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

leqwdate

An eight-byte value in little-endian byte order, interpreted as a Windows-style date.

lemsdosdate

A two-byte value in little-endian byte order, interpreted as FAT/DOS-style date.

lemsdostime

A two-byte value in little-endian byte order, interpreted as FAT/DOS-style time.

lestring16

A two-byte unicode (UCS16) string in little-endian byte order.

melong

A four-byte value in middle-endian (PDP-11) byte order.

medate

A four-byte value in middle-endian (PDP-11) byte order, interpreted as a UNIX date.

meldate

A four-byte value in middle-endian (PDP-11) byte order, interpreted as a UNIX-style date, but interpreted as local time rather than UTC.

indirect

Starting at the given offset, consult the magic database again. The offset of the indirect magic is by default absolute in the file, but one can specify /r to indicate that the offset is relative from the beginning of the entry.

name

Define a “named” magic instance that can be called from another use magic entry, like a subroutine call. Named instance direct magic offsets are relative to the offset of the previous matched entry, but indirect offsets are relative to the beginning of the file as usual. Named magic entries return true if there was a match in the evaluation of the entry, or if there was a previous existing match.

use

Recursively call the named magic starting from the current offset. If the name of the referenced begins with a ^ then the endianness of the magic is switched; if the magic mentioned leshort for example, it is treated as beshort and vice versa. This is useful to avoid duplicating the rules for different endianness.

regex

A regular expression match in extended POSIX regular expression syntax (like egrep). Regular expressions can take exponential time to process, and their performance is hard to predict, so their use is discouraged. When used in production environments, their performance should be carefully checked. The size of the string to search should also be limited by specifying /<length>, to avoid performance issues scanning long files. The type specification can also be optionally followed by /[c][s][l]. The “c” flag makes the match case insensitive, while the “s” flag update the offset to the start offset of the match, rather than the end. The “l” modifier, changes the limit of length to mean number of lines instead of a byte count. Lines are delimited by the platforms native line delimiter. When a line count is specified, an implicit byte count also computed assuming each line is 80 characters long. If neither a byte or line count is specified, the search is limited automatically to 8KiB. ^ and $ match the beginning and end of individual lines, respectively, not beginning and end of file.

search

A literal string search starting at the given offset. The same modifier flags can be used as for string patterns. The search expression must contain the range in the form /number, that is the number of positions at which the match will be attempted, starting from the start offset. This is suitable for searching larger binary expressions with variable offsets, using \ escapes for special characters. The order of modifier and number is not relevant.

default

This is intended to be used with the test x (which is always true) and it has no type. It matches when no other test at that continuation level has matched before. Clearing that matched tests for a continuation level, can be done using the clear test.

clear

This test is always true and clears the match flag for that continuation level. It is intended to be used with the default test.

der

Parse the file as a DER Certificate file. The test field is used as a der type that needs to be matched. The DER types are: eoc, bool, int, bit_str, octet_str, null, obj_id, obj_desc, ext, real, enum, embed, utf8_str, rel_oid, time, res2, seq, set, num_str, prt_str, t61_str, vid_str, ia5_str, utc_time, gen_time, gr_str, vis_str, gen_str, univ_str, char_str, bmp_str, date, tod, datetime, duration, oid-iri, rel-oid-iri. These types can be followed by an optional numeric size, which indicates the field width in bytes.

guid

A Globally Unique Identifier, parsed and printed as XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. It's format is a string.

offset

This is a quad value indicating the current offset of the file. It can be used to determine the size of the file or the magic buffer. For example the magic entries:

```
-0	offset	x	this file is %lld bytes
-0	offset	<=100	must be more than 100 \
    bytes and is only %lld
```

octal

A string representing an octal number.

For compatibility with the Single UNIX Standard, the type specifiers dC and d1 are equivalent to byte, the type specifiers uC and u1 are equivalent to ubyte, the type specifiers dS and d2 are equivalent to short, the type specifiers uS and u2 are equivalent to ushort, the type specifiers dI, dL, and d4 are equivalent to long, the type specifiers uI, uL, and u4 are equivalent to ulong, the type specifier d8 is equivalent to quad, the type specifier u8 is equivalent to uquad, and the type specifier s is equivalent to string. In addition, the type specifier dQ is equivalent to quad and the type specifier uQ is equivalent to uquad.

Each top-level magic pattern (see below for an explanation of levels) is classified as text or binary according to the types used. Types “regex” and “search” are classified as text tests, unless non-printable characters are used in the pattern. All other tests are classified as binary. A top-level pattern is considered to be a test text when all its patterns are text patterns; otherwise, it is considered to be a binary pattern. When matching a file, binary patterns are tried first; if no match is found, and the file looks like text, then its encoding is determined and the text patterns are tried.

The numeric types may optionally be followed by an operand and a numeric value, to specify that the value is to be modified according to the operand and the numeric value before any comparisons are done. The following operands are supported: &, |, ↑, +, -, *, /, %. Prepending a u to the type indicates that ordered comparisons should be unsigned.

test

The value to be compared with the value from the file. If the type is numeric, this value is specified in C form; if it is a string, it is specified as a C string with the usual escapes permitted (e.g. \n for new-line). Numeric values may be preceded by a character indicating the operation to be performed. It may be =, to specify that the value from the file must equal the specified value, <, to specify that the value from the file must be less than the specified value, >, to specify that the value from the file must be greater than the specified value, &, to specify that the value from the file must have set all of the bits that are set in the specified value, ^, to specify that the value from the file must have clear any of the bits that are set in the specified value, or ~, the value specified after is negated before tested. x, to specify that any value will match. If the character is omitted, it is assumed to be =. Operators &, ^, and ~ don't work with floats and doubles. The operator ! specifies that the line matches if the test does not succeed.

Numeric values are specified in C form; e.g. 13 is decimal, 013 is octal, and 0x13 is hexadecimal.

Numeric operations are not performed on date types, instead the numeric value is interpreted as an offset.

For string values, the string from the file must match the specified string. The operators =, < and > (but not &) can be applied to strings. The length used for matching is that of the string argument in the magic file. This means that a line can match any non-empty string (usually used to then print the string), with >\0 (because all non-empty strings are greater than the empty string).

Dates are treated as numerical values in the respective internal representation.

The special test x always evaluates to true.

message

The message to be printed if the comparison succeeds. If the string contains a printf(3) format specification, the value from the file (with any specified masking performed) is printed using the message as the format string. If the string begins with “\b”, the message printed is the remainder of the string with no whitespace added before it: multiple matches are normally separated by a single space.

An APPLE 4+4 character APPLE creator and type can be specified as:

```
!:apple	CREATYPE
```

A slash-separated list of commonly found filename extensions can be specified as:

```
!:ext	ext[/ext...]
```

i.e. the literal string “!:ext” followed by a slash-separated list of commonly found extensions; for example for JPEG images:

```
!:ext jpeg/jpg/jpe/jfif
```

A MIME type is given on a separate line, which must be the next non-blank or comment line after the magic line that identifies the file type, and has the following format:

```
!:mime	MIMETYPE
```

i.e. the literal string “!:mime” followed by the MIME type.

An optional strength can be supplied on a separate line which refers to the current magic description using the following format:

```
!:strength OP VALUE
```

The operand OP can be: +, -, *, or / and VALUE is a constant between 0 and 255. This constant is applied using the specified operand to the currently computed default magic strength.

Some file formats contain additional information which is to be printed along with the file type or need additional tests to determine the true file type. These additional tests are introduced by one or more > characters preceding the offset. The number of > on the line indicates the level of the test; a line with no > at the beginning is considered to be at level 0. Tests are arranged in a tree-like hierarchy: if the test on a line at level n succeeds, all following tests at level n+1 are performed, and the messages printed if the tests succeed, until a line with level n (or less) appears. For more complex files, one can use empty messages to get just the "if/then" effect, in the following way:

```
0      string    MZ
>0x18  uleshort  <0x40   MS-DOS executable
>0x18  uleshort  >0x3f   extended PC executable (e.g., MS Windows)
```

Offsets do not need to be constant, but can also be read from the file being examined. If the first character following the last > is a ( then the string after the parenthesis is interpreted as an indirect offset. That means that the number after the parenthesis is used as an offset in the file. The value at that offset is read, and is used again as an offset in the file. Indirect offsets are of the form: (x [[.,][bBcCeEfFgGhHiIlmosSqQ]][+-][ y ]). The value of x is used as an offset in the file. A byte, id3 length, short or long is read at that offset depending on the [bBcCeEfFgGhHiIlLmsSqQ] type specifier. The value is treated as signed if “,” is specified or unsigned if “.” is specified. The capitalized types interpret the number as a big endian value, whereas the small letter versions interpret the number as a little endian value; the m type interprets the number as a middle endian (PDP-11) value. To that number the value of y is added and the result is used as an offset in the file. The default type if one is not specified is long. The following types are recognized:

Type

Sy Mnemonic

Sy Endian

Sy Size

bcBC

Byte/Char

N/A

1

efg

Double

Little

8

EFG

Double

Big

8

hs

Half/Short

Little

2

HS

Half/Short

Big

2

i

ID3

Little

4

I

ID3

Big

4

l

Long

Little

4

L

Long

Big

4

m

Middle

Middle

4

o

Octal

Textual

Variable

q

Quad

Little

8

Q

Quad

Big

8

That way variable length structures can be examined:

```
# MS Windows executables are also valid MS-DOS executables
0           string   MZ
>0x18       uleshort <0x40  MZ executable (MS-DOS)
# skip the whole block below if it is not an extended executable
>0x18       uleshort >0x3f
>>(0x3c.l)  string   PE\0\0 PE executable (MS-Windows)
>>(0x3c.l)  string   LX\0\0 LX executable (OS/2)
```

This strategy of examining has a drawback: you must make sure that you eventually print something, or users may get empty output (such as when there is neither PE\0\0 nor LE\0\0 in the above example).

If this indirect offset cannot be used directly, simple calculations are possible: appending [+-*/%&|^]number inside parentheses allows one to modify the value read from the file before it is used as an offset:

```
# MS Windows executables are also valid MS-DOS executables
0           string   MZ
# sometimes, the value at 0x18 is less that 0x40 but there's still an
# extended executable, simply appended to the file
>0x18       uleshort <0x40
>>(4.s*512) leshort  0x014c  COFF executable (MS-DOS, DJGPP)
>>(4.s*512) leshort  !0x014c MZ executable (MS-DOS)
```

Sometimes you do not know the exact offset as this depends on the length or position (when indirection was used before) of preceding fields. You can specify an offset relative to the end of the last up-level field using ‘&’ as a prefix to the offset:

```
0           string   MZ
>0x18       uleshort >0x3f
>>(0x3c.l)  string   PE\0\0    PE executable (MS-Windows)
# immediately following the PE signature is the CPU type
>>>&0       leshort  0x14c     for Intel 80386
>>>&0       leshort  0x8664    for x86-64
>>>&0       leshort  0x184     for DEC Alpha
```

Indirect and relative offsets can be combined:

```
0             string   MZ
>0x18         uleshort <0x40
>>(4.s*512)   leshort  !0x014c MZ executable (MS-DOS)
# if it's not COFF, go back 512 bytes and add the offset taken
# from byte 2/3, which is yet another way of finding the start
# of the extended executable
>>>&(2.s-514) string   LE      LE executable (MS Windows VxD driver)
```

Or the other way around:

```
0                 string   MZ
>0x18             uleshort >0x3f
>>(0x3c.l)        string   LE\0\0  LE executable (MS-Windows)
# at offset 0x80 (-4, since relative offsets start at the end
# of the up-level match) inside the LE header, we find the absolute
# offset to the code area, where we look for a specific signature
>>>(&0x7c.l+0x26) string   UPX     \b, UPX compressed
```

Or even both!

```
0                string   MZ
>0x18            uleshort >0x3f
>>(0x3c.l)       string   LE\0\0 LE executable (MS-Windows)
# at offset 0x58 inside the LE header, we find the relative offset
# to a data area where we look for a specific signature
>>>&(&0x54.l-3)  string   UNACE  \b, ACE self-extracting archive
```

If you have to deal with offset/length pairs in your file, even the second value in a parenthesized expression can be taken from the file itself, using another set of parentheses. Note that this additional indirect offset is always relative to the start of the main indirect offset.

```
0                 string       MZ
>0x18             uleshort     >0x3f
>>(0x3c.l)        string       PE\0\0 PE executable (MS-Windows)
# search for the PE section called ".idata"...
>>>&0xf4          search/0x140 .idata
# ...and go to the end of it, calculated from start+length;
# these are located 14 and 10 bytes after the section name
>>>>(&0xe.l+(-4)) string       PK\3\4 \b, ZIP self-extracting archive
```

If you have a list of known values at a particular continuation level, and you want to provide a switch-like default case:

```
# clear that continuation level match
>18	clear	x
>18	lelong	1	one
>18	lelong	2	two
>18	default	x
# print default match
>>18	lelong	x	unmatched 0x%x
```

## SEE ALSO
file(1) - the command that reads this file.

## BUGS
The formats long, belong, lelong, melong, short, beshort, and leshort do not depend on the length of the C data types short and long on the platform, even though the Single UNIX Specification implies that they do. However, as OS X Mountain Lion has passed the Single UNIX Specification validation suite, and supplies a version of file(1) in which they do not depend on the sizes of the C data types and that is built for a 64-bit environment in which long is 8 bytes rather than 4 bytes, presumably the validation suite does not test whether, for example long refers to an item with the same size as the C data type long. There should probably be type names int8, uint8, int16, uint16, int32, uint32, int64, and uint64, and specified-byte-order variants of them, to make it clearer that those types have specified widths.


fzdefaults.xml

package: filezilla

title: fzdefaults.xml(5)

summary: Default options for FileZilla

text:
# fzdefaults.xml(5)

## NAME
fzdefaults.xml - Default options for FileZilla

## SYNOPSIS
/etc/filezilla/fzdefaults.xml

~/.filezilla/fzdefaults.xml

## DESCRIPTION
This configuration file can be used to specify some system‐wide default options for FileZilla:

- Location of user's settings directory

- Predefined list of Sitemanager entries

- Kiosk mode to prevent FileZilla from saving any passwords

- Disabling of update check capablity

Please search for the file fzdefaults.xml.example for further information. It is often found in the /usr/share/filezilla/docs directory.

## SUPPORT
Please visit https://filezilla-project.org/ for further information. Report bugs only if you are using the latest version available from the FileZilla website.

## COPYRIGHT
Copyright (C) 2004-2026 Tim Kosse

FileZilla is distributed under the terms of the GNU General Public License version 2 or later.

## SEE ALSO
filezilla(1)


firehol-action

package: firehol

title: firehol-action(5)

text:
# firehol-action(5)

## NAME
firehol - an easy to use but powerful iptables stateful firewall

## SYNOPSIS
firehol

sudo -E firehol panic [ IP ]

firehol command [ -- conf-arg... ]

firehol CONFIGFILE [start|debug|try] [-- conf-arg... ]

## DESCRIPTION
Running firehol invokes iptables(8) to manipulate your firewall.

Run without any arguments, firehol will present some help on usage.

When given CONFIGFILE, firehol will use the named file instead of /etc/firehol/firehol.conf as its configuration. If no command is given, firehol assumes try.

It is possible to pass arguments for use by the configuration file separating any conf-arg values from the rest of the arguments with --. The arguments are accessible in the configuration using standard bash(1) syntax e.g. $1, $2, etc.

### PANIC
To block all communication, invoke firehol with the panic command.

FireHOL removes all rules from the running firewall and then DROPs all traffic on all iptables(8) tables (mangle, nat, filter) and pre-defined chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).

DROPing is not done by changing the default policy to DROP, but by adding one rule per table/chain to drop all traffic. This allows systems which do not reset all the chains to ACCEPT when starting to function correctly.

When activating panic mode, FireHOL checks for the existence of the SSH_CLIENT shell environment variable, which is set by ssh(1). If it finds this, then panic mode will allow the established SSH connection specified in this variable to operate.

Note

In order for FireHOL to see the environment variable you must ensure that it is preserved. For sudo(8) use the -E and for su(1) omit the - (minus sign).

If SSH_CLIENT is not set, the IP after the panic argument allows you to give an IP address for which all established connections between the IP address and the host in panic will be allowed to continue.

## COMMANDS
start; restart

Activates the firewall using /etc/firehol/firehol.conf.

Use of the term restart is allowed for compatibility with common init implementations.

try

Activates the firewall, waiting for the user to type the word commit. If this word is not typed within 30 seconds, the previous firewall is restored.

stop

Stops a running iptables(8) firewall by clearing all of the tables and chains and setting the default policies to ACCEPT. This will allow all traffic to pass unchecked.

condrestart

Restarts the FireHOL firewall only if it is already active. This is the generally expected behaviour (but opposite to FireHOL prior to 2.0.0-pre4).

status

Shows the running firewall, using /sbin/iptables -nxvL | less.

save

Start the firewall and then save it using iptables-save(8) to the location given by FIREHOL_AUTOSAVE. See firehol-defaults.conf(5) for more information.

The required kernel modules are saved to an executable shell script /var/spool/firehol/last_save_modules.sh, which can be called during boot if a firewall is to be restored.

Note

External changes may cause a firewall restored after a reboot to not work as intended where starting the firewall with FireHOL will work.

This is because as part of starting a firewall, FireHOL checks some changeable values. For instance the current kernel configuration is checked (for client port ranges), and RPC servers are queried (to allow correct functioning of the NFS service).

debug

Parses the configuration file but instead of activating it, FireHOL shows the generated iptables(8) statements.

explain

Enters an interactive mode where FireHOL accepts normal configuration commands and presents the generated iptables(8) commands for each of them, together with some reasoning for its purpose.

Additionally, FireHOL automatically generates a configuration script based on the successful commands given.

Some extra commands are available in explain mode.

help

Present some help

show

Present the generated configuration

quit

Exit interactive mode and quit

helpme; wizard

Tries to guess the FireHOL configuration needed for the current machine.

FireHOL will not stop or alter the running firewall. The configuration file is given in the standard output of firehol, thus firehol helpme > /tmp/firehol.conf will produce the output in /tmp/firehol.conf.

The generated FireHOL configuration must be edited before use on your systems. You are required to take a number of decisions; the comments in the generated file will instruct you in the choices you must make.

## FILES
/etc/firehol/firehol.conf

## SEE ALSO
•

firehol.conf(5) - FireHOL configuration

•

firehol-defaults.conf(5) - control variables

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team; Original man page by Marc Brockschmidt.


firehol-actions

title: firehol-actions(5)

summary: actions for rules

text:
# firehol-actions(5)

## NAME
firehol-actions - actions for rules

## SYNOPSIS
accept

accept with hashlimit name upto|above amount/period [burst amount] [mode {srcip|srcport|dstip|dstport},...] [srcmask prefix] [dstmask prefix] [htable-size buckets] [htable-max entries] [htable-expire msec] [htable-gcinterval msec]

accept with connlimit upto|above limit [mask mask] [saddr|daddr]

accept with limit requests/period burst [overflow action]

accept with recent name seconds hits

accept with knock name

reject [with message]

drop | deny

return

tarpit

## DESCRIPTION
These actions are the actions to be taken on traffic that has been matched by a particular rule.

FireHOL will also pass through any actions that iptables(8) accepts, however these definitions provide lowercase versions which accept arguments where appropriate and which could otherwise not be passed through.

Note

The iptables(8) LOG action is best used through the optional rule parameter log since the latter can be combined with one of these actions (FireHOL will generate multiple firewall rules to make this happen). For more information see log and loglimit.

The following actions are defined:

### accept
accept allows the traffic matching the rules to reach its destination.

For example, to allow SMTP requests and their replies to flow:

```
server smtp accept

```

### accept with hashlimit name upto|above
amount/period [burst amount] [mode {srcip|srcport|dstip|dstport},...] [srcmask prefix] [dstmask prefix] [htable-size buckets] [htable-max entries] [htable-expire msec] [htable-gcinterval msec]

hashlimit hashlimit uses hash buckets to express a rate limiting match (like the limit match) for a group of connections using a single iptables rule. Grouping can be done per-hostgroup (source and/or destination address) and/or per-port.

name The name for the /proc/net/ipt_hashlimit/name entry.

upto amount[/second|/minute|/hour|/day] Match if the rate is below or equal to amount/quantum. It is specified either as a number, with an optional time quantum suffix (the default is 3/hour).

above amount[/second|/minute|/hour|/day] Match if the rate is above amount/quantum.

burst amount Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5. This option should be used with caution - if the entry expires, the burst value is reset too.

mode {srcip|srcport|dstip|dstport},... A comma-separated list of objects to take into consideration. If no mode option is given, srcip,dstport is assumed.

srcmask prefix When --hashlimit-mode srcip is used, all source addresses encountered will be grouped according to the given prefix length and the so-created subnet will be subject to hashlimit. prefix must be between (inclusive) 0 and 32. Note that srcmask 0 is basically doing the same thing as not specifying srcip for mode, but is technically more expensive.

dstmask prefix Like srcmask, but for destination addresses.

htable-size buckets The number of buckets of the hash table

htable-max entries Maximum entries in the hash.

htable-expire msec After how many milliseconds do hash entries expire.

htable-gcinterval msec How many milliseconds between garbage collection intervals.

Examples:

Allow up to 5 connections per second per client to SMTP server:

```
server smtp accept with hashlimit smtplimit upto 5/s
```

You can monitor it using the file /proc/net/ipt_hashlimit/smtplimit

### accept with connlimit upto|above limit [mask mask]
[saddr|daddr]

accept with connlimit matches on the number of connections per IP.

saddr matches on source IP. daddr matches on destination IP. mask groups IPs with the mask given upto matches when the number of connections is up to the given limit above matches when the number of connections above to the given limit

The number of connections counted are system wide, not service specific. For example for saddr, you cannot connlimit 2 connections for SSH and 4 for SMTP. If you connlimit 2 connections for SSH, then the first 2 connections of a client can be SSH. If a client has already 2 connections to another service, the client will not be able to connect to SSH.

So, connlimit can safely be used:

•

with daddr to limit the connections a server can accept

•

with saddr to limit the total connections per client to all services.

### accept with limit requests/period burst [overflow
action]

accept with limit allows the traffic, with new connections limited to requests/period with a maximum burst. Run iptables -m limit --help for more information.

The default overflow action is to REJECT the excess connections (DROP would produce timeouts on otherwise valid service clients).

Examples:

```
server smtp accept with limit 10/sec 100
server smtp accept with limit 10/sec 100 overflow drop
```

### accept with recent name seconds hits
accept with recent allows the traffic matching the rules to reach its destination, limited per remote IP to hits per seconds. Run iptables -m recent --help for more information.

The name parameter is used to allow multiple rules to share the same table of recent IPs.

For example, to allow only 2 connections every 60 seconds per remote IP, to the smtp server:

```
server smtp accept with recent mail 60 2

```

Note

When a new connection is not allowed, the traffic will continue to be matched by the rest of the firewall. In other words, if the traffic is not allowed due to the limitations set here, it is not dropped, it is just not matched by this rule.

### accept with knock name
accept with knock allows easy integration with knockd (http://www.zeroflux.org/projects/knock/), a server that allows you to control access to services by sending certain packets to "knock" on the door, before the door is opened for service.

The name is used to build a special chain knock_<name> which contains rules to allow established connections to work. If knockd has not allowed new connections any traffic entering this chain will just return back and continue to match against the other rules until the end of the firewall.

For example, to allow HTTPS requests based on a knock write:

```
server https accept with knock hidden

```

then configure knockd to enable the HTTPS service with:

```
iptables -A knock_hidden -s %IP% -j ACCEPT

```

and disable it with:

```
iptables -D knock_hidden -s %IP% -j ACCEPT

```

You can use the same knock name in more than one FireHOL rule to enable/disable all the services based on a single knockd configuration entry.

Note

There is no need to match anything other than the IP in knockd. FireHOL already matches everything else needed for its rules to work.

### reject
reject discards the traffic matching the rules and sends a rejecting message back to the sender.

### reject with message
When used with with the specific message to return can be specified. Run iptables -j REJECT --help for a list of the --reject-with values which can be used for message. See REJECT WITH MESSAGES for some examples.

The default (no message specified) is to send tcp-reset when dealing with TCP connections and icmp-port-unreachable for all other protocols.

For example:

```
UNMATCHED_INPUT_POLICY="reject with host-prohib"
policy reject with host-unreach
server ident reject with tcp-reset
```

### drop; deny
drop discards the traffic matching the rules. It does so silently and the sender will need to timeout to conclude it cannot reach the service.

deny is a synonym for drop. For example, either of these would silently discard SMTP traffic:

```
server smtp drop
server smtp deny
```

### return
return will return the flow of processing to the parent of the current command.

Currently, the only time return can be used meaningfully used is as a policy for an interface definition. Unmatched traffic will continue being processed with the possibility of being matched by a later definition. For example:

```
policy return

```

### tarpit
tarpit captures and holds incoming TCP connections open.

Connections are accepted and immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds.

Attempts to close the connection are ignored, forcing the remote side to time out the connection after 12-24 minutes.

Example:

```
server smtp tarpit
```

Note

As the kernel conntrack modules are always loaded by FireHOL, some per-connection resources will be consumed. See this bug report (http://bugs.sanewall.org/sanewall/issues/10) for details.

The following actions also exist but should not be used under normal circumstances:

### mirror
mirror returns the traffic it receives by switching the source and destination fields. REJECT will be used for traffic generated by the local host.

Warning

The MIRROR target was removed from the Linux kernel due to its security implications.

MIRROR is dangerous; use it with care and only if you understand what you are doing.

### redirect; redirect to-port port
redirect is used internally by FireHOL helper commands.

Only FireHOL developers should need to use this action directly.

## REJECT WITH MESSAGES
The following RFCs contain information relevant to these messages:

•

RFC 1812 (http://www.ietf.org/rfc/rfc1812.txt)

•

RFC 1122 (http://www.ietf.org/rfc/rfc1122.txt)

•

RFC 792 (http://www.ietf.org/rfc/rfc0792.txt)

icmp-net-unreachable; net-unreach

ICMP network unreachable

Generated by a router if a forwarding path (route) to the destination network is not available.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

Note

Use with care. The sender and the routers between you and the sender may conclude that the whole network your host resides in is unreachable, and prevent other traffic from reaching you.

icmp-host-unreachable; host-unreach

ICMP host unreachable

Generated by a router if a forwarding path (route) to the destination host on a directly connected network is not available (does not respond to ARP).

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

Note

Use with care. The sender and the routers between you and the sender may conclude that your host is entirely unreachable, and prevent other traffic from reaching you.

icmp-proto-unreachable; proto-unreach

ICMP protocol unreachable

Generated if the transport protocol designated in a datagram is not supported in the transport layer of the final destination.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

icmp-port-unreachable; port-unreach

ICMP port unreachable

Generated if the designated transport protocol (e.g. TCP, UDP, etc.) is unable to demultiplex the datagram in the transport layer of the final destination but has no protocol mechanism to inform the sender.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 792.

Generated by hosts to indicate that the required port is not active.

icmp-net-prohibited; net-prohib

ICMP communication with destination network administratively prohibited

This code was intended for use by end-to-end encryption devices used by U.S. military agencies. Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 1122.

Note

This message may not be widely understood.

icmp-host-prohibited; host-prohib

ICMP communication with destination host administratively prohibited

This code was intended for use by end-to-end encryption devices used by U.S. military agencies. Routers SHOULD use the newly defined Code 13 (Communication Administratively Prohibited) if they administratively filter packets.

From RFC 1812, section 5.2.7.1. See RFC 1812 and RFC 1122.

Note

This message may not be widely understood.

tcp-reset

TCP RST

The port unreachable message of the TCP stack.

See RFC 1122.

Note

tcp-reset is useful when you want to prevent timeouts on rejected TCP services where the client incorrectly ignores ICMP port unreachable messages.

## SEE ALSO
•

firehol(1) - FireHOL program

•

firehol.conf(5) - FireHOL configuration

•

firehol-interface(5) - interface definition

•

firehol-router(5) - router definition

•

firehol-params(5) - optional rule parameters

•

FireHOL Website (http://firehol.org/)

•

FireHOL Online PDF Manual (http://firehol.org/firehol-manual.pdf)

•

FireHOL Online Documentation (http://firehol.org/documentation/)

## AUTHORS
FireHOL Team.