ctdb-script.options

package: samba-ctdb

title: ctdb-script.options(5)

summary: CTDB scripts configuration files

text:
# ctdb-script.options(5)

## NAME
ctdb-script.options - CTDB scripts configuration files

## DESCRIPTION
Each CTDB script has 2 possible locations for its configuration options:

/etc/ctdb/script.options

This is a catch-all global file for general purpose scripts and for options that are used in multiple event scripts.

SCRIPT.options

That is, options for SCRIPT are placed in a file alongside the script, with a ".script" suffix added. This style is usually recommended for event scripts. Options in this script-specific file override those in the global file.

These files should include simple shell-style variable assignments and shell-style comments.

## NETWORK CONFIGURATION

### 10.interface
This event script handles monitoring of interfaces using by public IP addresses.

CTDB_PARTIALLY_ONLINE_INTERFACES=yes|no

Whether one or more offline interfaces should cause a monitor event to fail if there are other interfaces that are up. If this is "yes" and a node has some interfaces that are down then ctdb status will display the node as "PARTIALLYONLINE". Note that CTDB_PARTIALLY_ONLINE_INTERFACES=yes is not generally compatible with NAT gateway or LVS. NAT gateway relies on the interface configured by CTDB_NATGW_PUBLIC_IFACE to be up and LVS replies on CTDB_LVS_PUBLIC_IFACE to be up. CTDB does not check if these options are set in an incompatible way so care is needed to understand the interaction.

Default is "no".

### 11.natgw
Provides CTDB's NAT gateway functionality.

NAT gateway is used to configure fallback routing for nodes when they do not host any public IP addresses. For example, it allows unhealthy nodes to reliably communicate with external infrastructure. One node in a NAT gateway group will be designated as the NAT gateway leader node and other (follower) nodes will be configured with fallback routes via the NAT gateway leader node. For more information, see the NAT GATEWAY section in ctdb(7).

CTDB_NATGW_DEFAULT_GATEWAY=IPADDR

IPADDR is an alternate network gateway to use on the NAT gateway leader node. If set, a fallback default route is added via this network gateway. No default. Setting this variable is optional - if not set that no route is created on the NAT gateway leader node.

CTDB_NATGW_NODES=FILENAME

FILENAME contains the list of nodes that belong to the same NAT gateway group. File format:

```
IPADDR [follower-only]

```

IPADDR is the private IP address of each node in the NAT gateway group.

If "follower-only" is specified then the corresponding node can not be the NAT gateway leader node. In this case CTDB_NATGW_PUBLIC_IFACE and CTDB_NATGW_PUBLIC_IP are optional and unused.

No default, usually /etc/ctdb/natgw_nodes when enabled.

CTDB_NATGW_PRIVATE_NETWORK=IPADDR/MASK

IPADDR/MASK is the private sub-network that is internally routed via the NAT gateway leader node. This is usually the private network that is used for node addresses. No default.

CTDB_NATGW_PUBLIC_IFACE=IFACE

IFACE is the network interface on which the CTDB_NATGW_PUBLIC_IP will be configured. No default.

CTDB_NATGW_PUBLIC_IP=IPADDR/MASK

IPADDR/MASK indicates the IP address that is used for outgoing traffic (originating from CTDB_NATGW_PRIVATE_NETWORK) on the NAT gateway leader node. This must not be a configured public IP address. No default.

CTDB_NATGW_STATIC_ROUTES=IPADDR/MASK[@GATEWAY] ...

Each IPADDR/MASK identifies a network or host to which NATGW should create a fallback route, instead of creating a single default route. This can be used when there is already a default route, via an interface that can not reach required infrastructure, that overrides the NAT gateway default route. If GATEWAY is specified then the corresponding route on the NATGW leader node will be via GATEWAY. Such routes are created even if CTDB_NATGW_DEFAULT_GATEWAY is not specified. If GATEWAY is not specified for some networks then routes are only created on the NATGW leader node for those networks if CTDB_NATGW_DEFAULT_GATEWAY is specified.

This should be used with care to avoid causing traffic to unnecessarily double-hop through the NAT gateway leader, even when a node is hosting public IP addresses. Each specified network or host should probably have a corresponding automatically created link route or static route to avoid this.

No default.

Example

```
CTDB_NATGW_NODES=/etc/ctdb/natgw_nodes
CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
CTDB_NATGW_PUBLIC_IFACE=eth0

```

A variation that ensures that infrastructure (ADS, DNS, ...) directly attached to the public network (10.0.0.0/24) is always reachable would look like this:

```
CTDB_NATGW_NODES=/etc/ctdb/natgw_nodes
CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
CTDB_NATGW_PUBLIC_IFACE=eth0
CTDB_NATGW_STATIC_ROUTES=10.0.0.0/24

```

Note that CTDB_NATGW_DEFAULT_GATEWAY is not specified.

### 13.per_ip_routing
Provides CTDB's policy routing functionality.

A node running CTDB may be a component of a complex network topology. In particular, public addresses may be spread across several different networks (or VLANs) and it may not be possible to route packets from these public addresses via the system's default route. Therefore, CTDB has support for policy routing via the 13.per_ip_routing eventscript. This allows routing to be specified for packets sourced from each public address. The routes are added and removed as CTDB moves public addresses between nodes.

For more information, see the POLICY ROUTING section in ctdb(7).

CTDB_PER_IP_ROUTING_CONF=FILENAME

FILENAME contains elements for constructing the desired routes for each source address. The special FILENAME value __auto_link_local__ indicates that no configuration file is provided and that CTDB should generate reasonable link-local routes for each public IP address.

File format:

```
		IPADDR DEST-IPADDR/MASK [GATEWAY-IPADDR]

```

No default, usually /etc/ctdb/policy_routing when enabled.

CTDB_PER_IP_ROUTING_RULE_PREF=NUM

NUM sets the priority (or preference) for the routing rules that are added by CTDB. This should be (strictly) greater than 0 and (strictly) less than 32766. A priority of 100 is recommended, unless this conflicts with a priority already in use on the system. See ip(8), for more details.

CTDB_PER_IP_ROUTING_TABLE_ID_LOW=LOW-NUM, CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=HIGH-NUM

CTDB determines a unique routing table number to use for the routing related to each public address. LOW-NUM and HIGH-NUM indicate the minimum and maximum routing table numbers that are used. ip(8) uses some reserved routing table numbers below 255. Therefore, CTDB_PER_IP_ROUTING_TABLE_ID_LOW should be (strictly) greater than 255.

CTDB uses the standard file /etc/iproute2/rt_tables to maintain a mapping between the routing table numbers and labels. The label for a public address ADDR will look like ctdb.addr. This means that the associated rules and routes are easy to read (and manipulate).

No default, usually 1000 and 9000.

Example

```
CTDB_PER_IP_ROUTING_CONF=/etc/ctdb/policy_routing
CTDB_PER_IP_ROUTING_RULE_PREF=100
CTDB_PER_IP_ROUTING_TABLE_ID_LOW=1000
CTDB_PER_IP_ROUTING_TABLE_ID_HIGH=9000

```

### 91.lvs
Provides CTDB's LVS functionality.

For a general description see the LVS section in ctdb(7).

CTDB_LVS_NODES=FILENAME

FILENAME contains the list of nodes that belong to the same LVS group. File format:

```
IPADDR [follower-only]

```

IPADDR is the private IP address of each node in the LVS group.

If "follower-only" is specified then the corresponding node can not be the LVS leader node. In this case CTDB_LVS_PUBLIC_IFACE and CTDB_LVS_PUBLIC_IP are optional and unused.

No default, usually /etc/ctdb/lvs_nodes when enabled.

CTDB_LVS_PUBLIC_IFACE=INTERFACE

INTERFACE is the network interface that clients will use to connection to CTDB_LVS_PUBLIC_IP. This is optional for follower-only nodes. No default.

CTDB_LVS_PUBLIC_IP=IPADDR

CTDB_LVS_PUBLIC_IP is the LVS public address. No default.

## SERVICE CONFIGURATION
CTDB can be configured to manage and/or monitor various NAS (and other) services via its eventscripts.

In the simplest case CTDB will manage a service. This means the service will be started and stopped along with CTDB, CTDB will monitor the service and CTDB will do any required reconfiguration of the service when public IP addresses are failed over.

### 20.multipathd
Provides CTDB's Linux multipathd service management.

It can monitor multipath devices to ensure that active paths are available.

CTDB_MONITOR_MPDEVICES=MP-DEVICE-LIST

MP-DEVICE-LIST is a list of multipath devices for CTDB to monitor? No default.

### 31.clamd
This event script provide CTDB's ClamAV anti-virus service management.

This eventscript is not enabled by default. Use ctdb enablescript to enable it.

CTDB_CLAMD_SOCKET=FILENAME

FILENAME is the socket to monitor ClamAV. No default.

### 48.netbios
Provides CTDB's NetBIOS service management.

CTDB_SERVICE_NMB=SERVICE

Distribution specific SERVICE for managing nmbd. Default is distribution-dependant.

### 49.winbind
Provides CTDB's Samba winbind service management.

CTDB_SERVICE_WINBIND=SERVICE

Distribution specific SERVICE for managing winbindd. Default is "winbind".

### 50.samba
Provides the core of CTDB's Samba file service management.

CTDB_SAMBA_CHECK_PORTS=PORT-LIST

When monitoring Samba, check TCP ports in space-separated PORT-LIST. Default is to monitor ports that Samba is configured to listen on.

CTDB_SAMBA_SKIP_SHARE_CHECK=yes|no

As part of monitoring, should CTDB skip the check for the existence of each directory configured as share in Samba. This may be desirable if there is a large number of shares. Default is no.

CTDB_SERVICE_SMB=SERVICE

Distribution specific SERVICE for managing smbd. Default is distribution-dependant.

### 60.nfs
This event script (along with 06.nfs) provides CTDB's NFS service management.

This includes parameters for the kernel NFS server. Alternative NFS subsystems (such as NFS-Ganesha[1]) can be integrated using CTDB_NFS_CALLOUT.

CTDB_NFS_CALLOUT=COMMAND

COMMAND specifies the path to a callout to handle interactions with the configured NFS system, including startup, shutdown, monitoring. Default is the included nfs-linux-kernel-callout.

CTDB_NFS_CHECKS_DIR=DIRECTORY

Specifies the path to a DIRECTORY containing files that describe how to monitor the responsiveness of NFS RPC services. See the README file for this directory for an explanation of the contents of these "check" files. CTDB_NFS_CHECKS_DIR can be used to point to different sets of checks for different NFS servers.

One way of using this is to have it point to, say, /etc/ctdb/nfs-checks-enabled.d and populate it with symbolic links to the desired check files. This avoids duplication and is upgrade-safe.

