title: ipmi_sim_cmd(5)

text:
# ipmi_sim_cmd(5)

## DESCRIPTION
The ipmi_sim emulation is set up using these commands. They can be read from a command file, run from the command line, or executed inside the simulator after it is started.

This may be a little confusing, but the network interfaces are configured by the ipmi_lan configuration file, and the various management controllers, sensors, etc. are specified using this file. Plus, this can be used to configure the simulator after it is up, set sensor values, inject events, and things of that nature.

## GENERAL COMMANDS
Blank lines and lines starting with `#' are ignored. Long lines may be broken up by putting a '´ at the end of the line to be continued.

quit

Exit the simulator

include "file"

Include the given file.

define name "value"

Define the given name as a variable with the given value. This variable may be used later by doing $name. This cannot be used in quotes, but quotes may be broken up and the variable put between them. For instance, if you say:

define MCNUM "40"

you can use it later as in

mc_add $MCNUM 1 no-device-sdrs 00 00 00 0xc9 0x009000 0x0002

or

sensor_add $MCNUM 0 21 12 0x6f poll 1000 file "/sys/dev/sens1-"$MCNUM"-1"

sleep time

Pause the command interface for the given number of seconds. This does not affect the execution of the simulator.

debug options

Set the debugging output. Valid options are: msg Dump messages.

raw Dump raw I/O

Entering nothing turns of debugging.

read_cmds filename

Execute the commands in the given file.

## MC COMMANDS
mc_add IPMBAddress DeviceID HasDeviceSDRs DeviceRevision MajorFWRev MinorFWRev DeviceSupport ManufacturerID ProductID

Add an MC to the simulator. All values are hexadecimal. These are mostly values for the ``Get Device ID'' command, see the spec for details. Note that the MC is not enabled after being added, you must add it. Note that some of these values control the capabilities of the MC. For instance, HasDeviceSDRs sets whether device SDR repository commands will work.

You may use has-device-sdrs or no-device-sdrs in the HasDeviceSDRs field.

mc_add_fru_data mc-addr DeviceID FRUSize (data [byte1 [byte2 [...]]] | file offset filename)

Set the FRU data for a given MC and device id. Data may be supplied directly here, or it may be given as a file. The offset is the start from the beginning of the file where the data is kept.

mc_dump_fru_data mc-addr DeviceID

Dump the FRU data for a given MC and device id.

mc_delete mc-addr

Remove the MC from the system.

mc_disable mc-addr

Disable the MC, but don't remove it.

mc_enable mc-addr

Enable the given MC.

mc_setbmc mc-addr

Set the BMC's address.

mc_set_guid mc-addr guid

Set the GUID value. The guid may be a string (in quotes) or a hexadecimal string.

sel_enable mc-addr max-entries flags

Enable the System Event Log on the given MC. The flags is a byte this is returned from the ``Get SEL Info'' command; it controls various aspects of the SEL. See the spec for details.

sel_add mc-addr RecordType byte1 byte2 ... byte13

Add an entry to the MC's SEL.

main_sdr_add mc-addr byte1 [byte2 [...]]

Add an entry to the main SDR of the MC.

device_sdr_add mc-addr LUN byte1 [byte2 [...]]

Add an entry to the device SDR of the MC.

## SENSOR COMMANDS
sensor_add mc-addr LUN sensor-num sensor-type event-reading-code [poll poll_rate poll_type poll_type_options] [event-only]

Add a sensor to the given MC and LUN. The type of sensor is set by the event reading code.

If poll is specified, then the sensor will be polled for data. Only the file poll type is currently supported. The value is a number read from a file. It has the following options, all optional:

div=val will divide the read value by the given number. This is done after the multiply operation.

mult=val will multiply the read value by the given number. This is done after the subtraction.

sub=val will subtract the value by the given number. This is done after the mask.

mask=val will mask (bitwise and) the value by the given number.

base=value Specify the base of the value read from the file. By default this is zero, meaning "C" conventions are used.

initstate=value sets what the event state is initially set to. This is useful for discrete sensors with bits that should normally be set to "1", like a presence bit, to keep the program from issuing an event every time the program starts.

raw specifies that the data from the file is a raw value. Only length bytes are read from offset.

ascii specifies that the data from the file is in ASCII. This is the default. The offset value is used, but no the length.

length=val specifies the length of the data to read from the file. The maximum value is 4,and this is only used for raw data.

depends=<mc_addr>,<lun>,<sensor_number>,<bit> specifies a discrete sensor bit that must be set to 1 for the sensor to be active. Generally, you use the presence bit of a sensor to mark whether other sensors on the device are actually present. Each of the other sensors would have one of these pointing to the presence bit.

event-only specifies that the sensor will not be readable, it will only generate events (specified with a type 3 SDR).

sensor_set_bit mc-addr LUN sensor-num bit-to-set bit-value generate-event

Set the given bit to bit-value (0 or 1) for the sensor by bit number, either the threshold for analog or the discrete sensor bit. If generate-event is non-zero and the sensor has events enabled for that bit, then generate an event.

sensor_set_bit_clr_rest mc-addr LUN sensor-num bit-to-set bit-value generate-event

Like sensor_set_bit, but automatically clears all other bits.

sensor_set_value mc-addr LUN sensor-num value generate-event

Set the byte value for an analog sensor. If the sensor exceeds a threshold, the sensor has events enabled, and generate-event is non-zero, then generate an event for the condition.

sensor_set_hysteresis mc-addr LUN sensor-num support positive negative

Set the hysteresis capabilities of the sensor. It must be an analog sensor. The support value is the hysteresis capability, the same as the hysteresis support value in the sensor SDR. The positive and negative hysteresis values are also set by this command. The support value may also be none, readable, settable, or fixed instead of the numbers.

sensor_set_threshold mc-addr LUN sensor-num threshold-support threshold-enabled [value5 [value4 [... [value0]]]]

Set the threshold support for a sensor. It must be an analog sensor. The threshold-support value is the same as the threshold access support value in the sensor SDR. The threshold-enabled values is a string of ``0'' and ``1'' characters that enable the 6 corresponding thresholds; the rightmost value is value 0, the leftmost is value 5. Optionally, the threshold values may be specified as their byte values.

The threshold-support value may also be none, readable, settable, or fixed to make it a bit more readable. The thresholds are:

0 - lower non critical

1 - lower critical

2 - lower non recoverable

3 - upper non critical

4 - upper critical

5 - upper non recoverable

sensor_set_event_support mc-addr LUN sensor-num events-enable scanning event-support assert-support deassert-support assert-enabled deassert-enabled

Set the event support of a sensor. The events-enable will enable global events on the sensor if non-zero, otherwise they are disabled. The scanning values set the scanning value for the sensor. The event-support value sets the event capabilities in the sensor, this is the same as the ``sensor event message control support'' value in the sensor SDR. The assert-support, deassert-support, assert-enabled, and deassert-enabled are all bitmasks (a string of ``0'' and ``1'' characters) that set their corresponding sensor bit's capability to generate events (support) and whether it will generate events now (enabled).

Note that all bitmasks have the rightmost digit as the zeroth bit, and the leftmost digit as the highest order bit. Note that you must specify 15 bits here, even if you don't use all of them.

Note that you may use enable or disable in the events-enable field, and you may use scanning or no-scanning in the scanning field.

For event-support, you may use per-state, entire-sensor, global or none instead of a number.

For a threshold sensor, the values are:

0

- lower non-critical going low

1

- lower non-critical going high

2

- lower critical going low

3

- lower critical going high

4

- lower non-recoverable going low

5

- lower non-recoverable going high

6

- upper non-critical going low

7

- upper non-critical going high

8

- upper critical going low

9

- upper critical going high

1

- upper non-recoverable going low

1

- upper non-recoverable going high

Note that the "lower going high" and "upper going low" values are not supported, since they are simply stupid.

## ATCA OEM COMMANDS
These are for emulation of special ATCA capabilities.

atca_enable

The system is an ATCA system, enables the other ATCA capabilities. Note that you should do this *before* creating any MCs (this should really be first) because the MCs are set up a little differently for ATCA mode. This causes the MCs to be able to handle PICMG commands properly, sets up 2 LEDs by default, and enables proper hot-swap handling, including the blue LED. By default the blue LED supports local control and the other LEDs do not and are red.

In ATCA mode, to drive the hot-swap state machine, you should use sensor_set_bit_clr_rest to set the hot-swap state.

atca_set_site hardware-address site-type site-number

Sets the given values for an ATCA system, the values returned by the get address commands.

mc_set_num_leds mc-addr count

Set the number of ATCA LEDs the MC has.

mc_set_power mc-addr power gen-event

Set the ATCA power setting for the MC as its numeric value. If gen-event is non-zero, generate an event for the change.

## FILES
/etc/ipmi/lan.conf

## SEE ALSO
ipmi_sim(1)

## KNOWN PROBLEMS
IPMI is unnecessarily complicated. Hords of capabilities are not yet implemented.

## AUTHOR
Corey Minyard <cminyard@mvista.com>


title: openl2tpd.conf(5)

summary: OpenL2TP configuration file

text:
# openl2tpd.conf(5)

## NAME
openl2tpd.conf - OpenL2TP configuration file

## SYNOPSIS
This document describes the configuration file syntax of OpenL2TP.

## DESCRIPTION
The configuration file syntax is the same as that written by l2tpconfig's config save command. The file contains a number of l2tpconfig create and modify commands, though the commands aren't processed by l2tpconfig - they are processed by openl2tpd directly when it starts up and again if it receives a SIGHUP signal.

The preferred way to save and restore openl2tpd configuration information is to use the l2tpconfig utility's config save and config restore commands. The local configuration file support is usually enabled only when l2tpconfig is not available.

See l2tpconfig(1) for a list of all available create and modify commands.

A # character on the first line is used to begin a comment line.

A \ character at the end of a line is used to break a long command into multiple lines.

Commands are processed in order. If a tunnel create command references a named peer profile, the profile must be created before the tunnel create command.

A config file written by the config save command of the l2tpconfig utility may be copied to /etc/openl2tpd.conf if desired, in order to have the configuration automatically applied when openl2tpd restarts. However, the preferred method to reload saved configuration is to use l2tpconfig config restore file=xxx.

## EXAMPLES

```
tunnel profile create profile_name=one \
	hello_timeout=30
