openssl-LibreSSL.cnf

title: openssl-LibreSSL.cnf(5)

summary: OpenSSL configuration files

text:
# openssl-LibreSSL.cnf(5)

## NAME
openssl.cnf — OpenSSL configuration files

## DESCRIPTION
The OpenSSL CONF library can be used to read configuration files; see CONF_modules_load_file(3). It is used for the OpenSSL master configuration file /etc/libressl/openssl.cnf and in a few other places like SPKAC files and certificate extension files for the openssl-LibreSSL(1) x509 utility. OpenSSL applications can also use the CONF library for their own purposes.

A configuration file is divided into a number of sections. Each section starts with a line [section_name] and ends when a new section is started or the end of the file is reached. A section name can consist of alphanumeric characters and underscores.

The first section of a configuration file is special and is referred to as the “default section”. It is usually unnamed and extends from the start of file to the first named section. When a name is being looked up, it is first looked up in a named section (if any) and then in the default section.

The environment is mapped onto a section called ENV.

Comments can be included by preceding them with the ‘#’ character.

Each section in a configuration file consists of a number of name and value pairs of the form name=value.

The name string can contain any alphanumeric characters as well as a few punctuation symbols such as ‘.’ ‘,’ ‘;’ and ‘_’.

The value string consists of the string following the ‘=’ character until the end of the line with any leading and trailing whitespace removed.

The value string undergoes variable expansion. This can be done by including substrings of the form $name or ${name}: this will substitute the value of the named variable in the current section. It is also possible to substitute a value from another section using the syntax $section::name or ${section::name}. By using the form $ENV::name, environment variables can be substituted. It is also possible to assign values to environment variables by using the name ENV::name. This will work if the program looks up environment variables using the CONF library instead of calling getenv(3) directly. The value string must not exceed 64k in length after variable expansion or an error will occur.

It is possible to escape certain characters by using any kind of quote or the ‘\’ character. By making the last character of a line a ‘\’, a value string can be spread across multiple lines. In addition the sequences ‘\n’, ‘\r’, ‘\b’, and ‘\t’ are recognized.

## OPENSSL LIBRARY CONFIGURATION
Applications can automatically configure certain aspects of OpenSSL using the master OpenSSL configuration file, or optionally an alternative configuration file. The openssl-LibreSSL(1) utility includes this functionality: any sub command uses the master OpenSSL configuration file unless an option is used in the sub command to use an alternative configuration file.

To enable library configuration, the default section needs to contain an appropriate line which points to the main configuration section. The default name is openssl_conf, which is used by the openssl-LibreSSL(1) utility. Other applications may use an alternative name such as myapplication_conf. All library configuration lines appear in the default section at the start of the configuration file.

The configuration section should consist of a set of name value pairs which contain specific module configuration information. The name represents the name of the configuration module. The meaning of the value is module specific: it may, for example, represent a further configuration section containing configuration module specific information. For example:

```
# The following line must be in the default section.
openssl_conf = openssl_init

[openssl_init]
oid_section = new_oids
engines = engine_section

[new_oids]
... new oids here ...

[engine_section]
... engine stuff here ...
```

The features of each configuration module are described below.

### ASN1 Object Configuration Module
This module has the name oid_section. The value of this variable points to a section containing name value pairs of OIDs: the name is the OID short and long name, and the value is the numerical form of the OID. Although some of the openssl-LibreSSL(1) utility subcommands already have their own ASN1 OBJECT section functionality, not all do. By using the ASN1 OBJECT configuration module, all the openssl-LibreSSL(1) utility subcommands can see the new objects as well as any compliant applications. For example:

```
[new_oids]
some_new_oid = 1.2.3.4
some_other_oid = 1.2.3.5
```

It is also possible to set the value to the long name followed by a comma and the numerical OID form. For example:

shortName = some object long name, 1.2.3.4

### Engine Configuration Module
This ENGINE configuration module has the name engines. The value of this variable points to a section containing further ENGINE configuration information.

The section pointed to by engines is a table of engine names (though see engine_id below) and further sections containing configuration information specific to each ENGINE.

Each ENGINE specific section is used to set default algorithms, load dynamic ENGINEs, perform initialization and send ctrls. The actual operation performed depends on the command name which is the name of the name value pair. The currently supported commands are listed below.

For example:

```
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section
# Configure ENGINE named "bar"
bar = bar_section

[foo_section]
... foo ENGINE specific commands ...

[bar_section]
... "bar" ENGINE specific commands ...
```

The command engine_id is used to give the ENGINE name. If used, this command must be first. For example:

```
[engine_section]
# This would normally handle an ENGINE named "foo"
foo = foo_section

[foo_section]
# Override default name and use "myfoo" instead.
engine_id = myfoo
```

The command dynamic_path loads and adds an ENGINE from the given path. It is equivalent to sending the ctrls SO_PATH with the path argument followed by LIST_ADD with value 2 and LOAD to the dynamic ENGINE. If this is not the required behaviour then alternative ctrls can be sent directly to the dynamic ENGINE using ctrl commands.

The command init determines whether to initialize the ENGINE. If the value is 0, the ENGINE will not be initialized. If it is 1, an attempt is made to initialized the ENGINE immediately. If the init command is not present, then an attempt will be made to initialize the ENGINE after all commands in its section have been processed.

The command default_algorithms sets the default algorithms an ENGINE will supply using the functions ENGINE_set_default_string(3).

If the name matches none of the above command names, it is assumed to be a ctrl command which is sent to the ENGINE. The value of the command is the argument to the ctrl command. If the value is the string EMPTY, then no value is sent to the command.

For example:

```
[engine_section]
# Configure ENGINE named "foo"
foo = foo_section

[foo_section]
# Load engine from DSO
dynamic_path = /some/path/fooengine.so
# A foo specific ctrl.
some_ctrl = some_value
# Another ctrl that doesn't take a value.
other_ctrl = EMPTY
# Supply all default algorithms
default_algorithms = ALL
```

## FILES
/etc/libressl/openssl.cnf

standard configuration file

## EXAMPLES
Here is a sample configuration file using some of the features mentioned above:

```
# This is the default section.
HOME=/temp
RANDFILE= ${ENV::HOME}/.rnd
configdir=$ENV::HOME/config

[ section_one ]
# We are now in section one.

# Quotes permit leading and trailing whitespace
any = " any variable name "

other = A string that can \
cover several lines \
by including \\ characters

message = Hello World\n

[ section_two ]
greeting = $section_one::message
```

This next example shows how to expand environment variables safely.

Suppose you want a variable called tmpfile to refer to a temporary filename. The directory it is placed in can determined by the TEMP or TMP environment variables but they may not be set to any value at all. If you just include the environment variable names and the variable doesn't exist then this will cause an error when an attempt is made to load the configuration file. By making use of the default section both values can be looked up with TEMP taking priority and /tmp used if neither is defined:

```
TMP=/tmp
# The above value is used if TMP isn't in the environment
TEMP=$ENV::TMP
# The above value is used if TEMP isn't in the environment
tmpfile=${ENV::TEMP}/tmp.filename
```

More complex OpenSSL library configuration. Add OID:

```
# Default appname: should match "appname" parameter (if any)
# supplied to CONF_modules_load_file et al.
openssl_conf = openssl_conf_section

[openssl_conf_section]
# Configuration module list
alg_section = evp_sect
oid_section = new_oids

[new_oids]
# New OID, just short name
newoid1 = 1.2.3.4.1
# New OID shortname and long name
newoid2 = New OID 2 long name, 1.2.3.4.2
```

The above examples can be used with any application supporting library configuration if "openssl_conf" is modified to match the appropriate "appname".

For example if the second sample file above is saved to "example.cnf" then the command line:

OPENSSL_CONF=example.cnf openssl-LibreSSL asn1parse -genstr OID:1.2.3.4.1

will output:

0:d=0 hl=2 l= 4 prim: OBJECT :newoid1

showing that the OID "newoid1" has been added as "1.2.3.4.1".

## SEE ALSO
openssl-LibreSSL(1), CONF_modules_load_file(3), OPENSSL_config(3), x509v3.cnf(5)

## CAVEATS
If a configuration file attempts to expand a variable that doesn't exist, then an error is flagged and the file will not load. This can also happen if an attempt is made to expand an environment variable that doesn't exist. For example, in a previous version of OpenSSL the default OpenSSL master configuration file used the value of HOME which may not be defined on non Unix systems and would cause an error.

This can be worked around by including a default section to provide a default value: then if the environment lookup fails, the default value will be used instead. For this to work properly, the default value must be defined earlier in the configuration file than the expansion. See the EXAMPLES section for an example of how to do this.

If the same variable is defined more than once in the same section, then all but the last value will be silently ignored. In certain circumstances such as with DNs, the same field may occur multiple times. This is usually worked around by ignoring any characters before an initial ‘.’, for example:

```
1.OU="My first OU"
2.OU="My Second OU"
```

## BUGS
Currently there is no way to include characters using the octal \nnn form. Strings are all NUL terminated, so NUL bytes cannot form part of the value.

The escaping isn't quite right: if you want to use sequences like ‘\n’, you can't use any quote escaping on the same line.

Files are loaded in a single pass. This means that a variable expansion will only work if the variables referenced are defined earlier in the file.


ppdcfile

package: libcups-devel

title: ppdcfile(5)

text:
# ppdcfile(5)

## NAME
ppdcfile - cups ppd compiler source file format (deprecated)

## DESCRIPTION
The CUPS PPD compiler reads meta files that contain descriptions of one or more PPD files to be generated by ppdc(1). This man page provides a quick reference to the supported keywords and should be used in conjunction with the online help for CUPS.

