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

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

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

### Monitoring Thresholds
Event scripts can monitor resources or services. When a problem is detected, it may be better to warn about a problem rather than to immediately fail monitoring and mark a node as unhealthy. CTDB provides support for event scripts to do threshold-based monitoring.

A threshold setting looks like WARNING_THRESHOLD[:ERROR_THRESHOLD]. If the number of problems is ≥ WARNING_THRESHOLD then the script will log a warning and continue. If the number problems is ≥ ERROR_THRESHOLD then the script will log an error and exit with failure, causing monitoring to fail. Note that ERROR_THRESHOLD is optional, and follows the optional colon (:) separator.

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

### 40.vsftpd
Provides CTDB's vsftpd service management.

CTDB_VSFTPD_MONITOR_THRESHOLDS=THRESHOLDS

THRESHOLDS indicates how many consecutive monitoring attempts need to report that vsftpd is not listening on TCP port 21 before a warning is logged and before monitoring fails. See the Monitoring Thresholds for a description of how monitoring thresholds work. Default is 1:2.

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

CTDB_SAMBA_INTERFACES_FILE=FILENAME

Generates FILENAME, containing an smb.conf snippet with an interfaces setting that includes interfaces for configured CTDB public IP addresses. This file then needs to be explicitly included in smb.conf. For example, if public IP addresses are defined on interfaces eth0 and eth1, and this is set to /etc/samba/interfaces.conf, then that file will contain the following before smbd is started:

```
     bind interfaces only = yes

     interfaces = lo eth0 eth1

```

This can be useful for limiting the interfaces used by SMB multichannel.

Default is to not generate a file.

CTDB_SAMBA_INTERFACES_EXTRA=INTERFACE-LIST

A space separated list to provide additional interfaces to bind. Default is empty - no extra interfaces are added.

### 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 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_EXPORTS_FILE=FILE

Set FILE as the path of the file containing NFS exports, for use by the NFS callout (see CTDB_NFS_CALLOUT, above). This is used for share checks when CTDB_NFS_SKIP_SHARE_CHECK is not set to "yes". This is most useful with NFS-Ganesha, since it supports configuration include files and exports may be stored in a separate file. Default is /var/lib/nfs/etab for nfs-linux-kernel-callout, /etc/ganesha/ganesha.conf for nfs-ganesha-callout.

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

shutdown extra timeout = TIMEOUT

CTDB will wait for TIMEOUT seconds after failover completes during shutdown. This can provide extra time for SMB durable handles to be reclaimed. If set to 0 then no extra timeout occurs. This timeout only occurs if both of the following conditions are true:

•shutdown failover timeout (below) is not 0

•Failover during shutdown completes and does not time out

Default: 0

shutdown failover timeout = TIMEOUT

CTDB will wait for TIMEOUT seconds for failover to complete during shutdown. This allows NFS servers on other nodes to go into grace during graceful shutdown of a node. Failover during shutdown also helps with SMB durable handle reclaim. Set this to 0 to disable explicit failover on shutdown.

Default: 10

## 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 storage of credentials is not possible.

When using the KCM type, the supported mechanism is “KCM:UID”, which uses a Kerberos credential manager 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 that is 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.21.9-alt3.p11.1 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.

By default, sane-airscan treats all scanners as remote devices. This can be undesirable, if configuring a proxy that translates from eSCL/WSD to the SANE protocol, as saned(8) ignores any device that isn't attached locally. By setting pretend-local = true, sane-airscan can make its devices accessible to the SANE network daemon.

