[BUG] Install Type Docker, propably non working

[wofnull]

Describe the issue

During setup, the setup tool asks for the name of the gameserver container ... well there are more than one, one for every Map loaded, other containers aswell, needs to be specified.

available containers after a clean docker install ( server running ) with redblinks dune-docker Installer:

if a random of the game containers is selected, the installer works through the install process, but ends up only "half-working":

Environment (auto-filled by dune-admin)

• dune-admin version: 0.47.0
• commit: 4e0eff3
• build: 2026-07-23T08:53:37Z
• control plane: docker
• executor: local
• db connected: true
• ssh connected: false
• browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36

[Icehunter]

@wofnull test build is up if you want to try it: https://github.com/Icehunter/dune-admin/releases/tag/test-pr315

Grab dune-admin_linux_amd64.tar.gz. The web UI is bundled into the binary so there is nothing else to build.

tar -xzf dune-admin_linux_amd64.tar.gz
chmod +x dune-admin
./dune-admin

It reads your existing ~/.dune-admin/ config and does not modify it, so you can switch back by running your current binary again.

The cause was that setup only ever asked for one game server container name. Your install runs one per map, so whichever you picked was the only one dune-admin knew about, which is why the server table was empty and start/stop only cycled one container. This build finds them all by matching the seabass-server image, which is what separates the real game servers from dune-server-gateway and dune-text-router.

Four things worth checking:

1. Server Health lists your map containers instead of "No game servers found"
2. Database reads Connected rather than a dash
3. Battlegroup state reads Running while the containers are up
4. Restart cycles all of your map containers, not just one

If it picks the wrong set, you can override it in config.yaml and the explicit list always wins:

docker_gameservers:
  - dune-server-overmap
  - dune-server-deepdesert-1-8
  - dune-server-survival-1

One known gap: the partition and port columns come from the game process arguments, and that bit is inferred from how the AMP setup works rather than confirmed on docker. If the containers show up but those two columns are blank, that is the gap and not a new problem. Let me know either way.

Details in #315.

[wofnull]

First a few notes for the setup process:

• i deleted the old .dune-admin folder in userfiles, as it hindered the -setup to carry over with the new excutable
• base password for the postgres installation is dune and can be userchanged if needed, its locked to local access via 127.0.0.1 only, connection via other IPs does not work ( dune-docker based setting ) ( therefore PW and host can be preset )
• if dune-docker is started WITHOUT any setup it starts on port 18080, web setup is missing the new "setup steps"
• if dune docker is started WITH setup parameter it sets up on port 8080. If manually set to 18080, the dune-docker start, denies starting up with error "Port not set in config"

Coming to the "Docker Server", after setup was run:

With one connected player at surivial_1:

one player in overworld:

dd:

as i thought during the base setup - what happens if a map is loaded , which was not there on runtime during dune-admin setup? I entered Arakeen, new map server did not registered on panel:

As I read through the changes of this fix, it is mentioned that the logic was to identify based on the namespace dune-server-* , but found that there are many dune-server-* spawned including ones that are no gameservers at all, thus needed a specification, which to use. Well thats basicly working, but would it not be better to identify all dune-server-* container and

Variant a) exclude known not "gameserver" containers , to be excluded by a blacklist
or
Variant b) auto include the well known names of all real *gameserver" containers?

Both versions would erase the need to specify the gameserver containers at all, and would enable the script on runtime to register if additional mapserver pods would be started

[wofnull]

I also did a resetup with arrakeen / harkovillage / DD / overmap / 2 active sietches to verify setup works on "custom" installs aswell

[wofnull]

For your requested checks:

• Server Health lists your map containers instead of "No game servers found"

Verified, with the limitation that new spun up mapservers are not visible.

• Database reads Connected rather than a dash

Database reads connected

• Battlegroup state reads Running while the containers are up

State reads correctly aswell

• Restart cycles all of your map containers, not just one

Verified, restarts, restarts all containers successfull ( even though the new 0.47.1 single map restart button is missing here )

[wofnull]

@Icehunter , Still waiting for a reply to progress further in the fix for the implementation here, the test server is now up for about 2 weeks, and tests are done with my notes added.

[Icehunter]

@wofnull sorry for the delay, and thanks for the thorough testing. Both gaps you found are fixed in #315.

New map servers not showing up. You were right about the cause, and your Variant b is what the code already does at runtime: it matches on the seabass-server image, which is how dune-server-gateway and dune-text-router get excluded without a blacklist. The problem was the setup wizard. It wrote the detected names into docker_gameservers, and an explicit list short-circuits that detection, so the layout froze at whatever was running during setup.

Pinning is now opt-in. The wizard defaults to blank, which means detection re-runs on every status poll, so Arrakeen would appear on its own after you enter it. You can still pin specific containers if detection ever picks the wrong ones. If you have an existing config.yaml, delete the docker_gameservers key to get the live behavior.

Single map restart button missing. The backend already had it, the button was just hidden. The Battlegroup tab decided whether to show it by checking the control plane name against a hardcoded kubectl, so docker never qualified even after it gained the capability. The backend now reports the capability directly and the UI asks for it, so the button shows on docker and this cannot happen again for a future control plane.

On your setup notes: the port and postgres password observations are a separate thing from this issue. Worth its own ticket so they do not get lost here.

I will post a fresh test build once CI is green.

[Icehunter]

@wofnull new test build with both fixes: https://github.com/Icehunter/dune-admin/releases/tag/test-pr315-2

tar -xzf dune-admin_linux_amd64.tar.gz
chmod +x dune-admin
./dune-admin

arm64 is there too if you need it. SHA256 for amd64 is 86822617be6e411dc7ab07b0e1971e0d84e9f5da6185ce6953094bccd3bd770c.

One config step. Your config.yaml from the last build has docker_gameservers pinned to the three containers that were running during setup. Delete that key, or re-run -setup and press Enter at the game server prompt. Either way detection goes live.

Two things to check when you get a chance:

1. Start a map server that was not running at setup time, the Arrakeen case from before, and see whether it appears on Server Health within a poll cycle. Default poll is 30s.
2. Confirm the per-map restart button now shows on each row in the Battlegroup table, and that using it cycles only that one container.

No rush, and thanks for keeping the test server up this long.

[Icehunter]

Split your setup notes out into #325 so they do not get buried here: the config carry-over problem, the 18080/8080 collision, and presetting the dune-docker postgres defaults.

One question waiting for you there — "Port not set in config" is not a string anywhere in this repo, so it is coming from the dune-docker side. If you can tell me which process printed it, that decides whether it is ours to fix.

This issue stays open for the multi-container fix itself, pending your test of test-pr315-2.