title: virtual_domain_context(5)

text:
# virtual_domain_context(5)

## NAME
virtual_domain_context - The SELinux virtual machine domain context configuration file

## DESCRIPTION
The virtual_domain_context file contains a list of domain contexts that are available for use by the SELinux-aware virtualization API libvirt (see libvirtd(8)).

selinux_virtual_domain_context_path(3) will return the active policy path to this file. The default virtual domain context file is:

/etc/selinux/{SELINUXTYPE}/contexts/virtual_domain_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line in the file consists of an entry as follows:

user:role:type[:range]

Where:

user role type range A user, role, type and optional range (for MCS/MLS) separated by colons (:) that can be used as a virtual domain context.

## EXAMPLE
\# ./contexts/virtual_domain_context

system_u:object_r:svirt_t:s0

## SEE ALSO
selinux(8), libvirtd(8), selinux_virtual_domain_context_path(3), selinux_config(5)


package: libselinux-utils

title: virtual_image_context(5)

text:
# virtual_image_context(5)

## NAME
virtual_image_context - The SELinux virtual machine image context configuration file

## DESCRIPTION
The virtual_image_context file contains a list of image contexts for use by the SELinux-aware virtualization API libvirt (see libvirtd(8)).

selinux_virtual_image_context_path(3) will return the active policy path to this file. The default virtual image context file is:

/etc/selinux/{SELINUXTYPE}/contexts/virtual_image_context

Where {SELINUXTYPE} is the entry from the selinux configuration file config (see selinux_config(5)).

## FILE FORMAT
Each line in the file consists of an entry as follows:

user:role:type[:range]

Where:

user role type range A user, role, type and optional range (for MCS/MLS) separated by colons (:) that can be used as a virtual image context.

## EXAMPLE
\# ./contexts/virtual_image_context

system_u:object_r:svirt_image_t:s0

system_u:object_r:svirt_content_t:s0

## SEE ALSO
selinux(8), libvirtd(8), selinux_virtual_image_context_path(3), selinux_config(5)


semanage.conf

package: libsemanage

title: semanage.conf(5)

text:
# semanage.conf(5)

## NAME
semanage.conf - global configuration file for the SELinux Management library

## DESCRIPTION
The semanage.conf file is usually located under the directory /etc/selinux and it is used for run-time configuration of the behavior of the SELinux Management library.

Each line should contain a configuration parameter followed by the equal sign ("=") and then followed by the configuration value for that parameter. Anything after the "#" symbol is ignored similarly to empty lines.

The following parameters are allowed:

module-store

Specify how the SELinux Management library should interact with the SELinux policy store. When set to "direct", the SELinux Management library writes to the SELinux policy module store directly (this is the default setting). Otherwise a socket path or a server name can be used for the argument. If the argument begins with "/" (as in "/foo/bar"), it represents the path to a named socket that should be used to connect the policy management server. If the argument does not begin with a "/" (as in "foo.com:4242"), it should be interpreted as the name of a remote policy management server to be used through a TCP connection (default port is 4242 unless a different one is specified after the server name using the colon to separate the two fields).

root

Specify an alternative root path to use for the store. The default is "/"

store-root

Specify an alternative store_root path to use. The default is "/var/lib/selinux"

compiler-directory

Specify an alternative directory that contains HLL to CIL compilers. The default value is "/usr/libexec/selinux/hll".

ignore-module-cache

Whether or not to ignore the cache of CIL modules compiled from HLL. It can be set to either "true" or "false" and is set to "false" by default. If the cache is ignored, then all CIL modules are recompiled from their HLL modules.

policy-version

When generating the policy, by default semanage will set the policy version to POLICYDB_VERSION_MAX, as defined in <sepol/policydb/policydb.h>. Change this setting if a different version needs to be set for the policy.

target-platform

The target platform to generate policies for. Valid values are "selinux" and "xen", and is set to "selinux" by default.

expand-check

Whether or not to check "neverallow" rules when executing all semanage command. It can be set to either "0" (disabled) or "1" (enabled) and by default it is enabled. There might be a large penalty in execution time if this option is enabled.

file-mode

By default the permission mode for the run-time policy files is set to 0644.

save-previous

It controls whether the previous module directory is saved after a successful commit to the policy store and it can be set to either "true" or "false". By default it is set to "false" (the previous version is deleted).

save-linked

It controls whether the previously linked module is saved (with name "base.linked") after a successful commit to the policy store. It can be set to either "true" or "false" and by default it is set to "false" (the previous module is deleted).

ignoredirs

List, separated by ";", of directories to ignore when setting up users homedirs. Some distributions use this to stop labeling /root as a homedir.

usepasswd

Whether or not to enable the use getpwent() to obtain a list of home directories to label. It can be set to either "true" or "false". By default it is set to "true".

disable-genhomedircon

It controls whether or not the genhomedircon function is executed when using the semanage command and it can be set to either "false" or "true". By default the genhomedircon functionality is enabled (equivalent to this option set to "false").

handle-unknown

This option overrides the kernel behavior for handling permissions defined in the kernel but missing from the actual policy. It can be set to "deny", "reject" or "allow". By default the setting from the policy is taken.

bzip-blocksize

It should be in the range 0-9. A value of 0 means no compression. By default the bzip block size is set to 9 (actual block size value is obtained after multiplication by 100000).

bzip-small

When set to "true", the bzip algorithm shall try to reduce its system memory usage. It can be set to either "true" or "false" and by default it is set to "false".

remove-hll

When set to "true", HLL files will be removed after compilation into CIL. In order to delete HLL files already compiled into CIL, modules will need to be recompiled with the ignore-module-cache option set to 'true' or using the ignore-module-cache option with semodule. The remove-hll option can be set to either "true" or "false" and by default it is set to "false". Please note that since this option deletes all HLL files, an updated HLL compiler will not be able to recompile the original HLL file into CIL. In order to compile the original HLL file into CIL, the same HLL file will need to be reinstalled.

optimize-policy

When set to "true", the kernel policy will be optimized upon rebuilds. It can be set to either "true" or "false" and by default it is set to "false".

## SEE ALSO
semanage(8)

## AUTHOR
This manual page was written by Guido Trentalancia <guido@trentalancia.com>.

The SELinux management library was written by Tresys Technology LLC and Red Hat Inc.


package: libsofthsm

title: softhsm2.conf(5)

summary: SoftHSM configuration file

text:
# softhsm2.conf(5)

## NAME
softhsm2.conf - SoftHSM configuration file

## SYNOPSIS
softhsm2.conf

## DESCRIPTION
This is the configuration file for SoftHSM. It can be found on a default location, but can also be relocated by using the environment variable. Any configuration must be done according to the file format found in this document.

## FILE FORMAT
Each configuration option is a pair of name and value separated by a equality sign. The configuration option must be located on a single line.

```
<name> = <value>
```

It is also possible to add comments in the file by using the hash sign. Anything after the hash sign will be ignored.

```
# A comment
```

```
Any empty lines or lines that does not have the correct format will be ignored.
```

## DIRECTORIES.TOKENDIR
The location where SoftHSM can store the tokens.

```
directories.tokendir = /var/lib/softhsm/tokens/
```

## OBJECTSTORE.BACKEND
The backend to use by SoftHSM to store token objects. Either "file" or "db" is supported. In order to use the "db" backend, the SoftHSM build needs to be configured with "configure --with-objectstore-backend-db"

```
objectstore.backend = file
```

## LOG.LEVEL
The log level which can be set to ERROR, WARNING, INFO or DEBUG.

```
log.level = INFO
```

## SLOTS.REMOVABLE
If set to true CKF_REMOVABLE_DEVICE is set in the flags returned by C_GetSlotInfo. Default is false.

```
slots.removable = true
```

## TOKEN.MECHANISMS
Allows to enable and disable any of the PKCS#11 mechanisms reported in the C_GetMechanismList(). The option accepts string argument containing the comma separated list of all algorithms that should be enabled (do not forget about the keygen mechanisms). The list can be prefixed with minus sign "-" to list only the disabled mechanisms. Additionally, special keyword ALL can be used to enable all the known mechanisms (default). Unknown mechanisms are ignored. This option has higher priority than the CKA_ALLOWED_MECHANISMS attribute on the key objects.

```
slots.mechanisms = ALL
```

## LIBRARY.RESET_ON_FORK
If set to true, the library will reset the state on fork. Default is false.

```
library.reset_on_fork = true
```

## ENVIRONMENT
SOFTHSM2_CONF

When defined, the value will be used as path to the configuration file.

## FILES
~/.config/softhsm2/softhsm2.conf

default user-specific location of the SoftHSM configuration file; if it exists it will override the system wide configuration

/etc/softhsm2.conf

default system-wide location of the SoftHSM configuration file

/etc/softhsm2.conf.sample

an example of a SoftHSM configuration file

## AUTHOR
Written by Rickard Bellgrim, Francis Dupont, René Post, and Roland van Rijswijk.

## SEE ALSO
softhsm2-keyconv(1), softhsm2-migrate(1), softhsm2-util(1)


sss-certmap

title: sss-certmap(5)

text:
# sss-certmap(5)

## NAME
sss-certmap - SSSD Certificate Matching and Mapping Rules

## DESCRIPTION
The manual page describes the rules which can be used by SSSD and other components to match X.509 certificates and map them to accounts.

Each rule has four components, a “priority”, a “matching rule”, a “mapping rule” and a “domain list”. All components are optional. A missing “priority” will add the rule with the lowest priority. The default “matching rule” will match certificates with the digitalSignature key usage and clientAuth extended key usage. If the “mapping rule” is empty the certificates will be searched in the userCertificate attribute as DER encoded binary. If no domains are given only the local domain will be searched.

To allow extensions or completely different style of rule the “mapping” and “matching rules” can contain a prefix separated with a ':' from the main part of the rule. The prefix may only contain upper-case ASCII letters and numbers. If the prefix is omitted the default type will be used which is 'KRB5' for the matching rules and 'LDAP' for the mapping rules.

The 'sssctl' utility provides the 'cert-eval-rule' command to check if a given certificate matches a matching rules and how the output of a mapping rule would look like.

## RULE COMPONENTS

### PRIORITY
The rules are processed by priority while the number '0' (zero) indicates the highest priority. The higher the number the lower is the priority. A missing value indicates the lowest priority. The rules processing is stopped when a matched rule is found and no further rules are checked.

Internally the priority is treated as unsigned 32bit integer, using a priority value larger than 4294967295 will cause an error.

If multiple rules have the same priority and only one of the related matching rules applies, this rule will be chosen. If there are multiple rules with the same priority which matches, one is chosen but which one is undefined. To avoid this undefined behavior either use different priorities or make the matching rules more specific e.g. by using distinct <ISSUER> patterns.

### MATCHING RULE
The matching rule is used to select a certificate to which the mapping rule should be applied. It uses a system similar to the one used by “pkinit_cert_match” option of MIT Kerberos. It consists of a keyword enclosed by '<' and '>' which identified a certain part of the certificate and a pattern which should be found for the rule to match. Multiple keyword pattern pairs can be either joined with '&&' (and) or '||' (or).

Given the similarity to MIT Kerberos the type prefix for this rule is 'KRB5'. But 'KRB5' will also be the default for “matching rules” so that "<SUBJECT>.*,DC=MY,DC=DOMAIN" and "KRB5:<SUBJECT>.*,DC=MY,DC=DOMAIN" are equivalent.

The available options are:

<SUBJECT>regular-expression

With this a part or the whole subject name of the certificate can be matched. For the matching POSIX Extended Regular Expression syntax is used, see regex(7) for details. For the matching the subject name stored in the certificate in DER encoded ASN.1 is converted into a string according to RFC 4514. This means the most specific name component comes first. Please note that not all possible attribute names are covered by RFC 4514. The names included are 'CN', 'L', 'ST', 'O', 'OU', 'C', 'STREET', 'DC' and 'UID'. Other attribute names might be shown differently on different platform and by different tools. To avoid confusion those attribute names are best not used or covered by a suitable regular-expression.

Example: <SUBJECT>.*,DC=MY,DC=DOMAIN

Please note that the characters "^.[$()|*+?{\" have a special meaning in regular expressions and must be escaped with the help of the '\' character so that they are matched as ordinary characters.

Example: <SUBJECT>^CN=.* \(Admin\),DC=MY,DC=DOMAIN$

<ISSUER>regular-expression

With this a part or the whole issuer name of the certificate can be matched. All comments for <SUBJECT> apply her as well. Example: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$

<KU>key-usage

This option can be used to specify which key usage values the certificate should have. The following values can be used in a comma separated list:

•digitalSignature

•nonRepudiation

•keyEncipherment

•dataEncipherment

•keyAgreement

•keyCertSign

•cRLSign

•encipherOnly

•decipherOnly

A numerical value in the range of a 32bit unsigned integer can be used as well to cover special use cases.

Example: <KU>digitalSignature,keyEncipherment

<EKU>extended-key-usage

This option can be used to specify which extended key usage the certificate should have. The following value can be used in a comma separated list:

•serverAuth

•clientAuth

•codeSigning

•emailProtection

•timeStamping

•OCSPSigning

•KPClientAuth

•pkinit

•msScLogin

Extended key usages which are not listed above can be specified with their OID in dotted-decimal notation.

Example: <EKU>clientAuth,1.3.6.1.5.2.3.4

<SAN>regular-expression

To be compatible with the usage of MIT Kerberos this option will match the Kerberos principals in the PKINIT or AD NT Principal SAN as <SAN:Principal> does. Example: <SAN>.*@MY\.REALM

