mgr/dashboard: set MOTD fails on FIPS enabled systems
Root cause: On FIPS-compliant systems, the OpenSSL provider rejects hashlib.md5() calls that lack the usedforsecurity=False flag, because MD5 is not an approved algorithm for security-sensitive use. This causes the MOTD set command — and the /api/motd create endpoint — to raise a ValueError and crash whenever a new MOTD is saved.
Fix: Pass usedforsecurity=False to hashlib.md5(). This tells the FIPS provider that MD5 is being used only as a non-cryptographic checksum (to detect whether a user has already dismissed a specific MOTD message), which is a legitimate use-case that FIPS allows.
mgr/DaemonServer: Make an ok-to-upgrade error message more generic
When no OSDs within a CRUSH bucket can be found to upgrade, the earlier error
message indicated the minimum number of PGs affected if any OSD was removed
from the set. For e.g.,
"Error EBUSY: unsafe to upgrade osd(s) at this time (at least X PG(s) will
become offline if any OSD out of the Y in CRUSH bucket 'foo' is stopped)"
This was inaccurate in some cases because the number of PGs affected is
determined only from the last tested OSD in the CRUSH bucket based on the sort
order (i.e., OSD with least number of PGs per OSD). Based on the CRUSH rules
and placement, this doesn't mean that the least number of PGs are affected if
this OSD is stopped. There may be other OSDs in the set that affect a smaller
number of PGs if made offline.
But with the way ok-to-upgrade logic uses the convergence factor, not all OSDs
would be tested for the offline pg check. Therefore, it is not possible to
accurately determine the minimum number affected PGs.
In view of the above, the error message is modified as shown below to be
slightly more generic but still convey the reason:
"Error EBUSY: unsafe to upgrade osd(s) at this time (one or more PG(s) will
become offline if any OSD out of the Y in CRUSH bucket 'foo' is stopped)"
python-common/rgw: fix get_realm_tokens returning empty result for realms with a secondary zone
Issue: The Export Multi-site Realm Token feature in the Dashboard showed no token and no realm details for any realm that had a secondary zone configured (i.e. the realm had been replicated to another cluster). The API endpoint GET /api/rgw/realm/get_realm_tokens returned an empty list or raised a 500 Internal Server Error.
ptl-tool: log the ceph-ci push (and the equivalent git command)
Previously, a real (non-dry-run) push of the integration branch/tag to
ceph-ci was silent -- only the "[DRY RUN] Would push ..." path logged
anything. Add matching log.info() calls on the real-push path, and
include the literal `git push <remote> <ref>` invocation in the message
so it can be copy-pasted and re-run manually if needed (e.g. after a
network blip, or to re-push without re-running the whole merge).
* refs/pull/52147/head:
PendingReleaseNotes: add an note about dmclock based scheduler for MDS
doc/config-ref: mention about MDS dmclock configurations
qa: use dmclock with fs:workload
mds: add MDS dmClock scheduler for subvolume QoS support
Reviewed-by: Venky Shankar <vshankar@redhat.com> Reviewed-by: Robin H. Johnson <robbat2@orbis-terrarum.net>
David Galloway [Fri, 17 Jul 2026 18:34:44 +0000 (14:34 -0400)]
container: default FROM_IMAGE to Rocky Linux 10
Since tentacle, the preferred base image for ceph containers has been
Rocky Linux 10, and the CI tag-naming logic in build.sh already assumes
rockylinux-10 is the default fromtag for every branch except reef and
squid. The actual build default was never flipped, though: anything
that ran build.sh without FROM_IMAGE set (e.g. the release container
job in ceph-build) still got a CentOS Stream 9 base.
Flip the Containerfile ARG and the build.sh fallback to
docker.io/rockylinux/rockylinux:10 so umbrella and later build from
Rocky 10 by default. Builds that want a different base can still pass
FROM_IMAGE explicitly, as the CI pipeline does.
Signed-off-by: David Galloway <david.galloway@ibm.com>
Aggressive Link-Time Optimization (LTO) and stricter linker defaults
in newer toolchains (like GCC 13 on Ubuntu 24.04) can strip or
localize external global variables if their visibility is not
explicitly defined. Tagging g_lockdep with default visibility ensures
it remains accessible in the dynamic symbol table for external
binaries like monmaptool.
Assisted-by: Gemini Fixes: https://tracker.ceph.com/issues/78321 Signed-off-by: Patrick Donnelly <pdonnell@ibm.com>
Devika Babrekar [Mon, 15 Jun 2026 11:17:16 +0000 (16:47 +0530)]
mgr/dashboard:EC Profile creation form simplification and improvement Fixes: https://tracker.ceph.com/issues/77369 Signed-off-by: Devika Babrekar <devika.babrekar@ibm.com>
Conflicts:
src/pybind/mgr/dashboard/frontend/src/app/ceph/pool/erasure-code-profile-form/erasure-code-profile-form-modal.component.html
-removed Directory field, as it is no longer needed in form
Devika Babrekar [Mon, 22 Jun 2026 14:53:17 +0000 (20:23 +0530)]
mgr/dashboard: Disable multisite Action dropdown for read-only user Fixes: https://tracker.ceph.com/issues/77570 Signed-off-by: Devika Babrekar <devika.babrekar@ibm.com>
Conflicts:
src/pybind/mgr/dashboard/frontend/src/app/ceph/rgw/rgw-multisite-details/rgw-multisite-details.component.html
- added disabled property on table component to disable the table
src/pybind/mgr/dashboard/frontend/src/app/shared/datatable/table-actions/table-actions.component.html
- added disabled property on table component to disable the table
crimson/os/seastore/transaction: new conflict/no_conflict trans
synchronization
Use seastar::shared_mutex to synchronize transactions when committing
no_conflict ones.
Specifically, this commit achieves conflict/no_conflict trans
synchronization by:
1. The no_conflict trans acquires locks on all the stable extents which
it modifies.
2. The conflicting trans acquires shared locks on all the stable extents
which it modifies.
3. The no_conflict trans releases the locks after its committing.
4. The conflicting trans releases the shared locks once it enter the
prepare pipeline phase.
This commits makes sure that:
1. only transactions accessing the extents that the no_conflict trans
is committing will be blocked.
2. avoid persisting extents that a committing no_conflict trans is
modified
Compared to the old approach, this commit's strategy is much more
straightforward and understandable.
This commit is more performant as the no_conflict trans only blocks
the trans the modified extent set of which intersects with it, while,
in the old approach, all other transactions will be blocked once a
conflicting trans is blocked because it's blocked after it enters the
prepare pipeline phase
Anoop C S [Wed, 15 Jul 2026 18:41:13 +0000 (00:11 +0530)]
cephadm/smb: Update CTDB bind mount for new socket path
Samba recently changed CTDB to derive its runtime paths from Samba's
configure options instead of using a monolithic CTDB_RUNDIR[1].
With current packaging[2], the CTDB socket path moved from
/var/run/ctdb/ctdbd.socket to /run/samba/ctdb/ctdbd.socket.
Update the CTDB runtime bind mount target from /var/run/ctdb to
/run/samba/ctdb to match the new CTDB_SOCKETDIR. Additionally,
create the CTDB pid directory, /run/ctdb, and lock directory,
/var/lib/samba/lock/ctdb, on the host side as they are hidden
when their parent directories are bind mounted over.
Ideally these directories should be created by sambacc but sambacc is
included in samba-container images that may be built with different
Samba packages where these path configurations might not hold true.
projects / ceph.git / log