Confluence in Docker container replaces confluence.cfg.xml on launch

[FelixII]

Hi,

I use the following command to start Confluence in a Docker container:

docker run -v ~/Docker/confluence:/var/atlassian/application-data/confluence --name="confluence" -p 8090:8090 -p 8091:8091 atlassian/confluence-server

The server starts up fine and I complete setup with the built-in database and an example site.

As soon as I stop and restart the container, Confluence greets me with the setup dialog again. Confluence shows the following messages in its startup log:

$ docker start -a confluence

INFO:root:Generating /opt/atlassian/confluence/conf/server.xml from template server.xml.j2

INFO:root:Generating /opt/atlassian/confluence/confluence/WEB-INF/classes/seraph-config.xml from template seraph-config.xml.j2

INFO:root:Generating /opt/atlassian/confluence/confluence/WEB-INF/classes/confluence-init.properties from template confluence-init.properties.j2

INFO:root:Generating /var/atlassian/application-data/confluence/confluence.cfg.xml from template confluence.cfg.xml.j2

INFO:root:User is currently root. Will change directory ownership to confluence then downgrade permissions

INFO:root:Running Confluence with command '/bin/su', arguments ['/bin/su', 'confluence', '-c', '/opt/atlassian/confluence/bin/start-confluence.sh -fg']

executing as current user

If you encounter issues starting up Confluence, please see the Installation guide at http://confluence.atlassian.com/display/DOC/Confluence+Installation+Guide

As you can see, Confluence overrides my existing confluence.cfg.xml with an empty template file.

What am I missing here? Do I have to pass an environment variable for Confluence to pick up its existing configuration file?

I was able to reproduce this issue on an Ubuntu 18.04 Server and on a Mac running macOS 10.14.6, both using the latest Docker version.

Thank you for your help!

UPDATE:

I conducted a little research and found out that the 'confluence.cfg.xml' is generated by a script called 'entrypoint.py' in the root directory of the container. I also found out that I can specify my database configuration with the following environment variables:

ATL_DB_TYPE=

ATL_JDBC_URL=

ATL_JDBC_USER=

ATL_JDBC_PASSWORD=

But even with these variables set, Confluence still boots to the setup screen on subsequent launches.

I wonder if this script is supposed to run on every container start? If so, how can I inject the remaining values (e.g. the license) and skip the setup? If not, how can I skip the generation step on subsequent launches of the container?

My current workaround is to inject a copy of 'entrypoint.py' into the container without the generation command. But this is merely a bad workaround and likely to cause issues with future updates. 

[Dave Chevell · Accepted solution]

This should now be fixed! Apologies for the showstopper bug. All versions have been rebuilt with a fix that doesn't overwrite an existing confluence.cfg.xml file.

[FelixII]

Thank you for the quick fix. It's working for me now.

[domdom]

Does this fix only concern the confluence.cfg.xml? I pulled the atlassian/confluence-server:latest yesterday and can not edit the server.xml. It get's reset to the templat on each restart of the container.

[Dave Chevell]

Hey @domdom ,

If you need to overwrite a config file (confluence.cfg.xml, server.xml) instead of using the normal method of supplying all configuration values in the environment, here's the supported way to do that:

All of these configuration files have templates that are stored in `/opt/atlassian/etc/`. They are Jinja2 templates (e.g. `confluence.cfg.xml.j2`), however you can overwrite them with a "plain" configuration file. For example:

FROM atlassian/confluence-server:latest

COPY confluence.cfg.xml /opt/atlassian/etc/confluence.cfg.xml.j2

We'll be updating our README's to explicitly document this as the way to overwrite the built in Jinja2 templates with your own custom config files.

Hope that helps!

[avoova]

@domdom 

If you want to edit items as proxyName, proxyPort, secure and scheme for the reverse proxy add this enviroments in the docker-compose file as follows:

- CATALINA_CONNECTOR_PROXYNAME=example.com
- CATALINA_CONNECTOR_PROXYPORT=443
- CATALINA_CONNECTOR_SCHEME=https
- CATALINA_CONNECTOR_SECURE=true

[domdom]

Thanks for your replies and helping me understand. A lot of ressources asking me to "edit server.xml" led me on the wrong path.

[Thomas Bergmann]

They rebuilt all Docker containers 2 days ago and introduced a new entrypoint, which overwrites existing config files with values from environment. But they simply forgot to document it on Docker Hub...

