使用AFS, Active Directory和SSSD搭建用于集成电路设计的分布式存储系统 【十五】部署第一台 AFS 服务器 4

配置第一台 AFS 服务器：客户端的配置

我们在这里只对 AFS 客户端（Cache Manager）做最少的配置，使得系统管理员可以登录客户端进行维护和管理操作。

我们将在今后的章节里进一步介绍一台完整的客户端的配置（比如一台 EDA 设计服务器）。需要注意的是，EDA 设计服务器一般需要允许所有合法的 AFS 用户登录和使用。而我们不希望普通用户登录 AFS 服务器，所以对AFS 服务器上的客户端配置，系统管理员应该跳过 SSSD 的配置步骤，甚至限制这些服务器上的 SSH 服务，以保证只有系统管理员可以登录这些服务器。

客户端 CellServDB

在前文中我们已经解释过客户端 CellServDB 文件的作用。我们推荐客户端通过 DNS 查询的方式获得 Database Server 的地址，为了实现这一点，客户端 CellServDB 文件需要做一些特别安排。

对我们的例子，客户端 CellServDB 文件的地址是

/etc/openafs/CellServDB

这个文件在每次系统重启时都会被自动删除和改写，因此手动更改这个文件是没有效果的。

仔细阅读

/usr/lib/systemd/system/openafs-client.service  

就可以发现类似如下语句：

ExecStartPre=/bin/sed -n 'w/etc/openafs/CellServDB' /etc/openafs/CellServDB.local /etc/openafs/CellServDB.dist

这意味着该服务脚本在每次加载 AFS Client 程序之前会有一个预备操作，这个预备操作的内容是将以下两个文件的内容衔接在一起以后覆盖 /etc/openafs/CellServDB 文件的内容：

/etc/openafs/CellServDB.local
/etc/openafs/CellServDB.dist

其中 CellServDB.dist 包含许多公开注册于互联网的诸多研究机构的 Cell，而 CellServDB.local 则是供客户端系统管理员订制的 CellServDB 文件内容。

正是因为有如上操作的存在，所以手动修改 CellServDB 文件是没有效果的。系统管理员应该修改的是 CellServDB.dist 和 CellServDB.local 这两个文件。

如果管理员不希望客户端的用户访问互联网上的其他 AFS Cell，可以将 CellServDB.dist 的内容删除，使之变成一个空文件。

如果管理员希望添加自己新建的 Cell 的信息，则可以将这些信息添加到 CellServDB.local 文件里。

对我们的例子，我们希望生成的 CellServDB 文件只包含新建 Cell 的信息，因此我们将 CellServDB.dist 的内容删除使之成为一个空文件，然后更新 CellServDB.local 文件。

我们应该往 CellServDB.local 里写入什么信息呢？

OpenAFS 规定，如果希望 Cache Manager 使用 DNS 方式获得 Database Server 的信息，则客户端 CellServDB 文件里只能包含 Cell 的名称信息，而不能包含任何一台Database Server 的 IP 地址。因此我们的 CellServDB.local 文件应该只有一行内容，如下所示：

[xmsguan@afsdb1 openafs]$ cat CellServDB.local
>hq.company.com        #Cell name

读者可以对照修改自己的 CellServDB.local 文件。注意我们这里修改的是客户端相关的CellServDB 文件，它们存储在

/etc/openafs

目录下，而不存储在

/etc/openafs/server

目录下。

另外需要注意，AFS 对 CellServDB 文件有十分严格的格式要求。比如文件末尾不能有多余的回车或空行，大于号（>）与 Cell 名称之间不能有任何空格。

在做出上述修改前，系统管理员应该保证已经遵循本文之前的步骤验证过 DNS SRV 记录已经生效。

客户端 ThisCell

与 CellServDB 文件分为服务器端和客户端类似，ThisCell 文件也分为服务器端和客户端。如果读者按照我们的推荐 使用了 jsbillings 编译的安装包，则客户端 ThisCell 文件存储于

/etc/openafs/ThisCell

我们解释过一台 AFS 客户端（Cache Manager）可以同时连接多个 AFS Cell。客户端 ThisCell 的作用是指定 Cache Manager 默认连接的 Cell.

对于我们的例子，ThisCell 显然是我们新建的 Cell，因此其内容和服务器端的 ThisCell 地址是完全一致的。既然我们正在配置的是 AFS 服务器，我们可以直接将服务器端的 ThisCell 文件拷贝到客户端 ThisCell 文件位置，如下所示

[xmsguan@afsdb1 openafs]$ sudo cp server/ThisCell ./ThisCell
[xmsguan@afsdb1 openafs]$ cat ThisCell
hq.company.com[xmsguan@afsdb1 openafs]$

至此我们就完成了客户端 CellServDB 文件和 ThisCell 两个基本配置文件的设置。

值得留意的是，今后每一台隶属于这个 Cell 的 AFS 客户端（Cache Manager）都需要 CellServDB.local 文件和 ThisCell 文件。因此 AFS 系统管理员可以将这两个文件的最新版本保存在一个可靠的地方，供 AFS 客户端的用户下载使用。

配置 cacheinfo 文件

Cache Manager 启动时所需最重要的信息除了 Cell 的名称和 Database Server 的地址以外就是本地缓冲区的位置和大小。我们在安装操作系统时已经为客户端预留了 缓冲分区，现在是时候将这个缓冲区的地址告诉 Cache Manager 了。这同样是通过一个文本配置文件实现的，这个文件的名称是 cacheinfo。

对于使用 jsbillings 编译的OpenAFS安装包的情况，该文件在 CentOS 7 下的路径是

/etc/openafs/cacheinfo

检查该文件的内容，可以看到如下信息：

[xmsguan@afsdb1 openafs]$ cat cacheinfo 
/afs:/var/cache/openafs:100000
[xmsguan@afsdb1 openafs]$

可以看到，缓冲区路径的预置值是 /var/cache/openafs，正好是我们预留的缓冲区的挂载路径。如果读者预留的缓冲区挂载在其他路径，则现在应该修改此处的路径，指向正确的挂载路径。

最后一个冒号后的数字 100000 设定了 Cache Manager 可以使用的缓冲区的最大值，其单位是 KB. 默认值大约是 100 MB. 如果系统管理员预留了更大的缓冲分区，可以扩大这个数字的值，以便 Cache Manager 可以充分利用缓冲区的空间。

-dynroot, -afsdb 以及其他 afsd 参数

Cache Manager 还有一些其他启动参数，这些参数通过以下文本文件配置：

/etc/syconfig/openafs

检查其内容，可以看到一些默认值：

[xmsguan@afsdb1 openafs]$ cat /etc/sysconfig/openafs
# OpenAFS Client Configuration
AFSD_ARGS="-dynroot -fakestat -afsdb"

# OpenAFS Server Configuration
BOSSERVER_ARGS=

这些默认值和我们的需求没有冲突。它们的具体意义在 OpenAFS 的文档里有具体解释。
https://docs.openafs.org/Reference/8/afsd.html

目前我们可以不修改这些参数的值，保持上述配置文件不变。我们将在设置 AFS 顶层目录时回来讨论 -dynroot 参数的意义和影响。

注意 -afsdb 这个参数应该作为默认启动参数用于所有现代 AFS 部署的客户端，这个参数使得 Cache Manager 通过 DNS 查询来获得 AFS Database Server 的地址。

启动客户端服务

在前面的步骤里我们已经展示过，AFS 客户端安装包安装了一个服务脚本，用于在系统启动时加载Cache Manager 的内核模块并启动服务进程。在完成之前的配置步骤以后，现在可以开启此服务。

对于 CentOS 7，操作示例如下：

[xmsguan@afsdb1 ~]$ sudo systemctl enable openafs-client.service
[sudo] password for xmsguan:
Created symlink from /etc/systemd/system/multi-user.target.wants/openafs-client.service to /usr/lib/systemd/system/openafs-client.service.
Created symlink from /etc/systemd/system/remote-fs.target.wants/openafs-client.service to /usr/lib/systemd/system/openafs-client.service.
[xmsguan@afsdb1 ~]$ sudo shutdown -r now

可以看到要使服务生效必须重启系统，因为需要重新加载内核模块。

重启系统以后系统管理员应该使用 systemctl status 命令查看该服务的运行情况。同时系统管理员也应该使用之前步骤里提到 的 lsmod 命令检查内核模块的加载情况，确认 openafs 模块已经加载。

如果一切正常，就可以使用已经创建的管理员账号登录 AFS 客户端了。

登录 AFS 客户端

现在终于到了联合测试客户端与服务器端的时候。我们将用已经创建的 AFS 系统管理员账号登录刚刚配置和重启完毕的 AFS 客户端。

登录 AFS 的最基本方式分为两步

1. 使用 kinit 命令进行 Kerberos 身份验证
2. 使用 aklog 命令获取 AFS token

具体操作过程如下：

[xmsguan@afsdb1 ~]$ kinit xguanafsadmin
Password for xguanafsadmin@AD.COMPANY.COM:
[xmsguan@afsdb1 ~]$ aklog -d
Authenticating to cell hq.company.com (server afsdb1.test.company.com).
Trying to authenticate to user's realm AD.COMPANY.COM.
Getting tickets: afs/hq.company.com@AD.COMPANY.COM
Using Kerberos V5 ticket natively
About to resolve name xguanafsadmin to id in cell hq.company.com.
Id 2001
Setting tokens. xguanafsadmin @ hq.company.com
[xmsguan@afsdb1 ~]$

在上面的例子里，xmsguan 是一个Linux 的本地用户，这个用户在初始情况下和 AFS 没有任何关系。为了获得 AFS 管理员权限，这个本地用户必须以 AFS 管理员账号 xguanafsadmin 通过 Kerberos 身份验证。这通过 kinit 命令实现。在验证密码以后，本地用户 xmsguan 就获得了 KDC 颁发的 Kerberos Ticket. 之后该用户执行 AFS 的 aklog 命令，获得 AFS token. 我们在例子里使用了 -d 参数，以显示更多的登录细节。可以看到，新建的 Cell 认可了 xmsguan 转交的 ticket，将其解析成了 AFS ID 是 2001 的 AFS 用户，即 xguanafsadmin.

此时可以进一步用 AFS 命令 tokens 来查看获取的 AFS token 的细节：

[xmsguan@afsdb1 system]$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 2001) rxkad tokens for hq.company.com [Expires Jun  1 16:28]
   --End of list--
[xmsguan@afsdb1 system]$

看到以上信息以后系统管理员即可确认服务器端和客户端的配置已经顺利完成。

设置 AFS 顶层目录

AFS 的第一台服务器已经上线，客户端也已经启用，但是 AFS 的顶层目录还没有设置好。我们在这一节里讨论顶层目录的创建。

挂载第二层目录

我们在前文介绍第一台 AFS 服务器的安装步骤 里已经创建了对应于最顶层两级目录的 AFS Volume, 分别是 root.afs 和 root.cell.

root.afs 对应的目录是 /afs。作为一个特殊的 AFS Volume，它不需要挂载。

root.cell 对应的目录是

/afs/cellname

对于我们的例子，其路径是

/afs/hq.company.com

我们需要将 root.cell 挂载到这个路径下。也就是说，我们需要改写 root.afs 的内容，在 root.afs 这个 Volume 下的第一层目录里，创建一个指向 root.cell 的挂载点。

挂载一个 AFS Volume 的命令是 fs mkmount. 但是我们目前的情况十分特殊，不能直接使用这个命令。为什么呢？这和前一节里我们给 Cache Manager设定的一个参数有关，这个参数是 -dynroot.

早期 AFS 版本的客户端没有 -dynroot 参数。当用户的客户端作为内核模块和系统一起启动时，需要通过网络查询到 root.afs 这个 AFS Volume 以后才能将其挂载在 /afs 路径下。

查询的是哪个 AFS Cell 的 root.afs 呢？是客户端 ThisCell 文件指定的 Cell 的 root.afs.

这在用户网络不稳定的情况下产生了一些不便。比如当用户的笔记本处于旅行状态没有网络访问时，系统启动就可能因为联系不到 root.afs 而产生延时。

另外当用户列举 /afs 下第二层目录时，如果网络不稳定且 root.afs 的内容没有缓冲在本地，仅仅为了访问另一个 cell，就需要传输 root.afs 的所有二级目录，也会产生延时影响体验。

基于以上原因，AFS 的开发者创造了 -dynroot 参数。这个启动参数存在时， Cache Manager 不再通过查询 root.afs 的内容来决定 /afs 下的二级目录，而是通过客户端 CellServDB 文件的内容来“动态合成” /afs 下二级目录的内容。只有当用户继续深入 /afs/cellname 时，Cache Manager 才会联系相应 Cell 的 root.cell 来查询获得三级目录的内容。

因为绕过了 root.afs 这个 AFS Volume, 客户端启动就不再需要通过网络查询 AFS File Server，而可以迅速完成 /afs 路径在客户端操作系统下的挂载。用户列举 /afs内容的速度也不再取决于查询 root.afs 的速度，而完全由访问本地客户端 CellServDB 文件的速度决定。这就避免了上述例子带来的影响。

在绝大多数使用场景下，-dynroot 参数对用户体验都能产生正面影响。

-dynroot 的使用虽然加速了 /afs 下内容的列举，但也会产生其他副作用。其中一个影响是，客户端 /afs 下的内容不再受到 AFS 系统管理员的控制。

举一个夸张一些的例子，AFS 系统管理员在 root.afs 下可能设置了 30 个 Cell 的挂载点，除了一个是自己这个 Cell 的挂载点，其余 29 个指向其他友好 Cell 的 root.cell。而客户端 CellServDB 文件里可能只定义了两个 Cell。因为使用了 -dynroot 参数，Cache Manager 不会查询 root.afs 的内容而自己合成 /afs 下的目录列表，所以使用该客户端的用户就只能访问这两个 Cell 的内容。

取决于用户诠释问题的角度，上面这个例子也可以作为正面影响来看待。因为用户 /afs 路径下的路径得到了简化和加速。在不影响安全的情况下，我们将自由度交给了用户。

使用 -dynroot 的另一个影响是，即使 AFS 系统管理员还没有初始化 root.afs 的内容，Cache Manager 仍然会根据客户端 CellServDB 的内容显示二级目录的存在，让用户产生 root.afs 已经具有挂载点的“错觉”。我们的 Cell 部署就处于这个状态。

因为我们在Cache Manager的启动参数里保留了 -dynroot，当我们进入 /afs 目录时，Cache Manager 不会和 root.afs 建立联系。当我们使用 ls 命令时，就会发现二级目录 hq.company.com 已经存在。当我们试图用 fs mkmount 命令改变 root.afs 下的挂载点时，就无法实现目的。这不是因为我们的 AFS 部署产生了错误，而是因为 -dynroot 为我们合成了二级目录的“假象”。

作为 AFS 系统管理员，我们还是需要给 root.cell 创建真正的挂载点，而且在创建正常挂载点的同时，还需要创建一个隐藏的 rw 型挂载点。我们在前文介绍 AFS 的路径偏好规则时已经详细介绍过原因。

如何在不删除 -dynroot 参数的情况下方便地做到这一点呢？在同一篇前文的最后我们也介绍了相应的技巧，即在二级目录下为一级目录对应的 root.afs 临时创建一个额外的挂载点。

感兴趣的读者还可以了解另一个解决办法，即 /afs/.:mount 目录的工作机制（https://docs.openafs.org/Reference/8/afsd.html）。我们则在下面的例子里使用前文提到的技巧。

首先在二级目录下为一级目录对应的 root.afs 创建一个临时的挂载点，叫做 temp

[xmsguan@afsdb1 afs]$ ls /afs/hq.company.com/
[xmsguan@afsdb1 afs]$ fs mkmount /afs/hq.company.com/temp root.afs -rw
[xmsguan@afsdb1 afs]$ ls /afs/hq.company.com/
temp
[xmsguan@afsdb1 afs]$ fs lsmount /afs/hq.company.com/temp
'/afs/hq.company.com/temp' is a mount point for volume '%root.afs'
[xmsguan@afsdb1 afs]$

现在我们可以通过访问

/afs/hq.company.com/temp 

来访问 root.afs 的内容，我们可以使用 fs mkmount 命令将 root.cell 挂载在它下面:

[xmsguan@afsdb1 afs]$ fs mkmount /afs/hq.company.com/temp/hq.company.com root.cell
[xmsguan@afsdb1 afs]$ fs mkmount /afs/hq.company.com/temp/.hq.company.com root.cell -rw

我们创建了两个挂载点，一个正常的挂载点，一个 rw 型挂载点。读者在此时可以继续创建指向其他 Cell 的挂载点, 也可以为 hq.company.com 创建更简短的符号链接。

接着我们需要为这个目录设置访问权限。如果我们什么都不做，直接查看这个目录的访问权限（使用命令 fs la），可以看到下面的内容：

[xmsguan@afsdb1 ~]$ fs la /afs/hq.company.com/
Access list for /afs/hq.company.com/ is
Normal rights:
  system:administrators rlidwka
[xmsguan@afsdb1 ~]$

上面结果的意思是，/afs/hq.company.com/ 目录除了系统管理员可以访问外，其他所有人都无权访问，甚至连 “cd” 或者 “fs la” 命令都不行。

这显然不是我们希望的。我们希望所有合法的 AFS 用户都能访问 AFS 空间下得到授权的内容。根据我们在前文对 “l” 权限的介绍，我们至少应该保证 system:authuser 组的用户对第二层目录具有 “l” 权限。因此我们使用 fs sa 命令更改第二层目录的 ACL:

[xmsguan@afsdb1 ~]$ fs sa /afs/hq.compnay.com/temp/hq.company.com/ system:authuser l
[xmsguan@afsdb1 ~]$ fs la /afs/hq.company.com/
Access list for /afs/hq.company.com/ is
Normal rights:
  system:administrators rlidwka
  system:authuser l
[xmsguan@afsdb1 ~]$

做完这些，就可以“过河拆桥”，删除临时挂载点了：

[xmsguan@afsdb1 afs]$ fs rmmount /afs/hq.company.com/temp

这是我们可以使用 fs lsmount 命令来查询两个二级目录的性质，确定它们确实已经存在：

[xmsguan@afsdb1 afs]$ fs lsmount /afs/hq.company.com
'/afs/hq.company.com' is a mount point for volume '#hq.company.com:root.cell'
[xmsguan@afsdb1 afs]$ fs lsmount /afs/.hq.company.com
'/afs/.hq.company.com' is a mount point for volume '%hq.company.com:root.cell'
[xmsguan@afsdb1 afs]$

可以看到，两种类型的挂载点都已经出现在一级目录以下。常规挂载点用 # 号代表，而 rw 型挂载点用 % 号代表。至此，二级目录就创建完毕。

