fix(dev-new): stop shadowing the image's modules dir, activate module configs

dominik.polakovics commented

2026-08-21 00:33:24 +02:00

Owner

Follow-up to #375, found while verifying the deploy. Two bugs, one of which made the realm come up broken while every command reported success.

1. The modules bind mount shadowed the image's own modules

wow-db-import mounted /var/lib/wow/modules over /azerothcore/modules. That host directory is a leftover of the SD card era and still contained only the three modules the card last synced:

host  /var/lib/wow/modules : mod-npc-talent-template  mod-playerbots  mod-xp-lock
image /azerothcore/modules : all 11 modules, 273 SQL files

So db-import scanned the stale set, printed >> World database is up-to-date! Containing 1379 new and 1391 archived updates., exited 0, and applied none of the new SQL. The worldserver then started against a schema missing the tables its modules expect:

[1146] Table 'acore_world.custom_quest_xp' doesn't exist
Your database structure is not up to date.

A successful-looking exit that leaves the realm broken — the worst shape a failure can take.

Since #375 the images build their own modules from build/pins, so the mount is not merely stale, it is redundant. Removed from both containers plus the tmpfiles rule that created the directory. Checked first that nothing in the modules tree is read at runtime — the only non-source files are licences, test fixtures and a web testdeck.

2. Modules with default configs had no config file

The config loader reads *.conf; the image entrypoint lays down *.conf.dist. The five modules left on defaults therefore had no active config and warned on every property:

> Config: Missing property AOELoot.Message in config file ... add "AOELoot.Message = 1"

wow-config now seeds a .conf from each .conf.dist that lacks one. Behaviour was already correct (compiled defaults match the .dist values); this removes the noise and makes the files editable in the normal place.

Note the one-cycle lag, commented in the module: .dist files only exist after a container has started, so a brand-new module's config is seeded on the next run of the unit rather than the one that first pulls its image.

Already applied to the live host

The realm was fixed by hand before this PR so it was not left broken: db-import re-run without the bad mount (applied individual-progression, transmog, aoe-loot, challenge-modes SQL), then the worldserver restarted. It is up, 500 bots online, custom_quest_xp has 5657 rows, and Errors.log is down to one unrelated stock warning. This PR makes that state reproducible rather than hand-made.

Still manual

.ip set <name> 18 on Rhuarc, Restoria and Magnon needs those characters online — the handler takes an optional PlayerIdentifier and is Console::Yes, but driving it from the console FIFO against offline characters is a no-op (verified: no rows in character_queststatus_rewarded for quests 66000-66018 afterwards). Progression is derived from those hidden quest rows, so it can also be set directly in SQL if logging in three times is not appealing.

Follow-up to #375, found while verifying the deploy. Two bugs, one of which made the realm come up broken while every command reported success. ## 1. The modules bind mount shadowed the image's own modules `wow-db-import` mounted `/var/lib/wow/modules` over `/azerothcore/modules`. That host directory is a leftover of the SD card era and still contained only the three modules the card last synced: ``` host /var/lib/wow/modules : mod-npc-talent-template mod-playerbots mod-xp-lock image /azerothcore/modules : all 11 modules, 273 SQL files ``` So db-import scanned the stale set, printed `>> World database is up-to-date! Containing 1379 new and 1391 archived updates.`, exited 0, and applied none of the new SQL. The worldserver then started against a schema missing the tables its modules expect: ``` [1146] Table 'acore_world.custom_quest_xp' doesn't exist Your database structure is not up to date. ``` A successful-looking exit that leaves the realm broken — the worst shape a failure can take. Since #375 the images build their own modules from `build/pins`, so the mount is not merely stale, it is redundant. Removed from both containers plus the tmpfiles rule that created the directory. Checked first that nothing in the modules tree is read at runtime — the only non-source files are licences, test fixtures and a web testdeck. ## 2. Modules with default configs had no config file The config loader reads `*.conf`; the image entrypoint lays down `*.conf.dist`. The five modules left on defaults therefore had no active config and warned on every property: ``` > Config: Missing property AOELoot.Message in config file ... add "AOELoot.Message = 1" ``` `wow-config` now seeds a `.conf` from each `.conf.dist` that lacks one. Behaviour was already correct (compiled defaults match the .dist values); this removes the noise and makes the files editable in the normal place. Note the one-cycle lag, commented in the module: `.dist` files only exist after a container has started, so a brand-new module's config is seeded on the next run of the unit rather than the one that first pulls its image. ## Already applied to the live host The realm was fixed by hand before this PR so it was not left broken: db-import re-run without the bad mount (applied individual-progression, transmog, aoe-loot, challenge-modes SQL), then the worldserver restarted. It is up, 500 bots online, `custom_quest_xp` has 5657 rows, and `Errors.log` is down to one unrelated stock warning. This PR makes that state reproducible rather than hand-made. ## Still manual `.ip set <name> 18` on Rhuarc, Restoria and Magnon needs those characters **online** — the handler takes an optional `PlayerIdentifier` and is `Console::Yes`, but driving it from the console FIFO against offline characters is a no-op (verified: no rows in `character_queststatus_rewarded` for quests 66000-66018 afterwards). Progression is derived from those hidden quest rows, so it can also be set directly in SQL if logging in three times is not appealing.

