Fedora has issued an advisory today (March 5): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/OQTBKVXVYP7GPQNZ5VASOIJHMLK7727M/ The issues are fixed upstream in 15.2.9. Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOOStatus comment: (none) => Fixed upstream in 15.2.9
ceph-15.2.9-1.mga9 uploaded for Cauldron by Nicolas.
Whiteboard: MGA8TOO => (none)Version: Cauldron => 8CC: (none) => mageia
pushed in mga8: src: - ceph-15.2.9-1.mga8
Status comment: Fixed upstream in 15.2.9 => (none)Assignee: eatdirt => qa-bugs
Advisory: ======================== Updated ceph packages fix security vulnerabilities: A flaw was found in Ceph where Ceph stores mgr module passwords in clear text. This issue can be found by searching the mgr logs for Grafana and dashboard, with passwords visible. The highest threat from this vulnerability is to confidentiality (CVE-2020-25678). A flaw was found in ceph-dashboard. The JSON Web Token (JWT) used for user authentication is stored by the frontend application in the browser’s localStorage which is potentially vulnerable to attackers via XSS attacks. The highest threat from this vulnerability is to data confidentiality and integrity (CVE-2020-27839). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25678 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27839 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/OQTBKVXVYP7GPQNZ5VASOIJHMLK7727M/ ======================== Updated packages in core/updates_testing: ======================== ceph-mgr-15.2.9-1.mga8 ceph-15.2.9-1.mga8 ceph-radosgw-15.2.9-1.mga8 ceph-osd-15.2.9-1.mga8 lib64ceph2-15.2.9-1.mga8 lib64rados2-15.2.9-1.mga8 lib64radosgw2-15.2.9-1.mga8 lib64rgw2-15.2.9-1.mga8 ceph-rbd-15.2.9-1.mga8 lib64rbd1-15.2.9-1.mga8 ceph-mon-15.2.9-1.mga8 ceph-mds-15.2.9-1.mga8 lib64radosstriper1-15.2.9-1.mga8 python3-ceph-15.2.9-1.mga8 ceph-fuse-15.2.9-1.mga8 lib64rados-devel-15.2.9-1.mga8 ceph-immutable-object-cache-15.2.9-1.mga8 python3-rbd-15.2.9-1.mga8 python3-rgw-15.2.9-1.mga8 python3-rados-15.2.9-1.mga8 lib64ceph-devel-15.2.9-1.mga8 lib64rgw-devel-15.2.9-1.mga8 lib64radosstriper-devel-15.2.9-1.mga8 lib64rbd-devel-15.2.9-1.mga8 lib64radosgw-devel-15.2.9-1.mga8 from ceph-15.2.9-1.mga8.src.rpm
CC: (none) => eatdirt
https://ubuntu.com/ceph/what-is-ceph <quote> Ceph allows decoupling data from physical hardware storage, using software abstraction layers, providing scaling and fault management capabilities. This makes Ceph ideal for cloud, Openstack, Kubernetes and other microservice and container-based workloads as it can effectively address large data volume storage needs. </quote> Way above my paygrade - it is company level stuff. Installation pulls in something like 100 Mageia packages. /usr/share/doc/ceph/README.mageia provides a link to the ceph website. $ ceph Error initializing cluster client: ObjectNotFound('RADOS object not found (error calling conf_read_file)') To be expected when no initialisation has been performed. $ ceph --help works. $ ceph ping mon.* Error initializing cluster client: ObjectNotFound('RADOS object not found (error calling conf_read_file)') Updated the packages, a lot fewer this time. No problems there. Sending this on on the basis of a clean update. Assumed that mga7 is not affected. Please correct that if the assumption is wrong.
Whiteboard: (none) => MGA8-64-OKCC: (none) => tarazed25
The more I do this the more I learn that I don't know. This is one of those things. Going with a clean install looks good to me, Len. Validating. Advisory in Comment 3.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
I am arriving a bit late here as well, thanks again David...
For QA teams, please test package inconsistencies for ceph, starting a few binaries to see if nothing segfaults, that's all good. Setting up a ceph cluster is far above what is expected from you! Some info are there though: /usr/share/doc/ceph/README.mageia
Last remark, I think we were not concerned by these bugs, we don't have any high-evel level tools in our ceph, I've paid attention to not include those. Their compilation is buggy and they're superflous, everything can be done with CLI (we don't have dashboard for instance).
@TJ: yes we are definitely in the same boat. @Chris: README.mageia was not much help. As in the case of many other supported packages it speaks a language I do not understand. For instance OSD means 'on screen display' elsewhere but almost certainly means something else in Ceph. Without doing anything apart from copying a dummy config file into /etc/ceph I tried this: $ sudo ceph-volume lvm list No valid Ceph lvm devices found Tried this on a spare USB device: $ sudo ceph-volume lvm create --data /dev/sde1 Running command: /bin/ceph-authtool --gen-print-key Running command: /bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new 399e6458-565b-414c-ba2b-4c6b20245508 stderr: [errno 2] RADOS object not found (error connecting to the cluster) --> RuntimeError: Unable to create a new OSD id No segfaults or aborts anyway, so does this help?
/var/lib/ceph/bootstrap-osd/ is empty and there is no ceph.keyring on the system. I guess that has to be created somehow. Beyond me.
OSD in ceph is Object Storage Device
Advisory committed to SVN.
CC: (none) => ouaurelienKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0126.html
Status: NEW => RESOLVEDResolution: (none) => FIXED