Closed divin31 closed 1 month ago
Same problem here. Fresh install with an external PostgreSQL server and using 2024.8.1. The database connection is fine, but the worker/server are stuck in a loop after failing to create a duplicate authentik_tenants_domain table endlessly. I've dropped the database several times and upgraded the postgres user to SUPERUSER but to no avail.
Same for me!
@BeryJu Thanks for taking a look.
Sorry but I'm slowly sick of EVERY single release of authentik having MAJOR issues, not like small issues, but MAJOR bugs.
@divin31 Would you mind posting your (sanitized) .env file contents? Still working through this issue myself.
Sorry but I'm slowly sick of EVERY single release of authentik having MAJOR issues, not like small issues, but MAJOR bugs.
made me stop using authentik entirely and switch to an alternative. i've already mentioned this several times and its starting to get annoying
which is unfortunate cause authentik was great and had a lot of potential but it's just not worth the risk of having bugs which may become security issues or have to stay on the previous release and wait for the patch to not get impacted by major bugs
I got through this finally. There seem to be multiple issues with both database initializations and migrations when custom host, user, db name and/or authentication methods other than password are specified via the .env file. The errors indicated by the worker/server aren't necessarily what's starting the cascade of issues.
I was able to get things running by starting the stack with no .env configs other than the secret key and db password. After everything was up, I set up the default login, then paused all containers except the postgres. I created a dump of the database (with --no-owner) and restored it onto my external postgres server (as role of whatever the authentik user will be). After all that, I brought everything down and deleted all volumes via docker. Finally, I added my customizations to the .env file and docker-compose.yml (even though they they didn't work before) and everything came up fine.
For those that are looking to migrate a non-fresh, internal database, I'd suggest making a backup first, then try altering permissions to the default credentials, and renaming the database to the default name. Then, clear out the .env other than secret and db_pass and try bringing up the stack and letting the server/worker migrate the db. Finally, bring the server and worker down and revert your db privs, names, and other .env/compose settings.
Far from ideal...and made worse because it's so hard to figure out what the root cause is.
@michael1800v1 Updated my post with env vars.
@divin31 is the just released version 2024.8.2 now working for you?
@CrazyWolf13 Unfortunately I get the same error message with the new version as well. Tried with a clean postgres database from 0.
I can only guess about what's actually going on. I got up and running by using all defaults, no custom config whatsoever, just to get a fresh (empty) database initialized, then dump/restore the database to its real home and applied customized configs to docker-compose and .env afterwards. I've got it up using external Redis, external postgres, all tls with custom root CA and different usernames now...after a default-only initialization . If that doesn't work, I'm out of ideas.
As part of a fresh install, make sure to delete any docker volumes from old attempts--any partial data remnants or possibly even the database existence leads back to a failed initialization. I overlooked that and spent an hour or so going in circles until I figured that out.
I find the situation very worrying: you release a version, that comes with the reboot loop preventing everyone using that release from using the software. Yet, there is no clear documentation of a workaround, nor any clear understanding of the issue at hand. The reporting in this issue seems to tell there is a combination of bugs that was triggered by the release. We do not know exactly what causes the bug; all we know is that SSO service is down for a full week, without any chance of coming back up.
I would find it useful if GoAuthentik.io would be a bit more active supporting people hit by this bug and finding a resolution. Obviously the 2024.8.2 release did not fix any of it. I spent a few hours trying to figure things out and resorted to: abandon all hope and wait for a fix. But this is not a solution.
@BeryJu Thanks for looking into this, I fully agree with @ghz7l.
For the size of authentik at least a little "does it even start" test before a release would maybe be a good idea.
cc @fheisler (authentik ceo)
I'm jumping back in this thread because authentik was in the top 5 most useful tools in my homelab, and many people around me also use it. It's the only decent self-hostable SSO tool (it's also quite powerful), and it's disappointing to see this happen. My opinion is that a dedicated QA team is needed to test each update before its release, especially since there's an enterprise plan and people pay for the product. Now, I won't tell y'all how to run your company, but we are not the first to point this problem out.
I understand there is "No support" for the "Open Source" version, it's written on the pricing page. But breaking the OS version when releasing Enterprise-only features, really?
So, what's the migration path to another similar yet less interesting -- but maybe better supported -- alternative to Authentik? :cry: I'm really supportive of the GPL3 license, so I'd move away only in disgust.
Sorry for the delayed response. We have been looking into this issue over the past two weeks but have not been able to reproduce it ourselves. It seems to affect only a small number of instances, but we have not been able to track down the relevant difference. To those affected, especially the people that have run into this issue on an empty database, please create an export of the database using pg_dump and send it to me at jens@goauthentik.io. We have automated tests in place for each commit that test that code works for both a brand new database, the upgrade path works and the code works on the upgraded database. Additionally we run the beta version of authentik internally to catch any issues like this early. With 2024.8 we release zero enterprise-only features (and zero related database changes). We do want to help get to the bottom of this issue and support continued community adoption of authentik.
Thanks for the feedback @BeryJu, I think the main misunderstanding here was the long delay, I guess a simple "WIP" or looking into message would've compledtely change this.
Thanks for the explanation about the tests!
I've just gave authentik another go, and seems like updating to the latest 2024.8.3 or the latest image released 2 days ago fixed the issue for me.
I tried v 2024.8.3 and this version is working correctly with both a fresh database, and I could also migrate my old db. Thank you.
Describe the bug I've been using Authentik for more than a year now, always with the latest update. After the recent update (2024.8), Authentik server and worker keeps reboot looping. Also tried updating postgres from 12 to 16, but it resulted the same problem, even when I start with a fresh postgres db. If I set the tags for server and worker to 2024.6, it starts working again normally as before.
docker compose:
Update:
Initially I used only these evn variables:
Later tried adding these as well:
To Reproduce Steps to reproduce the behavior:
update to 2024.8
Expected behavior to work after update
Screenshots
Logs
Server:
Worker:
Version and Deployment (please complete the following information):
Additional context I'm running Authentik on a Synology 1522+ NAS, with RAM extended to 24 GB.