mfsexports.cfg

title: mfsexports.cfg(5)

summary: LizardFS access control for mfsmounts

text:
# mfsexports.cfg(5)

## NAME
mfsexports.cfg - LizardFS access control for mfsmounts

## DESCRIPTION
The file mfsexports.cfg contains LizardFS access list for mfsmount clients.

## SYNTAX
Syntax is:

ADDRESS DIRECTORY [OPTIONS]

Lines starting with # character are ignored.

ADDRESS can be specified in several forms:

•* all addresses

•n.n.n.n single IP address

•n.n.n.n/b IP class specified by network address and bits number

•n.n.n.n/m.m.m.m IP class specified by network address and mask

•f.f.f.f-t.t.t.t IP range specified by from-to addresses (inclusive)

DIRECTORY could be / or path relative to LizardFS root; special value . means MFSMETA companion filesystem.

## OPTIONS
ro, readonly

export tree in read-only mode (default)

rw, readwrite

export tree in read-write mode

ignoregid

disable testing of group access at mfsmaster level (it’s still done at mfsmount level) - in this case "group" and "other" permissions are logically added; needed for supplementary groups to work (mfsmaster receives only user primary group information)

dynamicip

allows reconnecting of already authenticated client from any IP address (the default is to check IP address on reconnect)

maproot=USER[:GROUP]

maps root (uid=0) accesses to given user and group (similarly to maproot option in NFS mounts); USER and GROUP can be given either as name or number; if no group is specified, USER's primary group is used. Names are resolved on mfsmaster side (see note below).

mapall=USER[:GROUP]

like above but maps all non privileged users (uid!=0) accesses to given user and group (see notes below).

minversion=VER

rejects access from clients older than specified

mingoal=N, maxgoal=N

specify range in which goal can be set by users

mintrashtime=TDUR, maxtrashtime=TDUR

specify range in which trashtime can be set by users

password=PASS, md5pass=MD5

requires password authentication in order to access specified resource

alldirs

allows to mount any subdirectory of specified directory (similarly to NFS)

nonrootmeta

allows non-root users to use filesystem mounted in the meta mode (option available only in this mode)

Default options are: ro,maproot=999:999.

## NOTES
USER and GROUP names (if not specified by explicit uid/gid number) are resolved on mfsmaster host.

TDUR can be specified as number without time unit (number of seconds) or combination of numbers with time units. Time units are: W,D,H,M,S. Order is important - less significant time units can’t be defined before more significant time units.

Option mapall works in LizardFS in different way than in NFS, because of using FUSE’s "default_permissions" option. When mapall option is used, users see all objects with uid equal to mapped uid as their own and all other as root’s objects. Similarly objects with gid equal to mapped gid are seen as objects with current user’s primary group and all other objects as objects with group 0 (usually wheel). With mapall option set attribute cache in kernel is always turned off.

## EXAMPLES
•* / ro

•192.168.1.0/24 / rw

•192.168.1.0/24 / rw,alldirs,maproot=0,password=passcode

•10.0.0.0-10.0.0.5 /test rw,maproot=nobody,password=test

•10.1.0.0/255.255.0.0 /public rw,mapall=1000:1000

•10.2.0.0/16 / rw,alldirs,maproot=0,mintrashtime=2h30m,maxtrashtime=2w

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

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

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster(8), mfsmaster.cfg(5)


mfsgoals.cfg

package: lizardfs-master

title: mfsgoals.cfg(5)

summary: replication goals configuration file

text:
# mfsgoals.cfg(5)

## NAME
mfsgoals.cfg - replication goals configuration file

## DESCRIPTION
The file mfsgoals.cfg contains definitions of the replication goals.

## SYNTAX
Syntax is:

id name : $type { label ... }

id name : label ...

The # character starts comments.

## DETAILS
There are 40 replication goals, with ids between 1 and 40, inclusive. Each file stored on the filesystem refers to some goal id and is replicated according to the goal currently associated with this id.

By default, goal 1 means one copy on any chunkserver, goal 2 means two copies on any two chunkservers and so on, until 5 - which is the maximal default number of copies. The purpose of mfsgoals.cfg is to override this behavior, when desired. The file is a list of goal definitions, each consisting of id, name and a list of labels. The maximal length of this list is 40 labels.

id indicates the goal id to be redefined. If some files are already assigned this goal id, their effective goal will change.

name is a human readable name used by the user interface tools (mfssetgoal(1), mfsgetgoal(1)). name can consist of up to 32 alphanumeric characters: a-z, A-Z, 0-9, _.

type specifies goal type - currently supported types are:

•std - for each file using this goal and for each label, the system will try to maintain a copy of the file on some chunkserver with this label.

•xorN - for each file using this goal, the system will split the file into N+1 parts (N ordinary + 1 parity). For reading, any N of the parts are necessary. If labels are specified, parts will be kept on chunkservers with these labels. Otherwise, default wildcard labels will be used. N can be in range from 2 to 9.

•ec(K,M) - for each file using this goal, the system will split the file into K + M parts (K data parts and M parity). For reading, any K of the parts are necessary. If labels are specified, parts will be kept on chunkservers with these labels. Otherwise, default wildcard labels will be used. K can be in range from 2 to 32 and M from 1 to 32.

```
If the type is unspecified is is assumed to be *std*.
```

The list of labels is a list of chunkserver labels as defined in mfschunkserver.cfg(5). label can consist of up to 32 alphanumeric characters: a-z, A-Z, 0-9, _.

One label may occur multiple times - in such case the system will create one copy per each occurrence. The special label _ means "a copy on any chunkserver".

Note that changing the definition of a goal in mfsgoals.cfg affects all files which currently use given goal id.

## EXAMPLES
Some example goal definitions:

3 3 : _ _ _ # one of the default goals (three copies anywhere)

8 not_important_file : _ # only one copy

11 important_file : _ _

12 local_copy_on_mars : mars _ # at least one copy in the Martian datacenter

13 cached_on_ssd : ssd _

14 very_important_file : _ _ _ _

15 default_xor3 : $xor3

16 fast_read : $xor2 { ssd ssd hdd }

17 xor5 : $xor5 { hdd } # at least one part on hdd

18 first_ec : $ec(3,1)

19 ec32_ssd : $ec(3,2) { ssd ssd ssd ssd ssd } # all parts on ssd

20 ec53_mixed : $ec(5,3) { hdd ssd hdd _ _ _ _ _ } # two parts on hdd and one part on ssd

## SNAPSHOT FILES
Snapshot shares data with the original file until the file receives modification and diverges from the snapshotted version. If some snapshot has different goal than its original file, any shared data are stored according to the goal with higher id of the two.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

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

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster.cfg(5)


mfsmaster.cfg

title: mfsmaster.cfg(5)

summary: main configuration file for mfsmaster

text:
# mfsmaster.cfg(5)

## NAME
mfsmaster.cfg - main configuration file for mfsmaster

## DESCRIPTION
The file mfsmaster.cfg contains configuration of LizardFS metadata server process.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored.

## OPTIONS
Configuration options:

PERSONALITY

Current personality of this instance of metadata server. Valid values are master, shadow and ha-cluster-managed. If installation is managed by an HA cluster the only valid value is ha-cluster-managed, otherwise the only valid values are master and shadow, in which case only one metadata server in LizardFS shall have master personality. PERSONALITY = master means that this instance of metadata server acts as main metadata server govering all file system metadata modifications.

PERSONALITY = shadow means that this instance of metadata server acts as backup metadata server ready for immediate deployment as new master in case of current master failure.

Metadata server personality can be changed at any moment as long as one changes personality from shadow to master, changing personality the other way around is forbidden.

PERSONALITY = ha-cluster-managed means that this instance is managed by HA cluster, server runs in shadow mode as long as its not remotely promoted to master.

DATA_PATH

where to store metadata files and lock file

WORKING_USER

user to run daemon as

WORKING_GROUP

group to run daemon as (optional - if empty then default user group will be used)

SYSLOG_IDENT

name of process to place in syslog messages (default is mfsmaster)

LOCK_MEMORY

whether to perform mlockall() to avoid swapping out mfsmaster process (default is 0, i.e. no)

NICE_LEVEL

nice level to run daemon with (default is -19 if possible; note: process must be started as root to increase priority)

EXPORTS_FILENAME

alternative name of mfsexports.cfg file

TOPOLOGY_FILENAME

alternative name of mfstopology.cfg file

CUSTOM_GOALS_FILENAME

alternative name of mfsgoals.cfg file

PREFER_LOCAL_CHUNKSERVER

If a client mountpoint has a local chunkserver, and a given chunk happens to reside locally, then mfsmaster will list the local chunkserver first. However, when the local client mount is issuing many read(s)/write(s), to many local chunks, these requests can overload the local chunkserver and disk subsystem. Setting this to 0(the default is 1) means that remote chunkservers will be considered as equivalent to the local chunkserver. This is useful when the network is faster than the disk, and when there is high-IO load on the client mountpoints.

BACK_LOGS

number of metadata change log files (default is 50)

BACK_META_KEEP_PREVIOUS

number of previous metadata files to be kept (default is 1)

AUTO_RECOVERY

when this option is set (equals 1) master will try to recover metadata from changelog when it is being started after a crash; otherwise it will refuse to start and mfsmetarestore should be used to recover the metadata (default is 0)

REPLICATIONS_DELAY_INIT

DEPRECATED - see OPERATIONS_DELAY_INIT

REPLICATIONS_DELAY_DISCONNECT

DEPRECATED - see OPERATIONS_DELAY_DISCONNECT

OPERATIONS_DELAY_INIT

initial delay in seconds before starting chunk operations (default is 300)

OPERATIONS_DELAY_DISCONNECT

chunk operations delay in seconds after chunkserver disconnection (default is 3600)

MATOML_LISTEN_HOST

IP address to listen on for metalogger connections (* means any)

MATOML_LISTEN_PORT

port to listen on for metalogger connections (default is 9419)

MATOML_LOG_PRESERVE_SECONDS

how many seconds of change logs have to be preserved in memory (default is 600; note: logs are stored in blocks of 5k lines, so sometimes real number of seconds may be little bigger; zero disables extra logs storage)

MATOCS_LISTEN_HOST

IP address to listen on for chunkserver connections (* means any)

MATOCS_LISTEN_PORT

port to listen on for chunkserver connections (default is 9420)

MATOCL_LISTEN_HOST

IP address to listen on for client (mount) connections (* means any)

MATOCL_LISTEN_PORT

port to listen on for client (mount) connections (default is 9421)

MATOTS_LISTEN_HOST

IP address to listen on for tapeserver connections (* means any)

MATOTS_LISTEN_PORT

Port to listen on for tapeserver connections (default is 9424)

CHUNKS_LOOP_MAX_CPS

Chunks loop shouldn’t check more chunks per seconds than given number (default is 100000)

CHUNKS_LOOP_MIN_TIME

Chunks loop will check all chunks in specified time (default is 300) unless CHUNKS_LOOP_MAX_CPS will force slower execution.

CHUNKS_LOOP_PERIOD

Time in milliseconds between chunks loop execution (default is 1000).

CHUNKS_LOOP_MAX_CPU

Hard limit on CPU usage by chunks loop (percentage value, default is 60).

CHUNKS_SOFT_DEL_LIMIT

Soft maximum number of chunks to delete on one chunkserver (default is 10)

CHUNKS_HARD_DEL_LIMIT

Hard maximum number of chunks to delete on one chunkserver (default is 25)

CHUNKS_WRITE_REP_LIMIT

Maximum number of chunks to replicate to one chunkserver (default is 2)

CHUNKS_READ_REP_LIMIT

Maximum number of chunks to replicate from one chunkserver (default is 10)

ENDANGERED_CHUNKS_PRIORITY

Percentage of endangered chunks that should be replicated with high priority. Example: when set to 0.2, up to 20% of chunks served in one turn would be extracted from endangered priority queue. When set to 1 (max), no other chunks would be processed as long as there are any endangered chunks in the queue (not advised) (default is 0, i.e. there is no overhead for prioritizing endangered chunks).

ENDANGERED_CHUNKS_MAX_CAPACITY

Max capacity of endangered chunks queue. This value can limit memory usage of master server if there are lots of endangered chunks in the system. This value is ignored if ENDANGERED_CHUNKS_PRIORITY is set to 0. (default is 1Mi, i.e. no more than 1Mi chunks will be kept in a queue).

ACCEPTABLE_DIFFERENCE

A maximum difference between disk usage on chunkservers that doesn’t trigger chunk rebalancing (default is 0.1, i.e. 10%).

CHUNKS_REBALANCING_BETWEEN_LABELS

When balancing disk usage, allow moving chunks between servers with different labels (default is 0, i.e. chunks will be moved only between servers with the same label).

REJECT_OLD_CLIENTS

Reject mfsmounts older than 1.6.0 (0 or 1, default is 0). Note that mfsexports access control is NOT used for those old clients.

GLOBALIOLIMITS_FILENAME

Configuration of global I/O limits (default is no I/O limiting)

GLOBALIOLIMITS_RENEGOTIATION_PERIOD_SECONDS

How often mountpoints will request bandwidth allocations under constant, predictable load (default is 0.1)

GLOBALIOLIMITS_ACCUMULATE_MS

After inactivity, no waiting is required to transfer the amount of data equivalent to normal data flow over the period of that many milliseconds (default is 250)

METADATA_CHECKSUM_INTERVAL

how often metadata checksum shall be sent to backup servers (default is: every 50 metadata updates)

METADATA_CHECKSUM_RECALCULATION_SPEED

how fast should metadata be recalculated in background (default : 100 objects per function call)

DISABLE_METADATA_CHECKSUM_VERIFICATION

should checksum verification be disabled while applying changelog

NO_ATIME

when this option is set to 1 inode access time is not updated on every access, otherwise (when set to 0) it is updated (default is 0)

METADATA_SAVE_REQUEST_MIN_PERIOD

minimal time in seconds between metadata dumps caused by requests from shadow masters (default is 1800)

SESSION_SUSTAIN_TIME

Time in seconds for which client session data (e.g. list of open files) should be sustained in the master server after connection with the client was lost. Values between 60 and 604800 (one week) are accepted. (default is 86400)

USE_BDB_FOR_NAME_STORAGE

When this option is set to 1 Berkley DB is used for storing file/directory names in file (DATA_PATH/name_storage.db). By default all strings are kept in system memory. (default is 0)

BDB_NAME_STORAGE_CACHE_SIZE

Size of memory cache (in MB) for file/directory names used by Berkeley DB storage. (default is 10)

AVOID_SAME_IP_CHUNKSERVERS

When this option is set to 1, process of selecting chunkservers for chunks will try to avoid using those that share the same ip. (default is 0)

REDUNDANCY_LEVEL

minimum number of required redundant chunk parts that can be lost before chunk becomes endangered (default is 0)

SNAPSHOT_INITIAL_BATCH_SIZE

This option can be used to specify initial number of snapshotted nodes that will be atomically cloned before enqueuing the task for execution in fixed-sized batches. (default is 1000)

SNAPSHOT_INITIAL_BATCH_SIZE_LIMIT

This option specifies the maximum initial batch size set for snapshot request. (default is 10000)

FILE_TEST_LOOP_MIN_TIME Test files loop will try to check all files in specified time in seconds (default is 3600). It’s possible for the loop to take more time if the master server is busy or the machine doesn’t have enough processing power to make all the needed calculations.

Options below are mandatory for all Shadow instances:

MASTER_HOST

address of the host running LizardFS metadata server that currently acts as master

MASTER_PORT

port number where LizardFS metadata server currently running as master listens for connections from 'shadow’s and metaloggers (default is 9420)

MASTER_RECONNECTION_DELAY

delay in seconds before trying to reconnect to metadata server after disconnection (default is 1)

MASTER_TIMEOUT

timeout (in seconds) for metadata server connections (default is 60)

LOAD_FACTOR_PENALTY

When set, percentage of load will be added to chunkserver disk usage to determine most fitting chunkserver. Heavy loaded chunkservers will be picked for operations less frequently. (default is 0, correct values are in range from 0 to 0.5)

## NOTES
Chunks in master are tested in loop. Speed (or frequency) is regulated by two options CHUNKS_LOOP_MIN_TIME and CHUNKS_LOOP_MAX_CPS. First defines minimal time of the loop and second maximal number of chunk tests per second. Typically at the beginning, when number of chunks is small, time is constant, regulated by CHUNK_LOOP_MIN_TIME, but when number of chunks became bigger then time of loop can increase according to CHUNKS_LOOP_MAX_CPS.

Deletion limits are defined as soft and hard limit. When number of chunks to delete increases from loop to loop then current limit can be temporary increased above soft limit, but never above hard limit.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

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

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster(8), mfsexports.cfg(5), mfstopology.cfg(5)


mfstopology.cfg

title: mfstopology.cfg(5)

summary: LizardFS network topology definitions

text:
# mfstopology.cfg(5)

## NAME
mfstopology.cfg - LizardFS network topology definitions

## DESCRIPTION
The file mfstopology.cfg contains assignments of IP addresses into network locations (usually switch numbers). This file is optional. If your network has one switch or decreasing traffic between switches is not necessary then leave this file empty.

## SYNTAX
Syntax is:

ADDRESS SWITCH-NUMBER

Lines starting with # character are ignored.

ADDRESS can be specified in several forms:

•* all addresses

•n.n.n.n single IP address

•n.n.n.n/b IP class specified by network address and bits number

