刚过大雪，公司的接入设备就给我一记闷棍，突然硬盘咔咔作响，表达自己的残喘。让人想起教父去探望的那个家族军师。

那台小服务器上，运行着挺重要的三个服务：DNS、LDAP、VPN。DNS 好弄一点；LDAP 比较麻烦的是各人的密码都得再重新设置；VPN 的恢复主要是得分发新的配置文件。

全部搞定之后（包括让所有的小伙伴在 LDAP 都设置好自己的密码，与之前保持一致的话，会减少浏览器登录障碍），发现了个问题，某个同学无法登录 GitLab，但其他平台都可以。具体给出的错误信息是：

Could not authenticate you from Ldapmain because “Undefined method ‘provider’ for nil:nilclass”.

网上检索，有一个说他的这个问题在升级了 GitLab 之后就解决了。公司的网络，不提也罢。反正就是 apt 永远无法成功更新 gitlab-ce，使用的源已经是清华的了，也无济于事。270MB 的下载量，偶尔一次都到了 240MB 左右，还是前功尽弃了。之后再试，往往就两三兆字节后就没流量了。最后还是手动在网上找到了 .deb 包后下载完成。升级安装的过程并不顺利，因为我对 PostgreSQL 的配置进行过定制，而升级过程中应该是会执行 gitlab-ctl reconfigure 或者等价指令，导致对 PostgreSQL 数据库的访问许可规则变回默认而无法连接。手忙脚乱把访问规则再次配置好以后，冷静考虑了一下，不再盲信此 LDAP 认证问题可以经由升级 GitLab 而解决。

上面牵涉到数据库反而给了我一个启示，想搞清楚 GitLab 是如何使用用户输入的凭据以及相关配置与 LDAP 进行交互的。用酷酷的 TablePlus 连接到 PostgreSQL，查看 GitLab 的各个表。首选当然是 users 表，仔细观察了若干条记录，并未发现不能正常登录的这个用户的数据记录与其他可以正常登录的用户记录有任何足以影响 LDAP 认证的差异。停滞了一阵后，琢磨着会不会还会有其他关联表？三百多张表的表名，逐个看下来，发现有张表叫 identities，相当可疑。点开一看，一排 LDAP 风格的描述串跳入眼中，果然，其他正常用户的认证，用户名关联的是 cn 域，而不正常的这个用户，其用户名关联的是 uid 域。直接就地编辑，将 uid 改为 cn 后提交，问题解决。