[PATCH ceph tentacle-stable-9 v2] patches: link the PVE cephx migration docs in the insecure key warnings

[PATCH ceph tentacle-stable-9 v2] patches: link the PVE cephx migration docs in the insecure key warnings

[Kefu Chai]

Ceph 19.2.6 and 20.2.4 added health checks for keys, service tickets and
cipher settings that still use aes. A node picking up the point release
starts reporting them, and the summary that `ceph -s` prints says only
that something is insecure, not what to do about it. The migration on
PVE goes through pve-cephx-rotate-service-keys, which also updates the
key copies that PVE manages, so the upstream procedure is not what a
user should follow here.

The web interface already explains every one of these checks and puts
the guide next to it, but a user reading `ceph -s` or `ceph health` over
ssh gets the summary and nothing else, so the link has to be in the
summary too.

Append it to AUTH_INSECURE_KEYS_ALLOWED and to nothing else. That check
is raised for as long as the monitors still allow aes, and the allowed
ciphers are restricted in the last of the three documented steps and
only by the helper, so the link tracks whether the migration is
finished. The other checks clear earlier: the two with error severity go
away in step 1, the rotating service key warning expires by itself, and
the last two are the ones the PVE docs tell users to mute while an
incompatible client keeps the migration from finishing. Appending the
url to those as well would print it up to six times in a single
`ceph health` line and in the cluster log.

The link is only useful on PVE, so there is no upstream commit behind
this patch: it is ours, and it stays in the series.

Signed-off-by: Kefu Chai <k.chai@proxmox.com>
---

Changes since v1:
* link only AUTH_INSECURE_KEYS_ALLOWED, not all six checks. That check is up
  for as long as the monitors still allow aes, so it tracks whether the
  migration is finished. The others do not: the two error severity ones clear
  in step 1, the rotating service key warning expires by itself, and the last
  two are the ones the PVE docs tell users to mute while an incompatible
  client remains.
* tested with a monitor built from this branch. The url appears in
  'ceph health', 'ceph -s', 'ceph health detail' and the cluster log while aes
  is allowed, and goes away when the ciphers are restricted to aes256k.
 ...link-the-PVE-cephx-migration-docs-in.patch | 53 +++++++++++++++++++
 patches/series                                |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 patches/0019-mon-AuthMonitor-link-the-PVE-cephx-migration-docs-in.patch

diff --git a/patches/0019-mon-AuthMonitor-link-the-PVE-cephx-migration-docs-in.patch b/patches/0019-mon-AuthMonitor-link-the-PVE-cephx-migration-docs-in.patch
new file mode 100644
index 0000000000..5388239b82
--- /dev/null
+++ b/patches/0019-mon-AuthMonitor-link-the-PVE-cephx-migration-docs-in.patch
@@ -0,0 +1,53 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Kefu Chai <k.chai@proxmox.com>
+Date: Thu, 15 Oct 2026 18:34:37 +0800
+Subject: [PATCH] mon/AuthMonitor: link the PVE cephx migration docs in
+ insecure key warnings
+
+Ceph 19.2.6 and 20.2.4 added health checks for keys, service tickets
+and cipher settings that still use aes, so PVE users can see them right
+after a point release upgrade without knowing what to do next. The
+migration has to be done with the pve-cephx-rotate-service-keys helper,
+which also updates the key copies managed by PVE, instead of the
+upstream procedure.
+
+The web interface explains each of these checks and links the guide
+next to them, but somebody reading "ceph -s" or "ceph health" over ssh
+gets the summary and nothing else, so the summary has to carry the
+link.
+
+Only AUTH_INSECURE_KEYS_ALLOWED carries it. That check is raised for as
+long as the monitors still allow aes, and the documented procedure
+restricts the allowed ciphers in its last step and only through the
+helper, so the check tracks whether the migration is finished. The
+others clear earlier: the two error severity ones go away in step 1,
+the rotating service key warning expires by itself, and the last two
+are the ones the PVE docs tell users to mute while an incompatible
+client keeps the migration from finishing. Linking those as well would
+repeat the same url up to six times in one "ceph health" line and in
+the cluster log.
+
+The summary points at the PVE documentation, so this change is not
+meant for upstream. It lives in the Proxmox patch series.
+
+Signed-off-by: Kefu Chai <k.chai@proxmox.com>
+---
+ src/mon/AuthMonitor.cc | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/mon/AuthMonitor.cc b/src/mon/AuthMonitor.cc
+index 00d3fe99344..434470c537b 100644
+--- a/src/mon/AuthMonitor.cc
++++ b/src/mon/AuthMonitor.cc
+@@ -498,7 +498,10 @@ bool AuthMonitor::check_health()
+       }
+     }
+     if (!details.empty()) {
+-      auto& check = next.add("AUTH_INSECURE_KEYS_ALLOWED", HEALTH_WARN, "Monitors are configured to allow auth using insecure key types", details.size());
++      auto& check = next.add("AUTH_INSECURE_KEYS_ALLOWED", HEALTH_WARN,
++                             "Monitors are configured to allow auth using insecure key types"
++                             ", see https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pveceph_cephx_migration",
++                             details.size());
+       for (auto& detail : details) {
+         check.detail.push_back(detail);
+       }
diff --git a/patches/series b/patches/series
index f6b8fda5f7..854eeb006b 100644
--- a/patches/series
+++ b/patches/series
@@ -19,3 +19,4 @@
 0015-bluefs-truncate-unused-allocation-on-close.patch
 0016-bluefs-fix-use_direct_io-override.patch
 0017-bluefs-acquire-file-lock-in-truncate.patch
+0019-mon-AuthMonitor-link-the-PVE-cephx-migration-docs-in.patch
-- 
2.47.3