kdc.conf

title: kdc.conf(5)

summary: Kerberos V5 KDC configuration file

text:
# kdc.conf(5)

## NAME
kdc.conf - Kerberos V5 KDC configuration file

The kdc.conf file supplements krb5.conf(5) for programs which are typically only used on a KDC, such as the krb5kdc(8) and kadmind(8) daemons and the kdb5_util(8) program. Relations documented here may also be specified in krb5.conf; for the KDC programs mentioned, krb5.conf and kdc.conf will be merged into a single configuration profile.

Normally, the kdc.conf file is found in the KDC state directory, /var/lib/kerberos/krb5kdc. You can override the default location by setting the environment variable KRB5_KDC_PROFILE.

Please note that you need to restart the KDC daemon for any configuration changes to take effect.

## STRUCTURE
The kdc.conf file is set up in the same format as the krb5.conf(5) file.

## SECTIONS
The kdc.conf file may contain the following sections:

[kdcdefaults]

Default values for KDC behavior

[realms]

Realm-specific database configuration and settings

[dbdefaults]

Default database settings

[dbmodules]

Per-database settings

[logging]

Controls how Kerberos daemons perform logging

### [kdcdefaults]
Some relations in the [kdcdefaults] section specify default values for realm variables, to be used if the [realms] subsection does not contain a relation for the tag. See the [realms] section for the definitions of these relations.

- host_based_services

- kdc_listen

- kdc_ports

- kdc_tcp_listen

- kdc_tcp_ports

- no_host_referral

- restrict_anonymous_to_tgt

The following [kdcdefaults] variables have no per-realm equivalent:

kdc_max_dgram_reply_size

Specifies the maximum packet size that can be sent over UDP. The default value is 4096 bytes.

kdc_tcp_listen_backlog

(Integer.) Set the size of the listen queue length for the KDC daemon. The value may be limited by OS settings. The default value is 5.

spake_preauth_kdc_challenge

(String.) Specifies the group for a SPAKE optimistic challenge. See the spake_preauth_groups variable in libdefaults for possible values. The default is not to issue an optimistic challenge. (New in release 1.17.)

### [realms]
Each tag in the [realms] section is the name of a Kerberos realm. The value of the tag is a subsection where the relations define KDC parameters for that particular realm. The following example shows how to define one parameter for the ATHENA.MIT.EDU realm:

```
[realms]

    ATHENA.MIT.EDU = {

        max_renewable_life = 7d 0h 0m 0s

    }
```

The following tags may be specified in a [realms] subsection:

acl_file

(String.) Location of the access control list file that kadmind(8) uses to determine which principals are allowed which permissions on the Kerberos database. To operate without an ACL file, set this relation to the empty string with acl_file = "". The default value is /var/lib/kerberos/krb5kdc/kadm5.acl. For more information on Kerberos ACL file see kadm5.acl(5).

database_module

(String.) This relation indicates the name of the configuration section under [dbmodules] for database-specific parameters used by the loadable database library. The default value is the realm name. If this configuration section does not exist, default values will be used for all database parameters.

database_name

(String, deprecated.) This relation specifies the location of the Kerberos database for this realm, if the DB2 module is being used and the [dbmodules] configuration section does not specify a database name. The default value is /var/lib/kerberos/krb5kdc/principal.

default_principal_expiration

(abstime string.) Specifies the default expiration date of principals created in this realm. The default value is 0, which means no expiration date.

default_principal_flags

(Flag string.) Specifies the default attributes of principals created in this realm. The format for this string is a comma-separated list of flags, with '+' before each flag that should be enabled and '-' before each flag that should be disabled. The postdateable, forwardable, tgt-based, renewable, proxiable, dup-skey, allow-tickets, and service flags default to enabled. There are a number of possible flags:

allow-tickets

Enabling this flag means that the KDC will issue tickets for this principal. Disabling this flag essentially deactivates the principal within this realm.

dup-skey

Enabling this flag allows the KDC to issue user-to-user service tickets for this principal.

forwardable

Enabling this flag allows the principal to obtain forwardable tickets.

hwauth

If this flag is enabled, then the principal is required to preauthenticate using a hardware device before receiving any tickets.

no-auth-data-required

Enabling this flag prevents PAC or AD-SIGNEDPATH data from being added to service tickets for the principal.

ok-as-delegate

If this flag is enabled, it hints the client that credentials can and should be delegated when authenticating to the service.

ok-to-auth-as-delegate

Enabling this flag allows the principal to use S4USelf tickets.

postdateable

Enabling this flag allows the principal to obtain postdateable tickets.

preauth

If this flag is enabled on a client principal, then that principal is required to preauthenticate to the KDC before receiving any tickets. On a service principal, enabling this flag means that service tickets for this principal will only be issued to clients with a TGT that has the preauthenticated bit set.

proxiable

Enabling this flag allows the principal to obtain proxy tickets.

pwchange

Enabling this flag forces a password change for this principal.

pwservice

If this flag is enabled, it marks this principal as a password change service. This should only be used in special cases, for example, if a user's password has expired, then the user has to get tickets for that principal without going through the normal password authentication in order to be able to change the password.

renewable

Enabling this flag allows the principal to obtain renewable tickets.

service

Enabling this flag allows the the KDC to issue service tickets for this principal. In release 1.17 and later, user-to-user service tickets are still allowed if the dup-skey flag is set.

tgt-based

Enabling this flag allows a principal to obtain tickets based on a ticket-granting-ticket, rather than repeating the authentication process that was used to obtain the TGT.

dict_file

(String.) Location of the dictionary file containing strings that are not allowed as passwords. The file should contain one string per line, with no additional whitespace. If none is specified or if there is no policy assigned to the principal, no dictionary checks of passwords will be performed.

encrypted_challenge_indicator

(String.) Specifies the authentication indicator value that the KDC asserts into tickets obtained using FAST encrypted challenge pre-authentication. New in 1.16.

host_based_services

(Whitespace- or comma-separated list.) Lists services which will get host-based referral processing even if the server principal is not marked as host-based by the client.

iprop_enable

(Boolean value.) Specifies whether incremental database propagation is enabled. The default value is false.

iprop_ulogsize

(Integer.) Specifies the maximum number of log entries to be retained for incremental propagation. The default value is 1000. Prior to release 1.11, the maximum value was 2500. New in release 1.19.

iprop_master_ulogsize

The name for iprop_ulogsize prior to release 1.19. Its value is used as a fallback if iprop_ulogsize is not specified.

iprop_replica_poll

(Delta time string.) Specifies how often the replica KDC polls for new updates from the primary. The default value is 2m (that is, two minutes). New in release 1.17.

iprop_slave_poll

(Delta time string.) The name for iprop_replica_poll prior to release 1.17. Its value is used as a fallback if iprop_replica_poll is not specified.

iprop_listen

(Whitespace- or comma-separated list.) Specifies the iprop RPC listening addresses and/or ports for the kadmind(8) daemon. Each entry may be an interface address, a port number, or an address and port number separated by a colon. If the address contains colons, enclose it in square brackets. If no address is specified, the wildcard address is used. If kadmind fails to bind to any of the specified addresses, it will fail to start. The default (when iprop_enable is true) is to bind to the wildcard address at the port specified in iprop_port. New in release 1.15.

iprop_port

(Port number.) Specifies the port number to be used for incremental propagation. When iprop_enable is true, this relation is required in the replica KDC configuration file, and this relation or iprop_listen is required in the primary configuration file, as there is no default port number. Port numbers specified in iprop_listen entries will override this port number for the kadmind(8) daemon.

iprop_resync_timeout

(Delta time string.) Specifies the amount of time to wait for a full propagation to complete. This is optional in configuration files, and is used by replica KDCs only. The default value is 5 minutes (5m). New in release 1.11.

iprop_logfile

(File name.) Specifies where the update log file for the realm database is to be stored. The default is to use the database_name entry from the realms section of the krb5 config file, with .ulog appended. (NOTE: If database_name isn't specified in the realms section, perhaps because the LDAP database back end is being used, or the file name is specified in the [dbmodules] section, then the hard-coded default for database_name is used. Determination of the iprop_logfile default value will not use values from the [dbmodules] section.)

kadmind_listen

(Whitespace- or comma-separated list.) Specifies the kadmin RPC listening addresses and/or ports for the kadmind(8) daemon. Each entry may be an interface address, a port number, or an address and port number separated by a colon. If the address contains colons, enclose it in square brackets. If no address is specified, the wildcard address is used. If kadmind fails to bind to any of the specified addresses, it will fail to start. The default is to bind to the wildcard address at the port specified in kadmind_port, or the standard kadmin port (749). New in release 1.15.

kadmind_port

(Port number.) Specifies the port on which the kadmind(8) daemon is to listen for this realm. Port numbers specified in kadmind_listen entries will override this port number. The assigned port for kadmind is 749, which is used by default.

key_stash_file

(String.) Specifies the location where the master key has been stored (via kdb5_util stash). The default is /var/lib/kerberos/krb5kdc/.k5.REALM, where REALM is the Kerberos realm.

kdc_listen

(Whitespace- or comma-separated list.) Specifies the UDP listening addresses and/or ports for the krb5kdc(8) daemon. Each entry may be an interface address, a port number, or an address and port number separated by a colon. If the address contains colons, enclose it in square brackets. If no address is specified, the wildcard address is used. If no port is specified, the standard port (88) is used. If the KDC daemon fails to bind to any of the specified addresses, it will fail to start. The default is to bind to the wildcard address on the standard port. New in release 1.15.

kdc_ports

(Whitespace- or comma-separated list, deprecated.) Prior to release 1.15, this relation lists the ports for the krb5kdc(8) daemon to listen on for UDP requests. In release 1.15 and later, it has the same meaning as kdc_listen if that relation is not defined.

kdc_tcp_listen

(Whitespace- or comma-separated list.) Specifies the TCP listening addresses and/or ports for the krb5kdc(8) daemon. Each entry may be an interface address, a port number, or an address and port number separated by a colon. If the address contains colons, enclose it in square brackets. If no address is specified, the wildcard address is used. If no port is specified, the standard port (88) is used. To disable listening on TCP, set this relation to the empty string with kdc_tcp_listen = "". If the KDC daemon fails to bind to any of the specified addresses, it will fail to start. The default is to bind to the wildcard address on the standard port. New in release 1.15.

kdc_tcp_ports

(Whitespace- or comma-separated list, deprecated.) Prior to release 1.15, this relation lists the ports for the krb5kdc(8) daemon to listen on for UDP requests. In release 1.15 and later, it has the same meaning as kdc_tcp_listen if that relation is not defined.

kpasswd_listen

(Comma-separated list.) Specifies the kpasswd listening addresses and/or ports for the kadmind(8) daemon. Each entry may be an interface address, a port number, or an address and port number separated by a colon. If the address contains colons, enclose it in square brackets. If no address is specified, the wildcard address is used. If kadmind fails to bind to any of the specified addresses, it will fail to start. The default is to bind to the wildcard address at the port specified in kpasswd_port, or the standard kpasswd port (464). New in release 1.15.

kpasswd_port

(Port number.) Specifies the port on which the kadmind(8) daemon is to listen for password change requests for this realm. Port numbers specified in kpasswd_listen entries will override this port number. The assigned port for password change requests is 464, which is used by default.

master_key_name

(String.) Specifies the name of the principal associated with the master key. The default is K/M.

master_key_type

(Key type string.) Specifies the master key's key type. The default value for this is aes256-cts-hmac-sha1-96. For a list of all possible values, see Encryption types.

max_life

(duration string.) Specifies the maximum time period for which a ticket may be valid in this realm. The default value is 24 hours.

max_renewable_life

(duration string.) Specifies the maximum time period during which a valid ticket may be renewed in this realm. The default value is 0.

no_host_referral

(Whitespace- or comma-separated list.) Lists services to block from getting host-based referral processing, even if the client marks the server principal as host-based or the service is also listed in host_based_services. no_host_referral = * will disable referral processing altogether.

reject_bad_transit

(Boolean value.) If set to true, the KDC will check the list of transited realms for cross-realm tickets against the transit path computed from the realm names and the capaths section of its krb5.conf(5) file; if the path in the ticket to be issued contains any realms not in the computed path, the ticket will not be issued, and an error will be returned to the client instead. If this value is set to false, such tickets will be issued anyways, and it will be left up to the application server to validate the realm transit path. If the disable-transited-check flag is set in the incoming request, this check is not performed at all. Having the reject_bad_transit option will cause such ticket requests to be rejected always.

This transit path checking and config file option currently apply only to TGS requests.

The default value is true.

restrict_anonymous_to_tgt

(Boolean value.) If set to true, the KDC will reject ticket requests from anonymous principals to service principals other than the realm's ticket-granting service. This option allows anonymous PKINIT to be enabled for use as FAST armor tickets without allowing anonymous authentication to services. The default value is false. New in release 1.9.

spake_preauth_indicator

(String.) Specifies an authentication indicator value that the KDC asserts into tickets obtained using SPAKE pre-authentication. The default is not to add any indicators. This option may be specified multiple times. New in release 1.17.

supported_enctypes

(List of key:salt strings.) Specifies the default key/salt combinations of principals for this realm. Any principals created through kadmin(1) will have keys of these types. The default value for this tag is aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal. For lists of possible values, see Keysalt lists.

### [dbdefaults]
The [dbdefaults] section specifies default values for some database parameters, to be used if the [dbmodules] subsection does not contain a relation for the tag. See the [dbmodules] section for the definitions of these relations.

- ldap_kerberos_container_dn

- ldap_kdc_dn

- ldap_kdc_sasl_authcid

- ldap_kdc_sasl_authzid

- ldap_kdc_sasl_mech

- ldap_kdc_sasl_realm

- ldap_kadmind_dn

- ldap_kadmind_sasl_authcid

- ldap_kadmind_sasl_authzid

- ldap_kadmind_sasl_mech

- ldap_kadmind_sasl_realm

- ldap_service_password_file

- ldap_conns_per_server

### [dbmodules]
The [dbmodules] section contains parameters used by the KDC database library and database modules. Each tag in the [dbmodules] section is the name of a Kerberos realm or a section name specified by a realm's database_module parameter. The following example shows how to define one database parameter for the ATHENA.MIT.EDU realm:

```
[dbmodules]

    ATHENA.MIT.EDU = {

        disable_last_success = true

    }
```

The following tags may be specified in a [dbmodules] subsection:

database_name

This DB2-specific tag indicates the location of the database in the filesystem. The default is /var/lib/kerberos/krb5kdc/principal.

db_library

This tag indicates the name of the loadable database module. The value should be db2 for the DB2 module, klmdb for the LMDB module, or kldap for the LDAP module.

disable_last_success

If set to true, suppresses KDC updates to the "Last successful authentication" field of principal entries requiring preauthentication. Setting this flag may improve performance. (Principal entries which do not require preauthentication never update the "Last successful authentication" field.). First introduced in release 1.9.

disable_lockout

If set to true, suppresses KDC updates to the "Last failed authentication" and "Failed password attempts" fields of principal entries requiring preauthentication. Setting this flag may improve performance, but also disables account lockout. First introduced in release 1.9.

ldap_conns_per_server

This LDAP-specific tag indicates the number of connections to be maintained per LDAP server.

ldap_kdc_dn and ldap_kadmind_dn

These LDAP-specific tags indicate the default DN for binding to the LDAP server. The krb5kdc(8) daemon uses ldap_kdc_dn, while the kadmind(8) daemon and other administrative programs use ldap_kadmind_dn. The kadmind DN must have the rights to read and write the Kerberos data in the LDAP database. The KDC DN must have the same rights, unless disable_lockout and disable_last_success are true, in which case it only needs to have rights to read the Kerberos data. These tags are ignored if a SASL mechanism is set with ldap_kdc_sasl_mech or ldap_kadmind_sasl_mech.

ldap_kdc_sasl_mech and ldap_kadmind_sasl_mech

These LDAP-specific tags specify the SASL mechanism (such as EXTERNAL) to use when binding to the LDAP server. New in release 1.13.

ldap_kdc_sasl_authcid and ldap_kadmind_sasl_authcid

These LDAP-specific tags specify the SASL authentication identity to use when binding to the LDAP server. Not all SASL mechanisms require an authentication identity. If the SASL mechanism requires a secret (such as the password for DIGEST-MD5), these tags also determine the name within the ldap_service_password_file where the secret is stashed. New in release 1.13.

ldap_kdc_sasl_authzid and ldap_kadmind_sasl_authzid

These LDAP-specific tags specify the SASL authorization identity to use when binding to the LDAP server. In most circumstances they do not need to be specified. New in release 1.13.

ldap_kdc_sasl_realm and ldap_kadmind_sasl_realm

These LDAP-specific tags specify the SASL realm to use when binding to the LDAP server. In most circumstances they do not need to be set. New in release 1.13.

ldap_kerberos_container_dn

This LDAP-specific tag indicates the DN of the container object where the realm objects will be located.

ldap_servers

This LDAP-specific tag indicates the list of LDAP servers that the Kerberos servers can connect to. The list of LDAP servers is whitespace-separated. The LDAP server is specified by a LDAP URI. It is recommended to use ldapi: or ldaps: URLs to connect to the LDAP server.

ldap_service_password_file

This LDAP-specific tag indicates the file containing the stashed passwords (created by kdb5_ldap_util stashsrvpw) for the ldap_kdc_dn and ldap_kadmind_dn objects, or for the ldap_kdc_sasl_authcid or ldap_kadmind_sasl_authcid names for SASL authentication. This file must be kept secure.

mapsize

This LMDB-specific tag indicates the maximum size of the two database environments in megabytes. The default value is 128. Increase this value to address "Environment mapsize limit reached" errors. New in release 1.17.

max_readers

This LMDB-specific tag indicates the maximum number of concurrent reading processes for the databases. The default value is 128. New in release 1.17.

nosync

This LMDB-specific tag can be set to improve the throughput of kadmind and other administrative agents, at the expense of durability (recent database changes may not survive a power outage or other sudden reboot). It does not affect the throughput of the KDC. The default value is false. New in release 1.17.

unlockiter

If set to true, this DB2-specific tag causes iteration operations to release the database lock while processing each principal. Setting this flag to true can prevent extended blocking of KDC or kadmin operations when dumps of large databases are in progress. First introduced in release 1.13.

The following tag may be specified directly in the [dbmodules] section to control where database modules are loaded from:

db_module_dir

This tag controls where the plugin system looks for database modules. The value should be an absolute path.

### [logging]
The [logging] section indicates how krb5kdc(8) and kadmind(8) perform logging. It may contain the following relations:

admin_server

Specifies how kadmind(8) performs logging.

kdc

Specifies how krb5kdc(8) performs logging.

default

Specifies how either daemon performs logging in the absence of relations specific to the daemon.

debug

(Boolean value.) Specifies whether debugging messages are included in log outputs other than SYSLOG. Debugging messages are always included in the system log output because syslog performs its own priority filtering. The default value is false. New in release 1.15.

Logging specifications may have the following forms:

FILE=filename or FILE:filename

This value causes the daemon's logging messages to go to the filename. If the = form is used, the file is overwritten. If the : form is used, the file is appended to.

STDERR

This value causes the daemon's logging messages to go to its standard error stream.

CONSOLE

This value causes the daemon's logging messages to go to the console, if the system supports it.

DEVICE=<devicename>

This causes the daemon's logging messages to go to the specified device.

SYSLOG[:severity[:facility]]

This causes the daemon's logging messages to go to the system log. For backward compatibility, a severity argument may be specified, and must be specified in order to specify a facility. This argument will be ignored.

The facility argument specifies the facility under which the messages are logged. This may be any of the following facilities supported by the syslog(3) call minus the LOG_ prefix: KERN, USER, MAIL, DAEMON, AUTH, LPR, NEWS, UUCP, CRON, and LOCAL0 through LOCAL7. If no facility is specified, the default is AUTH.

In the following example, the logging messages from the KDC will go to the console and to the system log under the facility LOG_DAEMON, and the logging messages from the administrative server will be appended to the file /var/adm/kadmin.log and sent to the device /dev/tty04.

```
[logging]

    kdc = CONSOLE

    kdc = SYSLOG:INFO:DAEMON

    admin_server = FILE:/var/adm/kadmin.log

    admin_server = DEVICE=/dev/tty04
```

If no logging specification is given, the default is to use syslog. To disable logging entirely, specify default = DEVICE=/dev/null.

### [otp]
Each subsection of [otp] is the name of an OTP token type. The tags within the subsection define the configuration required to forward a One Time Password request to a RADIUS server.

For each token type, the following tags may be specified:

server

This is the server to send the RADIUS request to. It can be a hostname with optional port, an ip address with optional port, or a Unix domain socket address. The default is /var/lib/kerberos/krb5kdc/<name>.socket.

secret

This tag indicates a filename (which may be relative to /var/lib/kerberos/krb5kdc) containing the secret used to encrypt the RADIUS packets. The secret should appear in the first line of the file by itself; leading and trailing whitespace on the line will be removed. If the value of server is a Unix domain socket address, this tag is optional, and an empty secret will be used if it is not specified. Otherwise, this tag is required.

timeout

An integer which specifies the time in seconds during which the KDC should attempt to contact the RADIUS server. This tag is the total time across all retries and should be less than the time which an OTP value remains valid for. The default is 5 seconds.

retries

This tag specifies the number of retries to make to the RADIUS server. The default is 3 retries (4 tries).

strip_realm

If this tag is true, the principal without the realm will be passed to the RADIUS server. Otherwise, the realm will be included. The default value is true.

indicator

This tag specifies an authentication indicator to be included in the ticket if this token type is used to authenticate. This option may be specified multiple times. (New in release 1.14.)

In the following example, requests are sent to a remote server via UDP:

```
[otp]

    MyRemoteTokenType = {

        server = radius.mydomain.com:1812

        secret = SEmfiajf42$

        timeout = 15

        retries = 5

        strip_realm = true

    }
```

An implicit default token type named DEFAULT is defined for when the per-principal configuration does not specify a token type. Its configuration is shown below. You may override this token type to something applicable for your situation:

```
[otp]

    DEFAULT = {

        strip_realm = false

    }
```

## PKINIT OPTIONS
NOTE:

The following are pkinit-specific options. These values may be specified in [kdcdefaults] as global defaults, or within a realm-specific subsection of [realms]. Also note that a realm-specific value over-rides, does not add to, a generic [kdcdefaults] specification. The search order is:

1.

realm-specific subsection of [realms]:

```
[realms]

    EXAMPLE.COM = {

        pkinit_anchors = FILE:/usr/local/example.com.crt

    }
```

2.

generic value in the [kdcdefaults] section:

```
[kdcdefaults]

    pkinit_anchors = DIR:/usr/local/generic_trusted_cas/
```

For information about the syntax of some of these options, see Specifying PKINIT identity information in krb5.conf(5).

pkinit_anchors

Specifies the location of trusted anchor (root) certificates which the KDC trusts to sign client certificates. This option is required if pkinit is to be supported by the KDC. This option may be specified multiple times.

pkinit_dh_min_bits

Specifies the minimum number of bits the KDC is willing to accept for a client's Diffie-Hellman key. The default is 2048.

pkinit_allow_upn

Specifies that the KDC is willing to accept client certificates with the Microsoft UserPrincipalName (UPN) Subject Alternative Name (SAN). This means the KDC accepts the binding of the UPN in the certificate to the Kerberos principal name. The default value is false. Without this option, the KDC will only accept certificates with the id-pkinit-san as defined in RFC 4556. There is currently no option to disable SAN checking in the KDC.

pkinit_eku_checking

This option specifies what Extended Key Usage (EKU) values the KDC is willing to accept in client certificates. The values recognized in the kdc.conf file are:

kpClientAuth

This is the default value and specifies that client certificates must have the id-pkinit-KPClientAuth EKU as defined in RFC 4556.

scLogin

If scLogin is specified, client certificates with the Microsoft Smart Card Login EKU (id-ms-kp-sc-logon) will be accepted.

none

If none is specified, then client certificates will not be checked to verify they have an acceptable EKU. The use of this option is not recommended.

pkinit_identity

Specifies the location of the KDC's X.509 identity information. This option is required if pkinit is to be supported by the KDC.

pkinit_indicator

Specifies an authentication indicator to include in the ticket if pkinit is used to authenticate. This option may be specified multiple times. (New in release 1.14.)

pkinit_pool

Specifies the location of intermediate certificates which may be used by the KDC to complete the trust chain between a client's certificate and a trusted anchor. This option may be specified multiple times.

pkinit_revoke

Specifies the location of Certificate Revocation List (CRL) information to be used by the KDC when verifying the validity of client certificates. This option may be specified multiple times.

pkinit_require_crl_checking

The default certificate verification process will always check the available revocation information to see if a certificate has been revoked. If a match is found for the certificate in a CRL, verification fails. If the certificate being verified is not listed in a CRL, or there is no CRL present for its issuing CA, and pkinit_require_crl_checking is false, then verification succeeds. However, if pkinit_require_crl_checking is true and there is no CRL information available for the issuing CA, then verification fails.

pkinit_require_crl_checking should be set to true if the policy is such that up-to-date CRLs must be present for every CA.

pkinit_require_freshness

Specifies whether to require clients to include a freshness token in PKINIT requests. The default value is false. (New in release 1.17.)

## ENCRYPTION TYPES
Any tag in the configuration files which requires a list of encryption types can be set to some combination of the following strings. Encryption types marked as "weak" and "deprecated" are available for compatibility but not recommended for use.

des3-cbc-raw

Triple DES cbc mode raw (weak)

des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd

Triple DES cbc mode with HMAC/sha1 (deprecated)

aes256-cts-hmac-sha1-96 aes256-cts aes256-sha1

AES-256 CTS mode with 96-bit SHA-1 HMAC

aes128-cts-hmac-sha1-96 aes128-cts aes128-sha1

AES-128 CTS mode with 96-bit SHA-1 HMAC

aes256-cts-hmac-sha384-192 aes256-sha2

AES-256 CTS mode with 192-bit SHA-384 HMAC

aes128-cts-hmac-sha256-128 aes128-sha2

AES-128 CTS mode with 128-bit SHA-256 HMAC

arcfour-hmac rc4-hmac arcfour-hmac-md5

RC4 with HMAC/MD5 (deprecated)

arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp

Exportable RC4 with HMAC/MD5 (weak)

camellia256-cts-cmac camellia256-cts

Camellia-256 CTS mode with CMAC

camellia128-cts-cmac camellia128-cts

Camellia-128 CTS mode with CMAC

des3

The triple DES family: des3-cbc-sha1

aes

The AES family: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha384-192, and aes128-cts-hmac-sha256-128

rc4

The RC4 family: arcfour-hmac

camellia

The Camellia family: camellia256-cts-cmac and camellia128-cts-cmac

The string DEFAULT can be used to refer to the default set of types for the variable in question. Types or families can be removed from the current list by prefixing them with a minus sign ("-"). Types or families can be prefixed with a plus sign ("+") for symmetry; it has the same meaning as just listing the type or family. For example, "DEFAULT -rc4" would be the default set of encryption types with RC4 types removed, and "des3 DEFAULT" would be the default set of encryption types with triple DES types moved to the front.

While aes128-cts and aes256-cts are supported for all Kerberos operations, they are not supported by very old versions of our GSSAPI implementation (krb5-1.3.1 and earlier). Services running versions of krb5 without AES support must not be given keys of these encryption types in the KDC database.

The aes128-sha2 and aes256-sha2 encryption types are new in release 1.15. Services running versions of krb5 without support for these newer encryption types must not be given keys of these encryption types in the KDC database.

## KEYSALT LISTS
Kerberos keys for users are usually derived from passwords. Kerberos commands and configuration parameters that affect generation of keys take lists of enctype-salttype ("keysalt") pairs, known as keysalt lists. Each keysalt pair is an enctype name followed by a salttype name, in the format enc:salt. Individual keysalt list members are separated by comma (",") characters or space characters. For example:

```
kadmin -e aes256-cts:normal,aes128-cts:normal
```

would start up kadmin so that by default it would generate password-derived keys for the aes256-cts and aes128-cts encryption types, using a normal salt.

To ensure that people who happen to pick the same password do not have the same key, Kerberos 5 incorporates more information into the key using something called a salt. The supported salt types are as follows:

normal

default for Kerberos Version 5

norealm

same as the default, without using realm information

onlyrealm

uses only realm information as the salt

special

generate a random salt

## SAMPLE KDC.CONF FILE
Here's an example of a kdc.conf file:

```
[kdcdefaults]

    kdc_listen = 88

    kdc_tcp_listen = 88
[realms]

    ATHENA.MIT.EDU = {

        kadmind_port = 749

        max_life = 12h 0m 0s

        max_renewable_life = 7d 0h 0m 0s

        master_key_type = aes256-cts-hmac-sha1-96

        supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal

        database_module = openldap_ldapconf

    }
[logging]

    kdc = FILE:/usr/local/var/krb5kdc/kdc.log

    admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log
[dbdefaults]

    ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu
[dbmodules]

    openldap_ldapconf = {

        db_library = kldap

        disable_last_success = true

        ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"

            # this object needs to have read rights on

            # the realm container and principal subtrees

        ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"

            # this object needs to have read and write rights on

            # the realm container and principal subtrees

        ldap_service_password_file = /etc/kerberos/service.keyfile

        ldap_servers = ldaps://kerberos.mit.edu

        ldap_conns_per_server = 5

    }
```

## FILES
/var/lib/kerberos/krb5kdc/kdc.conf

## SEE ALSO
krb5.conf(5), krb5kdc(8), kadm5.acl(5)

## AUTHOR
MIT

## COPYRIGHT
1985-2022, MIT


title: k5identity(5)

text:
# k5identity(5)

## NAME
k5identity - Kerberos V5 client principal selection rules

## DESCRIPTION
The .k5identity file, which resides in a user's home directory, contains a list of rules for selecting a client principals based on the server being accessed. These rules are used to choose a credential cache within the cache collection when possible.

Blank lines and lines beginning with # are ignored. Each line has the form:

principal field=value ...

If the server principal meets all of the field constraints, then principal is chosen as the client principal. The following fields are recognized:

realm

If the realm of the server principal is known, it is matched against value, which may be a pattern using shell wildcards. For host-based server principals, the realm will generally only be known if there is a domain_realm section in krb5.conf(5) with a mapping for the hostname.

service

If the server principal is a host-based principal, its service component is matched against value, which may be a pattern using shell wildcards.

host

If the server principal is a host-based principal, its hostname component is converted to lower case and matched against value, which may be a pattern using shell wildcards. If the server principal matches the constraints of multiple lines in the .k5identity file, the principal from the first matching line is used. If no line matches, credentials will be selected some other way, such as the realm heuristic or the current primary cache.

## EXAMPLE
The following example .k5identity file selects the client principal alice@KRBTEST.COM if the server principal is within that realm, the principal alice/root@EXAMPLE.COM if the server host is within a servers subdomain, and the principal alice/mail@EXAMPLE.COM when accessing the IMAP service on mail.example.com:

```
alice@KRBTEST.COM       realm=KRBTEST.COM
alice/root@EXAMPLE.COM  host=*.servers.example.com
alice/mail@EXAMPLE.COM  host=mail.example.com service=imap
```

## SEE ALSO
kerberos(1), krb5.conf(5)

## AUTHOR
MIT

## COPYRIGHT
1985-2022, MIT


title: k5login(5)

summary: Kerberos V5 acl file for host access

text:
# k5login(5)

## NAME
k5login - Kerberos V5 acl file for host access

## DESCRIPTION
The .k5login file, which resides in a user's home directory, contains a list of the Kerberos principals. Anyone with valid tickets for a principal in the file is allowed host access with the UID of the user in whose home directory the file resides. One common use is to place a .k5login file in root's home directory, thereby granting system administrators remote root access to the host via Kerberos.

## EXAMPLES
Suppose the user alice had a .k5login file in her home directory containing just the following line:

```
bob@FOOBAR.ORG
```

This would allow bob to use Kerberos network applications, such as ssh(1), to access alice's account, using bob's Kerberos tickets. In a default configuration (with k5login_authoritative set to true in krb5.conf(5)), this .k5login file would not let alice use those network applications to access her account, since she is not listed! With no .k5login file, or with k5login_authoritative set to false, a default rule would permit the principal alice in the machine's default realm to access the alice account.

Let us further suppose that alice is a system administrator. Alice and the other system administrators would have their principals in root's .k5login file on each host:

```
alice@BLEEP.COM
joeadmin/root@BLEEP.COM
```

This would allow either system administrator to log in to these hosts using their Kerberos tickets instead of having to type the root password. Note that because bob retains the Kerberos tickets for his own principal, bob@FOOBAR.ORG, he would not have any of the privileges that require alice's tickets, such as root access to any of the site's hosts, or the ability to change alice's password.

## SEE ALSO
kerberos(1)

## AUTHOR
MIT

## COPYRIGHT
1985-2022, MIT


kyua.conf

package: kyua

title: kyua.conf(5)

summary: Configuration file for the kyua tool

text:
# kyua.conf(5)

## NAME
kyua.conf — Configuration file for the kyua tool

## SYNOPSIS
syntax(int version);

Variables: architecture, platform, test_suites, unprivileged_user.

## DESCRIPTION
The configuration of Kyua is a simple collection of key/value pairs called configuration variables. There are configuration variables that have a special meaning to the runtime engine implemented by kyua(1), and there are variables that only have meaning in the context of particular test suites.

Configuration files are Lua scripts. In their most basic form, their whole purpose is to assign values to variables, but the user has the freedom to implement any logic he desires to compute such values.

### File versioning
Every kyua.conf file starts with a call to syntax(int version). This call determines the specific schema used by the file so that future backwards-incompatible modifications to the file can be introduced.

Any new kyua.conf file should set version to ‘2’.

### Runtime configuration variables
The following variables are internally recognized by kyua(1):

architecture

Name of the system architecture (aka processor type).

parallelism

Maximum number of test cases to execute concurrently.

platform

Name of the system platform (aka machine type).

unprivileged_user

Name or UID of the unprivileged user. If set, the given user must exist in the system and his privileges will be used to run test cases that need regular privileges when kyua(1) is executed as root.

### Test-suite configuration variables
Each test suite is able to recognize arbitrary configuration variables, and their type and meaning is specific to the test suite. Because the existence and naming of these variables depends on every test suite, this manual page cannot detail them; please refer to the documentation of the test suite you are working with for more details on this topic.

Test-suite specific configuration variables are defined inside the test_suites dictionary. The general syntax is:

```
test_suites.<test_suite_name>.<variable_name> = <value>
```

where test_suite_name is the name of the test suite, variable_name is the name of the variable to set, and value is a value. The value can be a string, an integer or a boolean.

## FILES
/usr/share/kyua/examples/kyua.conf

Sample configuration file.

## EXAMPLES
The following kyua.conf shows a simple configuration file that overrides a bunch of the built-in kyua(1) configuration variables:

```
syntax(2)

architecture = 'x86_64'
platform = 'amd64'
```

The following is a more complex example that introduces the definition of per-test suite configuration variables:

```
syntax(2)

-- Assign built-in variables.
unprivileged_user = '_tests'

-- Assign test-suite variables.  All of these must be strings.
test_suites.NetBSD.file_systems = 'ffs ext2fs'
test_suites.X11.graphics_driver = 'vesa'
```

## SEE ALSO
kyua(1)


kyuafile

title: kyuafile(5)

summary: Test suite description files

text:
# kyuafile(5)

## NAME
Kyuafile — Test suite description files

## SYNOPSIS
atf_test_program(string name, [string metadata]);

current_kyuafile();

fs.basename(string path);

fs.dirname(string path);

fs.exists(string path);

fs.files(string path);

fs.is_absolute(string path);

fs.join(string path, string path);

include(string path);

plain_test_program(string name, [string metadata]);

syntax(int version);

tap_test_program(string name, [string metadata]);

test_suite(string name);

## DESCRIPTION
A test suite is a collection of test programs and is represented by a hierarchical layout of test binaries on the file system. Any subtree of the file system can represent a test suite, provided that it includes one or more Kyuafiles, which are the test suite definition files.

A Kyuafile is a Lua script whose purpose is to describe the structure of the test suite it belongs to. To do so, the script has access to a collection of special functions provided by kyua(1) as described in Helper functions.

### File versioning
Every Kyuafile file starts with a call to syntax(int version). This call determines the specific schema used by the file so that future backwards-incompatible modifications to the file can be introduced.

Any new Kyuafile file should set version to ‘2’.

### Test suite definition
If the Kyuafile registers any test programs, the Kyuafile must define the name of the test suite the test programs belong to by using the test_suite() function at the very beginning of the file.

The test suite name provided in the test_suite() call tells kyua(1) which set of configuration variables from kyua.conf(5) to pass to the test programs at run time.

### Test program registration
A Kyuafile can register test programs by means of a variety of *_test_program() functions, all of which take the name of a test program and a set of optional metadata properties that describe such test program.

The test programs to be registered must live in the current directory; in other words, the various *_test_program() calls cannot reference test programs in other directories. The rationale for this is to force all Kyuafile files to be self-contained, and to simplify their internal representation.

ATF test programs are those that use the atf(7) libraries. They can be registered with the atf_test_program() table constructor. This function takes the name of the test program and a collection of optional metadata settings for all the test cases in the test program. Any metadata properties defined by the test cases themselves override the metadata values defined here.

Plain test programs are those that return 0 on success and non-0 on failure; in general, most test programs (even those that use fancy unit-testing libraries) behave this way and thus also qualify as plain test programs. They can be registered with the plain_test_program() table constructor. This function takes the name of the test program, an optional test_suite name that overrides the global test suite name, and a collection of optional metadata settings for the test program.

TAP test programs are those that implement the Test Anything Protocol. They can be registered with the tap_test_program() table constructor. This function takes the name of the test program and a collection of optional metadata settings for the test program.

The following metadata properties can be passed to any test program definition:

allowed_architectures

Whitespace-separated list of machine architecture names allowed by the test. If empty or not defined, the test is allowed to run on any machine architecture.

allowed_platforms

Whitespace-separated list of machine platform names allowed by the test. If empty or not defined, the test is allowed to run on any machine platform.

custom.NAME

Custom variable defined by the test where ‘NAME’ denotes the name of the variable. These variables are useful to tag your tests with information specific to your project. The values of such variables are propagated all the way from the tests to the results files and later to any generated reports. Note that if the name happens to have dashes or any other special characters in it, you will have to use a special Lua syntax to define the property. Refer to the EXAMPLES section below for clarification.

description

Textual description of the test.

is_exclusive

If true, indicates that this test program cannot be executed along any other programs at the same time. Test programs that affect global system state, such as those that modify the value of a sysctl(8) setting, must set themselves as exclusive to prevent failures due to race conditions. Defaults to false.

required_configs

Whitespace-separated list of configuration variables that the test requires to be defined before it can run.

required_disk_space

Amount of available disk space that the test needs to run successfully.

required_files

Whitespace-separated list of paths that the test requires to exist before it can run.

required_memory

Amount of physical memory that the test needs to run successfully.

required_programs

Whitespace-separated list of basenames or absolute paths pointing to executable binaries that the test requires to exist before it can run.

required_user

If empty, the test has no restrictions on the calling user for it to run. If set to ‘unprivileged’, the test needs to not run as root. If set to ‘root’, the test must run as root.

timeout

Amount of seconds that the test is allowed to execute before being killed.

### Recursion
To reference test programs in another subdirectory, a different Kyuafile must be created in that directory and it must be included into the original Kyuafile by means of the include() function.

include() may only be called with a relative path and with at most one directory component. This is by design: Kyua uses the file system structure as the layout of the test suite definition. Therefore, each subdirectory in a test suite must include its own Kyuafile and each Kyuafile can only descend into the Kyuafiles of immediate subdirectories.

If you need to source a Kyuafile located in disjoint parts of your file system namespace, you will have to create a ‘shadow tree’ using symbolic links and possibly helper Kyuafiles to plug the various subdirectories together. See the EXAMPLES section below for details.

Note that each file is processed in its own Lua environment: there is no mechanism to pass state from one file to the other. The reason for this is that there is no such thing as a “top-level” Kyuafile in a test suite: the user has to be able to run the test suite from any directory in a given hierarchy, and this execution must not depend on files that live in parent directories.

### Top-level Kyuafile
Every system has a top directory into which test suites get installed. The default is /usr/libexec/kyua. Within this directory live test suites, each of which is in an independent subdirectory. Each subdirectory can be provided separately by independent third-party packages.

Kyua allows running all the installed test suites at once in order to provide comprehensive cross-component reports. In order to do this, there is a special file in the top directory that knows how to inspect the subdirectories in search for other Kyuafiles and include them.

The FILES section includes more details on where this file lives.

### Helper functions
The ‘base’, ‘string’, and ‘table’ Lua modules are fully available in the context of a Kyuafile.

The following extra functions are provided by Kyua:

string current_kyuafile()

Returns the absolute path to the current Kyuafile.

string fs.basename(string path)

Returns the last component of the given path.

string fs.dirname(string path)

Returns the given path without its last component or a dot if the path has a single component.

bool fs.exists(string path)

Checks if the given path exists. If the path is not absolute, it is relative to the directory containing the Kyuafile in which the call to this function occurs.

iterator fs.files(string path)

Opens a directory for scanning of its entries. The returned iterator yields an entry on each call, and the entry is simply the filename. If the path is not absolute, it is relative to the directory containing the Kyuafile in which the call to this function occurs.

is_absolute fs.is_absolute(string path)

Returns true if the given path is absolute; false otherwise.

join fs.join(string path, string path)

Concatenates the two paths. The second path cannot be absolute.

## FILES
/usr/libexec/kyua/Kyuafile.

Top-level Kyuafile for the current system.

/usr/share/kyua/examples/Kyuafile.top.

Sample file to serve as a top-level Kyuafile.

## EXAMPLES
The following Kyuafile is the simplest you can define. It provides a test suite definition and registers a couple of different test programs using different interfaces:

```
syntax(2)

test_suite('first')

atf_test_program{name='integration_test'}
plain_test_program{name='legacy_test'}
```

The following example is a bit more elaborate. It introduces some metadata properties to the test program definitions and recurses into a couple of subdirectories:

```
syntax(2)

test_suite('second')

plain_test_program{name='legacy_test',
                   allowed_architectures='amd64 i386',
                   required_files='/bin/ls',
                   timeout=30}

tap_test_program{name='privileged_test',
                 required_user='root'}

include('module-1/Kyuafile')
include('module-2/Kyuafile')
```

The syntax to define custom properties may be not obvious if their names have any characters that make the property name not be a valid Lua identifier. Dashes are just one example. To set such properties, do something like this:

```
syntax(2)

test_suite('FreeBSD')

plain_test_program{name='the_test',
                   ['custom.FreeBSD-Bug-Id']='category/12345'}
```

### Connecting disjoint test suites
Now suppose you had various test suites on your file system and you would like to connect them together so that they could be executed and treated as a single unit. The test suites we would like to connect live under /usr/tests, /usr/local/tests and ~/local/tests.

We cannot create a Kyuafile that references these because the include() directive does not support absolute paths. Instead, what we can do is create a shadow tree using symbolic links:

```
$ mkdir ~/everything
$ ln -s /usr/tests ~/everything/system-tests
$ ln -s /usr/local/tests ~/everything/local-tests
$ ln -s ~/local/tests ~/everything/home-tests
```

And then we create an ~/everything/Kyuafile file to drive the execution of the integrated test suite:

```
syntax(2)

test_suite('test-all-the-things')

include('system-tests/Kyuafile')
include('local-tests/Kyuafile')
include('home-tests/Kyuafile')
```

Or, simply, you could reuse the sample top-level Kyuafile to avoid having to manually craft the list of directories into which to recurse:

```
$ cp /usr/share/kyua/examples/Kyuafile.top ~/everything/Kyuafile
```

## SEE ALSO
kyua(1)


lcdproc-config

package: lcdproc

title: lcdproc-config(5)

text:
# lcdproc-config(5)

## NAME
lcdproc-config - format of LCDproc's configuration files

## SYNTAX
The syntax for LCDproc's configuration files is INI-file style.

They are 8-bit text files divided into sections, each containing zero or more key-value pairs. Sections are introduced by section labels which start with '[' and end with ']', and key-value pairs consist of a key name, a '=' sign and a value each.

Key names are sequences of non-space characters, not starting with '[' and not containing '=' or '\n', while values are shell like strings. I.e. they are either simple sequences of non-space characters, or double quoted-strings with C-style syntax (except the missing support for '\NNN' and '\xNN' escape sequences) or or a mix of both of these forms.

Section labels and key names are case-insensitive and may occur more than once. Keys of duplicate sections will be merged into one section, while the values of duplicate keys in a section will be appended to form an array of values for this key. (In the program, all values of a key can be retrieved individually)

Spaces around section labels, keys, and values are ignored. Lines starting with ';' or '#' are considered comments and ignored too.

While all of the above is quite common to almost all INI-file implementations, there are a few special features that make LCDproc's config files special:

- Section labels may contain any character except ']', '\n' or '\0'. However, all characters are interpreted literally (i.e. neither quoting, nor escaping done).

- Key names may contain any non-space character except '\n' or '\0'. However, all characters are interpreted literally (i.e. neither quoting, nor escaping done).

- Comments are allowed after section labels and key value pairs

- Values may be a mix of quoted and unquoted strings similar as strings are interpreted in the shell. E.g. the value 'string" with "blanks"\t!"' will be parsed as 'string with blanks<TAB>!' where <TAB> stands for the TAB character.

In case of a a parsing error the rest of the line is ignored and parsing continues with the next line.

## EXAMPLE
Here is fully working example of an LCDd.conf (formatted somewhat strange to show the features):

```
# the server section
[server]
Bind=127.0.0.1
Port=13666
User="nobody"
#Foreground=no
#ReportLevel=3
#ReportToSyslog=yes
Driver="my Curses Driver"
DriverPath=/usr/lib/lcdproc/
WaitTime= "5"
ServerScreen=no
# assign keys to special functions #
ToggleRotateKey = Enter
PrevScreenKey = Left
NextScreenKey = Right
# ScrollUpKey = Up

 #ScrollDownKey=Down
#  menu section: define keys to use in the server menu #
	 [menu]
MenuKey = Escape	# ESC switches to server menu
EnterKey =Enter
UpKey= Up
DownKey="Down"

 LeftKey= "Left"

 RightKey = "Right"
# configuration of the curses driver #
[my curses Driver]	# yes I use the curse driver
File= "curses.so"
Size="20"x"4"		# LCD screen dimensions
TopLeftX=7		# screen position: X coordinate
TopLeftY=7		# screen position: Y coordinate
Foreground=blue		# foreground color
Background=cyan		# background color when backight is off
Backlight=red		# background color when backight is on
```

## FILES
These are the default config files for the various parts of the LCDproc suite:

/etc/LCDd.conf

configuration of the LCDd server daemon

/etc/lcdproc.conf

configuration of the lcdproc system monitoring client

/etc/lcdexec.conf

configuration of the lcdexec the program starter client

/etc/lcdvc.conf

configuration of the lcdvc virtual console client

## SEE ALSO
LCDd(8), lcdproc(1), lcdexec(1)

## AUTHOR
This manual page has been written by Peter Marschall <peter@adpm.de>


lcovrc

package: lcov

title: lcovrc(5)

summary: lcov configuration file

text:
# lcovrc(5)

## NAME
lcovrc - lcov configuration file

## DESCRIPTION
The lcovrc file contains configuration information for the lcov code coverage tool (see lcov(1)).

The system-wide configuration file is located at /etc/lcovrc. To change settings for a single user, place a customized copy of this file at location ~/.lcovrc. Where available, command-line options override configuration file settings.

Lines in a configuration file can either be:

*

empty lines or lines consisting only of white space characters. These lines are ignored.

*

comment lines which start with a hash sign ('#'). These are treated like empty lines and will be ignored.

*

statements in the form 'key = value'. A list of valid statements and their description can be found in section 'OPTIONS' below.

Example configuration:

\#

\# Example LCOV configuration file

\# # External style sheet file

\#genhtml_css_file = gcov.css

\# Coverage rate limits

genhtml_hi_limit = 90

genhtml_med_limit = 75

\# Width of line coverage field in source code view

genhtml_line_field_width = 12

\# Width of branch coverage field in source code view

genhtml_branch_field_width = 16

\# Width of overview image

genhtml_overview_width = 80

\# Resolution of overview navigation

genhtml_nav_resolution = 4

\# Offset for source code navigation

genhtml_nav_offset = 10

\# Do not remove unused test descriptions if non-zero

genhtml_keep_descriptions = 0

\# Do not remove prefix from directory names if non-zero

genhtml_no_prefix = 0

\# Do not create source code view if non-zero

genhtml_no_source = 0

\# Specify size of tabs

genhtml_num_spaces = 8

\# Highlight lines with converted-only data if non-zero

genhtml_highlight = 0

\# Include color legend in HTML output if non-zero

genhtml_legend = 0

\# Include HTML file at start of HTML output

\#genhtml_html_prolog = prolog.html

\# Include HTML file at end of HTML output

\#genhtml_html_epilog = epilog.html

\# Use custom HTML file extension

\#genhtml_html_extension = html

\# Compress all generated html files with gzip.

\#genhtml_html_gzip = 1

\# Include sorted overview pages

genhtml_sort = 1

\# Include function coverage data display

\#genhtml_function_coverage = 1

\# Include branch coverage data display

\#genhtml_branch_coverage = 1

\# Specify the character set of all generated HTML pages

genhtml_charset=UTF-8

\# Allow HTML markup in test case description text if non-zero

genhtml_desc_html=0

\# Specify the precision for coverage rates

\#genhtml_precision=1

\# Show missed counts instead of hit counts

\#genhtml_missed=1

\# Demangle C++ symbols

\#genhtml_demangle_cpp=1

\# Name of the tool used for demangling C++ function names

\#genhtml_demangle_cpp_tool = c++filt

\# Specify extra parameters to be passed to the demangling tool

\#genhtml_demangle_cpp_params = ""

\# Location of the gcov tool

\#geninfo_gcov_tool = gcov

\# Adjust test names if non-zero

\#geninfo_adjust_testname = 0

\# Calculate a checksum for each line if non-zero

geninfo_checksum = 0

\# Enable libtool compatibility mode if non-zero

geninfo_compat_libtool = 0

\# Specify whether to capture coverage data for external source

\# files

\#geninfo_external = 1

\# Use gcov's --all-blocks option if non-zero

\#geninfo_gcov_all_blocks = 1

\# Specify compatiblity modes (same as --compat option

\# of geninfo)

\#geninfo_compat = libtool=on, hammer=auto, split_crc=auto

\# Adjust path to source files by removing or changing path

\# components that match the specified pattern (Perl regular

\# expression format)

\#geninfo_adjust_src_path = /tmp/build => /usr/src

\# Specify if geninfo should try to automatically determine

\# the base-directory when collecting coverage data.

geninfo_auto_base = 1

\# Use gcov intermediate format? Valid values are 0, 1, auto

geninfo_intermediate = auto

\# Directory containing gcov kernel files

lcov_gcov_dir = /proc/gcov

\# Location for temporary directories

lcov_tmp_dir = /tmp

\# Show full paths during list operation if non-zero

lcov_list_full_path = 0

\# Specify the maximum width for list output. This value is

\# ignored when lcov_list_full_path is non-zero.

lcov_list_width = 80

\# Specify the maximum percentage of file names which may be

\# truncated when choosing a directory prefix in list output.

\# This value is ignored when lcov_list_full_path is non-zero.

lcov_list_truncate_max = 20

\# Specify if function coverage data should be collected and

\# processed.

lcov_function_coverage = 1

\# Specify if branch coverage data should be collected and

\# processed.

lcov_branch_coverage = 0

## OPTIONS
genhtml_css_file = filename

Specify an external style sheet file. Use this option to modify the appearance of the HTML output as generated by genhtml. During output generation, a copy of this file will be placed in the output directory. This option corresponds to the --css-file command line option of genhtml.

By default, a standard CSS file is generated.

genhtml_hi_limit = hi_limit

genhtml_med_limit = med_limit

Specify coverage rate limits for classifying file entries. Use this option to modify the coverage rates (in percent) for line, function and branch coverage at which a result is classified as high, medium or low coverage. This classification affects the color of the corresponding entries on the overview pages of the HTML output: High: hi_limit <= rate <= 100 default color: green

Medium: med_limit <= rate < hi_limit default color: orange

Low: 0 <= rate < med_limit default color: red

Defaults are 90 and 75 percent.

genhtml_line_field_width = number_of_characters

Specify the width (in characters) of the source code view column containing line coverage information. Default is 12.

genhtml_branch_field_width = number_of_characters

Specify the width (in characters) of the source code view column containing branch coverage information. Default is 16.

genhtml_overview_width = pixel_size

Specify the width (in pixel) of the overview image created when generating HTML output using the --frames option of genhtml. Default is 80.

genhtml_nav_resolution = lines

Specify the resolution of overview navigation when generating HTML output using the --frames option of genhtml. This number specifies the maximum difference in lines between the position a user selected from the overview and the position the source code window is scrolled to. Default is 4.

genhtml_nav_offset = lines

Specify the overview navigation line offset as applied when generating HTML output using the --frames option of genhtml. Clicking a line in the overview image should show the source code view at a position a bit further up, so that the requested line is not the first line in the window. This number specifies that offset.

Default is 10.

genhtml_keep_descriptions = 0|1

If non-zero, keep unused test descriptions when generating HTML output using genhtml. This option corresponds to the --keep-descriptions option of genhtml.

Default is 0.

genhtml_no_prefix = 0|1

If non-zero, do not try to find and remove a common prefix from directory names. This option corresponds to the --no-prefix option of genhtml.

Default is 0.

genhtml_no_source = 0|1

If non-zero, do not create a source code view when generating HTML output using genhtml. This option corresponds to the --no-source option of genhtml.

Default is 0.

genhtml_num_spaces = num

Specify the number of spaces to use as replacement for tab characters in the HTML source code view as generated by genhtml. This option corresponds to the --num-spaces option of genthml.

Default is 8.

genhtml_highlight = 0|1

If non-zero, highlight lines with converted-only data in HTML output as generated by genhtml. This option corresponds to the --highlight option of genhtml.

Default is 0.

genhtml_legend = 0|1

If non-zero, include a legend explaining the meaning of color coding in the HTML output as generated by genhtml. This option corresponds to the --legend option of genhtml.

Default is 0.

genhtml_html_prolog = filename

If set, include the contents of the specified file at the beginning of HTML output. This option corresponds to the --html-prolog option of genhtml.

Default is to use no extra prolog.

genhtml_html_epilog = filename

If set, include the contents of the specified file at the end of HTML output. This option corresponds to the --html-epilog option of genhtml.

Default is to use no extra epilog.

genhtml_html_extension = extension

If set, use the specified string as filename extension for generated HTML files. This option corresponds to the --html-extension option of genhtml.

Default extension is "html".

genhtml_html_gzip = 0|1

If set, compress all html files using gzip. This option corresponds to the --html-gzip option of genhtml.

Default extension is 0.

genhtml_sort = 0|1

If non-zero, create overview pages sorted by coverage rates when generating HTML output using genhtml. This option can be set to 0 by using the --no-sort option of genhtml.

Default is 1.

genhtml_function_coverage = 0|1

If non-zero, include function coverage data when generating HTML output using genhtml. This option can be set to 0 by using the --no-function-coverage option of genhtml.

Default is 1.

genhtml_branch_coverage = 0|1

If non-zero, include branch coverage data when generating HTML output using genhtml. This option can be set to 0 by using the --no-branch-coverage option of genhtml.

Default is 1.

genhtml_charset = charset

Specify the character set of all generated HTML pages. Use this option if the source code contains characters which are not part of the default character set. Note that this option is ignored when a custom HTML prolog is specified (see also genhtml_html_prolog).

Default is UTF-8.

genhtml_demangle_cpp = 0|1

If non-zero, demangle C++ function names in function overviews. Set this option to one if you want to convert C++ internal function names to human readable format for display on the HTML function overview page. This option requires that the c++filt tool is installed (see c++filt(1) ).

This option corresponds to the --demangle-cpp command line option of genhtml.

Default is 0.

genhtml_demangle_cpp_tool = path_to_c++filt

Specify the location of the demangle tool (see c++filt(1)) used to convert C++ internal function names to human readable format for display on the HTML function overview page. Default is 'c++filt'.

genhtml_demangle_cpp_params = parameters

Specify extra parameters to be passed to the demangling tool Use this option if your environment requires additional parameters such as --no-strip-underscore for correctly demangling C++ internal function names. See also c++filt(1)).

Default is "".

genhtml_desc_html = 0|1

If non-zero, test case descriptions may contain HTML markup. Set this option to one if you want to embed HTML markup (for example to include links) in test case descriptions. When set to zero, HTML markup characters will be escaped to show up as plain text on the test case description page.

Default is 0.

genhtml_precision = 1|2|3|4

Specify how many digits after the decimal-point should be used for displaying coverage rates. Default is 1.

genhtml_missed = 0|1

If non-zero, the count of missed lines, functions, or branches is shown as negative numbers in overview pages. Default is 0.

geninfo_gcov_tool = path_to_gcov

Specify the location of the gcov tool (see gcov(1)) which is used to generate coverage information from data files. Default is 'gcov'.

geninfo_adjust_testname = 0|1

If non-zero, adjust test names to include operating system information when capturing coverage data. Default is 0.

geninfo_checksum = 0|1

If non-zero, generate source code checksums when capturing coverage data. Checksums are useful to prevent merging coverage data from incompatible source code versions but checksum generation increases the size of coverage files and the time used to generate those files. This option corresponds to the --checksum and --no-checksum command line option of geninfo.

Default is 0.

geninfo_compat_libtool = 0|1

If non-zero, enable libtool compatibility mode. When libtool compatibility mode is enabled, lcov will assume that the source code relating to a .da file located in a directory named ".libs" can be found in its parent directory. This option corresponds to the --compat-libtool and --no-compat-libtool command line option of geninfo.

