helm install with default values fails

If I recall correctly, setting wpSalts: {} makes helm happy and should generate a random secret. So I think we only need to add such a line to values.yaml.

That would really surprise me. Are you sure you set wpSalts: {} and at the same time activated mu_cron? Because the problem is the fact that wpSalts.WP_CRON_CONTROL_SECRET does not exist. Helm does not generate random strings for variables that don't exist, that would be super weird.

TBH, revisiting this issue a month later I think mu_cron should be disabled by default. Then people won't run into this problem either.

Are you sure you set wpSalts: {} and at the same time activated mu_cron?

If mu_cron is enabled by default, then yes. With these values it works:

wordpress:
  config:
    db:
      prefix: wp_
    adm:
      usid: admin
      pssw: REDACTED
  site:
    default_language: en_US
    url: "http://testkubes.MYDOMAIN"
    title: "Wordpress on testkubes"

database:
  db:
    user: wordpress
    password: REDACTED
  rootUser:
    password: REDACTED
  replication:
    password: REDACTED

ingress:
  enabled: true
  path: /
  hosts:
    - testkubes.MYDOMAIN

wpSalts: {}

And removing the wpSalts: {} breaks it.

Because the problem is the fact that wpSalts.WP_CRON_CONTROL_SECRET does not exist. Helm does not generate random strings for variables that don't exist, that would be super weird.

Not by itself of course, but we instruct helm to do exactly that. From values.yaml:

WP_CRON_CONTROL_SECRET: {{ .Values.wpSalts.`WP_CRON_CONTROL_SECRET` | default ( randAlphaNum 32) }}

So it takes the wpSalts.WP_CRON_CONTROL_SECRET if present, and otherwise generates a random string. The only problem with this is that apparently the default function can handle an unset variable, but the "branches" in the variable name structure still have to exist, in this case wpSalts.

It's all coming back to me

With your suggestion helm doesn't fail during installation, but the cronjobs will fail because they don't have access to the secret that was generated by templates/secrets.yaml when templating the WP_CRON_CONTROL_SECRET template string.

Hm right. So if we want to generate a random value, it should be in the default value definition so both usage sites pick up the same thing. I'm not sure that is even possible: you can't use template functions in values.yaml by default, unless you use tpl in the value's usage sites but then I suspect it will generate a different random secret for every usage site .

Also, searching for information I found this:

There are functions in Helm that allow you to generate random data, cryptographic keys, and so on. These are fine to use. But be aware that during upgrades, templates are re-executed. When a template run generates data that differs from the last run, that will trigger an update of that resource.

Do you think the init container will overwrite the WordPress setting if it's run again with a different salt value? If not, letting Helm generate a random value will fail on upgrade for this reason.

Edit: something like this could work to prevent regenerating passwords/salts on upgrades. I'm not sure if it also fixes the problem of generating two different values in two usage sites, I think it actually might (depends on how helm does variable scoping in template functions) but we'd have to try it to be sure.

Another solutions that's easier for us chart authors is to always require this value to be set explicitly on helm install. For permanent installations that's actually what you'd want anyway, only for ephemeral/testing installs it's somewhat of a burden on the chart user (also mostly us ;-) ).

The value of this secret is actually also super unimportant. mu_cron needs it to be set and the client wanted it to not be the same for each installation, but the endpoint that you need to provide the secret to is only available in the Kubernetes internal network, so you can't do a DoS on it from the outside.

So I'd opt for the easy option of requiring it to be defined. But only if mu_cron is on. And mu_cron should be off by default IMO.

Ran into this again today on a fresh install. I believe the best short-term solution is to add wpSalts: {} to values-local.yaml.example so new users don't have to find this issue before creating their own workaround (such as hardcoding the salts). Here's what I'm adding to my values-local.yaml file when getting started:

# WORKAROUND
# BUG: https://open.greenhost.net/openappstack/wordpress-helm/-/issues/54
wpSalts: {}

I'd prefer if I didn't have to do this.

You can fix this by setting wpSalts: {} but only if you don't use mu_cron. I can't add this to values.yaml because it will break mu_cron.

Instead, I propose moving the WP_CRON_CONTROL_SECRET variable from the wpSalts to the mu_cron settings. That way it is also easier for the user to see that they need to set a WP_CRON_CONTROL_SECRET when they do enable mu_cron.

Background: mu_cron is a plugin that uses the Kubernetes cronjobs to run the WordPress cron endpoint every once in a while. It uses curl to access a cron endpoint and supplies a secret so that not everyone can use the endpoint to start cronjobs. Even though the endpoint is only available on the Kubernetes internal network, it's best to use a random secret. As far as I can see we can't let Helm set a random secret, so the user will have to choose one themself.

You can fix this by setting wpSalts: {} but only if you don't use mu_cron.

Ah, that explains my cron jobs are failing under k3s. I do want mu_cron so I'm glad it was failing loudly, leading me to this issue. I'll work on the proposed refactoring in a fork of my mirror and let you know when I have something reviewable.

BTW another tutorial using this chart. This one a microtutorial: https://habd.as/post/deadsimple-wordpress-kubernetes/

@balibebas please note that I already did the necessary refactoring in !29 (merged), it's under review at the moment.

mentioned in merge request !27 (merged)

mentioned in issue #62 (closed)

created merge request !29 (merged) to address this issue

mentioned in merge request !29 (merged)

closed with merge request !29 (merged)

mentioned in commit d6ffe670

helm install with default values fails

Designs

Child items 0

Activity

Admin message

helm install with default values fails

Activity