Access Control List(ACL)是 ClearCase 8.0.1 引入的最重要的新特性。通过 Policy 与 Rolemap 这两种对象，ACLs 赋予了 VOB 元素更灵活、细粒度的权限控制。当前很多客户的生产环境规模庞大，往往使用多站点部署。探讨如何将 ACLs 应用于 ClearCase Multisite 环境是本文的主要目的。本文将以一个小规模的 ClearCase Multisite 环境为例，将使用不同 ClearCase 版本的站点分段升级到 ClearCase 8.0.1 并应用 ACLs 为主线，分步讲解其中的关键点与注意事项，特别是 ACLs 在 Multisite 中的行为。

ClearCase ACLs 简介

Rational ClearCase 8.0.1 引入了 Access Control List(下文将简称 ACL 或 ACLs)，提供对 VOB 对象的访问控制。VOB 中定义了两种新的对象类型，policy 和 rolemap 来实现 ACLs 的有效管理。每个 rolemap 创建的时候都要指定一个 policy，而一个 policy 可以被多个 rolemap 实现。

Policy 含有 vob、element、policy 和 rolemap 四个部分，分别表明对于相应的对象类别，指定的 principal 具有何种访问权限。 Principal 分为 role、group、user 等类型，其中常以 role 来定义访问权限。而 rolemap 则指定了哪些用户(组)属于定义的 policy 中指定的 role。 Rolemap 和 policy 结合起来产生 effective ACL（简称 EACL）。针对每一个对象类别（即 vob、element、policy 和 rolemap），EACL 列出了授权的用户/组具有何种权限。

下文为创建 policy 和 rolemap 采用的文件（通过指定文件来创建 policy 或 rolemap），以及产生的对应的 EACL。

policy(element 部分)
[element]
Role:Testers Read
Role:Developers Change
Role:Administrator Full

Effective ACL(element 部分)

[element]
Group:your.domain/tester Read
Group:your.domain/develop Change
User:your.domain/admin Full

上述例子表示 tester 组对于应用此 rolemap 的 VOB 元素具有读权限，developer 组具有修改权限，而 admin 用户具有完全权限。当应用 ACLs 后，ClearCase 会在用户操作 VOB 数据的时候检查其是否具有相应的权限。更多关于 ACLs 的特点及使用方法，请参考 ClearCase 8.0.1 InfoCenter 。

与之前版本的 Multisite 环境相比，应用 ACLs 的 Multisite 环境中 VOB 副本的 preserving 模式对 ACLs 在多站点间的共享、使用有重要影响，而管理员也要更细致地计划如何根据需要在现有的 Multisite 环境中应用 ACLs。下文将结合实例说明。

ClearCase Multisite 场景介绍

实际生产环境的 ClearCase Multisite 千差万别，复杂多样。为了便于讲解，本文将通过一个相对简单的 ClearCase Multisite 实验环境来讲述如何应用 ACLs。对于更为复杂的 ClearCase Multisite 环境，同样可以参考本文并加以适当扩展。

图 1.CC Multisite 拓扑结构

如图 1 所示，本文 ClearCase Multisite 环境有三个站点，SiteA 为主站（Master Site），SiteB 和 SiteC 为从站（Replica Site）。站内机器通过局域网相连，站与站之间通过 Multisite Server 进行同步。

注：Rational License Server 与域服务器并未展示在拓扑图中。

表 1 列出了各个站点的具体信息。

表 1.CC Multisite 实验环境机器信息

表 1 所示的各个站点的 CC Server 均承担了多个 server components 的责任。在实际环境中，这些 server components 可由一个或多个单独的机器承担，如一个 site 中有多个 VOB Server，以及多个 CCRC WAN Server。同理，CC Client 可以是 Native Client，也可以是 CTE（CCRC） Client，可由一台机器或多台机器组成。由此整个环境可以从相对简单的拓扑结构扩展成适合客户生产环境的复杂结构（关于更为复杂的 Multisite 环境的升级，请参考文章“ClearCase 和 ClearQuest 集成、分布式、多站点复杂环境升级”）。而本文中的三个 site 可以视为精简的 CC Multisite 环境。