Default is 1.

geninfo_external = 0|1

If non-zero, capture coverage data for external source files. External source files are files which are not located in one of the directories (including sub-directories) specified by the --directory or --base-directory options of lcov/geninfo.

Default is 1.

geninfo_gcov_all_blocks = 0|1

If non-zero, call the gcov tool with option --all-blocks. Using --all-blocks will produce more detailed branch coverage information for each line. Set this option to zero if you do not need detailed branch coverage information to speed up the process of capturing code coverage or to work around a bug in some versions of gcov which will cause it to endlessly loop when analysing some files.

Default is 1.

geninfo_compat = mode=value[,mode=value,...]

Specify that geninfo should enable one or more compatibility modes when capturing coverage data. This option corresponds to the --compat command line option of geninfo.

Default is 'libtool=on, hammer=auto, split_crc=auto'.

geninfo_adjust_src_path = pattern => replacement

geninfo_adjust_src_path = pattern

Adjust source paths when capturing coverage data. Use this option in situations where geninfo cannot find the correct path to source code files of a project. By providing a pattern in Perl regular expression format (see perlre(1)) and an optional replacement string, you can instruct geninfo to remove or change parts of the incorrect source path.

Example:

1. When geninfo reports that it cannot find source file

/path/to/src/.libs/file.c

