Sorry, but it is outside my competence zone. I prefer to not tell you to try something that I don't know the exact consequences of.

Does someone else could reply ?

Yes, if the file is empty, it is expected to the openssl x509 command to fail.
Does is it the same on the master ?

Just my 2 cents, but with SSL involved time is important: could you check the date is accurate on the two hosts ?

having the output of the following commands might help too:

• stat /etc/stunnel/xapi-stunnel-ca-bundle.pem
• openssl x509 -in /etc/stunnel/xapi-stunnel-ca-bundle.pem -noout -text

please note that blacklisting ESP modules will break IPsec, and encrypted private tunnels rely on it.

Bonjour,

Apparemment, la valeur vient de la xapi :

$ xe host-list params=uuid,software-version
uuid ( RO)                : 9940971b-45f6-4225-aaef-ddb0668e3734
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793


uuid ( RO)                : 5f16a481-103e-4ca8-a0e2-b708d2c26437
    software-version (MRO): product_version: 8.3.0; product_version_text: 8.3; product_version_text_short: 8.3; platform_name: XCP; platform_version: 3.4.0; product_brand: XCP-ng; xapi: 26.1; build_number: 8.3.0; git_id: 3; hostname: localhost; date: 20260430T09:28:41Z; dbv: 0.0.1; xapi_build: 26.1.3; xen: 4.17.6-6; linux: 4.19.0+1; xencenter_min: 2.21; xencenter_max: 2.21; network_backend: openvswitch; db_schema: 5.793

qui prend l'information depuis le fichier /etc/xensource-inventory (sur le host):

# grep BUILD_NUMBER /etc/xensource-inventory
BUILD_NUMBER='8.3.0'

Ce fichier est mis à jour par le script de post-config du package rpm xcp-ng-release (voir le script utilisé ici)

La valeur a été mise à jour la dernière fois en 2023 (voir le changelog pour 8.3.0-13).
La valeur acutelle est définie dans la variable BUILD_NUMBER rpm variable du package.

Cela veut dire que le host avec Build number = cloud ne semble pas à jour ? Pouvez-vous vérifier la version installée du package xcp-ng-release, en utilisant la commande rpm -q xcp-ng-release ?

after testing (with net-snmp-utils 5.9.3), I have no problem with snmpv3 and SHA/AES.

On my testing host, snmpd server (OpenBSD):

• User: user1
• auth: AES with password123
• priv: AES with 321drowssap

From XCP-ng 8.3, with net-snmp-utils 5.9.3:
$ snmpbulkwalk -v3 -a SHA -A password123 -l authPriv -x AES -X 321drowssap -u user1 192.168.1.80

so the net-snmp client itself seems fine with SHA/AES.

could you share more elements ?

SHA`is SHA1. so I assume it is that.
And it seems to be still accepted in authProtocol parameter.

@Mitchel-APD SHA1 ? I am looking if it is still supported/activated-by-default. I saw that 5.8 added SHA-2 family for RFC-7860 compliance

@Mitchel-APD how do you auth on SNMP ? v1, v2, v3 ? and if v3, which authProtocol/privProtocol do you use ?

Having help from OpenBSD side could be the way to go.
Please forward your report to bugs@openbsd.org (with a link to this post too)

For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).

when a new host join an existing pool, it starts by configuring the management interface. so the first bound created is the management one (as bond0) even if the master of the pool has it as bond1.

while doing some tests with 8.3 I got problems too, but not systematically (as you, it seems).

I will send to you a PM regarding xensource.log

@afmart_dei could you share the /var/log/xensource.log of the joining host ? ideally the whole part after the host started (you could look at the file before rebooting and strip all lines before the last line you saw)