## 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
; Configure whether eSCL and WSD devices should be treated as
; if they were attached locally. The default behavior considers
; them as remote devices that are accessed over the network.
; This option has to be changed when exporting a scanner through
; saned. The default is "false"
pretend-local = false | true
```

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

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.

SANE_AIRSCAN_DEVICE

This variable, if set, overrides all devices, manually configured in the log files and disables auto discovery.

It consists of three parameters, delimited by the colons (:):

"PROTO:DEVICE NAME:URL"

Where:

- PROTO is either escl or wsd.

- DEVICE NAME will appear in the list of devices.

- URL is the device URL, using http: or https: schemes.

Examples:

"escl:Kyocera eSCL:http://192.168.1.102:9095/eSCL" (eSCL)

"wsd:Kyocera WSD:http://192.168.1.102:5358/WSDScanner" (WSD)

The primary purpose of this variable is the automated testing of the sane-airscan backend.

## 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), saned (8), scanimage(1), xsane(1), airscan-discover(1)

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


sbctl.conf

package: sbctl

title: sbctl.conf(5)

summary: the sbctl configuration file

text:
# sbctl.conf(5)

## NAME
sbctl.conf - the sbctl configuration file

## SYNOPSIS
/etc/sbctl/sbctl.conf

## DESCRIPTION
The sbctl configuration file is a YAML file. It is read on startup if present.

The file can be used for initial setup of a sbctl installation.

## CONFIGURATION DIRECTORIES AND PRECEDENCE
The configuration file is currently only read from /etc/sbctl. This might change in the future.

## OPTIONS
keydir: /path/to/key/dir

Defines the directory where sbctl will look for keys. Default: /var/lib/sbctl/keys

guid: /path/to/guid/file

The location of the file that defines the user created GUID. The GUID is used to unique identify the list of certificates stored in the EFI variables.

Default: /var/lib/sbctl/GUID

files_db: /path/to/files/json

The location of the json file storing the files sbctl will sign. Default: /var/lib/sbctl/files.json

bundles_db: /path/to/bundles/json

The location of the json file storing the bundles sbctl will sign. Default: /var/lib/sbctl/bundles.json

landlock: bool

Enable or disable the landlock sandboxing of sbctl. Default: true

db_additions: [ options... ] Include additional keys or checksums into the authorization database for Secure Boot. These values are synonymous with the flags passed to sbctl enroll-keys. Valid values: microsoft, tpm-eventlog, firmware-builtin, custom

files: [ [path: /path/to/file output: /path/to/output ], ... ]

A list of files sbctl will sign upon setup. It will be used to seed the files_db during initial setup. path

Absolute path to a file that sbctl should sign.

output

An optional absolute output path for the signed file.

keys: {pk: {...}, kek: {...}, db: {...}}

A key-value pair for all the keys in the key hierarchy used for Secure Boot. It is used for the initial bootstrap during setup.

•pk

•kek

•db

Each of the hierarchies can specify key type and location for the private key and certificate file independent of each other. This allows users to keep some keys on different storage mediums depending on needs. An example would be to keep the db key as an unencrypted file easily accessible for signing and the PK on a hardware backed enclave to be better secure the key material. privkey: /path/to/privatekey/file

Path to the private key. Defaults:

•pk: /var/lib/sbctl/keys/PK/PK.key

•kek: /var/lib/sbctl/keys/KEK/KEK.key

•db: /var/lib/sbctl/keys/db/db.key

pubkey: /path/to/certificate/file

Path to the public key. Default:

•pk: /var/lib/sbctl/keys/PK/PK.pem

•kek: /var/lib/sbctl/keys/KEK/KEK.pem

•db: /var/lib/sbctl/keys/db/db.pem

type: file

The type of key used for this signing key. Only the key type of file is currently supported by sbctl.

Default: file

## EXAMPLE
An example of a /etc/sbctl/sbctl.conf file with the default values.

```
---
keydir: /var/lib/sbctl/keys
guid: /var/lib/sbctl/GUID
files_db: /var/lib/sbctl/files.json
bundles_db: /var/lib/sbctl/bundles.json
landlock: true
db_additions:
- microsoft
files:
- path: /boot/vmlinuz-linux

  output: /boot/vmlinuz-linux
- path: /efi/EFI/Linux/arch-linux.efi

  output: /efi/EFI/Linux/arch-linux.efi
