-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
YUBICO_SERVER can no longer be an empty string, causes restart loops #54
Comments
Ran into this myself this AM, as my watchtower schedule was weekly and they updated the image just after my last watchtower check-in. Thanks for flagging, I came to the same conclusion and commented the vars out. It seems like they will keep this "empty string is a config error" approach, which I agree with. |
+1, thanks for flagging. The workaround worked for me as well. |
Thanks @AySz88 for finding this. I updated |
This vaultwarden commit, done as part of addressing vaultwarden issue #3003, appears to disallow setting YUBICO_SERVER to an empty string, such that it now considers it a configuration error rather than quietly(?) failing and continuing. The default .env.template, and any .env that left those lines in, now produces a restart loop and Error 503 for any users.
For users: workaround is to comment out YUBICO_* in .env, and re-run docker-compose up. Presumably .env.template should be changed so those lines are commented out by default as well.
Is there any mechanism to help existing deployments here other than asking to patch vaultwarden to consider empty strings to be unset?
[edit] I just noticed that the Vaultwarden issue has someone expecting an empty string to be some other behavior, so the idea of considering empty strings to be unset might not even be accepted. [edit2] Their reasoning here.
The text was updated successfully, but these errors were encountered: