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 public IP address release and takeover, as well as monitoring interfaces used by public IP addresses.

CTDB_KILLTCP_USE_SS_KILL=yes|try|no

Whether to use ss -K/--kill to reset incoming TCP connections to public IP addresses during releaseip. CTDB's standard method of resetting incoming TCP connections during releaseip is via its custom ctdb_killtcp command. This uses network trickery to reset each connection: send a "tickle ACK", capture the reply to extract the TCP sequence number, send a reset (containing the correct sequence number).

ss -K has been supported in ss since iproute 4.5 in March 2016 and in the Linux kernel since 4.4 in December 2015. However, the required kernel configuration item CONFIG_INET_DIAG_DESTROY is disabled by default. Although enabled in Debian kernels since ~2017 and in Ubuntu since at least 18.04, this has only recently been enabled in distributions such as RHEL. There seems to be no way, including running ss -K, to determine if this is supported, so use of this feature needs to be configurable. When available, it should be the fastest, most reliable way of killing connections.

Supported values are:

yes

Use ss -K and make no other attempt to kill any remaining connections. This is sane on modern Linux distributions that are guaranteed to have CONFIG_INET_DIAG_DESTROY enabled.

try

Attempt to use ss -K and fall back to ctdb_killtcp for any remaining connections. This may be a good value when ss supports the -K option but it is uncertain whether CONFIG_INET_DIAG_DESTROY is enabled.

no

Never attempt to use ss -K. Rely only on ctdb_killtcp.

Default is "no".

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_SHARED_STATE_DIR=DIRECTORY

DIRECTORY where clustered NFS shared state will be located. DIRECTORY should be in a cluster filesystem that is shared between the nodes. No default.

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_STATD_CALLOUT_SHARED_STORAGE=LOCATION

LOCATION where NFSv3 statd state will be stored. Valid values are: persistent_db[:TDB]

Data is queued to local storage and then dequeued to TDB during monitor events. This means there is a window where locking state may be lost. However, this works around performance limitations in CTDB's persistent database handling. If :TDB is omitted then TDB defaults to ctdb_statd_callout.tdb.

shared_dir[:DIRECTORY]

DIRECTORY is a directory in a cluster filesystem that is shared between the nodes. If DIRECTORY is relative (i.e. does not start with '/') then it is appended to CTDB_NFS_SHARED_STATE_DIR. If :DIRECTORY is omitted then DIRECTORY defaults to statd. Using a shared directory may result in performance and/or stability problems. rpc.statd is single-threaded and its HA callout is called synchronously, causing any latency introduced by the callout to be cumulative. Stability issues are most likely if thousands of clients reclaim locks after failover and use of the cluster filesystem introduces too much additional latency. Too much latency in in the HA callout may cause rpc.statd to fail health monitoring.

none

No cluster-aware handling of NFSv3 statd state is done. NFSv3 lock reclaim will not occur and applications that use locking over NFSv3 are likely to lose or corrupt data. This should be used with care and only in the case where no applications are using POSIX locks in NFSv3 mounts. It should probably be considered an option to test the latency of statd_callout, without including any storage costs.

### 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 HANDLING
CTDB checks the consistency of databases during startup and provides a facility to backup persistent databases.

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

CTDB_PERSISTENT_DB_BACKUP_DIR=DIRECTORY

Create a daily backup tarball for all persistent TDBs in DIRECTORY. Note that DIRECTORY must exist or no backups will be created. Given that persistent databases are fully replicated, duplication is avoid by only creating backups on the current leader node. To maintain a complete, single set of backups, it makes sense for DIRECTORY to be in a cluster filesystem.

This creates the backup from the monitor event, which should be fine because backing up persistent databases is a local operation. Users who do not wish do create backups during the monitor event can choose not to use this option and instead run /etc/ctdb/ctdb-backup-persistent-tdbs.sh -l DIRECTORY on all nodes using a cron(8) job, which will also need to manually manage backup pruning.

No default. No daily backups are created.

CTDB_PERSISTENT_DB_BACKUP_LIMIT=COUNT

Keep at most COUNT backups in CTDB_PERSISTENT_DB_BACKUP_DIR. Note that if additional manual backups are created in this directory then these will count towards the limit. Default is 14.

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

branch: sisyphus


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) or using InfiniBand for the private network. Another unlikely possibility would be running on a platform with a feature like Linux's net.ipv4.ip_nonlocal_bind=1 enabled and no usable getifaddrs(3) implementation (or replacement) available.

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

nodes list = SOURCE

