Configuration is ready.

Next step: deploy to docker-002, and ensure D3622 is already deployed there too.

@sandrined Could you publish the commit for this change for review?

Current status: deployed to Dwellers

Deployment on Dwellers

Decreasing priority as no wheelwar will exist on db-A: php83-pdo_pgsql isn't declared there.

Confirmed for recent package:

Taking this, we've PostgreSQL deinstalled on WindRiver; as we're on a UNIX system, it still runs without any issue as long as it doesn't need to load dynamically a library, accepts connection, serves traffic but software isn't there anymore.

In T2185#33876, @dereckson wrote:

Each test run produces this:

Nov 11 02:29:33 windriver postgres[63389]: [19-1] 2025-11-11 02:29:33.804 UTC [63389] ERROR:  relation "nonexisting" does not exist at character 13
Nov 11 02:29:33 windriver postgres[63389]: [19-2] 2025-11-11 02:29:33.804 UTC [63389] STATEMENT:  DELETE FROM nonexisting
Nov 11 02:29:34 windriver postgres[63402]: [19-1] 2025-11-11 02:29:34.181 UTC [63402] ERROR:  relation "nonexisting" does not exist at character 15
Nov 11 02:29:34 windriver postgres[63402]: [19-2] 2025-11-11 02:29:34.181 UTC [63402] STATEMENT:  SELECT * FROM nonexisting
Nov 11 02:29:34 windriver postgres[63403]: [19-1] 2025-11-11 02:29:34.209 UTC [63403] ERROR:  relation "nonexisting" does not exist at character 15
Nov 11 02:29:34 windriver postgres[63403]: [19-2] 2025-11-11 02:29:34.209 UTC [63403] STATEMENT:  SELECT * FROM nonexisting
Nov 11 02:29:34 windriver postgres[63408]: [19-1] 2025-11-11 02:29:34.357 UTC [63408] ERROR:  relation "not_existing_table" does not exist
Nov 11 02:29:34 windriver postgres[63408]: [19-2] 2025-11-11 02:29:34.357 UTC [63408] STATEMENT:  TRUNCATE not_existing_table
Nov 11 02:29:34 windriver postgres[63409]: [19-1] 2025-11-11 02:29:34.385 UTC [63409] ERROR:  relation "not_existing" does not exist
Nov 11 02:29:34 windriver postgres[63409]: [19-2] 2025-11-11 02:29:34.385 UTC [63409] STATEMENT:  TRUNCATE not_existing
Nov 11 02:29:34 windriver postgres[63416]: [19-1] 2025-11-11 02:29:34.591 UTC [63416] FATAL:  password authentication failed for user "notexisting"
Nov 11 02:29:34 windriver postgres[63416]: [19-2] 2025-11-11 02:29:34.591 UTC [63416] DETAIL:  Role "notexisting" does not exist.
Nov 11 02:29:34 windriver postgres[63416]: [19-3]       Connection matched pg_hba.conf line 22: "host    all             all             127.0.0.1/32            scram-sha-256"

I guess we could avoid to post PostgreSQL logs directly in /var/log/messages.

Each test run produces this:

Actually, we use the same database name than for MariaDB / MySQl:

Bruteforce attack scenario possible, so we're only interested by usernames defined in users.sls, not by "root" (can't login by SSH) or generic accounts like "docker" (doesn't exist):

Checking the RabbitMQ Monitoring with Prometheus guide:

• we're OK for cluster name
• to get sensible values for rate() in Grafana, we need to configure Prometheus to scrape RabbitMQ every 15s ; according Prometheus configuration, the value scrape_interval can be set at job level