实验中的三个站点分别代表了不同的操作系统部署方式，SiteA 为 Windows 与 Linux（UNIX）混合的环境，SiteB 为 Windows 环境，而 SiteC 为 Linux（UNIX）环境。VOB 副本的 Preserving 模式对 ACLs 的行为有很大影响。

Identities- and permissions-preserving replica

Identities- and permissions-preserving 副本（简称为 preserving 副本）在同类的副本间维护相同的用户和组的信息，并且对 VOB 元素维护同样的 permission（mode bits，对于 owner/group/other 的读、写、执行权限）。若 VOB 副本为此种模式，任何对用户、组以及权限的更改都可同步到其它的 preserving 副本。而由于 policy 和 rolemap 要指定角色、用户或组，因而 preserving 副本能够高效地在 VOB family 中共享 policy 和 rolemap 的使用与管理。

Permissions-preserving replica

Permissions-preserving 副本仅在副本间维护 VOB 元素的 permission。对于 policy 和 rolemap，permissions-preserving 副本需要维护自己的用户和组的信息。并且对于 policy 和 rolemap 的任何改变也不会在 vob family 间共享。管理员必须对每个 permissions-preserving 副本单独定义 policy 和 rolemap。

Non-preserving replica

Non-preserving replica 既不在副本间维护身份认证信息，也不共享 VOB 元素的 permission。Non-preserving replica 要各自维护属于自己的用户/组与 permission。

由上述的三种模式可以看出，Permissions-preserving replica 和 Non-preserving replica 对于 ACLs 的行为模式有共同点，它们都需要维护自己的用户/组信息，管理各自的 policy 和 rolemap。从 ACLs 的角度而言，这两种副本都可以被称为 Non-preserving 副本，而 Identities- and permissions-preserving 副本被称为 Preserving 副本。本文中， SiteB 使用的是 Non-preserving 的副本，而 SiteC 则使用了 Identities- and permissions-preserving（即 preserving）副本。

若想将一个 Non-preserving 副本转化为一个 preserving 副本，请不要使用multitool chreplica命令实现。这个命令会生成与其他 preserving 副本不同的元数据。推荐的方法是创建一个新的 preserving 副本，并且移除原有的 non-preserving 副本。

阶段性升级到 ClearCase 8.0.1

本文采用阶段性升级策略，每个阶段包含一台或多台机器，对这些机器中的 ClearCase 产品升级。关于具体的升级方法，本文采用直接升级，即在原有安装版本的基础上，直接升级到新版本。

下文为阶段性升级的数据准备与具体步骤。

数据准备：在 SiteA 上创建 basevob（以 basevob 为例讲解），flevel 设为 6，schema 设为 54。在 SiteB 和 SiteC 上创建相应的副本。其中 SiteB 为 non-preserving 副本，SiteC 为 preserving 副本。

为了防止升级过程中由于操作失误或其他不可预测的原因导致数据损坏，请在升级之前备份数据，包括（但不限于）ClearCase 注册文件，VOB，View 以及 Web 配置数据，请根据需要裁剪。关于升级前数据备份，请参考文章“ClearCase 和 ClearQuest 集成、分布式、多站点复杂环境升级”。

升级步骤：

（1）将 SiteA 升级到 8.0.1

测试各个 Site 之间的数据同步

（2）将 SiteC 升级到 8.0.1

将各个 Site 的 VOB 副本的 Schema 版本升级到 80，并测试各个 Site 之间的数据同步

将各个 Site 的 VOB 副本的 Feature Level 升级到 7，并测试各个 Site 之间的数据同步

将 VOB Family 的 Feature Level 升级到 7，并测试各个 Site 之间的数据同步

