This is an automated comment for commit 65435a3 with description of existing statuses. It's updated for the latest CI running

✅ Click here to open a full report in a separate page

@Felixoid, when the password for the default user is already set in one or another configuration file, it should not argue. Configuration files can be mapped to the container in numerous ways.

why you choose to runtime change configuration files inside the container in entrypoint.sh Instead of just change docker_related_config.xml? These changes mixed declarative configuration approach on build time.

Because there was a code that managed users, hardcoding defaults looked worse at the time. The purpose of the changes is pushing users to set up the user/password.

These changes actually will just break many installations, which will use read-only volumes for /etc/clickhouse-server or /etc/clichouse-server/users.d/

That was another point in favor of adding CLICKHOUSE_SKIP_USER_SETUP to make default as before. AFAIK, the RBAC user management is used for such cases. Unfortunately, not everyone is so advanced to set it up.

This is not make clickhouse-server docker installation more secure because most of the users just will decide CLICKHOUSE_SKIP_USER_SETUP=1 and default without password user will still present

Then it's on the user to leave the DB completely open, right?

when the password for the default user is already set in one or another configuration file, it should not argue. Configuration files can be mapped to the container in numerous ways.

It's an interesting point that could be implemented. However, making it work is tricky because of the numerous ways.

The 100% working way would imply the patch to clickhouse-extract-from-config that would automatically read the users' configuration by an arg '--users'. Something like

Then we can check the content of users.default for keys password, password_sha256_hex, password_double_sha1_hex, ldap.server, or kerberos.

Then we can check the content of users.default for keys password, password_sha256_hex, password_double_sha1_hex, ldap.server, or kerberos.

I would say just check that the user is configured, regardless of the password*/no_password, since if he provides the config - it was the "explicit intention"

It's a chicken-egg issue, kind of.

That means we need to compare the content of the default user to the "matrix" one. Copy /etc/clickhouse-server/users.xml into /tmp and compare the output to the one without users.d?

It looks like the #75643 addresses all concerns, especially the case when default user is already changed somehow

I don't want to beat about the bush, but I kind of liked the way clickhouse images works before, no need to set any env variables - it just works (unlike mysql, where you need to go and read documentation for the image make it run)

Everybody interesting in checking the fix from #75643 is working, you can build it as following:

cd ClickHouse # repo root
git fetch https://github.com/ClickHouse/ClickHouse.git improve-entrypoints
git checkout improve-entrypoints
docker buildx build --output=type=docker --platform=linux/amd64 --label=build-url=https://github.com/ClickHouse/ClickHouse/actions/runs/13187011934 --label=com.clickhouse.build.githash=183c840f10c9d869e5346357b3e7a6037247a9b4 --label=com.clickhouse.build.version= --build-arg=DIRECT_DOWNLOAD_URLS='https://s3.amazonaws.com/clickhouse-builds/PRs/75643/579c3023f7188f156e9a08320f522da467ccf2f9/package_release/clickhouse-client_25.2.1.1202_amd64.deb https://s3.amazonaws.com/clickhouse-builds/PRs/75643/579c3023f7188f156e9a08320f522da467ccf2f9/package_release/clickhouse-common-static_25.2.1.1202_amd64.deb https://s3.amazonaws.com/clickhouse-builds/PRs/75643/579c3023f7188f156e9a08320f522da467ccf2f9/package_release/clickhouse-server_25.2.1.1202_amd64.deb' --tag=clickhouse/clickhouse-server:head-amd64 --build-arg=VERSION='25.2.1.1' --progress=plain --file=docker/server/Dockerfile.ubuntu docker/server

@Felixoid

Then it's on the user to leave the DB completely open, right?

Nobody leaves anything open. Users are mapped from config maps or volumes or files.
Obviously read-only for security reasons. And then all other users are managed from DDL.
That setup is completely destroyed by the PR here.

@Slach

Hope, these changes not relates to the latest deepseek stupid installation mistakes

They for sure are. The Wiz attention whoring was hilarious though.
The right course of action is to ignore. But you know...

That setup is completely destroyed by the PR here.

Does it mean you've seen the code from the message above on how to check the follow-up PR?

What was the result?

We have checked it for the read-only volumes with the entrypoint.sh from #75643

Since everyone who commented on the PR has not provided feedback since last week, it either works or nobody wants to help.

I'll give it more time to try it out, and the check for the changed default user will be merged and backported tomorrow.

@Felixoid, could you add this change to the breaking changes section in the changelog? This would have saved me troubleshooting time.

I added a note.

Together with #75643, it's much less intrusive. Could you test the latest image, please? It's 25.1

Releases 24.3, 24.8, 24.11, and 24.12 don't have it backported yet

@Felixoid: I tested the image, but in my use case it still breaks the CI pipeline running integration tests as it is started like docker run --rm -p 127.0.0.1:9000:9000 clickhouse/clickhouse-server:latest. Using -e CLICKHOUSE_SKIP_USER_SETUP=1 brought back the old behavior.

Here is an example of such a CI pipeline.

Yes, the -p 127.0.0.1:9000:9000 doesn't work as the localhost under the hood https://github.com/ClickHouse/ClickHouse/pull/74605/files#diff-cb35cbd88e33b5c202774e3e47b97fb914a161f8a67e98d3c453ef57a56e81d1R76

To address it, --network=host will help.

I'll take the documentation part from the #74605 and will update it on the docker hub ASAP.

update: #76207

That setup is completely destroyed by the PR here.

Does it mean you've seen the code from the message above on how to check the follow-up PR?

What was the result?

I'm not sure how to answer that one.
I have a perfectly secure (as it can get) flow.
Now I need to change it for no reason.
No matter the setup, I need to change it. Because it fails.
Obviously the easiest change for me was just to set CLICKHOUSE_SKIP_USER_SETUP=1 to remove the strange attempt at "security" that just brings more headache. :)
In the future I think I will just return to building the image myself with a proper entrypoint.

No matter the setup, I need to change it. Because it fails.

With the latest image version, the user setup step is automatically omitted if the user default is changed in the users.d.

No matter the setup, I need to change it. Because it fails.

With the latest image version, the user setup step is automatically omitted if the user default is changed in the users.d.

That's much better! Unfortunately I don't see which version of CH supports --users ...

I think you mean the clickhouse-extract-from-config command.

25.1 supports it, as does the latest master.

I plan to update the rest of the active releases on Monday.

Which one of the 25.1s? Lol
25.2 does not support it asa far as I'm concerned:

std::exception. Code: 1001, type: boost::wrapexcept<boost::program_options::unknown_option>, e.what() = unrecognised option '--users' (version 25.2.1.1840 (official build))

the most recent one, 25.1.4.53, supports it

$ clickhouse-extract-from-config --version
std::exception. Code: 1001, type: boost::wrapexcept<boost::program_options::unknown_option>, e.what() = unrecognised option '--version' (version 25.1.4.53 (official build))
$ clickhouse-extract-from-config --help |& grep users
  --users                  Return values from users.xml config

The master supports it too, that's how to check it:

$ bash -c "$(curl https://clickhouse.com)"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2911    0  2911    0     0  35461      0 --:--:-- --:--:-- --:--:-- 35938
ClickHouse binary clickhouse already exists. Overwrite? [y/N] y

Will download https://builds.clickhouse.com/master/amd64/clickhouse into clickhouse

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  121M  100  121M    0     0  12.4M      0  0:00:09  0:00:09 --:--:-- 12.5M

Successfully downloaded the ClickHouse binary, you can run it as:
    ./clickhouse

You can also install it:
sudo ./clickhouse install
$ ./clickhouse extract-from-config --help |& grep users
  --users                  Return values from users.xml config
$ ./clickhouse extract-from-config --version
std::exception. Code: 1001, type: boost::wrapexcept<boost::program_options::unknown_option>, e.what() = unrecognised option '--version' (version 25.2.1.2374 (official build))

update

Or, the same with docker run

> docker run -it --rm clickhouse/clickhouse-server:25.1 clickhouse-extract-from-config --help |& grep users
  --users                  Return values from users.xml config
> docker run -it --rm clickhouse/clickhouse-server:head clickhouse-extract-from-config --help |& grep users
  --users                  Return values from users.xml config