•n.n.n.n/m.m.m.m IP class specified by network address and mask

•f.f.f.f-t.t.t.t IP range specified by from-to addresses (inclusive)

SWITCH-NUMBER can be specified as any positive 32-bit number.

## NOTES
If one IP belongs to more than one definition then last definition is used.

As for now distance between switches is constant. So distance between machines is calculated as: 0 when IP numbers are the same, 1 when IP numbers are different, but switch numbers are the same and 2 when switch numbers are different

Distances are used only to sort chunkservers during read and write operations. New chunks are still created randomly. Also rebalance routines do not take distances into account.

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

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

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmaster(8), mfsmaster.cfg(5)


mfsmetalogger.cfg

package: lizardfs-metalogger

title: mfsmetalogger.cfg(5)

summary: configuration file for mfsmetalogger

text:
# mfsmetalogger.cfg(5)

## NAME
mfsmetalogger.cfg - configuration file for mfsmetalogger

## DESCRIPTION
The file mfsmetalogger.cfg contains configuration of LizardFS metalogger process.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored.

## OPTIONS
Configuration options:

DATA_PATH

where to store metadata files

WORKING_USER

user to run daemon as

WORKING_GROUP

group to run daemon as (optional - if empty then default user group will be used)

SYSLOG_IDENT

name of process to place in syslog messages (default is mfsmetalogger)

LOCK_MEMORY

whether to perform mlockall() to avoid swapping out mfsmetalogger process (default is 0, i.e. no)

NICE_LEVEL

nice level to run daemon with (default is -19 if possible; note: process must be started as root to increase priority)

BACK_LOGS

number of metadata change log files (default is 50)

BACK_META_KEEP_PREVIOUS

number of previous metadata files to be kept (default is 3)

META_DOWNLOAD_FREQ

metadata download frequency in hours (default is 24, at most BACK_LOGS/2)

MASTER_HOST

address of LizardFS master host to connect with (default is mfsmaster)

MASTER_PORT

number of LizardFS master port to connect with (default is 9419)

MASTER_RECONNECTION_DELAY

delay in seconds before trying to reconnect to master after disconnection (default is 30)

MASTER_TIMEOUT

timeout (in seconds) for master connections (default is 60)

## COPYRIGHT
Copyright 2008-2009 Gemius SA, 2013-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

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

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
mfsmetalogger(8)


lizardfs-uraft.cfg

package: lizardfs-uraft

title: lizardfs-uraft.cfg(5)

summary: main configuration file for lizardfs\-uraft

text:
# lizardfs-uraft.cfg(5)

## NAME
lizardfs-uraft.cfg - main configuration file for lizardfs-uraft

## DESCRIPTION
The file lizardfs-uraft.cfg contains configuration of LizardFS HA suite.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored.

## OPTIONS
Configuration options:

URAFT_NODE_ADDRESS

Contains an IP address or hostname of uraft node, possibly with port. This option should be specified multiple times in order to contain information on every node in the cluster. Example: URAFT_NODE_ADDRESS = node1:9427 URAFT_NODE_ADDRESS = node2 URAFT_NODE_ADDRESS = 192.168.0.1:9427

URAFT_ID

This option is strictly connected with the ones above - URAFT_NODE_ADDRESS. It identifies on which node this uraft instance runs on. Node numbers start from 0 and have the same order as URAFT_NODE_ADDRESS entries. For example, if this configuration resides on node with hostname node2, its URAFT_ID should be set to 1.

LOCAL_MASTER_ADDRESS

Specifies an address of local LizardFS master server (default: localhost).

LOCAL_MASTER_MATOCL_PORT

Specifies a client port of local LizardFS master server (default: 9421).

URAFT_FLOATING_IP

Floating IP to be used as an active master.

URAFT_FLOATING_NETMASK

Network mask matching floating IP configuration.

URAFT_FLOATING_IFACE

Network interface where floating IP should be managed (example: eth0).

ELECTION_TIMEOUT_MIN

[advanced] minimal timeout in milliseconds for election algorithm.

ELECTION_TIMEOUT_MAX

[advanced] maximal timeout in milliseconds for election algorithm.

HEARTBEAT_PERIOD

[advanced] period in milliseconds between subsequent heartbeat messages.

LOCAL_MASTER_CHECK_PERIOD

[advanced] period in milliseconds between checking wheter local master is alive.

## COPYRIGHT
Copyright 2018-2019 Skytechnology sp. z o.o.

LizardFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

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

You should have received a copy of the GNU General Public License along with LizardFS. If not, see http://www.gnu.org/licenses/.

## SEE ALSO
lizardfs-uraft(8)


sensors.conf

title: sensors.conf(5)

summary: libsensors configuration file

text:
# sensors.conf(5)

## NAME
sensors.conf - libsensors configuration file

## DESCRIPTION
sensors.conf describes how libsensors, and so all programs using it, should translate the raw readings from the kernel modules to real-world values.

## SEMANTICS
On a given system, there may be one or more hardware monitoring chips. Each chip may have several features. For example, the LM78 monitors 7 voltage inputs, 3 fans and one temperature. Feature names are standardized. Typical feature names are in0, in1, in2... for voltage inputs, fan1, fan2, fan3... for fans and temp1, temp2, temp3... for temperature inputs.

Each feature may in turn have one or more sub-features, each representing an attribute of the feature: input value, low limit, high limit, alarm, etc. Sub-feature names are standardized as well. For example, the first voltage input (in0) would typically have sub-features in0_input (measured value), in0_min (low limit), in0_max (high limit) and in0_alarm (alarm flag). Which sub-features are actually present depend on the exact chip type.

The sensors.conf configuration file will let you configure each chip, feature and sub-feature in a way that makes sense for your system.

The rest of this section describes the meaning of each configuration statement.

### CHIP STATEMENT
A chip statement selects for which chips all following compute, label, ignore and set statements are meant. A chip selection remains valid until the next chip statement. Example:

chip "lm78-*" "lm79-*"

If a chip matches at least one of the chip descriptions, the following configuration lines are examined for it, otherwise they are ignored.

A chip description is built from several elements, separated by dashes. The first element is the chip type, the second element is the name of the bus, and the third element is the hexadecimal address of the chip. Such chip descriptions are printed by sensors(1) as the first line for every chip.

The name of the bus is either isa, pci, virtual, spi-*, i2c-N or mdio with N being a bus number as bound with a bus statement. This list isn't necessarily exhaustive as support for other bus types may be added in the future.

You may substitute the wildcard operator * for every element. Note however that it wouldn't make any sense to specify the address without the bus type, so the address part is plain omitted when the bus type isn't specified. Here is how you would express the following matches:

LM78 chip at address 0x2d on I2C bus 1

lm78-i2c-1-2d

LM78 chip at address 0x2d on any I2C bus

lm78-i2c-*-2d

LM78 chip at address 0x290 on the ISA bus

lm78-isa-0290

Any LM78 chip on I2C bus 1

lm78-i2c-1-*

Any LM78 on any I2C bus

lm78-i2c-*-*

Any LM78 chip on the ISA bus

lm78-isa-*

Any LM78 chip

lm78-*

Any chip at address 0x2d on I2C bus 1

*-i2c-1-2d

Any chip at address 0x290 on the ISA bus

*-isa-0290

If several chip statements match a specific chip, they are all considered.

### LABEL STATEMENT
A label statement describes how a feature should be called. Features without a label statement are just called by their feature name. Applications can use this to label the readings they present. Example:

label in3 "+5V"

The first argument is the feature name. The second argument is the feature description.

Note that you must use the raw feature name, which is not necessarily the one displayed by "sensors" by default. Use "sensors -u" to see the raw feature names. Same applies to all other statement types below.

### IGNORE STATEMENT
An ignore statement is a hint that a specific feature should be ignored - probably because it returns bogus values (for example, because a fan or temperature sensor is not connected). Example:

ignore fan1

The only argument is the feature name. Please note that this does not disable anything in the actual sensor chip; it simply hides the feature in question from libsensors users.

### COMPUTE STATEMENT
A compute statement describes how a feature's raw value should be translated to a real-world value, and how a real-world value should be translated back to a raw value again. This is most useful for voltage sensors, because in general sensor chips have a limited range and voltages outside this range must be divided (using resistors) before they can be monitored. Example:

compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)

The example above expresses the fact that the voltage input is divided using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the VOLTAGE COMPUTATION DETAILS section below for details.

The first argument is the feature name. The second argument is an expression which specifies how a raw value must be translated to a real-world value; `@' stands here for the raw value. This is the formula which will be applied when reading values from the chip. The third argument is an expression that specifies how a real-world value should be translated back to a raw value; `@' stands here for the real-world value. This is the formula which will be applied when writing values to the chip. The two formulas are obviously related, and are separated by a comma.

