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:

Already deployed on db-A.

rOBSIDIAN329bc358fc01 refers to table orbeon_form_data_attach, permission is needed for that one too, but missing in rOPS (was a hotfix on Complector)

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

Grafana dashboard was full N/A.

Did a run this night to update Certbot files, states are currently correct:

Vault is now alive and used for credentials provisioned by Salt.

Alkane doesn't need any new account. We can send a request to an URL and it will be run by the deploy user.

Eglide is still not configured from Complector with a salt-ssh roster, so running it locally:

Confirmed by shark key is correct.