Skip to content

[BUG] Docker control plane: first-run setup friction (config carry-over, port collision, DB defaults) #325

Description

@Icehunter

Splitting these out of #311 so they do not get lost in that thread. All three came from @wofnull testing a control: docker install against the redblinks dune-docker stack, quoted verbatim below.

1. Existing ~/.dune-admin/ blocks setup carrying over to a new binary

i deleted the old .dune-admin folder in userfiles, as it hindered the -setup to carry over with the new excutable

Dropping a new binary next to an existing config should either reuse that config or let -setup overwrite it. Having to delete the whole directory to get setup to work is not an acceptable upgrade path, and it costs the operator their server registry and dashboard password too.

Needs reproducing: run -setup against a ~/.dune-admin/ written by an older version and find what specifically refuses to carry over. needsSetup() reads the servers store first and falls back to a flat-config heuristic (main.go:745), so the store and config.yaml disagreeing is a likely suspect.

2. Listen port collides with dune-docker, and 18080 is rejected

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"

Two things here.

The :18080 fallback in the wizard is gated on ctrl == "amp" (setup.go:87), because AMP's own panel takes 8080. dune-docker appears to have the same collision, so the docker control plane likely wants the same treatment, or a port probe.

"Port not set in config" does not appear anywhere in this repo, so that error is coming from the dune-docker stack rather than from us. @wofnull, could you confirm which process printed it and paste the surrounding output? That decides whether this is our bug or a config-shape mismatch with theirs.

3. Preset the dune-docker postgres defaults

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 )

runDockerSetup currently prompts for DB host with a default of database and asks for the password with no default. For a stock dune-docker install the answers are known: host 127.0.0.1, user dune, password dune. Offering those as defaults would remove two guesses from the flow.

Worth confirming they are stable across dune-docker versions before hardcoding them, since a wrong default is worse than no default here.

Scope

1 and 2 are bugs. 3 is a setup-flow improvement. They are grouped because they are all first-run friction on the same install type, but they can be split if that is easier to work.

Reported by @wofnull in #311.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions