`DB_DATABASE` path not respected by entrypoint script.

[mattcl]

Describe the bug When setting DB_DATABASE to something other than /srv/database/database.sqlite, entrypoint.sh creates the database at /2fauth/database.sqlite then links it to a hardcoded /srv/database/database.sqlite. This causes the container to crash with Database file at path [<your path>] does not exist

To Reproduce Steps to reproduce the behavior:

1. Using the docker compose instructions, change the value of DB_DATABASE

Expected behavior I would expect the entrypoint to create the database at the location specified by DB_DATABASE

Additional context For context, I'm sticking with sqlite for now, but trying to persist the db on a persistent volume claim on my kubernetes cluster. What I am going to do is just mount the /2fauth folder as my persistent volume, but the behavior with DB_DATABASE is still probably an issue.

[gregory-carlton]

Good day Mattcl. I'm attempting to do the same thing with a kubernetes cluster. How did you fix the issue with the path not mapping/persisting? My setup is trying to mount an Azure File Share and use that as the database persistent volume.

How did you mount /2fauth as a persistent volume?

[mattcl]

Good day Mattcl. I'm attempting to do the same thing with a kubernetes cluster. How did you fix the issue with the path not mapping/persisting? My setup is trying to mount an Azure File Share and use that as the database persistent volume.

How did you mount /2fauth as a persistent volume?

I just mounted at /2fauth

from my kustomize configs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: 2fauth
  labels:
    app.kubernetes.io/name: 2fauth
spec:
  revisionHistoryLimit: 3
  replicas: 1
  strategy:
    type: RollingUpdate
  template:
    spec:
      containers:
        - name: 2fauth
          image: "2fauth/2fauth"
          imagePullPolicy: Always
          env:
            - name: APP_KEY
              valueFrom:
                secretKeyRef:
                  name: 2fauth-app-key
                  key: app-key
          envFrom:
            - configMapRef:
                name: "2fauth-config"
          ports:
            - name: http
              containerPort: 8000
              protocol: TCP
          volumeMounts:
            - name: 2fauth-storage
              mountPath: /2fauth
      volumes:
        - name: 2fauth-storage
          persistentVolumeClaim:
            claimName: 2fauth-storage-pvc

[gregory-carlton]

Thanks for the help. Does the database persist even when the docker image is recreated/updated? For example, if I deploy the docker image with Azure Pipelines, make a change and redeploy with Azure Pipelines, it still has the same database?

[mattcl]

Thanks for the help. Does the database persist even when the docker image is recreated/updated? For example, if I deploy the docker image with Azure Pipelines, make a change and redeploy with Azure Pipelines, it still has the same database?

I'm mounting a persistent volume, so it'll persist through pod rollouts and power failures (assuming I don't lose my drives). My cluster is local, so the plugins I have available to me are different, but I assume you just need to declare the appropriate resources in AKS https://learn.microsoft.com/en-us/azure/aks/concepts-storage#persistent-volumes. This is probably not the right thread for that, however.

[Bubka]

@mattcl I just pushed a fix on the dev branch for this issue. The entryscript has been modified to strictly apply a custom DB_DATABASE value, while still symlinking the legacy /srv/database/database.sqlite path. Could you run some tests to validate that it meets the need? (The Docker image has a :dev tag)

[mattcl]

@Bubka This appears to work, thank you. Feel free to close this issue if you'd like.

[Bubka]

Great, thx for the feedback