This is about @mprasil's container: Newest version listens on localhost rather than 0.0.0.0. As a result, docker cannot expose the port and Bitwarden is unreachable.
Originally created by @lablans on GitHub (Jul 12, 2018).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/73
This is about @mprasil's container: Newest version listens on localhost rather than 0.0.0.0. As a result, docker cannot expose the port and Bitwarden is unreachable.
Steps to reproduce:
```
# docker run -d --rm --name bitwarden --user 1002 -e ROCKET_PORT=8080 -v /srv/bitwarden/:/data/ -p 127.0.0.1:32080:8080 mprasil/bitwarden:latest
c6e390f52c899b0af595143d9692fd2644a0d7e18c8a4350fb834ebd38ac0618
# wget http://localhost:32080
--2018-07-12 13:34:16-- http://localhost:32080/
Resolving localhost (localhost)... 127.0.0.1, ::1
Connecting to localhost (localhost)|127.0.0.1|:32080... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
```
Previous image `110e31f98241` runs fine.
Hmm for some reason ROCKET_ENV is not applied correctly. Oddly enough you can run the container fine if you set the variable directly:
-e ROCKET_ENV=staging
Edit: Actually it's because it's defined at wrong spot in the node image and not the resulting one. Going to fire up an PR for that.
<!-- gh-comment-id:404493091 -->
@mprasil commented on GitHub (Jul 12, 2018):
Hmm for some reason `ROCKET_ENV` is not applied correctly. Oddly enough you can run the container fine if you set the variable directly:
```
-e ROCKET_ENV=staging
```
Edit: Actually it's because it's defined at wrong spot in the node image and not the resulting one. Going to fire up an PR for that.
I was just also going to chime in about the inconsistency between README and the ports actually in use in the image.
<!-- gh-comment-id:404495306 -->
@ptman commented on GitHub (Jul 12, 2018):
I was just also going to chime in about the inconsistency between README and the ports actually in use in the image.
I'm just testing the PR. Once verified in next ~10 minutes, I'll push and trigger the build on docker hub. In the meantime you can start the container with -e ROCKET_ENV=staging as a quick workaround.
<!-- gh-comment-id:404495773 -->
@mprasil commented on GitHub (Jul 12, 2018):
I'm just testing the PR. Once verified in next ~10 minutes, I'll push and trigger the build on docker hub. In the meantime you can start the container with `-e ROCKET_ENV=staging` as a quick workaround.
The code has been merged and pushed, build is now triggered, you should be able to follow it here. Once done (this usually takes just slightly less than one hour) you should be good to use the latest image.
<!-- gh-comment-id:404502167 -->
@mprasil commented on GitHub (Jul 12, 2018):
The code has been merged and pushed, build is now triggered, you should be able to follow it [here](https://hub.docker.com/r/mprasil/bitwarden/builds/bmz7wvczwv36halqwkk4pel/). Once done (this usually takes just slightly less than one hour) you should be good to use the latest image.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @lablans on GitHub (Jul 12, 2018).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/73
This is about @mprasil's container: Newest version listens on localhost rather than 0.0.0.0. As a result, docker cannot expose the port and Bitwarden is unreachable.
Steps to reproduce:
Previous image
110e31f98241runs fine.@mprasil commented on GitHub (Jul 12, 2018):
Hmm for some reason
ROCKET_ENVis not applied correctly. Oddly enough you can run the container fine if you set the variable directly:Edit: Actually it's because it's defined at wrong spot in the node image and not the resulting one. Going to fire up an PR for that.
@ptman commented on GitHub (Jul 12, 2018):
I was just also going to chime in about the inconsistency between README and the ports actually in use in the image.
@mprasil commented on GitHub (Jul 12, 2018):
I'm just testing the PR. Once verified in next ~10 minutes, I'll push and trigger the build on docker hub. In the meantime you can start the container with
-e ROCKET_ENV=stagingas a quick workaround.@mprasil commented on GitHub (Jul 12, 2018):
The code has been merged and pushed, build is now triggered, you should be able to follow it here. Once done (this usually takes just slightly less than one hour) you should be good to use the latest image.