Q&A

使用逻辑相关

题目类型中的“静态容器”指的是全部参赛者共用一个容器吗？

不是。静态容器与动态容器相同，每个参赛队伍都有一个独立的容器。

但是静态容器内的内容是一样的，且不会传递下发动态 flag。只能通过获取硬编码于容器中的一个或多个静态 flag 作为验证指标，也即“静态”的意思。

目前的组队逻辑是怎么样的呢？

一名用户可参与多个队伍，每场比赛每个均需要每名队员独立报名，同一个人可以以不同队伍身份同时参与多场比赛，报名时需要选择以哪个队伍进行参赛。

在报名等待审核和被拒绝时可以撤回报名。审核通过、禁赛时不可撤回报名及更换所属队伍，且队伍将会被锁定。

在比赛结束后，队伍仍然显示处于锁定状态，若确认没有其他正在进行中的比赛时进行人员变动，队伍将会自动解锁。

是否支持多容器题目？

目前由于考虑到一些容器后端的兼容性问题，暂不支持多容器题目。

是否支持多人同时编辑题目？

目前的题目编辑逻辑为拉取一次数据，本地更新后全量更新数据库，多人编辑可能造成数据冲突或丢失，最终数据以最后一次更新为准，因此不建议多人同时编辑同一个题目。

是否支持多阶段题目？

多阶段题目建议将 flag 在注入时进行切片，再分发到不同的位置或按照题目需要的方式进行组合。

题目描述编写建议

在一段时间的测试和使用后，我们发现了一种较好的题目描述编写方式，这一方式不会抢占附件下载按钮的位置，同时还能提供更多的题目信息：

**Author:** GZTime
**Difficulty:** Baby
**Category:** Misc
 
---
 
Description of the challenge...

需要注意的是，在 Markdown 编写规范中，如果需要换行的同时不另起一个段落，需要在行尾加上两个空格。

在 GZCTF 上编写题目时，请注意在信息行和另外有换行需求的行后适当加上空格，同时尽量多换行、保证短句每行宽度在 490px （约 30 个中文字符）以内来获得更好的显示效果。

平台部署相关

关于部署的建议？

对于拥有多机集群及其部署需求的用户，建议使用 K3s 作为 K8s 的发行版，其能提供所需的全部功能，且易于安装部署。

更一般的情况下最方便的部署方式为 Docker + K3s 分离部署，只需要执行 docker-compose 即可完成 GZCTF 平台的部署，而 K3s 的部署则只需要执行安装后导出 kubeconfig 挂载给 GZCTF 即可。

如果需要使用 K3s 集群内部署，需要提供两个 PVC（用于数据库及附件存储）、一个 ConfigMap（用于存储 appsettings.json）、一个 Secret（用于存储指向自己集群的 k8sconfig.yaml）。你可以按需进行数据库部署及 Redis 部署，如果只运行一个 GZCTF 实例，可以不部署 Redis。

经测试，出于数据库性能考量，暂不建议使用多实例分布部署，单实例多性能足以支持大多数比赛。

GZCTF 集群多实例部署有什么需要注意的？

GZCTF 支持多个实例同时运行，但需要提供相同的数据库实例及 Redis 实例（多实例必选）及共享存储（如 NFS）作为 PVC。其中数据库实例和共享存储用于保证数据一致，Redis 实例用于进行后端部分数据的缓存同步、SignalR 的 Scale-Out 广播。

同时，为了确保 SignalR 基于 websocket 的正常运行，需要在负载均衡器中配置 Sticky Session。

平台定位相关

是否考虑支持 AWD / AWDP 赛制

GZCTF 作为一个免费开源的项目不会去做 AWDP 的支持。

虽然目前能设想的方案兼容性是很高的，且不是不能做，但是实现起来需要大量的时间投入，且大概还需要三个附属项目，为此没有收入是不太能接受的；其次是，如果做出来可能会影响部分企业的盈利渠道，也算是不太好的一件事情。

解题赛本身已经能够训练大部分的技术能力，fix / patch 也是直接教学、分发镜像本地实验就可以实现。GZCTF 的初衷是 帮助高校更好地训练 CTF 队伍，而不是举办正式的比赛，从教育角度出发，去做一个 AWD 平台的必要性很低，想训练赛制的话不如去打个现场赛，这也是考量的另一个方面。