tunnel create tunnel_name=one dest_ipaddr=10.1.2.3 \
	profile_name=one
```

## SEE ALSO
l2tpconfig(1), openl2tp(7), openl2tpd(8),


ldap.conf

package: openldap-common

title: ldap.conf(5)

text:
# ldap.conf(5)

## NAME
ldap.conf, .ldaprc - LDAP configuration file/environment variables

## SYNOPSIS
/etc/openldap/ldap.conf, ldaprc, .ldaprc, $LDAP<option-name>

## DESCRIPTION
If the environment variable LDAPNOINIT is defined, all defaulting is disabled.

The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients.

Users may create an optional configuration file, ldaprc or .ldaprc, in their home directory which will be used to override the system-wide defaults file. The file ldaprc in the current working directory is also used.

Additional configuration files can be specified using the LDAPCONF and LDAPRC environment variables. LDAPCONF may be set to the path of a configuration file. This path can be absolute or relative to the current working directory. The LDAPRC, if defined, should be the basename of a file in the current working directory or in the user's home directory.

Environmental variables may also be used to augment the file based defaults. The name of the variable is the option name with an added prefix of LDAP. For example, to define BASE via the environment, set the variable LDAPBASE to the desired value.

Some options are user-only. Such options are ignored if present in the ldap.conf (or file specified by LDAPCONF).

Thus the following files and variables are read, in order:

```
    variable     $LDAPNOINIT, and if that is not set:

    system file  /etc/openldap/ldap.conf,

    user files   $HOME/ldaprc,  $HOME/.ldaprc,  ./ldaprc,

    system file  $LDAPCONF,

    user files   $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,

    variables    $LDAP<uppercase option name>.
