See inner commit message for details.
Semi-related: ceph-common, which pulls in python3-rgw in the first
place, should really split up in a handful of packages, which would
avoid this issue for us too, as we do not require RGW tooling by
default.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Recent 18.2.4 release contained a cherry-pick of 0985e201342
("ceph-volume: use 'no workqueue' options with dmcrypt") and that
patch introduced parsing the output of `cryptsetup --version`, but it
had a coupling on either a old (or distro-specific) cryptsetup version
output and/or some legacy behavior of the python `packaging` module that
is used for the version parsing.
As the `cryptsetup` tool on bookworm outputs the following version:
> cryptsetup 2.6.1 flags: UDEV BLKID KEYRING KERNEL_CAPI
As the extra strings at the end are not accepted anymore by the
`packaging` python module in bookworm [0], this test fails ceph-volume when
encrypted OSDs are used, which we do by default.
[0]: due to https://github.com/pypa/packaging/pull/407 being included
in the bookworm version
To make this work again cherry-pick two patches that first filter out
the numerical part from the raw version output using a regex and only
pass that to the version parsing call.
Fixes: https://tracker.ceph.com/issues/66393
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
with a cycle through `git am -3 ...` in the upstream repo, `rm
*.patch` here, and `git format-patch --zero-commit --no-signature
--diff-algorithm=myers --no-numbered -o ...` in the upstream repo
again.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch makes it so that `ceph-crash` attempts to use the
non-host-specific keyring before anything else, which avoids
unnecessary error messages landing in the systemd-journal in our case.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ceph has a postinst hook that sets the ownership of '/var/lib/ceph/*'
to ceph:ceph (in our case), but misses out on the contents of
'/var/lib/ceph/crash'.
This patch therefore also recursively updates the permissions of
'/var/lib/ceph/crash'.
The change was also proposed upstream [0].
[0]: https://github.com/ceph/ceph/pull/55917
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Assume there is an open TCP connection to a VM, and ceph-osd is
installed/upgraded on the host on which the PVE firewall is active.
Currently, ceph-osd postinst reloads all sysctl settings. Thus,
installing/upgrading ceph-osd will set the sysctl setting
`net.bridge.bridge-nf-call-iptables` to 0. The PVE firewall will flip
the setting back to 1 in its next iteration (in <10 seconds). But
while the setting is 0, conntrack will not see packets of the existing
TCP connection. When the setting is flipped back to 1, conntrack will
see packets again, but may consider the seq/ack numbers of new packets
out-of-window, mark them as invalid and drop them. This will freeze
the TCP connection.
To avoid this, add a patch that modifies the ceph-osd postinst to only
apply settings from the sysctl settings file shipped with ceph-osd,
and only apply them on fresh install. As the ceph-osd sysctl settings
do not set `net.bridge.bridge-nf-call-iptables`, this will avoid the
temporary flip to 0 when installing/upgrading ceph-osd.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Adapt the patch that originally disabled certain TLS checks during the
dashboard's startup and fixes the `ceph dashboard` subcommand becoming
unavailable if the dashboard crashes during that time.
This is achieved by re-implementing certain checks and also re-raising
any other unforeseen exceptions that occur in regards to TLS as one
of Ceph's internal exception types, which are then handled by the
dashboard itself. This is akin to how these cases were handled
originally.
Also fixes a typo in the `ceph dashboard create-self-signed-cert`
command output.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
As Fabian correctly noticed, from the two PR's, namely PR #54918[0]
and PR #54891[1], only the first one is necessary, that's why the
second one was closed upstream, so drop it here too to avoid a
unnecessary divergence from upstream.
[0]: https://github.com/ceph/ceph/pull/54918
[1]: https://github.com/ceph/ceph/pull/54891
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch allows the dashboard to work again with TLS enabled; it
however disables the possibility to create self-signed certs via the
`ceph` CLI. This means that users will have to supply the correct
key/cert pair themselves, which are just a few extra steps instead. [0]
Users that try to generate a self-signed cert via the `ceph` CLI are
instead provided with instructions on how to generate and configure a
key/cert pair themselves.
Additionally, the check whether the cert and key match is removed during
the dashboard's launch.
See the patch for additional details.
[0]: https://docs.ceph.com/en/reef/mgr/dashboard/#ssl-tls-support
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
After upgrading from PVE 7 to PVE 8, some users noted that the Ceph
Dashboard does not work anymore. [0] A user from our community
provided a pull request [1] which removes a dependency to `PyJWT`
(Python). This commit adds a backport of this PR as a single patch.
This patch by itself however does not yet allow the dashboard to run
with TLS enabled.
[0]: https://forum.proxmox.com/threads/ceph-warning-post-upgrade-to-v8.129371/
[1]: https://github.com/ceph/ceph/pull/54710
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Some of our users ran into issues with running Ceph on older CPU
architectures [1]. This is apparently due to a bug in gf-complete
paired with gcc-12, that
leads to SSE 4.1 instructions being emitted in the general code,
rather than dynamically dispatching functions using those
instructions. Those binaries then break on older CPUs that do not
support this instruction set.
I've ran some benchmarks with `rados bench` against our last release
(18.2.0-pve2) and this new version. The commands were taken from our
latest Ceph benchmarking paper [2]. The results showed that this patch
does not lead to performance regressions on newer hardware.
18.2.0-pve2 this patch
Read EC 4574.28 4651.95
Write EC 3739.59 3773.87
Read Replicated 5345.34 5568.41
Write Replicated 4123.28 4066.19
(numbers correspond to bandwidth in MB/s)
[1] https://forum.proxmox.com/threads/proxmox-8-ceph-quincy-monitor-no-longer-working-on-amd-opteron-2427.129613
[2] https://www.proxmox.com/en/downloads/proxmox-virtual-environment/documentation/proxmox-ve-ceph-benchmark-2020-09
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
