So anyway, the other day I updated the base OS for the instance of Vaultwarden I’m running. If you are interested in setting up your own you can follow this old guide, however you’ll have to note the YML config differences as noted in my other post upgrading to Vaultwarden, and this post.

It’s running on Ubuntu which was easy enough to update to the latest release build.

apt update
apt upgrade
reboot
do-release-upgrade

Simple enough, and everything went to plan. I made backups along each step too. The service was up, and life was good after a full complete system upgrade. Yay… or so I thought…. until I went to bring up a instance of pihole via docker compose and it errored out on me. When I looked up the error it seemed to be related to python.

So, I figured I’d install it, or try to?

Da faq? I remember this python/pip stuff being a pain intially too, what did I run again?

OK, maybe need to get the newer stuff? Old one no good?

Not now Kaa!!! let’s see…

apt install python3-pip

and…

pip install docker-compose

Looks like the command is working again. 🙂

But after pulling the latest build, and bringing it back up, there were no errors return to the command, but when I tried to access the service all I got was a 502 Gad Gateway from the loadbalancer. Since I knew it lived outside the container and was unaltered that it most likely was not the culprit, I ask on the #nginx channel and was told to check the container status with:

docker ps

OK, but why? then another helpful hint by a user:

docker-compose logs -f

This is when things get a bit weird/funny. I found this post about the SMTP Depreciated Warning, which stated that had nothing to do with the service not coming up. Which then linked to this issue post more likely to be the cause.

So, I kept trying, the log wouldn’t change from the snip above, I thought for sure, it has to be this “Rocket Address”, surely. I just wasn’t sure what .env was in that issue’s context. Another helpful hint from IRC:

docker inspect bitwardenzewwyca_app_1

When looking at it was already defined as 0.0.0.0.

This post, same exact problem, saying the exact same thing, but I don’t know what env.sh is in their context either, slowly losing hope, despair ensues.

I even try changing the log location, create a file, with cmod 777 on it:

Dang it! But this is when things take a strange turn…. I decided even though the SMTP_SSL wasn’t the root cause to change it anyway as it suggests:

changed SMTP_SSL=false to SMTP_SECURITY=false

Well, it finally shut up about the depreciated setting, but same dang issue, can I just get rid of the log file option? (since it’s just in the yml config file anyway…) Get rid of the log file entry in the YML file, and then…

Woah a different error message, wait the option is important, and I marked it wrong, ok final changed

changed SMTP_Security=false to SMTP_SECURITY=off.

bring down and up the container and…

Ehhhhhhhhh! My Vaultwardens back! Time to see if I can bring up ze PiHole!

I hope this post helps someone in the same boat.

The Story

A while a go I blogged about installing BitwardenRS, the on prem version of Bitwarden, which is amazing by the way.

Recently they announced they are changing the name to respect of the original project to avoid confusion.

You can follow this guys great video if you happen to use UNRAID (which I haven’t used myself but looks really neat).

If you followed my blog then you are running bitwardenrs via docker-compose.

In this case it was actually simpler than I thought.

Updating/Upgrading BitwardenRS to Vaultwarden

If you are simply updating to the latest build with the same old name.

Step 1) bring down the Container

cd \path\to\dockerimage
docker-compose down

Step 2) pull the latest build

docker-compose pull

Step 3) Bring up the new container

docker-compose up -d

That’s literally it, and it is super fast process.

However if you want to use the new image. You’ll have to change the name of the source project in the docker-compose yaml file:

Change the image: line

image: vaultwarden/server

Then, just like before, bring down the container, pull new, bring up.

Important Change (broken Email)

After updating I wasn’t first aware of an issue (as I normally don’t manage multiple users and orgs), however attempting to add a user to an org I got an error: SMTP improper Auth Mechanism selected.

No matter which one you pick the error remained (against a standard port 25 connection, anon). No matter what you entered in the “admin portal” under the SMTP configuration area, the same error would persist. My colleague started to dig through the source code, and the logic seemed clean. The issue seemed that once you configure specific “environment variables” (EG.
– SMTP_USERNAME=[username]
-SMTP_PASSWORD=[password]) that these for some reason are not being “overwritten” when defined in the admin portal. Since there was fields defined “[username]” the code was building a connection for auth, and expecting a proper auth mechanism. Since Auth Mechanism was never defined in the “environment variables” and the bug of the settings of SMTP in the “admin panel” were not overwriting it would never hit the proper method in the SMTP code to make a standard port 25 anonymous connection.

To fix the issue you have to remove those two lines from the docker-compose YAML file.

So ONLY DEFINE:
SMTP_HOST=Email Relay DNS name
SMTP_FROM=from address
SMTP_PORT=25
SMTP_SS=false

Save the YAML file and bring down, and then bring up the container.

Watch as email works again. 😀

Super thanks to my buddy GB for the deep code analysis to help resolve this issue. 🙂

Tag: Vaultwarden

Fixing Vaultwarden 502 Bad Gateway

BitwardenRS Upgrade to Vaultwarden

The Story

Updating/Upgrading BitwardenRS to Vaultwarden

Important Change (broken Email)