Default is /etc/ctdb/nfs-checks.d, which contains NFS RPC checks suitable for Linux kernel NFS.

CTDB_NFS_SKIP_SHARE_CHECK=yes|no

As part of monitoring, should CTDB skip the check for the existence of each directory exported via NFS. This may be desirable if there is a large number of exports. Default is no.

CTDB_RPCINFO_LOCALHOST=IPADDR|HOSTNAME

IPADDR or HOSTNAME indicates the address that rpcinfo should connect to when doing rpcinfo check on IPv4 RPC service during monitoring. Optimally this would be "localhost". However, this can add some performance overheads. Default is "127.0.0.1".

CTDB_RPCINFO_LOCALHOST6=IPADDR|HOSTNAME

IPADDR or HOSTNAME indicates the address that rpcinfo should connect to when doing rpcinfo check on IPv6 RPC service during monitoring. Optimally this would be "localhost6" (or similar). However, this can add some performance overheads. Default is "::1".

CTDB_NFS_STATE_FS_TYPE=TYPE

The type of filesystem used for a clustered NFS' shared state. No default.

CTDB_NFS_STATE_MNT=DIR

The directory where a clustered NFS' shared state will be located. No default.

### 70.iscsi
Provides CTDB's Linux iSCSI tgtd service management.

CTDB_START_ISCSI_SCRIPTS=DIRECTORY

DIRECTORY on shared storage containing scripts to start tgtd for each public IP address. No default.

## DATABASE SETUP
CTDB checks the consistency of databases during startup.

### 00.ctdb
CTDB_MAX_CORRUPT_DB_BACKUPS=NUM

NUM is the maximum number of volatile TDB database backups to be kept (for each database) when a corrupt database is found during startup. Volatile TDBs are zeroed during startup so backups are needed to debug any corruption that occurs before a restart. Default is 10.

## SYSTEM RESOURCE MONITORING

### 05.system
Provides CTDB's filesystem and memory usage monitoring.

CTDB can experience seemingly random (performance and other) issues if system resources become too constrained. Options in this section can be enabled to allow certain system resources to be checked. They allows warnings to be logged and nodes to be marked unhealthy when system resource usage reaches the configured thresholds.

Some checks are enabled by default. It is recommended that these checks remain enabled or are augmented by extra checks. There is no supported way of completely disabling the checks.

CTDB_MONITOR_FILESYSTEM_USAGE=FS-LIMIT-LIST

FS-LIMIT-LIST is a space-separated list of FILESYSTEM:WARN_LIMIT[:UNHEALTHY_LIMIT] triples indicating that warnings should be logged if the space used on FILESYSTEM reaches WARN_LIMIT%. If usage reaches UNHEALTHY_LIMIT then the node should be flagged unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be left blank, meaning that check will be omitted. Default is to warn for each filesystem containing a database directory (volatile database directory, persistent database directory, state database directory) with a threshold of 90%.

CTDB_MONITOR_MEMORY_USAGE=MEM-LIMITS

MEM-LIMITS takes the form WARN_LIMIT[:UNHEALTHY_LIMIT] indicating that warnings should be logged if memory usage reaches WARN_LIMIT%. If usage reaches UNHEALTHY_LIMIT then the node should be flagged unhealthy. Either WARN_LIMIT or UNHEALTHY_LIMIT may be left blank, meaning that check will be omitted. Default is 80, so warnings will be logged when memory usage reaches 80%.

## EVENT SCRIPT DEBUGGING

### debug-hung-script.sh
CTDB_DEBUG_HUNG_SCRIPT_STACKPAT=REGEXP

REGEXP specifies interesting processes for which stack traces should be logged when debugging hung eventscripts and those processes are matched in pstree output. REGEXP is an extended regexp so choices are separated by pipes ('|'). However, REGEXP should not contain parentheses. See also the ctdb.conf(5) [event] "debug script" option. Default is "exportfs|rpcinfo".

## FILES
/etc/ctdb/script.options

## SEE ALSO
ctdbd(1), ctdb(7), http://ctdb.samba.org/

## AUTHOR
This documentation was written by Amitay Isaacs, Martin Schwenke

## COPYRIGHT
Copyright © 2007 Andrew Tridgell, Ronnie Sahlberg

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

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

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

## NOTES
1.

NFS-Ganesha

https://github.com/nfs-ganesha/nfs-ganesha/wiki


ctdb.conf

title: ctdb.conf(5)

summary: CTDB configuration file

text:
# ctdb.conf(5)

## NAME
ctdb.conf - CTDB configuration file

## DESCRIPTION
This file contains CTDB configuration options that affect the operation of CTDB daemons and command-line tools. The default location of this file is /etc/ctdb/ctdb.conf.

Note that this is a Samba-style configuration file, so it has a very different syntax to previous CTDB configuration files.

For event script options please see ctdb-script.options(5).

Configuration options are grouped into several sections below. There are only a few options in each section, allowing them to be ordered (approximately) in decreasing order of importance.

## LOGGING CONFIGURATION
Options in this section control CTDB's logging. They are valid within the logging section of file, indicated by [logging].

log level = LOGLEVEL

LOGLEVEL is a string that controls the verbosity of ctdbd's logging. See the LOG LEVELS section in ctdb(7) for more details. Default: NOTICE

location = STRING

STRING specifies where ctdbd will write its log. Valid values are:

file:FILENAME

FILENAME where ctdbd will write its log. This is usually /var/log/log.ctdb.

syslog[:METHOD]

CTDB will log to syslog. By default this will use the syslog(3) API. If METHOD is specified then it specifies an extension that causes logging to be done in a non-blocking fashion. This can be useful under heavy loads that might cause the syslog daemon to dequeue messages too slowly, which would otherwise cause CTDB to block when logging. METHOD must be one of:

nonblocking

CTDB will log to syslog via /dev/log in non-blocking mode.

udp

CTDB will log to syslog via UDP to localhost:514. The syslog daemon must be configured to listen on (at least) localhost:514. Most implementations will log the messages against hostname "localhost" - this is a limit of the implementation for compatibility with more syslog daemon implementations.

udp-rfc5424

As with "udp" but messages are sent in RFC5424 format. This method will log the correct hostname but is not as widely implemented in syslog daemons.

Default: file:/var/log/log.ctdb

## CLUSTER CONFIGURATION
Options in this section affect the CTDB cluster setup. They are valid within the cluster section of file, indicated by [cluster].

cluster lock = LOCK

LOCK specifies the cluster-wide mutex used to detect and prevent a partitioned cluster (or "split brain"). For information about the cluster lock please see the CLUSTER LOCK section in ctdb(7).

Default: NONE. However, uses of a cluster lock is strongly recommended.

leader capability = true|false

Indicates whether a node can become the leader for the cluster. If this is set to false then the node will not be able to become the leader for the cluster. This feature is primarily used for making a cluster span across a WAN link and use CTDB as a WAN-accelerator. Please see the REMOTE CLUSTER NODES section in ctdb(7) for more information.

Default: true

leader timeout = SECONDS

Number of SECONDS without a leader broadcast before a node triggers an election. Default: 5

node address = IPADDR

IPADDR is the private IP address that ctdbd will bind to. This option is only required when automatic address detection can not be used. This can be the case when running multiple ctdbd daemons/nodes on the same physical host (usually for testing), using InfiniBand for the private network or on Linux when sysctl net.ipv4.ip_nonlocal_bind=1.

Default: CTDB selects the first address from the nodes list that it can bind to. See also the PRIVATE ADDRESS section in ctdb(7).

transport = tcp|ib

This option specifies which transport to use for ctdbd internode communications on the private network. ib means InfiniBand. The InfiniBand support is not regularly tested. If it is known to be broken then it may be disabled so that a value of ib is considered invalid.

Default: tcp

## DATABASE CONFIGURATION
Options in this section affect the CTDB database setup. They are valid within the database section of file, indicated by [database].

volatile database directory = DIRECTORY

DIRECTORY on local storage where CTDB keeps a local copy of volatile TDB databases. This directory is local for each node and should not be stored on the shared cluster filesystem. Mounting a tmpfs (or similar memory filesystem) on this directory can provide a significant performance improvement when there is I/O contention on the local disk.

Default: /var/lib/ctdb/volatile

persistent database directory=DIRECTORY

DIRECTORY on local storage where CTDB keeps a local copy of persistent TDB databases. This directory is local for each node and should not be stored on the shared cluster filesystem. Default: /var/lib/ctdb/persistent

state database directory = DIRECTORY

DIRECTORY on local storage where CTDB keeps a local copy of internal state TDB databases. This directory is local for each node and should not be stored on the shared cluster filesystem. Default: /var/lib/ctdb/state

tdb mutexes = true|false

This parameter enables TDB_MUTEX_LOCKING feature on volatile databases if the robust mutexes are supported. This optimizes the record locking using robust mutexes and is much more efficient that using posix locks. If robust mutexes are unreliable on the platform being used then they can be disabled by setting this to false.

lock debug script = FILENAME

FILENAME is a script used by CTDB's database locking code to attempt to provide debugging information when CTDB is unable to lock an entire database or a record. This script should be a bare filename relative to the CTDB configuration directory (/etc/ctdb/). Any directory prefix is ignored and the path is calculated relative to this directory.

CTDB provides a lock debugging script and installs it as /etc/ctdb/debug_locks.sh.

Default: NONE

## EVENT HANDLING CONFIGURATION
Options in this section affect CTDB event handling. They are valid within the event section of file, indicated by [event].

debug script = FILENAME

FILENAME is a script used by CTDB's event handling code to attempt to provide debugging information when an event times out. This script should be a bare filename relative to the CTDB configuration directory (/etc/ctdb/). Any directory prefix is ignored and the path is calculated relative to this directory.

CTDB provides a script for debugging timed out event scripts and installs it as /etc/ctdb/debug-hung-script.sh.

Default: NONE

## FAILOVER CONFIGURATION
Options in this section affect CTDB failover. They are valid within the failover section of file, indicated by [failover].

disabled = true|false

If set to true then public IP failover is disabled. Default: false

## LEGACY CONFIGURATION
Options in this section affect legacy CTDB setup. They are valid within the legacy section of file, indicated by [legacy].

ctdb start as stopped = true|false

If set to true CTDB starts in the STOPPED state. To allow the node to take part in the cluster it must be manually continued with the ctdb continue command.

Please see the NODE STATES section in ctdb(7) for more information about the STOPPED state.

Default: false

start as disabled = true|false

If set to true CTDB starts in the DISABLED state. To allow the node to host public IP addresses and services, it must be manually enabled using the ctdb enable command.

Please see the NODE STATES section in ctdb(7) for more information about the DISABLED state.

Default: false

realtime scheduling = true|false

Usually CTDB runs with real-time priority. This helps it to perform effectively on a busy system, such as when there are thousands of Samba clients. If you are running CTDB on a platform that does not support real-time priority, you can set this to false. Default: true

lmaster capability = true|false

Indicates whether a node can become a location master for records in a database. If this is set to false then the node will not be part of the vnnmap. This feature is primarily used for making a cluster span across a WAN link and use CTDB as a WAN-accelerator. Please see the REMOTE CLUSTER NODES section in ctdb(7) for more information.

Default: true

script log level = LOGLEVEL

This option sets the debug level of event script output to LOGLEVEL. See the DEBUG LEVELS section in ctdb(7) for more information.

Default: ERROR

## FILES
/etc/ctdb/ctdb.conf

## SEE ALSO
ctdbd(1), onnode(1), ctdb.sysconfig(5), ctdb-script.options(5), ctdb(7), ctdb-tunables(7), http://ctdb.samba.org/

## AUTHOR
This documentation was written by Amitay Isaacs, Martin Schwenke

## COPYRIGHT
Copyright © 2007 Andrew Tridgell, Ronnie Sahlberg

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

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

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


ctdb.sysconfig

title: ctdb.sysconfig(5)

summary: CTDB daemon configuration file

text:
# ctdb.sysconfig(5)

## NAME
ctdb.sysconfig - CTDB daemon configuration file

## DESCRIPTION
This file contains configuration that affects the operation of CTDB. This is a distribution-specific service configuration file such as /etc/sysconfig/ctdb (Red Hat) or /etc/default/ctdb (Debian) and is a shell script (see sh(1)).

## GLOBAL CONFIGURATION
CTDB_INIT_STYLE=debian|redhat|suse

This is the init style used by the Linux distribution (or other operating system) being used. This is usually determined dynamically by checking the system. This variable is used by the initscript to determine which init system primitives to use. It is also used by some eventscripts to choose the name of initscripts for certain services, since these can vary between distributions. If using CTDB's event scripts are unable to determine an appropriate default then this option can also be placed in a relevant ctdb-script.options(5) file.

Default: NONE. Guessed, based on features of distribution.

## RESOURCE LIMITS

### Maximum number of open files
CTDB can use a lot of file descriptors, especially when used with Samba. If there are thousands of smbd processes connected to CTDB when this can mean that thousands of file descriptors are used. For CTDB, it is often necessary to increase limit on the maximum number of open files.

The maximum number of open files should be configured using an operating system mechanism.

systemd

The LimitNOFILE=LIMIT option can be used in a unit/service file increase the maximum number of open files. See systemd.exec(5) for details.

SYSV init

Use a command like ulimit -n LIMIT to increase the maximum number of open files. This command can be put in the relevant distribution-specific service configuration file.

### Allowing core dumps
Many distributions do not allow core dump files to be generated by default. To assist with debugging, core files can be enabled. This should be configured using an operating system mechanism.

systemd

The LimitCORE=0|unlimited option can be used in a unit/service file. 0 disallows core files, unlimited allows them. maximum number of open files. See systemd.exec(5) for details.

SYSV init

Use a command like ulimit -c 0|unlimited to disable or enable core files as required. This command can be put in the relevant distribution-specific service configuration file.

## FILES
/etc/sysconfig/ctdb

/etc/default/ctdb

/etc/ctdb/script.options

## SEE ALSO
ctdbd(1), ctdb-script.options(5), ctdb(7), http://ctdb.samba.org/

## AUTHOR
This documentation was written by Martin Schwenke

## COPYRIGHT
Copyright © 2007 Andrew Tridgell, Ronnie Sahlberg

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

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

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


package: samba-winbind-clients

title: pam_winbind.conf(5)

text:
# pam_winbind.conf(5)

## NAME
pam_winbind.conf - Configuration file of PAM module for Winbind

## DESCRIPTION
This configuration file is part of the samba(7) suite.

pam_winbind.conf is the configuration file for the pam_winbind PAM module. See pam_winbind(8) for further details.

## SYNOPSIS
The pam_winbind.conf configuration file is a classic ini-style configuration file. There is only one section (global) where various options are defined.

## OPTIONS
pam_winbind supports several options which can either be set in the PAM configuration files or in the pam_winbind configuration file situated at /etc/security/pam_winbind.conf. Options from the PAM configuration file take precedence to those from the pam_winbind.conf configuration file.

debug = yes|no

Gives debugging output to syslog. Defaults to "no".

debug_state = yes|no

Gives detailed PAM state debugging output to syslog. Defaults to "no".

require_membership_of = [SID or NAME]

