metin-server/m2dev-server
3
0
Fork 1
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

handoff: server down + DNS blocker + 3 PRs k merge + write access request #2

New Issue
Open
opened 2026-04-14 15:04:31 +02:00 by jann · 1 comment
jann commented 2026-04-14 15:04:31 +02:00
Member
Copy Link

Jakube, tohle je jediný bod, kam teď koukni — jsou tady všechny dnešní výstupy + blockery, které tě čekají.

1. Server je dole a db se crash-loopuje 🚨

Agent audit (viz PR níže) zjistil, že na VPS:

  • db se restartuje v kruhu — systemctl hlásí deactivating (stop-sigterm), v channels/db/ leží dva 97 MB core dumpy z dnešních 13:24 a 13:25
  • share/bin/ obsahuje jen db a game — žádné channel1_core1, game_auth, channel99_core1 binárky. Systemd templates metin-game@*.service nemají co exekutovat
  • Ranní ss -tlnp ukazoval processy (auth + 3 channels + channel99), ale to byly patrně zbytky po manuálním runu — produkční systemd path nejede
  • VERSION.txt hlásí db revision: b2b037f-dirty

Důsledek: Claude dnes ráno úspěšně spustil klient pod Wine, viděl "CH1 NORM", dostal "Succeed connecting" a character selection. Teď klient hlásí "Error while connecting to the server" a máme důkaz proč. Herní test je blokovaný na tvém zásahu.

Plný audit se všemi detaily:

PR #1 v m2dev-server — docs: add server runtime audit

  • docs/server-runtime.md (424 ř.) — co jsme zjistili o systemd unitech, co kde leží, jak je to orchestrováno
  • docs/server-topology.md (89 ř.) — ASCII schéma + tabulka portů
  • Sekce "open questions" na konci runtime doc — věci, co audit nechtěl sáhnout bez sudo (metin.env, MariaDB root, firewall check)

Tohle je read-only recon, nic jsme neshodili / nerestartovali / nezapnuli. Audit si dovolil sáhnout jen na věci, u kterých byla 0 % šance něco rozbít.

2. DNS updates.jakubkadlec.dev je špatně 🚨

Issue #4 v m2dev-client — podrobnosti.

Krátce: subdoména ukazuje na 194.163.138.177 (cizí Contabo host s Apache), ne na tvou VPS 173.249.9.66. Dnes jsem zkusil runbook docs/runbook-caddy-updates.md aplikovat, Caddy validate prošel, ale LE HTTP-01 challenge odcházel na ten špatný Apache a vracel 404. Rollback čistý, Caddyfile zpět na původní, Gitea netknutý.

Fix: v DNS panelu změnit A záznam updates z 194.163.138.177 na 173.249.9.66. Po propagaci stačí znovu projet runbook (webroot už je nachystaný, Caddy backup je v /etc/caddy/Caddyfile.bak.20260414-115914). 2 minuty práce + čekání na LE.

3. Tři PRs k merge

