Some variables from .env file being ignored i.e. ROCKET_PORT #4497

RT-Tap · 2024-04-12T02:26:13Z

RT-Tap
Apr 12, 2024

Subject of the issue

ROCKET_PORT inside .env file is ignored
possibly others - i know there was an announcement about getting rid of websockets but I did notice that the default variable mentioned in the .env.template file ENABLE_WEBSOCKET=true does not work but WEBSOCKET_ENABLE=true does work. Because it's depreciated it shouldnt matter but I figured I would mention it as well.
Others that I have changed (in the env file) and can confirm worked fine:

DATABASE_URL
PUSH_*
DOMAIN
SIGNUPS_VERIFY
EXPERIMENTAL_CLIENT_FEATURE_FLAGS
LOG_FILE
ADMIN_TOKEN
YUBICO_*
AUTHENTICATOR_DISBALE_TIME_DRIFT
SMTP_*

Deployment environment

docker compose in namespace isolated docker hence needing to use a non privileged port

vaultwarden version:
docker hub image library:latest == 1.30.5

Install method:
docker compose
Clients used:
not applicable
Reverse proxy and version:
not applicable
MySQL/MariaDB or PostgreSQL version:
not applicable
Other relevant details:

Steps to reproduce

docker-compose.yml

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwardentest
    user: "4400:4400"
    security_opt:
      - no-new-privileges:true
    volumes:
      - "./logs/vaultwarden/:/logs/"
      - "./vaultwardendata/:/data/"
    restart: always
    secrets:
      - vaultwardenconfig
    environment:
      - ENV_FILE=/run/secrets/vaultwardenconfig
      #- ROCKET_PORT=4084   # only works when set here
    hostname: vaultwarden

secrets:
  vaultwardenconfig:
    file: ./envfile

.envfile

ROCKET_PORT=4084

Expected behaviour

Rocket server start on port 4084 when using ROCKET_PORT=4084 in env file

Actual behaviour

Rocket server still starts on port 80 unless environment variable explicitly set through docker-compose

Troubleshooting data

docker logs vaultwardentest
When set in envfile

[2024-04-12 01:38:07.039][start][INFO] Rocket has launched from http://0.0.0.0:80

when set in docker-compose environment directive

[2024-04-12 01:44:20.367][start][INFO] Rocket has launched from http://0.0.0.0:4084

BlackDex · 2024-04-12T08:17:46Z

BlackDex
Apr 12, 2024
Collaborator

I do not think we can fix this. The env's are loaded in a order, and the one which is last will probably override the previously set items.

The problem here is that the env of the container it self is not overridden when loading the .env file.
It currently checks if there already is an env value assigned, if so, it will not re-assign.
The reason a -e or custom environment setting works is that it will override the default container environment.

The only way we could solve this is by changing from_path to from_path_override, but that probably would be a breaking change as it might cause issues for other users.

So, it's not really an issue, as this is how it is designed.

4 replies

stefan0xC Apr 12, 2024

The env's are loaded in a order, and the one which is last will probably override the previously set items.

Yeah, that's the way docker compose works.

Note

The .env file from that list has nothing to do with the one that vaultwarden is loading from ENV_FILE (even if they are named the same).

But this means that you should be able to unset the pre-configured ROCKET_PORT by simply setting

    environment:
      - ENV_FILE=/run/secrets/vaultwardenconfig
      - ROCKET_PORT

The only way we could solve this is by changing from_path to from_path_override, but that probably would be a breaking change as it might cause issues for other users.

Well, I think the better solution would be not to set the ROCKET_PORT in the container image in the first place but that's also something that we can't change willy-nilly either - but that should be less destructive than changing the order of precedence we currently have (i.e. config.json > loaded environment > ENV_FILE > built-in defaults).

BlackDex Apr 12, 2024
Collaborator

We might be able to remove it from the container file, and set a different default in code. That might be a solution. It will be a special case then, but it already is.

stefan0xC Apr 12, 2024

@BlackDex I don't think that we can (or should) set a different default in code either because it would break the setup of all those that don't use the container image (and have their system configured for Rocket's default port 8000).

BlackDex Apr 12, 2024
Collaborator

Yea, thought so already, but dropped the thought anyway.
Also trying to detect if it's running in a container is not going to be 100% safe either.

I think we should better document this behaviour then.

BlackDex · 2024-04-12T08:21:47Z

BlackDex
Apr 12, 2024
Collaborator

I moved it to the Ideas section.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some variables from .env file being ignored i.e. ROCKET_PORT #4497

{{title}}

Replies: 2 comments 4 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Some variables from .env file being ignored i.e. ROCKET_PORT #4497

RT-Tap Apr 12, 2024

Subject of the issue

Deployment environment

Steps to reproduce

Expected behaviour

Actual behaviour

Troubleshooting data

Replies: 2 comments · 4 replies

BlackDex Apr 12, 2024 Collaborator

stefan0xC Apr 12, 2024

BlackDex Apr 12, 2024 Collaborator

stefan0xC Apr 12, 2024

BlackDex Apr 12, 2024 Collaborator

BlackDex Apr 12, 2024 Collaborator

RT-Tap
Apr 12, 2024

Replies: 2 comments 4 replies

BlackDex
Apr 12, 2024
Collaborator

BlackDex Apr 12, 2024
Collaborator

BlackDex Apr 12, 2024
Collaborator

BlackDex
Apr 12, 2024
Collaborator