while the file is actually located in

/path/to/src/file.c

use the following parameter:

geninfo_adjust_src_path = /.libs

This will remove all "/.libs" strings from the path.

2. When geninfo reports that it cannot find source file

/tmp/build/file.c

while the file is actually located in

/usr/src/file.c

use the following parameter:

geninfo_adjust_src_path = /tmp/build => /usr/src

This will change all "/tmp/build" strings in the path to "/usr/src".

geninfo_auto_base = 0|1

If non-zero, apply a heuristic to determine the base directory when collecting coverage data. Use this option when using geninfo on projects built with libtool or similar build environments that work with multiple base directories, i.e. environments, where the current working directory when invoking the compiler ist not the same directory in which the source code file is located, and in addition, is different between files of the same project.

Default is 1.

geninfo_intermediate = 0|1|auto

Specify whether to use gcov intermediate format Use this option to control whether geninfo should use the gcov intermediate format while collecting coverage data. The use of the gcov intermediate format should increase processing speed. It also provides branch coverage data when using the --initial command line option.

Valid values are 0 for off, 1 for on, and "auto" to let geninfo automatically use immediate format when supported by gcov.

Default is "auto".

geninfo_no_exception_branch = 0|1

Specify whether to exclude exception branches from branch coverage. Default is 0.

