XCP-ng 8.3 betas and RCs feedback π
-
@ThierryC01 Is there a
/etc/fstab.orig
file on your system? If yes, does it contain the missing line about the ISO? And what's the output ofrpm -q setup
? -
@stormi Now that you mention that, I did perform an ISO upgrade I should not have performed would I known. Remember a few posts above. My bad...
-
@xerxist said in XCP-ng 8.3 beta :
Which kernel are you looking at since 4.19 will be EOL in 9 months?
So, the main blocker in the way to upgrade the kernel is a kernel module we use for storage access from the VMs. Work is being done to replace it, which will unlock the possibility to move to a newer kernel. Which version exactly will be chosen in due time. Likely a LTS kernel.
Meanwhile, XCP-ng 8.3 remains on 4.19, on which we'll continue to provide security fixes for vulnerabilities that may affect it in the context of dom0.
-
Thanks for the explanation.
Will this be added like what there is now as an alternative kernel? -
@xerxist Possibly, but then only some storage drivers will work with it. This will mainly be for testing purposes and gathering feedback.
-
Not to be negative but in a professional environment auditors will trip on this. No one wants to explain to auditors that its plastered from upstream somewhere. Also itβs good for new hardware support. But good to hear work is progress.
-
USB Passthrough Testing & Feedback :
Tested 2 Devices :-
-
16 GB USB Flash Drive - Transcend
Results : Works Perfectly -
ePass2003 Token (for Digital Signatures)
Results :Not Detected(See update)
Deep Diving :
lsusb
&usb-devices
commands list the device (vendor id - 096e) on console (cli). However, the device is not shown in the 'Advanced' tab of the node/host.Maybe devices getting filtered only for USB Media / Flash Drive in Xen Orchestra ?Update :
Token also works now after editing :/etc/xensource/usb-policy.conf
as enumerated here.Thanks to @olivierlambert for the above link and prompt guidance!
-
-
Probably not in the white list of device type. Read https://docs.xcp-ng.org/compute/#οΈ-usb-passthrough for more details.
-
Thanks for the prompt reply !
You are right. The device was filtered. I am now removing from filter and re-testing.
Update: Re-tested and everything seems to work fine.
I will further try to use the signature device to see if it actually works inside the VM.PS: I see no reason to filter tokens by default. Can we remove the DENY line for smartcards by default ?
We also need to add :DENY: Class=03 subclass=00 prot=00 # HID
as this class is used by some MSI motherboards for HID. Since rest of the HID are filtered, this should be added too for consistency sake. -
So which page do need to refer my auditor to for all the patching that is done once the kernel is EOL?
-
In continuation of my previous post, I also noticed that any changes to
/etc/xensource/usb-policy.conf
are reverted in case of updates. I also notices this reverting in case of restart (but need to confirm this after thorough testing as it may be one-time senario) -
@gb-123 In case of restart I never had it reverted only in case of update. After an update I just run an ansible playbook to add my whitelist entries again. sure it's a work around and some include file like usb-policy.conf.d/*conf would be nice to have.
-
It reverted for me once in case of re-start but that has not happened the second time. That's why reported it as 'one-time' scenario.
I agree having usb-policy.conf.d/*conf would be nice to have.
For workaround, I am working on a script to over-write
/etc/xensource/usb-policy.conf
on every reboot (should take care of the updates as well). This is a crude way of doing it but this is just meant as a workaround rather than a long term solution which is adding the conf in something like usb-policy.conf.d/*conf as you mentioned. -
Any way to get the UUID of the Host using CLI ?
What I mean is not the list of hosts usingxe host-list params=uuid
but I only want to get the host uuid of the host on which the command is being run on. -
@gb-123
cat /etc/xensource-inventory | grep -i installation_uuid
-
@Tristis-Oris Thanks a Lot!
-
For everyone who needs to ensure
usb-policy.conf
remains intact after update/reboot, I have posted a workaround script here.Please note this is a workaround script only till a better implementation is done by the xcp-ng team.
-
@xerxist said in XCP-ng 8.3 beta :
So which page do need to refer my auditor to for all the patching that is done once the kernel is EOL?
Just in case Iβve asked Lawerence on Youtube what his thoughts are on promoting EOL products to his clients
-
https://xcp-ng.org/docs/releases.html#all-releases
Latest LTS: XCP-ng 8.2 Using the Long Term Support version is relevant if: you want to be sure the system will stay stable you want to **have all security fixes** without doing major upgrades every year you want a predictable migration path on a longer timeframe you don't care about new features coming for the next years LTS releases are supported for 5 years.
XCP-ng 8.2 still has about a year and 3 months left of support.
-
That is not the point Iβm trying to make.
The heart of the OS is going to be end of life December this year. You can probably plaster away but you need to keep track of everything for cveβs etc.. if you donβt want an auditor to trip on this. As they will because itβs end of life.