A compute statement applies to all sub-features of the target feature for which it makes sense. For example, the above example would affect sub-features in3_min and in3_max (which are voltage values) but not in3_alarm (which is a boolean flag.)

The following operators are supported in compute statements:

+ - * / ( ) ^ `

^x means exp(x) and `x means ln(x). You may use the name of sub-features in these expressions; current readings are substituted. You should be careful though to avoid circular references.

If at any moment a translation between a raw and a real-world value is called for, but no compute statement applies, a one-on-one translation is used instead.

### SET STATEMENT
A set statement is used to write a sub-feature value to the chip. Of course not all sub-feature values can be set that way, in particular input values and alarm flags can not. Valid sub-features are usually min/max limits. Example:

set in3_min 5 * 0.95

set in3_max 5 * 1.05

The example above basically configures the chip to allow a 5% deviance for the +5V power input.

The first argument is the feature name. The second argument is an expression which determines the written value. If there is an applying compute statement, this value is fed to its third argument to translate it to a raw value.

You may use the name of sub-features in these expressions; current readings are substituted. You should be careful though to avoid circular references.

Please note that set statements are only executed by sensors(1) when you use the -s option. Typical graphical sensors applications do not care about these statements at all.

### BUS STATEMENT
A bus statement binds the description of an I2C or SMBus adapter to a bus number. This makes it possible to refer to an adapter in the configuration file, independent of the actual correspondence of bus numbers and actual adapters (which may change from moment to moment). Example:

bus "i2c-0" "SMBus PIIX4 adapter at e800"

The first argument is the bus number. It is the literal text i2c-, followed by a number. As there is a dash in this argument, it must always be quoted.

The second argument is the adapter name, it must match exactly the adapter name as it appears in /sys/class/i2c-adapter/i2c-*/name. It should always be quoted as well as it will most certainly contain spaces or dashes.

The bus statements may be scattered randomly throughout the configuration file; there is no need to place the bus line before the place where its binding is referred to. Still, as a matter of good style, we suggest you place all bus statements together at the top of your configuration file.

Running sensors --bus-list will generate these lines for you.

In the case where multiple configuration files are used, the scope of each bus statement is the configuration file it was defined in. This makes it possible to have bus statements in all configuration files which will not unexpectedly interfere with each other.

### STATEMENT ORDER
Statements can go in any order, however it is recommended to put `set fanX_div' statements before `set fanX_min' statements, in case a driver doesn't preserve the fanX_min setting when the fanX_div value is changed. Even if the driver does, it's still better to put the statements in this order to avoid accuracy loss.

## VOLTAGE COMPUTATION DETAILS
Most voltage sensors in sensor chips have a range of 0 to 4.08 V. This is generally sufficient for the +3.3V and CPU supply voltages, so the sensor chip reading is the actual voltage.

Other supply voltages must be scaled with an external resistor network. The driver reports the value at the chip's pin (0 - 4.08 V), and the userspace application must convert this raw value to an actual voltage. The compute statements provide this facility.

Unfortunately the resistor values vary among motherboard types. Therefore you have to figure out the correct resistor values for your own motherboard.

For positive voltages (typically +5V and +12V), two resistors are used, with the following formula:

R1 = R2 * (Vs/Vin - 1)

where:

R1 and R2 are the resistor values

Vs is the actual voltage being monitored

Vin is the voltage at the pin

This leads to the following compute formula:

compute inX @*((R1/R2)+1), @/(((R1/R2)+1)

Real-world formula for +5V and +12V would look like:

compute in3 @*((6.8/10)+1), @/((6.8/10)+1)

compute in4 @*((28/10)+1), @/((28/10)+1)

For negative voltages (typically -5V and -12V), two resistors are used as well, but different boards use different strategies to bring the voltage value into the 0 - 4.08 V range. Some use an inverting amplifier, others use a positive reference voltage. This leads to different computation formulas. Note that most users won't have to care because most modern motherboards make little use of -12V and no use of -5V so they do not bother monitoring these voltage inputs.

Real-world examples for the inverting amplifier case:

compute in5 -@*(240/60), -@/(240/60)

compute in6 -@*(100/60), -@/(100/60)

Real-world examples for the positive voltage reference case:

compute in5 @*(1+232/56) - 4.096*232/56, (@ + 4.096*232/56)/(1+232/56)

compute in6 @*(1+120/56) - 4.096*120/56, (@ + 4.096*120/56)/(1+120/56)

Many recent monitoring chips have a 0 - 2.04 V range, so scaling resistors are even more needed, and resistor values are different.

There are also a few chips out there which have internal scaling resistors, meaning that their value is known and doesn't change from one motherboard to the next. For these chips, the driver usually handles the scaling so it is transparent to the user and no compute statements are needed.

## TEMPERATURE CONFIGURATION
On top of the usual features, temperatures can have two specific sub-features: temperature sensor type (tempX_type) and hysteresis values (tempX_max_hyst, tempX_crit_hyst etc.).

### THERMAL SENSOR TYPES
Available thermal sensor types:

1

PII/Celeron Diode

2

3904 transistor

3

thermal diode

4

thermistor

5

AMD AMDSI

6

Intel PECI

For example, to set temp1 to thermistor type, use:

set temp1_type 4

Only certain chips support thermal sensor type change, and even these usually only support some of the types above. Please refer to the specific driver documentation to find out which types are supported by your chip.

In theory, the BIOS should have configured the sensor types correctly, so you shouldn't have to touch them, but sometimes it isn't the case.

### THERMAL HYSTERESIS MECHANISM
Many monitoring chips do not handle the high and critical temperature limits as simple limits. Instead, they have two values for each limit, one which triggers an alarm when the temperature rises and another one which clears the alarm when the temperature falls. The latter is typically a few degrees below the former. This mechanism is known as hysteresis.

The reason for implementing things that way is that high temperature alarms typically trigger an action to attempt to cool the system down, either by scaling down the CPU frequency, or by kicking in an extra fan. This should normally let the temperature fall in a timely manner. If this was clearing the alarm immediately, then the system would be back to its original state where the temperature rises and the alarm would immediately trigger again, causing an undesirable tight fan on, fan off loop. The hysteresis mechanism ensures that the system is really cool before the fan stops, so that it will not have to kick in again immediately.

So, in addition to tempX_max, many chips have a tempX_max_hyst sub-feature. Likewise, tempX_crit often comes with tempX_crit_hyst. tempX_emerg_hyst, tempX_min_hyst and tempX_lcrit_hyst exist too but aren't as common. Example:

set temp1_max 60

set temp1_max_hyst 56

The hysteresis mechanism can be disabled by giving both limits the same value.

Note that it is strongly recommended to set the hysteresis value after the limit value it relates to in the configuration file. Implementation details on the hardware or driver side may cause unexpected results if the hysteresis value is set first.

## BEEPS
Some chips support alarms with beep warnings. When an alarm is triggered you can be warned by a beeping signal through your computer speaker. On top of per-feature beep flags, there is usually a master beep control switch to enable or disable beeping globally. Enable beeping using:

set beep_enable 1

or disable it using:

set beep_enable 0

## WHICH STATEMENT APPLIES
If more than one statement of the same kind applies at a certain moment, the last one in the configuration file is used. So usually, you should put more general chip statements at the top, so you can overrule them below.

## SYNTAX
Comments are introduced by hash marks. A comment continues to the end of the line. Empty lines, and lines containing only whitespace or comments are ignored. Other lines have one of the below forms. There must be whitespace between each element, but the amount of whitespace is unimportant. A line may be continued on the next line by ending it with a backslash; this does not work within a comment, NAME or NUMBER.

bus NAME NAME NAME chip NAME-LIST

label NAME NAME

compute NAME EXPR , EXPR

ignore NAME

set NAME EXPR

A NAME is a string. If it only contains letters, digits and underscores, it does not have to be quoted; in all other cases, you must use double quotes around it. Within quotes, you can use the normal escape-codes from C.

A NAME-LIST is one or more NAME items behind each other, separated by whitespace.

A EXPR is of one of the below forms:

NUMBER NAME

@

EXPR + EXPR

EXPR - EXPR

EXPR * EXPR

EXPR / EXPR

- EXPR

^ EXPR

` EXPR

( EXPR )

A NUMBER is a floating-point number. `10', `10.4' and `.4' are examples of valid floating-point numbers; `10.' or `10E4' are not valid.

## FILES
/etc/sensors3.conf

/etc/sensors.conf

The system-wide libsensors(3) configuration file. /etc/sensors3.conf is tried first, and if it doesn't exist, /etc/sensors.conf is used instead.

/etc/sensors.d

A directory where you can put additional libsensors configuration files. Files found in this directory will be processed in alphabetical order after the default configuration file. Files with names that start with a dot are ignored.

## SEE ALSO
libsensors(3)

## AUTHOR
Frodo Looijaard and the lm_sensors group https://hwmon.wiki.kernel.org/lm_sensors


logwatch.conf

package: logwatch

title: logwatch.conf(5)

text:
# logwatch.conf(5)

## NAME
logwatch.conf, ignore.conf, override.conf - logwatch configuration files

## DESCRIPTION
logwatch.conf - ( /etc/logwatch/conf/logwatch.conf ) - can contain the local configuration options. The list of valid settings and their default values are in /usr/share/logwatch/default.conf/logwatch.conf.

ignore.conf - ( /etc/logwatch/conf/ignore.conf ) is the list of regular expressions. The set of logs decribed by this set is ignored by logwatch.

override.conf - ( /etc/logwatch/conf/override.conf ) contains the settings which overrides the standard configuration of specific log files or services. The syntax is the same as in log/service files.

## FILES
/etc/logwatch/conf/logwatch.conf /etc/logwatch/conf/logwatch.conf /etc/logwatch/conf/logwatch.conf /usr/share/logwatch/default.conf/logwatch.conf

## SEE ALSO
logwatch(8)


lowdown

package: lowdown

title: lowdown(5)

summary: Markdown reference for lowdown

text:
# lowdown(5)

## NAME
lowdown — Markdown reference for lowdown

## DESCRIPTION
Markdown is a simple, plain-text formatting language. “Plain-text” in this case means the document input looks similar to the output, less the formatting niceties (boxed tables, italics, clickable links, etc.) provided by the output medium. For example:

```
# How to be a Picard fan

## Introduction

In order to develop fandom skills one must first and foremost
know *whom* one idolises. Therefore: **who is Captain Picard**?

1. Picard was named the \*Best Star Trek Captain\*, according
to a [5-week poll](poll.html).

    > Picard continued his winning ways in the final week,
    > with fans naming him the most inspiring captain.

2. Picard is handsome. Picard
3. Picard knows how to code: `make engage`

---------------------------------

## Picard Fandom

Here's why everyone wants to be a fan...
```

This example consists of a series of block elements: section header, sub-section header, paragraph, set of list elements, horizontal rule, then another sub-section header. Each block element contains inline elements: normal text, emphasised text (bold and italised), an image, a link, and a span of code.

This document describes the Markdown syntax accepted by lowdown(1).

## TEXT
Text within Markdown documents must be UTF-8. The document may have the byte-order mark (BOM), although this practice is discouraged by the Unicode standard. Lines of text may be UNIX terminated (‘\n’) or DOS (‘\r\n’). In the latter case, carriage returns are stripped from input if detected at the first line.

## BLOCK ELEMENTS
A block element starts on a new line and extends to the next blank line or block element. A block element contains inline elements.

### Paragraphs and Line Breaks
A paragraph is made up of one or more lines of text possibly containing inline elements. Paragraphs are separated by blank lines.

To insert a hard line break (i.e., a line-break in the input that is reproduced in the output), insert two spaces at the end of the line. If commonmark input parsing is enabled, this may also be effected by escaping the newline:

```
Darmok and Jalad...\
at Tanagra.
```

### Headers
There are two styles of headers: underlined (“setext”) and hash-marked (“atx”). For underlined headers, underline the given word using equal signs (“=”) for first-level headers and dashes (“-”) for second-level headers.

```
This is an underlined header 1
==============================
```

For hash-marked headers, use the corresponding number of hash characters to the corresponding level of header, up to 6 levels, at the start of the line separated by one space followed by the header.

```
## This is a hash-marked header 2
```

If commonmark input parsing is enabled, the space is required after the hash-marks in any hash-marked header.

Both types support PHP Extra attributes enclosed in curly braces. These may begin at any point and must end at the end of the line.

```
## Star Trek: Enterprise { #stent }

Star Trek: Enterprise { .reboots }
---------------------
```

Non-empty values with a leading period are interpreted as HTML (CSS) or OpenDocument classes, and values with a leading pound symbol are interpreted as in-document link identifiers.

Extra attribute identifiers override the default mechanism for creating header identifiers. They should contain only ASCII alphanumeric characters.

### Block Quotes
Block quoted sections are invoked with a single right-angle bracket (“>”) followed by a space at the start of each line and between paragraphs.

```
> The Prime Directive is not just a set of rules;
> it is a philosophy... and a very correct one.
>
> (It goes on for a few paragraphs).
```

Block quotes may also have a non-multiline invocation: you need only invoke the right-angle bracket at the start of a paragraph and omit it entirely between paragraphs.

```
> You cannot explain away a wantonly immoral act because
you think it is connected to some higher purpose.

> Here is another paragraph about Picard wisdom.
```

Consecutive blockquotes as above will be merged as paragraphs within a single block quote on output, even if styles (non-multiline and otherwise) are mixed.

Block quotes may be nested within other block quotes, as may any other block elements such as headers, ordered/unordered lists, and code blocks.

```
> ### hash-marked header 3
>
> > I'd be delighted to offer any advice
> > I have on understanding women.
> > When I have some, I'll let you know.
>
> 1.  advice list item 1
> 2.  advice list item 2
>
> Here's the code to implement JLP's advice:

>     yes | read engage
```

### Admonitions
Also called "callouts", these special block quotes call attention to contents. These are generally rendered as-is, but some output modes will specially render admonitions to highlight the content.

```
> **Note**
>
> The computer is voiced by Majel Barrett.
```

Callouts begin with a double-emphasis "Note" or "Warning", and omitting the initial newline suppresses white-space after the callout type. This is GFM syntax. The MDN syntax includes an initial phrase following the callout type and colon, and also supports the "Callout" type:

```
> **Warning:** red alert.
>
> Romulan warbird decloaking!
```

### Lists
Lists may be specified as ordered (numbered) or unordered. Ordered lists are invoked as numbers followed by periods (e.g., “1.”) and rendered in a similar format. Note: it does not matter which order or which numbers you use in your ordered lists, as all ordered lists start at one.

```
1. Make.
2. It.
1. So. (Not 1. again!)
```

If commonmark input parsing is enabled, list items may alternatively terminate with the right parenthesis:

```
1) Live long
2) Prosper
```

To prevent lists erroneously started by a paragraph beginning with a number and period, use a backslash before the period.

```
1987. The year TNG premiered.

1987\. The year TNG premiered.
```

Unordered lists, on the other hand, can be invoked using either asterisk (“*”), pluses (“+”), or hyphens (“-”), and can be a mix of all three styles. Regardless the style, list items are rendered the same way.

```
- Earl Grey tea.
* Shakespeare.
+ Exotic fish.
```

All nested block elements need a new line break, otherwise they will be rendered on the same line as the list item on output. To insert paragraphs into a list item, indent each paragraph with either four spaces or one tab.

```
- First list item

    Courage can be an emotion too.

    Things are only impossible until they're not.
+ Second list item
+ Third list item
```

To insert block quotes into a list item, indent the block quote with four spaces or one tab prior to the right-angle bracket (“>”).

```
* List item 1
* List item 2

     > I am Locutus of Borg.

     > That is the cutest of Borg.
```

Code blocks need to be indented twice (two tabs or eight leading spaces): once for being recognised within the list item, another for the code block itself.

```
* Here is a list item for an indented code block:

        alias path='echo -e ${PATH//:/\n}'
```

To make list elements occur in tight sequence — like a grocery list — don't have an empty line between the items.

```
- Phaser
- Communicator
```

On the other hand, if you want to render lists separated by white-space, use the following syntax:

```
- A phaser is a type of weapon.

- A communicator keeps Riker in contact with Troi.
```

This applies to ordered and unordered list types.

### Task lists
One form of an unordered list is task lists, a GFM extension. These begin with checkboxes (checked or not), rendered similarly in the output.

```
Star Trek series with episodes in the Delta quadrant:

- [ ] Original series
- [x] TNG
- [ ] DS9
- [x] Voyager
- [ ] Enterprise
- [ ] Discovery
```

The check may be upper or lower case. A space must follow the right square bracket.

### Definition Lists
Definition lists are a PHP Extra extension. They're similar to lists except in having key and value pairs, with keys being preceded by a blank line:

```
Best understated characters:

*Quark*
: Armin Shimerman

*Weyoun*
: Jeffrey Combs
```

Keys consist of a single line and may contain inline elements. Like other lists, values may consist of arbitrary nested blocks. There may be multiple consecutive values per key. If the key and value are separated by a blank line, the list is emitted as if it contained block elements (usually output as spacing between key-value pairs).

### Code Blocks
Code blocks consist of pre-formatted text, such as source code. Each code block contains opaque/literal text. This means that new lines and white spaces are retained — they're not formatted in any way, and any text inside the code block is not interpreted. To invoke a code block, create a line break then indent each line with four spaces or one tab.

```
Here is a paragraph about Bridge protocol

    Here is a code block for the command "Engage"
```

Within a code block, text is escaped given the output format. Therefore, characters that would normally need to be escaped in other text processing languages such as ampersands (“&”) do not need to be escaped.

```
Here is how you start the program xterm:

    xterm &
```

### Horizontal Rules
A horizontal rule is a line that goes across an output page. These are invoked with three or more asterisks (“*”), hyphens (“-”), or underscores (“_”) on their own line. Spaces between these characters are disregarded.

```
***
* * *
---
- - -
___
_ _ _
___________________________
```

### Metadata
Documents can include metadata that is not part of the main text. The syntax follows the MMD and Pandoc specifications.

In the MMD syntax, the block begins on the document's first line and continues until the first blank line. Keys and values are separated by a colon, and pairs separated by a newline. A key (and following value) must exist on the line beginning the metadata pair, but the value may span multiple lines.

```
Title: Captain's log
Author: Captain J-L Picard
Summary: As part of an exchange program, we're taking
 aboard a Klingon officer to return the recent visit
 of Commander Riker to the cruiser Pagh.
Stardate: 43917.4
```

Alternatively, a block of MMD metadata may begin with a line of "---" and end with "---" or "...".

If there are multiple lines of text in a metadata value, subsequent lines should (but need not) be offset with whitespace. Otherwise, they must not have a colon in the value, else they will be construed as a subsequent pair's key.

End each line with two spaces to ensure linebreaks are rendered on output for non-conforming Markdown renderers. Moreover, beginning a document with a regular sentence containing a colon might invoke metadata. To escape this, add one blank line to the beginning of the document.

Metadata keys must consist of alphanumeric ASCII characters, the hyphen ("-"), or the underscore ("_"). They must have at least one character and are stripped of white-space and converted to lower case.

Metadata values are opaque text: Markdown statements (e.g., italics, entities, etc.) are copied as-is. The values will have leading white-space stripped, i.e., space following the colon.

If multiple metadata keys resolve to the same name, the last invocation is retained. This check happens after canonicalising the name by stripping spaces, converting to lower-case, and substituting unknown characters.

In the Pandoc syntax, the block stops at the first line not starting with a percent sign or space. Metadata is limited to at most three keys: title, author(s), and date. The first line is for title, the second (if provided) for author(s), and the third (also if provided) for date. Lines may continue by having a subsequent line begin with a space. If only one leading-percent line is included, the metadata is only for the title; if two, for a title and author(s); and so on. If a leading-percent line is blank, the corresponding metadata is left empty (unspecified).

```
% A Skin of Evil
% Tasha Yar
  Armus
% 1988-04-2525

Wow what a day...
```

Multiple authors may be separated by multiple white-space (including newlines), a semicolon, or both.

The Pandoc title line is automatically scanned for whether it's a manpage-style title:

```
% TREK(6)
```

lowdown recognises a manpage title from the open parenthesis followed by a number (or "n"), optional following characters, then a closing parenthesis. If found, the title is broken down into title and section. Any text following the title is further recognised as the source and, if a vertical bar is detected, what comes after as the volume.

```
% TREK(6) OpenBSD | Games Manual
```

These may be accessed with the title and section metadata keys, and optionally volume and source.

Using either syntax, dates should be in the YYYY-MM-DD format, but can be in any format. Metadata values may be pasted into a document by referencing the [%key], such as using the above example, again with the caveat that Markdown annotations (italics, etc.) are copied verbatim:

```
date: 43917.4

It's currently stardate [%date].
```

Or using Pandoc:

```
%
%
% 43917.4
It's currently stardate [%date].
```

### Mathematics
Mathematics support is an extension of Markdown. The extension only describes how the math blocks begin and end: the contained equations are usually in LaTeX and implemented in the front-end (e.g., HTML). There are two types: inline and block. Both may occur anywhere in a text stream. Inline equations are rendered as part of the text; block equations are rendered on their own.

```
This is an inline $f(x)$ function.
This is a block $$f(x)$$ function.
This is also an inline \\(f(x)\\) function.
This is also a block \\[f(x)\\] function.
```

### Tables
Tables are a GFM (GitHub-flavoured Markdown) extension of the basic syntax. They consist of a table header and body, and columns may be left, right, or centre justified.

```
| Officer         | Rank                 |
| --------------: | -------------------- |
| Jean-Luc Picard | Captain              |
| Worf            | Lieutenant Commander |
| Data            | Lieutenant Commander |
| William Riker   | Commander            |
```

The table header must be followed by a line of hyphens with at least three hyphen/colons per column. Columns are separated by vertical bars. The colon indicates alignment: a colon at the beginning means left justified; at the right for right justified, and both for centred.

The leading and trailing column separator is superfluous. Table data is not necessary, but the table header is. The minimum table structure for the above is:

```
Officer | Rank
--:|---
Jean-Luc Picard | Captain
```

Table columns may contain arbitrary inline elements.

### Footnote Definition
Footnotes are a MMD extension of the basic syntax. Footnote definitions may occur anywhere in the text (except within blocks) and are “pointed to” by a Footnote Reference. They consist of the footnote name (in square brackets, preceded by the caret), a colon, then everything remaining in the block is the footnote content.

```
[^pt]:
    Klingon insult, meaning something like "weirdo," deriving from
    the verb "to be weird" (**taQ**), with and [sic] you (plural)
    imperative prefix (**pe-**).
```

Footnote contents may be on the same line as the colon. The footnote name is rendered as a number. If a footnote definition is not referred to, it is not printed.

### HTML Blocks
Embedded HTML is discouraged, as it inhibits formatting into non-HTML output, but is still accepted. Blocks of HTML must begin with a recognised HTML block-level element.

In the original Markdown, block-level elements were well-defined by HTML4. HTML5 elements are also accepted, but as there is no concept of block-level in HTML5, these are non-canonical. Accepted elements are <address>,
, ,
, , , <dialog>,
,
,
,
, <fieldset>,
,
, , <form>,
,
,
,
,
,
, , <hgroup>, , ,
, , <math>, , ,
,
,
,
,


lrzip.conf

package: lrzip

title: lrzip.conf(5)

summary: Configuration File for lrzip

text:
# lrzip.conf(5)

## NAME
lrzip.conf - Configuration File for lrzip

## DESCRIPTION
This file if used, will be read by the lrzip program, parsed, and options passed to the program. Some options may be overridden on the command line. Others are fixed.

The configuration file must be called lrzip.conf. The lrzip program will search for the file automatically in one of three places:

```
$PWD - Current Directory
/etc/lrzip
$HOME/./lrzip
```

```
Parameters are set in PARAMETER=VALUE fashion where any line
beginning with a # or that is blank will be ignored.
Parameter values are not case sensitive.
```

## CONFIG FILE EXAMPLE

```
# This is a comment.
# Compression Window size in 100MB. Normally selected by program.
# WINDOW = 5
# Compression Level 1-9 (7 Default).
# COMPRESSIONLEVEL = 7
# Unlimited Ram Compression
# UNLIMITED = YES
# Compression Method, rzip, gzip, bzip2, lzo, or lzma (default), zpaq.
# COMPRESSIONMETHOD = LZMA
# Perform LZO Test. Default = YES (-T option, NO)
# LZOTEST = NO
# Hash Check on decompression, YES
# HASHCHECK = YES
# Show HASH value on Compression even if Verbose is off, YES
# SHOWHASH = YES
# Default output directory
# OUTPUTDIRECTORY = location
# Verbosity, Yes or Max
# VERBOSITY = MAX
# Show Progress as file is parsed, YES, NO (yes is default)
# SHOWPROGRESS = NO
# Set Niceness. 19 is default. -20 to 19 is the allowable range
# NICE = 19
# Keep broken or damaged output files, YES
# KEEPBROKEN = YES
# Delete source file after compression
# this parameter and value are case sensitive
# value must be YES to activate
# DELETEFILES = NO
# Replace existing lrzip file when compressing
# this parameter and value are case sensitive
# value must be YES to activate
# REPLACEFILE = NO
# Select Temporary Directory when stdin/stdout or Test file is used
# TMPDIR = /tmp
```

## NOTES
Be careful when using DELETEFILES or REPLACEFILE as no warning will be given and lrzip will simply delete the source or replace the output file!

## SEE ALSO
lrzip(1)


ltrace.conf

package: ltrace

title: ltrace.conf(5)

summary: Configuration file for ltrace(1).

text:
# ltrace.conf(5)

## NAME
ltrace.conf - Configuration file for ltrace(1).

## DESCRIPTION
This manual page describes ltrace.conf, a file that describes prototypes of functions in binaries for ltrace(1) to use. Ltrace needs this information to display function call arguments.

Each line of a configuration file describes at most a single item. Lines composed entirely of white space are ignored, as are lines starting with semicolon or hash characters (comment lines). Described items can be either function prototypes, or definitions of type aliases.

## PROTOTYPES
A prototype describes return type and parameter types of a single function. The syntax is as follows:

[function] LENS NAME ([LENS{,LENS}]);

NAME is the (mangled) name of a symbol. In the elementary case, LENS is simply a type. Both lenses and types are described below. The function keyword, if present, has no effect. It can be used to force a line to be interpreted as a function prototype when the return type is a keyword that would start a different type of line (such as import).

For example, a simple function prototype might look like this:

int kill(int,int);

Despite the apparent similarity with C, ltrace.conf is really its own language that's only somewhat inspired by C.

## TYPES
Ltrace understands a range of primitive types. Those are interpreted according to C convention native on a given architecture. E.g. ulong is interpreted as 4-byte unsigned integer on 32-bit GNU/Linux machine, but 8-byte unsigned integer on 64-bit GNU/Linux machine.

void

Denotes that a function does not return anything. Can be also used to construct a generic pointer, i.e. pointer-sized number formatted in hexadecimal format.

char

8-bit quantity rendered as a character

ushort,short

Denotes unsigned or signed short integer.

uint,int

Denotes unsigned or signed integer.

ulong,long

Denotes unsigned or signed long integer.

float

Denotes floating point number with single precision.

double

Denotes floating point number with double precision.

Besides primitive types, the following composed types are possible:

struct([LENS{,LENS}])

Describes a structure with given types as fields, e.g. struct(int,int,float). Alignment is computed as customary on the architecture. Custom alignment (e.g. packed structs) and bit-fields are not supported. It's also not possible to differentiate between structs and non-POD C++ classes, for arches where it makes a difference.

array(LENS,EXPR)

Describes array of length EXPR, which is composed of types described by LENS, e.g. array(int, 6). Note that in C, arrays in role of function argument decay into pointers. Ltrace currently handles this automatically, but for full formal correctness, any such arguments should be described as pointers to arrays.

LENS*

Describes a pointer to a given type, e.g. char* or int***. Note that the former example actually describes a pointer to a character, not a string. See below for string lens, which is applicable to these cases.

## LENSES
Lenses change the way that types are described. In the simplest case, a lens is directly a type. Otherwise a type is decorated by the lens. Ltrace understands the following lenses:

oct(TYPE)

The argument, which should be an integer type, is formatted in base-8.

hex(TYPE)

The argument, which should be an integer or floating point type, is formatted in base-16. Floating point arguments are converted to double and then displayed using the %a fprintf modifier.

hide(TYPE)

The argument is not shown in argument list.

bool(TYPE)

Arguments with zero value are shown as "false", others are shown as "true".

bitvec(TYPE)

Underlying argument is interpreted as a bit vector and a summary of bits set in the vector is displayed. For example if bits 3,4,5 and 7 of the bit vector are set, ltrace shows <3-5,7>. Empty bit vector is displayed as <>. If there are more bits set than unset, inverse is shown instead: e.g. ~<0> when a number 0xfffffffe is displayed. Full set is thus displayed ~<>. If the underlying type is integral, then bits are shown in their natural big-endian order, with LSB being bit 0. E.g. bitvec(ushort) with value 0x0102 would be displayed as <1,8>, irrespective of underlying byte order.

For other data types (notably structures and arrays), the underlying data is interpreted byte after byte. Bit 0 of first byte has number 0, bit 0 of second byte number 8, and so on. Thus bitvec(struct(int)) is endian sensitive, and will show bytes comprising the integer in their memory order. Pointers are first dereferenced, thus bitvec(array(char, 32)*) is actually a pointer to 256-bit bit vector.

string(TYPE)

string[EXPR]

string

The first form of the argument is canonical, the latter two are syntactic sugar. In the canonical form, the function argument is formatted as string. The TYPE can have either of the following forms: X*, or array(X,EXPR), or array(X,EXPR)*. X is either char for normal strings, or an integer type for wide-character strings. If an array is given, the length will typically be a zero expression (but doesn't have to be). Using argument that is plain array (i.e. not a pointer to array) makes sense e.g. in C structs, in cases like struct(string(array(char, 6))), which describes the C type struct {char s[6];}.

Because simple C-like strings are pretty common, there are two shorthand forms. The first shorthand form (with brackets) means the same as string(array(char, EXPR)*). Plain string without an argument is then taken to mean the same as string[zero].

Note that char* by itself describes a pointer to a char. Ltrace will dereference the pointer, and read and display the single character that it points to.

enum(NAME[=VALUE]{,NAME[=VALUE]})

enum[TYPE](NAME[=VALUE]{,NAME[=VALUE]})

This describes an enumeration lens. If an argument has any of the given values, it is instead shown as the corresponding NAME. If a VALUE is omitted, the next consecutive value following after the previous VALUE is taken instead. If the first VALUE is omitted, it's 0 by default. TYPE, if given, is the underlying type. It is thus possible to create enums over shorts or longs—arguments that are themselves plain, non-enum types in C, but whose values can be meaningfully described as enumerations. If omitted, TYPE is taken to be int.

## TYPE ALIASES
A line in config file can, instead of describing a prototype, create a type alias. Instead of writing the same enum or struct on many places (and possibly updating when it changes), one can introduce a name for such type, and later just use that name:

typedef NAME = LENS;

## IMPORT DIRECTIVES
It's possible for config files to import definitions from other config files. A line of the form:

import "FILENAME";

will make all definitions from FILENAME.conf available in the current file. The imported file is searched for in the same directories as when looking up a config file corresponding to a library; see ltrace(1) for details.

## RECURSIVE STRUCTURES
Ltrace allows you to express recursive structures. Such structures are expanded to the depth described by the parameter -A. To declare a recursive type, you first have to introduce the type to ltrace by using forward declaration. Then you can use the type in other type definitions in the usual way:

typedef NAME = struct;

typedef NAME = struct(NAME can be used here)

For example, consider the following singy-linked structure and a function that takes such list as an argument:

typedef int_list = struct;

typedef int_list = struct(int, int_list*);

void ll(int_list*);

Such declarations might lead to an output like the following:

ll({ 9, { 8, { 7, { 6, ... } } } }) = <void>

Ltrace detects recursion and will not expand already-expanded structures. Thus a doubly-linked list would look like the following:

typedef int_list = struct;

typedef int_list = struct(int, int_list*, int_list*);

With output e.g. like:

ll({ 9, { 8, { 7, { 6, ..., ... }, recurse^ }, recurse^ }, nil })

The "recurse^" tokens mean that given pointer points to a structure that was expanded in the previous layer. Simple "recurse" would mean that it points back to this object. E.g. "recurse^^^" means it points to a structure three layers up. For doubly-linked list, the pointer to the previous element is of course the one that has been just expanded in the previous round, and therefore all of them are either recurse^, or nil. If the next and previous pointers are swapped, the output adjusts correspondingly:

ll({ 9, nil, { 8, recurse^, { 7, recurse^, { 6, ..., ... } } } })

## EXPRESSIONS
Ltrace has support for some elementary expressions. Each expression can be either of the following:

NUM

An integer number.

argNUM

Value of NUM-th argument. The expression has the same value as the corresponding argument. arg1 refers to the first argument, arg0 to the return value of the given function.

retval

Return value of function, same as arg0.

eltNUM

Value of NUM-th element of the surrounding structure type. E.g. struct(ulong,array(int,elt1)) describes a structure whose first element is a length, and second element an array of ints of that length.

zero

zero(EXPR)

Describes array which extends until the first element, whose each byte is 0. If an expression is given, that is the maximum length of the array. If NUL terminator is not found earlier, that's where the array ends.

## PARAMETER PACKS
Sometimes the actual function prototype varies slightly depending on the exact parameters given. For example, the number and types of printf parameters are not known in advance, but ltrace might be able to determine them in runtime. This feature has wider applicability, but currently the only parameter pack that ltrace supports is printf-style format string itself:

format

When format is seen in the parameter list, the underlying string argument is parsed, and GNU-style format specifiers are used to determine what the following actual arguments are. E.g. if the format string is "%s %d\n", it's as if the format was replaced by string, string, int.

## RETURN ARGUMENTS
C functions often use one or more arguments for returning values back to the caller. The caller provides a pointer to storage, which the called function initializes. Ltrace has some support for this idiom.

When a traced binary hits a function call, ltrace first fetches all arguments. It then displays left portion of the argument list. Only when the function returns does ltrace display right portion as well. Typically, left portion takes up all the arguments, and right portion only contains return value. But ltrace allows you to configure where exactly to put the dividing line by means of a + operator placed in front of an argument:

int asprintf(+string*, format);

Here, the first argument to asprintf is denoted as return argument, which means that displaying the whole argument list is delayed until the function returns:

a.out->asprintf( <unfinished ...>

libc.so.6->malloc(100) = 0x245b010

[... more calls here ...]

<... asprintf resumed> "X=1", "X=%d", 1) = 5

It is currently not possible to have an "inout" argument that passes information in both directions.

## EXAMPLES
In the following, the first is the C prototype, and following that is ltrace configuration line.

void func_charp_string(char str[]);

void func_charp_string(string);

enum e_foo {RED, GREEN, BLUE};

void func_enum(enum e_foo bar);

void func_enum(enum(RED,GREEN,BLUE)); - or -

typedef e_foo = enum(RED,GREEN,BLUE);

void func_enum(e_foo);

void func_arrayi(int arr[], int len);

void func_arrayi(array(int,arg2)*,int);

struct S1 {float f; char a; char b;};

struct S2 {char str[6]; float f;};

struct S1 func_struct(int a, struct S2, double d);

struct(float,char,char) func_struct(int, struct(string(array(char, 6)),float), double);

## AUTHOR
Petr Machata <pmachata@redhat.com>


lvm.conf

title: lvm.conf(5)

summary: Configuration file for LVM2

text:
# lvm.conf(5)

## NAME
lvm.conf — Configuration file for LVM2

## SYNOPSIS
/etc/lvm/lvm.conf

## DESCRIPTION
lvm.conf is loaded during the initialisation phase of lvm(8). This file can in turn lead to other files being loaded - settings read in later override earlier settings. File timestamps are checked between commands and if any have changed, all the files are reloaded.

For a description of each lvm.conf(5) setting, run:

lvmconfig --typeconfig default --withcomments --withspaces

The settings defined in lvm.conf can be overridden by any of these extended configuration methods:

direct config override on command line

The --config ConfigurationString command line option takes the ConfigurationString as direct string representation of the configuration to override the existing configuration. The ConfigurationString is of exactly the same format as used in any LVM configuration file.

profile config

A profile is a set of selected customizable configuration settings that are aimed to achieve a certain characteristics in various environments or uses. It's used to override existing configuration. Normally, the name of the profile should reflect that environment or use.

There are two groups of profiles recognised: command profiles and metadata profiles.

The command profile is used to override selected configuration settings at global LVM command level - it is applied at the very beginning of LVM command execution and it is used throughout the whole time of LVM command execution. The command profile is applied by using the --commandprofile ProfileName command line option that is recognised by all LVM2 commands.

The metadata profile is used to override selected configuration settings at Volume Group/Logical Volume level - it is applied independently for each Volume Group/Logical Volume that is being processed. As such, each Volume Group/Logical Volume can store the profile name used in its metadata so next time the Volume Group/Logical Volume is processed, the profile is applied automatically. If Volume Group and any of its Logical Volumes have different profiles defined, the profile defined for the Logical Volume is preferred. The metadata profile can be attached/detached by using the lvchange and vgchange commands and their --metadataprofile ProfileName and --detachprofile options or the --metadataprofile option during creation when using vgcreate or lvcreate command. The vgs and lvs reporting commands provide -o vg_profile and -o lv_profile output options to show the metadata profile currently attached to a Volume Group or a Logical Volume.

The set of options allowed for command profiles is mutually exclusive when compared to the set of options allowed for metadata profiles. The settings that belong to either of these two sets can't be mixed together and LVM tools will reject such profiles.

LVM itself provides a few predefined configuration profiles. Users are allowed to add more profiles with different values if needed. For this purpose, there's the command_profile_template.profile (for command profiles) and metadata_profile_template.profile (for metadata profiles) which contain all settings that are customizable by profiles of certain type. Users are encouraged to copy these template profiles and edit them as needed. Alternatively, the lvmconfig --file <ProfileName.profile> --type profilable-command <section> or lvmconfig --file <ProfileName.profile> --type profilable-metadata <section> can be used to generate a configuration with profilable settings in either of the type for given section and save it to new ProfileName.profile (if the section is not specified, all profilable settings are reported).

The profiles are stored in /etc/lvm/profile directory by default. This location can be changed by using the config/profile_dir setting. Each profile configuration is stored in ProfileName.profile file in the profile directory. When referencing the profile, the .profile suffix is left out.

tag config

See tags configuration setting description below.

When several configuration methods are used at the same time and when LVM looks for the value of a particular setting, it traverses this config cascade from left to right:

direct config override on command line → command profile config → metadata profile config → tag config → lvmlocal.conf → lvm.conf

No part of this cascade is compulsory. If there's no setting value found at the end of the cascade, a default value is used for that setting. Use lvmconfig to check what settings are in use and what the default values are.

## SYNTAX
This section describes the configuration file syntax.

Whitespace is not significant unless it is within quotes. This provides a wide choice of acceptable indentation styles. Comments begin with # and continue to the end of the line. They are treated as whitespace.

Here is an informal grammar:

file = value*

A configuration file consists of a set of values.

value = section | assignment

A value can either be a new section, or an assignment.

section = identifier '{' value* '}'

A section groups associated values together. If the same section is encountered multiple times, the contents of all instances are concatenated together in the order of appearance.

It is denoted by a name and delimited by curly brackets.

e.g. backup {

...

}

assignment = identifier '=' ( array | type )

An assignment associates a type with an identifier. If the identifier contains forward slashes, those are interpreted as path delimiters. The statement section/key = value is equivalent to section { key = value }. If multiple instances of the same key are encountered, only the last value is used (and a warning is issued).

e.g. level = 7

array = '[' ( type ',')* type ']' | '[' ']'

Inhomogeneous arrays are supported.

Elements must be separated by commas.

An empty array is acceptable.

An array with one element will be correctly interpreted if the array brackets are missing.

type = integer|float|string

integer = [0-9]*

float = [0-9]*'.'[0-9]*

string = '"' .* '"'

Strings with spaces must be enclosed in double quotes, single words that start with a letter can be left unquoted.

## SETTINGS
The lvmconfig command prints the LVM configuration settings in various ways. See the man page lvmconfig(8).

Command to print a list of all possible config settings, with their default values:

lvmconfig --type default

Command to print a list of all possible config settings, with their default values, and a full description of each as a comment:

lvmconfig --type default --withcomments

Command to print a list of all possible config settings, with their current values (configured, non-default values are shown):

lvmconfig --type current

Command to print all config settings that have been configured with a different value than the default (configured, non-default values are shown):

lvmconfig --type diff

Command to print a single config setting, with its default value, and a full description, where "Section" refers to the config section, e.g. global, and "Setting" refers to the name of the specific setting, e.g. umask:

lvmconfig --type default --withcomments Section/Setting

## FILES
/etc/lvm/lvm.conf

/etc/lvm/lvmlocal.conf

/etc/lvm/archive

/etc/lvm/backup

/etc/lvm/cache/.cache

/etc/lvm/profile

/run/lock/lvm

## SEE ALSO
lvm(8), lvmconfig(8)


lxc-usernet

package: lxc-core

title: lxc-usernet(5)

text:
# lxc-usernet(5)

## NAME
lxc-usernet - unprivileged user network administration file.

## DESCRIPTION
/etc/lxc/lxc-usernet controls the limits which the program lxc-user-nic places on network interfaces which an unprivileged user may create.

### CONFIGURATION
This file consists of multiple entries, one per line, of the form:

user type bridge number

or

@group type bridge number

Where

user

is the username to whom this entry applies.

@group

is the groupname to which this entry applies.

type

is the type of network interface being allowed. Only veth is currently supported.

bridge

is the bridge to which the network interfaces may be attached, for instance lxcbr0.

number

is the number or quota of network interfaces of the given type which the given user or group may attach to the given bridge, for instance 2.

Since a user can be specified both by username as well as one or more usergroups, it is possible that several configuration lines enable that user to create network interfaces. In such cases, any interfaces create are counted towards the quotas of the user or group in the order in which they appear in the file. If the quota of one line is full, the rest will be parsed until one is found or the end of the file.

## SEE ALSO
lxc(1), lxc-user-nic(1)


lxc.conf

title: lxc.conf(5)

summary: Configuration files for LXC.

text:
# lxc.conf(5)

## NAME
lxc.conf - Configuration files for LXC.

## DESCRIPTION
LXC configuration is split in two parts. Container configuration and system configuration.

### CONTAINER CONFIGURATION
The container configuration is held in the config stored in the container's directory.

A basic configuration is generated at container creation time with the default's recommended for the chosen template as well as extra default keys coming from the default.conf file.

That default.conf file is either located at /etc/lxc/default.conf or for unprivileged containers at ~/.config/lxc/default.conf.

Details about the syntax of this file can be found in: lxc.container.conf(5)

### SYSTEM CONFIGURATION
The system configuration is located at /etc/lxc/lxc.conf or ~/.config/lxc/lxc.conf for unprivileged containers.

This configuration file is used to set values such as default lookup paths and storage backend settings for LXC.

Details about the syntax of this file can be found in: lxc.system.conf(5)

## SEE ALSO
lxc(1), lxc.container.conf(5), lxc.system.conf(5), lxc-usernet(5)