The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available
at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this
document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity
Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
All other trademarks are the property of their respective owners.
7.4.21. verify-db.pl (Check for Corrupt Databases) .................................................... 321
A. Using the ns-slapd Command-Line Utilities 323
A.1. Overview of ns-slapd ................................................................................................ 323
A.2. Finding and Executing the ns-slapd Command-Line Utilities ........................................ 323
A.3. Utilities for Exporting Databases: db2ldif .................................................................... 323
A.4. Utilities for Restoring and Backing up Databases: ldif2db ............................................ 325
A.5. Utilities for Restoring and Backing up Databases: archive2db ...................................... 326
A.6. Utilities for Restoring and Backing up Databases: db2archive ...................................... 327
A.7. Utilities for Creating and Regenerating Indexes: db2index ........................................... 327
Glossary 329
Index 343
vii
viii
About This Reference
Red Hat Directory Server (Directory Server) is a powerful and scalable distributed directory server
based on the industry-standard Lightweight Directory Access Protocol (LDAP). Directory Server is the
cornerstone for building a centralized and distributed data repository that can be used in an intranet,
over an extranet with trading partners, or over the public Internet to reach customers.
This reference covers the server configuration and the command-line utilities. It is designed primarily
for directory administrators and experienced directory users who want to use the command-line to
access the directory. After configuring the server, use this reference to help maintain it.
The Directory Server can also be managed through the Directory Server Console, a graphical user
interface. The Red Hat Directory Server Administrator's Guide describes how to do this and explains
individual administration tasks more fully.
1. Directory Server Overview
The major components of Directory Server include:
• An LDAP server – The LDAP v3-compliant network daemon.
• Directory Server Console – A graphical management console that dramatically reduces the effort of
setting up and maintaining your directory service.
• SNMP agent – Can monitor the Directory Server using the Simple Network Management Protocol
(SNMP).
2. Examples and Formatting
Each of the examples used in this guide, such as file locations and commands, have certain defined
conventions.
2.1. Command and File Examples
All of the examples for Red Hat Directory Server commands, file locations, and other usage are given
for Red Hat Enterprise Linux 5 (32-bit) systems. Be certain to use the appropriate commands and files
for your platform.
To start the Red Hat Directory Server:
service dirsv start
Example 1. Example Command
2.2. Tool Locations
The tools for Red Hat Directory Server are located in the /usr/bin and the /usr/sbin directories.
These tools can be run from any location without specifying the tool location.
2.3. LDAP Locations
There is another important consideration with the Red Hat Directory Server tools. The LDAP tools
referenced in this guide are Mozilla LDAP, installed with Red Hat Directory Server in the /usr/lib/
ix
About This Reference
mozldap directory on Red Hat Enterprise Linux 5 (32-bit) (or /usr/lib64/mozldap for 64-bit
systems).
However, Red Hat Enterprise Linux systems also include LDAP tools from OpenLDAP in the /usr/bin directory. It is possible to use the OpenLDAP commands as shown in the examples, but you must
use the -x argument to disable SASL, which OpenLDAP tools use by default.
2.4. Text Formatting and Styles
Certain words are represented in different fonts, styles, and weights. Different character formatting is
used to indicate the function or purpose of the phrase being highlighted.
Formatting StylePurpose
Monospace fontMonospace is used for commands, package
names, files and directory paths, and any text
displayed in a prompt.
Monospace
with a
background
Italicized textAny text which is italicized is a variable, such
Bolded textMost phrases which are in bold are application
Other formatting styles draw attention to important text.
This type of formatting is used for anything
entered or returned in a command prompt.
as instance_name or hostname. Occasionally,
this is also used to emphasize a new term or
other phrase.
names, such as Cygwin, or are fields or
options in a user interface, such as a User
Name Here: field or Save button.
NOTE
A note provides additional information that can help illustrate the behavior of the
system or provide more detail for a specific issue.
IMPORTANT
Important information is necessary, but possibly unexpected, such as a configuration
change that will not persist after a reboot.
WARNING
A warning indicates potential data loss, as may happen when tuning hardware for
maximum performance.
x
Additional Reading
3. Additional Reading
The Directory Server Administrator's Guide describes how to set up, configure, and administer Red
Hat Directory Server and its contents. this manual does not describe many of the basic directory and
architectural concepts that you need to deploy, install, and administer a directory service successfully.
Those concepts are contained in the Red Hat Directory Server Deployment Guide. You should read
that book before continuing with this manual.
When you are familiar with Directory Server concepts and have done some preliminary planning for
your directory service, install the Directory Server. The instructions for installing the various Directory
Server components are contained in the Red Hat Directory Server Installation Guide. Many of the
scripts and commands used to install and administer the Directory Server are explained in detail in the
Red Hat Directory Server Configuration, Command, and File Reference.
Also, Managing Servers with Red Hat Console contains general background information on how to
use the Red Hat Console. You should read and understand the concepts in that book before you
attempt to administer Directory Server.
The document set for Directory Server contains the following guides:
• Red Hat Directory Server Release Notes contain important information on new features, fixed bugs,
known issues and workarounds, and other important deployment information for this specific version
of Directory Server.
• Red Hat Directory Server Deployment Guide provides an overview for planning a deployment of the
Directory Server.
• Red Hat Directory Server Administrator's Guide contains procedures for the day-to-day maintenance
of the directory service. Includes information on configuring server-side plug-ins.
• Red Hat Directory Server Configuration, Command, and File Reference provides reference
information on the command-line scripts, configuration attributes, and log files shipped with
Directory Server.
• Red Hat Directory Server Installation Guide contains procedures for installing your Directory Server
as well as procedures for migrating from a previous installation of Directory Server.
• Red Hat Directory Server Schema Reference provides reference information about the Directory
Server schema.
• Red Hat Directory Server Plug-in Programmer's Guide describes how to write server plug-ins in
order to customize and extend the capabilities of Directory Server.
• Using Red Hat Console gives an overview of the primary user interface and how it interacts with
the Directory Server and Administration Server, as well as how to perform basic management tasks
through the main Console window.
• Using the Admin Server describes the different tasks and tools associated with the Administration
Server and how to use the Administration Server with the Configuration and User Directory Server
instances.
For the latest information about Directory Server, including current release notes, complete product
documentation, technical notes, and deployment information, see the Red Hat Directory Server
documentation site at http://www.redhat.com/docs/manuals/dir-server/.
xi
About This Reference
4. Giving Feedback
If there is any error in this Configuration, Command, and File Reference or there is any way to improve
the documentation, please let us know. Bugs can be filed against the documentation for Red Hat
Directory Server through Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific
as possible, so we can be more effective in correcting any issues:
• Select the Red Hat Directory Server product.
• Set the component to Doc - cli-guide.
• Set the version number to 8.1.
• For errors, give the page number (for the PDF) or URL (for the HTML), and give a succinct
description of the problem, such as incorrect procedure or typo.
For enhancements, put in what information needs to be added and why.
• Give a clear title for the bug. For example, "Incorrect command example for setupscript options" is better than "Bad example".
We appreciate receiving any feedback — requests for new sections, corrections, improvements,
enhancements, even new ways of delivering the documentation or new styles of docs. You are
welcome to contact Red Hat Content Services directly at mailto:docs@redhat.com.
5. Documentation History
Revision
8.1.10
Adding information about setting an idle timeout period for large databases for the replication user,
per Bugzilla #618055.
Revision 8.1.9 February 11, 2010Ella Deon Lackey
Clarifying how passwordUnlock works, per Bugzilla #552377.
Changing thensDirectoryServerTask object class to extensibleObject, per Bugzilla #555787.
Adding extra reference to the 64-bit tools directory, per Bugzilla #554972.
Revision 8.1.8 January 11, 2010Ella Deon Lackey
Adding section on nsslapd-cachememsize and the import buffer size, per Bugzilla #531043.
July 29, 2010Ella Deon Lackey
Revision 8.1.7 October 10, 2009Ella Deon Lackey
Fixing two plug-in descriptions.
Revision 8.1.6 September 19, 2009Ella Deon Lackey
Removing the silent configuration parameters for the register-ds-admin.pl script, per Bugzilla
#514231.
xii
Documentation History
Revision 8.1.5 September 9, 2009Ella Deon Lackey
Removing any references to the Directory Server Gateway or Org Chart.
Revision 8.1.4 September 4, 2009Ella Deon Lackey
Correcting the directory paths for configuration LDIF files, per Bugzilla #521139.
Revision 8.1.3 August 26, 2009Ella Deon Lackey
Adding information about setting database and entry cache memory sizes and clarifying the units
of measurement for the attributes, per Bugzilla #503615.
Revision 8.1.2 August 4, 2009Ella Deon Lackey
Changed the default on the nsslapd-cache-autosize parameter to 0, per Bugzilla #514282.
Revision 8.1.1 July 19, 2009Ella Deon Lackey
Expanding the description of dnaNextRange, Bugzilla #512557.
Revision 8.1.0 April 28, 2009Ella Deon Lackey dlackey@redhat.com
Initial draft for version 8.1.
xiii
xiv
Chapter 1.
Introduction
Directory Server is based on an open-systems server protocol called the Lightweight Directory Access
Protocol (LDAP). The Directory Server is a robust, scalable server designed to manage large scale
directories to support an enterprise-wide directory of users and resources, extranets, and e-commerce
applications over the Internet. The Directory Server runs as the ns-slapd process or service on the
machine. The server manages the directory databases and responds to client requests.
This reference deals with the other methods of managing the Directory Server by altering the server
configuration attributes using the command line and using command-line utilities and scripts.
1.1. Directory Server Configuration
The format and method for storing configuration information for Directory Server and a listing for all
server attributes are found in two chapters, Chapter 2, Core Server Configuration Reference and
Chapter 3, Plug-in Implemented Server Functionality Reference.
1.2. Directory Server Instance File Reference
Chapter 4, Server Instance File Reference has an overview of the files and configuration information
stored in each instance of Directory Server. This is useful reference to helps administrators understand
the changes or absence of changes in the course of directory activity. From a security standpoint, this
also helps users detect errors and intrusion by highlighting normal changes and abnormal behavior.
1.3. Using Directory Server Command-Line Utilities
Directory Server comes with a set of configurable command-line utilities that can search and modify
entries in the directory and administer the server. Chapter 6, Command-Line Utilities describes these
command-line utilities and contains information on where the utilities are stored and how to access
them. In addition to these command-line utilities, Directory Server also provides ns-slapd commandline utilities for performing directory operations, as described in Appendix A, Using the ns-slapd
Command-Line Utilities.
1.4. Using Directory Server Command-Line Scripts
In addition to command-line utilities, several non-configurable scripts are provided with the Directory
Server that make it quick and easy to perform routine server administration tasks from the commandline. Chapter 7, Command-Line Scripts lists the most frequently used scripts and contains information
on where the scripts are stored and how to access them.
1
2
Chapter 2.
Core Server Configuration Reference
The configuration information for Red Hat Directory Server is stored as LDAP entries within the
directory itself. Therefore, changes to the server configuration must be implemented through the
use of the server itself rather than by simply editing configuration files. The principal advantage
of this method of configuration storage is that it allows a directory administrator to reconfigure the
server using LDAP while it is still running, thus avoiding the need to shut the server down for most
configuration changes.
This chapter gives details on how the configuration is organized and how to alter it. The chapter also
provides an alphabetical reference for all attributes.
2.1. Overview of the Directory Server Configuration
When the Directory Server is set up, its default configuration is stored as a series of LDAP entries
within the directory, under the subtree cn=config. When the server is started, the contents of the
cn=config subtree are read from a file (dse.ldif) in LDIF format. This dse.ldif file contains
all of the server configuration information. The latest version of this file is called dse.ldif, the
version prior to the last modification is called dse.ldif.bak, and the latest file with which the server
successfully started is called dse.ldif.startOK.
Many of the features of the Directory Server are designed as discrete modules that plug into the core
server. The details of the internal configuration for each plug-in are contained in separate entries
under cn=plugins,cn=config. For example, the configuration of the Telephone Syntax Plug-in is
contained in this entry:
cn=Telephone Syntax,cn=plugins,cn=config
Similarly, database-specific configuration is stored under
cn=ldbm database,cn=plugins,cn=config for local databases and cn=chaining
database,cn=plugins,cn=config for database links.
The following diagram illustrates how the configuration data fits within the cn=config directory
information tree.
Figure 2.1. Directory Information Tree Showing Configuration Data
2.1.1. LDIF and Schema Configuration Files
The Directory Server configuration data are stored in LDIF files in the /etc/dirsrv/
slapd-instance_name directory (/etc/opt/dirsrv/slapd-instance_name on HP-UX). Thus,
3
Chapter 2. Core Server Configuration Reference
if a server identifier is phonebook, then for a Directory Server on Red Hat Enterprise Linux 5 (32-bit),
the configuration LDIF files are all stored under /etc/dirsrv/slapd-phonebook.
This directory also contains other server instance-specific configuration files.
Schema configuration is also stored in LDIF format, and these files are located in the /etc/dirsrv/slapd-instance_name/schema directory (/etc/opt/dirsrv/slapd->instance_name on HP-
UX).
The following table lists all of the configuration files that are supplied with the Directory Server,
including those for the schema of other compatible servers. Each file is preceded by a number which
indicates the order in which they should be loaded (in ascending numerical and then alphabetical
order).
Configuration FilenamePurpose
dse.ldifContains front-end Directory Specific Entries
created by the directory at server startup. These
include the Root DSE ("") and the contents of
cn=config and cn=monitor (ACIs only).
00core.ldifContains only those schema definitions
necessary for starting the server with the bare
minimum feature set (no user schema, no
schema for any non-core features). The rest
of the schema used by users, features, and
applications is found in 01common.ldif and the
other schema files. Do not modify this file.
01common.ldifContains LDAPv3 standard operational schema,
such as subschemaSubentry, LDAPv3
standard user and organization schema
defined in RFC 2256 (based on X.520/X.521),
inetOrgPerson and other widely-used
attributes, and the operational attributes used by
Directory Server configuration. Modifying this file
causes interoperability problems. User-defined
attributes should be added through the Directory
Server Console.
05rfc2247.ldifSchema from RFC 2247 and related pilot
schema, from "Using Domains in LDAP/X500
Distinguished Names."
05rfc2927.ldifSchema from RFC 2927, "MIME Directory Profile
for LDAP Schema." Contains the ldapSchemas
operational attribute required for the attribute to
show up in the subschema subentry.
10presence.ldifLegacy. Schema for instant messaging presence
(online) information; the file lists the default
object classes with the allowed attributes that
must be added to a user's entry in order for
instant-messaging presence information to be
available for that user.
4
LDIF and Schema Configuration Files
Configuration FilenamePurpose
10rfc2307.ldifSchema from RFC 2307, "An Approach for Using
LDAP as a Network Information Service." This
may be superseded by 10rfc2307bis, the new
version of rfc2307, when that schema becomes
available.
20subscriber.ldifContains new schema elements and the Nortel
subscriber interoperability specification. Also
contains the adminRole and memberOf
attributes and inetAdmin object class,
previously stored in the 50ns-delegated-admin.ldif file.
25java-object.ldifSchema from RFC 2713, "Schema for
Representing Java® Objects in an LDAP
Directory."
28pilot.ldifContains pilot directory schema from RFC
1274, which is no longer recommended for
new deployments. Future RFCs which succeed
RFC 1274 may deprecate some or all of
28pilot.ldif attribute types and classes.
30ns-common.ldifSchema that contains objects classes and
attributes common to the Directory Server
Console framework.
50ns-admin.ldifSchema used by Red Hat Administration Server.
50ns-certificate.ldifSchema for Red Hat Certificate Management
System.
50ns-directory.ldifContains additional configuration schema used
by Directory Server 4.12 and earlier versions
of the directory, which is no longer applicable
to current releases of Directory Server. This
schema is required for replicating between
Directory Server 4.12 and current releases.
50ns-mail.ldifSchema used by Netscape Messaging Server to
define mail users and mail groups.
50ns-value.ldifSchema for servers' value item attributes.
50ns-web.ldifSchema for Netscape Web Server.
60pam-plugin.ldifReserved for future use.
99user.ldifUser-defined schema maintained by Directory
Server replication consumers which contains the
attributes and object classes from the suppliers.
Table 2.1. Directory Server LDIF Configuration Files
5
Chapter 2. Core Server Configuration Reference
2.1.2. How the Server Configuration Is Organized
The dse.ldif file contains all configuration information including directory-specific entries created
by the directory at server startup, such as entries related to the database. The file includes the root
Directory Server entry (or DSE, named by "") and the contents of cn=config and cn=monitor.
When the server generates the dse.ldif file, it lists the entries in hierarchical order in the order that
the entries appear in the directory under cn=config, which is usually the same order in which an
LDAP search of subtree scope for base cn=config returns the entries.
dse.ldif also contains the cn=monitor entry, which is mostly read-only, but can have ACIs set on
it.
NOTE
The dse.ldif file does not contain every attribute in cn=config. If the attribute has
not been set by the administrator and has a default value, the server will not write it to
dse.ldif. To see every attribute in cn=config, use ldapsearch.
2.1.2.1. Configuration Attributes
Within a configuration entry, each attribute is represented as an attribute name. The value of the
attribute corresponds to the attribute's configuration.
The following code sample is an example of part of the dse.ldif file for a Directory Server. The
example shows, among other things, that schema checking has been enabled; this is represented by
the attribute nsslapd-schemacheck, which takes the value on.
dn: cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsslapdConfig
nsslapd-accesslog-logging-enabled: on
nsslapd-enquote-sup-oc: off
nsslapd-localhost: phonebook.example.com
nsslapd-schemacheck: on
nsslapd-port: 389
nsslapd-localuser: nobody
...
2.1.2.2. Configuration of Plug-in Functionality
The configuration for each part of Directory Server plug-in functionality has its own separate entry
and set of attributes under the subtree cn=plugins,cn=config. The following code sample is an
example of the configuration entry for an example plug-in, the Telephone Syntax plug-in.
dn: cn=Telephone Syntax,cn=plugins,cn=config
objectclass: top
objectclass: nsSlapdPlugin
objectclass: extensibleObject
cn: Telephone Syntax
nsslapd-pluginType: syntax
nsslapd-pluginEnabled: on
6
Accessing and Modifying Server Configuration
Some of these attributes are common to all plug-ins, and some may be particular to a specific plug-in.
Check which attributes are currently being used by a given plug-in by performing an ldapsearch on
the cn=config subtree.
For a list of plug-ins supported by Directory Server, general plug-in configuration information, the plugin configuration attribute reference, and a list of plug-ins requiring restart for configuration changes,
see Chapter 3, Plug-in Implemented Server Functionality Reference.
2.1.2.3. Configuration of Databases
The o=NetscapeRoot and cn=UserRoot subtrees under the database plug-in entry contain
configuration data for the databases containing the o=NetscapeRoot suffix and the default suffix
created during setup, such as dc=example,dc=com.
These entries and their children have many attributes used to configure different database settings,
like the cache sizes, the paths to the index files and transaction logs, entries and attributes for
monitoring and statistics; and database indexes.
2.1.2.4. Configuration of Indexes
Configuration information for indexing is stored as entries in the Directory Server under the following
information-tree nodes:
For more information about indexes in general, see the Directory Server Administrator's Guide. For
information about the index configuration attributes, see Section 3.4.1, “Database Attributes under
This section discusses access control for configuration entries and describes the various ways in
which the server configuration can be viewed and modified. It also covers restrictions to the kinds
of modification that can be made and discusses attributes that require the server to be restarted for
changes to take effect.
2.2.1. Access Control for Configuration Entries
When the Directory Server is installed, a default set of access control instructions (ACIs) is
implemented for all entries under cn=config. The following code sample is an example of these
default ACIs.
These default ACIs allow all LDAP operations to be carried out on all configuration attributes by the
following users:
• Members of the Configuration Administrators group.
• The user acting as the administrator, the admin account that was configured at setup. By default,
this is the same user account which is logged into the Console.
• Members of local Directory Administrators group.
• The SIE (Server Instance Entry) group, usually assigned using the Set Access Permissions
process the main console.
For more information on access control, see the Directory Server Administrator's Guide.
2.2.2. Changing Configuration Attributes
Server attributes can be viewed and changed in one of three ways: through the Directory Server
Console, by performing ldapsearch and ldapmodify commands, or by manually editing the
dse.ldif file.
NOTE
Before editing the dse.ldif file, the server must be stopped; otherwise, the
changes are lost. Editing the dse.ldif file is recommended only for changes to
attributes which cannot be altered dynamically. See Section 2.2.2.3, “Configuration
Changes Requiring Server Restart” for further information.
The following sections describe how to modify entries using LDAP (both by using Directory Server
Console and by using the command line), the restrictions that apply to modifying entries, the
restrictions that apply to modifying attributes, and the configuration changes requiring restart.
2.2.2.1. Modifying Configuration Entries Using LDAP
The configuration entries in the directory can be searched and modified using LDAP either via the
Directory Server Console or by performing ldapsearch and ldapmodify operations in the same
way as other directory entries. The advantage of using LDAP to modify entries is changes can be
made while the server is running.
For further information, see the "Creating Directory Entries" chapter in the Directory ServerAdministrator's Guide. However, certain changes do require the server to be restarted before they are
taken into account. See Section 2.2.2.3, “Configuration Changes Requiring Server Restart” for further
information.
NOTE
As with any set of configuration files, care should be taken when changing or deleting
nodes in the cn=config subtree as this risks affecting Directory Server functionality.
8
Changing Configuration Attributes
The entire configuration, including attributes that always take default values, can be viewed by
performing an ldapsearch operation on the cn=config subtree:
ldapsearch -b cn=config -D bindDN -w password
• bindDN is the DN chosen for the Directory Manager when the server was installed (cn=Directory
Manager by default).
• password is the password chosen for the Directory Manager.
For more information on using ldapsearch, see Section 6.4, “ldapsearch”.
To disable a plug-in, use ldapmodify to edit the nsslapd-pluginEnabled attribute:
2.2.2.2. Restrictions to Modifying Configuration Entries and Attributes
Certain restrictions apply when modifying server entries and attributes:
• The cn=monitor entry and its child entries are read-only and cannot be modified, except to
manage ACIs.
• If an attribute is added to cn=config, the server ignores it.
• If an invalid value is entered for an attribute, the server ignores it.
• Because ldapdelete is used for deleting an entire entry, use ldapmodify to remove an attribute
from an entry.
2.2.2.3. Configuration Changes Requiring Server Restart
Some configuration attributes cannot be altered while the server is running. In these cases, for the
changes to take effect, the server needs to be shut down and restarted. The modifications should
be made either through the Directory Server Console or by manually editing the dse.ldif file.
Some of the attributes that require a server restart for any changes to take effect are listed below.
This list is not exhaustive; to see a complete list, run ldapsearch and search for the nsslapd-requiresrestart attribute. For example:
2.3. Core Server Configuration Attributes Reference
This section contains reference information on the configuration attributes that are relevant to the core
server functionality. For information on changing server configuration, see Section 2.2, “Accessing
and Modifying Server Configuration”. For a list of server features that are implemented as plug-ins,
see Section 3.1, “Server Plug-in Functionality Reference”. For help with implementing custom server
functionality, contact Directory Server support.
The configuration information stored in the dse.ldif file is organized as an information tree under
the general configuration entry cn=config, as shown in the following diagram.
Figure 2.2. Directory Information Tree Showing Configuration Data
Most of these configuration tree nodes are covered in the following sections.
The cn=plugins node is covered in Chapter 3, Plug-in Implemented Server Functionality Reference.
The description of each attribute contains details such as the DN of its directory entry, its default value,
the valid range of values, and an example of its use.
NOTE
Some of the entries and attributes described in this chapter may change in future
releases of the product.
2.3.1. cn=config
General configuration entries are stored in the cn=config entry. The cn=config entry is an instance
of the nsslapdConfig object class, which in turn inherits from extensibleObject object class.
10
cn=config
2.3.1.1. nsslapd-accesslog (Access Log)
This attribute specifies the path and filename of the log used to record each LDAP access. The
following information is recorded by default in the log file:
• IP address of the client machine that accessed the database.
• Operations performed (for example, search, add, and modify).
• Result of the access (for example, the number of entries returned or an error code).
For more information on turning access logging off, see the "Monitoring Server and Database Activity"
chapter in the Directory Server Administrator's Guide.
For access logging to be enabled, this attribute must have a valid path and parameter, and the
nsslapd-accesslog-logging-enabled configuration attribute must be switched to on. The table
lists the four possible combinations of values for these two configuration attributes and their outcome
in terms of disabling or enabling of access logging.
This attribute controls what is logged to the access log.
11
Chapter 2. Core Server Configuration Reference
ParameterDescription
Entry DNcn=config
Valid Values• 0 - No access logging
• 4 - Logging for internal access operations
• 256 - Logging for connections, operations, and
results
• 512 - Logging for access to an entry and
referrals
• 131072 - Provides microsecond operation
timing
• These values can be added together to
provide the exact type of logging required;
for example, 516 (4 + 512) to obtain internal
access operation, entry access, and referral
logging.
Default Value256
SyntaxInteger
Examplensslapd-accesslog-level: 256
2.3.1.3. nsslapd-accesslog-list (List of Access Log Files)
This read-only attribute, which cannot be set, provides a list of access log files used in access log
rotation.
When set to off, the server writes all access log entries directly to disk. Buffering allows the server
to use access logging even when under a heavy load without impacting performance. However, when
debugging, it is sometimes useful to disable buffering in order to see the operations and their results
right away instead of having to wait for the log entries to be flushed to the file. Disabling log buffering
can severely impact performance in heavily loaded servers.
This attribute specifies the maximum age that a log file is allowed to reach before it is deleted. This
attribute supplies only the number of units. The units are provided by the nsslapd-accesslog-logexpirationtimeunit attribute.
ParameterDescription
Entry DNcn=config
Valid Range-1 to the maximum 32 bit integer value
(2147483647)
A value of -1 or 0 means that the log never
expires.
Default Value-1
SyntaxInteger
Examplensslapd-accesslog-logexpirationtime: 2
2.3.1.6. nsslapd-accesslog-logexpirationtimeunit (Access Log Expiration
Time Unit)
This attribute specifies the units for nsslapd-accesslog-logexpirationtime attribute. If the unit
is unknown by the server, then the log never expires.
Disables and enables accesslog logging but only in conjunction with the nsslapd-accesslog
attribute that specifies the path and parameter of the log used to record each database access.
For access logging to be enabled, this attribute must be switched to on, and the nsslapd-accesslog configuration attribute must have a valid path and parameter. The table lists the four
possible combinations of values for these two configuration attributes and their outcome in terms of
disabling or enabling of access logging.
13
Chapter 2. Core Server Configuration Reference
AttributeValueLogging Enabled or Disabled
nsslapd-accesslog-loggingenabled
nsslapd-accesslog
nsslapd-accesslog-loggingenabled
nsslapd-accesslog
nsslapd-accesslog-loggingenabled
nsslapd-accesslog
nsslapd-accesslog-loggingenabled
nsslapd-accesslog
Table 2.3. dse.ldif Attributes
ParameterDescription
Entry DNcn=config
Valid Valueson | off
on
empty string
on
filename
off
empty string
off
filename
Disabled
Enabled
Disabled
Disabled
Default Valueon
SyntaxDirectoryString
Examplensslapd-accesslog-logging-enabled: off
2.3.1.8. nsslapd-accesslog-logmaxdiskspace (Access Log Maximum Disk
Space)
This attribute specifies the maximum amount of disk space in megabytes that the access logs are
allowed to consume. If this value is exceeded, the oldest access log is deleted.
When setting a maximum disk space, consider the total number of log files that can be created due
to log file rotation. Also, remember that there are three different log files (access log, audit log, and
error log) maintained by the Directory Server, each of which consumes disk space. Compare these
considerations to the total amount of disk space for the access log.
ParameterDescription
Entry DNcn=config
Valid Range-1 | 1 to the maximum 32 bit integer value
(2147483647), where a value of -1 means that
the disk space allowed to the access log is
unlimited in size.
Default Value-1
SyntaxInteger
Examplensslapd-accesslog-logmaxdiskspace: 100000
14
cn=config
2.3.1.9. nsslapd-accesslog-logminfreediskspace (Access Log Minimum
Free Disk Space)
This attribute sets the minimum allowed free disk space in megabytes. When the amount of free disk
space falls below the value specified on this attribute, the oldest access logs are deleted until enough
disk space is freed to satisfy this attribute.
ParameterDescription
Entry DNcn=config
Valid Range-1 | 1 to the maximum 32 bit integer value
This attribute sets whether access log rotation is to be synchronized with a particular time of the day.
Synchronizing log rotation this way can generate log files at a specified time during a day, such as
midnight to midnight every day. This makes analysis of the log files much easier because they then
map directly to the calendar.
For access log rotation to be synchronized with time-of-day, this attribute must be enabled
with the nsslapd-accesslog-logrotationsynchour and nsslapd-accesslog-logrotationsyncmin attribute values set to the hour and minute of the day for rotating log files.
For example, to rotate access log files every day at midnight, enable this attribute by setting its
value to on, and then set the values of the nsslapd-accesslog-logrotationsynchour and
nsslapd-accesslog-logrotationsyncmin attributes to 0.
ParameterDescription
Entry DNcn=config
Valid Valueson | off
Default Valueoff
SyntaxDirectoryString
Examplensslapd-accesslog-logrotationsync-enabled: on
This attribute sets the hour of the day for rotating access logs. This attribute must be used in
conjunction with nsslapd-accesslog-logrotationsync-enabled and nsslapd-accesslog-logrotationsyncmin attributes.
This attribute sets the minute of the day for rotating access logs. This attribute must be used in
conjunction with nsslapd-accesslog-logrotationsync-enabled and nsslapd-accesslog-logrotationsynchour attributes.
This attribute sets the time between access log file rotations. The access log is rotated when this
time interval is up, regardless of the current size of the access log. This attribute supplies only the
number of units. The units (day, week, month, and so forth) are given by the nsslapd-accesslog-logrotationtimeunit attribute.
Although it is not recommended for performance reasons to specify no log rotation since the log
grows indefinitely, there are two ways of specifying this. Either set the nsslapd-accesslog-maxlogsperdir attribute value to 1 or set the nsslapd-accesslog-logrotationtime
attribute to -1. The server checks the nsslapd-accesslog-maxlogsperdir attribute first,
and, if this attribute value is larger than 1, the server then checks the nsslapd-accesslog-logrotationtime attribute. See Section 2.3.1.16, “nsslapd-accesslog-maxlogsperdir (Access Log
Maximum Number of Log Files)” for more information.
ParameterDescription
Entry DNcn=config
Valid Range-1 | 1 to the maximum 32 bit integer value
(2147483647), where a value of -1 means that
the time between access log file rotation is
unlimited.
Default Value1
SyntaxInteger
Examplensslapd-accesslog-logrotationtime: 100
16
Loading...
+ 344 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.