{"id":1444,"date":"2023-04-10T20:11:12","date_gmt":"2023-04-11T01:11:12","guid":{"rendered":"https:\/\/zewwy.ca\/?p=1444"},"modified":"2023-04-10T20:11:12","modified_gmt":"2023-04-11T01:11:12","slug":"fixing-vaultwarden-502-bad-gateway","status":"publish","type":"post","link":"https:\/\/zewwy.ca\/index.php\/2023\/04\/10\/fixing-vaultwarden-502-bad-gateway\/","title":{"rendered":"Fixing Vaultwarden 502 Bad Gateway"},"content":{"rendered":"

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

It’s running on Ubuntu which was easy enough to update to the latest release build.<\/p>\n

apt update\r\napt upgrade\r\nreboot\r\ndo-release-upgrade<\/pre>\n
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.<\/p>\n
\"\"<\/a><\/p>\n
So, I figured I’d install it, or try to?<\/p>\n
\"\"<\/a><\/p>\n
Da faq? I remember this python\/pip stuff being a pain intially too, what did I run again?<\/p>\n
\"\"<\/a><\/p>\n
OK, maybe need to get the newer stuff? Old one no good?<\/p>\n
\"\"<\/a><\/p>\n
Not now Kaa!!! let’s see…<\/p>\n
apt install python3-pip<\/pre>\n
\"\"<\/a><\/p>\n
and…<\/p>\n
pip install docker-compose<\/pre>\n
Looks like the command is working again. \ud83d\ude42<\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
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:<\/p>\n
docker ps<\/pre>\n
\"\"<\/a><\/p>\n
OK, but why? then another helpful hint by a user:<\/p>\n
docker-compose logs -f<\/pre>\n
\"\"<\/a><\/p>\n
This is when things get a bit weird\/funny. I found this post about the SMTP Depreciated Warning<\/a>, 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<\/a>.<\/p>\n
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:<\/p>\n
docker inspect bitwardenzewwyca_app_1<\/pre>\n
When looking at it was already defined as 0.0.0.0.<\/p>\n
\"\"<\/a><\/p>\n
This post, same exact problem, saying the exact same thing,<\/a> but I don’t know what env.sh is in their context either, slowly losing hope, despair ensues.<\/p>\n
I even try changing the log location, create a file, with cmod 777 on it:<\/p>\n
\"\"<\/a><\/p>\n
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:<\/p>\n
changed SMTP_SSL=false to SMTP_SECURITY=false<\/p>\n
\"\"<\/a><\/p>\n
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…<\/p>\n
\"\"<\/a><\/p>\n
Woah a different error message, wait the option is important, and I marked it wrong, ok final changed<\/p>\n
changed SMTP_Security=false to SMTP_SECURITY=off.<\/p>\n
bring down and up the container and…<\/p>\n
\"\"<\/a><\/p>\n
Ehhhhhhhhh! My Vaultwardens back! Time to see if I can bring up ze PiHole!<\/p>\n
I hope this post helps someone in the same boat.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … <\/p>\n
Continue reading “Fixing Vaultwarden 502 Bad Gateway”<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"sfsi_plus_gutenberg_text_before_share":"","sfsi_plus_gutenberg_show_text_before_share":"","sfsi_plus_gutenberg_icon_type":"","sfsi_plus_gutenberg_icon_alignemt":"","sfsi_plus_gutenburg_max_per_row":"","footnotes":""},"categories":[8],"tags":[355],"class_list":["post-1444","post","type-post","status-publish","format-standard","hentry","category-server-administration","tag-vaultwarden"],"_links":{"self":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/1444","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/comments?post=1444"}],"version-history":[{"count":1,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/1444\/revisions"}],"predecessor-version":[{"id":1445,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/1444\/revisions\/1445"}],"wp:attachment":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/media?parent=1444"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/categories?post=1444"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/tags?post=1444"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}