「开源软件供应链点亮计划——暑期 2020」USTCLUG 项目提案
「开源软件供应链点亮计划」是由中国科学院软件研究所发起并长期支持一项活动，旨在解决基础开源软件面临的许可、质量、维护和技术支持等问题，进而影响整个软件产业的供应链。而「开源软件供应链点亮计划——暑期 2020」是由中科院软件所与 openEuler 社区共同举办的一项面向高校学生的暑期活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进国内优秀开源软件社区的蓬勃发展。
此活动与 GSoC (Google Summer of Code) 的模式类似：开源项目/社区提供项目需求与导师 (mentor)；学生申请项目通过后利用暑期的时间进行开发，将成果贡献给社区；主办方（中科院软件所与 openEuler 社区）根据评估结果给学生发放奖金。所有参与的社区列表可查看 https://isrc.iscas.ac.cn/summer2020/#/organisations。
今年夏天，USTCLUG (中科大学生 Linux 用户协会) 计划以社区身份加入此暑期活动。以下是我们计划的项目提案，也欢迎社团的各位同学提出建议。
本提案参考了清华大学 TUNA 协会（清华大学学生网络与开源软件协会）的项目提案，在此表示感谢。
在报名前，请先阅读由主办方提供的学生指南。
科大镜像站前端架构改进
项目描述：目前，科大镜像站的前端架构仍然沿用着 2013 年的设计，但是随着时间的发展，我们也发现目前的镜像站前端架构在用户体验、维护与部署上带来了一些不便。目前的镜像站主页是由一套 Python 脚本每小时从模板生成得到的，虽然足够使用，但是在维护中也遇到了一些问题，诸如界面设计的实用性、主页与 status 页面显示不一致等问题。本项目希望能够通过调整镜像站前端架构，提高用户体验，降低维护的复杂度，也方便其他需要的镜像站部署页面显示的解决方案。
项目难度：低
项目社区导师：付佳伟
导师联系方式：ibug@ustclug.org
合作导师联系方式：陶柯宇 taoky@ustclug.org
项目产出要求：以下要求不需要全部达到，选择感兴趣的方向即可
- 调整页面结构，与 Nginx FancyIndex 结合，提供美观的文件列表页面
- 改进页面功能，提供准确的仓库最近更新时间（可以参考 status 页面）
- 为了得到准确的更新时间，需要能够与多种同步后端结合，包括科大镜像站目前使用的镜像同步工具 Yuki，以及传统的 crontab + 同步脚本的方式
- 与帮助页面更好的结合，例如
- 自动为新的帮助页添加首页上的链接
- 提升易用性，例如
- 提供一个各大发行版的软件源配置生成器，方便用户快速切换软件源
- 美化页面，例如
- 使用响应式设计在不同平台上都能提供良好的显示效果
- 提供对深色模式的支持
- 前端工程化，提高可维护性，例如
- 使用 Sass 或 LESS 重构 CSS 结构
- 使用 Vue.js 实现前端模板和（部分）动态页面效果
- 分离获取更新时间等仓库信息的这部分逻辑，更方便与其他数据源对接
- 改善部署文档，方便其他需要的镜像站部署
项目技术要求：
- 熟练一种方便灵活的编程语言及该语言常用的模板框架，例如
- Python 和 Jinja2
- Ruby 和 ERB
- 或者熟悉一种静态网站生成器的使用，例如
- Jekyll
- Hugo
- 熟悉 web 纯前端开发
相关的开源软件仓库列表：
License: GNU GPLv2
Hackergame CTF 比赛平台改进
项目描述：Hackergame 是 USTCLUG 开发的一套开源 CTF 比赛平台，主要用于每年举办的科大信息安全大赛，随真实需求不断进行技术迭代，并且重视生产环境下的安全性和可靠性。目前使用的是 Django + Vue.js 框架，但前后端解耦仍然不够充分，代码中写死了一些不合理的规则，很多地方缺少通用性和灵活性，测试和部署也不够方便。本项目希望能通过调整架构设计，重构部分代码，得到一个更加通用、健壮的比赛平台，让将来比赛中的实际需求更容易实现。
项目难度：中
项目社区导师：王子博
导师联系方式：hypercube@0x01.me
合作导师联系方式（选填）：暂无。
项目产出要求：以下要求不需要全部达到，选择感兴趣的方向即可
- 在不影响安全性和可靠性的前提下，用 Django REST Framework 重构后端，用现代前端工具链（Yarn、webpack 等）重构前端
- 增加自动测试、Docker 化部署、持续集成等工具
- 通过重构去除代码中写死的规则，如登录方式、参赛组列表、每个参赛组需要收集的个人信息
- 改正一些不正确的业务模型，如：
- 题目应该支持打开链接、下载源代码、下载文件等操作，而不是只能打开一个 URL
- 用户组、用户属性和权限的模型需要重新设计
- 比赛应该有尚未开始、正在进行、暂停、结束等多种状态，而不是只有开/关两种
- 增加一些新功能，如：
- 让出题、导入题目、审查题目、修改题目等操作更容易
- 所有操作保留历史记录以便审计和回滚
- 支持动态分数题目
- 支持 I18N
项目技术要求：
- 熟练使用 Python 和 Django
- 了解前后端开发和运维全过程
- 会避免常见的 web 安全漏洞
相关的开源软件仓库列表：
License: MIT
镜像站单副本对象存储
项目描述：
传统文件系统（如 XFS）、ZFS、RAID 等解决方案对于镜像站的负载类型来说并不高效：首先在用户读取文件时，RAID 会带来读取放大，在用户读取小文件时影响尤甚；其次文件系统的元数据无法确保一直缓存于内存中，从而使列目录等操作容易成为性能瓶颈。
而使用单副本的对象存储可以解决以上的两个问题：由于镜像站的数据更像是缓存，允许丢失，因此可以采用单副本的方式存储，免去冗余保护。坏盘后只需更新元数据删除对应的文件，触发增量同步即可；而关于元数据，在对象存储的实现中，大多使用数据库存放元数据，而数据库性能调优有许多成熟的工具和经验。这对元数据访问优化是比较有利的。
本项目的难点在于：对象存储的实现需要考虑坏盘更新元数据，删除对应文件，平滑过渡、平衡各个磁盘的读负载，避免负载集中在同一块磁盘上，以及使用 SSD 加速读取请求。目前开源的对象存储实现（如 OpenIO 和 minio）都无法很好满足需求；另外，下游的 rsync 同步会带来较高的并发量，fuse 可能会带来性能问题。
在工业界中，CDN 缓存的需求（数据可靠性不敏感、数据量大、吞吐量高）与本项目希望解决的问题也是类似的。
项目难度：高
项目社区导师：高一凡
导师联系方式：yifan@ustclug.org
合作导师联系方式（选填）：暂无。
项目产出要求：
- 基于现有的对象存储实现进行修改，支持以上提到的部分特性，包括：
- 坏盘更新元数据，删除对应文件，平滑过渡
- 平衡各个磁盘的读负载，避免负载集中在同一块磁盘上
- SSD 加速读请求（可选）
- 测量下游的 rsync 同步为对象存储方案带来的性能影响。（可选）
- 服务器集群（可选）
- 使用单副本的方式，一旦磁盘故障，在下次成功同步之前，将会出现镜像不完整的问题。此时可以从集群中的其他节点获取数据。
- 镜像分级。对于不重要的镜像（或目录），可以在多个节点之间共享一个副本，从而提高可用空间，为更多镜像服务。
项目技术要求：
- 熟悉任何一种高性能的编程语言
- 能够阅读并理解现有对象存储的实现，以提出改进方案
- 对文件系统的实现有一定了解
相关的开源软件仓库列表：
- https://www.openio.io (开源对象存储实现)
- https://github.com/minio/minio (开源对象存储实现)
- https://github.com/openstack/swift (开源对象存储实现)
- https://rclone.org/ (S3 API fuse 实现)
- https://github.com/kahing/goofys/ (S3 API fuse 实现)
License: 与指定修改的开源对象存储实现相同。
rsync 反向代理
项目描述：
镜像站通常会借助 rsync 协议，在上下游之间同步数据。在实践中，我们遇到的问题是：当有两台服务器分别存储不同的镜像内容（例如，一台存储热门内容，另一台存储冷门镜像），对外提供 rsync 服务时， 接入点无法统一。
本项目希望以反向代理 rsync 服务的方式解决此问题。 即：所有 rsync 请求通过一台统一的反向代理服务器，根据请求的 module name 代理至不同后端服务器。
项目难度：中
项目社区导师：高一凡
导师联系方式：yifan@ustclug.org
合作导师联系方式（选填）：暂无。
项目产出要求：
- 实现 rsync 反向代理
- 解析 rsync 握手协议
- 处理不同协议版本号间的兼容性
- 支持透明代理特性（可选）
项目技术要求：
- 对网络编程有一定了解
- 能够阅读并理解 rsync 工具源代码，理解其协议
相关的开源软件仓库列表：
- https://git.samba.org/?p=rsync.git (原版 rsync)
- https://github.com/tuna/rsync (TUNA 实现的 rsync，缓存元数据在内存中以减少磁盘开销。科大镜像站目前亦使用此版本的 rsync 为下游提供服务。)
License: 自定，OSI 组织认证的开源协议即可。注意：如果计划在完成项目时使用 rsync 的源代码，则协议需要使用 GNU GPLv3。
