Per T2105, current solution is to use an external provider (Hurricane Electric?) to host our secondary zone.

In T2123#32403, @dereckson wrote:

Tests fix commits will be aggregated in datacube T2123-improve-tests-suite branch, so we can have a look of what's remaining to fix.

Tests fix commits will be aggregated in datacube T2123-improve-tests-suite branch, so we can have a look of what's remaining to fix.

Going to take this, as I wrote the tests suite, @DorianWinty will review, so at least two of us will be familiar with the tests.

Why not port encrypt to FreeBSD?

Support for PHP 8.4 is still there.

Uninstalled certbot.
Pruned old Python 3 dependencies.
Updated EPEL repo to epel-release-10-6
Updated packages
Reinstalled certbot, now running under Python 3.12 too.

Just for information, working on T2113, I've first updated the packages non related to that conflict, so I had fresh packages for both systemd and selinux config.

https://snapcraft.io/starship - last update: 27 April 2023 - latest/edge

Was looking to offer a fix upstream, like read hostname from /proc/sys/kernel/hostname on Linux, but then I've realised this is an interaction issue with snap, starship, systemd and SELinux.

Decreasing priority, as it only occurs with Starship.

Normal behavior observed with the policy:

Still an error with last packages versions.

audit2allow policy

Bumping for 14.3, are still going on, it makes sense to target latest version

First step is to create a script to renew all needed certificates:

Applied to Hervil, was missing there.

Find more easily the gateway

For reference, the configuration contains max_binlog_size = 1000M. This only affects the maximal size of ONE log file, but it can create as many as needed.

For dbserver-mysql role, configuration is located at roles/dbserver-mysql/mysql-server/files/conf.d/server.cnf

There is already a state to enable the module, freebsd_kernel_modules_enable but it only triggers when pefs-kmod is installed, and only to load the module right now.

Same issue after 2025-06-02 reboot for kernel upgrade, route to 172.27.27.1 is still missing.

After arc land is successful:

Next one detected during arc land:

Next one:

Monitoring could be as simple as:`

Decreased priority as it was on my local laptop, WindRiver is still 8.3.16.

Knot uses also the same format, last dump for nasqueron.org available at P369.

WindRiver looks stable enough, green light for other servers (still router-001 excepted)

In T2103#32089, @dereckson wrote:

False alert, server correctly booted but doesn't answer ICMP packets, see T2104.

Problem from the guest network firewall, not about WindRiver.

False alert, server correctly booted but doesn't answer ICMP packets, see T2104.

On WindRiver. 14.2 has been upgraded, not alive after reboot.