Linux 安装并配置 OpenLDAP 新编（4）配置详解
Linux 安装并配置 OpenLDAP 新编（4）配置详解
在开始了解 OpenLDAP 的详细配置之前，再次重温一下配置文件的铁律：
- OpenLDAP 2.3 以及之后 的版本，已经使用动态运行时配置引擎，不要再使用旧的 CONF 格式；
- 虽然 OpenLDAP 的配置文件被存储为文本格式的 LDIF 文件，但是永远不要直接修改任何 LDIF 配置文件。配置的改变通过 LDAP 操作工具来进行。
本章依旧用于测试，不要用于生产环境！！！
实验准备
我们依旧使用之前 QuickStart 章节所安装的编译版本，创建一个全新的配置文件 init.ldif ，通过添加逐个配置块后导入配置存储目录，来观察配置项是如何生效的。
实验技巧
导入后，只需要删除配置存储目录中的文件即可初始化目录来重新导入，默认情况下这个目录通常是： /usr/local/etc/slapd.d/ ，导入的命令如下：
# 离线添加配置文件
/usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l init.ldif
# 返回如下信息，表示添加成功
Closing DB...
即便在启动后，想要再次重置数据进行实验，除了删除上面的配置存储文件之外，只要再删除数据库存储目录即可。默认情况下，这个目录通常为： /usr/local/var/openldap-data/ 。
配置层级
SLAPD 配置树拥有非常特殊的结构。树的根名为 cn=config ，包含全局配置设置。其他设置均包含在单独的子条目中：
- 动态模块加载： 只有在使用了 --enable-modules 选项配置软件时，才能使用这些选项；
- 架构定义：cn=schema,cn=config 条目包含了系统架构；
- 后端特定配置
- 数据库特定配置
配置规范
特别注意！特别注意！特别注意！
LDIF 文件的通用规则适用于所有的配置文件：以 # 字符开头的注释行将被忽略。如果一行以单个空格开头，则视为前一行的延续（即使前一行是注释），并删除单个前导空格。条目之间以空行分隔。多行的配置，最后一行之前的行位需要增加一个空格。最后这一句，务必小心理解！
很多时候对 ldif 文件的添加、修改发生错误，都是由于格式错误引起的，请务必注意！
全局配置
全局配置是指顶级的 config 、schema 以及 module ，模块在后面的章节再行解析。
基础配置
# example config file - global configuration entry
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: Stats
olcArgsFile: /usr/local/openldap/var/run/slapd.args
olcPidFile: /usr/local/openldap/var/run/slapd.pid
如果只添加了这些基础配置，导入后只会在存储目录中添加一个名为： cn=config.ldif 的文件。
架构配置
Schema决定了在在LDAP中可以添加什么样的条目类型，以及条目类型包含哪些属性，这可以对应理解为编程语言中的 类 ，在 LDAP 中这称之为 objectclass 。而具体条目，可以理解为编程语言中的 实例化对象 。
# internal schema
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# include the core schema
include: file:///usr/local/openldap/etc/openldap/schema/core.ldif
虽然架构可以在后期需要时再行导入，但是为了省事以及避免出现问题时不知所措，可以把常用的架构先导入进来，官方提供的架构位于安装目录的 schema 子目录中，理论上可以满足绝大多数情况下的需求：
# 常用架构
include: file:///usr/local/etc/openldap/schema/cosine.ldif
include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif
include: file:///usr/local/etc/openldap/schema/nis.ldif
在官方文档中，还描述了 misc 和 openldap 这两个所谓实验性质的架构；collective, corba, duaconf, dyngroup, java 这几个架构目前不知道有什么具体作用；dsee, msuser, namedobject, pmi 应该是有什么依赖需求，直接导入会报错。
在定义了上面的配置信息并导入配置存储目录之后，会被复制到配置存储目录中的 cn=config/cn=schema 目录内。此时查看 /usr/local/etc/slapd.d 目录，可以看到如下的结构：
/usr/local/openldap/etc/slapd.d/
├── cn=config
│ ├── cn=schema
│ │ ├── cn={0}core.ldif
│ │ ├── cn={1}cosine.ldif
│ │ ├── cn={2}inetorgperson.ldif
│ │ └── cn={3}nis.ldif
│ └── cn=schema.ldif
└── cn=config.ldif
特定的数据库指令
接下来的配置，都是针对于不同的数据库类型，但是每种类型的数据库基本都支持下面的指令，同时数据库项必须具有 olcDatabaseConfig 对象类。
olcDatabase 指令
olcDatabase 的典型用法为：
olcDatabase: [{<index>}]<type>
该指令指定了一个数据库实例，同时可以提供一个数字索引来区分类型相同的数据库。但是该参数也可以省略，由 slapd 统一生成管理。
其中，type 有两个独特的类型：config 和 frontend 。config 用于保存一些系统级别的配置信息； frontend 用于保存可应用于所有其他数据库的数据库级选项。当然后续数据库定义也可以覆盖指定的 frontend 设置。同时，这两个数据库总是隐式创建的，而且他们会在其他任何数据库之前创建。而且， frontend 的索引一定是 -1 ， config 的索引一般是 0， 是否可以添加多个 config ，并无实际测试过。
切记！切记！切记！ 对于 编译安装 一定要显式配置 config 数据库，否则会无法进行管理操作！
frontend 数据库
# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: frontend
olcReadOnly: FALSE
olcAccess: to * by * read
olcAccess 指令用于设置该数据库的 Access Control（访问控制） ，访问控制的大概语句范式为：
olcAccess: to <what> [by <who> [<access>] [<control>] ] +
正如字面意思，即授权某项资源（what），可以由何人（who），执行什么（access）。针对于配置数据库，仅允许系统超级用户管理，并禁止其他人操作。关于访问控制的详细内容，会在下章，专门再次。
在 frontend 中定义的 olcAccess 指令，默认适用于其他所有数据库中的条目。
config 数据库
# set a rootpw for the config database so we can bind.
# deny access to everyone else.
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
# SASL 机制身份认证
olcAccess: to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
# 定义该数据库超级用户密码。（DN默认为 cn=config ）
olcRootPW: {SSHA}5/k+kuMcbt3/30yHLdmyupPeC+kz8/e3
对于 config 后端数据库来说，默认的 olcRootDN 即为 cn=config ，无需显式指定。olcRootPW 为该 DN 所绑定的超级密码，可以用下面的命令提前生成：
slappasswd -s 123456
{SSHA}pJqiuqP0RsTtZ/4LOmN9ZMN8ZVH+Lxtr
通用数据库配置
# MDB definition for example.com
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: dc=example,dc=com
# 数据库存储目录必须存在，并且权限配置为 700
olcDbDirectory: /usr/local/var/openldap-data
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn pres,eq,approx,sub
olcDbIndex: objectClass eq
olcAccess: to attrs=userPassword
by self write
by anonymous auth
by dn.base="cn=Admin,dc=example,dc=com" write
by * none
olcAccess: to *
by self write
by dn.base="cn=Admin,dc=example,dc=com" write
by * read
其他配置属性的描述：
- olcSuffix : 后缀配置，可以理解为该数据目录的根节点；
- olcDbDirectory ： 改数据库的存储目录；
- olcRootDN ：官网对这个属性的解释有点绕，可以简单粗暴的理解为这就是该数据库的超级ID，可以用于管理该数据库的超级ID。该值还可以使SASL标识；
- olcRootPW ： DN标识对应的密码。
- olcDbIndex ：索引方式
总结
通过分块测试，应该可以逐步看到每一块配置项，所能影响的结果。此时对比之前YUM安装后的结构，就会发现配置存储目录中的配置文件前缀，为什么会是 olcDatabase={-1} 、 olcDatabase={0} 等序列编号，以及对应名字的含义了。
接下来的两章，会进一步解析访问控制以及动态模块加载的相关配置。
