[bitnami/wordpress] The customPostInitScripts do not run on upgrade

[thecrabcode]

Name and Version

bitnami/wordpress:latest

What architecture are you using?

arm64

What steps will reproduce the bug?

1. Add this config

customPostInitScripts:
  wp-home-blog.sh: |
    #!/bin/bash
    chmod +w /bitnami/wordpress/wp-config.php
    sed -i "s|define( 'WP_HOME', 'http://' . \\\$_SERVER\['HTTP_HOST'\] . '/' );|define( 'WP_HOME', 'https://' . \\\$_SERVER\['HTTP_HOST'\] . '/news' );|g" /bitnami/wordpress/wp-config.php
    sed -i "s|define( 'WP_SITEURL', 'http://' . \\\$_SERVER\['HTTP_HOST'\] . '/' );|define( 'WP_SITEURL', 'https://' . \\\$_SERVER\['HTTP_HOST'\] . '/news' );|g" /bitnami/wordpress/wp-config.php
    sed -i "/define( 'WP_SITEURL', 'http:\/\/' . \\\$_SERVER\['HTTP_HOST'\] . '\/news' );/a define( 'WP_CONTENT_URL', 'https://' . \\\$_SERVER['HTTP_HOST'] . '/news/wp-content/' );" /bitnami/wordpress/wp-config.php
    ln -s /opt/bitnami/wordpress /opt/bitnami/wordpress/news
    wp cli cache clear
    chmod 444 bitnami/wordpress/wp-config.php
  set-up-symlink.sh: |
    #!/bin/bash
    ln -s /opt/bitnami/wordpress /opt/bitnami/wordpress/news
    wp cli cache clear

.2 run helm upgrade wordpress bitnami/wordpress -n my-namespace -f helm-override-values-installer.yaml

Are you using any custom parameters or values?

yes I am using a custom values.yaml where I add this

customPostInitScripts:
  wp-home-blog.sh: |
    #!/bin/bash
    chmod +w /bitnami/wordpress/wp-config.php
    sed -i "s|define( 'WP_HOME', 'http://' . \\\$_SERVER\['HTTP_HOST'\] . '/' );|define( 'WP_HOME', 'https://' . \\\$_SERVER\['HTTP_HOST'\] . '/news' );|g" /bitnami/wordpress/wp-config.php
    sed -i "s|define( 'WP_SITEURL', 'http://' . \\\$_SERVER\['HTTP_HOST'\] . '/' );|define( 'WP_SITEURL', 'https://' . \\\$_SERVER\['HTTP_HOST'\] . '/news' );|g" /bitnami/wordpress/wp-config.php
    sed -i "/define( 'WP_SITEURL', 'http:\/\/' . \\\$_SERVER\['HTTP_HOST'\] . '\/news' );/a define( 'WP_CONTENT_URL', 'https://' . \\\$_SERVER['HTTP_HOST'] . '/news/wp-content/' );" /bitnami/wordpress/wp-config.php
    ln -s /opt/bitnami/wordpress /opt/bitnami/wordpress/news
    wp cli cache clear
    chmod 444 bitnami/wordpress/wp-config.php
  set-up-symlink.sh: |
    #!/bin/bash
    ln -s /opt/bitnami/wordpress /opt/bitnami/wordpress/news
    wp cli cache clear

What is the expected behavior?

I would expect that after a new pod is created I would find my changes in wp-config.php as well as finding a new symlink called news in bitnami/wordpress/

What do you see instead?

There is no symlink and when I check wp-config.php I can see some changes which I applied earlier, but the upgrade command is not working.

I don't want though to delete everything and re-install it. Am I doing something wrong, shouldn't those scripts run everytime a new pod is spinned up?

[javsalgar]

Hi,

I believe the issue has to do with how the init script logic is implemented:

# Only execute init scripts once
if [[ ! -f "/bitnami/wordpress/.user_scripts_initialized" && -d "/docker-entrypoint-init.d" ]]; then
    read -r -a init_scripts <<< "$(find "/docker-entrypoint-init.d" -type f -print0 | sort -z | xargs -0)"
    if [[ "${#init_scripts[@]}" -gt 0 ]] && [[ ! -f "/bitnami/wordpress/.user_scripts_initialized" ]]; then
        mkdir -p "/bitnami/wordpress"
        for init_script in "${init_scripts[@]}"; do
            for init_script_type_handler in /post-init.d/*.sh; do
                "$init_script_type_handler" "$init_script"
            done
        done
    fi

    touch "/bitnami/wordpress/.user_scripts_initialized"
fi

https://github.com/bitnami/containers/blob/main/bitnami/wordpress/6/debian-11/rootfs/post-init.sh#L26

As you are upgrading, the system is assuming that the init script have already been initialized. One solution to workaround this would be to enter the container and remove this file /bitnami/wordpress/.user_scripts_initialized. Then after upgrading it should work

[thecrabcode]

Hi @javsalgar,

thanks for the quick answer! I tried what you suggested but after the upgrade nothing happened. I have even manually killed the pod to make them start again, but with no luck. I've entered the container once again and I could see that a new /bitnami/wordpress/.user_scripts_initialized file was created, but when I checked if there was a symlink /opt/bitnami/wordpress/news, it wasn't there.

Just to make sure there was no actual problem with my scripts I checked inside /docker-entrypoint-init.d and I saw both my scripts, executed them manually and they worked as expected.

[thecrabcode]

Ok, so now I just changed a parameter in the autoscaling and upgraded again, and it worked for some reasons

[thecrabcode]

Interestingly enough, I wanted to change again the autoscale setting by going back to 2 (from 1) and what happened is that the new pod that has been created did not execute the scripts and so now I have 2 pods with 2 different configurations.

If it can help this is how my values.yaml is defined

wordpressUsername: ****
wordpressPassword: ****
mariadb:
  enabled: false
customPostInitScripts:
  wp-home-blog.sh: |
    #!/bin/bash
    chmod +w /bitnami/wordpress/wp-config.php
    sed -i "s|define( 'WP_HOME', 'http://' . \\\$_SERVER\['HTTP_HOST'\] . '/' );|define( 'WP_HOME', 'https://' . \\\$_SERVER\['HTTP_HOST'\] . '/news' );|g" /bitnami/wordpress/wp-config.php
    sed -i "s|define( 'WP_SITEURL', 'http://' . \\\$_SERVER\['HTTP_HOST'\] . '/' );|define( 'WP_SITEURL', 'https://' . \\\$_SERVER\['HTTP_HOST'\] . '/news' );|g" /bitnami/wordpress/wp-config.php
    sed -i "/define( 'WP_SITEURL', 'https:\/\/' . \\\$_SERVER\['HTTP_HOST'\] . '\/news' );/a define( 'WP_CONTENT_URL', 'https://' . \\\$_SERVER['HTTP_HOST'] . '/news/wp-content/' );" /bitnami/wordpress/wp-config.php
    wp cli cache clear
    chmod 444 bitnami/wordpress/wp-config.php
  set-up-symlink.sh: |
    #!/bin/bash
    ln -s /opt/bitnami/wordpress /opt/bitnami/wordpress/news
    wp cli cache clear
externalDatabase:
  host: ****
  port: ****
  user: ****
  password: ****
  database: wordpress
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 6
  targetCPU: 75
livenessProbe:
  enabled: true
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 35
  failureThreshold: 4
  successThreshold: 1
resources:
  limits:
    memory: 4Gi
    cpu: 800m
  requests:
    memory: 2Gi
    cpu: 500m
persistence:
  enabled: true
  storageClass: aws-efs
  accessModes:
    - ReadWriteMany
service:
  type: ClusterIP
containerSecurityContext:
  enabled: true
  capabilities:
    drop: ["ALL"]
  runAsUser: 1001
  runAsNonRoot: true
  allowPrivilegeEscalation: false
memcached:
  enabled: true
volumePermissions:
  enabled: false
  containerSecurityContext:
    capabilities:
      drop: ["ALL"]
    runAsUser: 1
    runAsNonRoot: true
    allowPrivilegeEscalation: false

[FraPazGal]

Hello @thecrabcode, I've reproduced your reported error and indeed the post-init scripts won't run in a helm upgrade. I have also run the workaround suggested by my colleague and it should work for you. Just to double-check, make sure to run the following command:

$ kubectl exec -it <your-wordpress-pod-name> -- rm /bitnami/wordpress/.user_scripts_initialized
$ helm upgrade ...

That said, we'll need to work out a more permanent fix; be it by updating the container logic or by adapting the chart. I have created an internal task for the team to work on this, though I won't be able to give you an ETA on this.

[thecrabcode]

Hi @FraPazGal thanks for the reply. I have tried the suggested command but it didn't work as expected. Although repeating the procedure a couple of times, i eventually re-run the post init scripts, but it was very much a hit & miss thing.

[ivmos]

I'm trying this final added customPostInitScripts as a workaround:

 clean-user_scripts_initialized.sh: |
      #!/bin/bash
      set -x
      (sleep 10 && rm -f /bitnami/wordpress/.user_scripts_initialized)&

However I feel that if you need to clean the flag it means you should be maintaining your own image instead.. E.g this is my use case: https://github.com/bitnami/charts/issues/25210 where perhaps I should just maintain the plugins as part of a custom image