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

Grafana dashboard was full N/A.

Here we are with D3812 build:

That builds properly:

In T1098#21963, @dereckson wrote:

Tested a build manually successfully with:

$ git clone https://github.com/Learath2/sBNC.git
$ cd sBNC
$ cc *.c -o sbnc
$ sudo cp sbnc /usr/local/bin

Mail solution currently use Dovecot.

Same issue for rhyne-wyse.log. Configuration was copied from acme.sh one.

It's somewhat still maintained:

tikv is marketed as a distributed, solid, high-performant key/value store.

sys-info support for FreeBSD has been added if it was previously a blocker.

May 2020 - https://github.com/FillZpp/sys-info-rs/blob/master/c/freebsd.c

Package has been added in January 2022.

Two blockers at app-level:

• .env support is missing from application code.
• code need to be upgraded to test MySQL connectivity

Credentials
Password created in ops/secrets/dbserver/cluster-B/users/obsidian51

web-001 upgrade ready, next step: reboot and run again freebsd-update install

We switched to a dynamic approach for init.sls in D3334.

The full /etc/nginx directories on both docker-002 and dwellers use httpd_config_t for every file.

With T1452 resolved, this is resolved too.