博客访问： 96806
博文数量： 56
博客积分： 0
博客等级： 民兵
技术积分： 1126
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 系统运维
1.&&&&& 安装包
openldap-clients
openldap-server
2.&&&&& 配置文件
a)&&&&&& 创建模板
注意格式；证书名称；管理员，id/密码；slappasswd
b)&&&&&& 生成目录树结构
&&&&&&&&&&&&&&&&&&&
i.&&&&&&&&&&& 清空slaptest
&&&&&&&&&&&&&&&&&&
ii.&&&&&&&&&&& 权限
3.&&&&& 创建证书
ca.key&&&&& ca.crt&&&&& slapd.key(去掉密码)&&& slapd.csr(主机名一致)& slapd.crt
c)&&&&&& 导入bdb.ldif 全局管理员用户导入
5.&&&&& 创建data.ldif（用户条目）
a)&&&&&& 基准DN
b)&&&&&& 3个OU(People,Group,Admins)
c)&&&&&& RDN(People/student1,student2& Group/students)
d)&&&&&& 导入data.ldif(库的管理员)
6.&&&&& 创建autofs.ldif（autofs配置文件的条目）
a)&&&&&& auto.master
b)&&&&&& auto.home
&&&&&&&&&&&&&&&&&&&
i.&&&&&&&&&&& 使用/匹配用户名
&&&&&&&&&&&&&&&&&&
ii.&&&&&&&&&&& 指定nfs服务器共享
7.&&&&& nfs服务器配置
a)&&&&&& 创建用户。注意uid.gid.(与ldap服务器端一致)、家目录
b)&&&&&& exports(rw方式共享)
8.&&&&& 客户端（3种方式）
a)&&&&&& 图形化&& system-config-authtorcation
b)&&&&&& 命令行 authconfig&&&&& 或& authconfig-tu命令（缺点：公钥不能直接下载）
c)&&&&&& 修改配置文件nsswitch &&&& ldap.conf
2台机器 148-ldapserver|nfs &142-ldapclinet
iptables -F
setenforce 0
具体操作步骤：
yum install openldap-servers openldap-clients
cd /etc/openldap
创建ldap管理员密码redhat
[root@desktop148 ~]# slappasswd
New password:
Re-enter new password:
创建ldap服务器主配置文件，我们需要声明管理员与其密码
注意红色的是一行数据。
配置文件模板地址：/usr/share/openldap-servers/slapd.conf.obsolete
[root@desktop148
openldap]# vim /etc/openldap/slapd.conf
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
#### Encrypting Connections
TLSCACertificateFile /etc/pki/tls/certs/ca.crt
TLSCertificateFile /etc/pki/tls/certs/slapd.crt
TLSCertificateKeyFile /etc/pki/tls/certs/slapd.key
### Database Config###
database config
rootdn "cn=admin,cn=config"
rootpw redhat
access to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=authmanage by *
### Enable Monitoring
database monitor
# allow only rootdn to read the monitor
access to * by dn.exact="cn=admin,cn=config" read by * none
[root@desktop148
slapd.d]# rm -rf /etc/openldap/slapd.d/* //清空原先下面的目录树结构
[root@desktop148
slapd.d]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d& //把配置文件生成目录书结构
[root@desktop148
slapd.d]# chown -R ldap:ldap /etc/openldap/slapd.d
[root@desktop148
slapd.d]# chmod -R 000 /etc/openldap/slapd.d
[root@desktop148
slapd.d]# chmod -R u+rwX /etc/openldap/slapd.d
由于配置文件中有相应证书及路径，所以我们要将其创建
TLSCACertificateFile
/etc/pki/tls/certs/ca.crt
TLSCertificateFile
/etc/pki/tls/certs/slapd.crt
TLSCertificateKeyFile
/etc/pki/tls/certs/slapd.key
下面生成证书并且放置在/etc/pki/tls/certs下，也可以在其他目录生成，然后cp到该目录下
cd /etc/pki/tls/certs
(名字有出入)
生成ca私钥，一定要留密码。
[root@desktop148
certs]# openssl genrsa -des3 -out ca.key 4096
输入ca.key密码：uplooking
生成ca公钥，将来下发给客户端浏览器导入的。
[root@desktop148
certs]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
pass phrase for ca.key:uplooking
Name (2 letter code) [XX]:CN
or Province Name (full name) []:shanghai
Name (eg, city) [DefaultCity]:shanghai
Organization
Name (eg, company) [Default Company Ltd]:uplooking.org
Organizational
Unit Name (eg, section) []:uplooking
Name (eg, your name or your server's hostname) []:CA.uplooking.com
创建服务器私钥
[root@desktop148
slapd.d]# openssl genrsa -des3 -out slapd.key 4096
输入slapd.key:uplooking
去掉私钥密码
[root@desktop148
slapd.d]# openssl rsa -in slapd.key -out slapd.key
输入slapd.key:uplooking
以上为去掉服务器私钥密码,不然将来访问会不停的弹出输入密码的选项框
生成证书颁发机构
[root@desktop148 slapd.d]# openssl req -new -key slapd.key -out slapd.csr
Country Name (2 letter code) [XX]:CN
State or Province Name (full name) []:shanghai
Locality Name (eg, city) [DefaultCity]:shanghai
Organization Name (eg, company) [Default Company Ltd]:uplooking.org
Organizational Unit Name (eg, section) []:uplooking
Common Name (eg, your name or your server's hostname) []:desktop148.example.com
Email Address []:root@ desktop148.example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:直接回车
An optional company name []:直接回车
注意一下，Common Name要和你的主机名一致。
用CA签名并产生公钥(服务器证书)
&[root@desktop148 certs]# openssl x509 -req
-days 365 -in slapd.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out slapd.crt
pass phrase for ca.key:uplooking
在/etc/pki/tls/certs/ca.crt目录下生成，则跳过cp
[root@desktop148 slapd.d]# cp ca.crt /etc/pki/tls/certs/ca.crt
[root@desktop148 slapd.d]# cp slapd.key
/etc/pki/tls/certs/slapd.key
[root@desktop148 slapd.d]# cp slapd.crt
/etc/pki/tls/certs/slapd.crt
数据库配置
生成DB_CONFIG文件，ldap在启动过程中需要,复制到以下目录
[root@desktop148
ldap]# cp -p /usr/share/openldap-servers/DB_CONFIG.example
/var/lib/ldap/DB_CONFIG
chown ldap. /var/lib/ldap/DB_CONFIG
cd /etc/openldap(接下去的几个文件全写在这个目录下)
接下来我们要创建用户数据库，先生成ldif文件，用于描述数据库配置。
&(库信息描述、DN配置、授权等)
[root@desktop148
slapd.d]# mkdir ldif
[root@desktop148
slapd.d]# vim bdb.ldif
其中红色标注的是管理员用户名与帐号。注意空格和行，红色的是一行数据
olcDatabase=bdb,cn=config
objectClass:
olcDatabaseConfig
objectClass:
olcBdbConfig
olcDatabase:
olcSuffix:
dc=example,dc=org
olcDbDirectory:
/var/lib/ldap
olcRootDN: cn=Manager,dc=example,dc=org
olcRootPW: redhat
olcLimits: dn.exact="cn=Manager,dc=example,dc=org"
time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcDbIndex:
uid pres,eq
olcDbIndex:
cn,sn,displayName pres,eq,approx,sub
olcDbIndex:
uidNumber,gidNumber eq
olcDbIndex:
memberUid eq
olcDbIndex:
objectClass eq
olcDbIndex:
entryUUID pres,eq
olcDbIndex:
entryCSN pres,eq
olcAccess: to attrs=userPassword by self write by anonymous auth by dn.children="ou=admins,dc=example,dc=org"
write by * none&
olcAccess: to * by self write by
dn.children="ou=admins,dc=example,dc=org" write by * read
启动并导入数据库配置
slapd start& //先启动slapd服务
[root@desktop148
slapd.d]# ldapadd -x -D "cn=admin,cn=config" -w redhat -f bdb.ldif -h localhost
adding new entry "olcDatabase=bdb,cn=config" //添加成功
redhat 密码加密后导入
[root@desktop148 slapd.d]# slappasswd
New password:
Re-enter new password:
{SSHA}OLfakpNEj71gnF7G5NYSSjzJsu4kIG5+
[root@desktop148
slapd.d]# ldapadd -x -D "cn=admin,cn=config" -w {SSHA}OLfakpNEj71gnF7G5NYSSjzJsu4kIG5+ -f bdb.ldif -h localhost
创建用户数据文件并且同样导入ldap数据库中
[root@desktop148 ldif]# vim data1.ldif
dc=example,dc=org
objectClass:
objectClass:
objectclass:
organization
Example Organization
description:
LDAP Example
ou=People,dc=example,dc=org
objectClass:
organizationalUnit
ou=Groups,dc=example,dc=org
objectClass:
organizationalUnit
ou=Admins,dc=example,dc=org
objectClass:
organizationalUnit
uid=student1,ou=People,dc=example,dc=org
objectClass:
objectClass:
posixAccount
objectClass:
inetOrgPerson
loginShell:
homeDirectory:
/ldaphome/student1
uidNumber:
gidNumber:
userPassword: redhat
student1@example.org
Student1 User
uid=student2,ou=People,dc=example,dc=org
objectClass:
objectClass:
posixAccount
objectClass:
inetOrgPerson
loginShell:
homeDirectory:
/ldaphome/student2
uidNumber:
gidNumber:
userPassword: redhat
student2@example.org
Student2 User
cn=students,ou=Groups,dc=example,dc=org
objectClass:
posixGroup
objectClass:
userPassword:
gidNumber:
memberuid:
uid=student1
memberuid:
uid=student2
以上大致内容就是定义了基准DN为tudou.com,在下面有3个OU分别为people、group、admins,同时在people
ou下定义了2个用户student1和student2、group
ou下定义了students并且把student1和student2
2个用户加入进该条目,保存退出.
-x -D "cn=Manager,dc=example,dc=org" -w redhat -h localhost -f
data1.ldif
adding new entry "dc=example,dc=org"&&& //显示添加成功,如果报条目已存在，则修改data1把该条目删除，继续添加下面的条目。
adding new entry "ou=People,dc=example,dc=org"
。。。。。。。
创建自动挂载ldap用户家目录的autofs文件
[root@desktop148
ldif]# vim autofs.ldif
nisMapName=auto.master,dc=example,dc=org
objectClass:
objectClass:
nisMapName:
auto.master
cn=/ldaphome,nisMapName=auto.master,dc=example,dc=org
objectClass:
nisMapEntry:
ldap:nisMapName=auto.home,dc=example,dc=org
nisMapName:
auto.master
nisMapName=auto.home,dc=example,dc=org
objectClass:
objectClass:
nisMapName:
cn=/,nisMapName=auto.home,dc=example,dc=org
objectClass:
nisMapEntry: -rw 192.168.11.148:/ldaphome/&
nisMapName:
上述红色字体”　/ldaphome　”是ldap用户家目录的父目录，需要通过nfs导出的。
红色字体 nisMapEntry... ，是nfs服务器的地址(新增nfs，IP需改掉)，其中　& 符号用于匹配所有用户名。
之后我们将这些信息生成ldif文件并添加到LDAP 数据库中。
[root@desktop148
ldif]# ldapadd -x -D "cn=Manager,dc=example,dc=org" -w redhat -h
localhost -f /root/ldif/autofs.ldif
adding new entry
"nisMapName=auto.master,dc=example,dc=org" //添加成功
adding new entry
"cn=/ldaphome,nisMapName=auto.master,dc=example,dc=org"
adding new entry "nisMapName=auto.home,dc=example,dc=org"
adding new entry "cn=/,nisMapName=auto.home,dc=example,dc=org"
到这里为止ldap的配置已经全部完成了
另外要把ca.crt文件给放到apache的网站根目录下去
cp ca.crt /var/www/html/
service httpd start
148nfs共享
service nfs start
如果新增一台NFS，需多做以下步骤：
mkdir /ldaphome
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
vim /etc/exports
192.168.11.0/24(rw,sync)
service nfs start
创建用户：
groupadd students -g
useradd student1 -u
students -d /ldaphome/student1
useradd student2 -u
students -d /ldaphome/student2
注意这里的uid和gid号要和ldap端的data.ldif文件里定义的一样
客户端配置142
system-config-authentication
mkdir /ldaphome
service autofs start
以下步骤无需操作，ldap服务器端已经把autofs导入数据库，客户端验证通过就能同步。
yum install autofs -y
vim /etc/auto.master
/ldaphome /etc/auto.ldaphome
vim /etc/auto.ldaphome
192.168.11.148:/ldaphome/&
tty登录student2，密码redhat，studnet2家目录会自动挂载。
配置认证缓存SSSD
客户端安装sssd
install sssd
/var/lib/sss&&&& //存放缓存
运行system-config-authentication
重新再配置一次，这次可以看到sssd服务已经启动起来。
进行一次登录认证后，断开网络，再尝试登录，可以发现依然可以认证成功(登录时间比较长)。
阅读(3085) | 评论(3) | 转发(1) |
相关热门文章
给主人留下些什么吧！~~
个人觉得大系统的未来是自自组织性！！！
请登录后评论。来自Jabber/XMPP中文翻译计划
本文的英文原文来自
先翻译快速开始指南和目录复制。
版权所有 ，，保留所有权利。
版权所有年，的Regents，保留所有权利。
本文被视为OpenLDAP软件的一部分. 本文遵从和的第四款的条件. 完整的声明和相关的许可可以分别在附录K和L看到.
OpenLDAP软件和本文的一部分可能是来自其他各方和/或受到其他版权限制。单独的源文件应该有额外的版权声明。
本文的范围
本文为在UNIX (以及类似UNIX)系统上安装OpenLDAP 软件2.4版 (. 本文的目标读者是基本了解基于LDAP的目录服务的有经验的系统管理员.
本文件是用来与其他由软件包以及该项目的网站（
）上提供的OpenLDAP信息资源配合使用的。该网站的有很多来源.
OpenLDAP 资源
常见问答解答
问题跟踪系统
是一个由志愿者组成的团队。没有他们贡献的时间和精力本文是不可能的。
在OpenLDAP项目还要感谢美国对于LDAP软件和信息的建设，OpenLDAP软件是建立在它的基础上的。本文件是基于密歇根大学的以下文档而来的： 。
对本文的建议改进和更正应使用问题跟踪系统（
这份文件使用Ian Clatworthy开发的简单文件格式（SDF）文件系统（
）。SDF工具可以从 （
本文描述如何编译,配置,以及操作OpenLDAP软件来提供目录服务. 这包括如何配置和运行独立的LDAP守护进程, slapd(8). 它对于新的和有经验的管理人员是一样的。 本节提供了一个基本的目录服务的介绍，尤其是slapd(8)所提供的目录服务的介绍. 这只是提供足够的信息，以便人们开始了解的LDAP ， X.500和目录服务。
目录是一个专门的数据库，专门用于搜索和浏览，另外也支持基本的查询和更新功能。
注意: 目录被一些人视为仅仅是一个优化了读取操作的数据库。这一定义，往最好了说，是过于简单化了。
目录往往包含描述性的，基于属性的信息和支持先进的过滤功能. 目录一般不支持被设计用于处理大批量复杂更新的数据库管理系统的复杂交易或回滚计划. 目录的更新通常是简单的全有或全无的变更，如果变更被允许的话。目录一般都调整为快速反应大批量查找或搜索操作. 它们可能有能力复制广泛的信息，以提高可用性和可靠性，同时降低响应时间. 当复制目录信息时，临时的复制品之间的不一致性可能可以接受，只要矛盾及时得到解决.
有许多不同的方式提供一个目录服务. 不同的方法允许不同种类的信息存储在目录中，对于信息可以如何转发，查询和更新，以及如何保护未经授权的访问，等有不同的要求. 一些目录服务是本地的，提供服务给一个限制的范围内（例如，一台机器的finger服务）. 其他服务是全球性的，提供服务给更广泛的范围内（例如，整个互联网） 。全球服务通常是分散的，也就是说，它们包含的数据是分散在许多机器，所有这些合作来提供目录服务. 通常情况下一个全球性的服务定义了一个统一的名字空间，提供同一视图的数据，无论您身在何处和数据本身有何关系。
一个网站目录，如开放式目录管理项目&&提供的 ，就是一个很好的目录服务例子. 这些服务把网页目录化，并专门设计用于支持浏览和搜索。
虽然有些人认为，因特网的域名系统（ DNS ）是一个例子，一个全球分布式目录服务，但是DNS是不能浏览或搜寻的. 它更准确的描述是一个全球型的分布查找服务.
LDAP表示轻型目录访问协议. 顾名思义，它是一个轻量级协议，用于访问目录服务，特别是基于X.500的目录服务. LDAP运行在TCP / IP或其他面向连接的传输服务. LDAP是一个IETF标准跟踪协议，在“轻量级目录访问协议（ LDAP ）技术规范路线图”RFC4510中被指定。
本节概述了从用户的角度来看LDAP的样子。
什么样的信息可以存储在目录? LDAP信息模型是基于条目的. 一个条目是一个属性的集合，有一个全球唯一的识别名（ DN ）. DN用于明白无误地标识条目. 每个条目的属性有一个类型和一个或多个值. 该类型通常是可记忆的字符串，如“ cn ”就是标识通用名称，或“电子邮件”就是电子邮件地址。 值的语法依赖于属性类型. 例如, 一个 cn 属性可以包含一个值 Babs Jensen. 一个 mail 属性可以包含值"". 一个 jpegPhoto 属性将包含一个JPEG (binary) 格式的照片.
信息如何组织? 在LDAP, 目录条目都被排列在一个分层树形结构。传统上，这种结构反映了地域和/或组织界限. 代表国家的条目出现在树的顶端。它们下面是代表州和国家组织的条目. 再下面可能是代表组织单位,人,打印机,文档,或只是任何你你能想象到的东西. 图1.1所示的LDAP目录树中使用传统的命名。
图 1.1: LDAP 目录树 (传统的命名)
树也可以根据互联网域名组主。这种命名方式正越来越受欢迎，因为它允许使用DNS为目录服务定位 。图1.2所示的LDAP目录树中使用基于域的命名。
图 1.2: LDAP 目录树(Internet命名)
此外，可让您的LDAP控制在一个条目中哪个属性是必需的和允许的，通过使用一种特殊属性objectClass。objectClass属性的值确定条目必须遵守的架构规则。
信息是如何引用的的? 一个条目所引用的辨别名称，是构造于名字本身（称为相对辨别名称Relative Distinguished Name或RDN ）再串连其祖先条目的名字。 例如, 在上面Internet命名例子里的条目 Barbara Jensen 有一个 RDN 为 uid=babs 和一个 DN 为 uid=babs,ou=People,dc=example,dc=com. 全 DN 格式在 RFC4514 中的 "LDAP: String Representation of Distinguished Names."有描述.
如何访问信息? LDAP定义了查问和更新目录的操作. 提供的操作包括，从一个目录增加和删除一个条目,变更一个已存在的条目，以及变更一个条目的名字. 尽管，绝大部分时间, LDAP 是用于在目录中搜索信息. LDAP搜索操作允许目录的一些部分被搜索以寻找那些满足搜索过滤器规定的条件的条目. 可以请求每个和要求相匹配的条目的信息。
例如, 你可以在 dc=example,dc=com之下的整个目录树，搜索一个人，他的名字是 Barbara Jensen, 接收每个发现的条目的 email 地址. LDAP 让你很简单地完成这件事. 或者你可能想直接在st=California,c=US下搜索， organizations 为Acme 的所有条目的名字以及传真号码. LDAP 也能让你做到. 下一节对于你能用LDAP做什么和它如何帮助你做更详细的描述.
如何从未授权的访问中保护信息? 一些目录服务不提供保护, 允许任何人查看信息. LDAP提供了给客户一个机制，向一个目录服务器验证或保护他的标识，提供了丰富的访问控制方法来保护服务器包含的信息. LDAP也支持数据安全 (完整性和保密性) 服务.
这是个非常好的问题. 通常，当你需要通过标准化的方法访问集中化管理和存储的数据时，你应该使用一个目录服务器.
工业界一些常见(但不限于此)的例子如下:
用户/系统 组
组织机构表
电话信息存储
用户资源管理
E-mail地址查找
应用配置存储
PBX配置存储
虽然有各种基于标准的分布式规划文件, 但是你总是可以建立自己的规划规范.
你总是可以有新的办法来使用目录和应用LDAP原理来解决特定的问题, 所以这个问题不存在一个简单的答案.
如果有任何疑问, 加入常见的 LDAP 论坛来参加非商业性的讨论和获得关于LDAP的信息:
当你开始发现自己用目录来做你需要做的事情的时候很别扭, 就可能需要重新设计了（译者：这不等于没说吗？）. 或者你只是需要一个应用来使用和操作你的数据(关于 LDAP vs RDBMS, 参见 LDAP vs RDBMS 节).
当LDAP对某项工作很合适的时候，很明显就能看出来（译者：还是白说啊）。
LDAP采用客户－服务器模式. 包含在一个或多个LDAP服务器中的数据组成了目录信息树(DIT). 客户端连接到服务器然后问一个问题. 服务器返回一个应答和/或一个指针告诉客户端去哪里获得更多的信息 (通常是另一台 LDAP 服务器). 客户端连接哪台LDAP服务器不重要, 目录的视图看起来都一样; 一个提交到某台LDAP服务器的名字在另一台LDAP服务器上也将指向相同的条目. 这是全球目录服务的一个重要功能.
技术上来讲, LDAP是一个针对X.500目录服务(OSI目录服务)的目录访问协议. 起初, LDAP客户端通过网关访问 X.500 目录服务. 客户端和网关之间跑的是LDAP，而网关和X.500服务之间跑的是 X.500 的 目录访问协议 (DAP) . DAP是一个重量级的协议,它操作完整的OSI协议栈并且需要大量的计算资源. LDAP设计成通过TCP/IP操作并以非常少的开销来提供DAP的大部分功能.
虽然 LDAP 仍被用于通过网关访问 X.500 目录服务, LDAP 现在更常见的是直接在X.500服务器上实现.
标准的 LDAP 守护进程, 或曰 slapd(8), 可以被视为一个轻量级的 X.500 目录服务. 也就是说, 它既不由 X.500's DAP 实现，也不支持完整的 X.500 模型.
如果你以及功能运行了一个 X.500 DAP 服务并且你想继续这么干, 可能你不用读这本指南了. 这份指南全部是关于通过 slapd(8)运行 LDAP , 而不是运行 X.500 DAP. 如果你没有运行 X.500 DAP, 希望停止运行 X.500 DAP, 或最近没有打算运行 X.500 DAP, 请继续.
从一个 LDAP 目录服务器复制数据到一个 X.500 DAP DSA 是有可能的. 这需要一个 LDAP/DAP 网关. OpenLDAP软件不包含这样一个网关.
LDAPv3在20实际90年代末期开发用来替代LDAPv2. LDAPv3 为LDAP增加了以下功能:
使用SASL实现强验证和数据安全服务
使用TLS (SSL)实现证书验证和数据安全服务
使用Unicode实现国际化
转发和配置
扩展性 (控制, 扩展操作, 以及更多)
LDAPv2 过时了 (RFC3494). 大部分所谓LDAPv2实现(including slapd(8))已经不符合LDAPv2技术规范了, 那些声称支持LDAPv2的实现之间的互操作性是有限的. 由于LDAPv2和LDAPv3显著的差异, 同时部署LDAPv2和LDAPv3是很成问题的. 应该避免使用LDAPv2. LDAPv2缺省是被禁用的.
这个问题被提到很多次，以不同的形式. 最常见的是: 为什么OpenLDAP不放弃 Berkeley DB 而使用一个关系型数据库管理系统(RDBMS)替代它? 通常, 我们可以预期商业级RDBMS的复杂算法将使 OpenLDAP 更快或者反正是更好, 同时允许其他应用程序分享其数据.
简单的答案是，使用嵌入式数据库和定制的索引系统允许OpenLDAP提供更高的性能和可扩展性而又不减少可靠性. OpenLDAP使用Berkeley DB并行/事务数据库软件. 业界领先的商业目录软件也使用同样的软件.
现在来详细回答一下. 任何时候我们总是面对 RDBMSes vs. directories的选择. 很难选择，并且不存在简单的答案.
给目录一个关系数据库管理系统的后端来解决所有问题，这个想法无疑是很诱人的. 无论如何, 它是一头猪(译者:呃，老外骂人了). 这是因为数据模型是非常不同的. 用关系型数据库去表现目录数据，将需要把数据分割到多个表里面.
考虑一下关于 person 这个 objectclass. 它的定义需要属性类型 objectclass, sn 和 cn，并且允许属性类型 userPassword, telephoneNumber, seeAlso 以及 description. 所有这些属性都是多值的, 所以一个常规的需求就会把每个属性类型放大一个单独的表里面.
现在你不得不决定这些表的适当的键. 主键可能是一个DN的组合, 但是这在绝大多数数据库实现中是非常低效的.
现在的大问题是根据一个条目请求去不同的磁盘区域访问数据. 在某些应用里面这个还可以做到，但是在很多应用里面性能就很困难.
唯一可以放到主表条目里面的属性类型是那些强制性的和单值的. 你也可以增加可选性的单值属性并把他们设为NULL或其他什么东西.
但是请等一下, 这个条目有多个 objectclasses并且他们组织成一个继承的层次. 一个 objectclass organizationalPerson 的条目现在有从 person 来的属性加上一些其他的以及一些原有的可选的属性类型现在变成强制性的了.
怎么办? 我们应该用不同的表放不同的objectclasses吗? 这样 person 将有一个条目在 person 表, 另一个在 organizationalPerson表, 以此类推. 或我们应该不管 person 而把每样东西放在第二个表?
但是对于类似(cn=*) 这样的过滤器，cn是一个在很多很多objectclasses里出现的属性类型，我们怎么办？ 我们应该为匹配那个过滤器搜索所有可能的表吗? 不是很有吸引力.
一旦达到这种程度, 三种办法浮现在脑海中。 一个是做全面正常化，以使每个属性类型，不管如何，都有自己单独的表。简单的方法DN作为主键的一部分是非常浪费的, 并且调用的是那个条目的唯一性的数字id而不是键，并且需要一个表来负责映射DN到id。这个方法, 无论如何, 当从一个或多个条目中请求很多属性类型的时候是非常低效的. 这样一个数据库, 尽管繁琐, 也可能由SQL应用程序管理.
第二个办法是把整个DN作为一个blob类型字段存在表里由所有条目共享，不管objectclass，并且额外的表作为第一个表的索引. 索引表不是数据库索引, 而是完全由LDAP服务端实现来管理. 无论如何, 无法利用SQL数据库了. 因此，一个完全成熟的数据库系统很少或根本没有优势. 全功能的通用数据库是不需要的. 更好的办法是使用一些轻型快速的, 如 Berkeley DB.
从一种完全不同的方式来看这件事，就是放弃任何实现目录数据模型的希望。在这种情况下, LDAP被用作一个对数据的访问协议，这些数据仅提供目录数据模型层面的数据. 例如，它可能是只读，或允许更新，适用限制，如单值属性类型允许多个值。或无法添加新的objectclasses到现有的条目或删除其中之一。限制范围的跨度从允许的限制（可能在其他地方造成的访问控制结果），到直接侵犯数据模型。无论如何,它是一个可行的办法,对之前就存在的用于其它应用程序的数据提供LDAP操作. 但是从概念上讲，我们并不真的拥有一个"目录".
现有的商业LDAP服务器采用关系数据库实现的，都是从第一种或第三种方法。我不知道任何使用关系数据库的实现如何低效地执行BDB做起来很高效的事情。 对那些对"第三种"方法感兴趣的人来说 (把现有的数据的数据库管理系统作为的LDAP树，比起典型的LDAP模式有一定的局限性，但有可能在LDAP和SQL应用之间实现互操作性):
OpenLDAP包含了 back-sql - 这个后端使得它(第三种方法)成为可能. 它使用 ODBC + 扩展来把LDAP查询翻译成你的RDBMS规划的SQL查询, 提供不同的级别的操作 - 从只读到全访问，取决于你使用的 RDBMS , 和你的规划.
更多关于概念和限制的信息, 见 slapd-sql(5) 手册页, 或 Backends 一节. 在 back-sql/rdbms_depend/* 子目录也有很多关于RDBMS的例子.
slapd(8) 是一个 LDAP 目录服务期，可以运行在各种不同的平台之上. 你可使用它提供一个你自己的目录服务. 你的目录可能包含非常多期望放进去的东西. 你可以把它连接到全球 LDAP 目录服务中, 或完全自己运行一个目录服务. 一些 slapd's 更有意思的功能和能力包括:
LDAPv3: slapd实现了轻量级目录访问协议的版本3. slapd支持 LDAP 运行于 IPv4 和 IPv6 以及 Unix IPC.
简单验证和安全层: slapd通过使用SASL支持强验证和数据安全(完整性和保密性) 服务. slapd的SASL实现利用了 Cyrus SASL 软件，它支持不少机制，包括 DIGEST-MD5, EXTERNAL, 和 GSSAPI.
传输层安全： slapd通过使用TLS的（或SSL ）支持基于证书的身份验证和数据安全（完整性和保密性）服务。slapd的TLS实现可以利用OpenSSL或GnuTLS软件。
拓扑控制： slapd可以被配置为根据网络的拓扑结构信息限制访问的套接字层。此功能利用了TCP包装。
访问控制： slapd提供了丰富和强大的访问控制设施，使您可以控制对你的数据库的信息的获取 。您可以基于LDAP授权信息， IP地址，域名和其他标准控制对条目的访问。slapd支持静态和动态的访问控制信息。slapd provides a rich and powerful access control facility,
国际化： slapd支持Unicode和语言标签。
可选的数据库后端： slapd配备了各种不同的数据库后端您可以从中选择。它们包括BDB，一个高性能的交易数据库后端;HDB，一个分级的高性能的交易后端;SHELL，一个后端接口通向任意 shell脚本;和PASSWD，一个简单的后端接口，到passwd （ 5 ）文件。BDB和HDB后端利用了Oracle Berkeley DB。
多数据库实例： slapd可以配置为在同一时间服务多个数据库。这意味着，一个单一的slapd服务器能够使用相同或不同的数据库后端，响应许多逻辑上不同的LDAP树的请求。
通用模块API ：如果您需要更加个性化， slapd让你轻松地写自己的模块。slapd包括两个不同的部分：处理和LDAP客户沟通协议的前端;和处理特定任务，如数据库操作的模块。因为这两个部分之间通过一个明确界定的C API通讯 ，你可以用多种方式写自己的定制模块扩展slapd。此外，提供了一些可编程数据库模块。这些允许你使用流行的编程语言（ Perl，shell和SQL ）暴露外部数据源给slapd 。
线程： slapd是线程高性能的。一个单一的多线程slapd进程使用线程池处理所有传入的请求。这减少了系统开销，同时提供所需的高性能。
复制： slapd可以被配置为维护目录信息的影子复制。这个单主/多从复制规划，对于安装单一的slapd而不提供必要的可用性和可靠性的高容量环境，是至关重要的。对于不能接受单点故障的要求极高的环境，也可以用多主复制。 slapd包含了对LDAP基于同步的复制的支持。
代理缓存： slapd可以被配置为一个缓存的LDAP代理服务。
配置： slapd是高度可配置的，通过一个单一的配置文件你可以改变一切,任何你想改变的东西。配置选项有合理的默认值，使您的工作更加容易。配置也可以使用LDAP本身动态的执行，这极大地改善了可管理性。
以下是一个OpenLDAP2.4的快速开始指南, 包含独立的LDAP守护进程, slapd(8).
这表示带你走过安装和配置OpenLDAP软件所需要的基本步骤. 应该结合其它文档一起来看，包括本文的其他章节,手册页面,以及其随同软件提供的材料(例如INSTALL文档)或OpenLDAP网站(
如果你打算严肃使用OpenLDAP软件, 你应该在尝试安装软件之前阅读本文的全文.
注意: 这个快速开始指南没有使用强验证或任何保密服务. 这些服务在本OpenLDAP管理员指南的其它章节里有所描述.
1. 获得软件
你可以跟着OpenLDAP软件下载页面 () 的提示获得一份软件拷贝. 建议新用户使用最新版本.
2. 解包分发版
给源码选择一个目录, 进入到那个目录, 使用以下命令解包分发版:
gunzip -c openldap-VERSION.tgz | tar xvfB -
然后进入分发版的目录:
cd openldap-VERSION
你要把VERSION换成相应的版本名.
3. 阅读文档
你现在应该阅读分发版所提供的COPYRIGHT, LICENSE, README 和 INSTALL 文档. COPYRIGHT 和 LICENSE 提供的信息是关于可接受的使用,拷贝方式和OpenLDAP软件的有限保证.
你也应该阅读本文的其他章节. 特别是, 本文的编译和安装OpenLDAP软件章节提供了依赖的软件的详细信息和安装过程.
4. 运行configure
你将需要运行提供的configure脚本来配置分发版使它能在你的系统上进行编译. configure脚本接受很多命令行选项以打开或关闭可选的软件功能. 通常缺省就差不多了, 但是你可以改变它们. 要获得configure可接受的选项的完整列表, 使用 --help 选项:
./configure --help
无论如何, 是你在使用这个指南, 我们假定你足够勇敢,就让configure决定什么是最好的:
./configure
假定configure不喜欢你的系统, 你可以继续编译软件. 如果configure抱怨, 那么, 你可能需要去看看软件常见问题解答的安装一节 () 和/或仔细阅读本文的编译和安装OpenLDAP软件一章.
5. Build软件.
下一步是编译软件. 这一步分为两部分, 首先我们构建依赖，然后我们编译软件:
make depend
两个 makes 都应该不出错地完成.
6. 测试build.
为了确保正确的编译, 你应该运行测试套件(只要花几分钟):
应用你的配置的测试将运行并应该通过. 一些测试, 例如复制测试, 可以忽略.
7. 安装软件.
你现在准备安装软件; 这通常需要超级用户权限:
su root -c 'make install'
现在每样东西应该都被安装在 /usr/local 目录下(或任何configure指定的安装前缀).
8. 编辑配置文件.
使用你偏爱的编辑器编辑附带的slapd.conf(5)例子(通常安装在 /usr/local/etc/openldap/slapd.conf) 来包含一个如下格式的 BDB 数据库定义:
database bdb
suffix &dc=&MY-DOMAIN&,dc=&COM&&
rootdn &cn=Manager,dc=&MY-DOMAIN&,dc=&COM&&
rootpw secret
directory /usr/local/var/openldap-data
确保以你的域名的适当部分替换&MY-DOMAIN&和&COM& . 例如, 对于 example.com, 使用:
database bdb
suffix &dc=example,dc=com&
rootdn &cn=Manager,dc=example,dc=com&
rootpw secret
directory /usr/local/var/openldap-data
如果你的域包含额外的部分, 例如 eng.uni.edu.eu, 使用:
database bdb
suffix &dc=eng,dc=uni,dc=edu,dc=eu&
rootdn &cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu&
rootpw secret
directory /usr/local/var/openldap-data
关于配置slapd(8)的细节,可在slapd.conf(5) 手册页，以及本文的 slapd 配置文件 一章找到. 注意启动slapd(8)之前那些定义的目录必须实际存在.
9. 启动SLAPD.
现在你准备启动独立的LDAP守护进程, slapd(8), 运行这个命令:
su root -c /usr/local/libexec/slapd
为了检查服务器是否运行以及是否被正确地配置好, 你可以使用ldapsearch(1)针对它运行一个搜索. 缺省的, ldapsearch被安装在 /usr/local/bin/ldapsearch:
ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
注意在命令参数周围使用单引号来避免shell被特殊字符中断. 它应该返回:
namingContexts: dc=example,dc=com
关于运行slapd(8)的细节可以在slapd(8)手册页以及本文的 运行slapd 一章找到.
10. 添加初始条目到目录中去.
你可以使用ldapadd(1)添加条目到你的LDAP目录. ldapadd期待的输入是LDIF格式. 我们将分两步走:
建立LDIF文件
运行ldapadd
使用你偏爱的编辑器新建一个LDIF文件，包含如下内容:
dn: dc=&MY-DOMAIN&,dc=&COM&
objectclass: dcObject
objectclass: organization
o: &MY ORGANIZATION&
dc: &MY-DOMAIN&
dn: cn=Manager,dc=&MY-DOMAIN&,dc=&COM&
objectclass: organizationalRole
cn: Manager
确保使用你的域名的适当部分替换&MY-DOMAIN&和&COM&. &MY ORGANIZATION&应该被你的机构名称替换掉. 当你剪切粘贴时, 确定本例中的每一行的前面和后面都没有空格.
dn: dc=example,dc=com
objectclass: dcObject
objectclass: organization
o: Example Company
dc: example
dn: cn=Manager,dc=example,dc=com
objectclass: organizationalRole
cn: Manager
现在, 你可以运行ldapadd(1)来添加这些条目到你的目录.
ldapadd -x -D &cn=Manager,dc=&MY-DOMAIN&,dc=&COM&& -W -f example.ldif
确保用你的域名的适当部分替换&MY-DOMAIN&和&COM&. 你将收到提示输入密码，也就是在slapd.conf中定义的"secret". 例如, 对于 example.com, 使用:
ldapadd -x -D &cn=Manager,dc=example,dc=com& -W -f example.ldif
这里example.ldif就是你上面新建的文件.
另外关于建立目录的信息可以在本文的 数据库建立和维护工具 一章找到.
11. 看它是否起作用.
现在我们准备检验目录中添加的条目. 你可使用任何LDAP客户端来做这件事, 但我们的例子使用ldapsearch(1)工具. 记住把 dc=example,dc=com 替换成你的网站的正确的值:
ldapsearch -x -b 'dc=example,dc=com' '(objectclass=*)'
本命令将搜索和接收这个数据库中的每一个条目.
现在你准备使用ldapadd(1)或其它LDAP客户端添加更多的条目, 试验更多的配置选项, 后端安排, 等等.
注意缺省的情况下, slapd(8)数据库赋予阅读权限给每个人,除了超级用户(即配置文件中的rootdn参数). 强烈建议你建立控制来限制授权用户的操作. 操作权限控制在 访问控制 章讨论. 也鼓励你阅读安全事项，使用SASL和使用TLS章节.
接下来的章节提供更多编译,安装和运行slapd(8)的详细信息.
本节概述了各种LDAP目录配置，以及如何使您的独立的LDAP守护进程slapd （ 8 ）适合世界其他国家。
在这种配置中，您运行slapd （ 8 ）实例，只为您的本地网域提供目录服务。它不以任何方式与其他目录服务器交互。这种配置如图3.1.
图 3.1: 本地服务配置.
如果您刚刚起步（快速启动指南的目的之一就是为了你这种人），或者如果你想提供本地服务且对连接到世界其他地区不感兴趣,请使用此配置。如果以后你想的话,这也很容易升级到另一个配置。
在这种配置中，您运行slapd （ 8 ）实例，为您的本地网域提供目录服务，并配置它返回转发到其他能够处理请求的服务器。您可以自己运行此服务（或多个服务）或使用别人提供给您的服务。这种配置如图3.2.
图 3.2: 带转发的本地服务
如果你想提供本地服务，并参与全球目录，或者您想代表负责下属条目到另一台服务器,使用此配置。
slapd （ 8 ）包括了对LDAP基于同步的复制的支持, 即所谓syncrepl ，可用于在多个目录服务器上维持目录信息的影子复制。在其最基本的配置，主服务器是一个syncrepl供应商，而一个或多个从服务器（或影子服务器）是syncrepl消费者。一个主从配置的例子如图3.3. 多主机的配置，也支持。
图 3.3: 可复制的目录服务
此配置可用于头两个配置的任何一个情况下，例如一个单一的slapd （ 8 ）没有提供所需的可靠性和可用性。
在这种配置中，当地的服务被分割成较小的服务，每个都是可复制的，和上下级粘在一起转发。
这一章详细说明如何编译和安装包含了slapd （ 8 ） ，独立的LDAP守护进程的OpenLDAP软件包。编译和安装OpenLDAP软件需要几个步骤：安装依赖的软件，配置OpenLDAP软件本身，编译，并最终安装。以下各节详细描述了此过程中。
您可以从该项目的下载页面上 。
该项目提供两个系列的包作为一般用途。该项目发布版本提供新的特性和错误修正。虽然该项目采取措施，以改善这些版本的稳定性，但是经常会版本发布之后才发现问题。稳定版本是最新的经过一般性的使用已经显示出稳定的版本。
OpenLDAP软件的用户可以选择最适当的一系列安装，这取决于他们对于最新功能与稳定表现的期望。
OpenLDAP软件下载后，你需要从压缩存档文件提取发布版并更改您的工作目录到发布版的根目录：
gunzip -c openldap-VERSION.tgz | tar xf -
cd openldap-VERSION
你需要把 VERSION 换成发布版的实际版本号.
您现在应该阅读版权，许可证，自述文件和发布版提供的安装文件规定。版权和许可提供对OpenLDAP软件的可接受的使用，复制，和限制的保证。自述文件和安装文件提供依赖的软件和安装过程的详细资料。
OpenLDAP软件依靠一些第三方分发的软件包。根据您打算使用的不同的功能，您可能必须下载并安装一些额外的软件包。本节详述通常需要的您可能需要安装的第三方软件的软件包。然而，一个最新的依赖软件信息，应在自述文件中获得。请注意，其中一些第三方软件包可能依赖于额外的软件包。每个软件包提供了它自己的安装说明。
OpenLDAP客户端和服务器需要安装OpenSSL或GnuTLS的TLS库来提供TLS，传输层安全服务。虽然一些操作系统可能提供这些库的一部分，作为基本系统或一个可选的软件组件， OpenSSL和GnuTLS往往需要单独安装。
OpenSSL可从
获得. GnuTLS 可从
OpenLDAP 软件将不是完全兼容 LDAPv3,除非 OpenLDAP 的配置检测到一个可用的 TLS 库.
OpenLDAP客户端和服务器需要安装 Cyrus SASL 库提供简单身份认证和安全层服务。虽然一些操作系统可能会提供这个库，作为基本系统的一部分或作为一个可选的软件组件，Cyrus SASL 往往需要单独安装。
Cyrus SASL 可从
获得. Cyrus SASL 将使用 OpenSSL 和 Kerberos/GSSAPI 库，如果预先安装了的话.
OpenLDAP软件将不完全兼容 LDAPv3，除非 OpenLDAP 的配置检测到一个可用的 Cyrus SASL 安装.
OpenLDAP客户端和服务器支持Kerberos身份验证服务。特别是， OpenLDAP支持 Kerberos V GSS-API SASL 认证机制，称为GSSAPI机制。此功能要求，除了Cyrus SASL 库之外，还要有 Heimdal 或 MIT Kerberos V 库。
Heimdal Kerberos 可从
获得. MIT Kerberos 可从
强烈推荐使用强验证服务, 例如 Kerberos 提供的那些.
OpenLDAP的slapd （ 8 ）的BDB和HDB主要数据库后端需要甲骨文公司的Berkeley DB。如果在设定的时间没有可用的，您将无法与这些主要的数据库后端编译slapd （ 8 ）。
您的操作系统可能提供一个支持版本的Berkeley DB作为基础系统或作为一个可选的软件组件。如果不是这样，您将不得不自己去获取并安装它。
Berkeley DB 可从 Oracle 公司的 Berkeley DB 下载页
有很多可用的版本. 通常, 推荐最近的版本 (包含发布的补丁) . 如果你想使用BDB或HDB数据库后端，这个包是必需的.
注意: 请看推荐的 OpenLDAP 软件依赖版本 一节获得更多信息.
OpenLDAP设计成充分利用线程。 OpenLDAP支持POSIX pthreads，Mach CThreads ，以及其他一些品种。如果不能找到一个合适的线程子系统,configure会抱怨。如果发生这种情况，请咨询OpenLDAP常见问题
中的 软件|安装|平台 提示部分 。
slapd(8) 支持 TCP 包装 (IP 级访问控制过滤), 如果预先安装了的话. 建议为包含非公开信息的服务器使用 TCP 包装或其他 IP级的访问过滤 (例如那些IP级防火墙所提供的).
现在，您或许应该运行configure脚本的 --help 选项。这将给你一个选项列表，编译OpenLDAP时您可以变更这些选项 。使用此方法可以启用或禁用OpenLDAP的许多功能。
./configure --help
configure脚本还将研究各种环境变量的某些设置。这些环境变量包括：
表 4.1: 环境标量
指定替代的 C 编译器
指定额外的编译器 flags
指定 C 预编译器 flags
指定 linker flags
指定额外的库
现在以任何期望的配置选项或环境变量运行configure脚本.
[[env] settings] ./configure [options]
作为一个例子，假设我们要安装OpenLDAP,后端是BDB并支持TCP封装。默认情况下，BDB是启用的而TCP封装并非如此。所以，我们只需要指定 --with-wrappers， 来包含对TCP封装的支持：
./configure --with-wrappers
无论如何，这无法定位没有安装到系统目录的依赖的软件. 例如, 如果 TCP Wrappers 头文件和库文件分别被安装在 /usr/local/include 和 /usr/local/lib, configure 脚本应该如下调用:
env CPPFLAGS=&-I/usr/local/include& LDFLAGS=&-L/usr/local/lib& \
./configure --with-wrappers
注意: 一些 shells, 例如那些衍生自Bourne sh(1)的 shell, 不需要使用 env(1) 命令. 在某些情况下, 环境变量不得不使用替代的语法来指定.
configure脚本通常将自动检测适当的设定. 如果你对此阶段有任何问题, 咨询任何平台特定的提示并检查你的configure选项, 如果有的话.
一旦你运行了 configure 脚本,输出的最后一行应该是:
Please &make depend& to build dependencies
如果最后一行输出不符, configure失败了, 你需要阅读它的输出来决定什么地方出错了. 你不应继续下去,直到configure成功的完成.
编译依赖, 运行:
make depend
现在编译软件, 这一步将确实地编译OpenLDAP.
你应该仔细检查这个命令的输出信息以确认每件东西正确地被编译了. 注意这个命令同时编译了 LDAP 库文件和相关的客户端以及 slapd(8).
一旦软件被正确地配置和成功地编译了, 你应该运行测试套件来检查这个版本.
适用于您的配置地试验将运行，它们应该通过。一些测试，如复制测试，可以跳过，如果您的配置不支持的话。
一旦你成功地测试了软件, 你开始准备安装它. 你将需要在运行configure时你指定的那些安装目录的写权限. 缺省OpenLDAP软件安装在/usr/local. 如果你用 --prefix configure 选项改变了设置 , 它将被安装在你提出的位置.
典型的, 安装需要超级用户权限. 从OpenLDAP源码根目录, 键入:
su root -c 'make install'
需要的时候输入适当的密码.
你应该仔细检查此命令的输出以确保每件东西正确地安装了. 缺省你将在 /usr/local/etc/openldap 发现slapd(8)的配置文件. 更多信息见 配置 slapd 一章.
一旦该软件已编译并安装后，您准备配置slapd （ 8 ） ，用于您的网站。与以前OpenLDAP的版本不同，slapd （ 8 ）运行时配置在2.3 （及更高版本）是完全的允许LDAP并且可以LDIF数据使用标准的LDAP操作来管理 。LDAP配置引擎允许所有slapd的配置选项在运行中改变，一般不需要重新启动服务器以使更改生效。旧风格slapd.conf （ 5 ）文件仍然是支持的，但必须转换为新的slapd配置（ 5 ）格式，允许运行时改变被保存。虽然旧的风格配置使用一个单一的文件，通常安装在/usr/local/etc/openldap/slapd.conf ，新的风格采用了slapd后端数据库来存储配置。配置数据库通常放在/usr/local/etc/openldap/slapd.d目录。从slapd.conf格式转换成slapd.d格式时，任何包含文件也将被集成到由此产生的配置数据库。
可以通过slapd （ 8 ）的命令行选项指定候补的配置目录（或文件） 。本章说明配置系统的一般格式，然后详细说明了常用的配置设置。
注：一些后端和分布式覆盖还不支持运行时配置。在这种情况下，旧式slapd.conf （ 5 ）文件必须使用。
slapd配置作为一个特殊的拥有预定义的规划和DIT的LDAP目录来存储。有一些特定的objectClasses用于进行全球配置选项，架构定义，后端和数据库的定义，以及各种其他项目。样本配置树如图5.1.
图 5.1: 样本配置树.
其他对象可能是配置的一部分，但省略了明确的说明.
该slapd配置配置树有一个非常特殊的结构。树的根被命名为 cn=config，并且包含全球配置设置。其他设置均包含在独立的子条目中：:
动态装载模块
这些可能只在使用了 --enable-modules 选项 configure 软件的时候需要用.
cn=schema,cn=config 条目包含了系统的规划(在slapd中所有规划都是硬编码).
cn=schema,cn=config 的子条目包含从配置文件装载或运行时添加的的用户规划.
特定后端配置
特定数据库配置
Overlay被定义在数据库条目的子条目下.
数据库和Overlay也可以有其他的杂项子条目.
LDIF文件的通常规则适用于配置信息：以'＃'字符开始的注释行会被忽略。如果一行的开始是一个空格，它被认为是延续前行（即使前行是注释）并且这个单个的空格会被删除。条目是由空白行分开的。
config LDIF的总体布局如下：
# 全球配置设定
dn: cn=config
objectClass: olcGlobal
cn: config
&global config settings&
# 规划定义
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
&system schema&
dn: cn={X}core,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {X}core
&core schema&
# 额外的用户定义的规划
# 后端定义
dn: olcBackend=&typeA&,cn=config
objectClass: olcBackendConfig
olcBackend: &typeA&
&backend-specific settings&
# 数据库定义
dn: olcDatabase={X}&typeA&,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {X}&typeA&
&database-specific settings&
# 随后的定义和设置
一些以上所列项目在他们的名字有一个数字索引"{X}"。虽然大多数配置设置具有内在的次序依赖（即一个设置必须在另一个设定之前生效），LDAP数据库本身是无次序的。这个数字索引是用来在配置数据库强制一致性的次序，以便使所有的次序依赖被保存。在大多数情况下，并没有提供索引，它将根据条目创建的顺序自动生成。
配置指令被定义为一个独立属性的值。大部分用于slapd配置的属性和objectClasses在他们的名字有一个“olc”前缀 （ OpenLDAP配置）。通常在属性和旧式slapd.conf配置关键字之间有一对一的对应关系，使用关键字作为属性名称，以“olc”作前缀。
一个配置指令可采用参数。如果是这样，参数们由空格分开。如果参数包含空格，这个参数应包含在双引号里“像这样” 。在以下描述中，在方括号&&中的参数应被实际的文字替换 。
发布版包含一个配置文件例子，将被安装在/usr/local/etc/OpenLDAP目录。在/usr/local/etc/openldap/schema目录还提供了一些包含架构定义（属性类型和对象类）的文件。
本节详述常用的配置指令。如需完整清单，请参阅slapd-config（ 5 ）帮助页面。本节将按自上而下的顺序排列配置指令，首先是全球性指令的 cn=config 项。每个指令将描述其默认值（如果有的话）和它的一个使用例子。
此项目中所载的指令一般适用于把服务器作为一个整体。他们中的大多数是系统或面向连接的，而不是数据库相关的。此项目必须有olcGlobal对象。
指定强行关闭闲置客户端连接等待的秒数。默认情况下，值为0，禁用此功能。
该指令规定在哪一级的调试和运行统计报表应syslogged （目前记录到syslogd （ 8 ） LOG_LOCAL4设施）。您必须配置OpenLDAP -enable-debug（默认）为工作（除了这两个统计级别，是始终启用的）。日志级别可能会被指定为整数或关键字。可使用多重记录级别并且级别是可添加的。要显示哪些层次对应于什么样的调试，以 -D? 调用 slapd 或参考下表。&level&可能的值有：
表 5.1: 调试级别
(0x1 trace)
跟踪函数调用
(0x2 packets)
调试包的处理
(0x4 args)
重度跟踪调试
(0x8 conns)
(0x10 BER)
打印发送和接收的包
(0x20 filter)
搜索过滤器的处理
(0x40 config)
(0x80 ACL)
访问控制列表处理
(0x100 stats)
连接/操作/结果的统计日志
(0x200 stats2)
发送的条目的统计日志
(0x400 shell)
打印和shell后端的通信
(0x800 parse)
打印条目解析调试
(0x4000 sync)
syncrepl消费者处理
(0x8000 none)
只显示那些不受日志级别设置影响的消息
预期的日志级别可作为一个单一的整数输入，它结合了 (或运算) 预期级别(们), 包括十进制或十六进制符号, 作为一些整数的列表 (内部或运算), 或作为名字的列表，展示在括号里, 例如
olcLogLevel 129
olcLogLevel 0x81
olcLogLevel 128 1
olcLogLevel 0x80 0x1
olcLogLevel acl trace
olcLogLevel -1
This will cause lots and lots of debugging information to be logged.
olcLogLevel conns filter
Just log the connection and search filter processing.
olcLogLevel none
Log those messages that are logged regardless of the configured loglevel. This differs from setting the log level to 0, when no logging occurs. At least the None level is required to have high priority messages logged.
olcLogLevel stats
Basic stats logging is configured by default. However, if no olcLogLevel is defined, no logging occurs (equivalent to a 0 level).
This directive specifies the referral to pass back when slapd cannot find a local database to handle a request.
olcReferral: ldap://root.openldap.org
This will refer non-local queries to the global root LDAP server at the OpenLDAP Project. Smart LDAP clients can re-ask their query at that server, but note that most of these clients are only going to know how to handle simple LDAP URLs that contain a host part and optionally a distinguished name part.
dn: cn=config
objectClass: olcGlobal
cn: config
olcIdleTimeout: 30
olcLogLevel: Stats
olcReferral: ldap://root.openldap.org
If support for dynamically loaded modules was enabled when configuring slapd, cn=module entries may be used to specify sets of modules to load. Module entries must have the olcModuleList objectClass.
Specify the name of a dynamically loadable module to load. The filename may be an absolute path name or a simple filename. Non-absolute names are searched for in the directories specified by the olcModulePath directive.
Specify a list of directories to search for loadable modules. Typically the path is colon-separated but this depends on the operating system.
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: /usr/local/lib/smbk5pwd.la
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/local/lib:/usr/local/lib/slapd
olcModuleLoad: accesslog.la
olcModuleLoad: pcache.la
The cn=schema entry holds all of the schema definitions that are hard-coded in slapd. As such, the values in this entry are generated by slapd so no schema values need to be provided in the config file. The entry must still be defined though, to serve as a base for the user-defined schema to add in underneath. Schema entries must have the olcSchemaConfig objectClass.
This directive defines an attribute type. Please see the Schema Specification chapter for information regarding how to use this directive.
This directive defines an object class. Please see the Schema Specification chapter for information regarding how to use this directive.
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
dn: cn=test,cn=schema,cn=config
objectClass: olcSchemaConfig
olcAttributeTypes: ( 1.1.1
NAME 'testAttr'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1..1.27 )
olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1..1.44 )
olcObjectClasses: ( 1.1.3 NAME 'testObject'
MAY ( testAttr $ testTwo ) AUXILIARY )
Backend directives apply to all database instances of the same type and, depending on the directive, may be overridden by database directives. Backend entries must have the olcBackendConfig objectClass.
This directive names a backend-specific configuration entry. &type& should be one of the supported backend types listed in Table 5.2.
Table 5.2: Database Backends Types
Description
Berkeley DB transactional backend
Slapd configuration backend
DNS SRV backend
Hierarchical variant of bdb backend
Lightweight Directory Access Protocol (Proxy) backend
Lightweight Data Interchange Format backend
Meta Directory backend
Monitor backend
Provides read-only access to passwd(5)
Perl Programmable backend
Shell (extern program) backend
SQL Programmable backend
olcBackend: bdb
There are no other directives defined for this entry. Specific backend types may define additional attributes for their particular use but so far none have ever been defined. As such, these directives usually do not appear in any actual configurations.
dn: olcBackend=bdb,cn=config
objectClass: olcBackendConfig
olcBackend: bdb
Directives in this section are supported by every type of database. Database entries must have the olcDatabaseConfig objectClass.
This directive names a specific database instance. The numeric {&index&} may be provided to distinguish multiple databases of the same type. Usually the index can be omitted, and slapd will generate it automatically. &type& should be one of the supported backend types listed in Table 5.2 or the frontend type.
The frontend is a special database that is used to hold database-level options that should be applied to all the other databases. Subsequent database definitions may also override some frontend settings.
The config data both the config and the frontend databases are always created implicitly even if they are not explicitly configured, and they are created before any other databases.
olcDatabase: bdb
This marks the beginning of a new BDB database instance.
This directive grants access (specified by &accesslevel&) to a set of entries and/or attributes (specified by &what&) by one or more requestors (specified by &who&). See the Access Control section of this guide for basic usage.
Note: If no olcAccess directives are specified, the default access control policy, to * by * read, allows all users (both authenticated and anonymous) read access.
Note: Access controls defined in the frontend are appended to all other databases' controls.
This directive puts the database into "read-only" mode. Any attempts to modify the database will return an "unwilling to perform" error.
olcReadonly: FALSE
This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database. The DN need not refer to an entry in this database or even in the directory. The DN may refer to a SASL identity.
Entry-based Example:
olcRootDN: "cn=Manager,dc=example,dc=com"
SASL-based Example:
olcRootDN: "uid=root,cn=example.com,cn=digest-md5,cn=auth"
See the SASL Authentication section for information on SASL authentication identities.
This directive can be used to specify a password for the DN for the rootdn (when the rootdn is set to a DN within the database).
olcRootPW: secret
It is also permissible to provide a hash of the password in RFC2307 form. slappasswd(8) may be used to generate the password hash.
olcRootPW: {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
The hash was generated using the command slappasswd -s secret.
This directive specifies the maximum number of entries to return from a search operation.
olcSizeLimit: 500
See the Limits section of this guide and slapd-config(5) for more details.
This directive specifies the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given, and usually at least one is required for each database definition. (Some backend types, such as frontend and monitor use a hard-coded suffix which may not be overridden in the configuration.)
olcSuffix: "dc=example,dc=com"
Queries with a DN ending in "dc=example,dc=com" will be passed to this backend.
Note: When the backend to pass a query to is selected, slapd looks at the suffix value(s) in each database definition in the order in which they were configured. Thus, if one database suffix is a prefix of another, it must appear after it in the configuration.
olcSyncrepl: rid=&replica ID&
provider=ldap[s]://&hostname&[:port]
[type=refreshOnly|refreshAndPersist]
[interval=dd:hh:mm:ss]
[retry=[&retry interval& &# of retries&]+]
searchbase=&base DN&
[filter=&filter str&]
[scope=sub|one|base]
[attrs=&attr list&]
[attrsonly]
[sizelimit=&limit&]
[timelimit=&limit&]
[schemachecking=on|off]
[bindmethod=simple|sasl]
[binddn=&DN&]
[saslmech=&mech&]
[authcid=&identity&]
[authzid=&identity&]
[credentials=&passwd&]
[realm=&realm&]
[secprops=&properties&]
[starttls=yes|critical]
[tls_cert=&file&]
[tls_key=&file&]
[tls_cacert=&file&]
[tls_cacertdir=&path&]
[tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=&ciphers&]
[tls_crlcheck=none|peer|all]
[logbase=&base DN&]
[logfilter=&filter str&]
[syncdata=default|accesslog|changelog]
这个指令定义当前数据库作为一个主服务器内容的复制，通过当前的slapd(8) 建立一个运行syncrepl复制引擎的复制消费者站点. 主数据库由provider参数定位于复制提供者站点. 复制数据库使用LDAP内容同步协议保持对主服务器内容的更新. 关于协议的更多信息参见 RFC4533.
The rid parameter is used for identification of the current syncrepl directive within the replication consumer server, where &replica ID& uniquely identifies the syncrepl specification described by the current syncrepl directive. &replica ID& is non-negative and is no more than three decimal digits in length.
The provider parameter specifies the replication provider site containing the master content as an LDAP URI. The provider parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. Either a domain name or IP address may be used for &hostname&. Examples are ldap://provider.example.com:389 or ldaps://192.168.1.1:636. If &port& is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located at the consumer site, whereas the replica specification is located at the provider site. syncrepl and replica directives define two independent replication mechanisms. They do not represent the replication peers of each other.
The content of the syncrepl replica is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search specification. The search specification includes searchbase, scope, filter, attrs, attrsonly, sizelimit, and timelimit parameters as in the normal search specification. The searchbase parameter has no default value and must always be specified. The scope defaults to sub, the filter defaults to (objectclass=*), attrs defaults to "*,+" to replicate all user and operational attributes, and attrsonly is unset by default. Both sizelimit and timelimit default to "unlimited", and only positive integers or "unlimited" may be specified.
The LDAP Content Synchronization protocol has two operation types: refreshOnly and refreshAndPersist. The operation type is specified by the type parameter. In the refreshOnly operation, the next synchronization search operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the interval parameter. It is set to one day by default. In the refreshAndPersist operation, a synchronization search remains persistent in the provider slapd instance. Further updates to the master replica will generate searchResultEntry to the consumer slapd as the search responses to the persistent synchronization search.
If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the &retry interval& and &# of retries& pairs. For example, retry="60 10 300 3" lets the consumer retry every 60 seconds for the first 10 times and then retry every 300 seconds for the next three times before stop retrying. + in &# of retries& means indefinite number of retries until success.
The schema checking can be enforced at the LDAP Sync consumer site by turning on the schemachecking parameter. If it is turned on, every replicated entry will be checked for its schema as the entry is stored into the replica content. Every entry in the replica should contain those attributes required by the schema definition. If it is turned off, entries will be stored without checking schema conformance. The default is off.
The binddn parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the master database.
The bindmethod is simple or sasl, depending on whether simple password-based authentication or SASL authentication is to be used when connecting to the provider slapd instance.
Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPsec). Simple authentication requires specification of binddn and credentials parameters.
SASL authentication is generally recommended. SASL authentication requires specification of a mechanism using the saslmech parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials, respectively. The authzid parameter may be used to specify an authorization identity.
The realm parameter specifies a realm which a certain mechanisms authenticate the identity within. The secprops parameter specifies Cyrus SASL security properties.
The starttls parameter specifies use of the StartTLS extended operation to establish a TLS session before authenticating to the provider. If the critical argument is supplied, the session will be aborted if the StartTLS request fails. Otherwise the syncrepl session continues without TLS. Note that the main slapd TLS settings are not used by by default the TLS parameters from a ldap.conf(5) configuration file will be used. TLS settings may be specified here, in which case any ldap.conf(5) settings will be completely ignored.
Rather than replicating whole entries, the consumer can query logs of data modifications. This mode of operation is referred to as delta syncrepl. In addition to the above parameters, the logbase and logfilter parameters must be set appropriately for the log that will be used. The syncdata parameter must be set to either "accesslog" if the log conforms to the slapo-accesslog(5) log format, or "changelog" if the log conforms to the obsolete changelog format. If the syncdata parameter is omitted or set to "default" then the log parameters are ignored.
The syncrepl replication mechanism is supported by the bdb and hdb backends.
See the LDAP Sync Replication chapter of this guide for more information on how to use this directive.
This directive specifies the maximum number of seconds (in real time) slapd will spend answering a search request. If a request is not finished in this time, a result indicating an exceeded timelimit will be returned.
olcTimeLimit: 3600
See the Limits section of this guide and slapd-config(5) for more details.
This directive is only applicable in a slave slapd. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each URL is provided.
olcUpdateref:
ldap://master.example.net
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
olcReadOnly: FALSE
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootDN: cn=Manager,dc=example,dc=com
Directives in this category apply to both the BDB and the HDB database. They are used in an olcDatabase entry in addition to the generic database directives defined above. For a complete reference of BDB/HDB configuration directives, see slapd-bdb(5). In addition to the olcDatabaseConfig objectClass, BDB and HDB database entries must have the olcBdbConfig and olcHdbConfig objectClass, respectively.
This directive specifies the directory where the BDB files containing the database and associated indices live.
olcDbDirectory: /usr/local/var/openldap-data
This directive specifies the size in entries of the in-memory cache maintained by the BDB backend database instance.
olcDbCachesize: 1000
This directive specifies how often to checkpoint the BDB 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.
olcDbCheckpoint: 1024 10
This attribute specifies a configuration directive to be placed in the DB_CONFIG file of the database directory. At server startup time, if no such file exists yet, the DB_CONFIG file will be created and the settings in this attribute will be written to it. If the file exists, its contents will be read and displayed in this attribute. The attribute is multi-valued, to accommodate multiple configuration directives. No default is provided, but it is essential to use proper settings here to get the best server performance.
Any changes made to this attribute will be written to the DB_CONFIG file and will cause the database environment to be reset so the changes can take immediate effect. If the environment cache is large and has not been recently checkpointed, this reset operation may take a long time. It may be advisable to manually perform a single checkpoint using the Berkeley DB db_checkpoint utility before using LDAP Modify to change this attribute.
olcDbConfig: set_cachesize 0
olcDbConfig: set_lg_bsize 2097512
olcDbConfig: set_lg_dir /var/tmp/bdb-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
In this example, the BDB cache is set to 10MB, the BDB transaction log buffer size is set to 2MB, and the transaction log files are to be stored in the /var/tmp/bdb-log directory. Also a flag is set to tell BDB to delete transaction log files as soon as their contents have been checkpointed and they are no longer needed. Without this setting the transaction log files will continue to accumulate until some other cleanup procedure removes them. See the Berkeley DB documentation for the db_archive command for details. For a complete list of Berkeley DB flags please see -
Ideally the BDB cache must be at least as large as the working set of the database, the log buffer size should be large enough to accommodate most transactions without overflowing, and the log directory must be on a separate physical disk from the main database files. And both the database directory and the log directory should be separate from disks used for regular system activities such as the root, boot, or swap filesystems. See the FAQ-o-Matic and the Berkeley DB documentation for more details.
This option causes on-disk database contents to not be immediately synchronized with in memory changes upon change. Setting this option to TRUE may improve performance at the expense of data integrity. This directive has the same effect as using
olcDbConfig: set_flags DB_TXN_NOSYNC
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. The optimal size will depend on the data and search characteristics of the database, but using a number three times the entry cache size is a good starting point.
olcDbIDLcacheSize: 3000
This directive specifies the indices to maintain for the given attribute. If only an &attrlist& is given, the default indices are maintained. The index keywords correspond to the common types of matches that may be used in an LDAP search filter.
olcDbIndex: default pres,eq
olcDbIndex: uid
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass eq
The first line sets the default set of indices to maintain to present and equality. The second line causes the default (pres,eq) set of indices to be maintained for the uid attribute type. The third line causes present, equality, and substring indices to be maintained for cn and sn attribute types. The fourth line causes an equality index for the objectClass attribute type.
There is no index keyword for inequality matches. Generally these matches do not use an index. However, some attributes do support indexing for inequality matches, based on the equality index.
A substring index can be more explicitly specified as subinitial, subany, or subfinal, corresponding to the three possible components of a substring match filter. A subinitial index only indexes substrings that appear at the beginning of an attribute value. A subfinal index only indexes substrings that appear at the end of an attribute value, while subany indexes substrings that occur anywhere in a value.
Note that by default, setting an index for an attribute also affects every subtype of that attribute. E.g., setting an equality index on the name attribute causes cn, sn, and every other attribute that inherits from name to be indexed.
By default, no indices are maintained. It is generally advised that minimally an equality index upon objectClass be maintained.
olcDbindex: objectClass eq
Additional indices should be configured corresponding to the most common searches that are used on the database. Presence indexing should not be configured for an attribute unless the attribute occurs very rarely in the database, and presence searches on the attribute occur very frequently during normal use of the directory. Most applications don't use presence searches, so usually presence indexing is not very useful.
If this setting is changed while slapd is running, an internal task will be run to generate the changed index data. All server operations can continue as normal while the indexer does its work. If slapd is stopped before the index task completes, indexing will have to be manually completed using the slapindex tool.
If this setting is TRUE slapindex will index one attribute at a time. The default settings is FALSE in which case all indexed attributes of an entry are processed at the same time. When enabled, each indexed attribute is processed individually, using multiple passes through the entire database. This option improves slapindex performance when the database size exceeds the BDB cache size. When the BDB cache 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.
This directive specifies the file protection mode that newly created database index files should have. This can be in the form 0600 or -rw-------
olcDbMode: 0600
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 allocated for 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 separate 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 uses 512K bytes per level on a 32-bit machine, or 1024K bytes per level on a 64-bit machine. The default stack depth is 16, thus 8MB or 16MB per thread is used on 32 and 64 bit machines, respectively. Also the 512KB size of a single stack slot is set by a compile-time constant which may
the code must be recompiled for the change to take effect.
olcDbSearchStack: 16
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.
olcDbShmKey: 42
dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: hdb
olcSuffix: &dc=example,dc=com&
olcDbDirectory: /usr/local/var/openldap-data
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 10
olcDbConfig: set_cachesize 0
olcDbConfig: set_lg_bsize 2097152
olcDbConfig: set_lg_dir /var/tmp/bdb-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 3000
olcDbIndex: objectClass eq
为了提供一个有弹性的企业部署，复制目录是一个基础需求.
OpenLDAP有多种配置选项来建立一个可复制的目录. 在前一个版本里面, 复制被限定在一个主服务器和若干个从服务器的条件下来讨论。一个主服务器从其他客户端接受目录更新, 而一个从服务器则仅仅从一个（单个的）主服务器接受更新. 这个复制结构被僵化地定义并且任何典型的数据库只能完成一个单一角色,主或者从.
现在OpenLDAP支持一个更广泛的复制拓扑, 关于提供者和消费者的以下这些条件已经不推荐了: 一个提供者复制目录更新到消费者; 消费者从提供者接收复制更新. 不像僵化定义的主/从关系,提供者/消费者角色更加的流动化：一个接收复制更新的消费者可能传递给其它服务器的另一个消费者，所以一个消费者也可以同时成为一个提供者。而且，消费者不需要成为一个实际上的LDAP服务器;它也可以仅仅是一个LDAP客户端。
以下章