SOURCE specifies the location containing the list of the private addresses of nodes in the cluster. Typically, SOURCE will be a path to a file that contains the list of private addresses for the cluster. For details about the content of the file please see the PRIVATE ADDRESSES section in ctdb(7).

As an alternative to using a file one can use an arbitrary command to provide the contents of the nodes list. If an exclamation point ('!') is the first character of the SOURCE value, the remainder of the value will be executed when the private addresses are to be read. For example, a value of !/usr/bin/mynodes cluster1 would run the given command with the specified arguments. The output generated by the command (on standard out) must be the same as what is supported by a SOURCE file. The command name must be a full path to an executable. Arguments are supported, but shell-style quoting is not, and space characters will always produce a new argument for the command. It is important to note that running this command blocks until the command has completed. The run time of this command will depend on how it is implemented and environmental factors. Be aware that if the command runs for a non-trivial amount of time it can introduce undesirable stalls into ctdbd.

Default: /etc/ctdb/nodes

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.22.10-alt1 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 configuration 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.


sccschangeset

package: schilytools

title: sccschangeset(5)

summary: format of an SCCS changeset file

text:
# sccschangeset(5)

## NAME
sccschangeset - format of an SCCS changeset file

## DESCRIPTION
An SCCS changeset file is an ASCII file consisting of a list of entries that describe the state of a project set under control of SCCSv6 or later.

The changeset file itself is under control of SCCS. SCCS works directly on the s.changeset file. There is no need to check out the related file content, as the deltas can be constructed without explicitly running the diff(1) program; this results in a noticeable performance win.

Parts of the information are recorded inside the changeset file content and other information is recorded within the SCCS meta data of the changeset file.

### Conventions
The following terms are used in this documentation:

project set

A set of one or more files under control of SCCS that form a project.

project set home

A directory that is above all files from the related project set. This directory holds a directory .sccs with project set related meta data such as the changeset file and typically the SCCS history files related to the project.

commit set

A single set of changes into the repository for a project set.

committer

The person who formed a commit set.

email address

The email address used to identify a committer. Since the email address is valid for a whole commit set, it is recorded in the meta data of the related delta to the changeset file.

### File Format
Each commit set adds a number of entries to the beginning of the changeset file, one entry for every file that was modified by this commit set.

Each entry in the changeset file describes the new state of a single file after it was modified, renamed, removed or restored in a related commit set.

Each entry in the changeset file ends in a newline character. If the file name from the related file contains a newline character, additional newlines may be in the related entry.

Each entry in the changeset file consists of five fields that are specific to a single file from the changeset. The entries are separated by a vertical bar character (ASCII 0x7C). The vertical bar character may appear in the path name.

The following fields appear in the order of the following list:

urand

A unified pseudo random number that is used to help to identify single files across renames during the lifetime of the sccs history. The unified random number is unique to any file from the project set. See sccsfile(5) for a detailed description of the unified pseudo random number. The minimal length for the pseudo random number is thirteen hexadecimal characters. If the number could be represented with less digits, it is left filled with zeroes. This allows one to have a unique length for this number until Mar 31 10:55:07 2155 GMT.

sid

The file specific SID that was used for the file mentioned in that line of the changeset.

sid-sum

The SID specific checksum for the related file. See sccsfile(5) for a detailed description of the SID specific checksums for a file.

path length

A decimal number representing the number of bytes in the path name not including the final newline character used to terminate the whole entry.

path name

The path name of the related file after the commit has been applied. The path name holds a relative path as seen from the project set home directory. As the path name is the last member in the lines of a changeset file, it may contain the vertical bar character (ASCII 0x7C).

A typical entry in the changeset file may look like:

0e31666e43286|1.3|45206|15|some/dir/file.c

## FILES
The sccs init command creates an initial framework of directories and files that allow to maintain a set of files in project mode. The following directory structure is created:

projecthome/.sccs/

The location of SCCS files in case that SCCS is in project mode.

projecthome/.sccs/data

The location of the SCCS off-tree shadow directory tree that holds the history files for all files under control of SCCS when in project mode.

projecthome/.sccs/dels

The location of the history files from deleted files that have been in the repository.

projecthome/.sccs/SCCS/s.changeset

The project specific changeset file is in the directory .sccs in the project set home directory. This is the central database that allows one to retrieve the relation between project versions and file specific versions. Only the s.changeset file is present, a related g-file does not exist.

