-
Same here.
Updated a Dell R720 / dual Intel Xeon CPU E5-2640 v2 / 64GB
XCP-ng 8,1 fully patched
Standalone hostStill have to do some testing on / with VMs, but this is something for the weekend.
-
Update published. Thanks for testing!
https://xcp-ng.org/blog/2020/07/10/july-2020-xcp-ng-security-updates/
-
Hi everyone.
An update candidate is available for netdata packages in XCP-ng 8.0 and 8.1. Feedback about it is welcome.
They fix two issues:
- a buffer overflow in JSON parsing, that could pose a security threat
- netdata logs being flooded due to a bug in the computation of the last vcpu number
To install the update candidate on XCP-ng 8.0 or 8.1:
yum update "netdata*" --enablerepo=xcp-ng-testing
This will update the
netdata
andnetdata-ui
RPMs if they are installed on the host.You can also install them if not already present with:
yum install netdata-ui --enablerepo=xcp-ng-testing
Note that installing netdata-ui automatically opens port 19999.
-
[10:37 xcpngp02h01 ~]# yum update "netdata*" --enablerepo=xcp-ng-testing Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-testing: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org xcp-ng-testing/signature | 473 B 00:00 xcp-ng-testing/signature | 3.0 kB 00:00 !!! xcp-ng-testing/primary_db | 22 kB 00:01 Resolving Dependencies --> Running transaction check ---> Package netdata.x86_64 0:1.19.0-3.xcpng8.1 will be updated ---> Package netdata.x86_64 0:1.19.0-4.xcpng8.1 will be an update ---> Package netdata-debuginfo.x86_64 0:1.19.0-3.xcpng8.1 will be updated ---> Package netdata-debuginfo.x86_64 0:1.19.0-4.xcpng8.1 will be an update ---> Package netdata-ui.x86_64 0:1.19.0-3.xcpng8.1 will be updated ---> Package netdata-ui.x86_64 0:1.19.0-4.xcpng8.1 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: netdata x86_64 1.19.0-4.xcpng8.1 xcp-ng-testing 11 M netdata-debuginfo x86_64 1.19.0-4.xcpng8.1 xcp-ng-testing 1.6 M netdata-ui x86_64 1.19.0-4.xcpng8.1 xcp-ng-testing 6.4 k Transaction Summary ================================================================================ Upgrade 3 Packages Total download size: 13 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/3): netdata-debuginfo-1.19.0-4.xcpng8.1.x86_64.rpm | 1.6 MB 00:02 (2/3): netdata-ui-1.19.0-4.xcpng8.1.x86_64.rpm | 6.4 kB 00:00 (3/3): netdata-1.19.0-4.xcpng8.1.x86_64.rpm | 11 MB 00:12 -------------------------------------------------------------------------------- Total 1.1 MB/s | 13 MB 00:12 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : netdata-1.19.0-4.xcpng8.1.x86_64 1/6 Updating : netdata-ui-1.19.0-4.xcpng8.1.x86_64 2/6 Updating : netdata-debuginfo-1.19.0-4.xcpng8.1.x86_64 3/6 Cleanup : netdata-ui-1.19.0-3.xcpng8.1.x86_64 4/6 Cleanup : netdata-debuginfo-1.19.0-3.xcpng8.1.x86_64 5/6 Cleanup : netdata-1.19.0-3.xcpng8.1.x86_64 6/6 Verifying : netdata-debuginfo-1.19.0-4.xcpng8.1.x86_64 1/6 Verifying : netdata-1.19.0-4.xcpng8.1.x86_64 2/6 Verifying : netdata-ui-1.19.0-4.xcpng8.1.x86_64 3/6 Verifying : netdata-ui-1.19.0-3.xcpng8.1.x86_64 4/6 Verifying : netdata-1.19.0-3.xcpng8.1.x86_64 5/6 Verifying : netdata-debuginfo-1.19.0-3.xcpng8.1.x86_64 6/6 Updated: netdata.x86_64 0:1.19.0-4.xcpng8.1 netdata-debuginfo.x86_64 0:1.19.0-4.xcpng8.1 netdata-ui.x86_64 0:1.19.0-4.xcpng8.1 Complete! [12:47 xcpngp02h01 ~]# [12:50 xcpngp02h01 ~]# systemctl status netdata.service ? netdata.service - Real time performance monitoring Loaded: loaded (/usr/lib/systemd/system/netdata.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2020-07-16 12:50:46 -03; 10s ago Process: 9810 ExecStartPre=/usr/libexec/netdata/xcpng-iptables-restore.sh (code=exited, status=0/SUCCESS) Process: 9807 ExecStartPre=/bin/chown -R netdata:netdata /var/run/netdata (code=exited, status=0/SUCCESS) Process: 9804 ExecStartPre=/bin/mkdir -p /var/run/netdata (code=exited, status=0/SUCCESS) Process: 9800 ExecStartPre=/bin/chown -R netdata:netdata /var/cache/netdata (code=exited, status=0/SUCCESS) Process: 9797 ExecStartPre=/bin/mkdir -p /var/cache/netdata (code=exited, status=0/SUCCESS) Main PID: 9816 (netdata) CGroup: /system.slice/netdata.service ??9816 /usr/sbin/netdata -P /var/run/netdata/netdata.pid -D -W set... ??9849 /usr/bin/python /usr/libexec/netdata/plugins.d/python.d.plu... ??9852 /usr/libexec/netdata/plugins.d/go.d.plugin 1 ??9854 /usr/libexec/netdata/plugins.d/freeipmi.plugin 1 ??9857 /usr/libexec/netdata/plugins.d/xenstat.plugin 1 ??9867 /usr/libexec/netdata/plugins.d/apps.plugin 1 [12:50 xcpngp02h01 ~]#
-
![0_1594914932062_Anotação 2020-07-16 125339.png](Uploading 100%)
-
Doe the netdata update not actually fix the missing network interfaces or virtual drives?
-
@Biggen I am not aware of this problem. Mine (updated) displays the server's 6 physical eth interfaces and 3 more xapi0 ~ xapi2 and 9 physical drives sda to sdi. I still not have multipath configured in the servers.
-
Perhaps it was fixed. The bug report doesn’t show it: https://github.com/xcp-ng/xcp/issues/379
I uninstalled it back in April and haven’t retested.
-
@Biggen The updated netdata packages display the vm's vbds data (in and out), but nothing for the vm's network interfaces. Not even its presence in the vm's domain.
-
@Biggen said in Updates announcements and testing:
Doe the netdata update not actually fix the missing network interfaces or virtual drives?
No, that bug is not fixed yet.
-
Anyone else who could test the netdata update candidate?
-
I have pushed the netdata update to XCP-ng 8.0 and 8.1's update repository.
-
Several update candidates have been available for some time in our testing repositories without me asking for feedback, so here is the request for tests.
XCP-ng 8.0
Update with:
yum update openvswitch xapi-core xapi-doc xapi-tests xapi-xe xcp-networkd --enablerepo=xcp-ng-testing
Changes:
- support for backups with RAM in Xen Orchestra
- openflow support in the SDN controller
- dhcp requests now properly send the hostname to the DHCP server
Aim of the tests:
- no regression after installation and reboot
XCP-ng 8.1
Update with:
yum update xapi-core xapi-doc xapi-tests xapi-xe xcp-networkd --enablerepo=xcp-ng-testing
Changes:
- fix compatibility with XenDesktop
- openflow support in the SDN controller
- dhcp requests now properly send the hostname to the DHCP server
Aim of the tests:
- no regression after installation and reboot
Counting on you
-
Simple message to bring the topic on top to increase the chances of feedback.
-
Updated a D54250WYK / i5-4250U / 16GB
XCP-ng 8.1 fully patchedSeems to work without unexpected issues, VMs are running fine.
My USB NIC setup / configuration stopped working, but that was somewhat expected.
I will fix this and report back, if I have an idea why it broke.
Works again after another shutdown / start sequence -
Updated xcp-ng 8.1 fully patched (Dell R710, dual L5640, 92GB).
no regression to report (but I am not using Xendesktop, SDN, and my dhcp already contains hostname) -
IMPORTANT Security updates!
Calling all stations
Please test it with
yum update qemu --enablerepo=xcp-ng-testing
.Might be a bad flaw, so earlier people get feedback, faster we can release it
-
@olivierlambert said in Updates announcements and testing:
qemu
Does this require a reboot or toolstack restart?
-
Good question. If I'm reading this correctly:
Once the hotfix has been applied, the affected guest HVM VMs will need to be restarted or migrated to an updated host to make the remediation effective.
In short, fresh
qemu
"fixed" process will be respawn at VM creation/reboot, so no need to reboot the host. -
Updated a D54250WYK / i5-4250U / 16GB
XCP-ng 8.1 fully patched including the update candidates from 11 days agoUpdate ran succesfully (no errors).
Rebooted the host just to be sure.
VMs came up with no problem and seem to work as expected (but I realy just fired them up and poked around a bit, so no real testing)