<SAN:Principal>regular-expression

Match the Kerberos principals in the PKINIT or AD NT Principal SAN. Example: <SAN:Principal>.*@MY\.REALM

<SAN:ntPrincipalName>regular-expression

Match the Kerberos principals from the AD NT Principal SAN. Example: <SAN:ntPrincipalName>.*@MY.AD.REALM

<SAN:pkinit>regular-expression

Match the Kerberos principals from the PKINIT SAN. Example: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM

<SAN:dotted-decimal-oid>regular-expression

Take the value of the otherName SAN component given by the OID in dotted-decimal notation, interpret it as string and try to match it against the regular expression. Example: <SAN:1.2.3.4>test

<SAN:otherName>base64-string

Do a binary match with the base64 encoded blob against all otherName SAN components. With this option it is possible to match against custom otherName components with special encodings which could not be treated as strings. Example: <SAN:otherName>MTIz

<SAN:rfc822Name>regular-expression

Match the value of the rfc822Name SAN. Example: <SAN:rfc822Name>.*@email\.domain

<SAN:dNSName>regular-expression

Match the value of the dNSName SAN. Example: <SAN:dNSName>.*\.my\.dns\.domain

<SAN:x400Address>base64-string

Binary match the value of the x400Address SAN. Example: <SAN:x400Address>MTIz

<SAN:directoryName>regular-expression

Match the value of the directoryName SAN. The same comments as given for <ISSUER> and <SUBJECT> apply here as well. Example: <SAN:directoryName>.*,DC=com

<SAN:ediPartyName>base64-string

Binary match the value of the ediPartyName SAN. Example: <SAN:ediPartyName>MTIz

<SAN:uniformResourceIdentifier>regular-expression

Match the value of the uniformResourceIdentifier SAN. Example: <SAN:uniformResourceIdentifier>URN:.*

<SAN:iPAddress>regular-expression

Match the value of the iPAddress SAN. Example: <SAN:iPAddress>192\.168\..*

<SAN:registeredID>regular-expression

Match the value of the registeredID SAN as dotted-decimal string. Example: <SAN:registeredID>1\.2\.3\..*

### MAPPING RULE
The mapping rule is used to associate a certificate with one or more accounts. A Smartcard with the certificate and the matching private key can then be used to authenticate as one of those accounts.

Currently SSSD basically only supports LDAP to lookup user information (the exception is the proxy provider which is not of relevance here). Because of this the mapping rule is based on LDAP search filter syntax with templates to add certificate content to the filter. It is expected that the filter will only contain the specific data needed for the mapping and that the caller will embed it in another filter to do the actual search. Because of this the filter string should start and stop with '(' and ')' respectively.

In general it is recommended to use attributes from the certificate and add them to special attributes to the LDAP user object. E.g. the 'altSecurityIdentities' attribute in AD or the 'ipaCertMapData' attribute for IPA can be used.

This should be preferred to read user specific data from the certificate like e.g. an email address and search for it in the LDAP server. The reason is that the user specific data in LDAP might change for various reasons would break the mapping. On the other hand it would be hard to break the mapping on purpose for a specific user.

The default “mapping rule” type is 'LDAP' which can be added as a prefix to a rule like e.g. 'LDAP:(userCertificate;binary={cert!bin})'. There is an extension called 'LDAPU1' which offer more templates for more flexibility. To allow older versions of this library to ignore the extension the prefix 'LDAPU1' must be used when using the new templates in a “mapping rule” otherwise the old version of this library will fail with a parsing error. The new templates are described in section the section called “LDAPU1 extension”.

The templates to add certificate data to the search filter are based on Python-style formatting strings. They consist of a keyword in curly braces with an optional sub-component specifier separated by a '.' or an optional conversion/formatting option separated by a '!'. Allowed values are:

{issuer_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

This template will add the full issuer DN converted to a string according to RFC 4514. If X.500 ordering (most specific RDN comes last) an option with the '_x500' prefix should be used. The conversion options starting with 'ad_' will use attribute names as used by AD, e.g. 'S' instead of 'ST'.

The conversion options starting with 'nss_' will use attribute names as used by NSS.

The default conversion option is 'nss', i.e. attribute names according to NSS and LDAP/RFC 4514 ordering.

Example: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})

{subject_dn[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

This template will add the full subject DN converted to string according to RFC 4514. If X.500 ordering (most specific RDN comes last) an option with the '_x500' prefix should be used. The conversion options starting with 'ad_' will use attribute names as used by AD, e.g. 'S' instead of 'ST'.

The conversion options starting with 'nss_' will use attribute names as used by NSS.

The default conversion option is 'nss', i.e. attribute names according to NSS and LDAP/RFC 4514 ordering.

Example: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})

{cert[!(bin|base64)]}

This template will add the whole DER encoded certificate as a string to the search filter. Depending on the conversion option the binary certificate is either converted to an escaped hex sequence '\xx' or base64. The escaped hex sequence is the default and can e.g. be used with the LDAP attribute 'userCertificate;binary'. Example: (userCertificate;binary={cert!bin})

{subject_principal[.short_name]}

This template will add the Kerberos principal which is taken either from the SAN used by pkinit or the one used by AD. The 'short_name' component represents the first part of the principal before the '@' sign. Example: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))

{subject_pkinit_principal[.short_name]}

This template will add the Kerberos principal which is given by the SAN used by pkinit. The 'short_name' component represents the first part of the principal before the '@' sign. Example: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))

{subject_nt_principal[.short_name]}

This template will add the Kerberos principal which is given by the SAN used by AD. The 'short_name' component represent the first part of the principal before the '@' sign. Example: (|(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.short_name}))

{subject_rfc822_name[.short_name]}

This template will add the string which is stored in the rfc822Name component of the SAN, typically an email address. The 'short_name' component represents the first part of the address before the '@' sign. Example: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))

{subject_dns_name[.short_name]}

This template will add the string which is stored in the dNSName component of the SAN, typically a fully-qualified host name. The 'short_name' component represents the first part of the name before the first '.' sign. Example: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))

{subject_uri}

This template will add the string which is stored in the uniformResourceIdentifier component of the SAN. Example: (uri={subject_uri})

{subject_ip_address}

This template will add the string which is stored in the iPAddress component of the SAN. Example: (ip={subject_ip_address})

{subject_x400_address}

This template will add the value which is stored in the x400Address component of the SAN as escaped hex sequence. Example: (attr:binary={subject_x400_address})

{subject_directory_name[!((ad|ad_x500)|ad_ldap|nss_x500|(nss|nss_ldap))]}

This template will add the DN string of the value which is stored in the directoryName component of the SAN. Example: (orig_dn={subject_directory_name})

{subject_ediparty_name}