## SEE ALSO
sccs(1), sccs-admin(1), sccs-cdc(1), sccs-comb(1), sccs-cvt(1), sccs-delta(1), sccs-get(1), sccs-help(1), sccs-log(1), sccs-prs(1), sccs-prt(1), sccs-rmdel(1), sccs-sact(1), sccs-sccsdiff(1), sccs-unget(1), sccs-val(1), bdiff(1), diff(1), what(1), sccsfile(5).

## BUGS
None currently known.

Mail bugs and suggestions to schilytools@mlists.in-berlin.de or open a ticket at https://codeberg.org/schilytools/schilytools/issues.

The mailing list archive may be found at:

```
https://mlists.in-berlin.de/mailman/listinfo/schilytools-mlists.in-berlin.de.
```


sccsfile

title: sccsfile(5)

summary: format of an SCCS history file

text:
# sccsfile(5)

## NAME
sccsfile - format of an SCCS history file

## DESCRIPTION
An SCCS file is an ASCII file consisting of six logical parts (SCCS v4 checksum, delta table, usernames, flags, comments, body) or eight logical parts (SCCS v6 checksum, delta table, usernames, v4 flags, v6 flags, v6 metadata, comments, body):

checksum

Character sum computed on the rest of the file, used for error detection.

delta table

Log containing version info and statistics about each delta.

usernames

Login names and/or group IDs of users who may add deltas.

flags

Definitions of internal keywords and configuration for user defined behavior (SCCS v4).

v6 flags

Optional further internal definitions. SCCS v6 only.

v6 metadata

Optional global metadata. SCCS v6 only.

extensions

This is the area where future versions of SCCS will add extensions.

comments

An arbitrary descriptive information block about the file.

body

the Actual text lines intermixed with control lines. This body is also known as interleaved deltas or the weave.

Each section is described in detail below.

This document describes the SCCS v4 history file format that has been introduced in February 1977 as well as the SCCS v6 enhancements that have been introduced in September 2011.

### Conventions
Throughout an SCCS file there are lines which begin with the ASCII SOH (start of heading) character (octal 001). This character is hereafter referred to as the control character, and will be represented as `^A'. If a line described below is not depicted as beginning with the control character, it cannot do so and still be within SCCS file format.

Entries of the form ddddd represent a decimal number. In the statistics line from the delta table, this represents a five digit string (a number between 00000 and 99999). Other numbers are not artificially limited to a specific range. Serial numbers and SID number components may be any non negative number representable by a signed 32 bit integer.

The usable range on a specific machine is however limited by the available virtual memory. This implementation needs virtual memory that is approx. 100 times the highest serial number from the file. If a SCCS history file contains one million deltas, this implementation needs 100 MBytes of virtual memory to process the deltas.

### Checksum
The checksum is the first line of an SCCS file. The form of the line is:

```
^Ahddddd
```

The value of the checksum is the low 16 bits from the signed sum of all characters, except those contained in the first line. When reading files, values computed as the unsigned sum of all characters are accepted too. The ^Ah provides a 16 bit magic number of (octal) 064001 in PDP-byteorder and 000550 in Motorola-byteorder ("\001\150").

### SCCS v6 Checksum
SCCS v6 introduces a different checksum line:

```
^AhV6,sum=ddddd
```

The checksum line was changed in order to prevent historic SCCS implementations from accidentally ignoring project-related (project-global) locks. It permits future versions to decide on different checksum algorithms without a need to again introduce a new history file format.

In SCCS v6, the ^Ah magic is not directly followed by the checksum but by the letter V that is followed by the SCCS version number. The version number is followed by a comma and the checksum algorithm name. The string sum is interpreted as the SCCS v4 checksum method. The SCCS v4 checksum entry must directly follow the SCCS version number.

Further checksums may be added in the future, e.g.:

```
^AhV6,sum=ddddd,md5=hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
```

but the sum= entry is mandatory. SCCS v6 currently does not implement checksum algorithms other than sum. Other entries are currently ignored when reading and silently discarded when copying or modifying files.

### Delta Table
The delta table consists of a variable number of entries of the form:

```
^As inserted/deleted/unchanged
^Ad type  sid  yr/mo/da
hr:mi:se
username  serial-number \
predecessor-sn
^Ai include-list
^Ax exclude-list
^Ag ignored-list
^Am mr-number
...
^Ac comments ...
...
^Ae
```

The lines with the entry type ^As, ^Ad and ^Ae are mandatory.

The first line (^As) contains the number of lines inserted/deleted/unchanged respectively. The actual values for inserted/deleted/unchanged are five digit numbers. If an actual value is greater than 99999, then it is replaced by 99999.

The second line (^Ad) contains the type of the delta in the second word:

D

for a normal delta

R

for a removed delta

U

for a delta that causes to unlink the g-file If this delta type is used for the initial release of a SCCS history file, the default SID is set to 1.0 to permit the first delta with data to have the typical 1.1.

The delta table type is followed by the SCCS ID (SID) of the delta, the date and time of creation of the delta as local time, the user-name corresponding to the real user ID at the time the delta was created, and the serial numbers of the delta and its predecessor, respectively.

The year is either represented by a two digit year in the range 69..99 for 1969..1999 or 00..68 for 2000..2068 or by a four digit year number. Year numbers before 1969 are currently not supported. Older SCCS versions may not be able to understand four digit year numbers.

The user-name must not contain a space character, as space is the field separator in this file format. Since some non-POSIX platforms permit a space in the username, it is converted into a `_' by the SCCS software before storing it in the history file.