keys:

  pk:

    privkey: /var/lib/sbctl/keys/PK/PK.key

    pubkey: /var/lib/sbctl/keys/PK/PK.pem

    type: file

  kek:

    privkey: /var/lib/sbctl/keys/KEK/KEK.key

    pubkey: /var/lib/sbctl/keys/KEK/KEK.pem

    type: file

  db:

    privkey: /var/lib/sbctl/keys/db/db.key

    pubkey: /var/lib/sbctl/keys/db/db.pem

    type: file
```

## SEE ALSO
sbctl(8)

## AUTHORS
•Morten Linderud <morten@linderud.pw>


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. Each row must have the same number of columns; empty columns are permitted.

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.


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). https://github.com/fujita/tgt

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

DisplayServer=

Select the display server to use for the greeter. Valid values are:

- x11: X server running as root.

- x11-user: X server running as unprivileged user.

- wayland: Wayland compositor as unprivileged user. (Experimental)

Default value is "x11". For x11-user you might need to configure Xorg.wrap(1).

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.

CursorSize=

Cursor size 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".

SessionDir=

Comma-separated list of directories containing session files. Default value is "/usr/local/share/xsessions,/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".

DisplayCommand=

Path of script to execute when starting the display server. The script will be executed as root when General.DisplayServer is "x11", otherwise as sddm user. Default value is "/usr/share/sddm/scripts/Xsetup".

DisplayStopCommand=

Path of script to execute when stopping the display server. The script will be executed as root when General.DisplayServer is "x11", otherwise as sddm user. 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. This setting is no longer available since SDDM v0.20.

EnableHiDPI=

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

The XauthPath= option is no longer necessary, libxau is used instead.

The UserAuthFile= option was removed, the file is always created as /tmp/xauth_XXXXX. This is necessary for to the use of FamilyWild entries.

[Wayland] section:

CompositorCommand=

Path of the compositor to execute when starting the greeter. Default value is "weston --shell=kiosk".

SessionDir=

Comma-separated list of directories containing session files. Default value is "/usr/local/share/wayland-sessions,/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 "true".

[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


sopwith-mission

title: sopwith-mission(5)

text:
# sopwith-mission(5)

## NAME

.sop - Sopwith mission format

## DESCRIPTION
The Sopwith mission format allows sopwith(6) to load custom user-defined levels and other modifications to the game. The files use Yocton as their basic format:

https://github.com/fragglet/yocton

Each .sop file can contain three different sections:

level

This section contains level data. If present, the game's level is replaced with an entirely new level defined within this section. See LEVEL SECTION below.

symbols

This section allows the game's symbols (sprites) to be replaced. This allows graphical modifications to the game. See SYMBOLS SECTION below.

sounds

This section allows the game's music to be replaced. See SOUNDS SECTION below.

## LEVEL SECTION
The level section allows a complete new level to be defined. At present only a single level can be defined, although this may change in the future. Each level contains two types of subsection: ground, which defines the level's terrain, and multiple object sections, each of which defines an in-game object.

The ground subsection is a list of decimal integer values that describe the level's terrain. Each value is defined through a Yocton property named _. Values should be in the range 16-199, and there should be a minimum of 320 (ie. one screen's worth). The following is an example:

```
  ground {

    _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

    ...

  }
```

Each object subsection defines an object that appears in the level. The following is an example:

```
  object {

    type: PLANE

    x: 30

    orient: 0

    territory_l: 0

    territory_r: 0

    faction: PLAYER1

  }
```

As seen, each object has a number of different properties:

type

See OBJECT TYPES below.

x

The X coordinate within the level where the object appears. The Y coordinate is set automatically depending on the object type and can not be specified.

orient

For planes, defines the direction in which planes face: 0 (right) or 1 (left). For ground targets, this controls the type of ground target; see TARGET TYPES below.

faction

Specifies the faction to which the object belongs. See FACTIONS below.

transform

For ground targets, this specifies a "transformation" to apply to the symbol. Eight different transformations are supported: 0 (no transformation); 1 (rotate 90 degrees counterclockwise); 2 (rotate upside-down); 3 (rotate 90 degrees clockwise); 4 (flip vertically); 5 (mirror, then rotate 90 degrees counterclockwise); 6 (mirror); 7 (mirror and then rotate 90 degrees clockwise). If you want to see an Ox do a headstand, this is the property to use, although it's more likely you'll want to use it to make tanks face the right direction.

territory_l

For planes, the left boundary of the range of the level the plane defends.

territory_r

For planes, the right boundary of the range of the level the plane defends.

The following is an example of a minimal level section that just contains a flat ground with no objects other than the player's plane:

```
  level {

    object {

      type: PLANE

      x: 30

      orient: 0

      territory_l: 0

      territory_r: 0

      faction: PLAYER1

    }

    ground {

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

      _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64 _: 64

    }

  }
