ability to change admin password build-time

[eduarddrenth]

At the time there is no documented solution to change the admin password build-time.

See also https://github.com/eXist-db/docker-existdb/issues/52#issuecomment-492604937 for a failing attempt to set the admin password build-time.

[duncdrum]

the command you were passing included a variable substitute for the password. Both on Travis and on my local setting the password seems to work as expected. Could you try without variable substitution and see if that works?

[eduarddrenth]

Hi, I already did, does not help. I'll see if I can pinpoint more precisely or can create a reproducer.

Perhaps first thing to try is run using "docker run" instead of "stack deploy".

[eduarddrenth]

docker run works, docker-compose up works, stack deploy doesn't.

and my password variable isn't substituted, so I have to look into that.

[eduarddrenth]

passing the password as a ARG works, but...I get:

XMLDBException: err:XPDY0002 variable '$ADMINPW' is not set

Variables in a RUN command aren't substituted by docker, but by shell, which we do not have.

I do not want to have passwords in my Dockerfile. The setup with java distroless makes it impossible to pass an ARG to java/XQuery as far as I can see.

[duncdrum]

No it is possible to use ARG as we documented here and in in our Dockerfile here

That being said, I would recommend using Buildkit to pass a password to the build.

In either case your password will not appear in the Dockerfile itself in the clear. However, the second method adds additional protection, so that the password cannot be retrieved from an analysis of individual layers or via docker inspect

[eduarddrenth]

Perhaps I do not explain clear enough and I don't understand what you mean. I know ARG can be used, I know predefined java system properties can be set, but that does not help.

If I do this:

ARG PW
RUN ["java", "-jar", "start.jar", "client", "--no-gui", "-l", "-u", "admin", "-P", "", "-x", "sm:passwd('admin','${PW}')"]

Xquery receives the string '${PW}' and sets that as password.

If I do this:

ARG PW
RUN java -jar start.jar client --no-gui -l -u admin -P "" -x "sm:passwd('admin','${PW}')"

It will fail, there is no shell.

If I do this:

ENV JAVA_TOOL_OPTIONS \
-DPW=${PW}
RUN ["java", "-jar", "start.jar", "client", "--no-gui", "-l", "-u", "admin", "-P", "", "-x", "sm:passwd('admin',$PW)"]

xquery tries to resolve $PW, which fails.

So I do not know where to go from here. I would prefer not to use builkit, yet another technology for our small organization.

[duncdrum]

this all covered by the docker docks using ARG variable you should set an ENV and ARG (with a default value). So the Run Command can get it, from the --build-arg command mentioned in the readme.

You might have to tweak the sytnax with respect to shell escaping rules based on your shell, which is also covered by the docker docs for RUN.

Build-kit is included with recent docker releases, so no need for new tech if your docker is up to date.

[eduarddrenth]

This doesn't work either (password will be "${ADMINPW}"), plus I do not want an ENV variable for a password:

ARG ADMINPW
ENV ADMINPW ${ADMINPW}
RUN ["java", "-jar", "start.jar", "client", "--no-gui", "-l", "-u", "admin", "-P", "", "-x", "sm:passwd('admin','${ADMINPW}')"]

Do you have a working example where you set the admin password during build using ARG?

By the way I do have a workaround: manually setting the password in the Dockerfile before building and removing it after building.

[eduarddrenth]

Forked the repo to solve this. As I understand it you don't see this problem when using distroless and java shell not interpreting docker variables. In the fork also removed EXPOSE and set MaxRAMFraction=2, because 1 is not advised in production.

[eduarddrenth]

Solved all problems I had (set admin pw, reboot with stack deploy, have shell available), perhaps what I did is of use, see:

https://github.com/fryske-akademy/docker-existdb?organization=fryske-akademy&organization=fryske-akademy

and

https://bitbucket.org/fryske-akademy/exist-db/src/master/docker/

[duncdrum]

@eduarddrenth glad you got something that is working for you. The reason that HEALTHCHECK causes a reboot is that you configured that in your compose-file:

restart_policy:
        condition: on-failure

Since you have not provided a heathcheck in your own dockerfile, docker-swarm will take the healthcheck from the parent image. This is very much working as intended and documented.

As for the Ram Fraction, I would take the warning about production with a grain of salt. This depends very much on your sever environment, and the kind of tasks exist is asked to perform. Of the 5 production systems I m currently running: 3 are 1 and 2 ar 2. I haven't had a problem in 16months with the 1s, but as I said it many factors go into this. If you want to be on the safe side 2 is a good option, as mentioned in the Readme.

[eduarddrenth]

I know swarm was rebooting because of on-failure in combination with a failing HEALTHCHECK. The changed admin password makes it fail. For now I chose to remove the HEALTHCHECK in the fork, but I think I'll revert that and unset it in the child Dockerfile.

But I thought it would be good to have a safe value in the parent by default. See https://stackoverflow.com/questions/49854237/is-xxmaxramfraction-1-safe-for-production-in-a-containered-environment

Thanks for thinking along, and I do read and test based upon available docs by the way.