auto.master

package: autofs

title: auto.master(5)

text:
# auto.master(5)

## NAME
auto.master - Master Map for automounter consulted by autofs

## DESCRIPTION
The auto.master map is consulted to set up automount managed mount points when the autofs(8) script is invoked or the automount(8) program is run. Each line describes a mount point and refers to an autofs map describing file systems to be mounted under the mount point.

The default location of the master map is /etc/auto.master but an alternate name may be given on the command line when running the automounter and the default master map may changed by setting the MASTER_MAP_NAME configuration variable in /etc/sysconfig/autofs. If the master map name has no path then the system Name Service Switch configuration will be consulted and each of the sources searched in line with the rules given in the Name Service Switch configuration.

Access to mounts in maps is governed by a key.

For direct maps the mount point is always specified as:

/-

and the key used within the direct map is the full path to the mount point. The direct map may have multiple entries in the master map.

For indirect maps access is by using the path scheme:

/mount-point/key

where mount-point is one of the entries listed in the master map. The key is a single directory component and is matched against entries in the map given in the entry (See autofs(5)).

Additionally, a map may be included from its source as if it were itself present in the master map by including a line of the form:

+[maptype[,format]:]map [options]

and automount(8) will process the map according to the specification described below for map entries. Plus map inclusion is only permitted in file map sources. Indirect map entries must be unique in the master map so second and subsequent entries for an indirect mount point are ignored by automount(8).

NOTE:

autofs currently does not collapse multiple slashes in paths, so it is important to ensure paths used in maps are correct. If unnecessary multiple slashes are present in a path it can lead to unexpected failures such as an inability to expire automounts. An exception to this is a trailing slash at the end of the automount point path in the master map which will be removed if present.

## FORMAT
Master map entries have three fields separated by an arbitrary number of spaces or tabs. Lines beginning with # are comments. The first field is the mount point described above and the second field is the name of the map to be consulted for the mount point followed by the third field which contains options to be applied to all entries in the map.

The format of a master map entry is:

mount-point [map-type[,format]:]map [options]

mount-point

Base location for the autofs filesystem to be mounted. For indirect maps this directory will be created (as with mkdir -p) and is removed when the autofs filesystem is umounted.

map-type

Type of map used for this mount point. The following are valid map types:

file

The map is a regular text file.

program

The map is an executable program, which is passed a key on the command line and returns an entry (everything besides the key) on stdout if successful. Optinally, the keyword exec may be used as a synonym for program to avoid confusion with amd formated maps mount type program.

yp

The map is a NIS (YP) database.

nisplus

The map is a NIS+ database.

hesiod

The map is a hesiod database whose filsys entries are used for maps.

ldap or ldaps

The map is stored in an LDAP directory. If ldaps is used the appropriate certificate must be configured in the LDAP client.

multi

This map type allows the specification of multiple maps separated by "--". These maps are searched in order to resolve key lookups.

dir

This map type can be used at + master map including notation. The contents of files under given directory are included to the master map. The name of file to be included must be ended with ".autofs". A file will be ignored if its name is not ended with the suffix. In addition a dot file, a file which name is started with "." is also ignored.

format

Format of the map data; currently the formats recognized are sun, which is a subset of the Sun automounter map format, hesiod, for hesiod filesys entries and amd for amd formated map entries. If the format is left unspecified, it defaults to sun for all map types except hesiod unless it is a top level amd mount that has a configuration entry for the mount point path, in which case the format used is amd.

map

Name of the map to use. This is an absolute UNIX pathname for maps of types file, dir, or program, and the name of a database in the case for maps of type yp, nisplus, or hesiod or the dn of an LDAP entry for maps of type ldap.

options

Any remaining command line arguments without leading dashes (-) are taken as options (-o) to mount. Arguments with leading dashes are considered options for the maps and are passed to automount (8). The sun format supports the following options:

-Dvariable=value

Replace variable with value in map substitutions.

-strict