If this option is set, pam_winbind will only succeed if the user is a member of the given SID or NAME. A SID can be either a group-SID, an alias-SID or even an user-SID. It is also possible to give a NAME instead of the SID. That name must have the form: MYDOMAIN\mygroup or MYDOMAIN\myuser (where '\' character corresponds to the value of winbind separator parameter). It is also possible to use a UPN in the form user@REALM or group@REALM. pam_winbind will, in that case, lookup the SID internally. Note that NAME may not contain any spaces. It is thus recommended to only use SIDs. You can verify the list of SIDs a user is a member of with wbinfo --user-sids=SID. This setting is empty by default. This option only operates during password authentication, and will not restrict access if a password is not required for any reason (such as SSH key-based login).

try_first_pass = yes|no

By default, pam_winbind tries to get the authentication token from a previous module. If no token is available it asks the user for the old password. With this option, pam_winbind aborts with an error if no authentication token from a previous module is available. If a primary password is not valid, PAM will prompt for a password. Default to "no".

krb5_auth = yes|no

pam_winbind can authenticate using Kerberos when winbindd is talking to an Active Directory domain controller. Kerberos authentication must be enabled with this parameter. When Kerberos authentication can not succeed (e.g. due to clock skew), winbindd will fallback to samlogon authentication over MSRPC. When this parameter is used in conjunction with winbind refresh tickets, winbind will keep your Ticket Granting Ticket (TGT) up-to-date by refreshing it whenever necessary. Defaults to "no".

krb5_ccache_type = [type]

When pam_winbind is configured to try kerberos authentication by enabling the krb5_auth option, it can store the retrieved Ticket Granting Ticket (TGT) in a credential cache. The type of credential cache can be controlled with this option. The supported values are: KCM or KEYRING (when supported by the system's Kerberos library and operating system), FILE and DIR (when the DIR type is supported by the system's Kerberos library). In case of FILE a credential cache in the form of /tmp/krb5cc_UID will be created - in case of DIR you NEED to specify a directory. UID is replaced with the numeric user id. The UID directory is being created. The path up to the directory should already exist. Check the details of the Kerberos implementation. When using the KEYRING type, the supported mechanism is “KEYRING:persistent:UID”, which uses the Linux kernel keyring to store credentials on a per-UID basis. The KEYRING has its limitations. As it is secure kernel memory, for example bulk sorage of credentils is for not possible.

When using th KCM type, the supported mechanism is “KCM:UID”, which uses a Kerberos credential manaager to store credentials on a per-UID basis similar to KEYRING. This is the recommended choice on latest Linux distributions, offering a Kerberos Credential Manager. If not we suggest to use KEYRING as those are the most secure and predictable method.

It is also possible to define custom filepaths and use the "%u" pattern in order to substitute the numeric user id. Examples:

krb5_ccache_type = DIR:/run/user/%u/krb5cc

This will create a credential cache file in the specified directory.

krb5_ccache_type = FILE:/tmp/krb5cc_%u

This will create a credential cache file.

Leave empty to just do kerberos authentication without having a ticket cache after the logon has succeeded. This setting is empty by default.

cached_login = yes|no

Winbind allows one to logon using cached credentials when winbind offline logon is enabled. To use this feature from the PAM module this option must be set. Defaults to "no".

silent = yes|no

Do not emit any messages. Defaults to "no".

mkhomedir = yes|no

Create homedirectory for a user on-the-fly, option is valid in PAM session block. Defaults to "no".

warn_pwd_expire = days

Defines number of days before pam_winbind starts to warn about passwords that are going to expire. Defaults to 14 days.

pwd_change_prompt = yes|no

Generate prompt for changing an expired password. Defaults to "no".

## SEE ALSO
pam_winbind(8), wbinfo(1), winbindd(8), smb.conf(5)

## VERSION
This man page is part of version 4.19.9-alt12 of Samba.

## AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed.

This manpage was written by Jelmer Vernooij and Guenther Deschner.


sane-airscan

package: sane-airscan

title: sane-airscan(5)

text:
# sane-airscan(5)

## NAME
sane-airscan - SANE backend for AirScan (eSCL) and WSD scanners and MFP

## DESCRIPTION
The sane-airscan is the universal backend for "driverless" document scanning. Currently it supports two protocols:

```
1. eSCL, also known as AirScan or AirPrint scan
2. WSD, also known as WS-Scan
```

## CONFIGURATION
The sane-airscan loads its configuration files from the following places:

```
1. /etc/sane.d/airscan.conf
2. /etc/sane.d/airscan.d/*
```

The configuration file syntax is very similar to the .INI file syntax. It consist of sections, each section contains some variables. Comments are started from # or ; characters and continies until end of line

```
# This is a comment
[section 1]
variable 1 = value 1  ; and another comment
variable 2 = value 2
```

Leading and trailing spaces of variable name and value are striped. If you want to preserve them, put name or value into quotes ("like this").

## CONFIGURATION OF DEVICES
If scanner and computer are connected to the same LAN segment, everything expected to "just work" out of box, without any need of manual configuration.

However, in some cases manual configuration can be useful. For example:

```
1. If computer and scanner are connected via IP router
2. There are a lot of devices on a corporate network, but

   only few of them are interesting
3. Automatic discovery works unreliable
```

To manually configure a device, add the following section to the configuration file:

```
[devices]
"Kyocera eSCL" = http://192.168.1.102:9095/eSCL, eSCL
"Kyocera WSD" = http://192.168.1.102:5358/WSDScanner, WSD
"Device I do not want to see" = disable
```

The [devices] section contains all manually configured devices, one line per device, and each line contains a device name on a left side of equation and device URL on a rights side, followed by protocol (eSCL or WSD). If protocol is omitted, eSCL is assumed. You may also disable particular device by using the disable keyword instead of URL.

In addition, you can manually configure a device by directly passing its URL in a device name without adding it to the configuration file. This takes the format protocol:Device Name:URL. The examples above could be written as escl:Kyocera eSCL:http://192.168.1.102:9095/eSCL and wsd:Kyocera WSD:http://192.168.1.102:5358/WSDScanner.

To figure out URLs of available devices, the simplest way is to run the supplied airscan-discover(1) tool on a computer connected with scanner to the same LAN segment. On success, this program will dump to its standard output a list of discovered devices in a format suitable for inclusion into the configuration file.

If running airscan-discover(1) on the same LAN segment as a scanner is not possible, you will have to follow a hard way. Your administrator must know device IP address, consult your device manual for the eSCL port, and the URL path component most likely is the "/eSCL", though on some devices it may differ. Discovering WSD URLs doing this way is much harder, because it is very difficult to guess TCP port and URL path, that in a case of eSCL.

For eSCL devices, the URL can also use the unix:// scheme, such as unix://scanner.sock/eSCL. The "host" from the URL is a file name that will be searched for in the directory specified by socket_dir (see below). When connecting to the scanner, all traffic will be sent to the specified UNIX socket instead of a TCP connection.

## CONFIGURATION OPTIONS
Miscellaneous options all goes to the [options] section. Currently the following options are supported:

```
[options]
; If there are a lot of scanners around and you are only
; interested in few of them, disable auto discovery and
; configure scanners manually.
discovery = enable | disable
; Choose what SANE apps will show in a list of devices:
; scanner network name (the default) or hardware model name.
model = network | hardware
; If device supports both eSCL and WSD protocol, sane-airscan
; may either choose the "best" protocol automatically, or
; expose all variants for user, allowing manual protocol selection.
; The default is "auto".
protocol = auto | manual
; Discovery of WSD devices may be "fast" or "full". The "fast"
; mode works as fast as DNS-SD discovery, but in some cases
; may be unreliable. The "full" mode is slow and reliable.
; It is also possible to disable automatic discovery
; of WSD devices. The default is "fast".
ws-discovery = fast | full | off
; Scanners that use the unix:// schema in their URL can only specify a
; socket name (not a full path).  The name will be searched for in the
; directory specified here. The default is /var/run.
socket_dir = /path/to/directory
```

## BLACKLISTING DEVICES
This feature can be useful, if you are on a very big network and have a lot of devices around you, while interesting only in a few of them.

```
[blacklist]
model = "Xerox*"       ; blacklist by model name
name  = "HP*"          ; blacklist by network name
ip    = 192.168.0.1    ; blacklist by address
ip    = 192.168.0.0/24 ; blacklist the whole subnet
```

Network names come from DNS-SD, WS-Discovery doesn´t provide this information. For filtering by network name to work, Avahi must be enabled and device must be discoverable via DNS-SD (not necessarily as a scanner, it´s enough if WSD scanner is discoverable as a printer via DNS-SD).

Blacklisting only affects automatic discovery, and doesn´t affect manually configured devices.

## DEBUGGING
sane-airscan provides very good instrumentation for troubleshooting without physical access to the problemmatic device.

Debugging facilities can be controlled using the [debug] section of the configuration file:

```
[debug]
; Enable or disable console logging
enable = false | true
; Enable protocol trace and configure output directory
; for trace files. Like in shell, to specify path relative to
; the home directory, start it with tilda character, followed
; by slash, i.e., "~/airscan/trace". The directory will
; be created automatically.
trace = path
; Hex dump all traffic to the trace file (very verbose!)
hexdump = false | true
```

## FILES
/etc/sane.d/airscan.conf, /etc/sane.d/airscan.d/*

The backend configuration files

/usr/LIBDIR/sane/libsane-airscan.so

The shared library implementing this backend

## ENVIRONMENT
SANE_DEBUG_AIRSCAN

This variable if set to true or non-zero numerical value, enables debug messages, that are printed to stdout

SANE_CONFIG_DIR

This variable alters the search path for configuration files. This is a colon-separated list of directories. These directories are searched for the airscan.conf configuration file and for the airscan.d subdirectory, before the standard path (/etc/sane.d) is searched.

## BUGS AND SUPPORT
If you have found a bug, please file a GitHub issue on a GitHub project page: https://github.com/alexpevzner/sane-airscan

## SEE ALSO
sane(7), scanimage(1), xsane(1), airscan-discover(1)

## AUTHOR
Alexander Pevzner <pzz@apevzner.com>


scdoc

package: scdoc

title: scdoc(5)

text:
# scdoc(5)

## NAME
scdoc - document format for writing manual pages

## SYNTAX
Input files must use the UTF-8 encoding.

### PREAMBLE
Each scdoc file must begin with the following preamble:

name(section) ["left_footer" ["center_header"]]

name is the name of the man page you are writing, and section is the section you're writing for (see man(1) for information on manual sections).

left_footer and center_header are optional arguments which set the text positioned at those locations in the generated man page, and must be surrounded with double quotes.

### SECTION HEADERS
Each section of your man page should begin with something similar to the following:

\# HEADER NAME

Subsection headers are also understood - use two hashes. Each header must have an empty line on either side.

### PARAGRAPHS
Begin a new paragraph with an empty line.

### LINE BREAKS
Insert a line break by ending a line with ++.

The result looks

like this.

### FORMATTING
Text can be made bold or underlined with asterisks and underscores: *bold* or _underlined_. Underscores in the_middle_of_words will be disregarded.

### INDENTATION
You may indent lines with tab characters (\t) to indent them by 4 spaces in the output. Indented lines may not contain headers.

The result looks something like this. You may use multiple lines and most formatting.

Deindent to return to normal, or indent again to increase your indentation depth.

### LISTS
You may start bulleted lists with dashes (-), like so:

```
- Item 1
- Item 2
	- Subitem 1
	- Subitem 2
- Item 3
```

The result looks like this:

•Item 1

•Item 2

•Subitem 1

•Subitem 2

•Item 3

You may also extend long entries onto another line by giving it the same indent level, plus two spaces. They will be rendered as a single list entry.

```
- Item 1 is pretty long so let's

  break it up onto two lines
- Item 2 is shorter
	- But its children can go on
	  for a while
```

•Item 1 is pretty long so let's break it up onto two lines

•Item 2 is shorter

•But its children can go on for a while

### NUMBERED LISTS
Numbered lists are similar to normal lists, but begin with periods (.) instead of dashes (-), like so:

```
. Item 1
. Item 2
. Item 3,

  with multiple lines
```

1.Item 1

2.Item 2

3.Item 3, with multiple lines

### TABLES
To begin a table, add an empty line followed by any number of rows.

Each line of a table should start with | or : to start a new row or column respectively (or space to continue the previous cell on multiple lines), followed by [ or - or ] to align the contents to the left, center, or right, followed by a space and the contents of that cell. You may use a space instead of an alignment specifier to inherit the alignment of the same column in the previous row.

The first character of the first row is not limited to | and has special meaning. [ will produce a table with borders around each cell. | will produce a table with no borders. ] will produce a table with one border around the whole table.

To conclude your table, add an empty line after the last row.

```
[[ *Foo*
:- _Bar_
:-
|  *Row 1*
:  Hello
:] world!
|  *Row 2*
:  こんにちは
:  世界

   !
```

Foo

Bar

Row 1

Hello

world!

Row 2

こんにちは

世界 !

You may also cause columns to expand to fill the available space with < (left align), = (center align), and > (right align), like so:

```
[[ *Normal column*
:< Expanded column
|  *Foo*
:  Bar
```

Normal column

Expanded column

Foo

Bar

### LITERAL TEXT
You may turn off scdoc formatting and output literal text with escape codes and literal blocks. Inserting a \ into your source will cause the subsequent symbol to be treated as a literal and copied directly to the output. You may also make blocks of literal syntax like so:

````
```
_This formatting_ will *not* be interpreted by scdoc.
```
````

These blocks will be indented one level. Note that literal text is shown literally in the man viewer - that is, it's not a means for inserting your own roff macros into the output. Note that \ is still interpreted within literal blocks, which for example can be useful to output ``` inside of a literal block.

### COMMENTS
Lines beginning with ; and a space are ignored.

```
; This is a comment
```

## CONVENTIONS
By convention, all scdoc documents should be hard wrapped at 80 columns.

## SEE ALSO
scdoc(1)

## AUTHORS
Maintained by Drew DeVault <sir@cmpwn.com>. Up-to-date sources can be found at https://git.sr.ht/~sircmpwn/scdoc and bugs/patches can be submitted by email to ~sircmpwn/public-inbox@lists.sr.ht.


schroot-script-config

package: schroot

title: schroot-script-config(5)

text:
# schroot-script-config(5)

## NAME
schroot-script-config - schroot chroot setup script configuration

## DESCRIPTION
schroot uses scripts to set up and then clean up the chroot environment. These scripts may be customised using the script-config key in /etc/schroot/schroot.conf. This key specifies a file which the setup scripts will source when they are run. The file is a Bourne shell script, and in consequence may contain any valid shell code, in addition to simple variable assignments. This will, for example, allow behaviour to be customised according to the specific chroot type or name.

This file is deprecated, but is still used if present; it will be obsoleted and removed in a future release. All the settings in this file are now settable using configuration keys in schroot.conf, as detailed below. Existing configuration should be modified to use these keys in place of this file.

## ENVIRONMENT
The environment is the same as for all setup scripts, described in schroot-setup(5).

## VARIABLES
The following variables may be set to configure setup script behaviour. Note that new variables may be added in future releases. Third-party extensions to schroot which add their own setup scripts may add additional variables which are not documented here; consult the extension documentation for further details.

SETUP_COPYFILES

A file containing a list of files to copy into the chroot (one file per line). The file will have the same absolute location inside the chroot. Note that this is settable using the setup.copyfiles key.

SETUP_FSTAB

The filesystem table file to be used to mount filesystems within the chroot. The format of this file is the same as for /etc/fstab, documented in fstab(5). The only difference is that the mountpoint path fs_dir is relative to the chroot, rather than the root. Note that this is settable using the setup.fstab key. Also note that mountpoints are canonicalised on the host, which will ensure that absolute symlinks point inside the chroot, but complex paths containing multiple symlinks may be resolved incorrectly; it is advised to not use nested symlinks as mountpoints.

SETUP_NSSDATABASES

A file listing the system databases to copy into the chroot. The default databases are ‘passwd’, ‘shadow’, ‘group’, ‘services’, ‘protocols’, ‘networks’, and ‘hosts’. ‘gshadow’ is not yet copied by default, due to not being supported by all but the most recent version of the GNU C library. The databases are copied using getent(1) so all database sources listed in /etc/nsswitch.conf will be used for each database. Note that this is settable using the setup.nssdatabases key.

## AUTHORS
Roger Leigh.

## COPYRIGHT
Copyright © 2005-2012 Roger Leigh <rleigh@debian.org>

schroot is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

## SEE ALSO
sbuild(1), schroot(1), sh(1), schroot.conf(5), schroot-setup(5).


schroot-setup

title: schroot-setup(5)

summary: schroot chroot setup scripts

text:
# schroot-setup(5)

## NAME
schroot-setup - schroot chroot setup scripts

## DESCRIPTION
schroot uses scripts to set up and then clean up the chroot environment. The directory /etc/schroot/setup.d contains scripts run when a chroot is created and destroyed. Several environment variables are set while the scripts are being run, which allows their behaviour to be customised, depending upon, for example, the type of chroot in use.

The scripts are run in name order, like those run by init(8), by using the same style of execution as run-parts(8).

The setup scripts are all invoked with two options:

1

The action to perform.

When a session is first started, the chroot is set up by running the scripts in /etc/schroot/setup.d with the ‘setup-start’ option. When the session is ended, the scripts in /etc/schroot/setup.d are run in reverse order with the ‘setup-stop’ option.

2

The chroot status.

This is either ‘ok’ if there are no problems, or ‘fail’ if something went wrong. For example, particular actions may be skipped on failure.

Note that the scripts should be idempotent. They must be idempotent during the ‘setup-stop’ phase, because they may be run more than once, for example on failure.

## ENVIRONMENT

### General variables
AUTH_USER

The username of the user the command in the chroot will run as.

CHROOT_NAME

The chroot name. Note that this is the name of the orignal chroot before session creation; you probably want SESSION_ID.

LIBEXEC_DIR

The directory under which helper programs are located.

MOUNT_DIR

The directory under which non-filesystem chroots are mounted (e.g. block devices and LVM snapshots).

PID

The process ID of the schroot process.

PLATFORM

The operating system platform schroot is running upon. This may be used to introduce platform-specific behaviour into the setup scripts where required. Note that the HOST variables are probably what are required. In the context of schroot, the platform is the supported configuration and behaviour for a given architecture, and may be identical between different architectures.

SESSION_ID

The session identifier.

VERBOSE

Set to ‘quiet’ if only error messages should be printed, ‘normal’ if other messages may be printed as well, and ‘verbose’ if all messages may be printed. Previously called AUTH_VERBOSITY.

CHROOT_SESSION_CREATE

Set to ‘true’ if a session will be created, otherwise ‘false’.

CHROOT_SESSION_CLONE

Set to ‘true’ if a session will be cloned, otherwise ‘false’.

CHROOT_SESSION_PURGE

Set to ‘true’ if a session will be purged, otherwise ‘false’.

CHROOT_SESSION_SOURCE

Set to ‘true’ if a session will be created from a source chroot, otherwise ‘false’.

CHROOT_TYPE

The type of the chroot. This is useful for restricting a setup task to particular types of chroot (e.g. only block devices or LVM snapshots).

CHROOT_NAME

The name of the chroot. This is useful for restricting a setup task to a particular chroot, or set of chroots.

CHROOT_ALIAS

The name of the alias used to select the chroot. This is useful for specialising a setup task based upon one of its alternative alias names, or the default chroot name. For example, it could be used to specify additional sources in /etc/apt/sources.list, such as a stable-security alias for a stable chroot, or an experimental alias for an unstable chroot.

CHROOT_DESCRIPTION

The description of the chroot.

CHROOT_MOUNT_LOCATION

The location to mount the chroot. It is used for mount point creation and mounting.

CHROOT_LOCATION

The location of the chroot inside the mount point. This is to allow multiple chroots on a single filesystem. Set for all mountable chroot types.

CHROOT_PATH

The absolute path to the chroot. This is typically CHROOT_MOUNT_LOCATION and CHROOT_LOCATION concatenated together. This is the path which should be used to access the chroots.

### Plain and directory chroot variables
These chroot types use only general variables.

### File variables
CHROOT_FILE

The file containing the chroot files.

CHROOT_FILE_REPACK

Set to ‘true’ to repack the chroot into an archive file on ending a session, otherwise ‘false’.

### Mountable chroot variables
These variables are only set for directly mountable chroot types.

CHROOT_MOUNT_DEVICE

The device to mount containing the chroot. mounting.

CHROOT_MOUNT_OPTIONS

Options to pass to mount(8).

CHROOT_LOCATION

The location of the chroot inside the mount point. This allows the existence of multiple chroots on a single filesystem.

### Filesystem union variables
CHROOT_UNION_TYPE

Union filesystem type.

CHROOT_UNION_MOUNT_OPTIONS

Union filesystem mount options.

CHROOT_UNION_OVERLAY_DIRECTORY

Union filesystem overlay directory (writable).

CHROOT_UNION_UNDERLAY_DIRECTORY

Union filesystem underlay directory (read-only).

### Block device variables
CHROOT_DEVICE

The device containing the chroot root filesystem. This is usually, but not necessarily, the device which will be mounted. For example, an LVM snapshot this will be the original logical volume.

### LVM snapshot variables
CHROOT_LVM_SNAPSHOT_NAME

Snapshot name to pass to lvcreate(8).

CHROOT_LVM_SNAPSHOT_DEVICE

The name of the LVM snapshot device.

CHROOT_LVM_SNAPSHOT_OPTIONS

Options to pass to lvcreate(8).

### Custom variables
Custom keys set in schroot.conf will be uppercased and set in the environment as described in schroot.conf(5).

## FILES

### Setup script configuration
The directory /etc/schroot/default contains the default settings used by setup scripts.

config

Main configuration file read by setup scripts. The format of this file is described in schroot-script-config(5). This is the default value for the script-config key. Note that this was formerly named /etc/schroot/script-defaults. The following files are referenced by default:

copyfiles

A list of files to copy into the chroot from the host system. Note that this was formerly named /etc/schroot/copyfiles-defaults.

fstab

A file in the format decribed in fstab(5), used to mount filesystems inside the chroot. The mount location is relative to the root of the chroot. Note that this was formerly named /etc/schroot/mount-defaults.

nssdatabases

System databases (as described in /etc/nsswitch.conf on GNU/Linux systems) to copy into the chroot from the host. Note that this was formerly named /etc/schroot/nssdatabases-defaults.

### Setup scripts
The directory /etc/schroot/setup.d contains the chroot setup scripts.

00check

Print debugging diagnostics and perform basic sanity checking.

05file

Unpack, clean up, and repack file-based chroots.

05fsunion

Create and remove union filesystems.

05lvm

Create and remove LVM snapshots.

10mount

Mount and unmount filesystems.

15binfmt

Sets up the QEMU user emulator using binfmt-support. This permits a chroot for a different CPU architecture to be used transparently, providing an alternative to cross-compiling or whole-machine emulation.

15killprocs

Kill processes still running inside the chroot when ending a session, which would prevent unmounting of filesystems and cleanup of any other resources.

20copyfiles

Copy files from the host system into the chroot. Configure networking by copying hosts and resolv.conf, for example.

20nssdatabases

Configure system databases by copying passwd, shadow, group etc. into the chroot.

50chrootname

Set the chroot name (/etc/debian_chroot) in the chroot. This may be used by the shell prompt to display the current chroot.

## AUTHORS
Roger Leigh.

## COPYRIGHT
Copyright © 2005-2012 Roger Leigh <rleigh@debian.org>

schroot is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

## SEE ALSO
schroot(1), fstab(5), schroot.conf(5), schroot-script-config(5), run-parts(8).


schroot.conf

title: schroot.conf(5)

summary: chroot definition file for schroot

text:
# schroot.conf(5)

## NAME
schroot.conf - chroot definition file for schroot

## DESCRIPTION
schroot.conf is a plain UTF-8 text file, describing the chroots available for use with schroot.

Comments are introduced following a ‘#’ (“hash”) character at the beginning of a line, or following any other text. All text right of the ‘#’ is treated as a comment.

The configuration format is an INI-style format, split into groups of key-value pairs separated by section names in square brackets.

### General options
A chroot is defined as a group of key-value pairs, which is started by a name in square brackets on a line by itself. The file may contain multiple groups which therefore define multiple chroots.

A chroot definition is started by the name of the chroot in square brackets. For example,

[sid]

The name is subject to certain naming restrictions. For further details, see the section “Chroot Names” below.

This is then followed by several key-value pairs, one per line:

type=type

The type of the chroot. Valid types are ‘plain’, ‘directory’, ‘file’, ‘loopback’, ‘block-device’, ‘btrfs-snapshot’ and ‘lvm-snapshot’. If empty or omitted, the default type is ‘plain’. Note that ‘plain’ chroots do not run setup scripts and mount filesystems; ‘directory’ is recommended for normal use (see “Plain and directory chroots”, below).

description=description

A short description of the chroot. This may be localised for different languages; see the section “Localisation” below.

priority=number

Set the priority of a chroot. number is a positive integer indicating whether a distribution is older than another. For example, “oldstable” and “oldstable-security” might be ‘0’, while “stable” and “stable-security” are ‘1’, “testing” is ‘2’ and “unstable” is ‘3’. The values are not important, but the difference between them is. This option is deprecated and no longer used by schroot, but is still permitted to be used; it will be obsoleted and removed in a future release.

message-verbosity=verbosity

Set the verbosity of messages printed by schroot when setting up, running commands and cleaning up the chroot. Valid settings are ‘quiet’ (suppress most messages), ‘normal’ (the default) and ‘verbose’ (show all messages). This setting is overridden by the options --quiet and --verbose.

users=user1,user2,...

A comma-separated list of users which are allowed access to the chroot. If empty or omitted, no users will be allowed access (unless a group they belong to is also specified in groups).

groups=group1,group2,...

A comma-separated list of groups which are allowed access to the chroot. If empty or omitted, no groups of users will be allowed access.

root-users=user1,user2,...

A comma-separated list of users which are allowed password-less root access to the chroot. If empty or omitted, no users will be allowed root access without a password (but if a user or a group they belong to is in users or groups, respectively, they may gain access with a password). See the section “Security” below.

root-groups=group1,group2,...

A comma-separated list of groups which are allowed password-less root access to the chroot. If empty or omitted, no users will be allowed root access without a password (but if a user or a group they belong to is in users or groups, respectively, they may gain access with a password). See the section “Security” below.

aliases=alias1,alias2,...

A comma-separated list of aliases (alternate names) for this chroot. For example, a chroot named “sid” might have an ‘unstable’ alias for convenience. Aliases are subject to the same naming restrictions as the chroot name itself.

profile=directory

script-config=filename

The behaviour of the chroot setup scripts may be customised on a per-chroot basis by setting a specific configuration profile. The directory is relative to /etc/schroot. The default is ‘default’. The files in this directory are sourced by the setup scripts, and so their behaviour may be customised by selecting the appropriate profile. Alternatives are ‘minimal’ (minimal configuration), ‘desktop’ (for running desktop applications in the chroot, making more functionality from the host system available in the chroot) and ‘sbuild’ (for using the chroot for Debian package building). Other packages may provide additional profiles. The default values of the keys setup.config, setup.copyfiles, setup.fstab and setup.nssdatabases are set based upon the profile setting.

Note that the profile key replaces the older script-config key. The script-config key is exactly the same as profile, but has “/config” appended to it. The default filename is ‘default/config’. Either of these keys may be used. If both are present, then script-config will take precedence (profile will be unset). script-config is deprecated and will be removed in a future release. Note that profile is equivalent to script-config if the file sourced by script-config only contains the standard variables provided by schroot; if any additional variables or shell script fragments have been added, please also set setup.config, which will continue to allow this file to be sourced. It is recommended to replace the use of the sourced file with additional keys in schroot.conf where possible, but it will continue to be possible to source an additional configuration file using setup.config.

Desktop users should note that the fstab file desktop/fstab will need editing if you use gdm3; please see the comments in this file for further instructions. The preserve-environment key should also be set to ‘true’ so that the environment is preserved inside the chroot.

If none of the configuration profiles provided above meet your needs, then they may be edited to further customise them, and/or copied and used as a template for entirely new profiles.

Note that the different profiles have different security implications; see the section “Security” below for further details.

setup.config=filename

This key specifies a file which the setup scripts will source when they are run. This defaults to the same value as set by script-config. The file is a Bourne shell script, and in consequence may contain any valid shell code, in addition to simple variable assignments. This will, for example, allow behaviour to be customised according to the specific chroot type or name. Note that the script will be sourced once for each and every script invocation, and must be idempotent.

All the default settings in this file are now settable using configuration keys in schroot.conf, as detailed below. Existing configuration should be modified to use these keys in place of this file. See schroot-script-config(5) for further details. This type of setup script configuration file is no longer provided as part of the standard profiles, but will continue to be sourced if present and this key is set.

setup.copyfiles=filename

A file containing a list of files to copy into the chroot (one file per line). The file will have the same absolute location inside the chroot.

setup.fstab=filename

The filesystem table file to be used to mount filesystems within the chroot. The format of this file is the same as for /etc/fstab, documented in fstab(5). The only difference is that the mountpoint path fs_dir is relative to the chroot, rather than the root. Also note that mountpoints are canonicalised on the host, which will ensure that absolute symlinks point inside the chroot, but complex paths containing multiple symlinks may be resolved incorrectly; it is inadvisable to use nested symlinks as mountpoints.

setup.nssdatabases=filename

A file listing the system databases to copy into the chroot. The default databases are ‘passwd’, ‘shadow’, ‘group’ and ‘gshadow’. Other potential databases which could be added include ‘services’, ‘protocols’, ‘networks’, and ‘hosts’. The databases are copied using getent(1) so all database sources listed in /etc/nsswitch.conf will be used for each database.

setup.services=service1,service2,...

A comma-separated list of services to run in the chroot. These will be started when the session is started, and stopped when the session is ended.

command-prefix=command,option1,option2,...

A comma-separated list of a command and the options for the command. This command and its options will be prefixed to all commands run inside the chroot. This is useful for adding commands such as nice, ionice or eatmydata for all commands run inside the chroot. nice and ionice will affect CPU and I/O scheduling. eatmydata ingores filesystem fsync operations, and is useful for throwaway snapshot chroots where you don't care about dataloss, but do care about high speed.

personality=persona

Set the personality (process execution domain) to use. This option is useful when using a 32-bit chroot on 64-bit system, for example. Valid options on Linux are ‘bsd’, ‘hpux’, ‘irix32’, ‘irix64’, ‘irixn32’, ‘iscr4’, ‘linux’, ‘linux32’, ‘linux_32bit’, ‘osf4’, ‘osr5’, ‘riscos’, ‘scorvr3’, ‘solaris’, ‘sunos’, ‘svr4’, ‘uw7’, ‘wysev386’, and ‘xenix’. The default value is ‘linux’. There is also the special option ‘undefined’ (personality not set). For a 32-bit chroot on a 64-bit system, ‘linux32’ is the option required. The only valid option for non-Linux systems is ‘undefined’. The default value for non-Linux systems is ‘undefined’.

preserve-environment=true|false

By default, the environment will not be preserved inside the chroot, instead a minimal environment will be used. Set to true to always preserve the environment. This is useful for example when running X applications inside the chroot, which need the environment to function correctly. The environment may also be preserved using the --preserve-environment option.

shell=shell

When running a login shell a number of potential shells will be considered, in this order: the command in the SHELL environment variable (if --preserve-environment is used, or preserve-environment is enabled), the user's shell in the ‘passwd’ database, /bin/bash and finally /bin/sh. This setting overrides this list, and will use the shell specified. It may be overridden using the --shell option.

environment-filter=regex

The environment to be set in the chroot will be filtered in order to remove environment variables which may pose a security risk. Any environment variable matching the specified POSIX extended regular expression will be removed prior to executing any command in the chroot.

Potentially dangerous environment variables are removed for safety by default using the following regular expression: “^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$”.

### Plain and directory chroots
Chroots of type ‘plain’ or ‘directory’ are directories accessible in the filesystem. The two types are equivalent except for the fact that directory chroots run setup scripts, whereas plain chroots do not. In consequence, filesystems such as /proc are not mounted in plain chroots; it is the responsibility of the system administrator to configure such chroots by hand, whereas directory chroots are automatically configured. Additionally, directory chroots implement the filesystem union chroot options (see “Filesystem Union chroot options”, below).

These chroot types have an additional (mandatory) configuration option:

directory=directory

The directory containing the chroot environment. This is where the root will be changed to when executing a login shell or a command. The directory must exist and have read and execute permissions to allow users access to it. Note that on Linux systems it will be bind-mounted elsewhere for use as a chroot; the directory for ‘plain’ chroots is mounted with the --rbind option to mount(8), while for ‘directory’ chroots --bind is used instead so that sub-mounts are not preserved (they should be set in the fstab file just like in /etc/fstab on the host).

### File chroots
Chroots of type ‘file’ are files on the current filesystem containing an archive of the chroot files. They implement the source chroot options (see “Source chroot options”, below). Note that a corresponding source chroot (of type ‘file’) will be created for each chroot of this type; this is for convenient access to the source archive, e.g. for the purpose of updating. These additional options are also implemented:

file=filename

The file containing the archived chroot environment (mandatory). This must be a tar (tape archive), optionally compressed with gzip, bzip2, xz, lzop or lz4. The file extensions used to determine the type are are .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.lzop, .tar.lz4, .tgz, .tbz, .txz, .tzo and .tlz4. This file must be owned by the root user, and not be writable by other. Note that zip archives are no longer supported; zip was not able to archive named pipes and device nodes, so was not suitable for archiving chroots.

location=path

This is the path to the chroot inside the archive. For example, if the archive contains a chroot in /squeeze, you would specify “/squeeze” here. If the chroot is the only thing in the archive, i.e. / is the root filesystem for the chroot, this option should be left blank, or omitted entirely.

### Loopback chroots
Chroots of type ‘loopback’ are a filesystem available as a file on disk, accessed via a loopback mount. The file will be loopback mounted and unmounted on demand. Loopback chroots implement the mountable chroot and filesystem union chroot options (see “Mountable chroot options” and “Filesystem Union chroot options”, below), plus an additional option:

file=filename

This is the filename of the file containing the filesystem, including the absolute path. For example “/srv/chroot/sid”.

### Block device chroots
Chroots of type ‘block-device’ are a filesystem available on an unmounted block device. The device will be mounted and unmounted on demand. Block device chroots implement the mountable chroot and filesystem union chroot options (see “Mountable chroot options” and “Filesystem Union chroot options”, below), plus an additional option:

device=device

This is the device name of the block device, including the absolute path. For example, “/dev/sda5”.

### Btrfs snapshot chroots
Chroots of type ‘btrfs-snapshot’ are a Btrfs snapshot created from an existing Btrfs subvolume on a mounted Btrfs filesystem. A snapshot will be created from this source subvolume on demand at the start of a session, and then the snapshot will be mounted. At the end of the session, the snapshot will be unmounted and deleted. This chroot type implements the source chroot options (see “Source chroot options”, below). Note that a corresponding source chroot (of type ‘directory’) will be created for each chroot of this type; this is for convenient access to the source volume. These additional options are also implemented:

btrfs-source-subvolume=directory

The directory containing the source subvolume.

btrfs-snapshot-directory=directory

The directory in which to store the snapshots of the above source subvolume.

### LVM snapshot chroots
Chroots of type ‘lvm-snapshot’ are a filesystem available on an LVM logical volume (LV). A snapshot LV will be created from this LV on demand, and then the snapshot will be mounted. At the end of the session, the snapshot LV will be unmounted and removed.

LVM snapshot chroots implement the source chroot options (see “Source chroot options”, below), and all the options for ‘block-device’. Note that a corresponding source chroot (of type ‘block-device’) will be created for each chroot of this type; this is for convenient access to the source device. This additional option is also implemented:

lvm-snapshot-options=snapshot_options

Snapshot options. These are additional options to pass to lvcreate(8). For example, “-L 2g” to create a snapshot 2 GiB in size. Note: the LV name (-n), the snapshot option (-s) and the original LV path may not be specfied here; they are set automatically by schroot.

### Custom chroots
Chroots of type ‘custom’ are a special type of chroot, used for implementing new types of chroot not supported by any of the above chroot types. This may be useful for implementing and testing a new chroot type without needing to write any C++ code. However, you will need to write your own setup script to do the setup work, since by itself this chroot type does very little. You will also need to add custom keys to your chroot definition for use in the setup script; unlike the configuration for the above chroot types, no validation of the options will take place unless you do it yourself in your custom setup script. These additional options are also implemented:

custom-session-cloneable=true|false

Set whether or not sessions may be cloned using this chroot (enabled by default).

custom-session-purgeable=true|false

Set whether or not sessions may be cloned using this chroot (disabled by default).

custom-source-cloneable=true|false

Set whether or not source chroots may be cloned using this chroot (disabled by default).

### Source chroot options
The ‘btrfs-snapshot’, ‘file’ and ‘lvm-snapshot’ chroot types implement source chroots. Additionally, chroot types with union support enabled implement source chroots (see “Filesystem Union chroot options”, below). These are chroots which automatically create a copy of themselves before use, and are usually session managed. These chroots additionally provide an extra chroot in the source: namespace, to allow convenient access to the original (non-snapshotted) data, and to aid in chroot maintenance. I.e. for a chroot named wheezy (chroot:wheezy), a corresponding source:wheezy chroot will be created. For compatibility with older versions of schroot which did not support namespaces, a chroot with a -source suffix appended to the chroot name will be created in addition (i.e. wheezy-source using the above example). Note that these compatibility names will be removed in schroot 1.5.0, so the use of the source: namespace is preferred over the use of the -source suffix form. See schroot(1) for further details.

These chroots provide the following additional options:

source-clone=true|false

Set whether the source chroot should be automatically cloned (created) for this chroot. The default is true to automatically clone, but if desired may be disabled by setting to false. If disabled, the source chroot will be inaccessible.

source-users=user1,user2,...

A comma-separated list of users which are allowed access to the source chroot. If empty or omitted, no users will be allowed access. This will become the users option in the source chroot.

source-groups=group1,group2,...

A comma-separated list of groups which are allowed access to the source chroot. If empty or omitted, no users will be allowed access. This will become the groups option in the source chroot.

source-root-users=user1,user2,...

A comma-separated list of users which are allowed password-less root access to the source chroot. If empty or omitted, no users will be allowed root access without a password (but if a user is in users, they may gain access with a password). This will become the root-users option in the source chroot. See the section “Security” below.

source-root-groups=group1,group2,...

A comma-separated list of groups which are allowed password-less root access to the source chroot. If empty or omitted, no users will be allowed root access without a password (but if a user's group is in groups, they may gain access with a password). This will become the root-groups option in the source chroot. See the section “Security” below.

### Mountable chroot options
The ‘block-device’, ‘loopback’ and ‘lvm-snapshot’ chroot types implement device mounting. These are chroots which require the mounting of a device in order to access the chroot. These chroots provide the following additional options:

mount-options=options

Mount options for the block device. These are additional options to pass to mount(8). For example, “-o atime,sync,user_xattr”.

location=path

This is the path to the chroot inside the filesystem on the device. For example, if the filesystem contains a chroot in /chroot/sid, you would specify “/chroot/sid” here. If the chroot is the only thing on the filesystem, i.e. / is the root filesystem for the chroot, this option should be left blank, or omitted entirely.

### Filesystem Union chroot options
The ‘block-device’, ‘directory’ and ‘loopback’ chroot types allow for the creation of a session using filesystem unions to overlay the original filesystem with a separate writable directory. The original filesystem is read-only, with any modifications made to the filesystem made in the overlying writable directory, leaving the original filesystem unchanged. A union permits multiple sessions to access and make changes to a single chroot simultaneously, while keeping the changes private to each session. To enable this feature, set union-type to any supported value. If enabled, the chroot will also be a source chroot, which will provide additional options (see “Source chroot options”, above). All entries are optional.

union-type=type

Set the union filesystem type. Currently supported filesystems are ‘aufs’, ‘overlayfs’, ‘overlay’ (as of Linux 4.0+) and ‘unionfs’. The default is ‘none’, which disables this feature.

union-mount-options=options

Union filesystem mount options (branch configuration), used for mounting the union filesystem specified with union-type. This replaces the complete “-o” string for mount and allows for the creation of complex filesystem unions. Note that ‘aufs’, ‘overlayfs’ and ‘unionfs’ each have different supported mount options. Note: One can use the variables “${CHROOT_UNION_OVERLAY_DIRECTORY}” and “${CHROOT_UNION_UNDERLAY_DIRECTORY}” to refer to the writable overlay session directory and read-only underlying directory which are to form the union. See schroot-setup(5) for a complete variable list.

union-overlay-directory=directory

Specify the directory where the writeable overlay session directories will be created. The default is ‘/var/lib/schroot/union/overlay’.

union-underlay-directory=directory

Specify the directory where the read-only underlying directories will be created. The default is ‘/var/lib/schroot/union/underlay’.

### Customisation
In addition to the configuration keys listed above, it is possible to add custom keys. These keys will be used to add additional environment variables to the setup script environment when setup scripts are run. The only restriction is that the key name consists only of alphanumeric characters and hyphens, begins with an alphabet character and contains at least one period. That is to say, that it matches the extended regular expression “^([a-z][a-z0-9]*\.)+[a-z][a-z0-9-]*$”.

For example:

```
debian.apt-update=true
debian.distribution=unstable
```

would set the following environment:

```
DEBIAN_APT_UPDATE=true
DEBIAN_DISTRIBUTION=unstable
```

Note that it is an error to use different key names which would set the same environment variable by mixing periods and hyphens.

Custom configuration keys may also be modified at runtime using the --option option. However, for security, only selected keys may be modified. These keys are specified using the following options:

user-modifiable-keys=key1,key2,..

Set the keys which users may modify using --option.

root-modifiable-keys=key1,key2,.. Set the keys which the

root user may modify using --option. Note that the root user may use the keys specified in user-modifiable-keys in addition to those specified here.

### Localisation
Some keys may be localised in multiple languages. This is achieved by adding the locale name in square brackets after the key name. For example:

```
description[en_GB]=British English translation
```

This will localise the description key for the en_GB locale.

```
description[fr]=French translation
```

This will localise the description key for all French locales.

## CHROOT NAMES
A number of characters or words are not permitted in a chroot name, session name or configuration filename. The name may not contain a leading period (‘.’). The characters ‘:’ (colon), ‘,’ (comma) and ‘/’ (forward slash) are not permitted anywhere in the name. The name may also not contain a trailing tilde (‘~’). The rationale for these restrictions is given below.

‘.’

A leading period could be used to create a name with a relative path in it, in combination with ‘/’, and this could allow overwriting of files on the host filesystem. Not allowing this character also means hidden files cannot be created. It also means some editor backups are automatically ignored. Periods are allowed anywhere else in the name.

‘:’

A colon is used as a namespace delimiter, and so is not permitted as part of a chroot or session name. LVM snapshot names may also not contain this character due to a naming restriction by lvcreate(8).

‘/’

Names containing this character are not valid filenames. A forward slash would potentially allow creation of files in subdirectories.

‘,’

Commas are used to separate items in lists. Aliases are separated by commas and hence can't contain commas in their name.

‘~’

Filenames containing trailing tildes are used for editor backup files, which are ignored. Tildes are allowed anywhere else in the name.

‘dpkg-old’

‘dpkg-dist’

‘dpkg-new’

‘dpkg-tmp’

These names may not appear at the end of a name. These are saved copies of conffiles used by the dpkg package manager, and will be ignored.

## SECURITY

### Untrusted users
Note that giving untrusted users root access to chroots is a serious security risk! Although the untrusted user will only have root access to files inside the chroot, in practice there are many obvious ways of breaking out of the chroot and of disrupting services on the host system. As always, this boils down to trust.

Do not give chroot root access to users you would not trust with root access to the host system.

### Profiles
Depending upon which profile you have configured with the script-config option, different filesystems will be mounted inside the chroot, and different files will be copied into the chroot from the host. Some profiles will mount the host's /dev, while others will not. Some profiles also bind mount additional parts of the host filesystem in order to allow use of certain features, including user's home directories and specific parts of /var. Check the profile's fstab file to be certain of what will be mounted, and the other profile files to see which files and system databases will be copied into the chroot. Choose a different profile or edit the files to further restrict what is made available inside the chroot.

There is a tradeoff between security (keeping the chroot as minimal as possible) and usability (which sometimes requires access to parts of the host filesystem). The different profiles make different tradeoffs, and it is important that you assess which meets the security/usability tradeoff you require.

## EXAMPLE

```
# Sample configuration
[sid]
type=plain
description=Debian unstable
description[fr_FR]=Debian instable
directory=/srv/chroot/sid
priority=3
users=jim
groups=sbuild
root-users=rleigh
aliases=unstable,default
[etch]
type=block-device
description=Debian testing (32-bit)
priority=2
groups=users
#groups=sbuild-security
aliases=testing
device=/dev/hda_vg/etch_chroot
mount-options=-o atime
personality=linux32
[sid-file]
type=file
description=Debian sid file-based chroot
priority=3
groups=sbuild
file=/srv/chroots/sid.tar.gz
[sid-snapshot]
type=lvm-snapshot
description=Debian unstable LVM snapshot
priority=3
groups=sbuild
users=rleigh
source-root-users=rleigh
source-root-groups=admin
device=/dev/hda_vg/sid_chroot
mount-options=-o atime,sync,user_xattr
lvm-snapshot-options=--size 2G
```

## FILES

### Chroot definitions
/etc/schroot/schroot.conf

The system-wide chroot definition file. This file must be owned by the root user, and not be writable by other.

/etc/schroot/chroot.d

Additional chroot definitions may be placed in files under this directory. They are treated in exactly that same manner as /etc/schroot/schroot.conf. Each file may contain one or more chroot definitions.

### Setup script configuration
The directory /etc/schroot/default contains the default settings used by setup scripts.

config

Main configuration file read by setup scripts. The format of this file is described in schroot-script-config(5). This is the default value for the script-config key. Note that this was formerly named /etc/schroot/script-defaults. The following files are referenced by default:

copyfiles

A list of files to copy into the chroot from the host system. Note that this was formerly named /etc/schroot/copyfiles-defaults.

fstab

A file in the format decribed in fstab(5), used to mount filesystems inside the chroot. The mount location is relative to the root of the chroot. Note that this was formerly named /etc/schroot/mount-defaults.

nssdatabases

System databases (as described in /etc/nsswitch.conf on GNU/Linux systems) to copy into the chroot from the host. Note that this was formerly named /etc/schroot/nssdatabases-defaults.

## AUTHORS
Roger Leigh.

## COPYRIGHT
Copyright © 2005-2012 Roger Leigh <rleigh@debian.org>

schroot is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

## SEE ALSO
sbuild(1), schroot(1), schroot-script-config(5), schroot-faq(7), mount(8).


targets.conf

package: scsitarget-utils

title: targets.conf(5)

summary: Linux SCSI Target Configuration File

text:
# targets.conf(5)

## NAME
targets.conf - Linux SCSI Target Configuration File

## DESCRIPTION
tgt-admin uses /etc/tgt/targets.conf to initialize tgtd configuration, by default. Its layout uses a HTML-like structure, with a hierarchy of nested tags to define targets and LUNs.

## CONFIGURATION FILE SYNTAX
Global directives configure options that are global to tgtd's configuration, as well as defining exported targets, via target sections.

Target sections contain directives specific to one target device. They define each target's exported LUNs via "backing-store" and "direct-store" directives, as well as other target-wide options.

LUN directives ("backing-store" and "direct-store") may contain options specific to a single exported logical unit.

## GLOBAL DIRECTIVES
With the exception of target directives, each of these should occur at most once.

<target <IQN>>

Defines a the start of a target definition. IQN is an ISCSI Qualified Name such as "iqn.2001-04.com.example:storage1". Within this block should be target-level directives, as documented below.

The target definition ends with "</target>"

default-driver <lld>

Instead of specifying a driver type for each target, default-driver defines a default low-level driver for all exported targets. It may be overriden on a per-target basis. Valid lld values are "iscsi" or "iser". Since iscsi is assumed if this directive is not present, it is only generally needed if iser is the desired default.

include <path>

Include the configuration from another configuration file. Wildcards are allowed, so an example like "include /etc/tgt/xen/*.conf" is allowed.

ignore-errors yes

Errors from tgtadm will be ignored. Default is no.

control-port <port>

Define a different local socket key for communicating with tgtd. Defaults to 0. This is only generally useful if multiple instances of tgtd are in use.

iSNSServerIP <addr>

Define the address of the iSNS server in IPv4 dotted-quad address format. Required when using iSNS, otherwise ignored.

iSNSAccessControl <value>

Set iSNS access control. Valid values are "On" or "Off". Required when using iSNS, otherwise ignored.

iSNSServerPort <port>

Set a different iSNS server port. Default is 3205. Optional when using iSNS, otherwise ignored.

iSNS On

Enable iSNS. Only valid value is "On". Default is off.

incomingdiscoveryuser <user> <userpassword>

Define iscsi incoming discovery authentication setting. If no value is given, no authentication is performed.

outgoingdiscoveryuser <user> <userpassword>

Define iscsi outgoing discovery authentication setting. If no value is given, no authentication is performed.

## TARGET-LEVEL DIRECTIVES
Each target may export multiple block devices, or logical units (LUNs). For the purposes of LUN numbering, backing-store directives are processed before direct-store directives.

backing-store <path>

Defines a logical unit (LUN) exported by the target. This may specify either a regular file, or a block device.

direct-store <path>

Defines a direct mapped logical unit (LUN) with the same properties as the physical device (such as VENDOR_ID, SERIAL_NUM, etc.)

driver <lld>

Define the low-level driver to use for this target, either "iscsi" or "iser" (without quotes). This overrides the "default-driver" global directive.

initiator-address <addr>

Allows connections only from the specified IP address. Defaults to ALL if no initiator-address directive is specified.

initiator-name <addr>

Allows connections only from the specified initiator name.

incominguser <user> <userpassword>

Define iscsi incoming authentication setting. If no "incominguser" is specified, it is not used. This directive may be used multiple times per target.

outgoinguser <user> <userpassword>

Define iscsi outgoing authentication setting. If no "outgoinguser" is specified, it is not used. This directive may be used multiple times per target.

controller_tid <val>

Define the tid of the controller. Default is next available integer.

## LUN-LEVEL DIRECTIVES
All of these may be listed at the target level (and apply to all LUNs) or within an individual LUN's definition, if it is defined using the container-style, multi-line definition, rather than single-line definition format:

```
<backing-store /dev/sdb1>

  # LUN directives go here
</backing-store>
<direct-store /dev/sdb1>

  # LUN directives go here
</direct-store>

```

It is recommended to use either single-line or container-style LUN definitions within a target. Mixing styles can cause parser errors.

write-cache <val>

"on" or "off", default on.

scsi_id <val>

scsi_sn <val>

vendor_id <val>

product_id <val>

product_rev <val>

sense_format <val>

removable <val>

path <val>

mode_page <val>

readonly <val>

device-type <val>

bs-type <val>

allow-in-use <val>

block-size <val>

Specify the block size for this LUN.

lbppbe <val>

Specify the Logical blocks per physical block exponent. By default TGTD will set the lbppbe to automatically match the underlying filesystem. Use this parameter to override that setting. This is an internal option that should not be set directly.

la_lba <val>

Specify the lowest aligned logical block address. This is an internal option that should not be set directly.

optimal_xfer_gran <val>

Specify the optimal transfer granularity, to be reflected in the Block Limits VPD. This is an internal option that should not be set directly.

optimal_xfer_len <val>

Specify the optimal transfer length, to be reflected in the Block Limits VPD. This is an internal option that should not be set directly.

params <vals>

Pass additional parameters to tgtadm.

## CONFIGURATION FILE EXAMPLE

```
Example configuration file:
<target iqn.2007-04.com.example:san.monitoring>

  backing-store /dev/san/monitoring

  # if no "incominguser" is specified, it is not used

  incominguser backup secretpass12

  # defaults to ALL if no "initiator-address" is specified

  initiator-address 192.168.1.2
</target>
<target iqn.2007-02.com.example:san.xen1>

  backing-store /dev/san/xen1-disk1 # LUN1

  direct-store /dev/san/xen1-disk2  # LUN2

  initiator-address 192.168.1.2     # Allowed IP

  initiator-address 192.168.5.6     # Allowed IP

  incominguser user1 secretpass12

  incominguser user2 secretpass23

  outgoinguser userA secretpassA
</target>
<target iqn.2007-02.com.example:san.xen2>

  backing-store /dev/san/xen2
</target>
<target iqn.2007-06.com.example:san.vmware1>

  backing-store /dev/san/vmware1
</target>

```

## FILES
/etc/tgt/targets.conf

Configuration file for tgt-admin.

/usr/share/doc/tgt/targets.conf.example

Example configuration file for tgt-admin.

## SEE ALSO
tgtd(8), tgtadm(8), tgtimg(8), tgt-setup-lun(8). http://stgt.sourceforge.net/

## REPORTING BUGS
Report bugs to <stgt@vger.kernel.org>


sddm-state.conf

package: sddm

title: sddm-state.conf(5)

summary: sddm display manager configuration

text:
# sddm-state.conf(5)

## NAME
state.conf - sddm display manager configuration

## SYNOPSIS
~sddm/state.conf

## DESCRIPTION
This file carries state configuration for the sddm display manager sddm(1).

## OPTIONS
All options are configured in the [Last] section:

Session=

Name of the session file of the last session selected. This session will be preselected when the login screen shows up. Default value is empty.

User=

Name of last logged-in user. This username will be preselected/shown when the login screen shows up. Default value is empty.

## SEE ALSO
sddm(1)

The full documentation for sddm is available at https://github.com/sddm/sddm


sddm.conf

title: sddm.conf(5)

summary: sddm display manager configuration

text:
# sddm.conf(5)

## NAME
sddm.conf - sddm display manager configuration

## SYNOPSIS
Configuration loads all files in the configuration directories followed by the configuration file in the order listed below with the latter having highest precedence. Changes should be made to the local configurations.

/usr/share/sddm/conf.d

System configuration directory

/etc/sddm.conf.d

Local configuration directory

/etc/X11/sddm/sddm.conf

Local configuration file for compatibility

## DESCRIPTION
This file configures various parameters of the sddm display manager sddm(1). If this file is not available, default values are used.

## OPTIONS
[General] section:

HaltCommand=

Halt command. Default value is "/sbin/systemctl poweroff".

RebootCommand=

Reboot command. Default value is "/sbin/systemctl reboot".

Numlock=

Change numlock state when sddm-greeter starts. Valid values are on, off or none. If property is set to none, numlock won't be changed. Default value is "none".

InputMethod=

Set the Qt input method for the greeter. Tablet users with Qt Virtual Keyboard installed can set this to "qtvirtualkeyboard" for the on-screen keyboard. Other known values are "ibus" for the Intelligent Input Bus, or "compose" for dead keys support. Leave this empty if unsure.

Namespaces=

Comma-separated list of paths bound to Linux namespaces to enter with setns() before starting the user session. For example, to enter network namespace mynet created with ip netns add mynet, the value might be /run/netns/mynet. Default value is empty. (The value is ignored if the operating system is not Linux.)

[Theme] section:

ThemeDir=

Path of the directory containing theme files. Default value is "/usr/share/sddm/themes".

Current=

Name of the current theme. By default this setting is empty, meaning the embedded theme will be used.

FacesDir=

Path of the directory containing face files, face files should be in username.face.icon format. Default value is "/usr/share/sddm/faces".

CursorTheme=

Name of the cursor theme to be set before starting the display server.

Font=

Name of the font to be set before starting the display server. Please note that the theme can still override this option.

EnableAvatars=

When enabled, home directories are searched for ".face.icon" images to display as their avatars. This can be slow on some file systems. When disabled, all avatars will be default. Themes may choose to hide them altogether. Default value is true.

[X11] section:

ServerPath=

Path of the X server. Default value is "/usr/bin/X".

ServerArguments=

Arguments to the X server. Default value is "-nolisten tcp".

XephyrPath=

Path of the Xephyr. Default value is "/usr/bin/Xephyr".

XauthPath=

Path of the Xauth. Default value is "/usr/bin/xauth".

SessionDir=

Path of the directory containing session files. Default value is "/usr/share/xsessions".

SessionCommand=

Path of script to execute when starting the user session. This script receives the value of the "Exec" setting in the ".desktop" file of the selected session and runs it. Default value is "/etc/X11/Xsession".

SessionLogFile=

Path to the user session log file, relative to the home directory. Default value is ".local/share/sddm/xorg-session.log".

UserAuthFile=

Path to the Xauthority file, relative to the home directory. Default value is ".Xauthority".

DisplayCommand=

Path of script to execute when starting the display server. Default value is "/usr/share/sddm/scripts/Xsetup".

DisplayStopCommand=

Path of script to execute when stopping the display server. Default value is "/usr/share/sddm/scripts/Xstop".

MinimumVT=

Minimum virtual terminal number that will be used by the first display. Virtual terminal number will increase as new displays added. Default value is 1.

EnableHiDPI=

Enables Qt's automatic HiDPI scaling. Can be either "true" or "false". Default value is "false".

[Wayland] section:

SessionDir=

Path of the directory containing session files. Default value is "/usr/share/wayland-sessions".

SessionCommand=

Path of script to execute when starting the user session. This script receives the value of the "Exec" setting in the ".desktop" file of the selected session and run it. Default value is "/usr/share/sddm/scripts/wayland-session".

SessionLogFile=

Path to the user session log file, relative to the home directory. Default value is ".local/share/sddm/wayland-session.log".

EnableHiDPI=

Enables Qt's automatic HiDPI scaling. Can be either "true" or "false". Default value is "false".

[Users] section:

DefaultPath=

Default path to set after successfully logging in. This is also where SDDM looks for programs. Default value is "/usr/local/bin:/usr/bin:/bin".

MinimumUid=

Minimum user id of the users to be listed in the user interface. Default value is 500.

MaximumUid=

Maximum user id of the users to be listed in the user interface. Default value is 32000

HideUsers=

Comma-separated list of Users that shouldn't show up in the user list. Default value is empty.

HideShells=

Comma-separated list of Shells of users that shouldn't show up in the user list. Default value is empty.

RememberLastUser=

If this flag is true, LastUser value will updated on every successful login, if false last user value won't be updated. Default value is true.

RememberLastSession=

If this flag is true, LastSession value will updated on every successful login, if false last session value won't be updated. Default value is true.

[Autologin] section:

User=

Name of the user to automatically log in when the system starts first time. Default value is empty.

Session=

Name of the session to automatically log in when the system starts first time. Default value is empty.

Relogin=

If true and User and Session are set automatic login will kick in again on session exit, otherwise it will work only the first time. Default value is false.

## SEE ALSO
sddm(1)

The full documentation for sddm is available at https://github.com/sddm/sddm