[bug] FATAL: password authentication failed after fresh auto-install on old data path

[nemesifier]

Describe the bug

Stemming from https://github.com/orgs/openwisp/discussions/1213.

The auto-install.sh script generates a new .env file with randomized database credentials (DB_USER, DB_PASSWORD) on every new installation. If a user attempts to reinstall or recover a setup by re-running the script without purging existing Docker volumes, a credential mismatch occurs.

The PostgreSQL container retains the original credentials stored in its persistent data volume, while the OpenWISP application containers attempt to authenticate using the newly generated credentials in the .env file. This results in a permanent "FATAL: password authentication failed" error.

Steps To Reproduce

1. Install docker-openwisp using the auto-install.sh script.
2. Stop the containers using docker compose down (without the --volumes flag).
3. Delete the .env file or the configuration directory.
4. Run the auto-install.sh script again to generate a fresh configuration.
5. Attempt to start the stack; the application will fail to connect to the database.

Expected behavior

The installation process should be idempotent or provide a warning when existing volumes are detected. If the .env file is missing but volumes are present, the script should ideally warn the user that generating new credentials will break database connectivity unless the volumes are also cleared.

Screenshots

N/A

System Information:

• OS: Ubuntu 24.04 LTS
• Docker version: Docker version 28.1.1

Suggested Mitigation

For users encountering this, the following command must be run to ensure the database is initialized with the current .env credentials (note that this deletes all existing data):

docker compose -f /opt/openwisp/docker-openwisp/docker-compose.yml down --volumes

Alternatively, the auto-install.sh script could be updated to check for existing openwisp_db_data volumes and prompt the user for confirmation before proceeding with new credential generation.

[Srinath0916]

Hey @nemesifier , the context from #1213 makes the root cause clear.
I’d like to take this up. I think the installer should guard users during re-installs when an existing Postgres volume is present, instead of silently regenerating DB creds and breaking the setup.
I’m planning to add a small check in auto-install.sh to detect existing DB volumes and prompt the user to either keep existing data, start fresh (with a clear data-loss warning), or abort.
I’ll raise a PR with this behavior. Let me know if that sounds good.

[nemesifier]

@Srinath0916 let's wait for @pandafy's opinion, I want to know his opinion before proceeding as he's been working on this project a lot lately.

[pandafy]

Expected behavior

The installation process should be idempotent or provide a warning when existing volumes are detected. If the .env file is missing but volumes are present, the script should ideally warn the user that generating new credentials will break database connectivity unless the volumes are also cleared.

I agree with the expected behaviour.

I’m planning to add a small check in auto-install.sh to detect existing DB volumes and prompt the user to either keep existing data, start fresh (with a clear data-loss warning), or abort.

I want to be careful about allowing the auto-install script to clear the existing volumes to avoid any mishaps. We don't have automated checks for the auto-installs script which covers all paths (i.e unit tests). We need to make it clear to the user that doing so will delete all the data present in the posgtresql DB and they should re-think before proceeding.

@nemesifier what do you think about providing the users with the command to do this docker compose -f /opt/openwisp/docker-compose.yml down --volumes along with a warning in red text. The user will have to execute this command manually and restart the auto-install script.

[nemesifier]

Expected behavior
The installation process should be idempotent or provide a warning when existing volumes are detected. If the .env file is missing but volumes are present, the script should ideally warn the user that generating new credentials will break database connectivity unless the volumes are also cleared.

I agree with the expected behaviour.

I’m planning to add a small check in auto-install.sh to detect existing DB volumes and prompt the user to either keep existing data, start fresh (with a clear data-loss warning), or abort.

I want to be careful about allowing the auto-install script to clear the existing volumes to avoid any mishaps. We don't have automated checks for the auto-installs script which covers all paths (i.e unit tests). We need to make it clear to the user that doing so will delete all the data present in the posgtresql DB and they should re-think before proceeding.

@nemesifier what do you think about providing the users with the command to do this docker compose -f /opt/openwisp/docker-compose.yml down --volumes along with a warning in red text. The user will have to execute this command manually and restart the auto-install script.

@pandafy @Srinath0916 Agreed, let's not make the script do potentially dangerous operations, we can simply let the user know, suggest the most common solution and let them handle it, we'll still need a red warning to avoid people copy/pasting without reading and then blaming us for loss of data 😂