The source file format is plain ASCII text that can be edited using your favorite text editor. Comments are supported using the C (/* ... */) and C++ (// ...) comment mechanisms.

Printer driver information can be grouped and shared using curly braces ({ ... }); PPD files are written when a close brace or end-of-file is seen and a PCFileName directive has been defined.

Directives may be placed anywhere on a line and are followed by one or more values. The following is a list of the available directives and the values they accept:

\#define name value

\#elif {name | value}

\#else

\#endif

\#font name encoding "version" charset status

\#if {name | value}

\#include <filename>

\#include "filename"

\#media name width length

\#media "name/text" width length

\#po locale "filename"

Attribute name "" value

Attribute name keyword value

Attribute name "keyword/text" value

Choice name "code"

Choice "name/text" "code"

ColorDevice boolean-value

ColorModel name colorspace colororder compression

ColorModel "name/text" colorspace colororder compression

ColorProfile resolution/mediatype gamma density matrix

Copyright "text"

CustomMedia name width length left bottom right top "size-code" "region-code"

CustomMedia "name/text" width length left bottom right top "size-code" "region-code"

Cutter boolean-value

Darkness temperature name

Darkness temperature "name/text"

DriverType type

Duplex type

Filter mime-type cost program

Finishing name

Finishing "name/text"

Font *

Font name encoding "version" charset status

Group name

Group "name/text"

HWMargins left bottom right top

InputSlot position name

InputSlot position "name/text"

Installable name

Installable "name/text"

LocAttribute name "keyword/text" value

ManualCopies boolean-value

Manufacturer "name"

MaxSize width length

MediaSize name

MediaType type name

MediaType type "name/text"

MinSize width length

ModelName "name"

ModelNumber number

Option name type section order

Option "name/text" type section order

PCFileName "filename.ppd"

Resolution colorspace bits-per-color row-count row-feed row-step name

Resolution colorspace bits-per-color row-count row-feed row-step "name/text"

SimpleColorProfile resolution/mediatype density yellow-density red-density gamma red-adjust green-adjust blue-adjust

Throughput pages-per-minute

UIConstraints "*Option1 *Option2"

UIConstraints "*Option1 Choice1 *Option2"

UIConstraints "*Option1 *Option2 Choice2"

UIConstraints "*Option1 Choice1 *Option2 Choice2"

VariablePaperSize boolean-value

Version number

## NOTES
PPD files are deprecated and will no longer be supported in a future feature release of CUPS. Printers that do not support IPP can be supported using applications such as ippeveprinter(1).

## SEE ALSO
ppdc(1), ppdhtml(1), ppdi(1), ppdmerge(1), ppdpo(1), CUPS Online Help (http://localhost:631/help)

## COPYRIGHT
Copyright © 2020-2024 by OpenPrinting.


dat.conf

package: libdapl

title: dat.conf(5)

text:
# dat.conf(5)

## NAME
dat.conf - configuration file for static registration of user-level DAT rdma providers

## DESCRIPTION
The DAT (direct access transport) architecture supports the use of multiple DAT providers within a single consumer application. Consumers implicitly select a provider using the Interface Adapter name parameter passed to dat_ia_open().

The subsystem that maps Interface Adapter names to provider implementations is known as the DAT registry. When a consumer calls dat_ia_open(), the appropriate provider is found and notified of the consumer's request to access the IA. After this point, all DAT API calls acting on DAT objects are automatically directed to the appropriate provider entry points.

A persistent, administratively configurable database is used to store mappings from IA names to provider information. This provider information includes: the file system path to the provider library object, version information, and thread safety information. The location and format of the registry is platform dependent. This database is known as the Static Registry (SR) and is provided via entries in the dat.conf file. The process of adding a provider entry is termed Static Registration.

## Registry File Format

* All characters after # on a line are ignored (comments).

* Lines on which there are no characters other than whitespace

and comments are considered blank lines and are ignored.

* Non-blank lines must have seven whitespace separated fields.

These fields may contain whitespace if the field is quoted

with double quotes. Within fields quoated with double quotes,

the backslash or qoute are valid escape sequences:

* Each non-blank line will contain the following fields:

- The IA Name.

- The API version of the library:

[k|u]major.minor where "major" and "minor" are both integers

in decimal format. User-level examples: "u2.0".

- Whether the library is thread-safe: [threadsafe|nonthreadsafe]

- Whether this is the default section: [default|nondefault]

- The library image, version included, to be loaded.

- The vendor id and version of DAPL provider: id.major.minor

- ia params, IA specific parameters - device name and port

- platform params, (not used)

## OpenFabrics RDMA providers:

Provider options for different CM services

1. cma - OpenFabrics rdma_cm - uses rdma_cm services for connections

- requires IPoIB and SA/SM services for IB

- netdev used for device name, without port designation (ia_params)

- Supports any transport rdma_cm supports including IB, iWARP, RoCEE

- libdaplofa (2.0)

2. scm - uDAPL socket based CM - exchanges CM information over sockets

- eliminates the need for rdma_cm, IPoIB, and SA for IB

- verbs device used for device name with port designation (ia_param)

- Supports IB, RoCEE. Doesn't support iWARP

- libdaploscm (2.0)

3. ucm - uDAPL unreliable IB CM - exchanges CM information via IB UD QP's

- eliminates the need for sockets or rdma_cm

- verbs device used for device name with port designation (ia_param)

- Supports IB only, no name service.

- libdaploucm (2.0)

## Example entries for each OpenFabrics provider

1. cma - OpenFarbrics rdma_cm examples

ofa-v2-ib0 u2.0 nonthreadsafe default libdaplofa.so.2 dapl.2.0 "ib0 0" ""

ofa-v2-iwarp u2.0 nonthreadsafe default libdaplofa.so.2 dapl.2.0 "eth2 0" ""

ofa-v2-cma-roe-eth2 u2.0 nonthreadsafe default libdaplofa.so.2 dapl.2.0 "eth2 0" ""

ofa-v2-cma-roe-eth3 u2.0 nonthreadsafe default libdaplofa.so.2 dapl.2.0 "eth3 0" ""

NOTE: The OpenFabrics CMA providers use <ia_params> to specify the device with one of the following:

network address, network hostname, or netdev name; along with port number.

2. scm - uDAPL socket based CM v2.0 examples

ofa-v2-mlx4_0-1 u2.0 nonthreadsafe default libdaploscm.so.2 dapl.2.0 "mlx4_0 1" ""

ofa-v2-mlx4_0-2 u2.0 nonthreadsafe default libdaploscm.so.2 dapl.2.0 "mlx4_0 2" ""

ofa-v2-mlx5_1-1 u2.0 nonthreadsafe default libdaploscm.so.2 dapl.2.0 "mlx5_1 1" ""

ofa-v2-ehca0-1 u2.0 nonthreadsafe default libdaploscm.so.2 dapl.2.0 "ehca0 1" ""

ofa-v2-scm-roe-mlx5_0-1 u2.0 nonthreadsafe default libdaploscm.so.2 dapl.2.0 "mlx5_0 1" ""

3. ucm - uDAPL unreliable IB CM examples

ofa-v2-mlx4_0-1u u2.0 nonthreadsafe default libdaploucm.so.2 dapl.2.0 "mlx4_0 1" ""

ofa-v2-mlx4_0-2u u2.0 nonthreadsafe default libdaploucm.so.2 dapl.2.0 "mlx4_0 2" ""

ofa-v2-ipath0-1u u2.0 nonthreadsafe default libdaploucm.so.2 dapl.2.0 "ipath0 1" ""

ofa-v2-ehca0-1u u2.0 nonthreadsafe default libdaploucm.so.2 dapl.2.0 "ehca0 1" ""

Note: OpenIB- and ofa-v2- IA names are unique mappings, reserved for OpenFabrics providers.

The default location for this configuration file is /etc/dat.conf.

The file location may be overridden with the environment variable DAT_OVERRIDE=/your_own_directory/your_dat.conf.


libdskrc

package: libdsk-progs

title: libdskrc(5)

text:
# libdskrc(5)

## NAME
libdskrc - Custom format definitions for LibDSK programs

## DESCRIPTION
The libdskrc file contains definitions of disk geometries, which can be used by the LibDsk utilities dsktrans(1) , dskid(1) and dskform(1)

The file consists of one or more sections, each describing one disk layout. Each section begins with the format name in square brackets, and continues until the next section begins. Within each section are one or more entries of the form

variable = value

Anything after a semicolon or hash character is treated as a comment and ignored. Blank lines are also ignored.

## PARAMETERS
For each geometry, the entries listed below can be present. If not all the values are present, LibDsk will use default values from its "pcw180" format (40 tracks, 9 sectors, single-sided, MFM).

description = DESC

The description of the format as shown by (for example) dskform --help.

sides = TREATMENT

How a double-sided disk is handled. This can either be alt (sides alternate -- used by most PC-hosted operating systems), outback (use side 0 tracks 0-79, then side 1 tracks 79-0 -- used by 144FEAT CP/M disks), or outout (use side 0 tracks 0-79, then side 1 tracks 0-79 -- used by some Acorn formats). If the disk is single-sided, this parameter can be omitted.

cylinders = COUNT

Sets the number of cylinders (usually 40 or 80).

heads = COUNT

Sets the number of heads (usually 1 or 2 for single- or double-sided).

sectors = COUNT

Sets the number of sectors per track.

secbase = NUMBER

Sets the first sector number on a track. Usually 1; some Acorn formats use 0.

secsize = COUNT

Sets the size of a sector in bytes. This should be a power of 2.

datarate = VALUE

Sets the rate at which the disk should be accessed. This is one of HD (1.4Mb or 1.2Mb), DD (360k or 720k disc in 1.2Mb drive), SD (360k or 720k disc in 1.4Mb, 720k or 360k drive), ED (2.8Mb).

rwgap = VALUE

Set the read/write gap.

fmtgap = VALUE

Set the format gap.

fm = Y or N

Set the recording mode. Y for FM, N for MFM.

multitrack = Y or N

Set multitrack mode; this only affects attempts to read normal data from tracks containing deleted data (or vice versa). Y for yes, N for no.

skipdeleted = Y or N

Skip deleted data when searching for non-deleted data (or vice versa). Y for yes, N for no.

## FILES
$HOME/.libdskrc

User-specified format list.

/usr/local/share/LibDsk/libdskrc

System-wide format list.

## SEE ALSO
dsktrans(1) , dskform(1) , dskid(1)

## AUTHOR
John Elliott <seasip.webmaster@gmail.com>.


editrc

title: editrc(5)

summary: configuration file for editline library

text:
# editrc(5)

## NAME
editrc — configuration file for editline library

## SYNOPSIS
editrc

## DESCRIPTION
The editrc file defines various settings to be used by the editline(3) library.

The format of each line is:

[prog:]command [arg ...]

command is one of the editline(3) builtin commands. Refer to BUILTIN COMMANDS for more information.

prog is the program name string that a program defines when it calls el_init(3) to set up editline(3), which is usually argv[0]. command will be executed for any program which matches prog.

prog may also be a regex(3) style regular expression, in which case command will be executed for any program that matches the regular expression.

If prog is absent, command is executed for all programs.

## BUILTIN COMMANDS
The editline library has some builtin commands, which affect the way that the line editing and history functions operate. These are based on similar named builtins present in the tcsh(1) shell.

The following builtin commands are available:

bind [-aeklrsv] [key [command]]

Without options and arguments, list all bound keys and macros, and the editor command or input string to which each one is bound. If only key is supplied, show the binding for that key or macro. If key command is supplied, bind the editor command to that key or macro. The options are as follows:

-a

List or change key bindings in the vi(1) mode alternate (command mode) key map.

-e

Bind all keys to the standard GNU Emacs-like bindings.

-k

key is interpreted as a symbolic arrow key name, which may be one of ‘up’, ‘down’, ‘left’ or ‘right’.

-l

List all editor commands and a short description of each.

-r

Remove the binding of the key or macro key.

-s

Define a keyboard macro rather than a key binding or command macro: command is taken as a literal string and appended to the input queue whenever key is typed. Bound keys and macros in command are themselves reinterpreted, and this continues for ten levels of interpretation.

-v

Bind all keys to the standard vi(1)-like bindings.

The editline(7) manual documents all editor commands and contains more information about macros and the input queue.

key and command can contain control characters of the form ‘^character’ (e.g. ‘^A’), and the following backslashed escape sequences:

\a

Bell

\b

Backspace

\e

Escape

\f

Formfeed

\n

Newline

\r

Carriage return

\t

Horizontal tab

\v

Vertical tab

\nnn

The ASCII character corresponding to the octal number nnn.

‘\’ nullifies the special meaning of the following character, if it has any, notably ‘\’ and ‘^’.

echotc [-sv] arg ...

Exercise terminal capabilities given in arg .... If arg is ‘baud’, ‘cols’, ‘lines’, ‘rows’, ‘meta’, or ‘tabs’, the value of that capability is printed, with “yes” or “no” indicating that the terminal does or does not have that capability. -s returns an empty string for non-existent capabilities, rather than causing an error. -v causes messages to be verbose.

edit [on | off]

Enable or disable the editline functionality in a program.

history list | size n | unique n

The list command lists all entries in the history. The size command sets the history size to n entries. The unique command controls if history should keep duplicate entries. If n is non zero, only keep unique history entries. If n is zero, then keep all entries (the default).

settc cap val

Set the terminal capability cap to val, as defined in termcap(5). No sanity checking is done.

setty [-a] [-d] [-q] [-x] [+mode] [-mode] [mode] [char=c]

Control which tty modes that editrc won't allow the user to change. -d, -q or -x tells setty to act on the ‘edit’, ‘quote’ or ‘execute’ set of tty modes respectively; defaulting to -x. Without other arguments, setty lists the modes in the chosen set which are fixed on (‘+mode’) or off (‘-mode’). -a lists all tty modes in the chosen set regardless of the setting. With +mode, -mode or mode, fixes mode on or off or removes control of mode in the chosen set.

Setty can also be used to set tty characters to particular values using char=value. If value is empty then the character is set to _POSIX_VDISABLE.

telltc

List the values of all the terminal capabilities (see termcap(5)).

## ENVIRONMENT
EDITRC

Names the default configuration file for the editline(3) library.

## FILES
~/.editrc

Last resort, if no other file is specified, user configuration file for the editline(3) library.

## SEE ALSO
editline(3), regex(3), termcap(5), editline(7)

## AUTHORS
The editline library was written by Christos Zoulas, and this manual was written by Luke Mewburn, with some sections inspired by tcsh(1).


libgii.conf

package: libgii

title: libgii.conf(5)

text:
# libgii.conf(5)

## NAME
libgii.conf : LibGII configuration file format

## DESCRIPTION
/etc/ggi/libgii.conf is the configuration file that defines what input module are available and where libgii is supposed to find them. It consists of lines defining target locations (mapping a target name a function name) and target aliases (fake targets that actually calls other target with a specific set of parameters).

The format is common to all GGI libraries. It is defined by libgg. See ggLoadConfig(3) for additional information on file inclusions and other generic options.

## EXAMPLES
These examples show how to use the generic configuration mechanism proposed by LibGG with LibGII.

The first example defines three input modules (or targets) for which initialization function is found in three different dynamic libraries (.so files), under the default LibGII input symbol: GIIdlinit:

```
input-stdin                   input/stdin.so
input-x                       input/x.so
input-xwin                    input/xwin.so
```

In the second example, the two inputs are implemented in a single dynamic library, but they each have their own initialization functions in this library. Their name is separated from the path by a :.

input-x input/x.so:GIIdl_x input-xwin input/x.so:GIIdl_xwin

The third example defines only one real target input-x, located in shared object input/x.so under the symbol GIIdl_x. input-xwin is an alias that will resolve to target input-x with the option string -be-xwin to be passed to the target function (GIIdl_x in input/x.so). input-x input/x.so:GIIdl_x alias input-xwin input-x:-be-xwin

The last examples defines two inputs, with two possible location for their implementation. The first two lines are the same as in example 2. The other two states that these two inputs can also be found (if the previous fail) as a built-in modules. The /gii-builtins path points to the LibGII built-in symbol namespace. In this case both input would be found in this namespace under the default symbol GIIdlinit. The initialization function will be given the requested target name to know which implementation to use. input-x input/x.so:GIIdl_x input-xwin input/x.so:GIIdl_xwin

input-x /gii-builtins input-xwin /gii-builtins

## SEE ALSO
ggLoadConfig(3)


libguestfs-tools.conf

package: libguestfs

title: libguestfs-tools.conf(5)

summary: configuration file for guestfish, guestmount, virt\-rescue

text:
# libguestfs-tools.conf(5)

## NAME
libguestfs-tools.conf - configuration file for guestfish, guestmount, virt-rescue

## SYNOPSIS

```
 /etc/libguestfs-tools.conf
 $XDG_CONFIG_DIRS/libguestfs/libguestfs-tools.conf
 $HOME/.libguestfs-tools.rc
 $XDG_CONFIG_HOME/libguestfs/libguestfs-tools.conf
```

## DESCRIPTION
libguestfs-tools.conf (or $HOME/.libguestfs-tools.rc) changes the defaults for the following programs only:

- guestfish(1)

- guestmount(1)

- virt-rescue(1)

There is currently only one setting which is controlled by this file. Adding (or uncommenting):

```
 read_only = true;
```

changes these programs so they act as if the --ro flag was given on the command line. You can use this to make the programs safe against accidental modification of a live guest (users would have to explicitly add the --rw flag to modify guests). This is not the default because it is not backwards compatible. See also "OPENING DISKS FOR READ AND WRITE" in guestfish(1).

Note that the semicolon is required.

This file is parsed by the libconfig library. For more information about the format, see: http://www.hyperrealm.com/libconfig/libconfig_manual.html

## FILE LOCATION
The order of the configuration files being read is, by importance:

- $XDG_CONFIG_HOME/libguestfs/libguestfs-tools.conf ($XDG_CONFIG_HOME is $HOME/.config if not set).

- $HOME/.libguestfs-tools.rc

- $XDG_CONFIG_DIRS/libguestfs/libguestfs-tools.conf (where $XDG_CONFIG_DIRS means any of the directories in that environment variable, or just /etc/xdg if not set)

- /etc/libguestfs-tools.conf

This means local users can override the system configuration by copying the configuration file (or creating it anew) into $XDG_CONFIG_HOME/libguestfs/libguestfs-tools.conf.

/etc/libguestfs-tools.conf and $HOME/.libguestfs-tools.rc are the old non-XDG paths which are read for compatibility.

## SEE ALSO
"OPENING DISKS FOR READ AND WRITE" in guestfish(1), guestmount(1), virt-rescue(1), http://libguestfs.org/, http://standards.freedesktop.org/basedir-spec/latest/.

## AUTHORS
Richard W.M. Jones ("rjones at redhat dot com")

## COPYRIGHT
Copyright (C) 2011-2020 Red Hat Inc.

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

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

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

## BUGS
To get a list of bugs against libguestfs, use this link: https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools

To report a new bug against libguestfs, use this link: https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools

When reporting a bug, please supply:

- The version of libguestfs.

- Where you got libguestfs (eg. which Linux distro, compiled from source, etc)

- Describe the bug accurately and give a way to reproduce it.

- Run libguestfs-test-tool(1) and paste the complete, unedited output into the bug report.


title: krb5.conf(5)

summary: Kerberos configuration file

text:
# krb5.conf(5)

## NAME
krb5.conf - Kerberos configuration file

The krb5.conf file contains Kerberos configuration information, including the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos realms. Normally, you should install your krb5.conf file in the directory /etc. You can override the default location by setting the environment variable KRB5_CONFIG. Multiple colon-separated filenames may be specified in KRB5_CONFIG; all files which are present will be read. Starting in release 1.14, directory names can also be specified in KRB5_CONFIG; all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores will be read.

## STRUCTURE
The krb5.conf file is set up in the style of a Windows INI file. Lines beginning with '#' or ';' (possibly after initial whitespace) are ignored as comments. Sections are headed by the section name, in square brackets. Each section may contain zero or more relations, of the form:

```
foo = bar
```

or:

```
fubar = {

    foo = bar

    baz = quux
}
```

Placing a '*' after the closing bracket of a section name indicates that the section is final, meaning that if the same section appears within a later file specified in KRB5_CONFIG, it will be ignored. A subsection can be marked as final by placing a '*' after either the tag name or the closing brace.

The krb5.conf file can include other files using either of the following directives at the beginning of a line:

```
include FILENAME
includedir DIRNAME
```

FILENAME or DIRNAME should be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. Starting in release 1.15, files with names ending in ".conf" are also included, unless the name begins with ".". Included profile files are syntactically independent of their parents, so each included file must begin with a section header. Starting in release 1.17, files are read in alphanumeric order; in previous releases, they may be read in any order.

The krb5.conf file can specify that configuration should be obtained from a loadable module, rather than the file itself, using the following directive at the beginning of a line before any section headers:

```
module MODULEPATH:RESIDUAL
```

MODULEPATH may be relative to the library path of the krb5 installation, or it may be an absolute path. RESIDUAL is provided to the module at initialization time. If krb5.conf uses a module directive, kdc.conf(5) should also use one if it exists.

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

[libdefaults]

Settings used by the Kerberos V5 library

[realms]

Realm-specific contact information and settings

[domain_realm]

Maps server hostnames to Kerberos realms

[capaths]

Authentication paths for non-hierarchical cross-realm

[appdefaults]

Settings used by some Kerberos V5 applications

[plugins]

Controls plugin module registration

Additionally, krb5.conf may include any of the relations described in kdc.conf(5), but it is not a recommended practice.

### [libdefaults]
The libdefaults section may contain any of the following relations:

allow_weak_crypto

If this flag is set to false, then weak encryption types (as noted in Encryption_types in kdc.conf(5)) will be filtered out of the lists default_tgs_enctypes, default_tkt_enctypes, and permitted_enctypes. The default value for this tag is false.

canonicalize

If this flag is set to true, initial ticket requests to the KDC will request canonicalization of the client principal name, and answers with different client principals than the requested principal will be accepted. The default value is false.

ccache_type

This parameter determines the format of credential cache types created by kinit(1) or other programs. The default value is 4, which represents the most current format. Smaller values can be used for compatibility with very old implementations of Kerberos which interact with credential caches on the same host.

clockskew

Sets the maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid. The default value is 300 seconds, or five minutes. The clockskew setting is also used when evaluating ticket start and expiration times. For example, tickets that have reached their expiration time can still be used (and renewed if they are renewable tickets) if they have been expired for a shorter duration than the clockskew setting.

default_ccache_name

This relation specifies the name of the default credential cache. The default is FILE:/tmp/krb5cc_%{uid}. This relation is subject to parameter expansion (see below). New in release 1.11.

default_client_keytab_name

This relation specifies the name of the default keytab for obtaining client credentials. The default is FILE:/var/lib/kerberos/krb5/user/%{euid}/client.keytab. This relation is subject to parameter expansion (see below). New in release 1.11.

default_keytab_name

This relation specifies the default keytab name to be used by application servers such as sshd. The default is FILE:/etc/krb5.keytab. This relation is subject to parameter expansion (see below).

default_rcache_name

This relation specifies the name of the default replay cache. The default is dfl:. This relation is subject to parameter expansion (see below). New in release 1.18.

default_realm

Identifies the default Kerberos realm for the client. Set its value to your Kerberos realm. If this value is not set, then a realm must be specified with every Kerberos principal when invoking programs such as kinit(1).

default_tgs_enctypes

Identifies the supported list of session key encryption types that the client should request when making a TGS-REQ, in order of preference from highest to lowest. The list may be delimited with commas or whitespace. See Encryption_types in kdc.conf(5) for a list of the accepted values for this tag. Starting in release 1.18, the default value is the value of permitted_enctypes. For previous releases or if permitted_enctypes is not set, the default value is aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac. Do not set this unless required for specific backward compatibility purposes; stale values of this setting can prevent clients from taking advantage of new stronger enctypes when the libraries are upgraded.

default_tkt_enctypes

Identifies the supported list of session key encryption types that the client should request when making an AS-REQ, in order of preference from highest to lowest. The format is the same as for default_tgs_enctypes. Starting in release 1.18, the default value is the value of permitted_enctypes. For previous releases or if permitted_enctypes is not set, the default value is aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac. Do not set this unless required for specific backward compatibility purposes; stale values of this setting can prevent clients from taking advantage of new stronger enctypes when the libraries are upgraded.

dns_canonicalize_hostname

Indicate whether name lookups will be used to canonicalize hostnames for use in service principal names. Setting this flag to false can improve security by reducing reliance on DNS, but means that short hostnames will not be canonicalized to fully-qualified hostnames. If this option is set to fallback (new in release 1.18), DNS canonicalization will only be performed the server hostname is not found with the original name when requesting credentials. The default value is true.

dns_lookup_kdc

Indicate whether DNS SRV records should be used to locate the KDCs and other servers for a realm, if they are not listed in the krb5.conf information for the realm. (Note that the admin_server entry must be in the krb5.conf realm information in order to contact kadmind, because the DNS implementation for kadmin is incomplete.) Enabling this option does open up a type of denial-of-service attack, if someone spoofs the DNS records and redirects you to another server. However, it's no worse than a denial of service, because that fake KDC will be unable to decode anything you send it (besides the initial ticket request, which has no encrypted data), and anything the fake KDC sends will not be trusted without verification using some secret that it won't know.

dns_uri_lookup

Indicate whether DNS URI records should be used to locate the KDCs and other servers for a realm, if they are not listed in the krb5.conf information for the realm. SRV records are used as a fallback if no URI records were found. The default value is true. New in release 1.15.

enforce_ok_as_delegate

If this flag to true, GSSAPI credential delegation will be disabled when the ok-as-delegate flag is not set in the service ticket. If this flag is false, the ok-as-delegate ticket flag is only enforced when an application specifically requests enforcement. The default value is false.

err_fmt

This relation allows for custom error message formatting. If a value is set, error messages will be formatted by substituting a normal error message for %M and an error code for %C in the value.

extra_addresses

This allows a computer to use multiple local addresses, in order to allow Kerberos to work in a network that uses NATs while still using address-restricted tickets. The addresses should be in a comma-separated list. This option has no effect if noaddresses is true.

forwardable

If this flag is true, initial tickets will be forwardable by default, if allowed by the KDC. The default value is false.

ignore_acceptor_hostname

When accepting GSSAPI or krb5 security contexts for host-based service principals, ignore any hostname passed by the calling application, and allow clients to authenticate to any service principal in the keytab matching the service name and realm name (if given). This option can improve the administrative flexibility of server applications on multihomed hosts, but could compromise the security of virtual hosting environments. The default value is false. New in release 1.10.

k5login_authoritative

If this flag is true, principals must be listed in a local user's k5login file to be granted login access, if a .k5login(5) file exists. If this flag is false, a principal may still be granted login access through other mechanisms even if a k5login file exists but does not list the principal. The default value is true.

k5login_directory

If set, the library will look for a local user's k5login file within the named directory, with a filename corresponding to the local username. If not set, the library will look for k5login files in the user's home directory, with the filename .k5login. For security reasons, .k5login files must be owned by the local user or by root.

kcm_mach_service

On macOS only, determines the name of the bootstrap service used to contact the KCM daemon for the KCM credential cache type. If the value is -, Mach RPC will not be used to contact the KCM daemon. The default value is org.h5l.kcm.

kcm_socket

Determines the path to the Unix domain socket used to access the KCM daemon for the KCM credential cache type. If the value is -, Unix domain sockets will not be used to contact the KCM daemon. The default value is /var/run/.heim_org.h5l.kcm-socket.

kdc_default_options

Default KDC options (Xored for multiple values) when requesting initial tickets. By default it is set to 0x00000010 (KDC_OPT_RENEWABLE_OK).

kdc_timesync

Accepted values for this relation are 1 or 0. If it is nonzero, client machines will compute the difference between their time and the time returned by the KDC in the timestamps in the tickets and use this value to correct for an inaccurate system clock when requesting service tickets or authenticating to services. This corrective factor is only used by the Kerberos library; it is not used to change the system clock. The default value is 1.

noaddresses

If this flag is true, requests for initial tickets will not be made with address restrictions set, allowing the tickets to be used across NATs. The default value is true.

permitted_enctypes

Identifies the encryption types that servers will permit for session keys and for ticket and authenticator encryption, ordered by preference from highest to lowest. Starting in release 1.18, this tag also acts as the default value for default_tgs_enctypes and default_tkt_enctypes. The default value for this tag is aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac.

plugin_base_dir

If set, determines the base directory where krb5 plugins are located. The default value is the krb5/plugins subdirectory of the krb5 library directory. This relation is subject to parameter expansion (see below) in release 1.17 and later.

preferred_preauth_types

This allows you to set the preferred preauthentication types which the client will attempt before others which may be advertised by a KDC. The default value for this setting is "17, 16, 15, 14", which forces libkrb5 to attempt to use PKINIT if it is supported.

proxiable

If this flag is true, initial tickets will be proxiable by default, if allowed by the KDC. The default value is false.

qualify_shortname

If this string is set, it determines the domain suffix for single-component hostnames when DNS canonicalization is not used (either because dns_canonicalize_hostname is false or because forward canonicalization failed). The default value is the first search domain of the system's DNS configuration. To disable qualification of shortnames, set this relation to the empty string with qualify_shortname = "". (New in release 1.18.)

rdns

If this flag is true, reverse name lookup will be used in addition to forward name lookup to canonicalizing hostnames for use in service principal names. If dns_canonicalize_hostname is set to false, this flag has no effect. The default value is true.

realm_try_domains

Indicate whether a host's domain components should be used to determine the Kerberos realm of the host. The value of this variable is an integer: -1 means not to search, 0 means to try the host's domain itself, 1 means to also try the domain's immediate parent, and so forth. The library's usual mechanism for locating Kerberos realms is used to determine whether a domain is a valid realm, which may involve consulting DNS if dns_lookup_kdc is set. The default is not to search domain components.

renew_lifetime

(duration string.) Sets the default renewable lifetime for initial ticket requests. The default value is 0.

spake_preauth_groups

A whitespace or comma-separated list of words which specifies the groups allowed for SPAKE preauthentication. The possible values are: edwards25519

Edwards25519 curve (RFC 7748)

P-256

NIST P-256 curve (RFC 5480)

P-384

NIST P-384 curve (RFC 5480)

P-521

NIST P-521 curve (RFC 5480)

The default value for the client is edwards25519. The default value for the KDC is empty. New in release 1.17.

ticket_lifetime

(duration string.) Sets the default lifetime for initial ticket requests. The default value is 1 day.

udp_preference_limit

When sending a message to the KDC, the library will try using TCP before UDP if the size of the message is above udp_preference_limit. If the message is smaller than udp_preference_limit, then UDP will be tried before TCP. Regardless of the size, both protocols will be tried if the first attempt fails.

verify_ap_req_nofail

If this flag is true, then an attempt to verify initial credentials will fail if the client machine does not have a keytab. The default value is false.

client_aware_channel_bindings

If this flag is true, then all application protocol authentication requests will be flagged to indicate that the application supports channel bindings when operating over a secure channel. The default value is false.

### [realms]
Each tag in the [realms] section of the file is the name of a Kerberos realm. The value of the tag is a subsection with relations that define the properties of that particular realm. For each realm, the following tags may be specified in the realm's subsection:

admin_server

Identifies the host where the administration server is running. Typically, this is the primary Kerberos server. This tag must be given a value in order to communicate with the kadmind(8) server for the realm.

auth_to_local

This tag allows you to set a general rule for mapping principal names to local user names. It will be used if there is not an explicit mapping for the principal name that is being translated. The possible values are:

RULE:exp

The local name will be formulated from exp. The format for exp is [n:string](regexp)s/pattern/replacement/g. The integer n indicates how many components the target principal should have. If this matches, then a string will be formed from string, substituting the realm of the principal for $0 and the n'th component of the principal for $n (e.g., if the principal was johndoe/admin then [2:$2$1foo] would result in the string adminjohndoefoo). If this string matches regexp, then the s//[g] substitution command will be run over the string. The optional g will cause the substitution to be global over the string, instead of replacing only the first match in the string.

DEFAULT

The principal name will be used as the local user name. If the principal has more than one component or is not in the default realm, this rule is not applicable and the conversion will fail.

For example:

```
[realms]

    ATHENA.MIT.EDU = {

        auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/

        auth_to_local = RULE:[2:$1;$2](^.*;admin$)s/;admin$//

        auth_to_local = RULE:[2:$2](^.*;root)s/^.*$/root/

        auth_to_local = DEFAULT

    }
```

would result in any principal without root or admin as the second component to be translated with the default rule. A principal with a second component of admin will become its first component. root will be used as the local name for any principal with a second component of root. The exception to these two rules are any principals johndoe/*, which will always get the local name guest.

auth_to_local_names

This subsection allows you to set explicit mappings from principal names to local user names. The tag is the mapping name, and the value is the corresponding local user name.

default_domain

This tag specifies the domain used to expand hostnames when translating Kerberos 4 service principals to Kerberos 5 principals (for example, when converting rcmd.hostname to host/hostname.domain).

disable_encrypted_timestamp

If this flag is true, the client will not perform encrypted timestamp preauthentication if requested by the KDC. Setting this flag can help to prevent dictionary attacks by active attackers, if the realm's KDCs support SPAKE preauthentication or if initial authentication always uses another mechanism or always uses FAST. This flag persists across client referrals during initial authentication. This flag does not prevent the KDC from offering encrypted timestamp. New in release 1.17.

http_anchors

When KDCs and kpasswd servers are accessed through HTTPS proxies, this tag can be used to specify the location of the CA certificate which should be trusted to issue the certificate for a proxy server. If left unspecified, the system-wide default set of CA certificates is used. The syntax for values is similar to that of values for the pkinit_anchors tag:

FILE: filename

filename is assumed to be the name of an OpenSSL-style ca-bundle file.

DIR: dirname

dirname is assumed to be an directory which contains CA certificates. All files in the directory will be examined; if they contain certificates (in PEM format), they will be used.

ENV: envvar

envvar specifies the name of an environment variable which has been set to a value conforming to one of the previous values. For example, ENV:X509_PROXY_CA, where environment variable X509_PROXY_CA has been set to FILE:/tmp/my_proxy.pem.

kdc

The name or address of a host running a KDC for that realm. An optional port number, separated from the hostname by a colon, may be included. If the name or address contains colons (for example, if it is an IPv6 address), enclose it in square brackets to distinguish the colon from a port separator. For your computer to be able to communicate with the KDC for each realm, this tag must be given a value in each realm subsection in the configuration file, or there must be DNS SRV records specifying the KDCs.

kpasswd_server

Points to the server where all the password changes are performed. If there is no such entry, DNS will be queried (unless forbidden by dns_lookup_kdc). Finally, port 464 on the admin_server host will be tried.

master_kdc

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

primary_kdc

Identifies the primary KDC(s). Currently, this tag is used in only one case: If an attempt to get credentials fails because of an invalid password, the client software will attempt to contact the primary KDC, in case the user's password has just been changed, and the updated database has not been propagated to the replica servers yet. New in release 1.19.

v4_instance_convert

This subsection allows the administrator to configure exceptions to the default_domain mapping rule. It contains V4 instances (the tag name) which should be translated to some specific hostname (the tag value) as the second component in a Kerberos V5 principal name.

v4_realm

This relation is used by the krb524 library routines when converting a V5 principal name to a V4 principal name. It is used when the V4 realm name and the V5 realm name are not the same, but still share the same principal names and passwords. The tag value is the Kerberos V4 realm name.

### [domain_realm]
The [domain_realm] section provides a translation from a domain name or hostname to a Kerberos realm name. The tag name can be a host name or domain name, where domain names are indicated by a prefix of a period (.). The value of the relation is the Kerberos realm name for that particular host or domain. A host name relation implicitly provides the corresponding domain name relation, unless an explicit domain name relation is provided. The Kerberos realm may be identified either in the realms section or using DNS SRV records. Host names and domain names should be in lower case. For example:

```
[domain_realm]

    crash.mit.edu = TEST.ATHENA.MIT.EDU

    .dev.mit.edu = TEST.ATHENA.MIT.EDU

    mit.edu = ATHENA.MIT.EDU
```

maps the host with the name crash.mit.edu into the TEST.ATHENA.MIT.EDU realm. The second entry maps all hosts under the domain dev.mit.edu into the TEST.ATHENA.MIT.EDU realm, but not the host with the name dev.mit.edu. That host is matched by the third entry, which maps the host mit.edu and all hosts under the domain mit.edu that do not match a preceding rule into the realm ATHENA.MIT.EDU.

If no translation entry applies to a hostname used for a service principal for a service ticket request, the library will try to get a referral to the appropriate realm from the client realm's KDC. If that does not succeed, the host's realm is considered to be the hostname's domain portion converted to uppercase, unless the realm_try_domains setting in [libdefaults] causes a different parent domain to be used.

### [capaths]
In order to perform direct (non-hierarchical) cross-realm authentication, configuration is needed to determine the authentication paths between realms.

A client will use this section to find the authentication path between its realm and the realm of the server. The server will use this section to verify the authentication path used by the client, by checking the transited field of the received ticket.

There is a tag for each participating client realm, and each tag has subtags for each of the server realms. The value of the subtags is an intermediate realm which may participate in the cross-realm authentication. The subtags may be repeated if there is more then one intermediate realm. A value of "." means that the two realms share keys directly, and no intermediate realms should be allowed to participate.

Only those entries which will be needed on the client or the server need to be present. A client needs a tag for its local realm with subtags for all the realms of servers it will need to authenticate to. A server needs a tag for each realm of the clients it will serve, with a subtag of the server realm.

For example, ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NET realm as an intermediate realm. ANL has a sub realm of TEST.ANL.GOV which will authenticate with NERSC.GOV but not PNL.GOV. The [capaths] section for ANL.GOV systems would look like this:

```
[capaths]

    ANL.GOV = {

        TEST.ANL.GOV = .

        PNL.GOV = ES.NET

        NERSC.GOV = ES.NET

        ES.NET = .

    }

    TEST.ANL.GOV = {

        ANL.GOV = .

    }

    PNL.GOV = {

        ANL.GOV = ES.NET

    }

    NERSC.GOV = {

        ANL.GOV = ES.NET

    }

    ES.NET = {

        ANL.GOV = .

    }
```

The [capaths] section of the configuration file used on NERSC.GOV systems would look like this:

```
[capaths]

    NERSC.GOV = {

        ANL.GOV = ES.NET

        TEST.ANL.GOV = ES.NET

        TEST.ANL.GOV = ANL.GOV

        PNL.GOV = ES.NET

        ES.NET = .

    }

    ANL.GOV = {

        NERSC.GOV = ES.NET

    }

    PNL.GOV = {

        NERSC.GOV = ES.NET

    }

    ES.NET = {

        NERSC.GOV = .

    }

    TEST.ANL.GOV = {

        NERSC.GOV = ANL.GOV

        NERSC.GOV = ES.NET

    }
```

When a subtag is used more than once within a tag, clients will use the order of values to determine the path. The order of values is not important to servers.

### [appdefaults]
Each tag in the [appdefaults] section names a Kerberos V5 application or an option that is used by some Kerberos V5 application[s]. The value of the tag defines the default behaviors for that application.

For example:

```
[appdefaults]

    telnet = {

        ATHENA.MIT.EDU = {

            option1 = false

        }

    }

    telnet = {

        option1 = true

        option2 = true

    }

    ATHENA.MIT.EDU = {

        option2 = false

    }

    option2 = true
```

The above four ways of specifying the value of an option are shown in order of decreasing precedence. In this example, if telnet is running in the realm EXAMPLE.COM, it should, by default, have option1 and option2 set to true. However, a telnet program in the realm ATHENA.MIT.EDU should have option1 set to false and option2 set to true. Any other programs in ATHENA.MIT.EDU should have option2 set to false by default. Any programs running in other realms should have option2 set to true.

The list of specifiable options for each application may be found in that application's man pages. The application defaults specified here are overridden by those specified in the realms section.

### [plugins]

- pwqual interface

- kadm5_hook interface

- clpreauth and kdcpreauth interfaces

Tags in the [plugins] section can be used to register dynamic plugin modules and to turn modules on and off. Not every krb5 pluggable interface uses the [plugins] section; the ones that do are documented here.

New in release 1.9.

Each pluggable interface corresponds to a subsection of [plugins]. All subsections support the same tags:

disable

This tag may have multiple values. If there are values for this tag, then the named modules will be disabled for the pluggable interface.

enable_only

This tag may have multiple values. If there are values for this tag, then only the named modules will be enabled for the pluggable interface.

module

This tag may have multiple values. Each value is a string of the form modulename:pathname, which causes the shared object located at pathname to be registered as a dynamic module named modulename for the pluggable interface. If pathname is not an absolute path, it will be treated as relative to the plugin_base_dir value from [libdefaults].

For pluggable interfaces where module order matters, modules registered with a module tag normally come first, in the order they are registered, followed by built-in modules in the order they are documented below. If enable_only tags are used, then the order of those tags overrides the normal module order.

The following subsections are currently supported within the [plugins] section:

### ccselect interface
The ccselect subsection controls modules for credential cache selection within a cache collection. In addition to any registered dynamic modules, the following built-in modules exist (and may be disabled with the disable tag):

k5identity

Uses a .k5identity file in the user's home directory to select a client principal

realm

Uses the service realm to guess an appropriate cache from the collection

hostname

If the service principal is host-based, uses the service hostname to guess an appropriate cache from the collection

### pwqual interface
The pwqual subsection controls modules for the password quality interface, which is used to reject weak passwords when passwords are changed. The following built-in modules exist for this interface:

dict

Checks against the realm dictionary file

empty

Rejects empty passwords

hesiod

Checks against user information stored in Hesiod (only if Kerberos was built with Hesiod support)

princ

Checks against components of the principal name

### kadm5_hook interface
The kadm5_hook interface provides plugins with information on principal creation, modification, password changes and deletion. This interface can be used to write a plugin to synchronize MIT Kerberos with another database such as Active Directory. No plugins are built in for this interface.

### kadm5_auth interface
The kadm5_auth section (introduced in release 1.16) controls modules for the kadmin authorization interface, which determines whether a client principal is allowed to perform a kadmin operation. The following built-in modules exist for this interface:

acl

This module reads the kadm5.acl(5) file, and authorizes operations which are allowed according to the rules in the file.

self

This module authorizes self-service operations including password changes, creation of new random keys, fetching the client's principal record or string attributes, and fetching the policy record associated with the client principal.

### clpreauth and kdcpreauth interfaces
The clpreauth and kdcpreauth interfaces allow plugin modules to provide client and KDC preauthentication mechanisms. The following built-in modules exist for these interfaces:

pkinit

This module implements the PKINIT preauthentication mechanism.

encrypted_challenge

This module implements the encrypted challenge FAST factor.

encrypted_timestamp

This module implements the encrypted timestamp mechanism.

### hostrealm interface
The hostrealm section (introduced in release 1.12) controls modules for the host-to-realm interface, which affects the local mapping of hostnames to realm names and the choice of default realm. The following built-in modules exist for this interface:

profile

This module consults the [domain_realm] section of the profile for authoritative host-to-realm mappings, and the default_realm variable for the default realm.

dns

This module looks for DNS records for fallback host-to-realm mappings and the default realm. It only operates if the dns_lookup_realm variable is set to true.

domain

This module applies heuristics for fallback host-to-realm mappings. It implements the realm_try_domains variable, and uses the uppercased parent domain of the hostname if that does not produce a result.

### localauth interface
The localauth section (introduced in release 1.12) controls modules for the local authorization interface, which affects the relationship between Kerberos principals and local system accounts. The following built-in modules exist for this interface:

default

This module implements the DEFAULT type for auth_to_local values.

rule

This module implements the RULE type for auth_to_local values.

names

This module looks for an auth_to_local_names mapping for the principal name.

auth_to_local

This module processes auth_to_local values in the default realm's section, and applies the default method if no auth_to_local values exist.

k5login

This module authorizes a principal to a local account according to the account's .k5login(5) file.

an2ln

This module authorizes a principal to a local account if the principal name maps to the local account name.

### certauth interface
The certauth section (introduced in release 1.16) controls modules for the certificate authorization interface, which determines whether a certificate is allowed to preauthenticate a user via PKINIT. The following built-in modules exist for this interface:

pkinit_san

This module authorizes the certificate if it contains a PKINIT Subject Alternative Name for the requested client principal, or a Microsoft UPN SAN matching the principal if pkinit_allow_upn is set to true for the realm.

pkinit_eku

This module rejects the certificate if it does not contain an Extended Key Usage attribute consistent with the pkinit_eku_checking value for the realm.

dbmatch

This module authorizes or rejects the certificate according to whether it matches the pkinit_cert_match string attribute on the client principal, if that attribute is present.

## PKINIT OPTIONS
NOTE:

The following are PKINIT-specific options. These values may be specified in [libdefaults] as global defaults, or within a realm-specific subsection of [libdefaults], or may be specified as realm-specific values in the [realms] section. A realm-specific value overrides, not adds to, a generic [libdefaults] specification. The search order is:

1.

realm-specific subsection of [libdefaults]:

```
[libdefaults]

    EXAMPLE.COM = {

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

    }
```

2.

realm-specific value in the [realms] section:

```
[realms]

    OTHERREALM.ORG = {

        pkinit_anchors = FILE:/usr/local/otherrealm.org.crt

    }
```

3.

generic value in the [libdefaults] section:

```
[libdefaults]

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

### Specifying PKINIT identity information
The syntax for specifying Public Key identity, trust, and revocation information for PKINIT is as follows:

FILE:filename[,keyfilename]

This option has context-specific behavior. In pkinit_identity or pkinit_identities, filename specifies the name of a PEM-format file containing the user's certificate. If keyfilename is not specified, the user's private key is expected to be in filename as well. Otherwise, keyfilename is the name of the file containing the private key.

In pkinit_anchors or pkinit_pool, filename is assumed to be the name of an OpenSSL-style ca-bundle file.

DIR:dirname

This option has context-specific behavior. In pkinit_identity or pkinit_identities, dirname specifies a directory with files named *.crt and *.key where the first part of the file name is the same for matching pairs of certificate and private key files. When a file with a name ending with .crt is found, a matching file ending with .key is assumed to contain the private key. If no such file is found, then the certificate in the .crt is not used.

In pkinit_anchors or pkinit_pool, dirname is assumed to be an OpenSSL-style hashed CA directory where each CA cert is stored in a file named hash-of-ca-cert.#. This infrastructure is encouraged, but all files in the directory will be examined and if they contain certificates (in PEM format), they will be used.

In pkinit_revoke, dirname is assumed to be an OpenSSL-style hashed CA directory where each revocation list is stored in a file named hash-of-ca-cert.r#. This infrastructure is encouraged, but all files in the directory will be examined and if they contain a revocation list (in PEM format), they will be used.

PKCS12:filename

filename is the name of a PKCS #12 format file, containing the user's certificate and private key.

PKCS11:[module_name=]modname[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label]

All keyword/values are optional. modname specifies the location of a library implementing PKCS #11. If a value is encountered with no keyword, it is assumed to be the modname. If no module-name is specified, the default is opensc-pkcs11.so. slotid= and/or token= may be specified to force the use of a particular smard card reader or token if there is more than one available. certid= and/or certlabel= may be specified to force the selection of a particular certificate on the device. See the pkinit_cert_match configuration option for more ways to select a particular certificate to use for PKINIT.

ENV:envvar

envvar specifies the name of an environment variable which has been set to a value conforming to one of the previous values. For example, ENV:X509_PROXY, where environment variable X509_PROXY has been set to FILE:/tmp/my_proxy.pem.

### PKINIT krb5.conf options
pkinit_anchors

Specifies the location of trusted anchor (root) certificates which the client trusts to sign KDC certificates. This option may be specified multiple times. These values from the config file are not used if the user specifies X509_anchors on the command line.

pkinit_cert_match

Specifies matching rules that the client certificate must match before it is used to attempt PKINIT authentication. If a user has multiple certificates available (on a smart card, or via other media), there must be exactly one certificate chosen before attempting PKINIT authentication. This option may be specified multiple times. All the available certificates are checked against each rule in order until there is a match of exactly one certificate. The Subject and Issuer comparison strings are the RFC 2253 string representations from the certificate Subject DN and Issuer DN values.

The syntax of the matching rules is:

[relation-operator]component-rule ...

where:

relation-operator

can be either &&, meaning all component rules must match, or ||, meaning only one component rule must match. The default is &&.

component-rule

can be one of the following. Note that there is no punctuation or whitespace between component rules.

```
<SUBJECT>regular-expression
<ISSUER>regular-expression
<SAN>regular-expression
<EKU>extended-key-usage-list
<KU>key-usage-list
```

extended-key-usage-list is a comma-separated list of required Extended Key Usage values. All values in the list must be present in the certificate. Extended Key Usage values can be:

- pkinit

- msScLogin

- clientAuth

- emailProtection

key-usage-list is a comma-separated list of required Key Usage values. All values in the list must be present in the certificate. Key Usage values can be:

- digitalSignature

- keyEncipherment

Examples:

```
pkinit_cert_match = ||<SUBJECT>.*DoE.*<SAN>.*@EXAMPLE.COM
pkinit_cert_match = &&<EKU>msScLogin,clientAuth<ISSUER>.*DoE.*
pkinit_cert_match = <EKU>msScLogin,clientAuth<KU>digitalSignature
```

pkinit_eku_checking

This option specifies what Extended Key Usage value the KDC certificate presented to the client must contain. (Note that if the KDC certificate has the pkinit SubjectAlternativeName encoded as the Kerberos TGS name, EKU checking is not necessary since the issuing CA has certified this as a KDC certificate.) The values recognized in the krb5.conf file are:

kpKDC

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

kpServerAuth

If kpServerAuth is specified, a KDC certificate with the id-kp-serverAuth EKU will be accepted. This key usage value is used in most commercially issued server certificates.

none

If none is specified, then the KDC certificate will not be checked to verify it has an acceptable EKU. The use of this option is not recommended.

pkinit_dh_min_bits

Specifies the size of the Diffie-Hellman key the client will attempt to use. The acceptable values are 1024, 2048, and 4096. The default is 2048.

pkinit_identities

Specifies the location(s) to be used to find the user's X.509 identity information. If this option is specified multiple times, each value is attempted in order until certificates are found. Note that these values are not used if the user specifies X509_user_identity on the command line.

pkinit_kdc_hostname

The presence of this option indicates that the client is willing to accept a KDC certificate with a dNSName SAN (Subject Alternative Name) rather than requiring the id-pkinit-san as defined in RFC 4556. This option may be specified multiple times. Its value should contain the acceptable hostname for the KDC (as contained in its certificate).

pkinit_pool

Specifies the location of intermediate certificates which may be used by the client to complete the trust chain between a KDC certificate and a trusted anchor. 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_revoke

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

## PARAMETER EXPANSION
Starting with release 1.11, several variables, such as default_keytab_name, allow parameters to be expanded. Valid parameters are:

%{TEMP}

Temporary directory

%{uid}

Unix real UID or Windows SID

%{euid}

Unix effective user ID or Windows SID

%{USERID}

Same as %{uid}

%{null}

Empty string

%{LIBDIR}

Installation library directory

%{BINDIR}

Installation binary directory

%{SBINDIR}

Installation admin binary directory

%{username}

(Unix) Username of effective user ID

%{APPDATA}

(Windows) Roaming application data for current user

%{COMMON_APPDATA}

(Windows) Application data for all users

%{LOCAL_APPDATA}

(Windows) Local application data for current user

%{SYSTEM}

(Windows) Windows system folder

%{WINDOWS}

(Windows) Windows folder

%{USERCONFIG}

(Windows) Per-user MIT krb5 config file directory

%{COMMONCONFIG}

(Windows) Common MIT krb5 config file directory

## SAMPLE KRB5.CONF FILE
Here is an example of a generic krb5.conf file:

```
[libdefaults]

    default_realm = ATHENA.MIT.EDU

    dns_lookup_kdc = true

    dns_lookup_realm = false
[realms]

    ATHENA.MIT.EDU = {

        kdc = kerberos.mit.edu

        kdc = kerberos-1.mit.edu

        kdc = kerberos-2.mit.edu

        admin_server = kerberos.mit.edu

        primary_kdc = kerberos.mit.edu

    }

    EXAMPLE.COM = {

        kdc = kerberos.example.com

        kdc = kerberos-1.example.com

        admin_server = kerberos.example.com

    }
[domain_realm]

    mit.edu = ATHENA.MIT.EDU
[capaths]

    ATHENA.MIT.EDU = {

           EXAMPLE.COM = .

    }

    EXAMPLE.COM = {

           ATHENA.MIT.EDU = .

    }
```

## FILES
/etc/krb5.conf

## SEE ALSO
syslog(3)

## AUTHOR
MIT

## COPYRIGHT
1985-2022, MIT


package: libmjpegtools-devel

title: yuv4mpeg(5)

text:
# yuv4mpeg(5)

## NAME
YUV4MPEG2 - video stream format used by pipe-based MJPEGtools

## DESCRIPTION
Many of the MJPEGtools communicate via pipes and act as filters (or sources or sinks). The format of video data used in the pipes is referred to as "YUV4MPEG", or, more precisely, "YUV4MPEG2". (The format was extended and codified during v1.5.x of the tools.)

The basic structure is a stream header followed by an unlimited number of frames. Each frame itself consists of a header followed by video data. The headers are vaguely human-readable ASCII, but the video data is simple byte-size binary.

The MJPEGtools distribution has a C library (libmjpegutils) which contains functions for manipulating YUV4MPEG2 streams. We recommend that you use this library rather than writing your own code if possible. See the header file "yuv4mpeg.h" for a description of these functions.

Design Goals:

o

Easy to parse both via C or sh.

o

Extensible; easy to add new parameters while maintaining backwards compatibility.

o

Simple upgrade from original "YUV4MPEG" format.

Drawbacks:

o

Frame headers do not have constant size, so streams are not seekable.

## GRAMMAR
The precise description of the the YUV4MPEG2 stream format is as follows:

STREAM consists of

-

one STREAM-HEADER

-

unlimited number of FRAMEs

STREAM-HEADER consists of

-

magic string "YUV4MPEG2"

-

unlimited number of TAGGED-FIELDs, each preceeded by a ' ' (single space) separator

-

single '\n' line terminator

FRAME consists of

-

one FRAME-HEADER

-

"length" octets of planar YCbCr 4:2:0 image data (If the stream is interlaced, then the two fields per frame are interleaved, with proper spatial ordering.)

FRAME-HEADER consists of

-

magic string "FRAME"

-

unlimited number of TAGGED-FIELDs, each preceeded by a ' ' (single space) separator

-

single '\n' line terminator

TAGGED-FIELD consists of

-

single ASCII character tag

-

VALUE (which does not contain whitespace)

VALUE consists of

-

RATIO, or

-

integer (base 10 ASCII representation), or

-

single ascii character, or

-

string (multiple ASCII characters)

RATIO consists of

-

numerator (base 10 ASCII integer)

-

':' (a colon)

-

denominator (base 10 ASCII integer)

Header tags fall into three categories: optional, required and has-default. Optional tags are completely optional and may be omitted from a header. Required tags must be present in a header. Has-Default tags have a default value which is implied if the tag is not present. Independent of these categories, some tags allow an "unknown" value and some do not.

The supported tags for the STREAM-HEADER:

W[integer] - frame width in pixels, must be > 0 (required)

H[integer] - frame height in pixels, must be > 0 (required)

C[string] - chroma subsampling, image data format (has default)

420jpeg - 4:2:0 with JPEG/MPEG-1 siting (default)

420mpeg2 - 4:2:0 with MPEG-2 siting

420paldv - 4:2:0 with PAL-DV siting

411 - 4:1:1, cosited

422 - 4:2:2, cosited

444 - 4:4:4 (no subsampling)

444alpha - 4:4:4 with an alpha channel

mono - luma (Y') plane only

I[char] - interlacing specification: (has default)

? - unknown (default)

p - progressive/none

t - top-field-first

b - bottom-field-first

m - mixed-mode: refer to 'I' tag in frame header

F[ratio] - frame-rate (has default of 0:0 == unknown)

A[ratio] - sample aspect ratio (has default of 0:0 == unknown)

X[string] - 'metadata' (optional; unparsed, but passed around)

The currently supported tags for the FRAME-HEADER:

I[string] - framing and sampling (required if-and-only-if Im is present in stream header). Value is a string of three characters "xyz" which have the following meanings:

x: frame presentation

t - top-field-first

T - top-field-first and repeat

b - bottom-field-first

B - bottom-field-first and repeat

1 - single progressive frame

2 - double progressive frame (repeat)

3 - triple progressive frame (repeat)

y: frame temporal sampling

p - progressive (fields sampled at same time)

i - interlaced (fields sampled at different times)

z: frame chroma-subsampling

p - progressive (subsampling over whole frame)

i - interlaced (each field subsampled independently)

? - unknown (allowed only for non-4:2:0 subsampling)

X[string] - 'metadata' (optional; unparsed, but passed around)

Note that a filter application must faithfully forward all "X" tags from input pipe to output pipe (unless it uses one of those tags, of course). The supplied library will do this automatically if the functions y4m_copy_stream_info() and y4m_copy_frame_info() are used appropriately.

## NOTES ON IMAGE DATA
All image data is in the CCIR-601 Y'CbCr colorspace, presented plane-by-plane in row-major order. Each sample within each plane is one octet (8-bits) in size. When all planes are present, they are transmitted in the order Y', Cb, Cr, potentially followed by an alpha/transparency mask plane (for the 444alpha chroma format). The alpha channel data is follows the same range as the Y' luma channel: full transparency is at 16 and full opacity is at 235.

All Y' and alpha planes consist of (height X width) octets. The size of the chroma planes depends on the subsampling mode:

-

4:4:4 - (height X width) octets

-

4:2:2 - (height X width) / 2 octets

-

4:1:1 - (height X width) / 4 octets

-

4:2:0 - (height X width) / 4 octets

## NOTES ON FRAMING
For more details about reading and writing yuv4mpeg files read the sources - there are many utility programs, some simple, some complex that can serve as guides.

## SEE ALSO
mjpegtools(1), yuv4mpeg.h

## AUTHOR
This manual page Copyright 2004 Matthew J. Marjanovic.


jng

package: libmng

title: jng(5)

summary: JPEG Network Graphics (JNG) sub-format

text:
# jng(5)

## NAME
jng - JPEG Network Graphics (JNG) sub-format

## DESCRIPTION
JNG (JPEG Network Graphics) is a sub-format of the MNG (Multiple-image Network Graphics) format. As with MNG it extends on the features of the popular PNG (Portable Network Graphics) image-format.

This sub-format was designed to support a lossy compression-method. It is based completely on the JPEG specification. It adds the high-compression ratios of JPEG for photographic images.

As a member of the Network Graphics family, JNG was deemed adequate as a stand-alone format as it extends the JPEG format with color-correction and transparency features.

## SEE ALSO
png(5), mng(5), libmng(3)

MNG 1.00, February 9, 2001:

http://www.libpng.org/pub/mng

## AUTHORS
This man page: Gerard Juyn

Multiple-image Network Graphics (MNG) Specification Version 1.00 (Februari 9, 2001): Glenn Randers-Pehrson and others (png-list@ccrc.wustl.edu).

## COPYRIGHT NOTICE
The MNG-1.00 specification is copyright (c) 1998-2001 Glenn Randers-Pehrson. See the specification for conditions of use and distribution.


mng

title: mng(5)

text:
# mng(5)

## NAME
mng - Multiple-image Network Graphics (MNG) format

## DESCRIPTION
MNG (Multiple-image Network Graphics) is the animation extension of the popular PNG image-format. PNG (Portable Network Graphics) is an extensible file format for the lossless, portable, well-compressed storage of raster images.

MNG has advanced animation features which make it very useful as a full replacement for GIF animations. These features allow animations that are impossible with GIF or result in much smaller files as GIF.

As MNG builds on the same structure as PNG, it is robust, extensible and free of patents. It retains the same clever file integrity checks as in PNG.

MNG also embraces the lossy JPEG image-format in a sub-format named JNG, which allows for alpha-transparency and color-correction on highly compressed (photographic) images.

## SEE ALSO
png(5), jng(5), libmng(3), libpng(3), zlib(3), deflate(5) ", " zlib(5) ", " jpeg(5)

MNG 1.00, Februari 9, 2001:

http://www.libpng.org/pub/mng

## AUTHORS
This man page: Gerard Juyn

Multiple-image Network Graphics (MNG) Specification Version 1.00 (Februari 9, 2001): Glenn Randers-Pehrson and others (png-list@ccrc.wustl.edu).

## COPYRIGHT NOTICE
The MNG-1.00 specification is copyright (c) 1998-2001 Glenn Randers-Pehrson. See the specification for conditions of use and distribution.


idmapd.conf

package: libnfsidmap

title: idmapd.conf(5)

summary: configuration file for libnfsidmap

text:
# idmapd.conf(5)

## NAME
idmapd.conf - configuration file for libnfsidmap

## SYNOPSIS
Configuration file for libnfsidmap. Used by idmapd and svcgssd to map NFSv4 name to and from ids.

## DESCRIPTION
The idmapd.conf configuration file consists of several sections, initiated by strings of the form [General] and [Mapping]. Each section may contain lines of the form

```
  variable = value
```

The recognized sections and their recognized variables are as follows:

### [General] section variables

```

```

Verbosity

Verbosity level of debugging (Default: 0)

Domain

The local NFSv4 domain name. An NFSv4 domain is a namespace with a unique username<->UID and groupname<->GID mapping. (Default: Host's fully-qualified DNS domain name)

No-Strip

In multi-domain environments, some NFS servers will append the identity management domain to the owner and owner_group in lieu of a true NFSv4 domain. This option can facilitate lookups in such environments. If set to a value other than "none", the nsswitch plugin will first pass the name to the password/group lookup function without stripping the domain off. If that mapping fails then the plugin will try again using the old method (comparing the domain in the string to the Domain value, stripping it if it matches, and passing the resulting short name to the lookup function). Valid values are "user", "group", "both", and "none". (Default: "none")

Reformat-Group

Winbind has a quirk whereby doing a group lookup in UPN format (e.g. staff@americas.example.com) will cause the group to be displayed prefixed with the full domain in uppercase (e.g. AMERICAS.EXAMPLE.COM\staff) instead of in the familiar netbios name format (e.g. AMERICAS\staff). Setting this option to true causes the name to be reformatted before passing it to the group lookup function in order to work around this. This setting is ignored unless No-Strip is set to either "both" or "group". (Default: "false")

Local-Realms

A comma-separated list of Kerberos realm names that may be considered equivalent to the local realm name. For example, users juser@ORDER.EDU and juser@MAIL.ORDER.EDU may be considered to be the same user in the specified Domain. (Default: the host's default realm name)

Note: If a value is specified here, the default local realm must be included as well.

### [Mapping] section variables

```

```

Nobody-User

Local user name to be used when a mapping cannot be completed.

Nobody-Group

Local group name to be used when a mapping cannot be completed.

### [Translation] section variables

```

```

Method

A comma-separated, ordered list of mapping methods (plug-ins) to use when mapping between NFSv4 names and local IDs. Each specified method is tried in order until a mapping is found, or there are no more methods to try. The methods included in the default distribution include "nsswitch", "umich_ldap", and "static". (Default: nsswitch)

GSS-Methods

An optional comma-separated, ordered list of mapping methods (plug-ins) to use when mapping between GSS Authenticated names and local IDs. (Default: the same list as specified for Method)

### [Static] section variables

```

```

The "static" translation method uses a static list of GSS-Authenticated names to local user names. Entries in the list are of the form:

```
 principal@REALM = localusername
```

### [REGEX] section variables

```

```

If the "regex" translation method is specified, the following variables within the [REGEX] section are used to map between NFS4 names and local IDs.

User-Regex

Case-insensitive regular expression that extracts the local user name from an NFSv4 name. Multiple expressions may be concatenated with '|'. The first match will be used. There is no default. A basic regular expression for domain DOMAIN.ORG and realm MY.DOMAIN.ORG would be:

```
^DOMAIN\([^@]+)@MY.DOMAIN.ORG$
```

Group-Regex

Case-insensitive regular expression that extracts the local group name from an NFSv4 name. Multiple expressions may be concatenated with '|'. The first match will be used. There is no default. A basic regular expression for domain DOMAIN.ORG and realm MY.DOMAIN.ORG would be:

```
^([^@]+)@DOMAIN.ORG@MY.DOMAIN.ORG$|^DOMAIN\([^@]+)@MY.DOMAIN.ORG$
```

Prepend-Before-User

Constant string to put before a local user name when building an NFSv4 name. Usually this is the short domain name followed by '´. (Default: none)

Append-After-User

Constant string to put after a local user name when building an NFSv4 name. Usually this is '@' followed by the default realm. (Default: none)

Prepend-Before-Group

Constant string to put before a local group name when building an NFSv4 name. Usually not used. (Default: none)

Append-After-Group

Constant string to put before a local group name when building an NFSv4 name. Usually this is '@' followed by the domain name followed by another '@' and the default realm. (Default: none)

Group-Name-Prefix

Constant string that is prepended to a local group name when converting it to an NFSv4 name. If an NFSv4 group name has this prefix it is removed when converting it to a local group name. With this group names of a central directory can be shortened for an isolated organizational unit if all groups have a common prefix. (Default: none)

Group-Name-No-Prefix-Regex

Case-insensitive regular expression to exclude groups from adding and removing the prefix set by Group-Name-Prefix (Default: none)

### [UMICH_SCHEMA] section variables

```

```

If the "umich_ldap" translation method is specified, the following variables within the [UMICH_SCHEMA] section are used.

LDAP_server

LDAP server name or address (Required if using UMICH_LDAP)

LDAP_base

Absolute LDAP search base. (Required if using UMICH_LDAP)

LDAP_people_base

Absolute LDAP search base for people accounts. (Default: The LDAP_base value)

LDAP_group_base

Absolute LDAP search base for group accounts. (Default: The LDAP_base value)

LDAP_canonicalize_name

Whether or not to perform name canonicalization on the name given as LDAP_server (Default: "true")

LDAP_follow_referrals

Whether or not to follow ldap referrals. (Default: "true")

LDAP_use_ssl

Set to "true" to enable SSL communication with the LDAP server. (Default: "false")

LDAP_ca_cert

Location of a trusted CA certificate used when SSL is enabled (Required if LDAP_use_ssl is true and LDAP_tls_reqcert is not set to never)

LDAP_tls_reqcert

Controls the LDAP server certificate validation behavior. It can take the same values as ldap.conf(5)'s TLS_REQCERT tunable. (Default: "hard")

LDAP_timeout_seconds

Number of seconds before timing out an LDAP request (Default: 4)

LDAP_sasl_mech

SASL mechanism to be used for sasl authentication. Required if SASL auth is to be used (Default: None)

LDAP_realm

SASL realm to be used for sasl authentication. (Default: None)

LDAP_sasl_authcid

Authentication identity to be used for sasl authentication. (Default: None)

LDAP_sasl_authzid

Authorization identity to be used for sasl authentication. (Default: None)

LDAP_sasl_secprops

Cyrus SASL security properties. It can the same values as ldap.conf(5)'s sasl_secprops.

LDAP_sasl_canonicalize

Specifies whether the LDAP server hostname should be canonicalised. If set to yes LDAP lib with do a reverse hostname lookup. If this is not set the LDAP library's default will be used. (Default: None)

LDAP_sasl_krb5_ccname

Path to kerberos credential cache. If it is not set then the value of environment variable KRB5CCNAME will be used. If the environment variable is not set then the default mechanism of kerberos library will be used.

NFSv4_person_objectclass

The object class name for people accounts in your local LDAP schema (Default: NFSv4RemotePerson)

NFSv4_name_attr

Your local schema's attribute name to be used for NFSv4 user names (Default: NFSv4Name)

NFSv4_uid_attr

Your local schema's attribute name to be used for uidNumber (Default: uidNumber)

GSS_principal_attr

Your local schema's attribute name for GSSAPI Principal names (Default: GSSAuthName)

NFSv4_acctname_attr

Your local schema's attribute name to be used for account names (Default: uid)

NFSv4_group_objectclass

The object class name for group accounts in your local LDAP schema (Default: NFSv4RemoteGroup)

NFSv4_gid_attr

Your local schema's attribute name to be used for gidNumber (Default: gidNumber)

NFSv4_group_attr

Your local schema's attribute name to be used for NFSv4 group names (Default: NFSv4Name)

LDAP_use_memberof_for_groups

Some LDAP servers do a better job with indexing where searching through all the groups searching for the user in the memberuid list. Others like SunOne directory that search can takes minutes if there are thousands of groups. So setting LDAP_use_memberof_for_groups to true in the configuration file will use the memberof lists of the account and search through only those groups to obtain gids. (Default: false)

NFSv4_member_attr

If LDAP_use_memberof_for_groups is true, this is the attribute to be searched for. (Default: memberUid)

NFSv4_grouplist_filter

An optional search filter for determining group membership. (No Default)

## EXAMPLES
An example /etc/idmapd.conf file:

```
[General]
Verbosity = 0
Domain = domain.org
Local-Realms = DOMAIN.ORG,MY.DOMAIN.ORG,YOUR.DOMAIN.ORG
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = umich_ldap,regex,nsswitch
GSS-Methods = umich_ldap,regex,static
[Static]
johndoe@OTHER.DOMAIN.ORG = johnny
[Regex]
User-Regex = ^DOMAIN\([^@]+)@DOMAIN.ORG$
Group-Regex = ^([^@]+)@DOMAIN.ORG@DOMAIN.ORG$|^DOMAIN\([^@]+)@DOMAIN.ORG$
Prepend-Before-User = DOMAIN
Append-After-User = @DOMAIN.ORG
Append-After-Group = @domain.org@domain.org
Group-Name-Prefix = sales-
Group-Name-No-Prefix-Regex = -personal-group$
[UMICH_SCHEMA]
LDAP_server = ldap.domain.org
LDAP_base = dc=org,dc=domain
```

## SEE ALSO
idmapd(8) svcgssd(8)

## BUGS
Report bugs to <nfsv4@linux-nfs.org>