Lead Maintainer group | XCP-ng and XO forum

stormi

I had this tab still open which lets me realize that despite we packaged vmfs6-tools and updated the documentation at https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#local-migration-same-host, we didn't inform you here.

Now it's done

stormi

OEL 8 & 9 wouldn't contain the fix unless they applied extra patches for this to the RHEL 8 & 9 kernel(s). I'll let the hypervisor team check the current status.

stormi

I've had this thread in my TODO list for long.

I'm not sure what the different options we have mean for users.

As r8125-module is installed by default, we'll want to avoid breaking it for existing users. Would using the new code risk causing regressions? Maybe that's what you meant but I'm not sure. Does our current r8125 driver support both 8125 and 8126, and not 8127? Or just 8125?

If we can't update the driver without causing regressions, then can we offer an alternate driver based on the new code for each chip (8125, 8126, 8127), and what amount of work might this represent?

The target would be XCP-ng 8.3. In XCP-ng 9.0 we'll have a newer kernel and newer drivers anyway.

CCing @Team-Hypervisor-Kernel for their opinion.

stormi

@olivierlambert said in Limiting access to xo-lite to a specific IP address or ssubnet:

About iptables, there's /etc/sysconfig/iptables but I'm not sure it's the right place to put manual modification, that's why I pinged the @Team-OS-Platform-Release

In a way that's the right place, but one needs to be careful with modifications there.

stormi

This changes nothing regarding brute-forcing. XAPI still listens to RPC requests on port 443.

stormi

Without changing iptables rules (that's not very flexible and could conflict with XAPI's handling of the rules), there's a way to disable the webserver.

https://docs.xcp-ng.org/management/manage-locally/xo-lite/#disabling-xo-lite

Lead Maintainer

Posts

Member List