dominik.polakovics added 1 commit

2026-08-21 00:33:24 +02:00

fix(dev-new): stop shadowing the image's modules dir, activate module configs 4c5fa8d3d3

wow-db-import bind-mounted /var/lib/wow/modules over /azerothcore/modules.
That host directory is a leftover of the SD card era and still held only
the three modules the card last synced, so db-import scanned the stale set,
reported "World database is up-to-date" and applied none of the new SQL.
The worldserver then came up against a schema with no custom_quest_xp,
which is a successful-looking exit that leaves the realm broken.

The images now carry their own modules, built from build/pins, so the mount
is not just stale but redundant. Dropped from both containers, along with
the tmpfiles rule that created the directory.

Separately, the config loader only reads *.conf while the entrypoint lays
down *.conf.dist, so the modules whose defaults we accept had no config file
at all and warned on every unset property. Seed a .conf from each .dist when
one is absent.

dominik.polakovics added 1 commit

2026-08-21 00:57:33 +02:00

fix(dev-new): ship the module configs whole, not as partial overrides 276cad6e50

mod_ahbot.conf and individualProgression.conf carried only the handful of
settings that differ from upstream. That is not how these modules read
config: everything absent falls back to a compiled default, and for
mod-ah-bot-plus those defaults are not viable. The module reported itself
enabled, populated its item candidate lists, ran a full update cycle on
demand and posted exactly zero auctions.

Both files are now the upstream .dist verbatim with the overrides applied
on top, which is what mod-ah-bot-plus's own README asks for. Verified live:
the auction house went from 0 to 450 on the first cycle after the swap and
1800 by the next, and IndividualProgression's 1431 missing-property
warnings per startup went to none.

dominik.polakovics commented

2026-08-21 00:59:52 +02:00

Author

Owner

Third fix pushed: the AH bot was posting nothing. It reported enabled, populated candidate lists, ran a full .ahbot update cycle and inserted zero rows, with no error. Cause: mod_ahbot.conf shipped 6 of the module's 448 settings, and everything absent falls back to a compiled default that is not viable for item selection. Both mod_ahbot.conf and individualProgression.conf are now the upstream .dist verbatim with overrides applied on top. Verified live: 0 auctions on the partial config, 450 after the ah-bot swap, 1800 after the IP swap; missing-property warnings went 1431/startup to 0 once this PR's .dist seeding was also applied, with all 9 module configs loading.

dominik.polakovics added 1 commit

2026-08-21 01:00:58 +02:00

docs(dev-new): the ah bot fills all three houses, not just the seller's 655d960ee3

Both the config comment and ADR-0027 claimed the Horde auction house would
stay empty because all four characters are Alliance. It does not: the bot
posts to the Alliance, Horde and neutral houses alike, 1350 rows each on
the observed run.

dominik.polakovics merged commit 68dd2fd49d into main

2026-08-21 01:02:39 +02:00

dominik.polakovics deleted branch afk/wow-module-mounts

2026-08-21 01:02:39 +02:00

dominik.polakovics referenced this pull request from a commit

2026-08-21 01:02:41 +02:00

Merge pull request 'fix(dev-new): stop shadowing the image's modules dir, activate module configs' (#376) from afk/wow-module-mounts into main

dominik.polakovics referenced this pull request from a commit

2026-08-26 19:13:39 +02:00

fix(dev-new): re-run wow-config on every server start

dominik.polakovics referenced this pull request

2026-08-26 19:14:05 +02:00