boesr
commented
4 months ago I can reproduce that
Closed EdungDivinefavour closed 3 months ago
boesr
commented
4 months ago I can reproduce that
boesr
commented
4 months ago The error can be bypassed when adding backchannel_application_id and the corresponding foreign key to the authentik.public.authentik_core_provider table, as well as is_backchannel. Afterwards, I removed the migration lines in authentik/core/migrations/0029_provider_backchannel_applications_and_more.py.
Every change to the authentik.public.authentik_core_provider during the migration seems to lead to a hanging process. Maybe there is some broken lock setting? Unfortunately the application still cannot be run because now the following error is thrown:
django.db.utils.ProgrammingError: relation "authentik_outposts_dockerserviceconnection" does not exist
LINE 1: ...ntik_outposts_dockerserviceconnection"."tls" FROM "authentik...The docker error is thrown by docker = DockerServiceConnection.objects.filter(local=True).first() (line 40 of authentik/outposts/migrations/0001_squashed_0017_outpost_managed.py)
boesr
commented
4 months ago @EdungDivinefavour the version https://github.com/goauthentik/authentik/tree/version-2024.4 is working
Salvoxia
commented
3 months ago I'm seeing the same issue when bootstrapping a completely fresh instance of 2024.6.0 using the Helm Chart and an empty database. The pod that first gets the database lock will be stuck on
Applying authentik_core.0029_provider_backchannel_applications_and_more....
When testing the same with a new docker-compose stack, everything came up just fine.
My values.yaml looks like this (nothing special in there that should have any influence on that I guess):
## Globally shared configuration for authentik components.
global:
# Default image used by all authentik components. For GeoIP configuration, see the geoip values below.
image:
# -- Overrides the global authentik whose default is the chart appVersion
tag: 2024.6.0
# -- If defined, an image digest applied to all authentik deployments
volumeMounts:
- mountPath: /media
name: media
volumes:
- name: media
persistentVolumeClaim:
claimName: authentik-media
storageClass: longhorn
size: 100m
env:
- name: AUTHENTIK_POSTGRESQL__USER
valueFrom:
secretKeyRef:
name: authentik-database-app-user
key: username
- name: AUTHENTIK_POSTGRESQL__PASSWORD
valueFrom:
secretKeyRef:
name: authentik-database-app-user
key: password
- name: AUTHENTIK_POSTGRESQL__READ_REPLICAS__0__USER
valueFrom:
secretKeyRef:
name: authentik-database-app-user
key: username
- name: AUTHENTIK_POSTGRESQL__READ_REPLICAS__0__PASSWORD
valueFrom:
secretKeyRef:
name: authentik-database-app-user
key: password
- name: AUTHENTIK_LOG_LEVEL
value: debug
envFrom:
- configMapRef:
name: authentik-env-variables
- secretRef:
name: authentik-credentials
## Authentik configuration
authentik:
# -- Log level for server and worker
log_level: info
# -- Secret key used for cookie singing and unique user IDs,
# don't change this after the first install
secret_key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
## authentik server
server:
# -- The number of server pods to run
replicas: 2
# -- Init containers to add to the authentik server pod
## Note: Supports use of custom Helm templates
initContainers:
volume-permissions:
name: volume-permissions
image: busybox
command: ["sh", "-c", "chown -R 1000:1000 /media"]
volumeMounts:
- name: media
mountPath: /media
# -- Labels to be added to the authentik server pods
podLabels:
app.kubernetes.io/service: authentik-server
## authentik worker
worker:
# -- The number of worker pods to run
replicas: 2
# -- Labels to be added to the authentik worker pods
podLabels:
app.kubernetes.io/service: authentik-worker
Niich
commented
3 months ago I was able to get the migrations to finish by editing the local.env.yaml and removing the read_replicas: section.
...
outposts:
container_image_base: ghcr.io/goauthentik/dev-%(type)s:gh-%(build_hash)s
disable_embedded_outpost: false
postgresql:
# read_replicas:
# '0': {}
user: postgres
host: localhost
...The error seems to be caused by the backport_is_backchannel function in 0029_provider_backchannel_applications_and_more.py. When the config specifies that there is a read replica, but there really isn't, the db_for_read function returns an alias that leads back to the single instance DB. Django then tried to perform a SELECT while the previous transaction is still active and locking the relevant table.
I'm not sure where the best place to fix this is since its technically a 'user error' by supplying an invalid config. But it took quite a while for me to locate the problem, so it might be a good idea to at least do some more validation on the read_replica configs to notify the user they have submitted a potentially invalid config.
Describe the bug I followed all the steps in the Authentik full development setup here, and when I run ak serve, it runs forever and seems to get stuck In the step authentik_core.0029_provider_backchannel_applications_and_more...
To Reproduce
Follow the steps in the documentation, ensure to use the docker-compose.yml from the scripts folder as mentioned in the documentation
Run
ak serverExpected behavior I expect the server to start running without any issues
Logs
Version and Deployment (please complete the following information):
Docker compose
Docker postgres logs