（3）将 SiteB 升级到 8.0.1

将各个 Site 的 VOB 副本的 Feature Level 升级到 8，并测试各个 Site 之间的数据同步

将 VOB Family 的 Feature Level 升级到 8，并测试各个 Site 之间的数据同步

在升级后的实验环境中，各个 Site 有相同的 ClearCase 版本，以及统一的 schema version 80 和 Feature Level 8。这为下一步应用 ACLs 做好了准备。

应用 ACLs 示例

此部分主要介绍实验环境升级到 ClearCase 8.0.1 之后应用 ACLs 的注意事项，并提供了一个 ClearCase 8.0.1 Multisite 应用 ACLs 的使用实例。

应用 ACLs

为确保不会破坏数据，应用 ACLs 之前需完成对 VOB 的健康检查，具体请参考 Rational ClearCase 8.0.1 InfoCenter。而后用cleartool protectvob –enable_acls在 VOB 上应用 ACLs。请注意，一旦 VOB 应用了 ACLs 不能撤销，也不能返回到之前的模式。

在实际的企业级应用的多站点环境中，由于机器众多，环境复杂，各个站点的升级不能同时完成，需要分步进行。而应用了 ACLs 的 VOB 对 ClearCase Client(也包含 CCRC WAN Server)的版本有一定的要求，因此在升级前请做好计划。表 2 列出了 ClearCase 8.0.1 的 VOB Server 对不同版本的 ClearCase Client(也包含 CCRC WAN Server)的支持情况。

表 2.混合版本环境的兼容性

在 ClearCase 8.0.1 中新创建的 VOB 默认应用 ACLs，因此 ClearCase 8.0/7.1.2 Client 不能访问。如果需要在 8.0.1 上创建 Feature Level 为 8 的 vob，且能支持 ClearCase 8.0/7.1.2 Client 访问，则需要在创建 VOB 时先指定 Feature Level 为 7，再升级 Feature Level 到 8，并且不能应用 ACLs。

当计划在 VOB family 中创建新的副本时，请根据将要创建的新副本的 preserving 模式来选择从哪个副本创建。这是由于新副本会继承初始副本的特性（包括 ACLs）。如：从一个现有的应用 ACLs 的 preserving（即 Identities- and permissions-preserving replica）副本创建新的 preserving 副本，则新副本也是应用 ACLs 的；创建 permission-preserving 副本则可选择从现有的 Identities- and permissions-preserving 副本或 permission-preserving 副本创建；而创建 non-preserving 副本，则选择任意一个副本均可。对于后两种模式（permission-preserving and non-preserving），如果管理员想要为应用 ACLs，则需要单独为其配置 policy 和 rolemap。而这也是本文中 SiteB 需要做的。

如果管理员计划在 ClearCase 8.0.1 的 Multisite 的环境中使 VOB family 保持一种混合的状态，即一些副本应用 ACLs 而另外一些不应用，有以下两种方法：

方法 1：创建一个新的 VOB family，不应用 ACLs

由于 ACLs 一旦应用就不能取消，请在创建 VOB 时先指定 Feature Level 为 7，再升级到 8。管理员可以选择在创建 VOB 的副本前就升级 Feature Level 到 8，否则管理员必须在升级 VOB family Feature Level 前将所有副本的 Feature Level 先升级到 8。
一旦创建了未应用 ACLs 的 VOB，管理员可以开始创建 VOB 副本了。请至少保留 1 个 permission-preserving 或 non-preserving 的副本并且不要为其应用 ACLs，以便将来创建更多无需应用 ACLs 的 VOB 副本时使用。

方法 2：将已有的 Feature Level 为 7（或更低版本）的 VOB family 升级

在一个 preserving 副本（Identities- and permissions-preserving replica）上将 VOB family Feature Level 升级到 8（其它的 preserving 副本会有同样内容的缺省 policy 和 rolemap）。升级之后初始的 policy（DefaultPolicy）和 rolemap（DefaultRolemap）将会被创建，但是并不会应用 ACLs。之后对于要应用 ACLs 的副本，管理员可在其中一个 preserving 副本（如果 preserving 副本需要应用 ACLs）上创建需要的 policy 和 rolemap，以及每一个要应用 ACLs 的 permission-preserving 副本和 non-preserving 副本（对于那些不需要应用 ACLs 的 permission-preserving 副本和 non-preserving 副本，管理员无需创建 policy 和 rolemap）上创建 policy 和 rolemap。之后管理员可以在其中一个 preserving 副本上，以及其它要应用 ACLs 的副本上分别 enable ACLs。

ACLs 使用示例

此部分将以本文实验环境为基础演示升级之后的 ClearCase Multisite 环境如何应用 ACLs，以 base vob 为例讲述 policy 和 rolemap 的应用，以及如何配置不同 preserving 模式的 VOB 副本间的 ACLs，供用户参考。本例的前提条件为：

SiteA 为主站，VOB 副本为 preserving 副本；SiteB 的 VOB 副本为 non-preserving 副本；SiteC 的 VOB 副本为 preserving 副本。

各个 Site 已经升级到 ClearCase 8.0.1

各个 VOB 副本的 Feature Level 已经升级到 8

VOB family Feature Level 已经升级到 8（本实例的所有 VOB 副本都要应用 ACLs）

基于上述前提条件，本文进行了如下的尝试：

Step 1：应用 ACLs

在 SiteA 上用 vob owner user001 运行应用 ACLs 的命令，并查看 VOB 状态。

>cleartool protectvob –enable_acls vob_storage_dir_pname

如图 2 所示，应用 ACLs 后，VOB 默认被 DefaultRolemap 保护。DefaultRolemap 实现了 DefaultPolicy，它们是预定义的 rolemap 与 policy。

图 2.SiteA 上应用 ACLs 命令执行结果

Step 2：同步

将 SiteA 的变化同步到另外两个 Site 的 VOB 副本。在另外两个 Site 上用 vob owner user001 接收同步包。
SiteB 上为 non-preserving 的 VOB 副本，它接收同步包：

M:\MS_SiteB_testview1\MS_testvob1>multitool syncreplica –import –receive
Applied sync. packet C:\Program Files(x86)\IBM\RationalSDLC\ClearCase\var\shipping\ms_ship\incoming\
sync_SiteA_2013-07-30T18.16.22+08.00_23542 to VOB \\rcvmt111\ccstg_c\VOBs\MS_testvob1.vbs

通过查看 SiteB 上同步 VOB 的属性，可以看出该 VOB 并没有应用 ACLs，如下文粗体所示：

M:MS_SiteB_testview1\MS_testvob1>cleartool desc –l vob:\MS_testvob1
versioned object base “\MS_testvob1”
created 2013-07-30T14:27:33+08:00 by user001.cteuser@jrm-rhel6
protected by rolemap: “DefaultRolemap”
effective access for user “user001”: Full
master replica: SiteA@MS_testvob1
replica name: SiteB
………minimum client feature level: 5ACLs enabled: No………

因此需要在使用了 non-preserving 的 SiteB 上，再次运行 cleartool protectovb –enables来应用 ACLs。
SiteC 是 preserving(Identities- and permissions-preserving)副本，它接收同步包，请注意与上文中 SiteB 接收同步包的不同之处。

user001@jrm-suse10:/cc/vobs/MS_testvob1> multitool syncreplica –import –receive
This operation may take a long time to complete.
During this time, all policies and rolemaps will be locked as they are processed.
Applying ACLs to element containers…
Processed 3 element(s) associated with rolemap “DefaultRolemap”.
Applied sync. packet
/opt/rational/clearcase/shipping/ms_ship/incoming/sync_SiteA_2013-07-30T18.16.29+08.00_23548 to\
 VOB /net/jrm-suse10/cc/vobs/MS_testvob1.vbs

通过查看 SiteC 上 VOB 的属性，可以看出该 VOB 应用了 ACLs，如下文粗体所示：

user001@jrm-suse10:/cc/vobs/MS_testvob1> cleartool desc –l vob:/cc/vobs/MS_testvob1
versioned object base “/cc/vobs/MS_testvob1”
created 2013-07-30T14:27:33+08:00 by user001.cteuser@jrm-rhel6
protected by rolemap: “DefaultRolemap”
effective access for user “user001”: Full
master replica: SiteA@/cc/vobs/MS_testvob1
replica name: SiteC
………
minimum client feature level: 8ACLs feature level: 8
………

Step3：SiteA 上创建新的 policy/rolemap

在 Linux 和 Windows 混合的环境中(如本文的 SiteA)，请确保 policy 和 rolemap 中的 User 和 Group 可以被 Windows 系统和 Linux 系统识别为同样的名字，以避免存取 VOB 数据、显示或修改 ACLs 时发生错误。为节省篇幅，本文只列出 policy 的 VOB 和 element 部分文本。

部分 policy 文本

[vob]
Role:Administrator Full
Role:Developer Read
Role:Tester Read
[element]
Role:Administrator Full
Role:Developer Change
Role:Tester Read

rolemap 文本

Role:Administrator --> User:user001
Role:Developer --> Group:dev
Role:Tester --> Group:test

生成对应的 policy SiteA_Policy_Test 与 rolemap SiteA_Rolemap_Test（实现 SiteA _Policy_Test）。SiteA_Rolemap_Test 如下文所示（仅列出 contents 部分，便于与其他 Site 进行比较）:

[user001@jrm-rhel6 MS_testvob1]$ cleartool lsrolemap –l SiteA_Rolemap_Test
rolemap “SiteA_Rolemap_Test”
  ………
contents:
  Role:Administrator
    User:user001
  Role:Developer
    Group:dev
  Role:Tester
    Group:test
  ………

由于 SiteC 的 VOB 副本是 preserving 副本，在 SiteC 上创建用于所有 preserving 副本的 policy 和 rolemap 亦可。同理，可在任何一个 preserving 副本上修改 ACLs。但请注意要先获得 policy/rolemap 的 mastership。

Step4：Protect VOB object/element/policy/rolemap

本文中用刚刚产生的 rolemap SiteA_Rolemap_Test 来保护 VOB 以及 elements（也可以用它来保护 policy 和 rolemap，本文并未涉及）。

在保护 VOB elements 时，可以选择用命令cleartool protect –chrolemap RolemapName –recurse来保护当前 view 可见的所有 elements，这也正是本文所采用的方法。如果想要保护所有的 elements，则使用cleartool –find- all产生的结果，如

cleartool find –all –print | xargs --delim \\n cleartool protect –chrolemap SiteA_Rolemap_Test

Step 5：同步到 SiteB

SiteB 的 VOB 副本为 non-preserving 副本，因此虽然同步后的 SiteB 能够查看到 SiteA 新生成的 policy 和 rolemap，但是 rolemap 中用户与组的信息并没有被保留，如图 3 所示。

图 3.SiteB 上查看同步的 rolemap SiteA_Rolemap_Test

不仅如此，SiteB 中 VOB 以及 Element 并没有被 SiteA_Rolemap_Test 保护，它们仍旧被 DefaultRolemap 保护。这之后的其它 preserving 副本的 policy 和 rolemap 的改变也并不会被同步到 SiteB 上。管理员需要在 SiteB 上维护属于本 site 的 policy 与 rolemap，并进行相应的 protect 操作。

Step 6: 同步到 SiteC

SiteC 的 VOB 副本是 preserving 副本，因此利用cleartool lsrolemap –l SiteA_Rolemap_Test查看到的信息与 SiteA 相同，用户与组的信息被保留。下文为 SiteA_Rolemap_Test 的 contents 部分：

user001@jrm-suse10:/cc/vobs/MS_testvob1> cleartool lsrolemap –l SiteA_Rolemap_Test
rolemap “SiteA_Rolemap_Test”
………
contents:
  Role:Administrator
    User:/user001
  Role:Developer
    Group:/dev
  Role:Tester
    Group:/test
……

同时，SiteC 上的 VOB 以及 element 也被相应的 rolemap 所保护，与 SiteA 的权限相同，如下所示。

user001@jrm-suse10:/cc/vobs/MS_testvob1> cleartool desc –l vob:/cc/vobs/MS_testvob1
versioned object base “/cc/vobs/MS_testvob1”
  created 2013-07-30T14:27:33+08:00 by user001.cteuser@jrm-rhel6
protected by rolemap: “SiteA_Rolemap_Test”
………

在 SiteC 上修改 policy 或 rolemap 并同步到 SiteA，可以在 SiteA 上查看到 ACLs 的变化，相应的对 VOB/element/policy/rolemap 的保护也同样生效。

Step 7:在 SiteB 上创建独立的 policy/rolemap

由于 SiteB 的 VOB 副本为 non-preserving 副本，SiteB 需要建立自己的 policy 和 rolemap。本处只列出 policy 的 VOB 和 Element 部分。

如下为部分 policy 文本，相比于 SiteA，增加了 Integrator 的角色。

[vob]
Role:Administrator Full
Role:Integrator Change
Role:Developer Read
Role:Tester Read
[element]
Role:Administrator Full
Role:Developer Change
Role:Tester Read

如下为部分 rolemap 文本，相比于 SiteA，增加了 Integrator 角色的对应关系，且 Developer 和 Tester 角色对应的都是单一的用户，而非 SiteA 中的组。

Role:Administrator --> User:rsvt.cn.ibm.com/user001
Role:Integrator --> User:rsvt.cn.ibm.com/user002
Role:Developer --> user:rsvt.cn.ibm.com/dev1
Role:Tester --> User:rsvt.cn.ibm.com/test1

生成对应的 policy SiteB_Policy_Test 与 rolemap SiteB_Rolemap_Test（实现 SiteB_Policy_Test），如图 4 所示，并用其保护数据。

图 4.SiteB 上新创建的 rolemap SiteB_Rolemap_Test 描述

很明显保护 SiteB 的 ACLs 与 SiteA 的 ACLs 有差别。管理员可以在 preserving 的副本与 non-preserving 的副本间设计不同的 ACLs 以满足需要。当同步 SiteB 的变化到 SiteA 时，SiteA 能够显示出 SiteB 里新创建的 policy SiteB_Policy_Test 和 rolemap SiteB_Rolemap_Test。但 SiteA VOB 数据的 ACLs 并没有变化。

本部分描述了一个 ClearCase Multisite 环境中 preserving 副本和 non-preserving 副本共存的条件下应用 ACLs 的简单实例，供用户参考。而实际生产环境相对复杂，管理员可以采取更为复杂的 ACLs 来达到精密控制的目的。例如，管理员可以用一套 policy/rolemap 来保护 VOB、policy 和 rolemap，而用另一套或多套的 policy/rolemap 来保护 VOB elements。

结束语

为了便于现有的 ClearCase Multisite 环境能够升级到 ClearCase 8.0.1，并应用 ACLs 来实现更灵活的权限管理，本文以一个简单的 ClearCase Multisite 环境为例，讲述了升级到 ClearCase 8.0.1，并应用 ACLs 的过程以及注意事项。并较详细的阐述了在 Multisite 环境中，如何在 preserving 副本与 non-preserving 副本之间使用 ACLs。旨在为用户应用 ACLs 提供一定参考。