lcov_gcov_dir = path_to_kernel_coverage_data

Specify the path to the directory where kernel coverage data can be found or leave undefined for auto-detection. Default is auto-detection.

lcov_tmp_dir = temp

Specify the location of a directory used for temporary files. Default is '/tmp'.

lcov_list_full_path = 0|1

If non-zero, print the full path to source code files during a list operation. This option corresponds to the --list-full-path option of lcov.

Default is 0.

lcov_list_max_width = width

Specify the maximum width for list output. This value is ignored when lcov_list_full_path is non-zero. Default is 80.

lcov_list_truncate_max = percentage

Specify the maximum percentage of file names which may be truncated when choosing a directory prefix in list output. This value is ignored when lcov_list_full_path is non-zero. Default is 20.

lcov_function_coverage = 0|1

Specify whether lcov should handle function coverage data. Setting this option to 0 can reduce memory and CPU time consumption when lcov is collecting and processing coverage data, as well as reduce the size of the resulting data files. Note that setting genhtml_function_coverage will override this option for HTML generation.

Default is 1.

lcov_branch_coverage = 0|1

Specify whether lcov should handle branch coverage data. Setting this option to 0 can reduce memory and CPU time consumption when lcov is collecting and processing coverage data, as well as reduce the size of the resulting data files. Note that setting genhtml_branch_coverage will override this option for HTML generation.

Default is 0.

lcov_excl_line = expression

Specify the regular expression of lines to exclude. Default is 'LCOV_EXCL_LINE'.

lcov_excl_br_line = expression

Specify the regular expression of lines to exclude from branch coverage. Default is 'LCOV_EXCL_BR_LINE'.

lcov_excl_exception_br_line = expression

Specify the regular expression of lines to exclude from exception branch coverage. Default is 'LCOV_EXCL_EXCEPTION_BR_LINE'.

## FILES
/etc/lcovrc

The system-wide lcov configuration file.

~/.lcovrc

The individual per-user configuration file.

## SEE ALSO
lcov(1), genhtml(1), geninfo(1), gcov(1)


VirtualBindings

package: lesstif

title: VirtualBindings(5)

summary: Lesstif virtual-bindings facility

text:
# VirtualBindings(5)

## NAME
VirtualBindings - Lesstif virtual-bindings facility

## SYNOPSIS
To be written

## SEE ALSO
lesstif(1) xmbind(1)


mwmrc

package: lesstif-mwm

title: mwmrc(5)

text:
# mwmrc(5)

## NAME
mwmrc - The M*tif Window Manager configuration file

## DESCRIPTION
The LessTif window manager mwm supports both a global configuration file /etc/X11/mwm/system.mwmrc and a per-user configation file ~/.mwmrc.