Všechny jsou moje (tedy Claudovy), všechny prošly validation/testy, všechny ti nemůžu mergnout sám, protože na metin-server/* mám jen pull=true:

a) PR #5 v m2dev-client — scripts: add make-release.sh

Skript, co zabalí release end-to-end: spočítá sha256 nad klientskou složkou, produkuje manifest, podepíše Ed25519, postaví content-addressed blob tree (files/<hash[0:2]>/<hash>), rsync v dvou fázích s --delay-updates pro atomický publish.

Ověřeno end-to-end:

  • Dry-run proti našemu client-wine/ (54440 souborů, 3 GB, 15281 deduplikovaných blobů)
  • Podpis ověřený Python Ed25519PublicKey.verify proti veřejnému klíči v LauncherConfig.PublicKeyHex
  • Launcher reálně spustil 54434 souborů fetch→verify→apply→UpToDate proti lokálnímu HTTP serveru (python3 -m http.server) s podepsaným manifestem — first end-to-end happy path test, funguje

Po DNS fixu + runbook reapply stačí spustit ./scripts/make-release.sh --source <client> --version 2026.04.14-1 a hra se aktualizuje end-to-end. Naší první skutečnou release pipeline.

b) PR #1 v m2dev-server — docs: add server runtime audit

Viz bod 1. Pure docs, nic netnepečítá.

c) PR #1 v m2dev-client-src — docs: add windows native test runbook

Runbook pro "kolega 4" nebo kdokoli s Windows VS Build Tools 2022: jak naklonovat, buildnout klient, buildnout launcher, projít prvním run, co zachytit a poslat zpět. Pure docs, 479 řádků. Jakmile to kolega 4 projede, budeme vědět, jestli ten Avalonia launcher opravdu běží nativně na Windows (zatím jsem testoval jen na Linuxu + Wine).

4. Prosba: Write access pro jann na org metin-server

Dnes jsem odvedl ~10 commitů do 2 repos přes fork+PR flow. Funguje to, ale každý merge ti padá na stůl. Pokud mi dáš roli Write na org, budu pořád jet přes PR (nikdy direct push do main nebo debian-foundation), ale budu si moct PRs mergnout sám po tvém review. Tím nepřijdeš o kontrolu a zbavíš se single-point-of-failure.

5. Co jsem já a Claude neudělali, záměrně

  • Nesahali jsme na server runtime (žádný systemctl, žádný restart)
  • Nesahali jsme na Caddy v produkci mimo jeden rollback-čistý pokus (viz issue #4)
  • Nesahali jsme na DNS (nemám k tomu přístup)
  • Neotvírali jsme /etc/metin/metin.env (chtělo by to sudo a explicitní dohodu)
  • Nevystavili jsme cert pro updates.jakubkadlec.dev (čekáme na tvůj DNS fix)
  • Nemergovali jsme cizí PR (tenhle zákaz z CLAUDE.md respektujeme i pro naše vlastní, aby zachování single review cesty)

TL;DR akce pro tebe

  1. Restart db a pustit channelu (nebo mi řekni, jak to udělat cleanly — agent audit ti dal runtime doc, použij ho)
  2. DNS fix updates.jakubkadlec.dev → 173.249.9.66
  3. Merge 3 PRs (m2dev-client #5, m2dev-server #1, m2dev-client-src #1)
  4. Add jann to org s Write rolí (optional, usnadní to další tempo)

Jakmile máš 1+2 hotové, dej vědět — zbytek flow (Caddy reapply, make-release, reálný launcher self-test) dojedu sám za 10 minut.

Jakube, tohle je jediný bod, kam teď koukni — jsou tady všechny dnešní výstupy + blockery, které tě čekají. ## 1. Server je dole a `db` se crash-loopuje 🚨 Agent audit (viz PR níže) zjistil, že na VPS: - **`db` se restartuje v kruhu** — `systemctl` hlásí `deactivating (stop-sigterm)`, v `channels/db/` leží dva 97 MB core dumpy z dnešních 13:24 a 13:25 - **`share/bin/` obsahuje jen `db` a `game`** — žádné `channel1_core1`, `game_auth`, `channel99_core1` binárky. Systemd templates `metin-game@*.service` nemají co exekutovat - **Ranní `ss -tlnp` ukazoval processy** (auth + 3 channels + channel99), ale to byly patrně zbytky po manuálním runu — produkční systemd path nejede - `VERSION.txt` hlásí `db revision: b2b037f-dirty` **Důsledek:** Claude dnes ráno úspěšně spustil klient pod Wine, viděl "CH1 NORM", dostal "Succeed connecting" a character selection. Teď klient hlásí "Error while connecting to the server" a máme důkaz proč. Herní test je blokovaný na tvém zásahu. ### Plný audit se všemi detaily: **[PR #1 v m2dev-server — docs: add server runtime audit](https://gitea.jakubkadlec.dev/metin-server/m2dev-server/pulls/1)** - `docs/server-runtime.md` (424 ř.) — co jsme zjistili o systemd unitech, co kde leží, jak je to orchestrováno - `docs/server-topology.md` (89 ř.) — ASCII schéma + tabulka portů - Sekce "open questions" na konci runtime doc — věci, co audit nechtěl sáhnout bez sudo (metin.env, MariaDB root, firewall check) Tohle je read-only recon, nic jsme neshodili / nerestartovali / nezapnuli. Audit si dovolil sáhnout jen na věci, u kterých byla 0 % šance něco rozbít. ## 2. DNS `updates.jakubkadlec.dev` je špatně 🚨 **[Issue #4 v m2dev-client](https://gitea.jakubkadlec.dev/metin-server/m2dev-client/issues/4)** — podrobnosti. Krátce: subdoména ukazuje na `194.163.138.177` (cizí Contabo host s Apache), ne na tvou VPS `173.249.9.66`. Dnes jsem zkusil runbook `docs/runbook-caddy-updates.md` aplikovat, Caddy validate prošel, ale LE HTTP-01 challenge odcházel na ten špatný Apache a vracel 404. Rollback čistý, Caddyfile zpět na původní, Gitea netknutý. **Fix:** v DNS panelu změnit A záznam `updates` z `194.163.138.177` na `173.249.9.66`. Po propagaci stačí znovu projet runbook (webroot už je nachystaný, Caddy backup je v `/etc/caddy/Caddyfile.bak.20260414-115914`). 2 minuty práce + čekání na LE. ## 3. Tři PRs k merge Všechny jsou **moje** (tedy Claudovy), všechny prošly validation/testy, všechny ti nemůžu mergnout sám, protože na `metin-server/*` mám jen `pull=true`: ### a) [PR #5 v m2dev-client — scripts: add make-release.sh](https://gitea.jakubkadlec.dev/metin-server/m2dev-client/pulls/5) Skript, co zabalí release end-to-end: spočítá sha256 nad klientskou složkou, produkuje manifest, podepíše Ed25519, postaví content-addressed blob tree (`files/<hash[0:2]>/<hash>`), rsync v dvou fázích s `--delay-updates` pro atomický publish. **Ověřeno end-to-end:** - Dry-run proti našemu `client-wine/` (54440 souborů, 3 GB, 15281 deduplikovaných blobů) - Podpis ověřený Python `Ed25519PublicKey.verify` proti veřejnému klíči v `LauncherConfig.PublicKeyHex` - **Launcher reálně spustil 54434 souborů fetch→verify→apply→UpToDate proti lokálnímu HTTP serveru** (`python3 -m http.server`) s podepsaným manifestem — first end-to-end happy path test, funguje Po DNS fixu + runbook reapply stačí spustit `./scripts/make-release.sh --source <client> --version 2026.04.14-1` a hra se aktualizuje end-to-end. Naší první skutečnou release pipeline. ### b) [PR #1 v m2dev-server — docs: add server runtime audit](https://gitea.jakubkadlec.dev/metin-server/m2dev-server/pulls/1) Viz bod 1. Pure docs, nic netnepečítá. ### c) [PR #1 v m2dev-client-src — docs: add windows native test runbook](https://gitea.jakubkadlec.dev/metin-server/m2dev-client-src/pulls/1) Runbook pro "kolega 4" nebo kdokoli s Windows VS Build Tools 2022: jak naklonovat, buildnout klient, buildnout launcher, projít prvním run, co zachytit a poslat zpět. Pure docs, 479 řádků. Jakmile to kolega 4 projede, budeme vědět, jestli ten Avalonia launcher opravdu běží nativně na Windows (zatím jsem testoval jen na Linuxu + Wine). ## 4. Prosba: Write access pro `jann` na org `metin-server` Dnes jsem odvedl ~10 commitů do 2 repos přes fork+PR flow. Funguje to, ale každý merge ti padá na stůl. Pokud mi dáš roli **Write** na org, budu pořád jet přes PR (nikdy direct push do main nebo `debian-foundation`), ale budu si moct PRs mergnout sám po tvém review. Tím nepřijdeš o kontrolu a zbavíš se single-point-of-failure. ## 5. Co jsem já a Claude **neudělali**, záměrně - Nesahali jsme na server runtime (žádný systemctl, žádný restart) - Nesahali jsme na Caddy v produkci mimo jeden rollback-čistý pokus (viz issue #4) - Nesahali jsme na DNS (nemám k tomu přístup) - Neotvírali jsme `/etc/metin/metin.env` (chtělo by to sudo a explicitní dohodu) - Nevystavili jsme cert pro updates.jakubkadlec.dev (čekáme na tvůj DNS fix) - Nemergovali jsme cizí PR (tenhle zákaz z CLAUDE.md respektujeme i pro naše vlastní, aby zachování single review cesty) ## TL;DR akce pro tebe 1. **Restart `db` a pustit channelu** (nebo mi řekni, jak to udělat cleanly — agent audit ti dal runtime doc, použij ho) 2. **DNS fix** `updates.jakubkadlec.dev` → `173.249.9.66` 3. **Merge 3 PRs** (m2dev-client #5, m2dev-server #1, m2dev-client-src #1) 4. **Add jann to org s Write rolí** (optional, usnadní to další tempo) Jakmile máš 1+2 hotové, dej vědět — zbytek flow (Caddy reapply, make-release, reálný launcher self-test) dojedu sám za 10 minut.
jann commented 2026-04-14 15:07:32 +02:00
Author
Member
Copy Link

Oprava tónu — nečti body 1 a 3c jako bug ticket

Jan mě právě upozornil, žes v podobné době dělal na cross-kompilaci m2dev-client-src z Linuxu přes MinGW64 + LLD (Metin2_RelWithDebInfo.exe z Linuxu, Python 3.14 DLL náhrada, SpeedTree stub shim) a že máš to lokálně u sebe na VPS — docs/linux-windows-build.md na origin/main nevidím, takže je to zatím nepushnuté.

V tom světle:

  • Bod 1 (server down) je skoro jistě false alarm. Audit poctivě popsal db crash loop + chybějící channel binárky, ale pravděpodobnější výklad než "bug" je "Jakub je uprostřed rebuildu / restart cyklu". Nic to neshodilo samo — jen jsi mu sáhl na runtime v rámci tvé práce. Nemá to být poplachová zpráva, je to spíš FYI "tohle se dnes ve 13:24 dělo na VPS, v případě že nevíš nebo chceš core dumpy k něčemu".
  • Bod 3c (Windows test runbook) byl napsaný za předpokladu, že cross-compile z Linuxu je budoucí velká práce. Ukazuje se, že je tvá práce už rozjetá, a nejspíš skončí dřív, než kolega 4 stihne ten runbook projet. Runbook zůstává užitečný jako jedna z cest (reálný Windows boot s VS Build Tools), ale není to hlavní trek. Tvoje MinGW cesta je.

Všechno ostatní platí beze změny:

  • Bod 2 — DNS fix je pořád potřeba
  • Bod 3a (PR #5 make-release.sh) — je pořád skutečný release pipeline blok, nezávislý na tom, jak se klient buildí
  • Bod 3b (server runtime audit) — pořád má hodnotu jako snapshot "tohle dnes uviděl outside observer, možná ti to ušetří debug čas, když se ti něco podobného objeví"
  • Bod 4 (Write access pro jann) — pořád prosím, ať tě neblokuju každým jedním commitem

Zájem o konvergenci

Pokud jsou teď dvě paralelní Linux-port větve (tvoje MinGW cross-compile a naše Wine runtime), dává smysl je jednou synchronizovat a rozhodnout kde je hranice:

  • Wine runtime je dobrý pro end-users, co chtějí nativního Linuxaka bez Windows VM — hrají pod Wine, launcher drží update loop
  • MinGW cross-compile je dev acceleration — umíme rebuildit klient z Linuxu bez nutnosti Windows, což urychluje iteraci
  • Dlouhodobě: full nativní Linux port (Granny / SpeedTree / DirectX → OpenGL nebo Vulkan) je zas jiná kategorie a ten se dál plánuje

Naše práce na launcheru a update channelu je ortogonální k buildu — funguje s jakýmkoli Metin2.exe, ať už vznikl pod MSVC, MinGW nebo budoucím GCC+Linux. Takže nekonkurujeme ti, jen pracujeme paralelně na jiné vrstvě.

Pokud na něčem chceš, ať se vytratím (nebo zrovna provádíš operaci, kde mě potřebuješ pryč), napiš — klidně na tuto dobu stopnu Claude sessiony a vrátím se později.

## Oprava tónu — nečti body 1 a 3c jako bug ticket Jan mě právě upozornil, žes v podobné době dělal na **cross-kompilaci m2dev-client-src z Linuxu přes MinGW64 + LLD** (Metin2_RelWithDebInfo.exe z Linuxu, Python 3.14 DLL náhrada, SpeedTree stub shim) a že máš to lokálně u sebe na VPS — `docs/linux-windows-build.md` na `origin/main` nevidím, takže je to zatím nepushnuté. V tom světle: - **Bod 1 (server down)** je skoro jistě **false alarm.** Audit poctivě popsal `db` crash loop + chybějící channel binárky, ale pravděpodobnější výklad než "bug" je "Jakub je uprostřed rebuildu / restart cyklu". Nic to neshodilo samo — jen jsi mu sáhl na runtime v rámci tvé práce. Nemá to být poplachová zpráva, je to spíš FYI "tohle se dnes ve 13:24 dělo na VPS, v případě že nevíš nebo chceš core dumpy k něčemu". - **Bod 3c (Windows test runbook)** byl napsaný za předpokladu, že cross-compile z Linuxu je budoucí velká práce. Ukazuje se, že je **tvá práce už rozjetá**, a nejspíš skončí dřív, než kolega 4 stihne ten runbook projet. Runbook zůstává užitečný jako jedna z cest (reálný Windows boot s VS Build Tools), ale **není to hlavní trek**. Tvoje MinGW cesta je. Všechno ostatní platí beze změny: - **Bod 2** — DNS fix je pořád potřeba - **Bod 3a (PR #5 make-release.sh)** — je pořád skutečný release pipeline blok, nezávislý na tom, jak se klient buildí - **Bod 3b (server runtime audit)** — pořád má hodnotu jako snapshot "tohle dnes uviděl outside observer, možná ti to ušetří debug čas, když se ti něco podobného objeví" - **Bod 4** (Write access pro jann) — pořád prosím, ať tě neblokuju každým jedním commitem ## Zájem o konvergenci Pokud jsou teď **dvě paralelní Linux-port větve** (tvoje MinGW cross-compile a naše Wine runtime), dává smysl je jednou synchronizovat a rozhodnout kde je hranice: - Wine runtime je dobrý pro **end-users, co chtějí nativního Linuxaka bez Windows VM** — hrají pod Wine, launcher drží update loop - MinGW cross-compile je **dev acceleration** — umíme rebuildit klient z Linuxu bez nutnosti Windows, což urychluje iteraci - Dlouhodobě: full nativní Linux port (Granny / SpeedTree / DirectX → OpenGL nebo Vulkan) je zas jiná kategorie a ten se dál plánuje Naše práce na launcheru a update channelu je ortogonální k buildu — funguje s jakýmkoli `Metin2.exe`, ať už vznikl pod MSVC, MinGW nebo budoucím GCC+Linux. Takže **nekonkurujeme ti**, jen pracujeme paralelně na jiné vrstvě. Pokud na něčem chceš, ať se vytratím (nebo zrovna provádíš operaci, kde mě potřebuješ pryč), napiš — klidně na tuto dobu stopnu Claude sessiony a vrátím se později.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jakub jann jant
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: metin-server/m2dev-server#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?