Box云盘服务事故报告

发布者:发布时间:2023-10-19浏览次数:10

近期,大量Box云盘box.nju.edu.cn用户发现无法登入云盘(协同表格table.nju.edu.cn也有此情况),但是统一身份认证管理页authserver.nju.edu.cn登录正常。对大家近期的科研、教学、工作造成困扰,eScience中心首先对大家说声对不起。

好消息是经过信息化建设管理服务中心的紧张维修,目前Box云盘和协同表格对接的统一身份认证终于恢复正常。

如果突发类似的无法登录情况,可以尝试的临时措施如下:

如果用户正在登录着客户端,右键客户端的资料库选择在网页打开,也可进入云盘的网页端。图片如果之前没有登录过网页端的,尝试在网页端/客户端多次登录,其中网页端无论成不成功,记住勾选保持登录,之后不要退出登录图片

以下是本次情况的事故报告:


  • 云盘是如何对接统一身份认证的?

  • 云盘为什么采用这种方式认证?

  • 为什么近日登录认证一直失败?

  • 未来如何打算?

  • 为什么要等升级?深度定制不行吗?



>_事故报告

本着透明公开的态度,eScience中心详细总结、反思了云盘服务从开始至今的运维状况,供大家监督。

§云盘是如何对接统一身份认证的?

用户可能不太明白,也无法显式地看见,eScience中心的部分服务是如何与学校的统一身份认证对接的。

在用户的直接感觉上,很多校内系统的账号密码都是完全和统一身份认证一致的,一个能登大家全部都能登,似乎“统一身份认证”只有一种登录方式——

图片
用户可能认为的认证过程

事实上,由于各种历史原因和实际业务需要,虽然每个人的统一身份认证数据只有一个,但并非所有系统和软件都是同一种接入统一身份认证的方式

细心的用户现在一定能举出一些例子,它们使用统一身份认证账户密码,但是又不太像网上服务大厅ehall.nju.edu.cn一样,登录的时候弹出一个扫码界面。

有过出国经历的师生可能头疼过旅行插座的问题:各个国家的插座规范不一样,有些通用有些比较独特,自然就产生了这样一个“转接”的需求——

图片
一个典型的旅行插头

统一身份认证在这里也是一样,对于其便利性、安全性的愿景,自然是要大家一起花点功夫去把不同厂家的平台慢慢磨合的。

况且,有一些认证方式早在业界形成了行业规范或者行业习惯,适用范围广,第三方的软件设计之初就优先适配了它们,毕竟他们最开始也不是只想面向某一个学校

那么Box云盘是怎么样一个接入统一身份认证的方式呢?目前,受于各种原因,仅可支持LDAP

图片
实际的登录过程

学校提供给eScience中心有两个LDAP服务器,目前,云盘的多个节点会随机访问这两个服务器之一来实现LDAP认证。

§云盘为什么采用这种方式认证?

首先Box云盘box.nju.edu.cn(即Seafile) 从2017年开始正式上线服务(但未对全校开放,只有少数院系可用) ,当时学校的统一认证平台仅支持LDAP和CAS。其中CAS为非标版本,仅支持.net/java/php。而Box云盘核心与现今很多流行的软件一样,采用C和Python开发,无法支持该非标CAS协议

图片
TIOBE 指数排行榜(2023.10)

而且在Box云盘设计之初,就考虑到科研等用途,需要以命令行cli无头headless的形式使用,这种场景下CAS也无法支持

图片
完善的跨平台支持

其次,eScience中心所提供服务的所有软硬件均由人工微结构科学与技术协同创新中心cicam.nju.edu.cn经费支持。因此,必定需考虑到可能的校外协同单位的身份验证问题。

人工微结构科学与技术协同创新中心由南京大学牵头,联合复旦大学、浙江大学、中国科学技术大学、上海交通大学、中国科学院合肥物质科学研究院成立,2014年10月获教育部、财政部批准认定为科学前沿类国家级协同创新中心。