```

Settings late in the list override earlier ones.

## SYNTAX
The configuration options are case-insensitive; their value, on a case by case basis, may be case-sensitive.

Blank lines are ignored.

Lines beginning with a hash mark (`#') are comments, and ignored.

Valid lines are made of an option's name (a sequence of non-blanks, conventionally written in uppercase, although not required), followed by a value. The value starts with the first non-blank character after the option's name, and terminates at the end of the line, or at the last sequence of blanks before the end of the line. The tokenization of the value, if any, is delegated to the handler(s) for that option, if any. Quoting values that contain blanks may be incorrect, as the quotes would become part of the value. For example,

```
	# Wrong - erroneous quotes:
	URI     "ldap:// ldaps://"
	# Right - space-separated list of URIs, without quotes:
	URI     ldap:// ldaps://
	# Right - DN syntax needs quoting for Example, Inc:
	BASE    ou=IT staff,o="Example, Inc",c=US
	# or:
	BASE    ou=IT staff,o=Example\2C Inc,c=US
	# Wrong - comment on same line as option:
	DEREF   never           # Never follow aliases
```

A line cannot be longer than LINE_MAX, which should be more than 2000 bytes on all platforms. There is no mechanism to split a long line on multiple lines, either for beautification or to overcome the above limit.

## OPTIONS
The different configuration options are:

URI <ldap[si]://[name[:port]] ...>