The ^Ai, ^Ax, and ^Ag lines contain the serial numbers of deltas included, excluded, and ignored, respectively. These lines do not always appear.

The ^Am lines (optional) each contain one MR number associated with the delta.

The ^Ac lines contain comments associated with the delta. If there is more than one comment line, each comment line appears after a separate ^Ac lead in.

The ^Ae line ends the current delta table entry.

### SCCS v6 Delta Table
SCCS v6 uses an enhanced delta table:

```
^As inserted/deleted/unchanged
^Ad type  sid  yr/mo/da
hr:mi:se
[.ss]+-hhmm username \
serial-number predecessor-sn
^Ai include-list
^Ax exclude-list
^Ag ignored-list
^Am mr-number
...
^AS sid-specific metadata
...
^Ac comments ...
...
^Ae
```

The second line (^Ad) must have a four digit year number, may add sub-second time stamp granularity and must have a time zone offset.

Optional sub-second time stamp granularity is introduced by a dot `.' and adds one to nine decimal digits that represent a fraction of a second up to nanosecond granularity. This number must be non-negative.

The time zone offset starts with a `+' or a `-', the value 0000 starts with a `+', negative values start with a `-'. Positive values are east to GMT. The first two decimal digits represent the hour part of the GMT offset, the last two decimal digits represent the minute part of the GMT offset. A granularity less than a minute cannot be represented.

The date and time part represents local time as in SCCS v4 entries, but the mandatory timezone offset makes the time unique. The time stamp:

```
2012/02/01 13:00:00+0100
```

represents 2012, the first of February 12:00 GMT which is 13:00 MET.

The ^AS lines introduce SID specific SCCS v6 extensions. SID specific extension lines are in name/value format and take the form:

^AS name optional value text

The following name parameters are defined:

p path

Record the current path of the g-file relatively to the project's file set home directory. A path entry only appears in case a rename or remove operation has been applied to the file. The project set home is a directory that holds a directory .sccs for project specific SCCS metadata. The location of this directory .sccs is searched for by scanning the filesystem towards the root directory, starting from the current working directory. All files that belong to a project must be below the project's file set home directory.

See also the description for the same keyword in the section for global meta data, where the the initial file name is recorded.

s nnnnn

A SID specific additional checksum. The value of the checksum is the low 16 bits from the unsigned sum of all characters in the SID specific file content as retrieved by `get -e' (without keyword expansion). If the file is archived UU-encoded (see `e' flag), the checksum is computed on the UU-encoded text and not on the original file.

The data format in the extended SCCS delta entry (^Ad) and the SCCS SID specific metadata (^AS) is not accepted by historic SCCS implementations. When converting a SCCS v6 history file back to a SCCS v4 history file, these entries are converted into special comment at the beginning of the comment section. While converting, a copy of the unmodified ^Ad entry is kept as ^Ac_d and ^AS is turned into ^Ac_S.

### User Names
The list of user-names and/or numerical group IDs of users who may add deltas to the file, separated by NEWLINE characters. The lines containing these login names and/or numerical group IDs are surrounded by the bracketing lines ^Au and ^AU. An empty list allows anyone to make a delta.

### Flags
Flags are keywords that are used internally (see sccs-admin(1) for more information on their use). Each flag line takes the form:

^Af flag optional text

Flags may be selected from the set of 26 lower case characters in the range `a'..`z'. Historical SCCS implementations will dump core in case a character outside the specified range appears as flag character.

The following flags are defined in order of appearance:

^Af t type-of-program

Defines the replacement for the %Y% ID keyword.

^Af v program-name

Controls prompting for MR numbers in addition to comments. If the optional text is present, it defines an MR number validity checking program. The v flag and the z flag are mutually exclusive.

^Af i [value]

Indicates that the `No id keywords' message is to generate an error that terminates the SCCS command. Otherwise, the message is treated as a warning only. If the parameter value to the `i' flag is not empty, then it holds a line fragment with keywords starting with a `%', e.g.

`%Z%%M% %I% %E%'

This line fragment needs to exactly match a part of a line in the file and to result in expanded keywords. Otherwise an attempt to check in a new delta will fail. The parameter to the `i' flag is a SUN extension.

^Af b

Indicates that the -b option may be used with the SCCS get command to create a branch in the delta tree.

^Af m module-name

Defines the first choice for the replacement text of the %M% ID keyword.

^Af f floor

Defines the "floor" release, that is, the release below which no deltas may be added.

^Af c ceiling

Defines the "ceiling" release, that is, the release above which no deltas may be added.

^Af d default-sid

The d flag defines the default SID to be used when none is specified on an SCCS get command.

^Af n

The n flag enables the SCCS delta command to insert a "null" delta (a delta that applies no changes) in those releases that are skipped when a delta is made in a new release (for example, when delta 5.1 is made after delta 2.7, releases 3 and 4 are skipped).

^Af j

Enables concurrent get -e calls for editing on the same base SID of an SCCS file. This allows multiple concurrent updates to take place on the same version of the SCCS file.

^Af l lock-releases

Defines a list of releases that are locked against editing.

^Af q user-defined

Defines the replacement for the %Q% ID keyword.

^Af e 0|1

The e flag indicates whether a source file is encoded or not. A 1 indicates that the file is encoded. Source files need to be encoded when they contain control characters, or when they do not end with a NEWLINE. The e flag allows files that contain binary data to be checked in.

^Af z application

The name of an application for the CMF enhancements. CMF enhancements are currently undocumented and it is not known how they are expected to work. The v flag and the z flag are mutually exclusive.

^Af s nnn

The number of lines to be scanned for keyword expansion. This flag is a SUN extension that does not exist in historic sccs implementations.

^Af x SCHILY|0

If the value of the `x' flag is set to `SCHILY', enable sccs extensions that are not implemented in classical sccs variants. If the `x' flag is enabled, the keywords %d%, %e%, %g% and %h% are expanded even though not explicitly enabled by the `y' flag. This flag is a SCHILY extension that does not exist in historic sccs implementations.

This version of SCCS implements read only compatibility support for a SCO SCCS extension that sets the executable bit in the file permissions of a gotten file if the x-flag was set in the history file with no parameter. This version of SCCS does not allow to set this variant of the x-flag in the history file. If you like to get executable files from SCCS, set the executable bit in the file permissions of the history file.

If this version of SCCS is used to create the history file and the executable bit was set in the original file, SCCS automatically sets the executable bit in the history file and thus retains the executable bit in the gotten file.

^Af y val ...

The list of sccs keywords to be expanded. If the y-flag is missing in the sccs historyfile, all sccs keywords are expanded. If the flag is present but the list is empty, no keyword is expanded and no `No id keywords' message is generated. The value `*' controls the expansion of the %sccs.include.filename% keyword. This flag is a SUN/SCHILY extension that does not exist in historic sccs implementations.

### SCCS v6 Flags
SCCS v6 flags are additional keywords that are used internally (see sccs-admin(1) for more information on their use). Each flag line takes the form:

^AF flag optional text

No SCCS v6 flags are currently defined.

Historical SCCS implementations do not complain about SCCS v6 flags when reading SCCS history files and retain SCCS v6 flags when modifying history files. This is why SCCS v6 flags may be kept unmodified when converting a SCCS v6 history file back to a SCCS v4 history file.

### SCCS v6 Metadata
SCCS v6 metadata is additional global metadata that is used internally (see sccs-admin(1) for more information on it's use). Each metadata line takes the form:

^AG keyword optional text

The following keywords are defined:

p path

Record the initial path of the g-file relatively to the project's file set home directory. Once set up, this name must never change. See also the description for the project set home in the documentation for the same keyword in the section for SID specific meta data of the delta table. In case of a rename, the new file name is recorded in in the SID specific meta data of the delta table.

r random

A unified pseudo random number (see also changeset(5)) that is used to help to identify single files across renames during the lifetime of the sccs history. The pseudo random number is a hexadecimal string that represents the microseconds since Jul 13 11:01:20 2012 GMT when initially creating the sccs history for a specific file. Including microseconds gives sufficient randomness to make clashes rare.

With a 32 bit signed time_t, 52 bits in the pseudo random number are sufficient. With a 64 bit pseudo random number, more than 500000 years are covered.

The minimal length for the pseudo random number is thirteen hexadecimal characters. If the number could be represented with less digits, it is left filled with zeroes. This allows one to have a unique length for this number until Mar 31 10:55:07 2155 GMT.

The random metadata is mandatory for SCCS v6 history files. The initial path tag may be recorded later but before the changeset file is created. The value for this metadata tags must not change.

Historical SCCS implementations do not complain about SCCS v6 metadata when reading SCCS history files and retain SCCS v6 metadata when modifying history files. This is why SCCS v6 metadata may be kept unmodified when converting a SCCS v6 history file back to a SCCS v4 history file.

### Extensions
This is the area where future versions of SCCS will add extensions.

SCCS reserves the area just before the comments section for extensions by only checking the content at this location for syntactic correctness. Unknown elements at this location are still copied and kept intact when the historyfile is modified. SCCS v6 already introduced SCCS v6 flags and global SCCS v6 metadata as extensions, so future extensions must appear past the SCCS v6 metadata.

### Comments
Arbitrary text surrounded by the bracketing lines ^At and ^AT. The comments section typically will contain a description of the file's purpose.

### Body
The body consists of text lines and control lines. Text lines do not begin with the control character, unless they are using SCCS v6 escape extensions. Control lines always begin with the control character.

There are three kinds of control lines: insert, delete, and end, represented by:

```
^AI ddddd
^AD ddddd
^AE ddddd
```

respectively. The digit string is the serial number corresponding to the delta for the control line.

An inserted block of lines looks this way:

```
^AI ddddd
block of data
^AE ddddd
```

A deleted block of lines looks this way:

```
^AD ddddd
block of data
^AE ddddd
```

The block of data may contain control lines with other serial numbers.

### SCCS v6 Body escape extensions
There are two additional types of text lines with a control character at the beginning that represent features introduced by SCCS v6. These features are not understood by SCCS implementations that support the SCCS v4 history file format only.

^A^A

A line in the interleaved delta block that begins with two control characters represents a text line that begins at the second control character.

^AN

A line in the interleaved delta block that begins with the ^AN sequence represents a text line that does not end with a newline character. A line in the form ^AN^Atext is extracted as ^Atext without a need to add another quote.

## FILES
``g-file''

version retrieved by get

d.file

temporary file created by the delta(1) program with the content of the previous version, used to compute differences to the current version

e.file

temporary file to hold an uuencoded version of the g-file in case of an encoded history file. Used by admin(1) and delta(1).

l.file

file containing extracted delta table info

o.file

saved original version of the history file, created by sccscvt(1).

p.file

permissions (lock) file for checked-out versions. The p.file has an arbitrary number of lines, each is related to a get -e call. Each line has the following structure:

old-sid new-sid username date time \

[ -ii-arg ][ -xx-arg ][ -zz-arg ]

The old-sid is the SID that was checked out with get -e, the new-sid is the SID that will be used for the new version when delta is called. The username is the user-name corresponding to the real user ID at the time get -e was called. The date and time fields are in the same format as used in the delta table of the s.file as described in sccsfile(5) for SCCS v4. In order to grant POSIX compatibility, a two digit year is used between 1969 and 2068. For years outside that range, a four digit year is used. The following fields are only present when one or more of the -i -x or -z options have been specified on the command line, they refer to the list of included and excluded deltas or to the CMR list from the NSE enhancements.

q.file

temporary copy of the p.file; renamed to the p.file after completion

s.file

SCCS history file, see sccsfile(5).

SCCS/s.file

history file in SCCS subdirectory

x.file

temporary copy of the s.file; renamed to the s.file after completion. Used by admin(1), cdc(1), delta(1), rmdel(1), and sccscvt(1).

z.file

temporary lock file contains the binary process id in host byte order followed by the host name

projecthome/.sccs/SCCS/s.changeset

The project specific changeset file is in the directory .sccs in the project set home directory. Only the s.changeset file is present, a related g-file does not exist.

dump.core

If the file dump.core exists in the current directory and a fatal signal is received, a coredump is initiated via abort(3).

/usr/ccs/include/

If the environment SCCS_INCLUDEPATH does not exist, include files for the %sccs.include.filename% keyword directive are searched in this directory.

## SEE ALSO
sccs(1), sccs-admin(1), sccs-cdc(1), sccs-comb(1), sccs-cvt(1), sccs-delta(1), sccs-get(1), sccs-help(1), sccs-log(1), sccs-prs(1), sccs-prt(1), sccs-rmdel(1), sccs-sact(1), sccs-sccsdiff(1), sccs-unget(1), sccs-val(1), bdiff(1), diff(1), what(1), sccschangeset(5).

## NOTES
The following SCCS programs write or modify SCCS history files and create lock files for the SCCS history files:

admin(1)

create and administer SCCS history files

cdc(1)

change the delta commentary of an SCCS delta

delta(1)

make a delta to an SCCS file

rmdel(1)

remove a delta from an SCCS file

sccscvt(1)

convert history files between SCCS v4 and SCCS v6

The following SCCS programs do not write or modify SCCS history files but create lock files for SCCS history files since they modify p.files:

get(1)

when using the option -e to check out a file for editing

unget(1)

undo a previous get of an SCCS file

## BUGS
SCCS v4 uses local time without a timezone offset. If a delta is created less than an hour after switching from DST to non-DST, it may look as if the clock is going backwards. SCCS v6 fixes this problem by introducing a mandatory timezone offset.

Mail bugs and suggestions to schilytools@mlists.in-berlin.de or open a ticket at https://codeberg.org/schilytools/schilytools/issues.

The mailing list archive may be found at:

```
https://mlists.in-berlin.de/mailman/listinfo/schilytools-mlists.in-berlin.de.
```

## AUTHORS
The SCCS suite was originally written by Marc J. Rochkind at Bell Labs in 1972. Release 4.0 of SCCS, introducing new versions of the programs admin(1), get(1), prt(1), and delta(1) was published on February 18, 1977; it introduced the new text based SCCS v4 history file format (previous SCCS releases used a binary history file format). The SCCS suite was later maintained by various people at AT&T and Sun Microsystems. Since 2006, the SCCS suite has been maintained by Joerg Schilling and the schilytools project authors.


streamarchive

title: streamarchive(5)

summary: StreamArchive file format

text:
# streamarchive(5)

## NAME
streamarchive - StreamArchive file format

## DESCRIPTION
StreamArchive typed archives are a series of keyword and value records that are similar to content of the POSIX.1-2001 extended headers called TAR (PAX) HEADERs, based on a proposal from Sun Microsystems from 1997.

A new file always begins with the path keyword and after the mandatory size keyword, file content may follow. Each file record is terminated by a status keyword.

An archive begins with an archtype=StreamArchive record and ends with a status=EOF record.

The archive meta data do not add non-printable characters. If the file names in the archive are only made from ASCII characters and if the archive only contains files with ASCII content, the whole archive contains only ASCII content.

## HEADER FORMAT
The header records use the following format:

"%d %s=%s\n", <length>, <keyword>, <value>

Each record starts with a a decimal length field. The length includes the total size of a record including the length field itself and the trailing new line.

The keyword may not include an equal sign. All keywords beginning with upper case letters are reserved for local extensions.

If the value field is of zero length, it deletes any header field of the same name that is in effect from the same extended header or from a previous global header.

Null characters do not delimit any value. The data used for value is only limited by its implicit length.

## HEADER KEYWORDS
All numerical values are represented as decimal strings. All texts are represented as UTF-8 or an unspecified binary format (see hdrcharset keyword) that is expected to be understood by the receiving system:

atime

The time from st_atime in sub second granularity. A nanosecond granularity is currently supported.

charset

The name of the character set used to encode the data in the following file(s).

The following values are supported for charset:

ISO-IR 646 1990

ISO/IEC 646:1990

ISO-IR 8859 1 1998

ISO/IEC 8859-1:1998

ISO-IR 8859 2 1998

ISO/IEC 8859-2:1998

ISO-IR 8859 3 1998

ISO/IEC 8859-3:1998

ISO-IR 8859 4 1998

ISO/IEC 8859-4:1998

ISO-IR 8859 5 1998

ISO/IEC 8859-5:1998

ISO-IR 8859 6 1998

ISO/IEC 8859-6:1998

ISO-IR 8859 7 1998

ISO/IEC 8859-7:1998

ISO-IR 8859 8 1998

ISO/IEC 8859-8:1998

ISO-IR 8859 9 1998

ISO/IEC 8859-9:1998

ISO-IR 8859 10 1998

ISO/IEC 8859-10:1998

ISO-IR 8859 11 1998

ISO/IEC 8859-11:1998

ISO-IR 8859 12 1998

ISO/IEC 8859-12:1998

ISO-IR 8859 13 1998

ISO/IEC 8859-13:1998

ISO-IR 8859 14 1998

ISO/IEC 8859-14:1998

ISO-IR 8859 15 1998

ISO/IEC 8859-15:1998

ISO-IR 10646 2000

ISO/IEC 10646:2000

ISO-IR 10646 2000 UTF-8

ISO/IEC 10646, UTF-8 encoding

BINARY

None

comment

Any number of characters that should be treated as comment. The comment is ignored.

ctime

The time from st_ctime in sub second granularity. A nanosecond granularity is currently supported.

dev

The device id from st_dev of the file as decimal number. The value is a signed int. An implementation should be able to handle at least 64 bit values. Note that the value is signed because POSIX does not specify more than the type should be an int.

devmajor

The device major number of the file if it is a character or block special file. The argument is a decimal number. The value is a signed int. An implementation should be able to handle at least 64 bit values. Note that the value is signed because POSIX does not specify more than the type should be an int.

devminor

The device minor number of the file if it is a character or block special file. The argument is a decimal number. The value is a signed int. An implementation should be able to handle at least 64 bit values. Note that the value is signed because POSIX does not specify more than the type should be an int.

filetype

A textual version of the real file type of the file. The following names are used:

unallocated

An unknown file type that may be a result of a unlink(2) operation. This should never happen.

regular

A regular file.

contiguous

A contiguous file. On operating systems or file systems that don't support this file type, it is handled like a regular file.

symlink

A symbolic link to any file type.

directory

A directory.

character special

A character special file.

block special

A block special file.

fifo

A named pipe.

socket

A UNIX domain socket.

mpx character special

A multiplexed character special file.

mpx block special

A multiplexed block special file.

XENIX nsem

A XENIX named semaphore.

XENIX nshd

XENIX shared data.

door

A Solaris door.

eventcount

A UNOS event count.

whiteout

A BSD whiteout directory entry.

sparse

A sparse regular file.

volheader

A volume header.

unknown/bad

Any other unknown file type. This should never happen.

arfiletype

The following additional file types are used in arfiletype:

hardlink

A hard link to any file type.

fsdevmajor

The device major number of the file (from st_dev) as a decimal number. The value is a signed int. An implementation should be able to handle at least 64 bit values. Note that the value is signed because POSIX does not specify more than the type should be an int.

fsdevminor

The device minor number of the file (from st_dev). as a decimal number. The value is a signed int. An implementation should be able to handle at least 64 bit values. Note that the value is signed because POSIX does not specify more than the type should be an int.

gid

The group ID of the group that owns the file. The argument is a decimal number.

gname

The group name of the following file(s) coded in UTF-8 or (if the hdrcharset keyword is present) coded to fit the charset value.

hdrcharset

The name of the character set used to encode the data for the gname, linkpath, path and uname fields in the POSIX.1-2001 extended header records.

The following values are supported for hdrcharset:

ISO-IR 10646 2000 UTF-8

ISO/IEC 10646, UTF-8 encoding

BINARY

None

ino

The inode number from st_ino of the file as decimal number. The value is an unsigned int. An implementation should be able to handle at least 64 bit unsigned values.

linkpath

The name of the linkpath coded in UTF-8 or (if the hdrcharset keyword is present) coded to fit the charset value.

mtime

The time from st_mtime in sub second granularity. A nanosecond granularity is currently supported.

nlink

The link count of the file as decimal number. The value is an unsigned int. An implementation should be able to handle at least 32 bit unsigned values.

path

The name of the path coded in UTF-8 or (if the hdrcharset keyword is present) coded to fit the charset value.

size

The size of the file as decimal number. The size keyword may not refer to the real file size but is related to the size if the file in the archive.

status

The status keyword appears after file data and is used to signal whether the last file has been transferred correctly. The first status keyword that appears after file data, has a number as parameter. If this number is equal to 0, then the file data has been successfully transferred into the archive. If this number is non-zero, it is the errno from the creating system. In addition, each archive is terminated by a status keyword with the argument EOF to singal the end of the archive.

uid

The uid ID of the group that owns the file. The argument is a decimal number.

uname

The user name of the following file(s) coded in UTF-8 or (if the hdrcharset keyword is present) coded to fit the charset value.

VENDOR.keyword

Any keyword that starts with a vendor name in capital letters is reserved for vendor specific extensions by the standard.

## SEE ALSO
star(5).

## BUGS
None currently known.

Mail bugs and suggestions to schilytools@mlists.in-berlin.de or open a ticket at https://codeberg.org/schilytools/schilytools/issues.

The mailing list archive may be found at:

```
https://mlists.in-berlin.de/mailman/listinfo/schilytools-mlists.in-berlin.de.
```

## AUTHORS

```
Joerg Schilling and the schilytools project authors.
```