Container (Redmine 6.0.1) not starting when using the REDMINE_SECRET_KEY_BASE environment variable

[Waigie]

The Redmine container is not starting when setting the REDMINE_SECRET_KEY_BASE environment variable as shown in the docker compose example.

Error message and stacktrace:

ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit` (ArgumentError)

          raise ArgumentError, "Missing `secret_key_base` for '#{Rails.env}' environment, set this string with `bin/rails credentials:edit`"
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application/configuration.rb:519:in `secret_key_base='
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application/configuration.rb:503:in `secret_key_base'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application.rb:470:in `secret_key_base'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application.rb:205:in `block in message_verifiers'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/message_verifiers.rb:132:in `build'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/messages/rotation_coordinator.rb:85:in `block in build_with_rotations'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/messages/rotation_coordinator.rb:85:in `map'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/messages/rotation_coordinator.rb:85:in `build_with_rotations'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/messages/rotation_coordinator.rb:19:in `[]'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application.rb:232:in `message_verifier'
/usr/local/bundle/gems/activerecord-7.2.2/lib/active_record/railtie.rb:355:in `block (3 levels) in <class:Railtie>'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:97:in `class_eval'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:97:in `block in execute_hook'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:87:in `with_execution_control'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:92:in `execute_hook'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:62:in `block in on_load'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:61:in `each'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:61:in `on_load'
/usr/local/bundle/gems/activerecord-7.2.2/lib/active_record/railtie.rb:354:in `block (2 levels) in <class:Railtie>'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:94:in `block in execute_hook'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:87:in `with_execution_control'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:92:in `execute_hook'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:78:in `block in run_load_hooks'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:77:in `each'
/usr/local/bundle/gems/activesupport-7.2.2/lib/active_support/lazy_load_hooks.rb:77:in `run_load_hooks'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application/finisher.rb:94:in `block in <module:Finisher>'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/initializable.rb:32:in `instance_exec'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/initializable.rb:32:in `run'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/initializable.rb:61:in `block in run_initializers'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/initializable.rb:60:in `run_initializers'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application.rb:435:in `initialize!'
/usr/src/redmine/config/environment.rb:16:in `<top (required)>'
/usr/local/bundle/gems/zeitwerk-2.7.1/lib/zeitwerk/core_ext/kernel.rb:34:in `require'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application.rb:411:in `require_environment!'
/usr/local/bundle/gems/railties-7.2.2/lib/rails/application.rb:559:in `block in run_tasks_blocks'
/usr/local/bundle/gems/rake-13.2.1/exe/rake:27:in `<top (required)>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)

[ctassell]

Yeah, this is a problem with the config/initializers/secret_tokens.rb file not existing. If you backup and delete the config/secrets.yml and set the REDMINE_SECRETS_KEY_BASE environmental variable to contain your secret key it should automatically generate that .rb file.
I actually just cloned the image, generated it manually with rake generate_secret_token, and then copied the rb file in, so I'm not 100% certain the file removal will work. It should from how I read the code though:

       if [ ! -s config/secrets.yml ]; then
                file_env 'REDMINE_SECRET_KEY_BASE'
                if [ -n "$REDMINE_SECRET_KEY_BASE" ]; then
                        cat > 'config/secrets.yml' <<-YML
                                $RAILS_ENV:
                                  secret_key_base: "$REDMINE_SECRET_KEY_BASE"
                        YML
                elif [ ! -f config/initializers/secret_token.rb ]; then
                        rake generate_secret_token
                fi
        fi

The new release seems a little buggy. My system got completely hosed when I upgraded. Still can't get a custom theme to be recognized.

[achernyakevich-sc]

The new release seems a little buggy. My system got completely hosed when I upgraded. Still can't get a custom theme to be recognized.

@ctassell Redmine 6.0.x has incompatible changes about Themes. Maybe this is the root of your problems. See:

• https://www.redmine.org/projects/redmine/wiki/Themes
• https://www.redmine.org/issues/39111

I hope it helps. :)

[ctassell]

Thanks, I reverted back to 5.1 for now, I'll make sure to bookmark that so our web dev can upgrade the theme when we are prepared to migrate. One of our plugins also had issues, it must need to be patched as well.

[Waigie]

@ctassell Thanks for the help, i'll tests it as soon as possible

[peter-hank]

A quick fix is to remove the REDMINE_SECRET_KEY_BASE: supersecretkey environment variable from your docker compose yml. The secret key will be then generated automatically.

[ctassell]

A quick fix is to remove the REDMINE_SECRET_KEY_BASE: supersecretkey environment variable from your docker compose yml. The secret key will be then generated automatically.

Does doing this cause issues with an existing setup? I'm wondering if there is anything in the DB that uses the secret key and is not going to get properly decrypted, or if it's just for cookies and the like?

[DerDummePunkt]

This issues cost me more time today then I'm willing to admit ;)

A quick fix is to remove the REDMINE_SECRET_KEY_BASE: supersecretkey environment variable from your docker compose yml. The secret key will be then generated automatically.

Does doing this cause issues with an existing setup? I'm wondering if there is anything in the DB that uses the secret key and is not going to get properly decrypted, or if it's just for cookies and the like?

According to the readme

This variable is required when using Docker Swarm replicas to maintain session connections when being loadbalanced between containers. It will create an initial config/secrets.yml and set the secret_key_base value, which is "used by Rails to encode cookies storing session data thus preventing their tampering. Generating a new secret token invalidates all existing sessions after restart" (session store⁠). If you do not set this variable or provide a secrets.yml one will be generated using rake generate_secret_token.

So, as long as you aren't using Docker Swarm or using scale with docker compose, you should be good, its only used for consistent session management across multiple redmine backend containers as far as i understand it.

I also just removed the env variable from the service and everything's running just fine.

[lupa18]

A quick fix is to remove the REDMINE_SECRET_KEY_BASE: supersecretkey environment variable from your docker compose yml. The secret key will be then generated automatically.

I did it but I got the same error:

app-1  | rake aborted!
app-1  | ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit` (ArgumentError)
app-1  | 
app-1  |           raise ArgumentError, "Missing `secret_key_base` for '#{Rails.env}' environment, set this string with `bin/rails credentials:edit`"
app-1  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app-1  | /usr/local/bundle/gems/railties-7.2.2/lib/rails/application/configuration.rb:519:in `secret_key_base='

[DerDummePunkt]

A quick fix is to remove the REDMINE_SECRET_KEY_BASE: supersecretkey environment variable from your docker compose yml. The secret key will be then generated automatically.

I did it but I got the same error:

app-1  | rake aborted!
app-1  | ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `bin/rails credentials:edit` (ArgumentError)
app-1  | 
app-1  |           raise ArgumentError, "Missing `secret_key_base` for '#{Rails.env}' environment, set this string with `bin/rails credentials:edit`"
app-1  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
app-1  | /usr/local/bundle/gems/railties-7.2.2/lib/rails/application/configuration.rb:519:in `secret_key_base='

Can you check if the file /usr/src/redmine/config/secrets.yml exists in your redmine container?

Unless you put some secret in there yourself, remove the file and restart the container. that might fix it.

@ctassell pointed this out in his comment, the code in the entrypoint is kinda weird:

• it checks whether config/secrets.yml does not exist or is of non-zero size
• if the file is missing or empty (this should be true the first time you start a container from the image), it tries to grab a value for REDMINE_SECRET_KEY_BASE from either an env var a an env var pointing to a text file
• if that is not none, the value is put into config/secrets.yml. I dont know if its the cat statement that fails or somehting else, the result, having the secret.yml file wihtout something else, causes redmine to crash at startup, there something missing here
  EDIT:
• if it is none, it checks if config/initializers/secret_token.rb exists, i think this file should be absent in new containers
• if the file does not exist, rake generate_secret_token is called, that creates config/initializers/secret_token.rb with the secret key
• i think on subsequent starts the same outer loop is entered, but if no env value for REDMINE_SECRET_KEY_BASE is provided, nothin happens and remine boots, since config/initializers/secret_token.rb now exists

You cant really fault the authors of the Dockerfile. The way you have to configure redmine is, uhm, bad? Its inconsistent and all over the place, some things can be done by Env vars, some in config yml files, others in ruby files, it changes with every release, redmines documentation doesnt alwayss refelct that, etc...

[LaurentGoderre]

It might be simpler to user the compose way to add secrets instead:

https://docs.docker.com/compose/how-tos/use-secrets/

[lupa18]

Thanks for your answer !

Can you check if the file /usr/src/redmine/config/secrets.yml exists in your redmine container?

I'm using a docker-compose file (that is working on redmine v5) with mysql and had tried 2 main configs now:

1. With my own Dockefile (pushing configuration and database yml files) tested these options:
1.1. No env variable, no file secrets.yml -> file doesn't autogenerate -> doesn't start
1.2. env variable, no file -> file doesn't autogenerate -> doesn't start
1.3. env variable, pushing file secrets.yml (see below) -> doesn't start with error previously reported

secrets.yml content:

production:
  secret_key_base: <%= ENV["REDMINE_SECRET_KEY_BASE"] %>

2. Directly as image:

• Another error:

Gem::LoadError: mysql2 is not part of the bundle. Add it to your Gemfile. (Gem::LoadError)

despite:

• I has no Gemfile persistence
• I has configured REDMINE_DB_MYSQL env var

I see now reported #353 and #354

[kuzakov]

The same problem on redmine:6.0.2
Guys, can we help you? That's too long guys...

[tianon]

Do you know what's causing it? What needs to be changed to fix it? (When I looked into it, the relevant documentation suggested doing things exactly the way we currently do, so there's more research required.)

[tianon]

A PR that demonstrates a fix would definitely be helpful.

[kuzakov]

Yesterday, I took the redmine:6.0.2 image from Dockerhub and tried to deploy in k8s - I got the same error...