您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
计划生育家庭特别扶助制度研究--基于泉州市的实证研究.pdf-全文阅读 下载-投稿赚钱网 77页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：150 &&
优秀硕士学位论文，完美PDF格式，支持自由编辑复制。
你可能关注的文档：
··········
··········
学校代码： 10385
研究生学号：
硕士专业学位论文
计划生育家庭特别扶助制度研究
——基于泉州市的实证研究
Family planning special assistance system
——An Empirical Study Based Quanzhou
作者姓名：
指导教师：
汤兆云 教授
实际单位导师：
专业学位类别： 公共管理硕士(MPA)
研究方向：
社会政策与管理
所在学院：
公共管理学院
论文提交日期：二○一三年九月十六日
学位论文独创性声明
本人声明兹呈交的学位论文是本人在导师指导下完成的研究成
果。论文写作中不包含其他人已经发表或撰写过的研究内容，如参考
他人或集体的科研成果，均在论文中以明确的方式说明。本人依法享
有和承担由此论文所产生的权利和责任。
论文作者签名：
签名日期：
学位论文版权使用授权声明
本人同意授权华侨大学有权保留并向国家机关或机构送交学
位论文的复印件和电子版，允许学位论文被查阅和借阅。本人授
权华侨大学可以将本学位论文的全部内容或部分内容编入有关数
据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇
编本学位论文。
论文作者签名：
指导教师签名：
签 名 日期：
签 名 日期：
计划生育家庭特别扶助制度是指国家对城镇和农村独生子女死亡或者伤、
病残后未再生育或收养子女家庭的夫妻，各级政府给予一定数额的特别扶助的
制度，作为计划生育基本国策的一项配套政策，是国家制定的针对我国独生子
女出现重大疾病伤残的家庭提供扶助的社会保障制度。
本文对我国计划生育家庭特别扶助制度的形成过程按照时序进行了完整地
梳理，理清了该制度出台的背景、意义以及所取得的成效，并剖析了制度实行
过程中遇到的问题、障碍，从而引发对改进该项制度的思考。本文主要采取文
献研究法、案例分析法及定量分析方法三种研究方法进行研究。本文以福建省
泉州市为例，对泉州市计划生育家庭特别扶助制度的实行成效主要按照多阶段
抽样的方法抽取调查样本，根据调查问卷中受访者的性别、年龄、婚姻情况、
文化程度、职业、家庭人均年收入、结婚年龄、生育年龄、子女情况等九个变
量的数据定量分析中间变量进行评估。为了克服各个变量之间的这种相关性、
重叠性，通过采用较少的变量即因子分析来代替原来的较多的变量。因子分析
是一种通过显在变量测评潜在变量，通过具体指标抽象因子的统计分析方法。
本文还在参考前人文献的基础上，提出以社会分层的理论对独生子女死亡
伤残的家庭进行分类，考察不同受助群体对扶助制度的认可程度、利用率和需
要满足状况，并结合地区经济发展及居民消费水平实际，参考相应社会保障制
度，有针对性地提出四点建议来完善现有的计划生育家庭特别扶助制度。
关键词：计划生育
独生子女家庭
利益导向机制
特别扶助制度
正在加载中，请稍后...developerWorks 社区
在本教程中，Sean Walberg 帮助您准备 Linux Professional Institute® Senior Level Linux Professional（LPIC-3）考试。在这个共 6 个教程的系列的第一篇中，Sean 介绍 Lightweight Directory Access Protocol（LDAP）的概念、体系结构和设计。学完本教程之后，您将掌握 LDAP 的概念和体系结构、目录设计和模式。
, Senior Network Engineer
Sean Walberg has been working with Linux and UNIX systems since 1994 in academic, corporate, and Internet Service Provider environments. He has written extensively about systems administration over the past several years. You can contact him at .
开始之前本节解释这些教程讲授什么内容，以及如何从这些教程获得最大的收益。关于本系列 （LPI）对 Linux 系统管理员的认证分为三级：初级（也称为 “认证级别 1”）、中级（也称为 “认证级别 2”）和高级（也称为 “认证级别 3”）。要获得认证级别 1，您必须通过 101 和 102 考试；要获得认证级别 2，您必须通过 201 和 202 考试。要获得认证级别 3，您必须已经获得中级认证，并通过 301 考试（“core”）。在高级认证中，可能还要通过其他专业考试。developerWorks 提供教程来帮助您准备初级、中级和高级认证的 5 门考试。每门考试包含几个主题，每个主题在 developerWorks 上都有一个对应的自学教程。表 1 列出 LPI 301 考试的 6 个主题和对应的 developerWorks 教程。表 1. LPI 301 考试：教程和主题LPI 301 考试主题developerWorks 教程教程摘要主题 301LPI 301 考试准备：概念、体系结构和设计（本教程）了解 LDAP 的概念和体系结构，了解如何设计和实现 LDAP 目录，并了解模式。参见下面详细的 。主题 302LPI 301 考试准备：安装和开发 敬请期待！主题 303LPI 301 考试准备：配置 敬请期待！主题 304LPI 301 考试准备：使用 敬请期待！主题 305LPI 301 考试准备：集成和迁移 敬请期待！主题 306LPI 301 考试准备：容量计划 敬请期待！要想通过考试 301（并获得认证级别 3），您应该：具备几年在许多计算机上为各种用途安装和维护 Linux® 的经验。具备使用各种技术和操作系统的经验。具备企业级 Linux 专业人员的经验（或者受过相关培训），包括作为其他角色从事企业级 Linux 管理的经验。了解高级和企业级 Linux 管理，包括安装、管理、安全、故障排除和维护。能够使用开放源码工具评估容量计划和解决资源问题。具备使用 LDAP 集成 UNIX® 和 Microsoft® Windows® 服务的专业经验，包括 Samba、Pluggable Authentication Modules（PAM）、电子邮件和 Microsoft Active Directory 目录服务。能够计划、设计、构建和实现一个使用 Samba 和 LDAP 的完整环境，而且能够评估容量计划和服务的安全性。能够创建 Bash 或 Perl 脚本，或者至少了解一种系统编程语言（比如 C）。Linux Professional Institute 不为任何第三方考试准备资料或技术做担保。关于本教程欢迎阅读 “概念、体系结构和设计”，这是针对 LPI 301 考试而设计的 6 篇教程中的第 1 篇。在本教程中，了解 LDAP 的概念和体系结构，了解如何设计和实现 LDAP 目录，并了解模式。本教程是按照
组织的。大致来说，权值越高的学习目标，在考试中出的题就越多。目标表 2 给出本教程的详细目标。表 2. 概念、体系结构和设计：本教程中涉及的考试目标LPI 考试目标目标权值目标摘要301.13熟悉 LDAP 和 X.500 概念。301.22设计和实现一个 LDAP 目录，计划一个适当的 Directory Information Tree 以避免冗余。了解适合在 LDAP 目录中存储的数据类型。301.33熟悉模式概念和 OpenLDAP 中包含的基本模式文件。前提条件要想从本教程获得最大的收益，您应该具备 Linux 的高级知识并且拥有一个可以用来实践的 Linux 系统。 如果您的基本 Linux 技能有点儿生疏了，可以先复习 。不同的程序版本可能会导致不同格式的输出，所以您在进行实践时获得的结果可能会与本教程中的清单和图不完全一样。系统需求为了学习这些教程中的示例，需要一个带 OpenLDAP 包并支持 PAM 的 Linux 工作站。大多数现代发行版都能够满足这些需求。概念和体系结构本节讨论 Senior Level Linux Professional（LPIC-3）考试 301 的 301.1 主题的内容。这个主题的权值为 3。 在本节中，学习： LDAP 和 X.500 技术规范属性定义目录名称空间区别名LDAP Data Interchange 格式元目录changetype 操作LPIC-3 考试主要针对 Lightweight Directory Access Protocol（LDAP）的使用。因此，第一个目标是了解 LDAP 是什么、它的作用是什么以及这个概念背后的一些基本术语。了解了这些知识之后，就能够开始设计自己的目录并将应用程序与目录集成起来。LDAP 是什么？在讨论 LDAP 之前，先回顾一下目录的概念。目录的典型例子是电话簿，电话簿中按照字母表次序列出人名以及他们的电话号码和地址。每个人（或家庭）代表一个对象，电话号码和地址是这个对象的属性。一些对象是企业而不是个人，这些对象可能有传真号码或营业时间等属性。与印刷的目录不同，计算机目录本质上是层次化的，允许将对象放在其他对象下面，形成父-子关系。例如，可以扩展电话目录，让它包含代表城市地区的对象，每个个人和企业对象分别归入对应的地区对象。这些地区对象归入城市对象，城市对象进一步归入州或省对象，依此类推，形成图 1 这样的层次结构。这种结构会使印刷的目录更难使用，因为需要知道人名和地理位置才能进行查询，但是计算机可以对信息进行排序和搜索目录的不同部分，所以这不是个问题。图 1. 一个示例目录看一下图 1，Simpson 的记录表明的信息不仅仅是地址和电话号码。您还知道他处于 Springfield 城的东部。这个结构称为树。在这里，树的根是 Springfield 对象，其他对象代表分支的不同级别。这种基于目录的数据存储方式与您熟悉的关系数据库很不一样。为了比较这两种模型，图 2 显示在采用关系数据库模型的情况下电话数据的样子。图 2. 采用关系形式的目录数据在关系模型中，每种类型的数据是一个单独的表，允许存储不同类型的信息。每个表还有一个指向父表的链接，这样就能够保存对象之间的关系。注意，如果要添加更多的信息字段，就必须修改表的结构。请记住，目录模型没有对数据在磁盘上的存储方式施加任何限制。实际上，OpenLDAP 支持许多种后端，包括平面文件和 Structured Query Language（SQL）数据库。表在磁盘上的布局机制在很大程度上是对用户隐藏的。例如，Active Directory 提供一个 LDAP 接口来操作它的专有后端。LDAP 的历史LDAP 是在 Request for Comments（RFC）1487 中提出的，它作为一种访问 X.500 目录的轻量方式，替代比较复杂的 Directory Access Protocol（参见
中这个 RFC 和相关 RFC 的链接）。X.500 是来自 International Telecommunication Union（ITU，以前称为 CCITT）的一组标准，指定了如何实现目录。您可能熟悉 X.509 标准，这个标准构成大多数 Public Key Infrastructure（PKI）和 Secure Sockets Layer（SSL）证书的核心。在此之后，LDAP 发展到了第 3 版，在 RFC 4511 中定义。最初，连接 X.500 数据库需要按照真正的 ITU 方式使用 Open Systems Interconnection（OSI）协议簇，这要求理解大量的协议文档。LDAP 使基于 Internet Protocol（IP）的网络能够连接相同的目录，而且所需的开发周期比使用 OSI 协议时短得多。最终，IP 网络的流行导致 LDAP 服务器的出现，这些服务器只支持必要的 X.500 概念。尽管 LDAP 和 IP 战胜了 X.500 和 OSI，但是目录数据的底层组织仍然符合 X.500。本教程中讨论的一些概念（比如区分名和对象标识符）都来自 X.500。X.500 是一种创建全局目录系统的方法，主要用来协助用于电子邮件的 X.400 系列标准。通过一些处理，LDAP 也可以用作全局目录，但是它主要在企业的内部使用。命名和属性在 LDAP 系统中，名称是非常重要的。名称使我们能够访问和搜索记录，而且名称常常暗示出记录在 LDAP 树中的位置。图 3 显示一个典型的 LDAP 树。图 3. 一个显示用户的典型 LDAP 树树的顶部（即根）是一个称为 dc=ertw,dc=com 的实体。dc 是 domain component 的简写。因为 ertw 在顶级域 .com 下面，所以它们被分成两个不同的单元。在使用 X.500 命名法时，用一个逗号连接名称的各个成分，新的成分添加在左边。从技术上说，也可以将根命名为 ，但是为了保持互操作性，最好将域名的各个成分分隔开（实际上，RFC 2247 建议采用分隔的域名成分）。dc=ertw,dc=com 惟一地标识树中的这个实体。按照 X.500 的说法，这称为区分名（distinguished name，DN）。DN 很像关系数据库中的主键，因为在树中只有一个实体具有给定的 DN。最顶部条目的 DN 称为 根 DN（Root DN）。在根 DN 下面是一个 DN 为 ou=people,dc=ertw,dc=com 的对象。ou 表示 organizational unit，可以确定它处于根 DN 下面，因为 ou 直接出现在根 DN 的左边。也可以将 ou=people 称为相对区分名（relative distinguished name，RDN），因为它在它的层次上是惟一的。按照递归术语来说，一个实体的 DN 就是它的 RDN 加上父实体的 DN。为了消除冗余，大多数 LDAP 浏览器只显示 RDN。沿着树向下移动到 cn=Sean Walberg,ou=people,dc=ertw,dc=com，就会发现一个人的记录。cn 表示 common name。但是，记录包含一些采用属性（attribute） 形式的额外信息。属性提供关于实体的额外信息。实际上，可以看到 DN 最左边的成分是重复的；在本例中，它是 cn 属性。从另一个角度来看，一个实体的 RDN 由这个实体的一个或多个属性组成。尽管 mail 和 description 很容易理解，但是 objectClass 的意义就不这么明显了。对象类是与某个实体类型对应的一组属性。一个对象类可能包含人的属性，另一个对象类包含 UNIX 帐户的属性。通过将两个对象类分配给一个实体，就可以存储两组属性。每个对象类有一个对象标识符（object identifier，OID），OID 惟一地标识它。对象类还指定属性，以及哪些属性是必需的，哪些是可选的。必需属性必须有数据，才能保存这个实体。对象类还标识保存的数据类型以及是否允许同名的多个属性。例如，一个人只能有一个职员编号，但是可以有多个名字（比如 Bob、Robert 和 Rob）。并非只有最底层的对象能够有相关联的对象类。称为容器（container） 的对象也有对象类和属性。people ou 是 organizationalUnit 类型的，它有一个描述属性和 ou=people，这些组成了 RDN。树的根是 dcObject 和 organization 类型的。根据对象中和对象下面的内容，可以知道将哪些对象类分配给对象。更多细节参见
一节。根 DN 还定义树的名称空间（namespace），或者按照更技术性的说法，Directory Information Tree（DIT）。以 dc=ibm,dc=com 结尾的实体处于
所示的名称空间外边，而 Sean Walberg 的记录属于这个名称空间。但是要记住，一个 LDAP 服务器可能包含多个名称空间。一个有点儿抽象的概念称为根 DSE（Root DSE），它包含服务器上可用的所有名称空间的相关信息。DSE 表示 DSA-Specific Entry，DSA 表示 Directory System Agent（也就是 LDAP 服务器）。 总结了与 LDAP 树相关联的术语。图 4. LDAP 术语最后，LDAP 树可以与其他树或数据源进行同步。例如，树的一个分支可能来自一个安全系统，另一个分支来自一个客户数据库，其他数据存储在 LDAP 服务器中。这称为元目录（meta-directory），可以作为单点登录等用途的单一数据源。LDIF 文件数据可以按照两种方式之一进入 LDAP 服务器。可以使用 LDAP 协议通过网络装载数据，也可以通过 LDAP Data Interchange Format（LDIF）格式的文件将数据导入服务器。在任何时候都可以使用 LDIF，比如在创建最初的树时，或者在以后某个时间批量添加数据或修改数据时。搜索的输出也可以保存为 LDIF 格式，这样可以方便解析或导入另一个服务器。LDIF 的完整规范在 RFC 2849 中（见
中的链接）。添加记录清单 1 给出生成图 3 所示的树的 LDIF。清单 1. 一个填充树的简单 LDIF 文件# This is a comment
dn: dc=ertw,dc=com
description: This is my company
the description continues on the next line
indented by one space
objectClass: dcObject
objectClass: organization
dn: ou=people,dc=ertw,dc=com
ou: people
description: Container for users
objectclass: organizationalunit
dn: cn=Sean Walberg,ou=people,dc=ertw,dc=com
objectclass: inetOrgPerson
cn: Sean Walberg
cn: Sean A. Walberg
sn: Walberg
homephone: 555-111-2222
description: Watch out for this guy
ou: Engineering在讨论 LDIF 文件的细节之前，要注意属性名是不区分大小写的。也就是说，objectclass 与 objectClass 和 OBJECTCLASS 相同。许多人喜欢将每个单词的首字母大写，但是第一个单词除外，比如 objectClass、homePhone 和 thisIsAReallyLongAttribute。LDIF 的第一行是一个 UNIX 风格的注释，这种注释的前面是一个 hash 符号（#）。LDIF 文件是标准的 ASCII 文件，可以由人进行编辑，所以注释可能有帮助。LDAP 服务器会忽略注释。LDIF 文件中的记录由一个空行分隔，记录包含由冒号（:）分隔的属性和值的列表。记录以 dn 属性开头，这个属性标识记录的区分名。因此， 显示三个记录，它们的 RDN 分别是 dc=ertw、ou=people 和 cn=Sean Walberg。看一下 ，可以看到第一个记录是树的根。首先出现的是区分名。然后是冒号分隔的所有属性和值的列表。值中的冒号不需要任何特殊处理。LDAP 工具知道第一个冒号是属性和值的分隔符。如果需要为一个属性定义两个值，那么只需在单独的两行上列出它们。例如，根对象定义了两个对象类。每个记录必须定义至少一个对象类。对象类进而要求某些属性必须存在。对于根对象，dcObject 对象类要求定义一个 domain component（即 dc）属性，organization 对象类要求定义一个 organization（即 o）属性。因为对象必须有一个与 RDN 对应的属性和值，所以需要通过 dcObject 对象类导入 dc 属性。对于有效的记录，o 属性并不是必需的。根对象上还使用 description 描述这个公司。这里的目的是演示换行格式。如果值需要跨越多行，那么每个新行应该以一个空格开头。请记住，指定多个属性：值对会定义这个属性的多个实例。 中的第二个记录定义一个 organizationalUnit，这是人员对象的容器。第三个记录定义一个类型为 inetOrgPerson 的用户，这个类型提供了定义组织人员的常用属性。注意，定义了两个 cn 属性；一个也用在记录的 DN 中。第二个包含中间名的首字母，它用来帮助搜索，但是其格式首先必须满足 RDN 的定义条件。在用户记录中还有一个 ou 属性，它并不对应于这个用户所属的 organizationalUnit。总是能够通过解析 DN 找到用户对象所属的容器。这个 ou 属性引用用户定义的某些东西，在这个示例中是一个部门。服务器并不保证引用完整性，但是应用程序可以搜索 ou=Engineering,ou=Groups,dc=ertw,dc=com 这样的有效 DN。对添加记录的 LDIF 文件的惟一限制是，必须从根开始按次序构建树。 显示先构建根对象，然后是一个 ou，然后是 ou 中的一个用户。构建了这个结构之后，就可以在 people 容器中直接添加用户，但是如果要使用一个新容器，就必须先创建它。添加对象所需的 LDIF 相当简单。如果必须修改或删除对象，格式就会更复杂。LDIF 定义一个 changetype，它可以是以下操作之一：add：添加一个项目（默认）。delete 删除 DN 指定的项目。modrdn 修改当前容器中指定对象的名称，或者将这个对象移动到树的其他部分。moddn 与 modrdn 同义。modify 修改当前 DN 中的属性。删除用户删除一个项目是最简单的情况，只需要 dn 和 changetype。清单 2 显示如何删除一个用户。清单 2. 用 LDIF 删除一个用户dn: cn=Fred Smith,ou=people,dc=ertw,dc=com
changetype: delete操作 DN操作对象的 DN 稍微复杂一点儿。尽管有两个命令 moddn 和 modrdn，但是它们的作用是相同的！这个操作由三个部分组成：指定新的 RDN（DN 最左边的成分）。决定记录中新的 RDN 是否应该替换旧的 RDN，还是应该保留旧的 RDN。（可选）通过指定新的父 DN，将记录转移到树的其他部分。假设 Jane Smith 要将她的姓名改为 Jane Doe。首先需要修改她的 cn 属性来反映姓名的变化。因为新的姓名是引用她的主要方式，而且姓名是 DN 的组成部分，所以需要执行 moddn 操作（如果姓名不是 DN 的组成部分，那么这只是个属性修改，属性修改在下一节中讨论）。
第二个问题是，除了 cn: Jane Doe 之外，是否应该保留 cn: Jane Smith，这样就可以用这两个姓名搜索她。清单 3 给出执行这一修改的 LDIF。清单 3. 修改用户 RDN 的 LDIF# Specify the record to operate on
dn: cn=Jane Smith,ou=people,dc=ertw,dc=com
changetype: moddn
# Specify the new RDN, including the attribute
newrdn: cn=Jane Doe
# Should the old RDN (cn=Jane Smith) be deleted?
1/0, Default = 1
deleteoldrdn: 0清单 3 首先识别出 Jane 的记录，然后执行 moddn 操作。指定新的 RDN，它仍然使用 common name 类型，但是使用新的名称。最后，deleteoldrdn 指示服务器保留旧的名称。注意，newrdn 是 moddn 操作中惟一的必有选项，但是如果省略 deleteoldrdn，这个操作就会删除原来的 RDN。RFC 2849 指出，deleteoldrdn 是一个必需元素。如果要将新的 Jane Doe 转移到树的其他部分，比如转移到 ou=managers,dc=ertw,dc=com，那么 LDIF 必须指定这个新位置，见清单 4。清单 4. 将记录转移到树的其他部分dn: cn=Jane Doe,ou=people,dc=ertw,dc=com
changetype: modrdn
newrdn: cn=Jane Doe
deleteoldrdn: 0
newsuperior: ou=managers,dc=ertw,dc=com奇怪的是，尽管必须指定新的 RDN，即使它与旧的 RDN 相同；而且 OpenLDAP 解析器现在要求有 deleteoldrdn，尽管在 RDN 保持不变的情况下它是没有意义的。在它们后面是 newsuperior，这是树中新的父节点的 DN。关于 modrdn 操作要注意的最后一点是次序问题，这与大多数其他 LDIF 格式不一样。changetype 之后是 newrdn，然后是 deleteoldrdn 和可选的 newsuperior。修改属性最后一种 changetype 操作是 modify，它用来修改记录的属性。通过前面对 moddn 的讨论可以看出，modify 显然不应该应用于记录的 DN 或 RDN。清单 5 演示对单个记录的几个修改。清单 5. 通过 LDIF 修改记录dn: cn=Sean Walberg,dc=ertw,dc=com
changetype: modify
replace: homePhone
homePhone: 555-222-3333
changetype: modify
add: title
title: network guy
changetype: modify
delete: mail
-执行 modify 操作的 LDIF 看起来与其他 LDIF 很相似。首先是记录的 DN，然后是 changetype。在此之后是 replace:、add: 或 delete:，然后是属性。对于 delete，这些信息就够了。其他操作需要属性:值对。每个修改后面是空行上的一个连字符（-），最后一个修改也是如此。对于人和计算机来说，LDIF 的格式都很容易理解。LDIF 对于导入和导出大量数据是很有用的工具。目录设计本节讨论 Senior Level Linux Professional（LPIC-3）考试 301 的 301.2 主题的内容。这个主题的权值为 2。在本节中，学习：定义 LDAP 目录内容目录的组织如何计划适当的 Directory Information Trees判断 LDAP 是否合适与其他任何工具一样，并非每种解决方案都适合使用 LDAP。在选用 LDAP 之前，必须问自己一些问题：修改记录的频率有多高？主要是哪些修改？哪些系统要使用这些数据？对这些数据执行的查询是什么类型的？这些信息在本质上是否是层次化的？LDAP 数据库面对的操作以读操作为主。人们每年只修改个人信息几次，但是查询属性的次数要多得多，比如将拥有一个文件的 UserID 解析为可打印的用户名。常常为 LDAP 数据编制索引来帮助服务器搜索数据，这意味着对底层数据的每个修改会导致对索引的多个修改。而且，LDAP 没有提供对树进行大量更新的简便方法，只能执行搜索，然后修改各个 DN。LDAP 规范没有定义关系数据库中常见的事务概念。事务确保其中的所有操作都成功，否则就将数据回滚到事务之前的状态（个别服务器可能会实现事务，但这不是规范的要求）。由于更新数据方面的这些限制和缺少事务概念，对于银行交易这样的场景，LDAP 不是合适的选择。了解数据的用户（即消费者）也很重要。如果没有消费者使用 LDAP，那么 LDAP 可能不合适。但是，LDAP 是一种极其简单的协议，大多数平台上的大多数语言都可以实现 LDAP。由于只定义了很少的操作，很容易将它集成到现有的应用程序中。LDAP 提供了搜索功能，但是无法与关系数据库的搜索功能相比。LDAP 服务器可能使用 SQL 存储底层数据，但是用户接触不到这个层次，无法使用 SQL。因此，用户只能使用 LDAP 服务器支持的搜索过滤器。本系列后续的文章会详细讨论这些过滤器，目前只需知道这些过滤器的功能很有限。可以执行一些强大的搜索，比如 “告诉我住在 Washington 的所有职员和住在 Texas 的超过 40 岁的职员”。但是，没有与 SQL GROUP BY 等效的语句。LDAP 最适合查找型的操作，比如 “告诉我 UID 为 4131 的职员的用户名” 和 “告诉我 Jim Smith 的所有下属的名字”。最后，要存储的信息在本质上应该是层次化的。可以在 LDAP 服务器上存储平面的数据列表，但是这可能会浪费资源。如果您回答了以上问题，而且断定 LDAP 就是正确的解决方案，就该设计目录树了。组织您的树首先要记住的一点是，谁都不希望以后对树进行重新组织。所以我们的目标是，对对象进行划分，让树的每个分支包含相似类型的对象，尽可能减少不得不移动对象的情况。这有两个原因。首先，移动对象是一种会引起争议的操作。第二，移动对象很麻烦，需要修改对象的 DN，然后必须更新引用这个对象的所有对象。根 DN树的根应该代表您的公司。RFC 2247 主张使用 dc 属性和 dc=example,dc=com 格式将公司的主域名映射为 DN。您的公司可能有许多互联网域名，但是其中应该有一个是首选的。另一种常见做法是在 local 顶级域名（TLD）下选择一个当前在互联网上还不存在的域名。Microsoft 一直建议对他们的 Active Directory 实现使用这个 TLD，尽管它不是保留的 TLD。如果不希望在根 DN 中使用域名，那么只需给一个对象设置 objectclass: organization，这会提供根 DN o=My Corporation。填充结构决定将什么放在 DIT 的下一级上比较困难。设计人员常常希望用一系列嵌套的 organizationalUnit 对象描述公司的组织结构，但是公司经常会重组，这会破坏第一条规则（尽可能不移动对象）。所以，应该考虑用属性存储公司的组织结构信息。根据 LDAP 服务器的用途和您选择的对象命名方式，可以把所有用户放在一个树中，也可以根据角色将他们分开。例如，可以为职员创建一个容器，为客户创建另一个容器，也可以把他们放在一个容器中。这个决策取决于您的意图和管理树的方式。如果销售部门负责管理客户列表，系统管理员负责管理职员列表，那么创建两个容器可能更合适。图 5 显示的 DIT 就划分为客户和用户两部分。图 5. 为用户和客户提供单独分支的 LDAP 树图 5 所示的结构将职员和客户分开了。所有职员位于同一个组织单元（organizational unit，OU）中，但是客户按照地区进行进一步划分。在这种情况下，不同的人员就可以管理各自地区的客户。如果打算用 LDAP 对 UNIX 资源进行验证，那么必须决定将这些信息存储在哪里。前面已经处理了用户帐户，但是还需要存储组和其他映射，比如主机、服务、网络和别名。把哪些信息存储在 LDAP 中，哪些存储在本地文件中，以及是否需要集中地更新它们，这些都由您自己决定。最简单的方法是将每个映射存储在一个单独的 organizationalUnit 中。当配置 UNIX 系统来读取这些信息时，需要指定容器的 DN 和过滤器。如果在用户 OU 中存储组，就必须编写一些过滤器。如果要对职员 OU 做任何结构性修改，还必须调整这些过滤器。决定对象类到目前为止，讨论一直集中在 LDAP 树的布局上，基本目标是避免以后被迫修改对象的名称。决定了树的布局之后，必须决定使用哪些对象类。对于树中同一分支下的对象，可以分配不同的对象类，但是这几乎肯定会在以后造成维护困难。更糟糕的是，如果在对象类分配方面犯了错误，那么不一定能够在对象上添加更多的对象类。LDAP 模式定义两种对象类：结构的（structural） 和辅助的（auxiliary）。结构对象类常常从其他对象类继承属性，继承链是从一个称为 top 的对象类开始的。可以认为，结构对象类定义对象的 “身份”，而辅助对象类添加属性。organizationalUnit 是一个结构对象类，inetOrgPerson 也是。请再看一下 ，顶级条目有两个对象类：dcObject 和 organization。organization 是结构对象类。dcObject 起辅助作用，它定义了 dc 属性。可能导致问题的原因是，一个条目只能有一个结构对象类。有时候，会在同一个记录中看到 inetOrgPerson、organizationalPerson、person 和 top，但是它们都是同一个继承树的组成部分。inetOrgPerson 和 account 都是结构的，而且不属于同一个继承树，因此不能一起使用。一些 LDAP 服务器允许这么做，但是这种行为最终可能会改变并导致问题。第三种对象类称为抽象（abstract）对象类。它很像结构对象类，但是必须继承它，然后才能使用。top 就是这种对象类。有一些通用的结构对象类：inetOrgPerson：定义一个人，包括一些联系信息。organizationalRole：与人很相似，但是它定义一个角色，比如 IT Helpdesk 或 Fire Warden。organizationalUnit：一个一般性容器，可以描述一个部门，也可以用来分隔 LDAP 树的各个部分，比如组、人和服务器。organization：一个公司或其他组织。groupOfNames：存储一个或多个 DN，它们引用一个组的成员。尽管对于 UNIX 组不一定有用，但是对会议邀请和其他简单情况有帮助。应该坚持对人和组织使用这些对象类，这样比较安全。大多数扩展（比如身份验证）使用辅助属性。如果有疑问，可以参考模式。最后一个设计问题是选择 DN。对于大多数分支，这相当容易，因为没有出现重复的可能性。UNIX 组名和 ID 是惟一的，所以可以将 cn 用作组的 RDN。但是，如果有两个职员都叫作 Fred Smith，那该怎么办？DN 必须是惟一的，而他们两人的 DN 都是 cn=Fred Smith,ou=People,dc=example,dc=com。必须使用别的数据，比如 employeeNumber，或者用两个以加号（+）分隔的属性组成 RDN。例如，cn=Fred Smith+userid=123, ou=people, dc=example, dc=com 就包含一个由两个属性组成的 RDN。无论采用哪种方式，都应该保持一致！模式本节讨论 Senior Level Linux Professional（LPIC-3）考试 301 的 301.3 主题的内容。这个主题的权值为 3。 在本节中，学习：LDAP 模式概念如何创建和修改模式属性和对象类语法到目前为止，我们几次提到了模式，但是还没有全面解释这个概念。模式（schema）是对象类及其属性的集合。模式文件以 LDAP 服务器可以理解的一种文本格式包含一个或多个对象类和属性。将模式文件导入 LDAP 服务器的配置，然后就可以在对象中使用对象类和属性。如果可用的模式无法满足需要，还可以创建自己的模式或者扩展现有的模式。LDAP 模式概念从技术上说，模式是一种对对象类和属性进行打包的机制。但是，对象类的分组并不是随机的。模式一般根据应用进行组织，比如核心、X.500 兼容性、UNIX 网络服务、发送邮件等等。如果需要将一个应用程序与 LDAP 集成，一般必须在 LDAP 服务器中添加一个模式。本系列中的一个后续教程会详细讨论 OpenLDAP 的配置，现在只需知道添加模式的方法是使用 include /path/to/file.schema。在重新启动服务器之后，新模式就会生效了。在装载模式之后，就可以将新的对象类应用于相关的对象。这可以通过 LDIF 文件或 LDAP API 完成。应用对象类就提供了更多属性。创建和修改模式模式文件的格式相当简单。清单 6 显示的模式包含 inetOrgPerson 对象类以及它的一些属性。清单 6. inetOrgPerson 定义的一部分attributetype ( 2.16.840.1..1.241
NAME 'displayName'
DESC 'RFC2798: preferred name to be used when displaying entries'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1..1.15
SINGLE-VALUE )
attributetype ( 0.9.0.100.1.60
NAME 'jpegPhoto'
DESC 'RFC2798: a JPEG image'
SYNTAX 1.3.6.1.4.1..1.28 )
objectclass
( 2.16.840.1..2.2
NAME 'inetOrgPerson'
DESC 'RFC2798: Internet Organizational Person'
SUP organizationalPerson
STRUCTURAL
audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
)在模式文件中空行并不重要，主要用来提高对人的可读性。第一个定义是一个 attributetype，这表示一个属性。属性定义放在圆括号中。首先是一串由点号分隔的数字，称为对象 ID（object ID，OID），这是一组全局惟一的数字。OID 也是层次化的，所以如果您被分配了 1.1 树，就可以创建 1.1.1 或 1.1.2.3.4.5.6 这样的 OID，而不需要注册。OID 后面是一系列关键字，每个关键字后面有一个值。首先，属性的 NAME 定义人使用的名称，比如在 LDIF 文件中使用或者在通过 LDAP API 检索信息时使用。有时候可能会看到 NAME ( 'foo' 'bar' ) 形式的名称，这意味着 foo 和 bar 都是可接受的。但是，服务器把第一个名称作为属性的主要名称。DESC 提供属性的描述。这帮助您在浏览模式文件时理解属性的意义。EQUALITY、SUBSTR 和 ORDERING（这里没有显示）需要一个匹配规则（matching rule）。它们分别定义如何比较、搜索和排序字符串。caseIgnoreMatch 是不区分大小写的匹配，caseIgnoreSubstringsMatch 也属于不区分大小写的匹配。 中列出的 Web 站点定义了所有标准匹配规则。与 LDAP 中的大多数东西一样，服务器可以为自己的属性定义匹配方法，所以无法提供完整的匹配规则列表。属性的 SYNTAX 通过引用 OID 定义数据的格式。RFC 2252 列出标准语法及其 OID。如果 OID 后面紧跟着一个放在花括号（{}）中的数字，这就表示数据的最大长度。1.3.6.1.4.1..1.15 表示 DirectoryString 是一个 UTF-8 字符串。最后是 SINGLE-VALUE 关键字，它没有参数，指定只允许 displayName 的一个实例。jpegPhoto 属性的定义非常短：只有 OID、名称和描述以及 JPEG 对象（这是二进制数据的编码字符串）的语法。对图像进行搜索或排序是不可行的，而且多个图像可以放在一个记录中。然后，按照相似的方法定义一个对象类。定义的开头是 objectclass 关键字，然后是圆括号、对象类的 OID 和定义。NAME 和 DESC 的意义与前面一样。SUP 定义父对象类，也就是说这个对象类继承 SUP 关键字指定的对象类。因此，inetOrgPerson 包含 organizationalPerson 的属性。STRUCTURAL 关键字定义这是一个结构对象类，可以作为对象的主类型。其他选项是 AUXILIARY（这在现有对象中添加属性）和 ABSTRACT（这与结构对象类相似，但是不能直接使用）。抽象对象类必须由另一个对象类继承，然后可以使用继承的对象类。top 对象类是抽象的。大多数其他结构对象类都继承它，包括 person，person 是 organizationalPerson 的父类，organizationalPerson 进而由 inetOrgPerson 继承。MAY 和 MUST 关键字分别定义使用这个对象类的记录允许使用的属性和必须具备的属性。如果缺少任何必需属性，记录就无法保存。每个属性由美元符号（$）分隔，即使换行了，也不能省略美元符号。最好不要修改结构对象类或者现有的广泛使用的辅助对象类。因为这些对象类是众所周知的，如果以后改用其他服务器，这种修改可能导致不兼容。最好的解决方案是定义自己的辅助对象类，创建一个本地模式，并将它应用于自己的记录。例如，如果您的组织是一所大学，希望存储学生的属性，那么可以考虑创建一个学生对象类，这个对象类继承 organizationalPerson 或 inetOrgPerson，并添加自己的属性。然后可以创建辅助对象类来添加课程表等属性。了解要使用哪些模式学习了如何创建模式之后，您很可能迫不及待地根据自己的环境创建自己的模式。这肯定可以满足您当前的需要，但是随着在 LDAP 树中添加更多功能以及集成其他系统，这很可能在以后造成许多困难。最好的方法是尽可能坚持使用标准的对象类和属性，只在必要的情况下进行扩展。OpenLDAP 通常将它的模式文件存储在 /etc/openldap/schema 中，文件扩展名是 .schema。表 3 列出默认的模式及其用途。表 3. OpenLDAP 附带的模式文件名用途corba.schema它定义的对象类和属性用来跨多台机器处理 Common Object Request Broker Architecture（CORBA）对象引用。core.schema它定义许多常用的属性和对象类。这个模式包含 organizationalUnit、top、dcObject 和 organizationalRole。在寻找合适的对象类和属性时，应该首先查看 core.schema。cosine.schema它定义的对象类和属性来自 X.500 规范。尽管其中的一些对象类和属性是有用的，但是在 core 和 inetorgperson 等其他模式中常常有更好的替代品。dyngroup.schema它定义由 Netscape Enterprise Server 使用的一组试验性对象。inetorgperson.schema它定义 inetOrgPerson 对象（扩展 core.schema 中的对象）。java.schema与 corba.schema 相似，这个模式定义的一系列对象类和属性用于在 LDAP 树中查找 Java™ 类。misc.schema它实现的对象类用于在树中查找邮件。最好查阅自己的电子邮件服务器文档，了解服务器使用哪个模式。nis.schema如果用 LDAP 进行身份验证，就要使用这个模式。nis.schema 定义 posixAccount，其中提供的属性用于在用户对象中存储身份验证数据。它还提供各种映射类型，用来处理组、网络、服务和 Network Information System（NIS）等网络身份验证机制所用的其他文件。openldap.schema它主要用于演示，提供了一些基本对象。ppolicy.schema它提供的一组对象用来在 LDAP 中实现密码策略，比如口令老化（aging）。注意，其中一些对象由传统的 UNIX 影子机制处理，已经包含 nis.schema 中。另外，RFC 4519 解释了一些常用属性。找到自己需要的属性之后，就可以查看模式文件，判断需要将哪些文件包含在 LDAP 配置中，以及必须在记录中使用哪些对象类。结束语在本教程中，学习了 LDAP 的概念、体系结构和设计。LDAP 的设计目的是以简单的方式通过 IP 连接 X.500 目录。目录以层次化方式存储数据，其结构就像是树。树中的记录由区分名来标识，并具有许多属性-值对，包括一个或多个对象类，它们定义可以在记录中存储哪些数据。LDAP 本身是指用来搜索和修改树的协议。但是在实践中，LDAP 这个词也用于所有相关事物，比如 LDAP 服务器、LDAP 数据等等。常常用 LDIF 导入和导出 LDAP 数据，LDIF 是一种表示 LDAP 数据的文本格式。LDIF 文件指定一些 changetype 操作，比如 add、delete、modrdn、moddn 和 modify。可以通过这些操作在树中添加条目、删除条目或移动数据，以及修改数据属性。正确地设计树对于 LDAP 服务器的长期运行非常重要。正确的设计可以减少所需的修改操作，使数据保持一致性，便于其他应用程序搜索。通过选用常用的属性，可以确保 LDAP 数据的其他消费者能够理解属性的意义，减少必需的转换。LDAP 模式指定在服务器中可以使用哪些属性。模式包含属性的定义，包括惟一标识它们的 OID、关于数据如何存储和排序的指示以及对属性作用的文字描述。对象类将属性进行分组，它们可以定义为结构、辅助和抽象三种类型。结构对象类定义记录，所以一个记录只能有一个结构对象类。辅助对象类添加用于特殊用途的属性，可以添加到任何记录中。抽象对象类必须被继承，不能直接使用。
参考资料 参考 developerWorks 上的整个 ，学习 Linux 的基础知识并准备系统管理员认证考试。 在
中，可以找到 Linux Professional Institute 的三个 Linux 系统管理认证级别的任务列表、问题示例和详细的学习目标。 （X.500 Lightweight
Directory Access Protocol）介绍了 LDAP 的开发过程和 X.500 的历史。 （Using Domains in
LDAP/X.500 Distinguished Names）简要描述了 domainComponent 属性以及在 LDAP 树中如何正确地使用它。 （Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions）列出了属性的标准语法，可以帮助您了解特定属性所需的格式。 （The LDAP Data
Interchange Format (LDIF) - Technical Specification）描述了 LDIF 语言。它使用 Backus-Naur Form（BNF）指定这种语言，可能比较难以理解。（Augmented BNF for Syntax Specifications: ABNF）可以帮助您理解各种操作符。 （Lightweight
Directory Access Protocol (LDAP): The Protocol）是 LDAP 协议最新的工作草案。 （Lightweight
Directory Access Protocol (LDAP): Schema for User Applications）是更新的常用属性列表；这个列表帮助所有人使用相同的属性描述相同的数据。
详细描述每个匹配的规则（字符串比较、子字符串和次序）的工作方式。 详细描述处理对象类时的一些比较微妙的规则。一些 OpenLDAP 错误消息非常简单，尤其在处理 LDIF 导入时。OpenLDAP 中的
框架是关键，因为可以进一步发展元目录概念，而不只是将多个 LDAP 服务器连接起来。可以将对特定的树或 OID 的请求转发到定制代码，代码可以调用脚本、读取数据库或调用 API。 Web 站点上也对此做了描述。
“”（O'Reilly，2006 年 11 月）解释了对象类继承。它讨论了 inetOrgPerson 对象类并描述了结构和辅助对象类。
是一份出色的开放源码指南，但是目前仍然在开发过程中。 在
可以找到为 Linux 开发人员准备的更多参考资料，还可以查阅 。 查阅 developerWorks 上的所有
和 。 随时关注 。 如果您正在寻找一种 LDAP 服务器，那么
是不错的选择。
是一个基于 Web 的 LDAP 管理工具。
是一种出色的 GUI。 使用
构建您的下一个 Linux 开发项目，这些软件可以从 developerWorks 直接下载。 通过
中的 blog、论坛、podcast 和社区主题，加入 。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
免费下载、试用软件产品，构建应用并提升技能。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Linux, Open sourceArticleID=270838ArticleTitle=LPI 301 考试准备，主题 301: 概念、体系结构和设计publish-date=}