Specifies the URI(s) of an LDAP server(s) to which the LDAP library should connect. The URI scheme may be any of ldap, ldaps or ldapi, which refer to LDAP over TCP, LDAP over SSL (TLS) and LDAP over IPC (UNIX domain sockets), respectively. Each server's name can be specified as a domain-style name or an IP address literal. Optionally, the server's name can followed by a ':' and the port number the LDAP server is listening on. If no port number is provided, the default port for the scheme is used (389 for ldap://, 636 for ldaps://). For LDAP over IPC, name is the name of the socket, and no port is required, nor allowed; note that directory separators must be URL-encoded, like any other characters that are special to URLs; so the socket /usr/local/var/ldapi

must be specified as

ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi

A space separated list of URIs may be provided.

BASE <base>

Specifies the default base DN to use when performing ldap operations. The base must be specified as a Distinguished Name in LDAP format.

BINDDN <dn>

Specifies the default bind DN to use when performing ldap operations. The bind DN must be specified as a Distinguished Name in LDAP format. This is a user-only option.

DEREF <when>

Specifies how alias dereferencing is done when performing a search. The <when> can be specified as one of the following keywords:

never

Aliases are never dereferenced. This is the default.

searching

Aliases are dereferenced in subordinates of the base object, but not in locating the base object of the search.

finding

Aliases are only dereferenced when locating the base object of the search.

always

Aliases are dereferenced both in searching and in locating the base object of the search.

HOST <name[:port] ...>

Specifies the name(s) of an LDAP server(s) to which the LDAP library should connect. Each server's name can be specified as a domain-style name or an IP address and optionally followed by a ':' and the port number the ldap server is listening on. A space separated list of hosts may be provided. HOST is deprecated in favor of URI.

NETWORK_TIMEOUT <integer>

Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.

PORT <port>

Specifies the default port used when connecting to LDAP servers(s). The port may be specified as a number. PORT is deprecated in favor of URI.

REFERRALS <on/true/yes/off/false/no>

Specifies if the client should automatically follow referrals returned by LDAP servers. The default is on. Note that the command line tools ldapsearch(1) &co always override this option.

SIZELIMIT <integer>

Specifies a size limit (number of entries) to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies a request for unlimited search size. Please note that the server may still apply any server-side limit on the amount of entries that can be returned by a search operation.

TIMELIMIT <integer>

Specifies a time limit (in seconds) to use when performing searches. The number should be a non-negative integer. TIMELIMIT of zero (0) specifies unlimited search time to be used. Please note that the server may still apply any server-side limit on the duration of a search operation.

VERSION {2|3}

Specifies what version of the LDAP protocol should be used.

TIMEOUT <integer>

Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also used for any ldap_result(3) calls where a NULL timeout parameter is supplied.

## SASL OPTIONS
If OpenLDAP is built with Simple Authentication and Security Layer support, there are more options you can specify.

SASL_MECH <mechanism>

Specifies the SASL mechanism to use.

SASL_REALM <realm>

Specifies the SASL realm.

SASL_AUTHCID <authcid>

Specifies the authentication identity. This is a user-only option.

SASL_AUTHZID <authcid>

Specifies the proxy authorization identity. This is a user-only option.

SASL_SECPROPS <properties>

Specifies Cyrus SASL security properties. The <properties> can be specified as a comma-separated list of the following:

none

(without any other properties) causes the properties defaults ("noanonymous,noplain") to be cleared.

noplain

disables mechanisms susceptible to simple passive attacks.

noactive

disables mechanisms susceptible to active attacks.

nodict

disables mechanisms susceptible to passive dictionary attacks.

noanonymous

disables mechanisms which support anonymous login.

forwardsec

requires forward secrecy between sessions.

passcred

requires mechanisms which pass client credentials (and allows mechanisms which can pass credentials to do so).

minssf=<factor>

specifies the minimum acceptable security strength factor as an integer approximating the effective key length used for encryption. 0 (zero) implies no protection, 1 implies integrity protection only, 56 allows DES or other weak ciphers, 112 allows triple DES and other strong ciphers, 128 allows RC4, Blowfish and other modern strong ciphers. The default is 0.

maxssf=<factor>

specifies the maximum acceptable security strength factor as an integer (see minssf description). The default is INT_MAX.

maxbufsize=<factor>

specifies the maximum security layer receive buffer size allowed. 0 disables security layers. The default is 65536.

SASL_NOCANON <on/true/yes/off/false/no>

Do not perform reverse DNS lookups to canonicalize SASL host names. The default is off.

## GSSAPI OPTIONS
If OpenLDAP is built with Generic Security Services Application Programming Interface support, there are more options you can specify.

GSSAPI_SIGN <on/true/yes/off/false/no>

Specifies if GSSAPI signing (GSS_C_INTEG_FLAG) should be used. The default is off.

GSSAPI_ENCRYPT <on/true/yes/off/false/no>

Specifies if GSSAPI encryption (GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG) should be used. The default is off.

GSSAPI_ALLOW_REMOTE_PRINCIPAL <on/true/yes/off/false/no>

Specifies if GSSAPI based authentication should try to form the target principal name out of the ldapServiceName or dnsHostName attribute of the targets RootDSE entry. The default is off.

## TLS OPTIONS
If OpenLDAP is built with Transport Layer Security support, there are more options you can specify. These options are used when an ldaps:// URI is selected (by default or otherwise) or when the application negotiates TLS by issuing the LDAP StartTLS operation.

TLS_CACERT <filename>

Specifies the file that contains certificates for all of the Certificate Authorities the client will recognize.

TLS_CACERTDIR <path>

Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. The TLS_CACERT is always used before TLS_CACERTDIR. This parameter is ignored with GnuTLS. When using Mozilla NSS, <path> may contain a Mozilla NSS cert/key database. If <path> contains a Mozilla NSS cert/key database and CA cert files, OpenLDAP will use the cert/key database and will ignore the CA cert files.

TLS_CERT <filename>

Specifies the file that contains the client certificate. This is a user-only option. When using Mozilla NSS, if using a cert/key database (specified with TLS_CACERTDIR), TLS_CERT specifies the name of the certificate to use:

```
	TLS_CERT Certificate for Sam Carter
```

If using a token other than the internal built in token, specify the token name first, followed by a colon:

```
	TLS_CERT my hardware device:Certificate for Sam Carter
```

Use certutil -L to list the certificates by name:

```
	certutil -d /path/to/certdbdir -L
```

TLS_ECNAME <name>

Specify the name of the curve(s) to use for Elliptic curve Diffie-Hellman ephemeral key exchange. This option is only used for OpenSSL. This option is not used with GnuTLS; the curves may be chosen in the GnuTLS ciphersuite specification.

TLS_KEY <filename>

Specifies the file that contains the private key that matches the certificate stored in the TLS_CERT file. Currently, the private key must not be protected with a password, so it is of critical importance that the key file is protected carefully. This is a user-only option. When using Mozilla NSS, TLS_KEY specifies the name of a file that contains the password for the key for the certificate specified with TLS_CERT. The modutil command can be used to turn off password protection for the cert/key database. For example, if TLS_CACERTDIR specifies /home/scarter/.moznss as the location of the cert/key database, use modutil to change the password to the empty string:

```
	modutil -dbdir ~/.moznss -changepw 'NSS Certificate DB'
```

You must have the old password, if any. Ignore the WARNING about the running browser. Press 'Enter' for the new password.

TLS_CIPHER_SUITE <cipher-suite-spec>

Specifies acceptable cipher suite and preference order. <cipher-suite-spec> should be a cipher specification for the TLS library in use (OpenSSL, GnuTLS, or Mozilla NSS). Example:

OpenSSL:

TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2

GnuTLS:

TLS_CIPHER_SUITE SECURE256:!AES-128-CBC

To check what ciphers a given spec selects in OpenSSL, use:

```
	openssl ciphers -v <cipher-suite-spec>
```

With GnuTLS the available specs can be found in the manual page of gnutls-cli(1) (see the description of the option --priority).

In older versions of GnuTLS, where gnutls-cli does not support the option --priority, you can obtain the — more limited — list of ciphers by calling:

```
	gnutls-cli -l
```

When using Mozilla NSS, the OpenSSL cipher suite specifications are used and translated into the format used internally by Mozilla NSS. There isn't an easy way to list the cipher suites from the command line. The authoritative list is in the source code for Mozilla NSS in the file sslinfo.c in the structure

```
        static const SSLCipherSuiteInfo suiteInfo[]
```

TLS_PROTOCOL_MIN <major>[.<minor>]

Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g.,

```
	TLS_PROTOCOL_MIN 3.2
```

would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This parameter is ignored with GnuTLS.

TLS_RANDFILE <filename>

Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket. The environment variable RANDFILE can also be used to specify the filename. This parameter is ignored with GnuTLS and Mozilla NSS.

TLS_REQCERT <level>

Specifies what checks to perform on server certificates in a TLS session, if any. The <level> can be specified as one of the following keywords:

never

The client will not request or check any server certificate.

allow

The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally.

try

The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated.

demand | hard

These keywords are equivalent. The server certificate is requested. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated. This is the default setting.

TLS_REQSAN <level>

Specifies what checks to perform on the subjectAlternativeName (SAN) extensions in a server certificate when validating the certificate name against the specified hostname of the server. The <level> can be specified as one of the following keywords:

never

The client will not check any SAN in the certificate.

allow

The SAN is checked against the specified hostname. If a SAN is present but none match the specified hostname, the SANs are ignored and the usual check against the certificate DN is used. This is the default setting.

try

The SAN is checked against the specified hostname. If no SAN is present in the server certificate, the usual check against the certificate DN is used. If a SAN is present but doesn't match the specified hostname, the session is immediately terminated. This setting may be preferred when a mix of certs with and without SANs are in use.

demand | hard

These keywords are equivalent. The SAN is checked against the specified hostname. If no SAN is present in the server certificate, or no SANs match, the session is immediately terminated. This setting should be used when only certificates with SANs are in use.

TLS_CRLCHECK <level>

Specifies if the Certificate Revocation List (CRL) of the CA should be used to verify if the server certificates have not been revoked. This requires TLS_CACERTDIR parameter to be set. This parameter is ignored with GnuTLS and Mozilla NSS. <level> can be specified as one of the following keywords:

none

No CRL checks are performed

peer

Check the CRL of the peer certificate

all

Check the CRL for a whole certificate chain

TLS_CRLFILE <filename>

Specifies the file containing a Certificate Revocation List to be used to verify if the server certificates have not been revoked. This parameter is only supported with GnuTLS and Mozilla NSS.

## ENVIRONMENT VARIABLES
LDAPNOINIT

disable all defaulting

LDAPCONF

path of a configuration file

LDAPRC

basename of ldaprc file in $HOME or $CWD

LDAP<option-name>

Set <option-name> as from ldap.conf

## FILES
/etc/openldap/ldap.conf

system-wide ldap configuration file

$HOME/ldaprc, $HOME/.ldaprc

user ldap configuration file

$CWD/ldaprc

local ldap configuration file

## SEE ALSO
ldap(3), ldap_set_option(3), ldap_result(3), openssl(1), sasl(3)

## AUTHOR
Kurt Zeilenga, The OpenLDAP Project

## ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.


ldif

title: ldif(5)

summary: LDAP Data Interchange Format

text:
# ldif(5)

## NAME
ldif - LDAP Data Interchange Format

## DESCRIPTION
The LDAP Data Interchange Format (LDIF) is used to represent LDAP entries and change records in text form. LDAP tools, such as ldapadd(1) and ldapsearch(1), read and write LDIF entry records. ldapmodify(1) reads LDIF change records.

This manual page provides a basic description of LDIF. A formal specification of LDIF is published in RFC 2849.

## ENTRY RECORDS
LDIF entry records are used to represent directory entries. The basic form of an entry record is:

```
	dn: <distinguished name>
	<attrdesc>: <attrvalue>
	<attrdesc>: <attrvalue>
	<attrdesc>:: <base64-encoded-value>
	<attrdesc>:< <URL>
	...
```

The value may be specified as UTF-8 text or as base64 encoded data, or a URI may be provided to the location of the attribute value.

A line may be continued by starting the next line with a single space or tab, e.g.,

```
	dn: cn=Barbara J Jensen,dc=exam
	 ple,dc=com
```

Lines beginning with a sharp sign ('#') are ignored.

Multiple attribute values are specified on separate lines, e.g.,

```
	cn: Barbara J Jensen
	cn: Babs Jensen
```

If an value contains a non-printing character, or begins with a space or a colon ':', the <attrtype> is followed by a double colon and the value is encoded in base 64 notation. e.g., the value " begins with a space" would be encoded like this:

```
	cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
```

If the attribute value is located in a file, the <attrtype> is followed by a ':<' and a file: URI. e.g., the value contained in the file /tmp/value would be listed like this:

```
	cn:< file:///tmp/value
```

Other URI schemes (ftp,http) may be supported as well. Multiple entries within the same LDIF file are separated by blank lines.

## ENTRY RECORD EXAMPLE
Here is an example of an LDIF file containing three entries.

```
	dn: cn=Barbara J Jensen,dc=example,dc=com
	cn: Barbara J Jensen
	cn: Babs Jensen
	objectclass: person
	description:< file:///tmp/babs
	sn: Jensen
	dn: cn=Bjorn J Jensen,dc=example,dc=com
	cn: Bjorn J Jensen
	cn: Bjorn Jensen
	objectclass: person
	sn: Jensen
	dn: cn=Jennifer J Jensen,dc=example,dc=com
	cn: Jennifer J Jensen
	cn: Jennifer Jensen
	objectclass: person
	sn: Jensen
	jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
	 A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
	 ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
	...
```

Note that the description in Barbara Jensen's entry is read from file:///tmp/babs and the jpegPhoto in Jennifer Jensen's entry is encoded using base 64.

## CHANGE RECORDS
LDIF change records are used to represent directory change requests. Each change record starts with line indicating the distinguished name of the entry being changed:

```
	dn: <distinguishedname>
```

```
	changetype: <[modify|add|delete|modrdn]>
```

Finally, the change information itself is given, the format of which depends on what kind of change was specified above. For a changetype of modify, the format is one or more of the following:

```
	add: <attributetype>
	<attrdesc>: <value1>
	<attrdesc>: <value2>
	...
	-
```

Or, for a replace modification:

```
	replace: <attributetype>
	<attrdesc>: <value1>
	<attrdesc>: <value2>
	...
	-
```

If no attributetype lines are given to replace, the entire attribute is to be deleted (if present).

Or, for a delete modification:

```
	delete: <attributetype>
	<attrdesc>: <value1>
	<attrdesc>: <value2>
	...
	-
```

If no attributetype lines are given to delete, the entire attribute is to be deleted.

For a changetype of add, the format is:

```
	<attrdesc1>: <value1>
	<attrdesc1>: <value2>
	...
	<attrdescN>: <value1>
	<attrdescN>: <value2>
```

For a changetype of modrdn or moddn, the format is:

```
	newrdn: <newrdn>
	deleteoldrdn: 0 | 1
	newsuperior: <DN>
```

where a value of 1 for deleteoldrdn means to delete the values forming the old rdn from the entry, and a value of 0 means to leave the values as non-distinguished attributes in the entry. The newsuperior line is optional and, if present, specifies the new superior to move the entry to.

For a changetype of delete, no additional information is needed in the record.

Note that attribute values may be presented using base64 or in files as described for entry records. Lines in change records may be continued in the manner described for entry records as well.

## CHANGE RECORD EXAMPLE
The following sample LDIF file contains a change record of each type of change.

```
	dn: cn=Babs Jensen,dc=example,dc=com
	changetype: add
	objectclass: person
	objectclass: extensibleObject
	cn: babs
	cn: babs jensen
	sn: jensen
	dn: cn=Babs Jensen,dc=example,dc=com
	changetype: modify
	add: givenName
	givenName: Barbara
	givenName: babs
	-
	replace: description
	description: the fabulous babs
	-
	delete: sn
	sn: jensen
	-
	dn: cn=Babs Jensen,dc=example,dc=com
	changetype: modrdn
	newrdn: cn=Barbara J Jensen
	deleteoldrdn: 0
	newsuperior: ou=People,dc=example,dc=com
	dn: cn=Barbara J Jensen,ou=People,dc=example,dc=com
	changetype: delete
```

## INCLUDE STATEMENT
The LDIF parser has been extended to support an include statement for referencing other LDIF files. The include statement must be separated from other records by a blank line. The referenced file is specified using a file: URI and all of its contents are incorporated as if they were part of the original LDIF file. As above, other URI schemes may be supported. For example:

```
	dn: dc=example,dc=com
	objectclass: domain
	dc: example
	include: file:///tmp/example.com.ldif
	dn: dc=example,dc=org
	objectclass: domain
	dc: example
```

This feature is not part of the LDIF specification in RFC 2849 but is expected to appear in a future revision of this spec. It is supported by the ldapadd(1), ldapmodify(1), and slapadd(8) commands.

## SEE ALSO
ldap(3), ldapsearch(1), ldapadd(1), ldapmodify(1), slapadd(8), slapcat(8), slapd-ldif(5).

"LDAP Data Interchange Format," Good, G., RFC 2849.

## ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.


slapd-bdb

package: openldap-servers

title: slapd-bdb(5)

summary: Berkeley DB backends to slapd

text:
# slapd-bdb(5)

## NAME
slapd-bdb, slapd-hdb - Berkeley DB backends to slapd

## SYNOPSIS
/etc/openldap/slapd.conf

## DESCRIPTION
The bdb backend to slapd(8) uses the Oracle Berkeley DB (BDB) package to store data. It makes extensive use of indexing and caching to speed data access.

Note that BDB is deprecated and support will be dropped in future OpenLDAP releases. Installations should use the mdb backend instead.

hdb is a variant of the bdb backend that uses a hierarchical database layout which supports subtree renames. It is both more space-efficient and more execution-efficient than the bdb backend. It is otherwise identical to the bdb behavior, and all the same configuration options apply.

It is noted that these options are intended to complement Berkeley DB configuration options set in the environment's DB_CONFIG file. See Berkeley DB documentation for details on DB_CONFIG configuration options. Where there is overlap, settings in DB_CONFIG take precedence.

## CONFIGURATION
These slapd.conf options apply to the bdb and hdb backend database. That is, they must follow a "database bdb" or "database hdb" line and come before any subsequent "backend" or "database" lines. Other database options are described in the slapd.conf(5) manual page.

cachesize <integer>

Specify the size in entries of the in-memory entry cache maintained by the bdb or hdb backend database instance. The default is 1000 entries.

cachefree <integer>

Specify the number of entries to free from the entry cache when the cache reaches the cachesize limit. The default is 1 entry.

checkpoint <kbyte> <min>

Specify the frequency for checkpointing the database transaction log. A checkpoint operation flushes the database buffers to disk and writes a checkpoint record in the log. The checkpoint will occur if either <kbyte> data has been written or <min> minutes have passed since the last checkpoint. Both arguments default to zero, in which case they are ignored. When the <min> argument is non-zero, an internal task will run every <min> minutes to perform the checkpoint. See the Berkeley DB reference guide for more details.

checksum

Enable checksum validation of DB pages whenever they are read from disk. This setting can only be configured before any database files are created.

cryptfile <file>

Specify the pathname of a file containing an encryption key to use for encrypting the database. Encryption is performed using Berkeley DB's implementation of AES. Note that encryption can only be configured before any database files are created, and changing the key can only be done after destroying the current database and recreating it. Encryption is not enabled by default, and some distributions of Berkeley DB do not support encryption.

cryptkey <key>

Specify an encryption key to use for encrypting the database. This option may be used when a separate cryptfile is not desired. Only one of cryptkey or cryptfile may be configured.

dbconfig <Berkeley-DB-setting>

Specify a configuration directive to be placed in the DB_CONFIG file of the database directory. The dbconfig directive is just a convenience to allow all necessary configuration to be set in the slapd.conf file. The options set using this directive will only be written to the DB_CONFIG file if no such file existed at server startup time, otherwise they are completely ignored. This allows one to set initial values without overwriting/destroying a DB_CONFIG file that was already customized through other means. This directive may be specified multiple times, as needed. For example:

```
	dbconfig set_cachesize 0 1048576 0
	dbconfig set_lg_bsize 2097152
```

dbnosync

Specify that on-disk database contents should not be immediately synchronized with in memory changes. Enabling this option may improve performance at the expense of data security. See the Berkeley DB reference guide for more details.

dbpagesize <dbfile> <size>

Specify the page size to use for a particular database file, in units of 1024 bytes. The default for the id2entry file is 16, the default for all other files depends on the size of the underlying filesystem's block size (typically 4 or 8). The maximum that BerkeleyDB supports is 64. This setting usually should not need to be changed, but if BerkeleyDB's "db_stat -d" shows a large amount of overflow pages in use in a file, setting a larger size may increase performance at the expense of data integrity. This setting only takes effect when a database is being newly created. See the Berkeley DB reference guide for more details.

directory <directory>

Specify the directory where the BDB files containing this database and associated indexes live. A separate directory must be specified for each database. The default is /var/lib/ldap/bases.

dirtyread

Allow reads of modified but not yet committed data. Usually transactions are isolated to prevent other operations from accessing uncommitted data. This option may improve performance, but may also return inconsistent results if the data comes from a transaction that is later aborted. In this case, the modified data is discarded and a subsequent search will return a different result.

dncachesize <integer>

Specify the maximum number of DNs in the in-memory DN cache. Ideally this cache should be large enough to contain the DNs of every entry in the database. If set to a smaller value than the cachesize it will be silently increased to equal the cachesize. The default value is 0 which means unlimited, i.e. the DN cache will grow without bound. It should be noted that the DN cache is allowed to temporarily grow beyond the configured size. It does this if many entries are locked when it tries to do a purge, because that means they're legitimately in use. Also, the DN cache never purges entries that have cached children, so depending on the shape of the DIT, it could have lots of cached DNs over the defined limit.

idlcachesize <integer>

Specify the size of the in-memory index cache, in index slots. The default is zero. A larger value will speed up frequent searches of indexed entries. An hdb database needs a large idlcachesize for good search performance, typically three times the cachesize (entry cache size) or larger.

index {<attrlist>|default} [pres,eq,approx,sub,<special>]

Specify the indexes to maintain for the given attribute (or list of attributes). Some attributes only support a subset of indexes. If only an <attr> is given, the indices specified for default are maintained. Note that setting a default does not imply that all attributes will be indexed. Also, for best performance, an eq index should always be configured for the objectClass attribute. A number of special index parameters may be specified. The index type sub can be decomposed into subinitial, subany, and subfinal indices. The special type nolang may be specified to disallow use of this index by language subtypes. The special type nosubtypes may be specified to disallow use of this index by named subtypes. Note: changing index settings in slapd.conf(5) requires rebuilding indices, see slapindex(8); changing index settings dynamically by LDAPModifying "cn=config" automatically causes rebuilding of the indices online in a background task.

linearindex

Tell slapindex to index one attribute at a time. By default, all indexed attributes in an entry are processed at the same time. With this option, each indexed attribute is processed individually, using multiple passes through the entire database. This option improves slapindex performance when the database size exceeds the dbcache size. When the dbcache is large enough, this option is not needed and will decrease performance. Also by default, slapadd performs full indexing and so a separate slapindex run is not needed. With this option, slapadd does no indexing and slapindex must be used.

lockdetect {oldest|youngest|fewest|random|default}

Specify which transaction to abort when a deadlock is detected. The default is random.

mode <integer>

Specify the file protection mode that newly created database index files should have. The default is 0600.

searchstack <depth>

Specify the depth of the stack used for search filter evaluation. Search filters are evaluated on a stack to accommodate nested AND / OR clauses. An individual stack is assigned to each server thread. The depth of the stack determines how complex a filter can be evaluated without requiring any additional memory allocation. Filters that are nested deeper than the search stack depth will cause a separate stack to be allocated for that particular search operation. These allocations can have a major negative impact on server performance, but specifying too much stack will also consume a great deal of memory. Each search stack uses 512K bytes per level. The default stack depth is 16, thus 8MB per thread is used.

shm_key <integer>

Specify a key for a shared memory BDB environment. By default the BDB environment uses memory mapped files. If a non-zero value is specified, it will be used as the key to identify a shared memory region that will house the environment.

## ACCESS CONTROL
The bdb and hdb backends honor access control semantics as indicated in slapd.access(5).

## FILES
/etc/openldap/slapd.conf

default slapd configuration file

DB_CONFIG

Berkeley DB configuration file

## SEE ALSO
slapd.conf(5), slapd-config(5), slapd-mdb(5), slapd(8), slapadd(8), slapcat(8), slapindex(8), Berkeley DB documentation.

## ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release. Originally begun by Kurt Zeilenga. Caching mechanisms originally designed by Jong-Hyuk Choi. Completion and subsequent work, as well as back-hdb, by Howard Chu.