Rebuild and re-import the felis-lobby image so LuckPerms is present #4

New Issue

2026-07-28T12:20:49+09:00

FLYEMOJ1 commented

2026-07-28 12:20:49 +09:00

(Migrated from github.com)

问题

跑着的 lobby Pod 的 /data/plugins 里没有 LuckPerms。镜像是在 LuckPerms 接线加进来之前构建并导入的。

失败是静默的：没有 LuckPerms，权限相关的操作不报错，只是不生效。

felis setup 修不了这个 —— 它在已部署的主机上会跳过 bootstrap（setup.go:69-74 的 hostBootstrapReady 门控），所以不会重新构建或重新导入镜像。

收敛命令

在节点上重跑装机器：

sudo bash deploy/bootstrap.sh

build_game_stack()（:1245-1279）会重新解析 LuckPerms 的下载地址、重建 lobby 镜像、并重新导入 k3s 的 containerd。

证据

Identified by Claude Opus 5 (claude-opus-5) while auditing the deployed lobby against its build recipe on 2026-07-28.

deploy/bootstrap.sh:1245-1279：

log "building ${FELIS_LOBBY_IMAGE} (Paper ${MC_VERSION} + felis-paper /menu + LuckPerms)"
docker build -f "${GAME_STACK_DIR}/deploy/lobby/Dockerfile" \
  --build-arg PAPER_JAR_URL="$PAPER_JAR_URL" \
  --build-arg LUCKPERMS_JAR_URL="$LUCKPERMS_JAR_URL" \
  -t "$FELIS_LOBBY_IMAGE" "$GAME_STACK_DIR"
...
  remove_k3s_image "$img"; docker save "$img" | k3s_cmd ctr images import -

LuckPerms 是构建期解析的，:1207 那行 die 消息写明了它的用途：the lobby needs it for the panel's permission controls。

导入镜像本身还不够，脚本自己也知道这一点，所以 :2013-2017 专门重建两台系统 Pod：