This template will add the value which is stored in the ediPartyName component of the SAN as escaped hex sequence. Example: (attr:binary={subject_ediparty_name})

{subject_registered_id}

This template will add the OID which is stored in the registeredID component of the SAN as a dotted-decimal string. Example: (oid={subject_registered_id})

LDAPU1 extension

The following template are available when using the 'LDAPU1' extension:

{serial_number[!(dec|hex[_ucr])]}

This template will add the serial number of the certificate. By default it will be printed as a hexadecimal number with lower-case letters. With the formatting option '!dec' the number will be printed as decimal string. The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.

Example: LDAPU1:(serial={serial_number})

{subject_key_id[!hex[_ucr]]}

This template will add the subject key id of the certificate. By default it will be printed as a hexadecimal number with lower-case letters. The hexadecimal output can be printed with upper-case letters ('!hex_u'), with a colon separating the hexadecimal bytes ('!hex_c') or with the hexadecimal bytes in reverse order ('!hex_r'). The postfix letters can be combined so that e.g. '!hex_uc' will produce a colon-separated hexadecimal string with upper-case letters.

Example: LDAPU1:(ski={subject_key_id})

{cert[!DIGEST[_ucr]]}

This template will add the hexadecimal digest/hash of the certificate where DIGEST must be replaced with the name of a digest/hash function supported by OpenSSL, e.g. 'sha512'. The hexadecimal output can be printed with upper-case letters ('!sha512_u'), with a colon separating the hexadecimal bytes ('!sha512_c') or with the hexadecimal bytes in reverse order ('!sha512_r'). The postfix letters can be combined so that e.g. '!sha512_uc' will produce a colon-separated hexadecimal string with upper-case letters.

Example: LDAPU1:(dgst={cert!sha256})

