How to update to 2.0.1? No user found in database

[MalteMagnussen]

I am trying out 2.0.1 for the first time. Upgrading from 1.9.6.

The environment is kubernetes, but the sqlite is backed up to S3 with litestream, the S3 is also the storage for the files, and the auth is Entra ID.

But I am getting this error in the test environment if I try to upgrade.

mhm@mhm:~/Documents/gokapi$ k logs statefulsets/wip1-gokapi-deployment gokapi 

██████   ██████   ██   ██  █████  ██████  ██ 
██       ██    ██ ██  ██  ██   ██ ██   ██ ██ 
██   ███ ██    ██ █████   ███████ ██████  ██ 
██    ██ ██    ██ ██  ██  ██   ██ ██      ██ 
 ██████   ██████  ██   ██ ██   ██ ██      ██ 
                                             
Gokapi v2.0.1 starting
No user found in database. Please run setup first or crate user with --deployment-password

Going to /setup gives me nothing. Just the nginx throwing 503.

What is this "super admin" and why is it necessary? And how do I fix this problem in a k8s world?

Set the env variable GOKAPI_ADMIN_USER containing the email address of the super admin when upgrading

The ENV var GOKAPI_ADMIN_USER is just set to my email at the moment. The one I use for the Entra ID login as well. Assumed I wouldn't need a password then.

...
        - image: harbor.../mirror/docker.io/f0rc3/gokapi:v2.0.1
          imagePullPolicy: "IfNotPresent"
          name: gokapi
          env:
            - name: GOKAPI_ADMIN_USER
              value: "malte.hviid-magnussen@group.one"
...

config.json

{
  "Authentication": {
    "Method": 1,
    "SaltAdmin": "...",
    "SaltFiles": "...",
    "Username": "\"malte.hviid-magnussen@group.one\"",
    "HeaderKey": "",
    "OauthProvider": "https://login.microsoftonline.com/.../v2.0",
    "OAuthClientId": "...",
    "OAuthClientSecret": "...",
    "OauthGroupScope": "",
    "OAuthRecheckInterval": 24,
    "OAuthGroups": [],
    "OnlyRegisteredUsers": false
  },
  "Port": ":53842",
  "ServerUrl": "https://gokapi...one.com/",
  "RedirectUrl": "https://www.one.com",
  "PublicName": "group.one",
  "DataDir": "data",
  "DatabaseUrl": "sqlite://./data/gokapi.sqlite",
  "ConfigVersion": 22,
  "MaxFileSizeMB": 102400,
  "MaxMemory": 100,
  "ChunkSize": 90,
  "MaxParallelUploads": 6,
  "Encryption": {
    "Level": 0,
    "Cipher": null,
    "Salt": "",
    "Checksum": "",
    "ChecksumSalt": ""
  },
  "UseSsl": false,
  "PicturesAlwaysLocal": false,
  "SaveIp": true,
  "IncludeFilename": false
}

[Forceu]

It looks like there was a problem during the upgrade, but I can't say what exactly went wrong. Do you still have the logs from the upgrade?
You should be able to fix it by running gokapi --deployment-password and entering a random password, as long as there are no other users. Otherwise you need to call the setup again with gokapi --reconfigure, afterwards it should work. The environment variable GOKAPI_ADMIN_USER needs only to be set during the upgrade, you can now remove it, as your configuration file is already on the correct version 22.

[MalteMagnussen]

Do you still have the logs from the upgrade?

Sadly not, they're gone.

You should be able to fix it by running gokapi --deployment-password and entering a random password, as long as there are no other users.

I can't write back to the config.json, since it is a mounted configmap in kubernetes :(

I get a new config.json by upgrading in a local docker-compose, and then turning that config.json into a secret, which is mounted into the pod.

[MalteMagnussen]

I got it working.

Mounted an empty volume at the app config.
Then gave it the reconfigure flag.
Then did the setup via the UI.
Then exec'ed into the pod and extracted the config.json.
Then sealed it into a sealed secret, and removed the reconfigure flag and set the secret as the config volume instead of the empty one.

Now it works.

[Forceu]

If your config.json was not writable, this is most likely the cause of the problem. For the upgrade it has to be available with write-access, otherwise the database upgrade cannot proceed correctly.

Running gokapi --deployment-password will probably return an error if run without write-access, but should create the user in the database nevertheless. Normally it would not be possible to log in in this case, but as you are using OIDC as an authentication source, it should work.

/edit: Great to hear it is working now!