# The login/lobby images use local mutable tags. Importing a replacement updates
# containerd, but an existing StatefulSet template is byte-for-byte unchanged and
# Kubernetes will not roll it. Recreate only the two always-on system pods so a
# convergent bootstrap actually starts the images it just imported.
restart_existing_system_servers() {

接线本身是有测试守着的 —— bootstrap_asset_test.go 的 TestLobbyLuckPermsWiringIsConsistent 检查三个文件的一致性：

// The lobby's LuckPerms wiring is a three-file contract with no compiler behind it:
// bootstrap.sh resolves a URL and passes it as a build-arg, the Dockerfile requires
// that exact arg name and writes the jar to a fixed path, and entrypoint.sh copies
// from that same path on every boot.

所以问题不在接线，在于这套接线的产物没有到达已部署的节点。

2026-07-28 更正：这条原本写成 issue #1 的症状之一，那是归错了。LuckPerms 住在容器镜像里，不在 MinecraftServer CR 上，ensureSystemServers 的 create-if-absent 限制够不到它。收敛路径一直存在，只是没人把它写下来。

验收

crictl exec 或等价手段在跑着的 lobby 容器里 ls /data/plugins 能看到 LuckPerms 的 jar。

备注

需要在节点上执行，我这边执行不了，所以挂 help wanted。

注意这条和「Patch spec.rcon on the lobby/demo/demo2 MinecraftServer CRs」（issue #3）的顺序关系：镜像先，CR patch 后。反过来做的话，CR 上 rcon.enabled=true 会让 reconciler 的就绪门卡在一个不存在的 RCON 监听上，服务器出不了 Starting 就被 markFailed。

## 问题跑着的 lobby Pod 的 `/data/plugins` 里没有 LuckPerms。镜像是在 LuckPerms 接线加进来之前构建并导入的。失败是静默的：没有 LuckPerms，权限相关的操作不报错，只是不生效。 `felis setup` 修不了这个 —— 它在已部署的主机上会跳过 bootstrap（`setup.go:69-74` 的 `hostBootstrapReady` 门控），所以不会重新构建或重新导入镜像。 ## 收敛命令在节点上重跑装机器： ```sh sudo bash deploy/bootstrap.sh ``` `build_game_stack()`（`:1245-1279`）会重新解析 LuckPerms 的下载地址、重建 lobby 镜像、并重新导入 k3s 的 containerd。 ## 证据 Identified by Claude Opus 5 (claude-opus-5) while auditing the deployed lobby against its build recipe on 2026-07-28. `deploy/bootstrap.sh:1245-1279`： ```sh log "building ${FELIS_LOBBY_IMAGE} (Paper ${MC_VERSION} + felis-paper /menu + LuckPerms)" docker build -f "${GAME_STACK_DIR}/deploy/lobby/Dockerfile" \ --build-arg PAPER_JAR_URL="$PAPER_JAR_URL" \ --build-arg LUCKPERMS_JAR_URL="$LUCKPERMS_JAR_URL" \ -t "$FELIS_LOBBY_IMAGE" "$GAME_STACK_DIR" ... remove_k3s_image "$img"; docker save "$img" | k3s_cmd ctr images import - ``` LuckPerms 是构建期解析的，`:1207` 那行 die 消息写明了它的用途：`the lobby needs it for the panel's permission controls`。导入镜像本身还不够，脚本自己也知道这一点，所以 `:2013-2017` 专门重建两台系统 Pod： ```sh # The login/lobby images use local mutable tags. Importing a replacement updates # containerd, but an existing StatefulSet template is byte-for-byte unchanged and # Kubernetes will not roll it. Recreate only the two always-on system pods so a # convergent bootstrap actually starts the images it just imported. restart_existing_system_servers() { ``` 接线本身是有测试守着的 —— `bootstrap_asset_test.go` 的 `TestLobbyLuckPermsWiringIsConsistent` 检查三个文件的一致性： ```go // The lobby's LuckPerms wiring is a three-file contract with no compiler behind it: // bootstrap.sh resolves a URL and passes it as a build-arg, the Dockerfile requires // that exact arg name and writes the jar to a fixed path, and entrypoint.sh copies // from that same path on every boot. ``` 所以问题不在接线，在于这套接线的产物没有到达已部署的节点。 > **2026-07-28 更正**：这条原本写成 issue #1 的症状之一，那是归错了。LuckPerms 住在容器**镜像**里，不在 MinecraftServer CR 上，`ensureSystemServers` 的 create-if-absent 限制够不到它。收敛路径一直存在，只是没人把它写下来。 ## 验收 `crictl exec` 或等价手段在跑着的 lobby 容器里 `ls /data/plugins` 能看到 LuckPerms 的 jar。 ## 备注需要在节点上执行，我这边执行不了，所以挂 `help wanted`。注意这条和「Patch `spec.rcon` on the lobby/demo/demo2 MinecraftServer CRs」（issue #3）的顺序关系：**镜像先，CR patch 后**。反过来做的话，CR 上 `rcon.enabled=true` 会让 reconciler 的就绪门卡在一个不存在的 RCON 监听上，服务器出不了 Starting 就被 `markFailed`。

Lemon-miaow commented

2026-09-24 12:02:40 +09:00

(Migrated from github.com)

注记（老装机一次性操作，非代码缺陷——保持打开做待办跟踪）：
LuckPerms 住在 lobby 镜像里。重跑 deploy/bootstrap.sh 会从当前源码重建并推送 felis-lobby（含 LuckPerms jar；批 40 起 demo-up 也是同一安装器来源），lobby 的 StatefulSet 滚动后即生效。无需代码改动。

注记（老装机一次性操作，非代码缺陷——保持打开做待办跟踪）： LuckPerms 住在 lobby **镜像**里。重跑 `deploy/bootstrap.sh` 会从当前源码重建并推送 felis-lobby（含 LuckPerms jar；批 40 起 demo-up 也是同一安装器来源），lobby 的 StatefulSet 滚动后即生效。无需代码改动。

Lemon-miaow commented

2026-09-26 08:43:59 +09:00

(Migrated from github.com)

VM 上验证过，另外补了一层兜底，免得以后再静默失效。

重跑装机器（b107）重建并导入 lobby 镜像，lobby-0 被重建：
kubectl -n minecraft exec lobby-0 -- ls /data/plugins | grep -i luckperms → LuckPerms.jar
201cfc8：服务器没有 LuckPerms 时，权限/用户组/LP 信息三个接口返回 409 luckperms_missing，面板显示原因（lobby 重跑装机器、其他服务器加 LuckPerms 插件）。判定依据是 Paper/Spigot/vanilla 的未知命令回复；在 VM 上一台没装 LuckPerms 的服务器实测回复为
Unknown or incomplete command. See below for error\nlp user Steve permission info<--[HERE]，与判定一致。LuckPerms 装着时它异步执行、RCON 回空串，这条路径照旧返回 200。
7c2fa08 把升级步骤写进 docs/operations.md。

VM 上验证过，另外补了一层兜底，免得以后再静默失效。 - 重跑装机器（b107）重建并导入 lobby 镜像，lobby-0 被重建： `kubectl -n minecraft exec lobby-0 -- ls /data/plugins | grep -i luckperms` → `LuckPerms.jar` - 201cfc8：服务器没有 LuckPerms 时，权限/用户组/LP 信息三个接口返回 `409 luckperms_missing`，面板显示原因（lobby 重跑装机器、其他服务器加 LuckPerms 插件）。判定依据是 Paper/Spigot/vanilla 的未知命令回复；在 VM 上一台没装 LuckPerms 的服务器实测回复为 `Unknown or incomplete command. See below for error\nlp user Steve permission info<--[HERE]`，与判定一致。LuckPerms 装着时它异步执行、RCON 回空串，这条路径照旧返回 200。 - 7c2fa08 把升级步骤写进 `docs/operations.md`。

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: FelisMC/Felis#4