Treat errors when mounting file systems as fatal. This is important when multiple file systems should be mounted (`multimounts'). If this option is given, no file system is mounted at all if at least one file system can't be mounted.

[no]browse

This is an autofs specific option that is a pseudo mount option and so is given without a leading dash. Use of the browse option pre-creates mount point directories for indirect mount maps so the map keys can be seen in a directory listing without being mounted. Use of this option can cause performance problem if the indirect map is large so it should be used with caution. The internal program default is to enable browse mode for indirect mounts but the default installed configuration overrides this by setting BROWSE_MODE to "no" because of the potential performance problem. This option does the same as the deprecated --ghost option, the browse option is preferred because it is used by other autofs implementations.

nobind

This is an autofs specific option that is a pseudo mount option and so is given without a leading dash. It may be used either in the master map entry (so it effects all the map entries) or with individual map entries to prevent bind mounting of local NFS filesystems. For direct mount maps the option is only effective if specified on the first direct map entry and is applied to all direct mount maps in the master map. It is ignored if given on subsequent direct map entries. It may be used on individual map entries of both types. Preventing bind mounts of NFS file systems can no longer be done by using the "port=" option, the nobind option must be used instead.

symlink

This option makes bind mounting use a symlink instead of an actual bind mount. It is an autofs specific option that is a pseudo mount option and so is given without a leading dash. It may be used with indirect map entries only, either in the master map (so it effects all map entries) or with individual map entries. The option is ignored for direct mounts and non-root offest mount entries.

strictexpire

Use a strict expire policy for this automount. Using this option means that last use of autofs directory entries will not be updated during path walks so that mounts in an automount won't be kept mounted by applications scanning the mount tree. Note that this doesn't completely resolve the problem of expired automounts being immediately re-mounted due to application accesses triggered by the expire itself.

slave, private or shared

This option allows mount propagation of bind mounts to be set to slave, private or shared. This option defaults to slave if no option is given. When using multi-mounts that have bind mounts the bind mount will have the same properties as its parent which is commonly propagation shared. And if the mount target is also propagation shared this can lead to a deadlock when attempting to access the offset mounts. When this happens an unwanted offset mount is propagated back to the target file system resulting in a deadlock since the automount target is itself an (unwanted) automount trigger. This option is an autofs pseudo mount option that can be used in the master map only.

-r, --random-multimount-selection

Enables the use of random selection when choosing a host from a list of replicated servers. This option is applied to this mount only, overriding the global setting that may be specified on the command line.

-w, --use-weight-only

Use only specified weights for server selection where more than one server is specified in the map entry. If no server weights are given then each available server will be tried in the order listed, within proximity.

-t, --timeout <seconds>

Set the expire timeout for map entries. This option can be used to override the global default given either on the command line or in the configuration.

-n, --negative-timeout <seconds>

Set the timeout for caching failed key lookups. This option can be used to override the global default given either on the command line or in the configuration.

--mode <octal_mode>

Set the directory mode for the base location of the autofs mount point. If this option is given, autofs will chmod that directory with this mode.

## BUILTIN MAP -hosts
If "-hosts" is given as the map then accessing a key under the mount point which corresponds to a hostname will allow access to the exports of that host. The hosts map cannot be dynamically updated and requires a HUP signal to be sent to the daemon for it to check hosts for an update. Due to possible hierarchic dependencies within a mount tree, it might not be completely updated during the HUP signal processing.

For example, with an entry in the master map of /net -hosts accessing /net/myserver will mount exports from myserver on directories below /net/myserver.

NOTE: mounts done from a hosts map will be mounted with the "nosuid,nodev" options unless overridden by explicitly specifying the "suid", "dev" options in the master map entry.

## BUILTIN MAP -null
If "-null" is given as the map it is used to tell automount(8) to ignore a subsequent master map entry with the given path.

It can be used for paths that appear in the master map or in direct mount maps (but not in direct mount maps themselves) or as a key in an indirect mount map.

An indirect mount map key can be nulled. If so the map key is ignored and does not result in a mount attempt (essentially the key lookup is abandoned early on).

An indirect mount map top level mount point path can be nulled. If so no mounts from the nulled mount are performed (essentially it isn't mounted).

Direct mount map path entries can be nulled. Since they must be present at startup they are (notionally) part of the master map so direct mount paths that use the -null map may be used in the master map to ignore subsequent direct mount map entries.

A nulled master map entry path will ignore a single subsequent matching entry. Any matching entry following that will be treated as it normally would be. An example use of this is allowing local master map entries to override remote ones.

NOTE: If a duplicate master map entry path is seen (excluding paths of null entries) it will be ignored and noted in the log, that is the first encountered master map entry is used unless there is a corresponding null entry.

## LDAP MAPS
If the map type ldap is specified the mapname is of the form [//servername/]dn, where the optional servername is the name of the LDAP server to query, and dn is the Distinguished Name of a subtree to search for map entries. The old style ldap:servername:mapname is also understood. Alternatively, the type can be obtained from the Name Service Switch configuration, in which case the map name alone must be given.

If no schema is set in the autofs configuration then autofs will check each of the commonly used schema for a valid entry and if one is found it will be used for subsequent lookups.

There are three common schemas in use:

nisMap

Entries in the nisMap schema are nisObject objects in the specified subtree, where the cn attribute is the key (the wildcard key is "/"), and the nisMapEntry attribute contains the information used by the automounter.

automountMap

The automountMap schema has two variations that differ in the attribute used for the map key. Entries in the automountMap schema are automount objects in the specified subtree, where the cn or automountKey attribute (depending on local usage) is the key (the wildcard key is "/"), and the automountInformation attribute contains the information used by the automounter. Note that the cn attribute is case insensitive.

The object classes and attributes used for accessing automount maps in LDAP can be changed by setting entries in the autofs configuration located in /etc/sysconfig/autofs.conf.

NOTE:

If a schema is given in the configuration then all the schema configuration values must be set, any partial schema specification will be ignored.

For amd format maps a different schema is used:

amdMap

The amdmap schema contains attributes amdmapName, amdmapKey and amdmapValue where amdmapName contains the name of the containing map, amdmapKey contains the map key and amdmapValue contains the map entry.

## LDAP AUTHENTICATION, ENCRYPTED AND CERTIFIED CONNECTIONS
LDAP authenticated binds, TLS encrypted connections and certification may be used by setting appropriate values in the autofs authentication configuration file and configuring the LDAP client with appropriate settings. The default location of this file is /etc/autofs_ldap_auth.conf.

If this file exists it will be used to establish whether TLS or authentication should be used.

An example of this file is:

```
<?xml version="1.0" ?>
<autofs_ldap_sasl_conf

        usetls="yes"

        tlsrequired="no"

        authrequired="no"

        authtype="DIGEST-MD5"

        user="xyz"

        secret="abc"
/>
```

If TLS encryption is to be used the location of the Certificate Authority certificate must be set within the LDAP client configuration in order to validate the server certificate. If, in addition, a certified connection is to be used then the client certificate and private key file locations must also be configured within the LDAP client.

In OpenLDAP these may be configured in the ldap.conf file or in the per-user configuration. For example, it may be sensible to use the system wide configuration for the location of the Certificate Authority certificate and set the location of the client certificate and private key in the per-user configuration. The location of these files and the configuration entry requirements is system dependent so the documentation for your installation will need to be consulted to get further information.

See autofs_ldap_auth.conf (5) for more information.

## EXAMPLE

```
/-	auto.data
/home	/etc/auto.home
/mnt	yp:mnt.map
```

This will generate two mountpoints for /home and /mnt and install direct mount triggers for each entry in the direct mount map auto.data. All accesses to /home will lead to the consultation of the map in /etc/auto.home and all accesses to /mnt will consult the NIS map mnt.map. All accesses to paths in the map auto.data will trigger mounts when they are accessed and the Name Service Switch configuration will be used to locate the source of the map auto.data.

To avoid making edits to /etc/auto.master, /etc/auto.master.d may be used. Files in that directory must have a ".autofs" suffix, e.g. /etc/auto.master.d/extra.autofs. Such files contain lines of the same format as the auto.master file, e.g.

```
/foo    /etc/auto.foo
/baz    yp:baz.map
```

## SEE ALSO
automount(8), autofs(5), autofs(8), autofs.conf(5), autofs_ldap_auth.conf(5).

## AUTHOR
This manual page was written by Christoph Lameter <chris@waterf.org>, for the Debian GNU/Linux system. Edited by <hpa@transmeta.com> and Ian Kent <raven@themaw.net> .


autofs

title: autofs(5)

summary: Format of the automounter maps

text:
# autofs(5)

## NAME
autofs - Format of the automounter maps

## DESCRIPTION
The automounter maps are FILE, NIS, NISPLUS or LDAP (including LDAP via SSS) referred to by the master map of the automounter (see auto.master(5)). These maps describe how file systems below the mount point of the map (given in the master map) are to be mounted. This page describes the sun map format; if another map format, other than amd , is specified (e.g. hesiod), this documentation does not apply.

Indirect maps, except for the internal hosts map, can be changed on the fly and the automouter will recognize those changes on the next operation it performs on that map. Direct maps require a HUP signal be sent to the daemon to refresh their contents as does the master map.

## SUN FORMAT
This is a description of the text file format. Other methods of specifying these files may exist. All empty lines or lines beginning with # are ignored. The basic format of one line in such maps is:

key [-options] location

key

For indirect mounts this is the part of the path name between the mount point and the path into the filesystem when it is mounted. Usually you can think about the key as a sub-directory name below the autofs managed mount point. For direct mounts this is the full path of each mount point. This map is always associated with the /- mount point in the master map.

options

Zero or more options may be given. Options can also be given in the auto.master file in which case both values are cumulative (this is a difference from SunOS). The options are a list of comma separated options as customary for the mount(8) command. There are several special options

-fstype=

is used to specify a filesystem type if the filesystem is not of the default NFS type. This option is processed by the automounter and not by the mount command.

-strict

is used to treat errors when mounting file systems as fatal. This is important when multiple file systems should be mounted (`multi-mounts'). If this option is given, no file system is mounted at all if at least one file system can't be mounted.

-use-weight-only

is used to make the weight the sole factor in selecting a server when multiple servers are present in a map entry.

-no-use-weight-only

can be used to negate the option if it is present in the master map entry for the map but is not wanted for the given mount.

location

The location specifies from where the file system is to be mounted. In the most cases this will be an NFS volume and the usual notation host:pathname is used to indicate the remote filesystem and path to be mounted. If the filesystem to be mounted begins with a / (such as local /dev entries or smbfs shares) a : needs to be prefixed (e.g. :/dev/sda1).

## EXAMPLE
Indirect map:

```
kernel	-ro,soft	ftp.kernel.org:/pub/linux
boot	-fstype=ext2	:/dev/hda1
windoze	-fstype=smbfs	://windoze/c
removable	-fstype=ext2	:/dev/hdd
cd	-fstype=iso9660,ro	:/dev/hdc
floppy	-fstype=auto	:/dev/fd0
server	-rw,hard	/ -ro myserver.me.org:/ \
			/usr myserver.me.org:/usr \
			/home myserver.me.org:/home
```

In the first line we have a NFS remote mount of the kernel directory on ftp.kernel.org. This is mounted read-only. The second line mounts an ext2 volume from a local ide drive. The third makes a share exported from a Windows machine available for automounting. The rest should be fairly self-explanatory. The last entry (the last three lines) is an example of a multi-map (see below).

If you use the automounter for a filesystem without access permissions (like vfat), users usually can't write on such a filesystem because it is mounted as user root. You can solve this problem by passing the option gid=<gid>, e.g. gid=floppy. The filesystem is then mounted as group floppy instead of root. Then you can add the users to this group, and they can write to the filesystem. Here's an example entry for an autofs map:

```
floppy-vfat  -fstype=vfat,sync,gid=floppy,umask=002  :/dev/fd0
```

Direct map:

```
/nfs/apps/mozilla	bogus:/usr/local/moxill
/nfs/data/budgets	tiger:/usr/local/budgets
/tst/sbin		bogus:/usr/sbin
```

## FEATURES

### Map Key Substitution
An & character in the location is expanded to the value of the key field that matched the line (which probably only makes sense together with a wildcard key).

### Wildcard Key
A map key of * denotes a wild-card entry. This entry is consulted if the specified key does not exist in the map. A typical wild-card entry looks like this:

```
*	server:/export/home/&
```

The special character '&' will be replaced by the provided key. So, in the example above, a lookup for the key 'foo' would yield a mount of server:/export/home/foo.

### Variable Substitution
The following special variables will be substituted in the location field of an automounter map entry if prefixed with $ as customary from shell scripts (curly braces can be used to separate the field name):

```
ARCH	Architecture (uname -m)
CPU	Processor Type
HOST	Hostname (uname -n)
OSNAME	Operating System (uname -s)
OSREL	Release of OS (uname -r)
OSVERS	Version of OS (uname -v)
```

autofs provides additional variables that are set based on the user requesting the mount:

```
USER	The user login name
UID	The user login ID
GROUP	The user group name
GID	The user group ID
HOME	The user home directory
SHOST	Short hostname (domain part removed if present)
```

If a program map is used these standard environment variables will have a prefix of "AUTOFS_" to prevent interpreted languages like python from being able to load and execute arbitrary code from a user home directory.

Additional entries can be defined with the -Dvariable=Value map-option to automount(8).

### Executable Maps
A map can be marked as executable. A program map will be called with the key as an argument. It may return no lines of output if there's an error, or one or more lines containing a map entry (with \ quoting line breaks). The map entry corresponds to what would normally follow a map key.

An executable map can return an error code to indicate the failure in addition to no output at all. All output sent to stderr is logged into the system logs.

### Multiple Mounts
A multi-mount map can be used to name multiple filesystems to mount. It takes the form:

```
key [ -options ] [[/] location [/relative-mount-point [ -options ] location...]...
```

This may extend over multiple lines, quoting the line-breaks with `\´. If present, the per-mountpoint mount-options are appended to the default mount-options. This behaviour may be overridden by the append_options configuration setting.

### Replicated Server
A mount location can specify multiple hosts for a location, portentially with a different export path for the same file system. Historically these different locations are read-only and provide the same replicated file system.

```
Multiple replicated hosts, same path:
<path> host1,host2,hostn:/path/path
Multiple hosts, some with same path, some with another
<path> host1,host2:/blah host3:/some/other/path
Multiple replicated hosts, different (potentially) paths:
<path> host1:/path/pathA host2:/path/pathB
Mutliple weighted, replicated hosts same path:
<path> host1(5),host2(6),host3(1):/path/path
Multiple weighted, replicated hosts different (potentially) paths:
<path> host1(3):/path/pathA host2(5):/path/pathB
Anything else is questionable and unsupported, but these variations will also work:
<path> host1(3),host:/blah
```

## UNSUPPORTED
This version of the automounter supports direct maps stored in FILE, NIS, NISPLUS and LDAP (including LDAP via SSS) only.

## AMD FORMAT
This is a description of the text file format. Other methods of specifying mount map entries may be required for different map sources. All empty lines or lines beginning with # are ignored. The basic format of one line in such maps is:

key location-list

key

A key is a path (or a single path component alone) that may end in the wildcard key, "*", or the wildcard key alone and must not begin with the "/" character.

location-list

Following the key is a mount location-list.

A location-list list has the following syntax:

location[ location[ ... ]] [|| location[ location[ ... ]]

A mount location-list can use the cut operator, ||, to specify locations that should be tried if none of the locations to the left of it where selected for a mount attempt.

A mount location consists of an optional colon separated list of selectors, followed by a colon separated list of option:=value pairs.

The selectors that may be used return a value or boolean result. Those that return a value may be to used with the comparison operators == and != and those that return a boolean result may be negated with the !.

For a location to be selected for a mount attempt all of its selectors must evaluate to true. If a location is selected for a mount attempt and succeeds the lookup is completed and returns success. If the mount attempt fails the procedure continues with the next location until they have all been tried.

In addition, some selectors take no arguments, some one argument and others optionally take two arguments.

The selectors that take no arguments are:

arch

The machine architecture which, if not set in the configuration, is obtained using uname(2).

karch

The machine kernel architecture which, if not set in the configuration, is obtained using uname(2).

os

The operating system name, if not set in the configuration, is obtained using uname(2).

osver

The operating system version, if not set in the configuration, is obtained using uname(2).

full_os

The full operating system name, if not set in the configuration this selector has no value.

vendor

The operating system vendor name, if not set in the configuration this selector has the value "unknown".

byte

The endianness of the hardware.

cluster

The name of the local cluster. It has a value only if it is set in the configuration.

autodir

The base path under which external mounts are done if they are needed. Most mounts are done in place but some can't be and this is the base path under which those mounts will be done.

domain

The local domain name. It is set to the value of the configuration option sub_domain. If sub_domain is not given in the configuration it is set to the domain part of the local host name, as given by gethostname(2).

host

The local host name, without the domain part, as given by gethostname(2).

hostd

The full host name. If sub_domain is given in the configuration this is set to the contatenation of host and sub_domain deperated by a .. If sub_domain is not set in the configuration the value of domain is used instead of sub_domain.

uid

The numeric value of the uid of the user that first requested the mount. Note this is usual the same as that used by amd but can be different within autofs.

gid

The numeric value of the gid of the user that first requested the mount. Note this is usual the same as that used by amd but can be different within autofs.

key

The string value of the key being looked up.

map

The string value of the map name used to lookup keys.

path

The string value of the full path to the mount being requested.

dollar

Evaluates to the string "$".

The selectors that take one argument are:

in_network(network) , network(network) , netnumber(network) , wire(network)

These selectors are all the same. in_network() is the preferred usage. The network argument is an address (which may include a subnet mask) or network name. The function compares network against each interface and returns true if network belongs to the network the interface is connected to.

xhost(hostname)

The xhost() selector compares hostname to the ${host} and if it doesn't match it attempts to lookup the cannonical name of hostname and compares it to {host} as well.

exists(filename)

Returns true if filename exits as determined by lstat(2).

true()

Evaluates to true, the argument is ignored and may be empty.

false()

Evaluates to false, the argument is ignored and may be empty.

The selectors that take up to two arguments are:

netgrp(netgroup[,hostname])

The netgrp() selector returns true if hostname is a member of the netgroup netgroup. If hostname is not given ${host} is used for the comparison.

netgrpd(netgroup[,hostname])

The netgrpd()i selector behaves the same as netgrp() except that if hostname is not given ${hostd}, the fully qualified hostname, is used instead of ${host}.

The options that may be used are:

type

This is the mount filesystem type. It can have a value of auto, link, linkx, host, lofs, ext2-4, xfs, nfs, nfsl or cdfs. Other types that are not yet implemented or are not available in autofs are nfsx, lustre, jfs, program, cachefs and direct.

maptype

The maptype option specifies the type of the map source and can have a value of file, nis, nisplus, exec, ldap or hesiod. Map sources either not yet implemented or not available in autofs are sss, ndbm, passwd and union.

fs

The option fs is used to specify the local filesystem. The meaning of this option (and whether or not it is used) is dependent on the mount filesystem type.

rhost

The remote host name for network mount requests.

rfs

The remote host filesystem path for network mount requests.

dev

Must resolve to the device file for local device mount requests.

sublink

The sublink option is used to specify a subdirectory within the mount location to which this entry will point.

pref

The pref option is used to specify a prefix that is prepended to the lookup key before looking up the map entry key.

opts

The opts option is used to specify mount options to be used for the mount. If a "-" is given it is ignored. Options that may be used are dependend on the mount filesystem.

addopts

The addopts option is used to specify additional mount options used in addition to the default mount options for the mount location.

remopts

The addopts option is used to specify mount options used instead the options given in opts when the mount location is on a remote retwork.

A number of options aren't available or aren't yet implemented

within autofs, these are:

cache

The cache option isn't used by autofs. The map entry cache is continually updated and stale entries cleaned on re-load when map changes are detected so these configuration entries are not used. The regex map key matching is not implemented and may not be due to the potential overhead of the full map scans needed on every key lookup.

cachedir

The cachefs filesystem is not available on Linux, a different implementation is used for caching network mounted file systems.

mount , unmount , umount

These options are used by the amd program mount type which is not yet implemented.

delay

This option is not used by the autofs implementation and is ignored.

## FEATURES

### Key Matching
The amd parser key matching is unusual.

The key string to be looked up is constructed by prepending the prefix, if there is one.

The resulting relative path string is matched by first trying the sting itself. If no match is found the last component of the key string is replaced with the wilcard match cahracter ("*") and a wildcard match is attemted. This process continues until a match is found or until the last match, against the wilcard match key alone, fails to match a map entry and the key lookup fails.

### Macro Usage
Macros are used a lot in the autofs amd implementation.

Many of the option values are set as macro variables corresponding to the option name during the map entry parse. So they may be used in subsequent option values. Beware though, the order in which option values is not necessarily left to right so you may get unexpected results.

## EXAMPLE
Example NFS mount map:

Assuming we have the autofs master map entry:

```
/test	file,amd:/etc/amd.test
```

And the following map in /etc/amd.test:

```
/defaults	type:=nfs;rhost:=bilbo
apps	rfs:=/autofs
util	rhost:=zeus;rfs:=/work/util
local	rfs:=/shared;sublink:=local
```

In the first line we have an NFS remote mount of the exported directory /autofs from host bilbo which would be mounted on /test/apps. Next another nfs mount for the exported directory /work/util from host zeus. This would be mounted on /test/util.

Finally, we have an example of the use of the sublink option. In this case the filesystem bilbo:/shared would be mounted on a path external the automount directory (under the direcory given by configuration option auto_dir) and the path /test/local either symlinked or bind mounted (depending on the setting autofs_use_lofs) to the "local" subdirectory of the external mount.

## NOTES
To be able to use IPv6 within autofs maps the package must be build to use the libtirpc library for its RPC communications. This is becuase the glibc RPC implementation doesn't support IPv6 and is depricated so this is not likely to change.

## SEE ALSO
automount(8), auto.master(5), autofs(8), autofs.conf(5), mount(8), autofs_ldap_auth.conf(5).

## AUTHOR
This manual page was written by Christoph Lameter <chris@waterf.org>, for the Debian GNU/Linux system. Edited by H. Peter Avian <hpa@transmeta.com>, Jeremy Fitzhardinge <jeremy@goop.org> and Ian Kent <raven@themaw.net>.

branch: sisyphus


autofs.conf

title: autofs.conf(5)

summary: autofs configuration

text:
# autofs.conf(5)

## NAME
autofs.conf - autofs configuration

## DESCRIPTION
Configuration settings used by automount(8) may be changed in the configuration file /etc/autofs.conf.

This file contains two primary sections, autofs and amd.

Configuration entries may be present at the beginning of the configuration file without a section header and are implicitly included as part of the autofs section.

Each section name is enclosed in square brackets with spaces between the brackets and the section name. The amd section may be followed by further sections, named by the top level mount point path, that contain per mount configuration settings.

## SECTION autofs CONFIGURATION OPTIONS
Configuration settings available are:

+.B open_file_limit

+.br +Set the maximum number of open files. Note there may be other limits +within the system that prevent this from being set, systemd for example +may need a setting in the unit file to increase its default. The autofs +default is 20480. +.TP timeout

Sets the default mount timeout in seconds. The internal program default is 10 minutes, but the default installed configuration overrides this and sets the timeout to 5 minutes to be consistent with earlier autofs releases.

master_wait

Sets the default maximum number of retries (actaul iterations is half this, each is delayed by 2 seconds before retrying) waiting for the master map to become available if it cannot be read at program start (program default 10, then continue). This can be longer if the map source itself waits for availability (such as sss).

negative_timeout

Set the default timeout for caching failed key lookups (program default 60). If the equivalent command line option is given it will override this setting.

positive_timeout

Set the default timeout for using cached map entries (program default 120). If the equivalent command line option is given it will override this setting.

mount_verbose

Use the verbose flag when spawning mount(8), and log some process info about the requestor and its parent (program default "no").

mount_wait

Set the default time to wait for a response from a spawned mount(8) before sending it a SIGTERM. Note that we still need to wait for the RPC layer to timeout before the sub-process exits so this isn't ideal but it is the best we can do. The default is to wait until mount(8) returns without intervention.

umount_wait

Set the default time to wait for a response from a spawned umount(8) before sending it a SIGTERM. Note that we still need to wait for the RPC layer to timeout before the sub-process exits so this isn't ideal but it is the best we can do.

browse_mode

Maps are browsable by default (program default "yes").

mount_nfs_default_protocol

Set the default protocol that mount.nfs(8) uses when performing a mount (program default 3). Autofs needs to know the default NFS protocol that mount.nfs(8) uses so it can do special case handling for its availability probe for different NFS protocols. Since we can't identify this default automatically we need to set it in the autofs configuration.

append_options

Determine whether global options, given on the command line or per mount in the master map, are appended to map entry options or if the map entry options replace the global options (program default "yes", append options).

logging

set default log level "none", "verbose" or "debug" (program default "none").

force_standard_program_map_env

override the use of a prefix with standard environment variables when a program map is executed. Since program maps are run as the privileged user setting these standard environment variables opens automount(8) to potential user privilege escalation when the program map is written in a language that can load components from, for example, a user home directory (program default "no").

map_hash_table_size

This configuration option may be used to change the number of hash table slots (default 1024). This configuration option affects the overhead of searching the map entry cache for map entries when there are a large number of entries. It affects the number of entries that must be looked at to locate a map entry in the map entry cache. For example, the default of 1024 and a direct map with 8000 entries would result in each slot containing an average of 8 entries, which should be acceptable.

However, if excessive CPU usage is observed during automount lookups increasing this option can reduce the CPU overhead considerably because it reduces the length of the search chains.

Note that the number of entries in a map doesn't necessarily relate to the number of entries used in the map entry cache.

There are two distinct cases where the map hash table can make a significant difference, direct maps and indirect maps that use the "browse" option.

For indirect maps that do not use the "browse" option entries are added to the map entry cache at lookup so the number of active cache entries, in this case, is usually much less than the number of entries in the map. In this last case it would be unusual for the map entry cache to grow large enough to warrant increasing the default before an event that cleans stale entries, a map re-read for example.

use_hostname_for_mounts

NFS mounts where the host name resolves to more than one IP address are probed for availability and to establish the order in which mounts to them should be tried. To ensure that mount attempts are made only to hosts that are responding and are tried in the order of hosts with the quickest response the IP address of the host needs to be used for the mount. If it is necessary to use the hostname given in the map entry for the mount regardless, then set this option to "yes".

Be aware that if this is done there is no defense against the host name resolving to one that isn't responding and while the number of attempts at a successful mount will correspond to the number of addresses the host name resolves to the order will also not correspond to fastest responding hosts.

disable_not_found_message

The original request to add this log message needed it to be unconditional. That produces, IMHO, unnecessary noise in the log so a configuration option has been added to provide the ability to turn it off. The default is "no" to maintain the current behaviour.

use_ignore_mount_option

An option to enable the use of autofs pseudo option "disable". This option is used as a hint to user space that the mount entry should be ommitted from mount table listings. The default is "no" to avoid unexpected changes in behaviour and so is an opt-in setting.

sss_master_map_wait

Set the time to wait and retry if sssd is unable to read the master map at program start. Program default is 0 (don't wait) or 10 if sss supports returning EHSTDOWN when the provider isn't available. If the sss library supports returning EHOSTDOWN when the provider is down then this value is how long to wait between retries reading the master map. When reading dependent maps or looking up a map key this value is multiplied by the number of retries that would be used when reading the master map.

use_mount_request_log_id

Set whether to use a mount request log id so that log entries for specific mount requests can be easily identified in logs that have multiple concurrent requests. Default is don't use mount request log ids.

### LDAP Configuration
Configuration settings available are:

ldap_timeout

Set the network response timeout (default 8). Set timeout value for the synchronous API calls. The default is the LDAP library default of an infinite timeout.

ldap_network_timeout

Set the network response timeout (default 8).

ldap_uri

A space separated list of server uris of the form <proto>://<server>[/] where <proto> can be ldap or ldaps. The option can be given multiple times. Map entries that include a server name override this option and it is then not used. Default is an empty list in which case either the server given in a map entry or the LDAP configured default is used. This uri list is read at startup and whenever the daemon receives a HUP signal. This configuration option can also be used to request autofs lookup SRV RRs for a domain of the form <proto>:///[<domain dn>]. Note that a trailing "/" is not allowed when using this form. If the domain dn is not specified the dns domain name (if any) is used to construct the domain dn for the SRV RR lookup. The server list returned from an SRV RR lookup is refreshed according to the minimum ttl found in the SRV RR records or after one hour, whichever is less.

search_base

The base dn to use when searching for amap base dn. This entry may be given multiple times and each will be checked for a map base dn in the order they occur in the configuration. The search base list is read at startup and whenever the daemon recieves a HUP signal.

map_object_class

The map object class. In the nisMap schema this corresponds to the class nisMap and in the automountMap schema it corresponds to the class automountMap.

entry_object_class

The map entry object class. In the nisMap schema this corresponds to the class nisObject and in the automountMap schema it corresponds to the class automount.

map_attribute

The attribute used to identify the name of the map to which this entry belongs. In the nisMap schema this corresponds to the attribute nisMapName and in the automountMap schema it corresponds to the attribute ou or automountMapName.

entry_attribute

The attribute used to identify a map key. In the nisMap schema this corresponds to the attribute cn and in the automountMap schema it corresponds to the attribute automountKey.

value_attribute

The attribute used to identify the value of the map entry. In the nisMap schema this corresponds to the attribute nisMapEntry and in the automountMap schema it corresponds to the attribute automountInformation.

NOTE:

It is essential that entries use class and attribute in a consistent manner for correct operation of autofs. For example mixing cn and automountKey attributes in automount schema will not work as expected.

auth_conf_file

This configuration option may be used to specify an alternate location for the ldap authentication configuration file. See autofs_ldap_auth.conf(5) for more information.

## SECTION amd CONFIGURATION OPTIONS
A number of the amd configuration options are not used by autofs, some because they are not relevant within autofs, some because they are done differently in autofs and others that are not yet implemented.

Since mount_type is always autofs (because there's no user space NFS server) the configuration entries relating to that aren't used. Also, server availability is done differently within autofs so the options that relate to the amd server monitoring sub-system are also not used.

These options are mount_type, auto_attrcache, portmap_program, nfs_vers_ping, nfs_allow_any_interface, nfs_allow_insecure_port, nfs_proto, nfs_retransmit_counter, nfs_retransmit_counter_udp, nfs_retransmit_counter_tcp, nfs_retransmit_counter_toplvl, nfs_retry_interval, nfs_retry_interval_udp, nfs_retry_interval_tcp, nfs_retry_interval_toplvl and nfs_vers.

Other options that are not used within the autofs implementation:

log_file, truncate_log

sends its output to syslog so an alternate log file (or truncating the log) can't be used.

print_pid

There's no corresponding option for this within autofs.

use_tcpwrappers, show_statfs_entries

There's no user space NFS server to control access to so this option isn't relevant. The show_statfs_entries can't be implemented for the same reason.

debug_mtab_file

There's no user space NFS server and autofs avoids using file based mtab whenever possible.

sun_map_syntax

Sun map format is handled by autofs itself.

plock, show_statfs_entries, preferred_amq_port

Are not supported by autofs.

ldap_cache_maxmem, ldap_cache_seconds

External ldap caching is not used by autofs.

ldap_proto_version

autofs always attempts to use the highest available ldap protocol version.

cache_duration, map_reload_interval, map_options

The map entry cache is continually updated and stale entries cleaned on re-load, which is done when map changes are detected so these configuration entries are not used by autofs. An exception to this is the case where the map is large. In this case it may be necessary to read the whole map at startup even if browsing is not enabled. Adding the cache:=all option to map_options can be used to for this.

localhost_address

This is not used within autofs. This configuration option was only used in the amd user space server code and is not relevant within autofs.

Options that are handled differently within autofs:

pid_file

To specify a pid file name a command line option must be used on startup.

print_version

Program version and feature information is obtained by using the automount command line option "-V".

debug_options , log_options

autofs has somewhat more limited logging and debug logging options. When the log_options options is encountered it is converted to the nearest matching autofs logging option. Since the configuration option debug_options would be handled the same way it is ignored.

restart_mounts

This option has no sensible meaning within autofs because autofs always tries to re-connect to existing mounts. While this has its own set of problems not re-connecting to existing mounts always results in a non-functional automount tree if mounts were busy at the last shutdown (as is also the case with amd when using mount_type autofs).

forced_unmounts

Detaching mounts often causes serious problems for users of existing mounts. It is used by autofs in some cases, either at the explicit request of the user (with a command line or init option) and in some special cases during program operation but is avoided whenever possible.

A number of configuration options are not yet implemented:

search_path

Always a little frustrating, the compiled in map location should be used to locate maps but isn't in some cases. This requires work within autofs itself and that will (obviously) include implementing this configuration option for the amd map parser as well.

fully_qualified_hosts

Not yet implemented.

unmount_on_exit

Since autofs always tries to re-connect to mounts left mounted from a previous shutdown this is a sensible option to implement and that will be done.

browsable_dirs

Allow map keys to be shown in directory listings. This option can have values of "yes" or "no". The default is "no". A variation of this option, "browsable", can be used as a pseudo mount option in type "auto" map entries to provide browsing functionality in sub-mounts. The amd "browsable_dirs = full" option cannot be implemented within the current autofs framework and is not supported.

exec_map_timeout

A timeout is not currently used for program maps but this might be implemented in the future.

tag

The tag option is not implemented within autofs.

Supported options:

arch, karch, os, osver

These options default to what is returned from uname(2) and can be overridden if required.

full_os

This option has no default and must be set in the configuration if used in maps.

cluster

If not set defaults to the host domain name. This option corresponds to the HP_UX cluster name (according to the amd source) and is probably not used in Linux but is set anyway.

vendor

This option has a default value of "unknown", it must be set in the configuration if used in maps.

auto_dir

Is the base name of the mount tree used for external mounts that are sometimes needed by amd maps. Its default value is "/a".

map_type

Specifies the autofs map source, such as file, nis, ldap etc. and has no default value set.

map_defaults

This option is used to override /defaults entries within maps and can be used to provide different defaults on specific machines without having to modify centrally managed maps. It is empty by default.

search_path

Colon separated paths to search for maps that are not specified as a full path.

dismount_interval

Is equivalent to the autofs timeout option. It is only possible to use this with type "auto" mounts due to the way the autofs kernel module performs expiry. It takes its default value from the autofs internal default of 600 seconds.

autofs_use_lofs

If set to "yes" autofs will attempt to use bind mounts for type "link" entries when possible (default is "yes").

nis_domain

Allows setting of a domain name other than the system default.

local_domain

Is used to override (or set) the host domain name.

normalize_hostnames

If set to "yes" then the contents of ${rhost} is translated in its official host name.

domain_strip

If set to "yes" the domain name part of the host is stripped when normalizing hostnames. This can be useful when using of the same maps in a multiple domain environment.

normalize_slashes

This option is set to "yes" by default and will collapse multiple unescaped occurrences of "/" to a single "/".

selectors_in_defaults, selectors_on_default

This option has a default value of "no". If set to "yes" then any defaults entry will be checked for selectors to determine the values to be used. selectors_in_defaults is the preferred option to use.

ldap_base

iThis option has no default value. It must be set to the base dn that is used for queries if ldap is to be used as a map source.

ldap_hostports

This option has no default value set. It must be set to the URI of the LDAP server to be used for lookups when ldap is used as a map source. It may contain a comma or space separated list of LDAP URIs.

hesiod_base

Sets the base name used for hesiod map sources.

linux_ufs_mount_type

This is an additional configuration option for the autofs amd format parser implementation. There's no simple way to determine what the system default filesystem is and am-utils needs to be continually updated to do this and can easily get it wrong ayway. So allow it to be set in the configuration.

## EXAMPLE

```
[ autofs ]
timeout = 300
browse_mode = no
[ amd ]
dismount_interval = 300
map_type = nis
autofs_use_lofs = no
[ /expamle/mount ]
dismount_interval = 60
map_type = file
```

## SEE ALSO
automount(8), auto.master(5), autofs_ldap_auth.conf(5).

## AUTHOR
This manual page was written by Ian Kent <raven@themaw.net>.


title: autofs_ldap_auth.conf(5)

text:
# autofs_ldap_auth.conf(5)

## NAME
autofs_ldap_auth.conf - autofs LDAP authentication configuration

## DESCRIPTION
LDAP authenticated binds, TLS encrypted connections and certification may be used by setting appropriate values in the autofs authentication configuration file and configuring the LDAP client with appropriate settings. The default location of this file is /etc/autofs_ldap_auth.conf. If this file exists it will be used to establish whether TLS or authentication should be used.

An example of this file is:

```
<?xml version="1.0" ?>
<autofs_ldap_sasl_conf

        usetls="yes"

        tlsrequired="no"

        authrequired="no"

        authtype="DIGEST-MD5"

        user="xyz"

        secret="abc"
/>
```

If TLS encryption is to be used the location of the Certificate Authority certificate must be set within the LDAP client configuration in order to validate the server certificate. If, in addition, a certified connection is to be used then the client certificate and private key file locations must also be configured within the LDAP client.

## OPTIONS
This files contains a single XML element, as shown in the example above, with several attributes.

The possible attributes are:

usetls="yes"|"no"

Determines whether an encrypted connection to the ldap server should be attempted.

tlsrequired="yes"|"no"

This flag tells whether the ldap connection must be encrypted. If set to "yes", the automounter will fail to start if an encrypted connection cannot be established.

authrequired="yes"|"no"|"autodetect"|"simple"

This option tells whether an authenticated connection to the ldap server is required in order to perform ldap queries. If the flag is set to yes, only sasl authenticated connections will be allowed. If it is set to no then authentication is not needed for ldap server connections. If it is set to autodetect then the ldap server will be queried to establish a suitable sasl authentication mechanism. If no suitable mechanism can be found, connections to the ldap server are made without authentication. Finally, if it is set to simple, then simple authentication will be used instead of SASL.

authtype="GSSAPI"|"LOGIN"|"PLAIN"|"ANONYMOUS"|"DIGEST-MD5"|"SCRAM-SHA-1"|"EXTERNAL"

This attribute can be used to specify a preferred authentication mechanism. In normal operations, the automounter will attempt to authenticate to the ldap server using the list of supportedSASLmechanisms obtained from the directory server. Explicitly setting the authtype will bypass this selection and only try the mechanism specified. The EXTERNAL mechanism may be used to authenticate using a client certificate and requires that authrequired set to "yes" if using SSL or usetls, tlsrequired and authrequired all set to "yes" if using TLS, in addition to authtype being set to EXTERNAL. If using authtype EXTERNAL two additional configuration entries are required:

external_cert="<client certificate path>"

This specifies the path of the file containing the client certificate.

external_key="<client certificate key path>"

This specifies the path of the file containing the client certificate key.

These two configuration entries are mandatory when using the EXTERNAL method as the HOME environment variable cannot be assumed to be set or, if it is, to be set to the location we expect.

user="<username>"

This attribute holds the authentication identity used by authentication mechanisms that require it. Legal values for this attribute include any printable characters that can be used by the selected authentication mechanism.

secret="<password>"

This attribute holds the secret used by authentication mechanisms that require it. Legal values for this attribute include any printable characters that can be used by the selected authentication mechanism.

encoded_secret="<base64 encoded password>"

This attribute holds the base64 encoded secret used by authentication mechanisms that require it. If this entry is present as well as the secret entry this value will take precedence.

clientprinc="<GSSAPI client principal>"

When using GSSAPI authentication, this attribute is consulted to determine the principal name to use when authenticating to the directory server. By default, this will be set to "autofsclient/<fqdn>@<REALM>.

credentialcache="<external credential cache path>"

When using GSSAPI authentication, this attribute can be used to specify an externally configured credential cache that is used during authentication. By default, autofs will setup a memory based credential cache.

## SEE ALSO
auto.master(5), autofs.conf(5).

## AUTHOR
This manual page was written by Ian Kent <raven@themaw.net>.


avahi-daemon.conf

package: avahi-daemon

title: avahi-daemon.conf(5)

summary: avahi-daemon configuration file

text:
# avahi-daemon.conf(5)

## NAME
avahi-daemon.conf - avahi-daemon configuration file

## SYNOPSIS
/etc/avahi/avahi-daemon.conf

## DESCRIPTION
avahi-daemon.conf is the configuration file for avahi-daemon.

## SECTION [SERVER]
host-name= Set the host name avahi-daemon tries to register on the LAN. If omitted defaults to the system host name as set with the sethostname() system call.

host-name-from-machine-id= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will use the machine-id(5) as name on the LAN. It should be noted that this ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments. Defaults to "no".

domain-name= Set the default domain name avahi-daemon tries to register its host name and services on the LAN in. If omitted defaults to ".local".

browse-domains= Set a comma separated list of browsing domains (in addition to the default one and those announced inside the default browsing domain). Please note that the user may specify additional browsing domains on the client side, either by setting $AVAHI_BROWSE_DOMAINS to a list of colon separated domains or by adding them to the XDG config file ~/.config/avahi/browse-domains (separated by newlines).

use-ipv4= Takes a boolean value ("yes" or "no"). If set to "no" avahi-daemon will not use IPv4 sockets. Default is "yes".

use-ipv6= Takes a boolean value ("yes" or "no"). If set to "no" avahi-daemon will not use IPv6 sockets. Default is "yes".

allow-interfaces= Set a comma separated list of allowed network interfaces that should be used by the avahi-daemon. Traffic on other interfaces will be ignored. If set to an empty list all local interfaces except loopback and point-to-point will be used.

deny-interfaces= Set a comma separated list of network interfaces that should be ignored by avahi-daemon. Other not specified interfaces will be used, unless allow-interfaces= is set. This option takes precedence over allow-interfaces=.

check-response-ttl= Takes a boolean value ("yes" or "no"). If set to "yes", an additional security check is activated: incoming IP packets will be ignored unless the IP TTL is 255. Earlier mDNS specifications required this check. Since this feature may be incompatible with newer implementations of mDNS it defaults to "no". On the other hand it provides extra security.

use-iff-running= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon monitors the IFF_RUNNING flag bit which is used by some (modern) network drivers to tell user space if a network cable is plugged in (in case of copper ethernet), or the network card is associated with some kind of network (in case of WLAN). If IFF_RUNNING is set avahi-daemon will automatically announce its services on that network. Unfortunately far too many network drivers do not support this flag or support it in a broken way. Therefore this option defaults to "no".

enable-dbus= Takes either "yes", "no" or "warn". If set to "yes" avahi-daemon connects to D-Bus, offering an object oriented client API. It is only available if Avahi has been compiled with --enable-dbus in which case it defaults to "yes". "warn" behaves like "yes", but the daemon starts up even when it fails to connect to a D-Bus daemon. In addition, if the connection to the D-Bus daemon is terminated we try to reconnect. (Unless we are in a chroot() environment where this definitely will fail.)

disallow-other-stacks= Takes a boolean value ("yes" or "no"). If set to "yes" no other process is allowed to bind to UDP port 5353. This effectively impedes other mDNS stacks from running on the host. Use this as a security measure to make sure that only Avahi is responsible for mDNS traffic. Please note that we do not recommend running multiple mDNS stacks on the same host simultaneously. This hampers reliability and is a waste of resources. However, to not annoy people this option defaults to "no".

allow-point-to-point= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will make use of interfaces with the POINTOPOINT flag set. This option defaults to "no" as it might make mDNS unreliable due to usually large latencies with such links and opens a potential security hole by allowing mDNS access from Internet connections. Use with care and YMMV!

cache-entries-max= Takes an unsigned integer specifying how many resource records are cached per interface. Bigger values allow mDNS work correctly in large LANs but also increase memory consumption.

clients-max= Takes an unsigned integer. The maximum number of concurrent D-Bus clients allowed. If the maximum number is reached further clients will be refused until at least one existing client disconnects.

objects-per-client-max= Takes an unsigned integer. The maximum number of objects (entry groups, browsers, resolvers) that may be registered per D-Bus client at a time. If the maximum number is reached further object creation will be refused until at least one object is freed.

entries-per-entry-group-max= Takes an unsigned integer. The maximum number of entries (resource records) per entry group registered by a D-Bus client at a time. If the maximum number is reached further resource records may not be added to an entry group.

ratelimit-interval-usec= Takes an unsigned integer. Sets the per-interface packet rate-limiting interval parameter. Together with ratelimit-burst= this may be used to control the maximum number of packets Avahi will generated in a specific period of time on an interface.

ratelimit-burst= Takes an unsigned integer. Sets the per-interface packet rate-limiting burst parameter. Together with ratelimit-interval-usec= this may be used to control the maximum number of packets Avahi will generated in a specific period of time on an interface.

## SECTION [WIDE-AREA]
enable-wide-area= Takes a boolean value ("yes" or "no"). Enable wide-area DNS-SD, aka DNS-SD over unicast DNS. If this is enabled only domains ending in .local will be resolved on mDNS, all other domains are resolved via unicast DNS. When this is enabled, unless explicitly specified reverse lookups will go over unicast DNS and fall back to mDNS if unicast DNS lookups fail. If you want to maintain multiple different multicast DNS domains even with this option enabled we encourage you to use subdomains of .local, such as "kitchen.local". This option defaults to "no".

## SECTION [PUBLISH]
disable-publishing= Takes a boolean value ("yes" or "no"). If set to "yes", no record will be published by Avahi, not even address records for the local host. Avahi will be started in a querying-only mode. Use this is a security measure. This option defaults to "no"

disable-user-service-publishing= Takes a boolean value ("yes" or "no"). If set to "yes", Avahi will still publish address records and suchlike but will not allow user applications to publish services. Use this is a security measure. This option defaults to "no"

add-service-cookie= Takes a boolean value ("yes" or "no"). If set to "yes" an implicit TXT entry will be added to all locally registered services, containing a cookie value which is chosen randomly on daemon startup. This can be used to detect if two services on two different interfaces/protocols are actually identical. Defaults to "no".

publish-addresses= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will register mDNS address records for all local IP addresses. Unless you want to use avahi-daemon exclusively for browsing it's recommended to enable this. If you plan to register local services you need to enable this option. Defaults to "yes".

publish-hinfo= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will register an mDNS HINFO record on all interfaces which contains information about the local operating system and CPU, which might be useful for administrative purposes. This is recommended by the mDNS specification but not required. For the sake of privacy you might choose to disable this feature. Defaults to "no".

publish-workstation= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will register a service of type "_workstation._tcp" on the local LAN. This might be useful for administrative purposes (i.e. browse for all PCs on the LAN), but is not required or recommended by any specification. Newer MacOS X releases register a service of this type. Defaults to "no".

publish-domain= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will announce the locally used domain name (see above) for browsing by other hosts. Defaults to "yes".

publish-dns-servers= Takes a comma separated list of IP addresses for unicast DNS servers. You can use this to announce unicast DNS servers via mDNS. When used in conjunction with avahi-dnsconfd on the client side this allows DHCP-like configuration of unicast DNS servers.

publish-resolv-conf-dns-servers= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will publish the unicast DNS servers specified in /etc/resolv.conf in addition to those specified with publish-dns-servers. Send avahi-daemon a SIGHUP to have it reload this file. Defaults to "no".

publish-aaaa-on-ipv4= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will publish an IPv6 AAAA record via IPv4, i.e. the local IPv6 addresses can be resolved using an IPv4 transport. Only useful when IPv4 is enabled with use-ipv4=true. Defaults to "yes".

publish-a-on-ipv6= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will publish an IPv4 A record via IPv6, i.e. the local IPv4 addresses can be resolved using an IPv6 transport. Only useful when IPv6 is enabled with use-ipv6=true. Defaults to "no".

## SECTION [REFLECTOR]
enable-reflector= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will reflect incoming mDNS requests to all local network interfaces, effectively allowing clients to browse mDNS/DNS-SD services on all networks connected to the gateway. The gateway is somewhat intelligent and should work with all kinds of mDNS traffic, though some functionality is lost (specifically the unicast reply bit, which is used rarely anyway). Make sure to not run multiple reflectors between the same networks, this might cause them to play Ping Pong with mDNS packets. Defaults to "no".

reflect-ipv= Takes a boolean value ("yes" or "no"). If set to "yes" and enable-reflector is enabled, avahi-daemon will forward mDNS traffic between IPv4 and IPv6, which is usually not recommended. Defaults to "no".

reflect-filters= Set a comma separated list of allowed service names to be reflected. Each service that is seen must match an entry in this list to be reflected to other networks. This list can match the type of service or the name of the machine providing the service. Defaults to allowing all services.

## SECTION [RLIMITS]
This section is used to define system resource limits for the daemon. See setrlimit(2) for more information. If any of the options is not specified in the configuration file, avahi-daemon does not change it from the system defaults.

rlimit-as= Value in bytes for RLIMIT_AS (maximum size of the process's virtual memory). Sensible values are heavily system dependent.

rlimit-core= Value in bytes for RLIMIT_CORE (maximum core file size). Unless you want to debug avahi-daemon, it is safe to set this to 0.

rlimit-data= Value in bytes for RLIMIT_DATA (maximum size of the process's data segment). Sensible values are heavily system dependent.

rlimit-fsize= Value for RLIMIT_FSIZE (maximum size of files the process may create). Since avahi-daemon shouldn't write any files to disk, it is safe to set this to 0.

rlimit-nofile= Value for RLIMIT_NOFILE (open file descriptors). avahi-daemon shouldn't need more than 15 to 20 open file descriptors concurrently.

rlimit-stack= Value in bytes for RLIMIT_STACK (maximum size of the process stack). Sensible values are heavily system dependent.

rlimit-nproc= Value for RLIMIT_NPROC (max number of processes a user can launch). avahi-daemon forks of a helper process on systems where chroot(2) is available therefore this value should not be set below 2. Note that while the process limit only applies to this process, the total count of processes to reach that limit includes all processes on the system with the same UID, including any containers without UID remapping (such as lxd containers with security.privileged=true). The default configuration of 3 was removed to prevent problems in this scenario.

## AUTHORS
The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/

## SEE ALSO
avahi-daemon(8), avahi-dnsconfd(8)

## COMMENTS
This man page was written using xml2man(1) by Oliver Kurth.


avahi.hosts

title: avahi.hosts(5)

summary: avahi-daemon static host name file

text:
# avahi.hosts(5)

## NAME
avahi.hosts - avahi-daemon static host name file

## SYNOPSIS
/etc/avahi/hosts

## DESCRIPTION
/etc/avahi/hosts is a file which may be used to define static host name to IP address mappings for multicast DNS. This is especially useful when publishing DNS-SD services on behalf of other hosts. See avahi.service(5) for more information.

The file format is similar to the one of /etc/hosts: on each line an IP address and the corresponding host name. The host names should be in FQDN form, i.e. with appended .local suffix.

## AUTHORS
The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/

## SEE ALSO
avahi-daemon(8), avahi.service(5)

## COMMENTS
This man page was written using xml2man(1) by Oliver Kurth.


avahi.service

title: avahi.service(5)

summary: avahi-daemon static service file

text:
# avahi.service(5)

## NAME
avahi.service - avahi-daemon static service file

## SYNOPSIS
/etc/avahi/services/*.service

## DESCRIPTION
/etc/avahi/services/*.service are XML fragments containing static DNS-SD service data. Every service file can contain multiple service definitions which share the same name. This is useful for publishing service data for services which implement multiple protocols. (i.e. a printer implementing _ipp._tcp and _printer._tcp)

## XML TAGS
<service-group> The document tag of avahi service files. Should contain one <name> and one or more <service> elements.

<name replace-wildcards="yes|no"> The service name. If replace-wildcards is "yes", any occurrence of the string "%h" will be replaced by the local host name. This can be used for service names like "Remote Terminal on %h". If replace-wildcards is not specified, defaults to "no".

<service protocol="ipv4|ipv6|any"> Contains the service information for exactly one service type. Should contain one <type> and one <port> element. Optionally it may contain one <domain-name>, one <host-name>, any number of <subtype> and any number of <txt-record> elements. The attribute protocol specifies the protocol to advertise the service on. If any is used (which is the default), the service will be advertised on both IPv4 and IPv6.

<type> Contains the DNS-SD service type for this service. e.g. "_http._tcp".

<subtype> Contains an additional DNS-SD service subtype for this service. e.g. "_anon._sub._ftp._tcp".

<domain-name> The domain name this service should be registered. If omitted defaults to the default domain of the avahi daemon. (probably .local)

<host-name> The host name of the host that provides this service. This should be a host that is resolvable by multicast or unicast DNS. Please note that you need to specify a fully-qualified domain name (FQDN) here, i.e. .local is not appended implicitly! The host name doesn't need to be part of the domain specified in <domain-name>. See avahi.hosts(5) for more information how to publish additional host name mappings.

<port> The IP port number the service listens on.

<txt-record value-format="text|binary-hex|binary-base64"> DNS-SD TXT record data. If value-format is "text", the value of the TXT record is taken verbatim. If value-format is "binary-hex" then the value of TXT record is decoded by taking pairs of characters after the "=" char and interpreting them as the textual representation of the two-digit hexadecimal number. Both uppercase and lowercase hexadecimal digits are allowed. The 0x or 0X prefix is not allowed. This requires the length of the value to be even. If value-format is "binary-base64" then the value of TXT record is decoded with a base64 decoder. The character set used is A-Za-z0-9+/. This requires the length of the value to be a multiple of 4, with "=" as padding at the end. If value-format is not specified, defaults to "text". Examples (all the values are decoded to the string "value" without quotes):

<txt-record>key=value</txt-record>

<txt-record value-format="text">key=value</txt-record>

<txt-record value-format="binary-hex">key=76616c7565</txt-record>

<txt-record value-format="binary-base64">key=dmFsdWU=</txt-record>

## AUTHORS
The Avahi Developers <avahi (at) lists (dot) freedesktop (dot) org>; Avahi is available from http://avahi.org/

## SEE ALSO
avahi-daemon(8), avahi.hosts(5)

## COMMENTS
This man page was written using xml2man(1) by Oliver Kurth.


avr-gdbinit

package: avr-gdb

title: avr-gdbinit(5)

summary: GDB initialization scripts

text:
# avr-gdbinit(5)

## NAME
gdbinit - GDB initialization scripts

## SYNOPSIS
~/.gdbinit

./.gdbinit

## DESCRIPTION
These files contain GDB commands to automatically execute during GDB startup. The lines of contents are canned sequences of commands, described in the GDB manual in node "Sequences" -- shell command "info -f gdb -n Sequences".

Please read more in the GDB manual in node "Startup" -- shell command "info -f gdb -n Startup".

(not enabled with "--with-system-gdbinit" during compilation)

System-wide initialization file. It is executed unless user specified GDB option "-nx" or "-n". See more in the GDB manual in node "System-wide configuration" -- shell command "info -f gdb -n 'System-wide configuration'".

~/.gdbinit

User initialization file. It is executed unless user specified GDB options "-nx", "-n" or "-nh".

./.gdbinit

Initialization file for current directory. It may need to be enabled with GDB security command "set auto-load local-gdbinit". See more in the GDB manual in node "Init File in the Current Directory" -- shell command "info -f gdb -n 'Init File in the Current Directory'".

## SEE ALSO
gdb(1), "info -f gdb -n Startup"

The full documentation for GDB is maintained as a Texinfo manual. If the "info" and "gdb" programs and GDB's Texinfo documentation are properly installed at your site, the command

```
        info gdb
```

should give you access to the complete manual.

Using GDB: A Guide to the GNU Source-Level Debugger, Richard M. Stallman and Roland H. Pesch, July 1991.

## COPYRIGHT
Copyright (c) 1988-2018 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being "Free Software" and "Free Software Needs Free Documentation", with the Front-Cover Texts being "A GNU Manual," and with the Back-Cover Texts as in (a) below.

(a) The FSF's Back-Cover Text is: "You are free to copy and modify this GNU Manual. Buying copies from GNU Press supports the FSF in developing GNU and promoting software freedom."


awesomerc

package: awesome

title: awesomerc(5)

text:
# awesomerc(5)

## NAME
awesomerc - Configuration file for the awesome window manager

## SYNOPSIS
awesome looks for a configuration file in this order:

•$XDG_CONFIG_HOME/awesome/rc.lua

•$HOME/.config/awesome/rc.lua

•$XDG_CONFIG_DIRS/awesome/rc.lua

## DESCRIPTION
The rc.lua file contains configuration information for awesome. It can be used to configure the behavior and look of awesome in a variety of ways. It can be assimilated as a Lua program/script run at startup by awesome. Therefore, it should use the awesome Lua API described in the API section. This file is read at startup.

## AWESOME LUA API
Documentation for the Lua API can be found in the luadoc directory.

## COLORS FORMAT
The color format in awesome is either a standard X color name (blue, darkblue, lightred, etc) or a hexadecimal formatted color (#rrggbb or #rrggbbaa). By using the hexadecimal format, you can also specify an alpha channel: that means that #00ff00 will draw pure green, but #00ff00aa will set the alpha channel to ‘aa’ and will blend the green with the color under it.

## TEXT FORMAT
You can use Pango markup in a text string. This allows formatting the text rendered inside widgets. Pango markup documentation can be found in the Pango documentation at <http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html>.

A Pango markup example: ....

## SEE ALSO
awesome(1) awesome-client(1)

## AUTHORS
Written by Julien Danjou <julien@danjou.info>.

## WWW
<https://awesomewm.org>


title: b4(5)

text:
# b4(5)

## NAME
B4 - Work with code submissions in a public-inbox archive

## SYNOPSIS
b4 {mbox,am,shazam,pr,diff,ty,kr,prep,send,trailers} [options]

## DESCRIPTION
This is a helper utility to work with patches and pull requests made available via a public-inbox archive like lore.kernel.org. It is written to make it easier to participate in a patch-based workflows, like those used in the Linux kernel development.

The name "b4" was chosen for ease of typing and because B-4 was the precursor to Lore and Data in the Star Trek universe.

Full documentation is available on https://b4.docs.kernel.org/.

## SUBCOMMANDS
Maintainer-oriented:

- mbox: Download a thread as an mbox file

- am: Create an mbox file that is ready to git-am

- shazam: Apply patch series to git repositories

- pr: Work with pull requests

- diff: Show range-diff style diffs between patch versions

- ty: Create templated replies for processed patches and pull requests

- kr: (EXPERIMENTAL) Operate on patatt-compatible keyrings

Contributor-oriented:

- prep: (EXPERIMENTAL) prepare your series for submission

- send: (EXPERIMENTAL) send your series for review on distribution lists

- trailers: (EXPERIMENTAL) retrieve and apply code-review trailers

## OPTIONS
-h, --help

show this help message and exit

-d, --debug

Add more debugging info to the output (default: False)

-q, --quiet

Output critical information only (default: False)

-n, --no-interactive

Do not ask any interactive questions (default: False)

--offline-mode

Do not perform any network queries (default: False)

--no-stdin

Disable TTY detection for stdin (default: False)

## SUBCOMMAND OPTIONS

### b4 mbox
This command allows retrieving entire threads from a remote public-inbox instance. The resulting mbox file can then be opened with most MUA clients for actions like replying to conversations or reviewing patch submissions.

usage:

b4 mbox [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [-o OUTDIR] [-c] [-n WANTNAME] [-M] [-f] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

options:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of default (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

-o OUTDIR, --outdir OUTDIR

Output into this directory (or use - to output mailbox contents to stdout)

-c, --check-newer-revisions

Check if newer patch revisions exist

-n WANTNAME, --mbox-name WANTNAME

Filename to name the mbox destination

-M, --save-as-maildir

Save as maildir (avoids mbox format ambiguities)

-f, --filter-dupes

When adding messages to existing maildir, filter out duplicates

Example: b4 mbox 20200313231252.64999-1-keescook@chromium.org

### b4 am
This command allows retrieving threads from a public-inbox instance and preparing them for applying to a git repository using the "git am" command. It will automatically perform the following operations:

- pick the latest submitted version of the series (it can check for newer threads using -c as well)

- check DKIM signatures and patatt attestation on all patches and code review messages

- collate all submitted code-review trailers (Reviewed-by, Acked-by, etc) and put them into the commit message

- add your own Signed-off-by trailer (with -s)

- reroll series from partial updates (e.g. someone submits a v2 of a single patch instead of rerolling the entire series)

- guess where in the tree history the patches belong, if the exact commit-base is not specified (with -g)

- prepare the tree for a 3-way merge (with -3)

- cherry-pick a subset of patches from a large series (with -P)

usage:

b4 am [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [-o OUTDIR] [-c] [-n WANTNAME] [-M] [-v WANTVER] [-t] [-S] [-T] [-s] [-l] [-P CHERRYPICK] [--cc-trailers] [--no-parent] [--allow-unicode-control-chars] [-Q] [-g] [-b GUESSBRANCH [GUESSBRANCH ...]] [--guess-lookback GUESSDAYS] [-3] [--no-cover] [--no-partial-reroll] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

options:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of default (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

-o OUTDIR, --outdir OUTDIR

Output into this directory (or use - to output mailbox contents to stdout)

-c, --check-newer-revisions

Check if newer patch revisions exist

-n WANTNAME, --mbox-name WANTNAME

Filename to name the mbox destination

-M, --save-as-maildir

Save as maildir (avoids mbox format ambiguities)

-v WANTVER, --use-version WANTVER

Get a specific version of the patch/series

-t, --apply-cover-trailers

Apply trailers sent to the cover letter to all patches

-S, --sloppy-trailers

Apply trailers without email address match checking

-T, --no-add-trailers

Do not add or sort any trailers

-s, --add-my-sob

Add your own signed-off-by to every patch

-l, --add-link

Add a Link: with message-id lookup URL to every patch

-P CHERRYPICK, --cherry-pick CHERRYPICK

Cherry-pick a subset of patches (e.g. "-P 1-2,4,6-", "-P _" to use just the msgid specified, or "-P globbing" to match on commit subject)

--cc-trailers

Copy all Cc'd addresses into Cc: trailers

--no-parent

Break thread at the msgid specified and ignore any parent messages

--allow-unicode-control-chars

Allow unicode control characters (very rarely legitimate)

-Q, --quilt-ready

Save patches in a quilt-ready folder

-g, --guess-base

Try to guess the base of the series (if not specified)

-b GUESSBRANCH [GUESSBRANCH ...], --guess-branch GUESSBRANCH [GUESSBRANCH ...]

When guessing base, restrict to this branch (use with -g)

--guess-lookback GUESSDAYS

When guessing base, go back this many days from the patch date (default: 2 weeks)

-3, --prep-3way

Prepare for a 3-way merge (tries to ensure that all index blobs exist by making a fake commit range)

--no-cover

Do not save the cover letter (on by default when using -o -)

--no-partial-reroll

Do not reroll partial series when detected

Example: b4 am 20200313231252.64999-1-keescook@chromium.org

### b4 shazam
This is very similar to b4 am, but will also apply patches directly to the current git tree using git am. Alternatively, when used with -H, it can fetch the patch series into FETCH_HEAD as if it were a pull request, so it can be reviewed and merged. In this case, the cover letter is used as a template for the merge commit.

If you want to automatically invoke git-merge, you can use -M instead of -H.

usage:

b4 shazam [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [-v WANTVER] [-t] [-S] [-T] [-s] [-l] [-P CHERRYPICK] [--cc-trailers] [--no-parent] [--allow-unicode-control-chars] [-H | -M] [--guess-lookback GUESSDAYS] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

options:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of default (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

-v WANTVER, --use-version WANTVER

Get a specific version of the patch/series

-t, --apply-cover-trailers

Apply trailers sent to the cover letter to all patches

-S, --sloppy-trailers

Apply trailers without email address match checking

-T, --no-add-trailers

Do not add or sort any trailers

-s, --add-my-sob

Add your own signed-off-by to every patch

-l, --add-link

Add a Link: with message-id lookup URL to every patch

-P CHERRYPICK, --cherry-pick CHERRYPICK

Cherry-pick a subset of patches (e.g. "-P 1-2,4,6-", "-P _" to use just the msgid specified, or "-P globbing" to match on commit subject)

--cc-trailers

Copy all Cc'd addresses into Cc: trailers

--no-parent

Break thread at the msgid specified and ignore any parent messages

--allow-unicode-control-chars

Allow unicode control characters (very rarely legitimate)

-H, --make-fetch-head

Attempt to treat series as a pull request and fetch it into FETCH_HEAD

-M, --merge

Attempt to merge series as if it were a pull request (execs git-merge)

--guess-lookback GUESSDAYS

(use with -H or -M) When guessing base, go back this many days from the patch date (default: 3 weeks)

Example: b4 shazam -H 20200313231252.64999-1-keescook@chromium.org

### b4 pr
This command is for working with pull requests submitted using git-request-pull.

usage:

command.py pr [-h] [-g GITDIR] [-b BRANCH] [-c] [-e] [-o OUTMBOX] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

optional arguments:

-h, --help

show this help message and exit

-g GITDIR, --gitdir GITDIR

Operate on this git tree instead of current dir

-b BRANCH, --branch BRANCH

Check out FETCH_HEAD into this branch after fetching

-c, --check

Check if pull request has already been applied

-e, --explode

Convert a pull request into an mbox full of patches

-o OUTMBOX, --output-mbox OUTMBOX

Save exploded messages into this mailbox (default: msgid.mbx)

-l, --retrieve-links

Attempt to retrieve any Link: URLs (use with -e)

-f MAILFROM, --from-addr MAILFROM

Use this From: in exploded messages (use with -e)

Example: b4 pr 202003292120.2BDCB41@keescook

### b4 ty
usage:

b4 ty [-h] [-g GITDIR] [-o OUTDIR] [-l] [-t THANK_FOR [THANK_FOR ...]] [-d DISCARD [DISCARD ...]] [-a] [-b BRANCH] [--since SINCE] [-S] [--dry-run]

optional arguments:

-h, --help

show this help message and exit

-g GITDIR, --gitdir GITDIR

Operate on this git tree instead of current dir

-o OUTDIR, --outdir OUTDIR

Write thanks files into this dir (default=.)

-l, --list

List pull requests and patch series you have retrieved

-t THANK_FOR, --thank-for THANK_FOR

Generate thankyous for specific entries from -l (e.g.: 1,3-5,7-; or "all")

-d DISCARD, --discard DISCARD

Discard specific messages from -l (e.g.: 1,3-5,7-; or "all")

-a, --auto

Use the Auto-Thankanator gun to figure out what got applied/merged

-b BRANCH, --branch BRANCH

The branch to check against, instead of current

--since SINCE

The --since option to use when auto-matching patches (default=1.week)

-S, --send-email

Send email instead of writing out .thanks files

--dry-run

Print out emails instead of sending them

--pw-set-state PW_STATE

Set this patchwork state instead of default (use with -a, -t or -d)

NOTE:

To send mails directly using -S, you should have a configured [sendemail] section somewhere in your applicable git configuration files (global or in-tree).

Example: b4 ty -aS --dry-run

### b4 diff
usage:

b4 diff [-h] [-g GITDIR] [-p USEPROJECT] [-C] [-v WANTVERS [WANTVERS ...]] [-n] [-o OUTDIFF] [-c] [-m AMBOX AMBOX] [msgid]

positional arguments:

msgid Message ID to process, pipe a raw message, or use -m

optional arguments:

-h, --help

show this help message and exit

-g GITDIR, --gitdir GITDIR

Operate on this git tree instead of current dir

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of guessing (linux-mm, linux-hardening, etc)

-C, --no-cache

Do not use local cache

-v WANTVERS [WANTVERS ...], --compare-versions WANTVERS [WANTVERS ...]

Compare specific versions instead of latest and one before that, e.g. -v 3 5

-n, --no-diff

Do not generate a diff, just show the command to do it

-o OUTDIFF, --output-diff OUTDIFF

Save diff into this file instead of outputting to stdout

-c, --color

Force color output even when writing to file

-m AMBOX AMBOX, --compare-am-mboxes AMBOX AMBOX

Compare two mbx files prepared with "b4 am"

Example: b4 diff 20200526205322.23465-1-mic@digikod.net

### b4 kr
usage:

b4 kr [-h] [-p USEPROJECT] [-m LOCALMBOX] [-C] [--show-keys] [msgid]

positional arguments:

msgid Message ID to process, or pipe a raw message

optional arguments:

-h, --help

show this help message and exit

-p USEPROJECT, --use-project USEPROJECT

Use a specific project instead of guessing (linux-mm, linux-hardening, etc)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

--show-keys

Show all developer keys from the thread

Example: b4 kr --show-keys 20210521184811.617875-1-konstantin@linuxfoundation.org

### b4 prep
usage:

b4 prep [-h] [-c | -p OUTPUT_DIR | --edit-cover | --show-revision | --force-revision N | --compare-to vN | --manual-reroll COVER_MSGID | --set-prefixes PREFIX [PREFIX ...] | --show-info ] [-n NEW_SERIES_NAME] [-f FORK_POINT] [-F MSGID] [-e ENROLL_BASE]

options:

-h, --help

show this help message and exit

-c, --auto-to-cc

Automatically populate cover letter trailers with To and Cc addresses

-p OUTPUT_DIR, --format-patch OUTPUT_DIR

Output prep-tracked commits as patches

--edit-cover

Edit the cover letter in your defined $EDITOR (or core.editor)

--show-revision

Show current series revision number

--force-revision N

Force revision to be this number instead

--compare-to vN

Display a range-diff to previously sent revision N

--manual-reroll COVER_MSGID

Mark current revision as sent and reroll (requires cover letter msgid)

--set-prefixes PREFIX [PREFIX ...]

Extra prefixes to add to [PATCH] (e.g.: RFC mydrv)

--show-info

Show current series info in a column-parseable format

Create new branch:

Create a new branch for working on patch series

-n NEW_SERIES_NAME, --new NEW_SERIES_NAME

Create a new branch for working on a patch series

-f FORK_POINT, --fork-point FORK_POINT

When creating a new branch, use this fork point instead of HEAD

-F MSGID, --from-thread MSGID

When creating a new branch, use this thread

Enroll existing branch:

Enroll existing branch for prep work

-e ENROLL_BASE, --enroll ENROLL_BASE

Enroll current branch, using the passed tag, branch, or commit as fork base

### b4 send
usage:

b4 send [-h] [-d] [-o OUTPUT_DIR] [--reflect] [--no-trailer-to-cc] [--hide-cover-to-cc] [--to TO [TO ...]] [--cc CC [CC ...]] [--not-me-too] [--resend RESEND] [--no-sign] [--web-auth-new] [--web-auth-verify VERIFY_TOKEN]

options:

-h, --help

show this help message and exit

-d, --dry-run

Do not send, just dump out raw smtp messages to the stdout

-o OUTPUT_DIR, --output-dir OUTPUT_DIR

Do not send, write raw messages to this directory (forces --dry-run)

--reflect

Send everything to yourself instead of the actual recipients

--no-trailer-to-cc

Do not add any addresses found in the cover or patch trailers to To: or Cc:

--hide-cover-to-cc

Hide To: and Cc: entries from the cover letter trailers (but still send to them)

--to TO [TO ...]

Addresses to add to the To: list

--cc CC [CC ...]

Addresses to add to the Cc: list

--not-me-too

Remove yourself from the To: or Cc: list

--resend RESEND

Resend a previously sent version of the series

--no-sign

Do not add the cryptographic attestation signature header

Web submission:

Authenticate with the web submission endpoint

--web-auth-new

Initiate a new web authentication request

--web-auth-verify VERIFY_TOKEN

Submit the token received via verification email

### b4 trailers
usage:

b4 trailers [-h] [-u] [-S] [-F MSGID] [--since SINCE]

options:

-h, --help

show this help message and exit

-u, --update

Update branch commits with latest received trailers

-S, --sloppy-trailers

Apply trailers without email address match checking

-F MSGID, --trailers-from MSGID

Look for trailers in the thread with this msgid instead of using the series change-id

--since SINCE

The --since option to use with -F when auto-matching patches (default=1.month)

-m LOCALMBOX, --use-local-mbox LOCALMBOX

Instead of grabbing a thread from lore, process this mbox file (or - for stdin)

--stdin-pipe-sep STDIN_PIPE_SEP

When accepting messages on stdin, split using this pipe separator string

-C, --no-cache

Do not use local cache

## CONFIGURATION
B4 configuration is handled via git-config(1), so you can store it in either the toplevel $HOME/.gitconfig file, or in a per-repository .git/config file if your workflow changes per project.

To see configuration options available, see online documentation at https://b4.docs.kernel.org/en/latest/config.html

## PROXYING REQUESTS
Commands making remote HTTP requests may be configured to use a proxy by setting the HTTPS_PROXY environment variable, as described in https://docs.python-requests.org/en/latest/user/advanced/#proxies.

## SUPPORT
Please email tools@linux.kernel.org with support requests, or browse the list archive at https://lore.kernel.org/tools.

## AUTHOR
mricon@kernel.org

License: GPLv2+

## COPYRIGHT
The Linux Foundation and contributors


backup.d

package: backupninja

title: backup.d(5)

text:
# backup.d(5)

## NAME
BACKUP.D - Action configuration files for backupninja(1).

## SYNOPSIS
/etc/backup.d/*

## DESCRIPTION
To preform the actual backup actions, backupninja processes each action configuration file in /etc/backup.d according to the file's suffix.

.sh

run this file as a shell script.

.rdiff

backup action for rdiff-backup.

.restic

backup action for restic.

.dup

backup action for duplicity.

.borg

backup action for borgbackup.

.maildir

backup action for slow, incremental rsyncs of tens of thousands of maildirs.

.mysql

backup action for safe MySQL dumps.

.pgsql

backup action for safe PostgreSQL dumps.

.sys

backup action for general system reports and hardware information.

.svn

backup action for safe backups of subversion repositories.

.trac

backup action for safe backups of trac repositories.

.makecd

backup action for burning backups to CD/DVD or creating ISOs.

These files must be owned by root and must not be world or group readable/writable. Support for additional configuration types can be added by dropping bash scripts with the name of the suffix into /usr/share/backupninja.

The configuration files are processed in alphabetical order. However, it is suggested that you name the config files in "sysvinit style."

For example:

10-local.pgsql.disabled

15-runthisfirst.sh

20-runthisnext.mysql

90-runthislast.rdiff

Typically, you will put a '.rdiff' config file last, so that any database dumps you make are included in the filesystem backup. Action configurations which end with .disabled are skipped.

Example templates for the action configuration files can be found in /usr/share/doc/backupninja/examples. You can also use ninjahelper(1), a console based "wizard" for creating backup actions.

## SCHEDULING
By default, each configuration file is processed everyday at 01:00 (1 AM). This can be changed by specifying the 'when' option in a backup action's config file or in the global configuration file. Special value 'manual' will disable scheduling for the backup action. It is possible to run the backup action manually by invoking ninjahelper(1) with --run command line argument.

For example:

when = sundays at 02:00

when = 30th at 22

when = 30 at 22:00

when = everyday at 01

when = Tuesday at 05:00

when = hourly

when = manual

These values for "when" are invalid:

when = everyday at 5:00

when = tuesday at 2am

when = tuesday at 2

when = tues at 02

A configuration file will be processed at the time(s) specified by the "when" option. If multiple "when" options are present, then they all apply. If two configurations files are scheduled to run in the same hour, then we fall back on the alphabetical ordering specified above. The "when" must occur before any sections in the action configuration file.

## FILE FORMAT
The file format of the action configuration files is "ini style." Sections are created by using square bracket. Long lines are connected with a backslash. For example:

\# this is a comment

[fishes]

fish = red

fish = blue

[fruit]

apple = yes

pear = no thanks \

i will not have a pear.

## SEE ALSO
backupninja(1), ninjahelper(1), backupninja.conf(5),

## AUTHOR
BACKUPNINJA was written by the riseup.net collective.