nextcloud / helm

A community maintained helm chart for deploying Nextcloud on Kubernetes.
GNU Affero General Public License v3.0
295 stars 258 forks source link

mariadb.existingSecret doesn't seem to be working #506

Open v1nsai opened 6 months ago

v1nsai commented 6 months ago

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

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

@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 commented 3 months ago

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