Was actually correctly configured in rOPS, but not deployed, so old version was still there.

Alias photo.nasqueron.org → photos.nasqueron.org : Configuré et fonctionnel

Mounting the ZFS datasets mysql-innodb-data and mysql-innodb-logs outside of /var/db/mysql, then deploying them to db-B-001: operation completed and functional.

https://agora.nasqueron.org/Operations_grimoire/NTP#FreeBSD

Deployed on all FreeBSD servers with salt -G 'os:FreeBSD' state.apply roles/core/ntp

Action plan

Activer ntpd : nécessaire si le serveur doit aussi servir de source horaire à d'autres machines.

Let's go for that road, even if it's only for the local machine.

Next: reconfigure DNS zone in HE control panel, as it only has our IPv4.

DNS server listens correctly to IPv6:

Dans le cadre de mes activités du jour, j'ai travaillé avec mon maître de stage sur un problème de synchronisation horaire détecté sur le serveur db-B-001, qui présentait un décalage de deux heures.
Ce problème a été documenté dans le rapport d'incident suivant :
https://agora.nasqueron.org/Operations_grimoire/Incidents/2025-11-25-MariaDB
Nous avons analysé la configuration actuelle : la synchronisation NTP est gérée par les scripts périodiques situés dans :

ntpq log shows it only works to print statistics when ntpd is launched.

ntpq log: https://termbin.com/1vu4

Deployed on WindRiver.

Avancement sur T2074

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

Deployed for WindRiver, server now runs on 17.6.

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

Grafana dashboard was full N/A.

Here we are with D3812 build: