【山大智云】SeafileServer源码分析之用户与用户组

2021SC@SDUSC

用户与用户组

Seafile支持用户与用户组，包含一个用户与用户组管理系统。而这个子系统也被另一个项目复用：ccnet-server，它是Seafile服务器的内部通信框架和用户/组管理。由于这个项目关于用户与用户组子系统方面比seafile-server更全面，所以我们主要基于该项目进行介绍。这篇文章主要介绍后者，即用户与用户组管理；前者内容属于RPC，下面会涉及到一点。

Ccnet-server中当然还有进程间通信，例如对等体识别、连接管理、服务调用、消息传递等，而这些内容属于协议，在seafile : librpc 分析中可以找到。

• Ccnet

  指的是RPC协议下的用户集群。Ccnet包含唯一的服务端，以及多个客户端。服务端（ccnet-server）负责管理用户与用户组。客户端也被称为协议对等体，向服务端发起RPC。

用户与用户组中分为三个层次结构：用户、群组、组织。用户与用户组管理就是对这三个层次的结构进行维护。

三个层级依次递进，所管理的用户数量的数量级逐级递增。

这三个层次的相关信息可以很方便地用关系模型描述，并且需要统一在同一个数据库下进行维护，所以这个系统的数据持久化主要基于关系型数据库。

用户

用户与用户组中的一个个体，即一个用户。用户之间存在沟通和联系，但这不是用户与用户组管理的关键。用户与用户组管理主要做的是对用户信息进行维护，至于怎样将信息在用户与用户组内部进行协调，用户与用户组管理一概不关心。

用户管理的ER图如下：

用户的信息包括基本的id、邮箱、密码等。另外有两个标签：is_staff代表是否是管理员，is_active代表目前是否活跃。

用户绑定对等体

用户与用户组中出现了一个特殊名字，叫做对等体。我们都知道对等体之间通过协议来通信或协调其他工作，例如seafile中以自身实现的rpc协议来进行rpc操作。对等体的概念在RPC中频繁涉及，从狭义角度理解，对等体就是相对于服务端的RPC中的客户端，以peer_id、peer_ip、peer_port区分。其中peer_id区分了每个RPC连接（实际使用的是用户设备id），也就是说peer_id能区分每个RPC中的用户，因此采用一个绑定关系Binding来将peer_id与用户关联，即把RPC连接与请求连接的用户关联。

（对等体的内容在seafile-server的开源内容中只有声明没有实现，可能不开源；或者说在社区版中没有用到此项技术。上述结论来源于ccnet-server）

角色

用户可能扮演多个角色，因此创建了另外一个实体UserRole来表示用户当前的角色。这些角色并不是预定义的，可由开发者通过用户与用户组的功能自定。

用户管理操作

由于用户管理重点是对用户信息进行管理，所以内容就是增删查改。详细信息见user-mgr.h。

群组

将多个用户进行集中式管理，每个用户属于一个群组。ER图如下：

群组结构

群组的结构是一棵树（对应了集合的包含关系），根被称为顶级群组，每个群组都有一个指向父群组的指针。更方便的，通过一个字符串路径能够唯一确定一个群组，这个信息以实体GroupStructure表示。

群组管理操作

群组管理中除了对群组自身进行操作，还要设计到群组中用户的操作，内容依旧是增删查改。详见group-mgr.h。

组织

将多个群组进行集中式管理，每个群组属于一个组织。ER图如下：

组织就是一个用户与用户组。与组织相关的关系和实体中描述了组织中包含的用户、群组的信息。

组织管理操作

内容与群组类似，但并不关心群组和用户间的具体关系，重点关注组织和用户、组织和群组间的关系。具体内容详见org-mgr.h

用户与用户组架构

通过源码，我们能总结出上述内容所实现的用户与用户组架构。一个最基本的线索就是包含关系：群组是用户的集合、组织是群组的集合。这个关系也是我们从ER关系中作出的直观推断。实际上这里实现的用户与用户组的结构也正是如此：分层架构。

现在我们已经知道了分层这样一个关系，现在思考为什么要进行分层。

首先，用户与用户组内还存在一个关系，那就是管理。管理显然是不可或缺的，因为有时候在可进行可靠交互时，必须引入第三方。但用户与用户组的管理同样也是个问题，它与管理的规模挂钩。而用户与用户组管理的分层架构，恰好体现了分而治之的思想。试想一下，如果全部交由一个中心用户来管理所有其他用户，那么中心用户的负载将会过大。于是分层架构中就诞生了群组的概念，将各个群组分摊给一些管理员，群组管理员管理群组内的用户。那么谁来管理管理员，于是需要一个级别更高管理员，来管理用户与用户组内其他所有管理员和所有用户。如果这些管理员负载也太大了，那么就进一步分为更小的群组，这也就是群组间呈现的树状关系。

为了方便管理，并且考虑到用户与用户组的动态性，我们需要将用户与用户组实体化，并在持久化部件中进行维护。这个时候又有问题了，谁来实体化？于是引入创建者的概念。一个群组由某个用户进行创建，并将其持久化，这个用户被称为创建者。

现在我们重新考虑用户与用户组内部的各种关系，包括管理与创建关系，从用户开始向上递推，于是我们得到了更加清晰的描述：

上图也就是对用户与用户组管理的总结。