```

## OBJECT TYPES
The following object types can appear in a level:

PLANE

Defines either a player or computer-controlled plane. The faction property controls whether it is a human player or computer-controlled player; see FACTIONS below. Computer-controlled planes will defend their "territory", the range of which is defined by the territory_l and territory_r properties. If the player enters this territory, they will take off from their base and attack.

TARGET

A ground target. The value of the orient property defines the type of target, see TARGET TYPES below. The value of the faction property specifies the faction to which the target belongs. When one player destroys all targets owned by all enemy factions, the game advances to the next level.

BALLOON

Observation balloon. The value of the orient property defines the type of balloon; 0 = spherical balloon, 1 = Caquot-style. The value of the faction property specifies the faction to which the balloon belongs.

OX

An Ox (type of cattle). The Ox does nothing except act as an obstacle, and does not need to be killed to advance to the next level. Does not appear in novice mode.

BIRD

A single bird flies the randomly around the level. The bird acts as an obstacle that the player(s) must avoid. Does not appear in novice mode.

FLOCK

A flock of birds moves along the top of the screen. The flock acts an obstacle and may disperse into many different birds if disturbed. Does not appear in novice mode.

## FACTIONS
Military objects belong to a "faction"; objects allied to a different faction are considered enemies. The color of the object indicates the faction:

PLAYER1

For planes, cyan fuselage and magenta wings. This corresponds to the human player in single player mode, and player 1 in multiplayer mode.

PLAYER2

For planes, magenta fuselage and cyan wings. This corresponds to the computer opponent in single player mode, and player 2 in multiplayer mode.

NONE

Used for animals / non-military targets.

The following values are also recognized; they are currently (effectively) unused, but may be used in the future if the multiplayer feature is extended to support more than two players.

PLAYER3

Maps to PLAYER2 in single player mode, or PLAYER1 in multiplayer mode. Planes of this faction are currently ignored in multiplayer mode.

PLAYER4

Maps to PLAYER2. Planes of this faction are currently ignored in multiplayer mode.

PLAYER5, PLAYER7

Maps to PLAYER1, but planes with this faction are currently ignored.

PLAYER6, PLAYER8

Maps to PLAYER2, but planes with this faction are currently ignored.

## SYMBOLS SECTION
The symbols section allows the game's graphics to be replaced. The section can contain a number of subsections, one for each type of graphic. Graphics are defined as multiline text strings. The following is an example of a symbols section that changes the hangar graphic to add an extra (white) flag:

```
  symbols {

    swtrgsym {

      0:

      "    -                 -         \n" &

      "    - # # # #         - * * * * \n" &

      "    - # # # #         - * * * * \n" &

      "    -                 -         \n" &

      "    -                 -         \n" &

      "    -                 -         \n" &

      "    -                 -         \n" &

      "* * * * * * * * * * * * * * * * \n" &

      "* * * * * * * * * * * * * * * * \n" &

      "* * - - - - - - - - - - - - * * \n" &

      "* * - * * * * * * * * * * - * * \n" &

      "* * - * * * * * * * * * * - * * \n" &

      "* * - * * * * * * * * * * - * * \n" &

      "* * - * * * * * * * * * * - * * \n" &

      "* * - * * * * * * * * * * - * * \n" &

      "* * - * * * * * * * * * * - * * \n"

    }

  }
