Vates group | XCP-ng and XO forum

Danp

@acebmxer Pretty sure that coming from Veeam. Did you try the option to Restore with different settings?

poddingue

I checked this on an 8.3 host here, and your sshd_config.d observation is exactly right: the shipped /etc/ssh/sshd_config has no Include line at all, so anything you drop in that directory is never read.
The directory exists and is empty, which is what makes it look like it should work. It is not an OpenSSH version limit either, since the package is openssh-server-9.8p1-1.2.4.xcpng8.3 and 9.8 supports Include fine.
On @tjkreidl's route, two things check out on my side: the packaged unit really is ExecStart=/usr/sbin/sshd -D $OPTIONS, so his blank ExecStart= plus a replacement line is the correct shape, and RH-Firewall-1-INPUT does exist as a chain, so his iptables step targets the right place.
I have not actually moved a port with it, so treat that as "the pieces line up" rather than "I tested it end to end", and keep a second session open when you try.
Might be worth a mention to @Team-OS-Platform-Release, since whether there is a supported way to pin a port is a packaging question more than a config one.

poddingue

@tjkreidl's systemd override is the angle I would try first too, since it moves the port out of the file the package keeps rewriting and into a drop-in that an update should leave alone.

His firewall step is worth reading carefully rather than skimming, because on XCP-ng the iptables rule is the part that locks you out if you miss it, and he says himself he has not run this.

On your sshd_config.d question, I would check whether the shipped sshd_config actually contains an Include /etc/ssh/sshd_config.d/*.conf line, because if it does not then those files are simply never read and that would explain the silence rather completely.
One thing that is written down is that since 8.3 the accepted ciphers and algorithms are baked in at OpenSSH build time, and anything you override yourself is yours to maintain across updates: https://docs.xcp-ng.org/releases/release-8-3#openssh-security-ciphers-and-user-configuration.
Might be worth a mention to @Team-OS-Platform-Release, since whether a supported way to pin a port exists is really a packaging question rather than a config one.

I have not done this on a live host, so please keep a second session open while you test.

poddingue

That is clearer than I expected, thank you.
The part that lands for me is that the cap sits on the agent rather than on the token, so a delete is not refused after the fact, it simply never appears in the catalogue the model can see.
I had assumed most of the work would live in a policy engine, and it sounds like the bulk of it is classifying the 267 tools once and shipping that classification with the description itself.
Treating a refused call as a signal rather than a near miss is the bit I want to borrow if/when we talk about this, because it turns the log from an audit trail into something closer to a smoke alarm.
I am not deep enough in MCP to have a useful opinion on where this model breaks, so I will read the endpoint matrix properly before asking anything else.
Passing it on internally as promised.

poddingue

That is a useful pair of findings, thanks for going back and testing both.
So the appliance was never the blocker, it just needs the Windows console next to it to add the NFS repository and connect XCP-ng, which fits what @AtaxyaNetwork saw too.
The part I would not have guessed is that upgrading an existing console pulls the plug-in in by itself, while running the standalone plugin installer against a fresh 13.1 offers to uninstall it instead, so anyone coming from 12.x probably wants to look at the console component list rather than hunt for a separate download.

Your screenshot showing Veeam Plug-In for Xen UI Extension 13.1.0.295 sitting next to the Nutanix, oVirt and Proxmox extensions is a good confirmation it is a proper component now and not a side channel.

I have not run 13.1 myself so I am going entirely on your screenshots here. If you get as far as a first successful backup run, it would be great to hear how that went.

poddingue

Merci pour les précisions, elles écartent ma piste. Si vous reproduisez en BIOS comme en UEFI, le ticket #151 ne colle pas, d'autant qu'il parle de l'installeur Windows et pas d'Anaconda : je l'avais résumé un peu vite.
La différence intéressante est peut-être RHEL 9 contre RHEL 10, puisque @AtaxyaNetwork a un build qui fonctionne en 10 avec cd_files et sans DHCP, et son test en 9 ce week-end devrait trancher.
Sur cd_label = "OEMDRV", je n'ai trouvé ni issue ni PR dans le dépôt du plugin, donc ça n'existe visiblement pas encore : si ça vous va, ça ferait une demande propre à ouvrir sur https://github.com/vatesfr/packer-plugin-xenserver, en reprenant l'argument air-gapped que vous détaillez plus haut, qui est plus convaincant que ce que j'écrirais moi.

Je ne connais pas assez le plugin pour dire si c'est simple à ajouter, donc je préfère ne rien promettre.
Merci en tout cas de documenter tout précisément, ça servira sans doute bien au-delà de votre POC.

poddingue

Trying to pull the last few posts together, because there is a pattern I keep staring at.
Every failed run in @JB's screenshots lasts exactly 5 minutes while the successful ones finish in seconds, and @abudef's history going back to 23 June shows the same 5-minute wall.
That reads to me like a fixed timeout firing rather than a merely slow transfer, though I could be wrong about which one.
@christopher-petzel's syslog looks like a different animal, since assert(!this.paused) in undici's Parser.finish is xo-server crashing outright at job start while 13 other instances backed up fine the same minute. The only knob I can find written down is httpInactivityTimeout at https://docs.xen-orchestra.com/xo5/backup_troubleshooting#error-http-connection-has-timed-out, but that one sits on the XAPI GET path, and I do not know whether it touches pool metadata jobs at all. @florent, does the 5-minute signature change anything on your side?

Vates

Posts

Member List