## STRUCTURE
Each mwm configuration file consist of blocks of bindings. Each block consists of a block type keyword, a name and a set of entries between curly braces (`{' and '}').

An exclamation mark (`!') introduces a comment. Comments extend to the end of the line.

## Block types
There are three types of blocks:

Menu bindings

Button bindings

Key bindings

## Menu bindings
Menu bindings are introduced by the Menu keyword. The generic form of the entries is label mnemonic accelerator function . Both mnemonic and accelerator may be empty. For example:

"Foo bar" _R Alt<Key>F5 f.restore

## Button bindings
Button bindings are introduced by the Buttons keyword. The entries each are Button name Context Function . For example:

<Btn3Down> icon|frame f.post_wmenu

## Key bindings
Key bindings are very similar to button bindings. The entries each are Key name Context Function . For example:

Alt<Key>Tab root|icon|window f.next_key

## Label
A label is either a plain string, or a bitmap. Bitmaps are indicated as "@" followed by the filename. For example:

mailer @fortytwo.bmp

## Mnemonic
A mnemonic is an underscore ("_") followed by a single character. For example:

_M

## Accelerator
An accelerator is a key name.

## Button name
A button name is Btn followed by the number (1..5) and an action (Up, Down, Click, Click2); for example:

Btn2Click

## Context
A context is a single string consisting of bar (`|') separated object names (root, icon, menub, minimizeb, maximizeb , window, title, frame, border); for example:

icon|title

## Function
A function is a string starting with "f.". The functions are: f.beep, f.circle_down, f.circle_up, f.desk, f.exec, f.focus_color, f.focus_key, f.goto_page, f.kill, f.lower, f.maximize, f.menu, f.minimize, f.move, f.next_cmap, f.next_key, f.nop, f.normalize, f.normalize_and_raise, f.pack_icons, f.pass_keys, f.post_wmenu, f.prev_cmap, f.prev_key, f.quit_mwm, f.raise, f.raise_lower, f.refresh, f.refresh_win, f.resize, f.restart, f.restore, f.restore_and_raise, f.screen, f.send_msg, f.separator, f.set_behavior, f.title, f.toggle_page, f.window_list.

## EXAMPLE
For a complete example, check out /etc/X11/mwm/system.mwmrc or look at the system.mwmrc distributed with the LessTif sources.

## AUTHORS
mwm was written by the LessTif project, http://www.lesstif.org/ and others. This manpage was written by Ray Dassen <jdassen@debian.org>.

## SEE ALSO
mwm(1x)


lftp.conf

package: lftp

title: lftp.conf(5)

summary: the global configuration file for lftp

text:
# lftp.conf(5)

## NAME
lftp.conf - the global configuration file for lftp

## DESCRIPTION
the /etc/lftp.conf configuration file changes the default behavior of lftp and affects the settings for all users. User-specific options should be set in either the ~/.lftprc or ~/.lftp/rc file. These configuration files are read when lftp starts up and the parameters defined therein take affect at that time.

In addition to lftp's configuration options, aliases and 'set' commands can be defined in any of these configuration files. Refer to the Command and Settings sections of the lftp man page for more details.

## SEE ALSO
lftp(1)


Compose

title: Compose(5)

text:
# Compose(5)

## NAME
Compose - X client mappings for multi-key input sequences

## DESCRIPTION
The X library, libX11, provides a simple input method for characters beyond those represented on typical keyboards using sequences of key strokes that are combined to enter a single character.

The compose file is searched for in the following order:

-

If the environment variable $XCOMPOSEFILE is set, its value is used as the name of the Compose file.

-

If the user's home directory has a file named .XCompose, it is used as the Compose file.

-

The system provided compose file is used by mapping the locale to a compose file from the list in /usr/share/X11/locale/compose.dir.

Compose files can use an "include" instruction. This allows local modifications to be made to existing compose files without including all of the content directly. For example, the system's iso8859-1 compose file can be included with a line like this:

include "%S/iso8859-1/Compose"

There are several substitutions that can be made in the file name of the include instruction:

%H

expands to the user's home directory (the $HOME environment variable)

%L

expands to the name of the locale specific Compose file (i.e., "/usr/share/X11/locale/<localename>/Compose")

%S

expands to the name of the system directory for Compose files (i.e., "/usr/share/X11/locale")

For example, you can include in your compose file the default Compose file by using:

include "%L"

and then rewrite only the few rules that you need to change. New compose rules can be added, and previous ones replaced.

## FILE FORMAT
Compose files are plain text files, with a separate line for each compose sequence. Comments begin with # characters. Each compose sequence specifies one or more events and a resulting input sequence, with an optional comment at the end of the line:

EVENT [EVENT...] : RESULT [# COMMENT]

Each event consists of a specified input keysym, and optional modifier states:

[([!] ([~] MODIFIER)...) | None] <keysym>

If the modifier list is preceded by "!" it must match exactly. MODIFIER may be one of Ctrl, Lock, Caps, Shift, Alt or Meta. Each modifier may be preceded by a "~" character to indicate that the modifier must not be present. If "None" is specified, no modifier may be present.

The result specifies a string, keysym, or both, that the X client receives as input when the sequence of events is input:

"STRING" | keysym | "STRING" keysym

Keysyms are specified without the XK_ prefix.

Strings may be direct text encoded in the locale for which the compose file is to be used, or an escaped octal or hexadecimal character code. Octal codes are specified as "\123" and hexadecimal codes as "\x3a". It is not necessary to specify in the right part of a rule a locale encoded string in addition to the keysym name. If the string is omitted, Xlib figures it out from the keysym according to the current locale. I.e., if a rule looks like:

<dead_grave> <A> : "\300" Agrave

the result of the composition is always the letter with the "\300" code. But if the rule is: <dead_grave> <A> : Agrave

the result depends on how Agrave is mapped in the current locale.

## ENVIRONMENT
XCOMPOSEFILE

File to use for compose sequences.

XCOMPOSECACHE

Directory to use for caching compiled compose files.

## FILES
$HOME/.XCompose

User default compose file if XCOMPOSEFILE is not set.

/usr/share/X11/locale/compose.dir

File listing the compose file path to use for each locale.

/usr/share/X11/locale/<localemapping>/Compose

System default compose file for the locale, mapped via compose.dir.

/var/cache/libx11/compose/

System-wide cache directory for compiled compose files.

$HOME/.cache/compose/

Per-user cache directory for compiled compose files.

## SEE ALSO
XLookupString(3), XmbLookupString(3), XwcLookupString(3), Xutf8LookupString(3), mkcomposecache(1), locale(7).

Xlib - C Language X Interface


libao.conf

package: libao

title: libao.conf(5)

summary: configuration for libao.

text:
# libao.conf(5)

## NAME
libao.conf - configuration for libao.

## SYNOPSIS
/etc/libao.conf

~/.libao

## DESCRIPTION
libao.conf and .libao are configuration files for libao, the audio output library. They specify various options to libao, as described below. libao.conf sets system-wide options, whereas ~/.libao sets user-specific options. When an option is set in both places, the option in ~/.libao takes precedence.

## FILE FORMAT
The file consists of comments and key-value pairs. Comments are on separate lines that start with a # symbol. The key-value pairs are of the form:

key=value

where key contains no whitespace and no equal signs. value will be all of the text after the equal sign until (but not including) the ending newline. Beware of extra spaces at the end of the line! They will probably be interpreted as part of the option value. The following is a list of valid global option keys. Any driver specific option may be used as well as those keys.

default_driver

The short name of the driver libao should use by default. Valid values include (not all are available on every platform): pulse, oss, esd, arts, alsa, nas, irix, sun, roar and sndio. Note that "sun" is used on many BSD systems as well as Solaris.

debug (Value optional/ignored)

Sets all the drivers as well as AO itself into debugging output mode. Unlike passing the debug option to a driver, debug will also print debugging information from driver loading and testing.

quiet (Value optional/ignored)

Sets all the drivers as well as AO itself into silent mode. Errors will return only error codes; neither ao nor the drivers will print any output whatsoever to stderr.

verbose (Value optional/ignored)

Sets all the drivers as well as AO itself into verbose mode.

## EXAMPLE
Here is an example libao.conf that forces the OSS driver to be used by default:

\# This is a comment.

default_driver=oss

## BUGS
libao.conf is missing a number of potentially useful options.

## AUTHORS
Stan Seibert <volsung@xiph.org>


cpio

package: libarchive-devel

title: cpio(5)

summary: format of cpio archive files

text:
# cpio(5)

## NAME
cpio — format of cpio archive files

## DESCRIPTION
The cpio archive format collects any number of files, directories, and other file system objects (symbolic links, device nodes, etc.) into a single stream of bytes.

### General Format
Each file system object in a cpio archive comprises a header record with basic numeric metadata followed by the full pathname of the entry and the file data. The header record stores a series of integer values that generally follow the fields in struct stat. (See stat(2) for details.) The variants differ primarily in how they store those integers (binary, octal, or hexadecimal). The header is followed by the pathname of the entry (the length of the pathname is stored in the header) and any file data. The end of the archive is indicated by a special record with the pathname “TRAILER!!!”.

### PWB format
The PWB binary cpio format is the original format, when cpio was introduced as part of the Programmer's Work Bench system, a variant of 6th Edition UNIX. It stores numbers as 2-byte and 4-byte binary values. Each entry begins with a header in the following format:

```
struct header_pwb_cpio {
        short   h_magic;
        short   h_dev;
        short   h_ino;
        short   h_mode;
        short   h_uid;
        short   h_gid;
        short   h_nlink;
        short   h_majmin;
        long    h_mtime;
        short   h_namesize;
        long    h_filesize;
};
```

The short fields here are 16-bit integer values, while the long fields are 32 bit integers. Since PWB UNIX, like the 6th Edition UNIX it was based on, only ran on PDP-11 computers, they are in PDP-endian format, which has little-endian shorts, and big-endian longs. That is, the long integer whose hexadecimal representation is 0x12345678 would be stored in four successive bytes as 0x34, 0x12, 0x78, 0x56. The fields are as follows:

h_magic

The integer value octal 070707.

h_dev, h_ino

The device and inode numbers from the disk. These are used by programs that read cpio archives to determine when two entries refer to the same file. Programs that synthesize cpio archives should be careful to set these to distinct values for each entry.

h_mode

The mode specifies both the regular permissions and the file type, and it also holds a couple of bits that are irrelevant to the cpio format, because the field is actually a raw copy of the mode field in the inode representing the file. These are the IALLOC flag, which shows that the inode entry is in use, and the ILARG flag, which shows that the file it represents is large enough to have indirect blocks pointers in the inode. The mode is decoded as follows:

0100000

IALLOC flag - irrelevant to cpio.

0060000

This masks the file type bits.

0040000

File type value for directories.

0020000

File type value for character special devices.

0060000

File type value for block special devices.

0010000

ILARG flag - irrelevant to cpio.

0004000

SUID bit.

0002000

SGID bit.

0001000

Sticky bit.

0000777

The lower 9 bits specify read/write/execute permissions for world, group, and user following standard POSIX conventions.

h_uid, h_gid

The numeric user id and group id of the owner.

h_nlink

The number of links to this file. Directories always have a value of at least two here. Note that hardlinked files include file data with every copy in the archive.

h_majmin

For block special and character special entries, this field contains the associated device number, with the major number in the high byte, and the minor number in the low byte. For all other entry types, it should be set to zero by writers and ignored by readers.

h_mtime

Modification time of the file, indicated as the number of seconds since the start of the epoch, 00:00:00 UTC January 1, 1970.

h_namesize

The number of bytes in the pathname that follows the header. This count includes the trailing NUL byte.

h_filesize

The size of the file. Note that this archive format is limited to 16 megabyte file sizes, because PWB UNIX, like 6th Edition, only used an unsigned 24 bit integer for the file size internally.

The pathname immediately follows the fixed header. If h_namesize is odd, an additional NUL byte is added after the pathname. The file data is then appended, again with an additional NUL appended if needed to get the next header at an even offset.

Hardlinked files are not given special treatment; the full file contents are included with each copy of the file.

### New Binary Format
The new binary cpio format showed up when cpio was adopted into late 7th Edition UNIX. It is exactly like the PWB binary format, described above, except for three changes:

First, UNIX now ran on more than one hardware type, so the endianness of 16 bit integers must be determined by observing the magic number at the start of the header. The 32 bit integers are still always stored with the most significant word first, though, so each of those two, in the struct shown above, was stored as an array of two 16 bit integers, in the traditional order. Those 16 bit integers, like all the others in the struct, were accessed using a macro that byte swapped them if necessary.

Next, 7th Edition had more file types to store, and the IALLOC and ILARG flag bits were re-purposed to accommodate these. The revised use of the various bits is as follows:

0170000

This masks the file type bits.

0140000

File type value for sockets.

0120000

File type value for symbolic links. For symbolic links, the link body is stored as file data.

0100000

File type value for regular files.

0060000

File type value for block special devices.

0040000

File type value for directories.

0020000

File type value for character special devices.

0010000

File type value for named pipes or FIFOs.

0004000

SUID bit.

0002000

SGID bit.

0001000

Sticky bit.

0000777

The lower 9 bits specify read/write/execute permissions for world, group, and user following standard POSIX conventions.

Finally, the file size field now represents a signed 32 bit integer in the underlying file system, so the maximum file size has increased to 2 gigabytes.

Note that there is no obvious way to tell which of the two binary formats an archive uses, other than to see which one makes more sense. The typical error scenario is that a PWB format archive unpacked as if it were in the new format will create named sockets instead of directories, and then fail to unpack files that should go in those directories. Running bsdcpio -itv on an unknown archive will make it obvious which it is: if it's PWB format, directories will be listed with an 's' instead of a 'd' as the first character of the mode string, and the larger files will have a '?' in that position.

### Portable ASCII Format
Version 2 of the Single UNIX Specification (“SUSv2”) standardized an ASCII variant that is portable across all platforms. It is commonly known as the “old character” format or as the “odc” format. It stores the same numeric fields as the old binary format, but represents them as 6-character or 11-character octal values.

```
struct cpio_odc_header {
        char    c_magic[6];
        char    c_dev[6];
        char    c_ino[6];
        char    c_mode[6];
        char    c_uid[6];
        char    c_gid[6];
        char    c_nlink[6];
        char    c_rdev[6];
        char    c_mtime[11];
        char    c_namesize[6];
        char    c_filesize[11];
};
```

The fields are identical to those in the new binary format. The name and file body follow the fixed header. Unlike the binary formats, there is no additional padding after the pathname or file contents. If the files being archived are themselves entirely ASCII, then the resulting archive will be entirely ASCII, except for the NUL byte that terminates the name field.

### New ASCII Format
The "new" ASCII format uses 8-byte hexadecimal fields for all numbers and separates device numbers into separate fields for major and minor numbers.

```
struct cpio_newc_header {
        char    c_magic[6];
        char    c_ino[8];
        char    c_mode[8];
        char    c_uid[8];
        char    c_gid[8];
        char    c_nlink[8];
        char    c_mtime[8];
        char    c_filesize[8];
        char    c_devmajor[8];
        char    c_devminor[8];
        char    c_rdevmajor[8];
        char    c_rdevminor[8];
        char    c_namesize[8];
        char    c_check[8];
};
```

Except as specified below, the fields here match those specified for the new binary format above.

magic

The string “070701”.

check

This field is always set to zero by writers and ignored by readers. See the next section for more details.

The pathname is followed by NUL bytes so that the total size of the fixed header plus pathname is a multiple of four. Likewise, the file data is padded to a multiple of four bytes. Note that this format supports only 4 gigabyte files (unlike the older ASCII format, which supports 8 gigabyte files).

In this format, hardlinked files are handled by setting the filesize to zero for each entry except the first one that appears in the archive.

### New CRC Format
The CRC format is identical to the new ASCII format described in the previous section except that the magic field is set to “070702” and the check field is set to the sum of all bytes in the file data. This sum is computed treating all bytes as unsigned values and using unsigned arithmetic. Only the least-significant 32 bits of the sum are stored.

### HP variants
The cpio implementation distributed with HPUX used XXXX but stored device numbers differently XXX.

### Other Extensions and Variants
Sun Solaris uses additional file types to store extended file data, including ACLs and extended attributes, as special entries in cpio archives.

XXX Others? XXX

## SEE ALSO
cpio(1), tar(5)

## STANDARDS
The cpio utility is no longer a part of POSIX or the Single Unix Standard. It last appeared in Version 2 of the Single UNIX Specification (“SUSv2”). It has been supplanted in subsequent standards by pax(1). The portable ASCII format is currently part of the specification for the pax(1) utility.

## HISTORY
The original cpio utility was written by Dick Haight while working in AT&T's Unix Support Group. It appeared in 1977 as part of PWB/UNIX 1.0, the “Programmer's Work Bench” derived from Version 6 AT&T UNIX that was used internally at AT&T. Both the new binary and old character formats were in use by 1980, according to the System III source released by SCO under their “Ancient Unix” license. The character format was adopted as part of IEEE Std 1003.1-1988 (“POSIX.1”). XXX when did "newc" appear? Who invented it? When did HP come out with their variant? When did Sun introduce ACLs and extended attributes? XXX

## BUGS
The “CRC” format is mis-named, as it uses a simple checksum and not a cyclic redundancy check.

The binary formats are limited to 16 bits for user id, group id, device, and inode numbers. They are limited to 16 megabyte and 2 gigabyte file sizes for the older and newer variants, respectively.

The old ASCII format is limited to 18 bits for the user id, group id, device, and inode numbers. It is limited to 8 gigabyte file sizes.

The new ASCII format is limited to 4 gigabyte file sizes.

None of the cpio formats store user or group names, which are essential when moving files between systems with dissimilar user or group numbering.

Especially when writing older cpio variants, it may be necessary to map actual device/inode values to synthesized values that fit the available fields. With very large filesystems, this may be necessary even for the newer formats.