mariadb.existingSecret doesn't seem to be working

[v1nsai]

Describe your Issue

When using an existing secret with the bitnami mariadb chart config, nextcloud pod is unable to log into mariadb. The existing secret contains the keys specified in the values.yaml file. When omitting mariadb.existingSecret, the pod starts up no problem.

Logs and Errors

$ kubectl logs -n nextcloud nextcloud-mariadb-0
2024-01-04 15:25:42 150 [Warning] Access denied for user 'nextcloud'@'10.1.72.175' (using password: YES)
2024-01-04 15:25:44 151 [Warning] Access denied for user 'nextcloud'@'10.1.72.175' (using password: YES)
2024-01-04 15:25:46 152 [Warning] Access denied for user 'nextcloud'@'10.1.72.175' (using password: YES)
...

Describe your Environment

• Kubernetes distribution: MicroK8s v1.28.3 revision 6089

• Helm Version (or App that manages helm): Microk8s Helm version.BuildInfo{Version:"v3.9.1+unreleased", GitCommit:"6303a77a1c2a0be76eaec96531e0a99bddec959a", GitTreeState:"clean", GoVersion:"go1.20.10"}

• Helm Chart Version: latest

• values.yaml: N/A because I am avoiding using a separate values.yaml for simplicity and always using the latest. Here's my helm command:

helm install nextcloud nextcloud/nextcloud \
    --namespace nextcloud \
    --set ingress.enabled=true \
    --set nextcloud.host=$NC_HOST \
    --set nextcloud.username=admin \
    --set nextcloud.existingSecret.enabled=true \
    --set nextcloud.existingSecret.secretName=$NC_ADMIN_SECRET_NAME \
    --set internalDatabase.enabled=false \
    --set externalDatabase.enabled=true \
    --set mariadb.enabled=true \
    --set mariadb.auth.existingSecret=$MARIADB_SECRET_NAME \
    --set persistence.enabled=true \
    --set persistence.storageClass=$STORAGECLASS

Additional context, if any

I've checked 1000 times to make sure that I'm including the proper keys in the mariadb-passwords secret, this looks correct to me

$ kubectl describe secret -n nextcloud $MARIADB_SECRET_NAME
Name:         mariadb-passwords
Namespace:    nextcloud
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
mariadb-replication-password:  28 bytes
mariadb-root-password:         28 bytes
password:                      28 bytes
mariadb-password:              28 bytes

I created all of the passwords with openssl rand -base64 20, if that makes any difference

[wrenix]

you use the wrong values for setup to work with an existing/externalDatabase.

you need to use externalDatabase.existingSecret instatt of mariadb.auth.existingSecret.

PS: a look in your secret ... i thing you need also to set also externalDatabase.existingSecret.passwordKey=...

[MohammedNoureldin]

After checking the definition of the templates, I confirm what @wrenix said.

It turns out that externalDatabase.existingSecret must be used to specify the same secret the dependency-db-chart uses, otherwise the variables will be used.

[hagak]

After checking the definition of the templates, I confirm what @wrenix said.

It turns out that externalDatabase.existingSecret must be used to specify the same secret the dependency-db-chart uses, otherwise the variables will be used.

Also just confirmed this bug as well. I ran into the same issue as @wrenix and when reviewing the templates came to the same conclusion that their is a bug in the helm charts.

[wrenix]

I do not see any bug here, that is an expected behaviour.

Option 1: you use the internalDatabase with the dependencies of an mariadb Option 2: you use another database, so you could use externalDatabase

but here in this issue the person disabled the internalDatabase / depenencies mariadb-chart and wonder, that the have to use externalDatabase.existingSecret instatt of mariadb.auth.existingSecret

[hagak]

If you use the mariadb.authexistingSecret this failure happens while using the mariadb.enabled. The workaround is to set the externalDatabase.existingSecret even though you are NOT enabling externalDatabase since you are using mariadb. This is very much a bug.

[hagak]

Here is the issue, notice how mariadb.auth.existingSecret is not referenced at all.

{{- if .Values.mariadb.enabled }}
        - name: mariadb-isalive
          image: {{ .Values.mariadb.image.registry | default "docker.io" }}/{{ .Values.mariadb.image.repository }}:{{ .Values.mariadb.image.tag }}
          env:
            - name: MYSQL_USER
              valueFrom:
                secretKeyRef:
                  name: {{ .Values.externalDatabase.existingSecret.secretName | default (printf "%s-db" .Release.Name) }}
                  key: {{ .Values.externalDatabase.existingSecret.usernameKey }}
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: {{ .Values.externalDatabase.existingSecret.secretName | default (printf "%s-db" .Release.Name) }}
                  key: {{ .Values.externalDatabase.existingSecret.passwordKey }}
'''

[wrenix]

@hagak okay i understand your bug -> but that is a different "bug" like @v1nsai describt.

@v1nsai values is

mariadb:
  enabled: true
  existingSecret: ".."
internalDatabase:
  enabled: false
externalDatabase:
  enabled: true

@hagak values is

mariadb:
  enabled: true
  auth:
    existingSecret: ".."

and you are correct, that product a bug in several places

[v1nsai]

Thanks for the hints @wrenix , I understand the problem now. I wasn't configuring how to connect to the "external" database in the externalDatabase config. I got it working by adding those connection details for externalDatabase and not messing with internalDatabase at all:

externalDatabase:
    enabled: true
    existingSecret:
        enabled: true
        secretName: mariadb-passwords
        usernameKey: mariadb-username
        passwordKey: mariadb-password
    mariadb:
        enabled: true
        auth:
            existingSecret: mariadb-passwords

[jessebot]

Thanks for your help on this @wrenix :) I understand the word internalDatabase is confusing, but it's referring to the embedded sqllite database. Perhaps we should change that to be sqlliteDatabase? 🤔

Also we have some docs on that here now: https://github.com/nextcloud/helm/tree/main/charts/nextcloud#database-configurations

[provokateurin]

Agreed, the name is confusing and not helpful at all. Let's change it :)

[provokateurin]

TBH when this breaking change is made we could also set it to disabled by default since nobody should really be using SQLite as a database except for development purposes, so anyone deploying on k8s definitely doesn't want it.