最后,Box云盘也是eScience中心高性能与人工智能计算集群hpc.nju.edu.cn用户数据同步和备份的重要方式(使用方法见:HPC x Box | 在唐仲英楼集群上使用 Box 云盘),且为我中心首创

图片
HPC集成云盘

基于这三方面的要求,Box云盘需要对接多套认证平台,通过LDAP协议获取用户信息包含userPrincipalName字段,其值理应为学工号@nju.edu.cn(这也是我们在一些服务里强调账号看着像邮箱但不是的原因),通过@区分不同用户域的方法可以确保跨认证平台时绝不会出现ID冲突的情况

基于上述原因,在当前版本下,Box云盘只能采用LDAP这一最广泛成熟、相对灵活的方式进行认证集成

§为什么近日登录认证一直失败?

LDAP认证集成的方式从2017年以来就没有改变过。2020年10月31日,eScience中心收到校内师生的建议,经过审慎评估后决定将云盘Box开放给全校使用

同期,学校更换了新的统一认证平台[1],云盘迁移后发现新的LDAP存在诸多问题,其中影响最严重的问题是部分用户userPrincipalName属性值存在但无法搜索,这将直接导致用户在统一身份认证服务正常的情况下无法登录Box云盘

2023-10-18 08:55:55 Verify LDAP password for user ******@nju.edu.cn on server ldap://******.
2023-10-18 08:55:55 Successfully bind admin user_dn uid=box,ou=Read,ou=Manager,dc=wisedu,dc=com on server ldap://******.
2023-10-18 08:55:55 Search filter: (&(userPrincipalName=******@nju.edu.cn) (<过滤字符串略>), login_attr: userPrincipalName.
2023-10-18 08:55:55 Cannot find user ******@nju.edu.cn in LDAP server ldap://******.

此前,仅有极少数用户碰到这个情况无法使用Box。由于南京大学统一身份认证系统由学校负责统一建设、管理和运行维护,所以eScience中心只能积极协助用户通过OA提交反馈,但仍有部分学生用户直至毕业前都没有成功登录过。

2023年10月16日下午统一身份认证故障[2]绝大多数用户userPrincipalName属性值存在却无法搜索,导致了绝大多数用户都无法登录Box云盘。此情况直至《关于10月16日服务器设备故障已恢复的通知[3]》发布时仍然存在。

事情发生后,eScience中心第一时间积极与学校沟通。但是直到10月19日中午前,提供给eScience中心的两台服务器,均各有一些问题:

  • 对接的主LDAP服务器能检索到,但是延迟上分钟,会导致整个Box都会被拖慢,也有概率自己先崩溃。有印象的用户应该还记得这篇推送:最近云盘登录慢怎么办?
  • 从LDAP服务器检索较快,但是无法检索到用户

恢复正常之前,少数用户能登上是因为Box云盘的LDAP认证服务随机访问上述两个服务器之一,以试图让用户能够有概率登录成功(但此时认证服务仍是异常的,非常缓慢)。打趣一点说,也就是对受影响的未成功登录用户来说:

其中  是个随机变量。

于是,我们双线并行,一方面等待信息化建设管理服务中心的维修进展并不停切换LDAP服务器;另一方面深入源代码分析并与开发工程师讨论临时应急方案,可惜由于软件架构复杂、引入风险过大,遂放弃。

§未来如何打算?

随着这些年学校统一认证的升级,扫码登录极大地方便了广大师生。

学校以前一直要求以反向代理认证的方式对接Box云盘,但是我们内部测试的结果表明反向代理认证会导致云盘功能出现一系列问题

  • 速度瓶颈:从校内良好网络情况下跑满网络带宽的1Gbps下降至300Mbps,即速度下降70%
  • 客户端失效:命令行均无法使用云盘Box,还会导致所有的客户端均无法登录使用。
  • WebDAV失效:无法使用WebDAV功能。

2022年底,恰逢eScience中心全新改版的在线TeX服务tex.nju.edu.cn要上线,认证集成存在困难,信息化建设管理服务中心针对认证模式组织了一次交流会。经过半天的坦率交谈,双方交换了意见,产生了较为积极的结果——经过eScience中心争取,学校同意提供OAuth2的接口。此后在线TeX服务tex.nju.edu.cn成为学校第一个采用OAuth2认证集成的业务。由于在线TeX使用场景相对单一,因此在当前阶段可以直接采用OAuth2认证的模式。

OAuth2相比于LDAP更先进,支持多达5种授权流,但当前统一身份认证平台不能够全面支持OAuth2,因此还是无法完全替代Box云盘所需要的LDAP

如果彻底抛弃LDAP换OAuth2,就会影响Box云盘/协同表格的功能;而如果换反向代理认证,那么Box云盘基本没法使用,所以基于统一身份认证的现状,最佳的方案就是LDAP和OAuth2两者同时做

有了在线TeX成功集成OAuth2的经验,eScience中心也紧锣密鼓地开始规划云盘Box和协同表格的用户管理认证集成的全面升级改造,并计划在今年底、明年初下一个大版本升级时,推出全新用户架构的Box云盘和协同表格。届时,将能够实现LDAP和OAuth2的双认证,既能像原来方式登录,又可以支持校内常见的扫码登录方式。

LDAP、OAuth2、反向代理认证这些技术细节过于复杂,本文就不展开继续解释了。(有兴趣了解的师生可以给本文点个赞或转发,如果呼声高,或许可以针对这个主题开个讲座图片。)

§为什么要等升级?深度定制不行吗?

直至19日中午,学校LDAP服务器上userPrincipalName的检索问题才最终修好,连带一些个例的历史遗留问题也一并解决。感谢信息化建设管理服务中心这段时间的辛苦维修,解决了Box云盘三年来影响最大的一个问题,为后续稳定服务提供了保障。

中心深刻反思,为什么不能做得更完美一些,能够抵御外部系统的各类问题,在这样的极端情况下仍能维持正常服务?成立以来,eScience中心一直只有一个人,并且只有人工微结构科学与技术协同创新中心予以经费支持。 虽然理论上任何认证都可以集成,任何软件都可以定制开发。但是相关专业的师生一定明白,过多的定制开发,必定需要更多的时间、人力和经费的投入,并会带来更多的BUG和安全漏洞。现阶段,这的确超出了个人的精力和能力范围,可能需要等到我能够手搓芯片、一天工作48h的时候才能实现。

多年来,Seafile作为一款优秀的国产开源方案,不仅仅只有全球开源社区参与贡献,校内遇到的各类需求、问题、BUG,我们也是第一时间收集、整理并向开发团队反馈。我们的需求,都要求进入软件主线版本而非仅对南京大学定制,这意味着不是只有南京大学可以使用这些功能,具备开放性和可持续性。

受益于长期以来的这种开放理念,我校用户一直以来能够享受最新Seafile Pro正式版最全面的功能。例如,通过集成LDAP认证,云盘支持WebDAV等高级功能,这在国内案例中是领先的

>_写在最后

在经费紧缺、人手不足的情况下,eScience中心一直以最大努力去维护当前服务的正常、稳定、高质量运转。纵然,中心如果不提供Box云盘、协同表格之类的服务,就不会遭遇这样的问题——但是,开拓创新、奋进向前,需要有“敢为、敢闯、敢干”的精神;自然,出了问题,我们也要敢担当!

感谢广大用户一直以来的支持与关切!正是大家的支持与包容,让eScience中心在服务中进步成长。今后,eScience中心也将在成长中为广大师生提供更多更好的服务。

最后,eScience中心为给广大用户带来的不便再次致以诚挚歉意。

参考资料

[1]

关于规范统一身份认证服务的通知: https://itsc.nju.edu.cn/9c/f2/c21415a498930/pagem.htm

[2]

关于10月16日下午服务器设备突发故障影响部分业务的通知: https://itsc.nju.edu.cn/c3/c7/c21415a639943/page.htm

[3]

关于10月16日服务器设备故障已恢复的通知: https://itsc.nju.edu.cn/c4/0c/c21415a640012/page.htm