{subject_dn_component[(.attr_name|[number]]}

This template will add an attribute value of a component of the subject DN, by default the value of the most specific component. A different component can it either selected by attribute name, e.g. {subject_dn_component.uid} or by position, e.g. {subject_dn_component.[2]} where positive numbers start counting from the most specific component and negative numbers start counting from the least specific component. Attribute name and the position can be combined as e.g. {subject_dn_component.uid[2]} which means that the name of the second component must be 'uid'.

Example: LDAPU1:(uid={subject_dn_component.uid})

{issuer_dn_component[(.attr_name|[number]]}

This template will add an attribute value of a component of the issuer DN, by default the value of the most specific component. See 'subject_dn_component' for details about the attribute name and position specifiers.

Example: LDAPU1:(domain={issuer_dn_component.[-2]}.{issuer_dn_component.dc[-1]})

{sid[.rid]}

This template will add the SID if the corresponding extension introduced by Microsoft with the OID 1.3.6.1.4.1.311.25.2 is available. With the '.rid' selector only the last component, i.e. the RID, will be added. Example: LDAPU1:(objectsid={sid})

### DOMAIN LIST
If the domain list is not empty users mapped to a given certificate are not only searched in the local domain but in the listed domains as well as long as they are know by SSSD. Domains not know to SSSD will be ignored.

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/


netconfig

package: libtirpc

title: netconfig(5)

summary: network configuration data base

text:
# netconfig(5)

## NAME
netconfig — network configuration data base

## SYNOPSIS
/etc/netconfig

## DESCRIPTION
The netconfig file defines a list of “transport names”, describing their semantics and protocol. In FreeBSD, this file is only used by the RPC library code.

Entries have the following format:

network_id semantics flags family protoname device libraries

Entries consist of the following fields:

network_id

The name of the transport described.

semantics

Describes the semantics of the transport. This can be one of: tpi_clts

Connectionless transport.

tpi_cots

Connection-oriented transport

tpi_cots_ord

Connection-oriented, ordered transport.

tpi_raw

A raw connection.

flags

This field is either blank (specified by “-”), or contains a “v”, meaning visible to the getnetconfig(3) function.

family

The protocol family of the transport. This is currently one of: inet6

The IPv6 (PF_INET6) family of protocols.

inet

The IPv4 (PF_INET) family of protocols.

loopback

The PF_LOCAL protocol family.

protoname

The name of the protocol used for this transport. Can currently be either udp, tcp or empty.

device

This field is always empty in FreeBSD.

libraries

This field is always empty in FreeBSD.

The order of entries in this file will determine which transport will be preferred by the RPC library code, given a match on a specified network type. For example, if a sample network config file would look like this:

```
udp6       tpi_clts      v     inet6    udp     -       -
tcp6       tpi_cots_ord  v     inet6    tcp     -       -
udp        tpi_clts      v     inet     udp     -       -
tcp        tpi_cots_ord  v     inet     tcp     -       -
rawip      tpi_raw       -     inet      -      -       -
local      tpi_cots_ord  -     loopback  -      -       -
```

then using the network type udp in calls to the RPC library function (see rpc(3)) will make the code first try udp6, and then udp.

getnetconfig(3) and associated functions will parse this file and return structures of the following format:

```
struct netconfig {
    char *nc_netid;              /* Network ID */
    unsigned long nc_semantics;  /* Semantics (see below) */
    unsigned long nc_flag;       /* Flags (see below) */
    char *nc_protofmly;          /* Protocol family */
    char *nc_proto;              /* Protocol name */
    char *nc_device;             /* Network device pathname (unused) */
    unsigned long nc_nlookups;   /* Number of lookup libs (unused) */
    char **nc_lookups;           /* Names of the libraries (unused) */
    unsigned long nc_unused[9];  /* reserved */
};
```

## FILES
/etc/netconfig

## SEE ALSO
getnetconfig(3), getnetpath(3)


fapi-config

title: fapi-config(5)

text:
# fapi-config(5)

## SEE ALSO
fapi-profile(5)

## DESCRIPTION
FAPI configuration file

The FAPI parameters which can be adjusted via the configuration file are;

•

profile_name: Name of the default cryptographic profile chosen from the profile_dir directory.

•

profile_dir: Directory that contains all cryptographic profiles known to FAPI.

•

user_dir: The directory where user objects are stored.

•

system_dir: The directory where system objects, policies, and imported objects are stored.

•

tcti: The TCTI interface which will be used.

•

system_pcrs: The PCR registers which are used by the system.

•

log_dir: The directory for the event log.

•

ek_cert_less: A switch to disable certificate verification (optional).

•

ek_fingerprint: The fingerprint of the endorsement key (optional).

If not otherwise specified during TSS installation, the default location for the exemplary profiles is /etc/tpm2-tss/profiles/ and /etc/tpm2-tss/ for the FAPI configuration file. The environment variable TSS2_FAPICONF can be used to set an alternative pathname for the FAPI configuration file.

## EXAMPLES
The FAPI configuration file is JSON encoded:

```
{
     "profile_name": "P_ECCP256SHA256",
     "profile_dir": "/etc/tpm2-tss/fapi-profiles/",
     "user_dir": "~/.local/share/tpm2-tss/user/keystore/",
     "system_dir": "/home/myhome/keystore/system/keystore",
     "tcti": "",
     "system_pcrs" : [0, 1, 2, 3, 4, 5, 6, 7],
     "log_dir" : "/home/myhome/eventlog/"
}

```

For this example the default TCTI of the system will be used. The certificates for the stored endorsement keys will be checked. If the certificate checking is not needed the option:

"ek_cert_less": "yes" can be added to the config file. Alternative to the standard certificate checking a fingerprint (hash of the public key) for the stored endorsement key can be defined in the config file:

"ek_fingerprint": { "hashAlg" : "sha256", "digest" : "9e56...214d" }

## COLOPHON
This page is part of release 3.2.0 of Open Source implementation of the TCG TPM2 Software Stack (TSS2). A description of the project, information about reporting bugs, and the latest version of this page can be found at https://github.com/tpm2-software/tpm2-tss/.


fapi-profile

title: fapi-profile(5)

text:
# fapi-profile(5)

## SEE ALSO
fapi-config(5)

## DESCRIPTION
FAPI Cryptographic Profile

Cryptographic profiles determine the cryptographic algorithms and parameters for all keys and operations of a specific TPM interaction. The values affected by these profiles are:

•

the name hash algorithm

•

asymmetric signature algorithm, scheme and parameters (such as curve, keysize, default padding, hash, etc)

•

PCR bank selection (which PCR banks shall be extended, quoted and read)

Two exemplary profiles for RSA and ECC are installed with the TSS. By default, the RSA cryptographic profile is activated. The user is free to create own cryptographic profiles according to his needs.

Specific profiles are activated in the FAPI configuration file. If not otherwise specified during TSS installation, the default location for the exemplary profiles is /etc/tpm2-tss/profiles/ and /etc/tpm2-tss/ for the FAPI configuration file.

The parameters of the profile are:

•

type: The asymmetric algorithm used for this profile.

•

nameAlg: The hash algorithm which will be used for sessions and keys.

•

srk_template: The type definition for the /SRK object. See the type parameter of Fapi_CreateKey.

•

srk_description: The description to be set for the /EK object. See Fapi_GetDescription.

•

ek_template: The type definition for the /EK object. See the type parameter of Fapi_CreateKey.

•

ek_description: The description to be set for the /SRK object. See Fapi_GetDescription.

•

ecc_signing_scheme: The signing scheme used for ECC keys.

•

rsa_signing_scheme: The signing scheme used for RSA keys.

•

keyBits: The key size for RSA keys.

•

exponent: The exponent of RSA keys.

•

sym_mode: The block cipher mode for symmetric encryption.

•

sym_parameters: The algorithm and parameters used for symmetric encryption.

•

sym_block_size: The block size used for symmetric encryption.

•

pcr_selection: The PCR registers and banks used by FAPI.

•

curveID: The curve ID for ECC keys.

•

ek_policy: The JSON encoded policy for the /EK object.

•

srk_policy: The JSON encoded policy for the /SRK object.

•

eh_policy: The JSON encoded policy for the endorsement hierarchy /HE.

•

sh_policy: The JSON encoded policy for the owner hierarchy /HS.

•

lockout_policy: The JSON encoded policy for the lockout hierarchy /LOCKOUT.

•

newMaxTries: Count of authorization failures before the lockout is imposed. If not set the default is 5.

•

newRecoveryTime: Time in seconds before the authorization failure count is automatically decremented. A value of zero indicates that DA protection is disabled. If not set the default is 1000.

•

lockoutRecovery: Time in seconds after a lockoutAuth failure before use of lockoutAuth is allowed A value of zero indicates that a reboot is required. If not set the default is 1000.

## EXAMPLES
The following JSON encoded example shows the standard profile for ECC keys:

```
{
    "type": "TPM2_ALG_ECC",
    "nameAlg":"TPM2_ALG_SHA256",
    "srk_template": "system,restricted,decrypt,0x81000001",
    "srk_description": "Storage root key SRK",
    "ek_template":  "system,restricted,decrypt",
    "ek_description": "Endorsement key EK",
    "ecc_signing_scheme": {
        "scheme":"TPM2_ALG_ECDSA",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        },
    },
    "sym_mode":"TPM2_ALG_CFB",
    "sym_parameters": {
        "algorithm":"TPM2_ALG_AES",
        "keyBits":"128",
        "mode":"TPM2_ALG_CFB"
    },
    "sym_block_size": 16,
    "pcr_selection": [
       { "hash": "TPM2_ALG_SHA1",
         "pcrSelect": [ ],
       },
       { "hash": "TPM2_ALG_SHA256",
         "pcrSelect": [ 8, 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 ]
       }
    ],
    "curveID": "TPM2_ECC_NIST_P256",
    "ek_policy": {
        "description": "Endorsement hierarchy used for policy secret.",
        "policy":[
            {
                "type":"POLICYSECRET",
                "objectName": "4000000b",
            }
        ]
    }
}

```

Beside the cryptographic parameters descriptions for the storage root key and the endorsement key can be set. For the endorsement hierarchy the policy "ek_policy" is set according to the TCG Credential profile EK 2.0. The values of the constants are the same as the constants defined in the TSS header files, where the prefix TPM2_ can be omitted.

The key type of the storage root key and the endorsement key is defined by the JSON fields srk_template and ek_template. The type consists of a list of comma and/or space separated keywords. If a keyword is not present the inverse of the reference TPM attribute bits SHALL be set or cleared. The keywords are:

•

sign: Sets the sign attribute of a key.

•

decrypt: Sets the decrypt attribute of a key.

•

If neither sign nor decrypt are provided, both attributes SHALL be set.

•

restricted: Sets the restricted attribute of a key.

•

If restricted is set, either sign or decrypt (but not both) SHALL be set.

•

noda: Sets the noda attribute of a key or NV index.

•

A hexadecimal number: Marks a key object to be made persistent and sets the persistent object handle to this value.

The RSA profile has specific values for the signing scheme and the decrypt scheme:

```
      "rsa_signing_scheme": {
        "scheme":"TPM2_ALG_RSAPSS",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        }
    "rsa_decrypt_scheme": {
        "scheme":"TPM2_ALG_OAEP",
        "details":{
            "hashAlg":"TPM2_ALG_SHA256"
        }
    },

```

Possible values for the signing schemes are:

•

RSA: RSASSA, RSAPSS

•

ECC: ECDSA, ECDAA

Possible modes for symmetric encryption are:

•

CTR, OFB, CBC, CFB, ECB, NULL

Possible modes for the RSA decrypt scheme are:

•

RSAES, OAEP

The following curve ids can be used:

•

ECC_NIST_P192, ECC_NIST_P224, ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521, ECC_BN_P256, ECC_BN_P638, ECC_SM2_P256

## COLOPHON
This page is part of release 3.2.0 of Open Source implementation of the TCG TPM2 Software Stack (TSS2). A description of the project, information about reporting bugs, and the latest version of this page can be found at https://github.com/tpm2-software/tpm2-tss/.


libuser.conf

package: libuser

title: libuser.conf(5)

text:
# libuser.conf(5)

## NAME
libuser.conf - configuration for libuser and libuser utilities

## FILE FORMAT
libuser.conf is a text file. Leading and trailing white space on each line is ignored. Lines starting with # are ignored.

The file defines variables grouped into sections. Each section starts with a section header:

[section name]

A single section header can appear more than once in the file. The lines following a section header define variables from that section:

variable = value

The value can be empty. A variable can have more than one value, specified by using more than one line defining that variable. All currently defined variables accept only the first value and ignore the others, if any.

## [defaults]
create_modules

A list of module names to use when creating user or group entries, unless the application specifies a different list. The module names in the list can be separated using space, tab or comma. Default value is files shadow.

crypt_style

The algorithm to use for password encryption when creating new passwords. The current algorithm may be retained when changing a password of an existing user, depending on the application. Possible values are des, md5, blowfish, sha256, sha512, and yescrypt, all case-insensitive. Unrecognized values are treated as des. Default value is des.

hash_rounds_min, hash_rounds_max

These variables specify an inclusive range of hash rounds used when crypt_style is sha256 or sha512. A number of hash rounds is chosen from this interval randomly. A larger number of rounds makes password checking, and brute-force attempts to guess the password by reversing the hash, more CPU-intensive. The number of rounds is restricted to the interval [1000, 999999999]. If only one of the above variables is specified, the number of rounds used is specified by the other variable. If neither variable is specified, the number of rounds is chosen by libc.

mailspooldir

The directory containing user's mail spool files. Default value is /var/mail.

moduledir

The directory containing libuser modules. Default value uses the modules installed with libuser, corresponding to the architecture of the libuser library, e.g. /usr/lib/libuser or /usr/lib64/libuser (assuming libuser was configured with --prefix=/usr).

modules

A list of module names to use when not creating user or group entries, unless the application specifies a different list. The module names in the list can be separated using space, tab or comma. Default value is files shadow.

skeleton

The directory containing files to copy to newly created home directories. Default value is /etc/skel.

## [import]
login_defs

A path to the login.defs file from shadow. If this variable is defined, the variables from the named file are used in place of some libuser variables. Variables explicitly defined in libuser.conf are not affected by contents of login.defs. The following variables are imported:

Variable

Imported as

ENCRYPT_METHOD

defaults/crypt_style

GID_MIN

groupdefaults/LU_GIDNUMBER

MAIL_DIR

defaults/mailspooldir

MD5_CRYPT_ENAB

defaults/crypt_style

PASS_MAX_DAYS

userdefaults/LU_SHADOWMAX

PASS_MIN_DAYS

userdefaults/LU_SHADOWMIN

PASS_WARN_AGE

userdefaults/LU_SHADOWWARNING

SHA_CRYPT_MIN_ROUNDS

defaults/hash_rounds_min

SHA_CRYPT_MAX_ROUNDS

defaults/hash_rounds_max

UID_MIN

userdefaults/LU_UIDNUMBER

The following variables are not imported: CREATE_HOME, GID_MAX, MAIL_FILE, SYSLOG_SG_ENAB, UID_MAX, UMASK, USERDEL_CMD, USERGROUPS_ENAB

default_useradd

A path to the default/useradd file from useradd in shadow. If this variable is defined, the variables from the named file are used in place of some libuser variables. Variables explicitly defined in libuser.conf are not affected by contents of default/useradd. The following variables are imported:

Variable

Imported as

EXPIRE

userdefaults/LU_SHADOWEXPIRE

GROUP

userdefaults/LU_GIDNUMBER

HOME

userdefaults/LU_HOMEDIRECTORY

INACTIVE

userdefaults/LU_SHADOWINACTIVE

SHELL

userdefaults/LU_LOGINSHELL

SKEL

defaults/skeleton

The HOME variable value has /%n appended to it before importing.

## [userdefaults]
This section defines attribute values of newly created user entities. There is one special variable:

LU_UIDNUMBER

A decimal number, the first allowed UID value for regular users (not system users). Default value is 500.

All other variables have the same names as the attribute names from <libuser/entity.h> and define attribute values. Either the macro name (e.g. LU_GECOS) or the macro content (e.g. pw_gecos) can be used; if both are used, the one appearing later in the configuration file is used.

The % character in the value of the variable introduces an escape sequence: %n is replaced by the user name, %d is replaced by current date in days since the epoch, %u is replaced by the user's UID. There is no way to escape the % character and avoid this substitution.

After the userdefaults section is processed, modules may define additional attributes or even override the attributes defined in this section.

## [groupdefaults]
The groupdefaults section is similar to userdefaults. There is one special variable:

LU_GIDNUMBER

A decimal number, the first allowed GID value for regular groups (not system groups). Default value is 500.

The other variables follow the same rules as in the userdefaults section, except that %n and %u are replaced by the group name and group's GID, respectively.

After the groupdefaults section is processed, modules may define additional attributes or even override the attributes defined in this section.

## [files]
Configures the files module, which manages /etc/group and /etc/passwd. The configuration variables are probably useful only for libuser development.

directory

The directory containing the group and passwd files. Default value is /etc.

nonroot

Allow module initialization when not invoked as the root user if the value is yes.

## [shadow]
Configures the files module, which manages /etc/gshadow and /etc/shadow. The configuration variables are probably useful only for libuser development.

directory

The directory containing the gshadow and shadow files. Default value is /etc.

nonroot

Allow module initialization when not invoked as the root user if the value is yes.

## [ldap]
Configures the ldap module, which manages an user database accessible using LDAP.

userBranch

The LDAP suffix for user entities. Default value is ou=People.

groupBranch

The LDAP suffix for group entities. Default value is ou=Group.

server

A domain name or an URI of the LDAP server. The URI can use the ldap, ldapi or the ldaps protocol. When a simple domain name is used, the connection fails if TLS can not be used; an URI using the ldap protocol allows connection without TLS. TLS is never used with the ldapi protocol. Default value is ldap.

basedn

The base DN of the server. Default value is dc=example,dc=com.

binddn

A DN for binding to the server. If the value is empty or binding using this DN fails, a DN of uid=user,userBranch,basedn is used, where userBranch and basedn are variables from this section and user is the user name of the invoking user, unless overridden by the user variable from this section. Default value is cn=manager,dc=example,dc=com.

user

The SASLv2 identity for authenticating to the LDAP server, also overrides the user name for generating a bind DN. Default value is the name of the invoking user.

password

The password used for a simple bind by default. If not specified, there is no default and the user must supply the password each time. IT IS STRONGLY RECOMMENDED NOT TO STORE A PASSWORD IN THE SYSTEM-WIDE /etc/libuser.conf FILE. The configuration file is world-readable by default, and setuid programs that prompt for a server name could be used to send the password to an attacker-controlled server.

authuser

The SASLv2 authorization user, if non-empty. Default value is empty.

bindtype

The list of bind types to use, separated by commas. Allowed bind types are simple, sasl, and sasl/mechanism, where mechanism is a SASL mechanism. The bind types (but not necessarily mechanism) are case-insensitive. If more than one bind type is specified, their relative order is ignored. Default value is simple,sasl.

## [sasl]
Configures the sasl module, which manages a SASLv2 user database.

appname

Name of the SASLv2 application. Default value is empty.

domain

Domain used by libuser for the SASLv2 authentication object. Default value is empty.

## BUGS
Invalid lines in the configuration file (or the imported shadow configuration files) are silently ignored.

## FILES
/etc/libuser.conf

The default location of the configuration file. Can be overridden by the LIBUSER_CONF environment variable, except in set-uid or set-gid programs.


xforms

package: libxforms

title: xforms(5)

summary: A GUI Toolkit for X Window Systems

text:
# xforms(5)

## NAME
xforms - A GUI Toolkit for X Window Systems

## SYNOPSIS
Forms Library for X (xforms) is a GUI toolkit and builder for the X Window Systems and runs on all major UNIX platforms as well as OpenVMS and OS2. Forms Library is too complex to be described in the "man" page format. Ask your system administrator for the location of the HTML, PDF or PostScript document or follow the links on the Forms Library's home page for an online version of the documentation.

## DESCRIPTION
Forms Library is a graphical user interface toolkit based on Xlib for X Window Systems. It comes with a rich set of objects such as buttons, browsers, sliders and menus integrated into an elegant event/object callback execution model that allows fast and easy construction of X applications. In addition, the library has support for image read and write, format conversion and simple image processing. The library consists of a flexible set of C-routines that can be used in C and C++ programs (As of this writing, perl, ada95, pascal, scheme and Fortran bindings to the Forms Library are in beta.)

The library is efficient and portable and runs on all major Unix platforms, including Sun, SGI, HP, DEC Alpha/OSF, IBM RS6000, Convex, Cray, Linux, FreeBSD, NetBSD, SCO, Unixware, OpenBSD , BSDi, DecSystem(mips)/Ultrix and others. Non-unix platforms include OpenVMS, OS/2, and Window/NT.

Bundled with the library is also a Form designer, fdesign, which can be used to build interaction forms in a WYSIWYG (what you see is what you get) way and to generate the corresponding C (or any of the binding languages) code for you. 50+ demos in source code are distributed with the library.

## OPTIONS
All programs written using the Forms Library recognize the following command line options

-display host:dpy

specifies the server to connect to.

-bw borderwidth

specifies the border width to use for built-in objects.

-flversion

prints the xforms version information.

-visual visualName

requests a visual by name such as TrueColor etc. By default the Forms Library always selects the visual that has the most depth.

-depth depth

requests a specific depth.

-fldebug level

generates some info about the state of the XForms. where level is an integer between 1-5 and controls the amount of information to output. Depending on the options used when the Forms Library was built, a level more than 3 might not be available.

-sync

runs the application in synchronous mode with debug level set to 4.

-private

requests a private colormap for the application.

-shared

requests a shared colormap even if the application needs more colors than available. For those colors that can't be allocated in the shared colormap, substitutions are made so the closest matching color is used.

-stdcmap

requests a standard colormap.

-name newname

specifies the application name under which resources are to be obtained, rather than the default executable file name.

## SEE ALSO
fdesign(1L), fd2ps(1L)

## AUTHOR
Copyright (c) 1996-2002 T.C. Zhao, Mark Overmars and Steve Lamont

Since 2002: GNU Lesser General Public License

Maintainers: Jean-Marc Lasgouttes, Angus Leeming, Jens Thoms Toerring <jt@toerring.de>

## HOME PAGE
http://xforms-toolkit.org

http://savannah.nongnu.org/projects/xforms/


title: xine2(5)

summary: a free video player

text:
# xine2(5)

## NAME
xine - a free video player

## MRL (media resource locator)
MRLs are similar to URLs in your web browser. They describe the media to read from. Valid MRLs may be plain file names or one of the following (see also the notes below):

• Filesystem:

file:<path>

fifo:<path>

stdin:/

• CD and DVD:

dvd:/[device_name][/title[.part]]

dvd:/DVD_image_file[/title[.part]]

dvd:/DVD_directory[/title[.part]]

(use the path of the directory which contains VIDEO_TS)

vcd://[CD_image_or_device_name][@[letter]number]

vcdo://track_number

cdda:/[device][/track_number]

• Video devices:

v4l://[tuner_device/frequency]

v4l2://tuner_device

dvb://channel_number

(nth channel in your channels.conf)

dvb://channel_name

dvbc://channel_name:tuning_parameters

dvbs://channel_name:tuning_parameters

dvbt://channel_name:tuning_parameters

dvba://channel_name:tuning_parameters

pvr:/tmp_files_path!saved_files_path!max_page_age

(for WinTV PVR 250 and 350)

• Network:

http://host...

tcp://host[:port]

udp://host[:port[?iface=interface]]

rtp://host[:port[?iface=interface]]

(default port for tcp, udp and rtp is 7658)

smb://...

mms://host...

pnm://host...

rtsp://host... (requires Real codecs)

Additional input plugins will provide additional MRL types. The ones listed above are available with stock libxine.

NOTE: where a file name is required, the full path must be provided - from a shell, you can normally use "$PWD/file" or "$(pwd)/file" or "`pwd`/file" if the file is in the current directory. (Which one depends on your shell; all three work in bash. Also, normal URL encoding rules apply; `%', in particular, must be encoded as `%25'.)

As of xine-lib 1.1.3, the DVD title number may be 0 (select navigation) and the chapter number may be 0 (full title).

### VCD MRL Syntax
A simple vcd:/ runs the default item (e.g. perhaps track 1 or entry 0) using the default VCD device (perhaps /dev/cdrom). Both the default item and default device are user-configurable.

It is however also possible to specify both Video CD device/filename and item explicitly in the MRL.

For example vcd:/dev/dvd specifies the default entry using device /dev/dvd which might useful if this is your DVD which is different than your CD-ROM device and your DVD drive can play CD's. And vcd://test_svcd_ntsc.cue specifies the cue file for CD image on disk. (test_svcd_ntsc.bin is the corresponding bin file, but using that won't work.)

After the optional device name or file name, you can name the kind of unit, preceded by a colon. An MRL which ends in a colon is like not adding it at all: the default entry type and number is used. Items come in 4 flavours: "Track", "Entry", "Playback" and "Segment". These units are indicated with the capital first letter of each type: T, E, P, S, s. An uppercase S in the MRL display indicates a NTSC segment while a lowercase s indicates a PAL segment. However, when you enter an MRL, the case of these letters is insignificant.

Depending on the Video CD, you might not have any playable segments (S,s) or playback control (P). If you give a MRL that refers to a playback control entry but there is no playback control, your playback number will silently be converted into the corresponding entry number.

You can configure various things that affect MRLs are selected when there is some ambiguity in the MRL name. media.vcd.autoplay sets what kind of unit to to use in a MRL is none is given. Another configuration setting, vcd.device, determines what device to use if that part is not given. When you hit the VCD button, that is equivalent to entering vcd:/ and thus these two configuration settings are used to expand the MRL.

Some examples of MRLs are given below. In the examples, we assume the following configuration settings:

vcd://

Play (navigate) default item (in this case Entry ID 0) from the default device (in this case set to /dev/cdrom)

vcd://@

Same as above

vcd:///dev/cdrom@

Same effect as above since the default device is set to /dev/cdrom.

vcd:///dev/cdrom@E0

Same as above. But note that this is because we have autoplay:entry which is no longer the default value.

vcd:///dev/cdrom2@

Play (navigate) the default item of /dev/cdrom2

vcd:///dev/cdrom2

should be same as above but is currently broken?

vcd:///dev/cdrom2@T1

Play Track 1 from /dev/cdrom2

vcd:///dev/cdrom@S1

Play segment 1 from /dev/cdrom. This assumes that there *is* a segment 1. Check the MRL list to see if that is the case.

vcd://@P1

Play playlist item 1 from default device. If there is no playback control, the MRL will be converted into vcd:/@E0. Again check the MRL list to see if there is a P1.

vcd://@P1*

Probably same as above.

vcd:///dev/cdrom@E1

Play Entry id 1 from default device.

vcd://@S0

Play segment 0 from default device.

vcd://@3

Play track 3 from default device.

vcd:///dev/cdrom2:1

Play track 1 from /dev/cdrom2.

vcd:///tmp/ntsc.cue@

Play default item (E0) of /tmp/ntsc.bin. Note trailing @.

vcd://ntsc.cue/@E0

Play entry 0 of ntsc.bin.

vcd:///tmp/ntsc.nrg/@E0

Play entry 0 of /tmp/ntsc.nrg (Nero file). Works for some simple Nero images.

### DVB
DVB MRLs require that xine-lib/channels.conf exists in $XDG_CONFIG_HOME/ or ~/.config/ and contains valid data. This can be obtained by generating a tuning file using the LinuxTV DVB apps utility "scan" (or "dvbscan" if you're using a version newer than 1.1.0):

scan -o zap /usr/share/doc/dvb-utils/examples/scan/dvb-t/uk-PontopPike >~/.config/xine-lib/channels.conf

(This example is for the writer's local transmitter, using a file from the Debian dvb-utils package.)

For the dvbc, dvbs and dvbt MRLs, tuning parameters are expected, taking one of the following forms:

DVB-S

<frequency>:<polarisation>:<sat-no>:<sym-rate>:<vpid>:<apid>:<service-id>

DVB-C

<frequency>:<inversion>:<sym-rate>:<fec>:<qam>:<vpid>:<apid>:<service-id>

DVB-T

<frequency>:<inversion>:<bw>:<fec-hp>:<fec-lp>:<qam>:<transmission-mode>:<guardlist>:<hierarchy-info>:<vpid>:<apid>:<service-id>

DVB-A

<frequency>:<qam>:<vpid>:<apid>:<service-id>

The individual parameters are:

frequency

number, usually in kHz

polarisation

`v' or `h'

sat-no

unsigned long, usually 0

sym-rate

symbol rate in MSyms/sec

inversion

INVERSION_ON, INVERSION_OFF, INVERSION_AUTO

fec, fec-hp, fec-lp

FEC_1_2, FEC_2_3, FEC_3_4 ... FEC_8_9, FEC_AUTO, FEC_NONE

qam

QPSK, QAM_128, QAM_16 ...

bw

BANDWIDTH_6_MHZ, BANDWIDTH_7_MHZ, BANDWIDTH_8_MHZ

transmission-mode

TRANSMISSION_MODE_2K, TRANSMISSION_MODE_8K

guardlist

GUARD_INTERVAL_1_4, GUARD_INTERVAL_1_8, GUARD_INTERVAL_1_16, GUARD_INTERVAL_1_32,

hierarchy-info

HIERARCHY_1, HIERARCHY_2, HIERARCHY_4, HIERARCHY_NONE

vpid

video program ID

apid

audio program ID

service-id

service ID (needed for now/next information etc.)

The following keyboard & mouse inputs may be accepted:

Menu 2

Start/stop recording

Menu 3

Toggle zoom

Menu 7

Toggle now/next display

Previous/Next Chapter

Previous/next channel

Mouse wheel & button 1

Scroll through channel list & select the highlighted channel

## SUBTITLE
external subtitle files (any mrl)

Text subtitle files may be appended to the MRL:.

<mrl>#subtitle:<subtitlefile>

This is the normal way to define the subtitle file to use. The frontend will not take any notice of the subtitle file. For example:

file://home/user/wibble.mpg#subtitle:/home/user/wibble.sub

(Note that some front ends can detect subtitles files where the name differs as shown in the example.)

## STREAM OPTIONS
After a delimiting # you can add several stream parameters:

novideo

Video will be ignored.

noaudio

Audio will be ignored.

nospu

Subpictures will be ignored.

demux:<demux name>

Specify the demux plugin to use.

volume:<level>

Set audio volume.

compression:<level>

Set audio dynamic range compression.

<config entry>:<config value>

Assign a new value to any config entry.

save:<file>

Save the stream (if allowed) to the named file, relative to the directory given by the option "media.capture.save_dir".

change configuration option 'on the fly':

You can change a configuration option at any time, using the special cfg:/ MRL style. The syntax is:

cfg:/<config entry> : <config value>

Unlike stream config option, you can change anything before playing the stream.

## SEE ALSO
xine(1), aaxine(1), gxine(1), toxine(1), totem(1), kaffeine(1) ...

The programs are documented fully on the xine home page: http://www.xine-project.org/

## AUTHOR
This text was extracted from the xine man page by Darren Salt <dsalt@users.sourceforge.net>. The xine man page was written by Siggi Langauf <siggi@debian.org> for the xine project. Lots of additions by Guenter Bartsch <guenter@users.sourceforge.net>, Daniel Caujolle-Bert <f1rmb@users.sourceforge.net>, Rocky Bernstein <rocky@panix.com>, and Philipp Hahn <pmhahn@users.sourceforge.net>.