Anyway, my infrastructure is documented in a git repository and i don´t want any credentials stored there!

Same with Jira Docker images. Actually it´s a bug, they write on Docker Hub database environment variables are optional and you can set up via web gui on first start, but second time container starts, file will also be overwritten by entrypoint script.

Really, Atlassian???

My fix is to change file permissions of config files to 0400.

[niiku]

The file permission change of the confluence.cfg.xml to 0400 didn't work for me as the following snippet from the entrypoint.py runs as root and simply overwrites the existing file:

gen_cfg('confluence.cfg.xml.j2',
        f"{env['confluence_home']}/confluence.cfg.xml", env,
        user=env['run_user'], group=env['run_group'], mode=0o640)

 The workaround from FelixII worked, but as he already stated is only a temporary solution. 

[Thomas Bergmann]

Haven´t tested yet, too much downtime for a day...

But entrypoint.py changes file permissions after trying to write the file.

def gen_cfg(tmpl, target, env, user='root', group='root', mode=0o644): logging.info(f"Generating {target} from template {tmpl}") cfg = jenv.get_template(tmpl).render(env) with open(target, 'w') as fd: fd.write(cfg) set_perms(target, user, group, mode)

[Thomas Bergmann]

/entrypoint.py will run on every start rewriting your confluence.cfg.xml. If you set your database environment variables or not, license is still missing and you will always get the setup screen.

[Robert Alonso]

I found two issues (in 6.15.19) that I'm having to work around.

1) /entrypoint.sh's gen_cfg function has its "Overwrite" argument set to True by default.  I have to wonder why you'd *always* want to replace the config file with it's template version.  I changed this to be False.

2) The files which are being replaced (e.g. server.xml, confluence.cfg.xml, etc.) are already present in the base image anyway!  If the entrypoint is going to replace these anyway, I don't see why they're present to begin with.  If they weren't there, then a new container would create them anyway.  I changed it so these files aren't in the image.

Here's my Dockerfile that applies these changes:

#########################

ARG CONFLUENCE_VERSION
ARG UBUNTU_VERSION

FROM atlassian/confluence-server:${CONFLUENCE_VERSION}-ubuntu-${UBUNTU_VERSION}-adoptopenjdk8

# set default behavior to NOT overwrite configuration files with their corresponding templates
RUN sed -i 's/overwrite=True/overwrite=False/' /entrypoint.py

# Remove files whose presence would otherwise block the template versions from being
# copied in their place.  This will result in the template versions only being used 
# when a new container is created from this image and when the user does not provide 
# a host volume which binds to those paths in the container.
RUN rm -f ${CONFLUENCE_INSTALL_DIR}/{conf/server.xml,confluence/WEB-INF/classes/seraph-config.xml,confluence/WEB-INF/classes/confluence-init.properties,confluence.cfg.xml} ${CONFLUENCE_HOME}/confluence.cfg.xml

#########################

@Dave Chevell , you suggested a custom Docker image to work around this, but is there a reason my changes couldn't just be applied to Atlassian's official image?  It seems like it'd still work, at least for the use cases that I can imagine.  Thanks.

[Philipp Kayser]

i have the same issues with seraph-config

[Dave Chevell]

Hi @Philipp Kayser ,

See my above answer further up this page. You can supply your own version of the file by overwriting the template in /opt/atlassian/etc/seraph-config.xml.j2 (e.g. by building a new image with ours as the base image, then adding a COPY command to overwrite the template with your own)

Let me know if I’ve misunderstood or if that doesn’t help!

[avoova]

I have same problem with replacing confluence.cfg.xml and I have to stay with version 6.15.5 which is the last working one :( In another topic, @xbb suggested to use to another and functional image, but I prefer this one from Attlassian.

[niiku]

I tried a lot of versions and I think 6.15.5 is affected too, as Atlassian rebuild almost every image a few day ago, probably with an updated Dockerfile which now copies the problematic entrypoint.py file:

https://hub.docker.com/r/atlassian/confluence-server/tags

I guess you still have an old version of 6.15.5 on your server, and docker didn't pulled it again as it was already present. To be safe, better tag your current in use version, so you can fallback.

[avoova]

You're right, I didn't pull the 6.15.5 again. I'm lucky, I used the downloaded version.