本小节使用相当篇幅解释了 -dynroot 存在下创建二级目录挂载点的方法。其中涉及的知识和技巧在一个 Cell 正常运转时几乎不会用到。用户也很少察觉到它们的影响。这个技巧性的操作在 Cell 的部署过程中几乎是一次性的步骤，用过以后就不再需要重复。因此不是 AFS 系统管理员需要记住和常常使用的技术。但是 fs mkmount、 fs rmmount 和 fs lsmount 将是 AFS 系统管理员频繁使用的命令。它们相当于针对挂载点的 “mkdir”, “rm -r” 和 “ls -l” 命令。

创建顶层 Volume 的只读副本

我们在前文介绍了 AFS Volume 的只读副本的工作原理，并且在 AFS 的路径偏好一节 里指出了顶层目录对应的 Volume 必须创建只读副本。现在我们将在第一台 AFS 服务器上为 root.afs 和 root.cell 这两个 AFS Volumes 创建只读副本。

我们将分两步进行。第一步，在第一台 AFS 服务器上创建只读副本，这由命令 vos addsite 实现。

[xmsguan@afsdb1 afs]$ vos addsite afsdb1.test.company.com a root.afs -verbose
Adding a new site ... done
Added replication site afsdb1.test.company.com /vicepa for volume root.afs
[xmsguan@afsdb1 afs]$ vos addsite afsdb1.test.company.com a root.cell -verbose
Adding a new site ... done
Added replication site afsdb1.test.company.com /vicepa for volume root.cell

注意上面示例中，vos addsite 后的第一个参数是服务器地址，第二个参数（字母 a）代表分区名。在我们的例子里分区是 /vicepa，AFS 允许将其简称为 a.

上述步骤只是在 Volume Location Database 里创建了记录，并且在 AFS 服务器上预留了只读副本的记录，但只读副本还没有更新。

第二步，通过 vos release 命令更新只读副本的内容。

[xmsguan@afsdb1 afs]$ vos release root.afs -verbose

root.afs
    RWrite: 536870912
    number of sites -> 2
       server afsdb1.test.company.com partition /vicepa RW Site
       server afsdb1.test.company.com partition /vicepa RO Site  -- Not released
This is a complete release of volume 536870912
Creating a new permanent RO clone 536870913 ... done
Getting status of parent volume 536870912... done
Starting transaction on RO clone volume 536870913... done
Setting volume flags for volume 536870913... done
Ending transaction on volume 536870913... done
Replacing VLDB entry for root.afs... done
Starting transaction on cloned volume 536870913... done
updating VLDB ... done
Released volume root.afs successfully
[xmsguan@afsdb1 afs]$

上述示例完成了 root.afs 的更新。采用同样的命令可以更新 root.cell，其执行过程完全类似：

[xmsguan@afsdb1 afs]$ vos release root.cell -verbose

root.cell
    RWrite: 536870915
    number of sites -> 2
       server afsdb1.test.company.com partition /vicepa RW Site
       server afsdb1.test.company.com partition /vicepa RO Site  -- Not released
This is a complete release of volume 536870915
Creating a new permanent RO clone 536870916 ... done
Getting status of parent volume 536870915... done
Starting transaction on RO clone volume 536870916... done
Setting volume flags for volume 536870916... done
Ending transaction on volume 536870916... done
Replacing VLDB entry for root.cell... done
Starting transaction on cloned volume 536870916... done
updating VLDB ... done
Released volume root.cell successfully
[xmsguan@afsdb1 afs]$

至此，顶层目录的创建就完成了。

从此处开始，AFS 系统管理员可以决定三级目录是常规目录还是新的挂载点，并继续创建三级和更多级目录，展开 AFS Cell 的建设。而第一台 AFS 服务器的配置至此就完成了。

AFS 系统管理员之后需要进行的操作包括增加第二台 AFS Database Server，或者增加更多的 AFS File Server。在 Cell 已经上线和正常运转的情况下，这些操作的难度比起第一台服务器的上线低许多，也不再需要额外的知识。

之后的文章里我们将介绍作为 AFS 客户端的集成电路设计服务器应该如何部署。