```

Graphics are limited to the original four CGA colors: black (space); cyan (asterisk); magenta (hyphen) and white (number sign / pound / octothorpe). Cyan and magenta are swapped for enemy planes (single player) and player 2 (multiplayer).

The following graphics are defined:

swplnsym (16x16)

Plane. There are four frames, for facing right (0), rotated 22.5 degrees counterclockwise (1), 45 degrees (2) and 67.5 degrees (3).

swhitsym (16x16)

Crashing plane. There are two frames of animation.

swwinsym (16x16)

Plane flying into the distance after completing the level. There are four frames of animation.

swtrgsym (16x16)

Ground target. Each frame is a different target type and the values are those from TARGET TYPES below.

swhtrsym (16x16)

Destroyed ground target. Each frame a different target type; the values are those from TARGET TYPES below. The number of pixels in the symbol control the size of the explosion when the target is destroyed.

swballoonsym (16x16)

Observation balloon. Each type of balloon has three animation frames: drifting left, centered, and drifting right. Spherical balloon starts at frame 0 and Caquot-style balloon begins at frame 3.

swoxsym (16x16)

Ox. There is one frame.

swflksym (16x16)

Bird flock. There are two frames, for the "flapping wings" animation.

swbrdsym (4x2)

Bird. There are two frames, for the "flapping wings" animation.

swbmbsym (8x8)

Falling bomb. There are two frames, for facing right (0) and rotated 45 degrees counterclockwise (1).

swmscsym (8x8)

Missile. There are four frames, for facing right (0), rotated 22.5 degrees counterclockwise (1), 45 degrees (2) and 67.5 degrees (3).

swbstsym (8x8)

Starburst (flare). There are two frames of animation.

swexpsym (8x8)

Debris after an explosion. There are eight frames for different types of debris.

swmedalsym (8x12)

Medals. There are three frames for each different type.

swribbonsym (8x2)

Ribbons. There are six frames for each different type.

swshtsym (16x16)

Shot out window. There is a single frame.

swsplsym (32x32)

Bird "splatted" into window. There is a single frame.

## TARGET TYPES
0

Hangar

1

Factory

2

fuel tank

3

Tank

4

Truck

5

Tanker truck

6

Flag

7

Tent

8-12

User-defined target; the symbols section should be used to supply the graphics (see SYMBOLS SECTION above). Type 12 produces a big explosion like an oil tank when destroyed.

13-17

"Passive" user-defined target (does not fire at enemy planes). Type 17 produces a big explosion like an oil tank when destroyed.

18

Radio tower

19

Water tower

## SOUNDS SECTION
The sounds section allows the in-game music to be replaced. There is only one property at present, named title_tune; its value is a string containing a sequence of notes to play. The following is an example of a sounds section that replaces the title music with the beginning of "Au Clair de la Lune":

```
  sounds {

    title_tune:

    "g4/r8/g4/r8/g4/r8/a4/r8/b2/r4/a2/r2/" &

    "g4/r8/b4/r8/a4/r8/a4/r8/g2/r2/"

  }
```

As seen, the format consists of a number of musical notes (a-g) separated by '/' characters. The notes are in the C major scale. Each note is followed by a number that indicates the length of the note as a fraction of a whole note; for example, 2 means half-note, 4 means quarter-note, etc. The following additional syntax is also supported:

- For a rest, use "r" instead of a note character. The syntax is otherwise identical to that for a normal note, with the only difference being that no note will be played.

- To play a sharp, append a '+' character. For example, "g+4/" represents a quarter-length G#. Alternatively you can append a '-' to play a flat; for example "e-2/" is a half-length E-flat (aka D#).

- Prefix a note with < or > to shift down or up an octave. All subsequent notes will be played in this octave.

- Append a '.' character to play a dotted note. A dotted note plays for 50% longer than a normal note.

The original DOS version of Sopwith interpreted notes as being in the A minor scale, but this is believed to have been a mistake and notes are now assumed to be in the more common C major scale. This does, however, mean that tunes from DOS .exe hacks will play differently; any A or B notes will need to be shifted down one octave to convert to the C major scale.

## SEE ALSO
sopwith(6),

## AUTHORS
This manual page was written by Simon Howard.

## HISTORY
The original DOS version of Sopwith only supported a single level, although later versions increased the difficulty by repeatedly playing the same level again at increasing speeds. Some modifications were made by fans by hex-editing the DOS .exe file.

Some simple hacks just changed the name shown on the title screen (one changed it to "Red Baron", for example). Some more elaborate mods that changed the level itself included "Blokwit" and "Sokwith". Andrew Jenner even developed a basic level editor that allowed people to make their own maps, although the changes that can be made using this technique are inherently limited.

Full support for custom maps did not appear until 2024, with SDL Sopwith's v2.4 release. There will likely be further future extensions to this format to allow people to share more elaborate modifications to the game.


sopwith.cfg

title: sopwith.cfg(5)

summary: configuration file for SDL Sopwith

text:
# sopwith.cfg(5)

## NAME
sopwith.cfg - configuration file for SDL Sopwith

## DESCRIPTION
sopwith.cfg is the configuration file for sopwith(6). The settings stored in sopwith.cfg are usually modified in-game via the options menu.

sopwith.cfg is normally stored in the user's home directory, as ~/.local/share/SDL Sopwith/default.cfg. The path can be overridden using the XDG_DATA_HOME environment variable (see the XDG Base Directory Specification).

## FILE FORMAT
The file is a plain-text file, consisting of a list of configuration options and their values, separated by whitespace. Each option is stored on a separate line.

For example:

integer_value 1

integer_value2 1

Lines beginning with "#" are interpreted as comments and will be ignored. Invalid lines or comments in the file will generate a warning, but will otherwise be ignored.

Some options are used for keyboard key bindings; these are stored as integer values containing the keyboard scan code of the key to be bound to. Boolean values are also stored as integers, with a value of zero usually indicating "false" and a non-zero value indicating "true".

## CONFIGURATION VARIABLES
vid_fullscreen

If 1, the game runs full screen rather than in a window. By default this is 0.

conf_solidground

If 1, display the ground as a solid white block, reproducing the visual appearance of "Sopwith 1". If 0, the ground is displayed as a line, reproducing the visual appearance of "Sopwith 2". By default this is 0.

conf_video_palette

Video palette to use for display. Valid values are 0 (CGA 1), 1 (CGA 2), 2 (CGA 3), 3 (Mono Amber), 4 (Mono Green), 5 (Mono Grey), 6 (Tosh LCD 1), 7 (Tosh LCD 2), 8 (Tosh LCD 3), 9 (IBM LCD), 10 (Tandy LCD), 11 (Gas Plasma) or 12 (Atari).

conf_hudsplats

If 1, "splats" are shown on the screen when the plane takes damage: splatted birds are shown on the screen after a bird strike; windscreen "cracks" are shown if the plane is hit by bullets, and the whole screen turns magenta after flying through an ox. This feature was added by the original author of Sopwith in the "Network Edition" release. By default this is 0.

conf_wounded

If 1, planes can take a single unit of damage without crashing. Your plane becomes slower to turn when wounded. This feature was added by the original author of Sopwith in the "Network Edition" release. By default this is 0.

conf_animals

If 1, oxen and birds appear in the game. These were added in "Sopwith 2" but were not present in the original "Sopwith 1". By default this is 1.

conf_harrykeys

If 1, the key_pullup and key_pulldown controls turn your plane relative to the screen, rather than your plane. It is a common point of confusion that the direction of turning appears to "reverse" when the plane is flipped / flying towards the left. By default this is 0.

conf_big_explosions

If 1, oil tanks produce a huge explosion when destroyed. This reproduces the behavior found in both "Sopwith 1" and "Sopwith 2", but the magnitude of the explosion was dialed back significantly in the "Network Edition" release. The default is 1.

conf_medals

If 1, medals are sometimes awarded to the player on return to base. Some details can be found in the "MEDALS" section of sopwith(6). The medals do not have any effect on gameplay. By default this is 1.

## KEY BINDINGS
The following settings determine the in-game controls. These are keyboard scancodes, so the key binding does not change with keyboard layout. However, the name for the key as shown in the in-game options menu should match the current keyboard layout. The values for these settings are scancodes from the USB standard for HID devices:

https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf

key_accelerate

Key to accelerate the plane. Default is "X" on a US layout keyboard.

key_decelerate

Key to decelerate the plane. Decelerating too much may cause the plane to stall. Default is "Z" on a US layout keyboard.

key_pullup

Key to pull up (aim the plane towards the sky). Default is "," on a US layout keyboard. Note that conf_harrykeys may change the behavior of this key binding.

key_pulldown

Key to pull down (aim the plane towards the ground. Default is "/" on a US layout keyboard. Note that conf_harrykeys may change the behavior of this key binding.

key_flip

Key to flip the plane upside down. Default is "." on a US layout keyboard.

key_fire

Key to fire the machine gun. Default on a US layout keyboard is the spacebar.

key_dropbomb

Key to drop a bomb. Default is "B" on a US layout keyboard.

key_home

Key to autopilot the plane home to base. Default is "H" on a US layout keyboard.

## HIDDEN SETTINGS
The following are "hidden settings": they cannot be edited in-game via the options menu, and editing the configuration file is the only way to change them.

snd_tinnyfilter

If 1, a filter is applied to the sound output so that it sounds more like a tinny PC speaker that's inside a metal PC case. By default this is 1.

conf_missiles

Enable missiles and starbursts (flares). This is a feature that was originally added by the author of Sopwith in the "Network Edition" release, but has been hidden as it significantly changes the gameplay in a way that doesn't fit the game's theme and also isn't particularly fun.

key_missile

Fire missile, if conf_missiles is enabled. Default key is "V" on a US layout keyboard.

key_starburst

Launch starburst (flare) if conf_missiles is enabled. Default key is "C" on a US layout keyboard.

## SEE ALSO
sopwith(6)


aliases

package: sendmail

title: aliases(5)

summary: aliases file for sendmail

text:
# aliases(5)

## NAME
aliases - aliases file for sendmail

## SYNOPSIS
aliases

## DESCRIPTION
This file describes user ID aliases used by sendmail. The file resides in /etc/mail and is formatted as a series of lines of the form

name: addr_1, addr_2, addr_3, . . .

The name is the name to alias, and the addr_n are the aliases for that name. addr_n can be another alias, a local username, a local filename, a command, an include file, or an external address.

Local Username

username

The username must be available via getpwnam(3).

Local Filename

/path/name

Messages are appended to the file specified by the full pathname (starting with a slash (/))

Command

|command

A command starts with a pipe symbol (|), it receives messages via standard input.

Include File

:include: /path/name

The aliases in pathname are added to the aliases for name.

E-Mail Address

user@domain

An e-mail address in RFC 822 format.

Lines beginning with white space are continuation lines. Another way to continue lines is by placing a backslash directly before a newline. Lines beginning with # are comments.

Aliasing occurs only on local names. Loops can not occur, since no message will be sent to any person more than once.

If an alias is found for name, sendmail then checks for an alias for owner-name. If it is found and the result of the lookup expands to a single address, the envelope sender address of the message is rewritten to that address. If it is found and the result expands to more than one address, the envelope sender address is changed to owner-name.

After aliasing has been done, local and valid recipients who have a ``.forward'' file in their home directory have messages forwarded to the list of users defined in that file.

This is only the raw data file; the actual aliasing information is placed into a binary format in the file /etc/mail/aliases.db using the program newaliases(1). A newaliases command should be executed each time the aliases file is changed for the change to take effect.

## SEE ALSO
newaliases(1), dbm(3), dbopen(3), db_open(3), sendmail(8)

SENDMAIL Installation and Operation Guide.

SENDMAIL An Internetwork Mail Router.

## BUGS
If you have compiled sendmail with DBM support instead of NEWDB, you may have encountered problems in dbm(3) restricting a single alias to about 1000 bytes of information. You can get longer aliases by ``chaining''; that is, make the last name in the alias be a dummy name which is a continuation alias.

## HISTORY
The aliases file format appeared in 4.0BSD.


faillog

package: shadow-log

title: faillog(5)

summary: login failure logging file

text:
# faillog(5)

## NAME
faillog - login failure logging file

## DESCRIPTION
/var/log/faillog maintains a count of login failures and the limits for each account.

The file contains fixed length records, indexed by numerical UID. Each record contains the count of login failures since the last successful login; the maximum number of failures before the account is disabled; the line on which the last login failure occurred; the date of the last login failure; and the duration (in seconds) during which the account will be locked after a failure.

The structure of the file is:

```
struct	faillog {
	short   fail_cnt;
	short   fail_max;
	char    fail_line[12];
	time_t  fail_time;
	long    fail_locktime;
};
```

## FILES
/var/log/faillog

Failure logging file.

## SEE ALSO
faillog(8)


subgid

package: shadow-submap

title: subgid(5)

text:
# subgid(5)

## NAME
subgid - the configuration for subordinate group ids

## DESCRIPTION
Subgid authorizes a group id to map ranges of group ids from its namespace into child namespaces.

The delegation of the subordinate gids can be configured via the subid field in /etc/nsswitch.conf file. Only one value can be set as the delegation source. Setting this field to files configures the delegation of gids to /etc/subgid. Setting any other value treats the delegation as a plugin following with a name of the form libsubid_$value.so. If the value or plugin is missing, then the subordinate gid delegation falls back to files.

Note, that newusers, useradd, and usermod will only create entries in /etc/subgid if subid delegation is managed via subid files.

## LOCAL SUBORDINATE DELEGATION
Each line in /etc/subgid contains a user name and a range of subordinate group ids that user is allowed to use. This is specified with three fields delimited by colons (“:”). These fields are:

•login name or UID

•numerical subordinate group ID

•numerical subordinate group ID count

This file specifies the group IDs that ordinary users can use, with the newgidmap command, to configure gid mapping in a user namespace.

Multiple ranges may be specified per user.

When large number of entries (10000-100000 or more) are defined in /etc/subgid, parsing performance penalty will become noticeable. In this case it is recommended to use UIDs instead of login names. Benchmarks have shown speed-ups up to 20x.

## FILES
/etc/subgid

Per user subordinate group IDs.

/etc/subgid-

Backup file for /etc/subgid.

## SEE ALSO
login.defs(5), newgidmap(1), newuidmap(1), newusers(8), subuid(5), useradd(8), userdel(8), usermod(8), user_namespaces(7).


subuid

title: subuid(5)

text:
# subuid(5)

## NAME
subuid - the configuration for subordinate user ids

## DESCRIPTION
Subuid authorizes a user id to map ranges of user ids from its namespace into child namespaces.

The delegation of the subordinate uids can be configured via the subid field in /etc/nsswitch.conf file. Only one value can be set as the delegation source. Setting this field to files configures the delegation of uids to /etc/subuid. Setting any other value treats the delegation as a plugin following with a name of the form libsubid_$value.so. If the value or plugin is missing, then the subordinate uid delegation falls back to files.

Note, that newusers, useradd, and usermod will only create entries in /etc/subuid if subid delegation is managed via subid files.

## LOCAL SUBORDINATE DELEGATION
Each line in /etc/subuid contains a user name and a range of subordinate user ids that user is allowed to use. This is specified with three fields delimited by colons (“:”). These fields are:

•login name or UID

•numerical subordinate user ID

•numerical subordinate user ID count

This file specifies the user IDs that ordinary users can use, with the newuidmap command, to configure uid mapping in a user namespace.

Multiple ranges may be specified per user.

When large number of entries (10000-100000 or more) are defined in /etc/subuid, parsing performance penalty will become noticeable. In this case it is recommended to use UIDs instead of login names. Benchmarks have shown speed-ups up to 20x.

## FILES
/etc/subuid

Per user subordinate user IDs.

/etc/subuid-

Backup file for /etc/subuid.

## SEE ALSO
login.defs(5), newgidmap(1), newuidmap(1), newusers(8), subgid(5), useradd(8), userdel(8), usermod(8), user_namespaces(7).