public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Dominik Rusovac <d.rusovac@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-manager] fix #7011: ceph monitor: set ownership of monitor logs
Date: Tue, 16 Dec 2025 08:25:30 +0100	[thread overview]
Message-ID: <c5bdd343-b13d-48eb-bec2-1a925c6464e1@proxmox.com> (raw)
In-Reply-To: <20251212130531.116019-1-d.rusovac@proxmox.com>

Am 12.12.25 um 14:05 schrieb Dominik Rusovac:
> Ownership of ceph logs is now set to ceph:ceph after the creation of a
> new monitor and before the new monitor starts. Hence, effective ceph
> monitor logging on freshly set up ceph clusters no longer depends on the
> first upgrade of ceph-common.

Might it be a better fix to then change the postinst script of
ceph-common, or whatever packages postinst script creates those
directories, to chown them to ceph:ceph? That way it would also work
if one installs ceph directly, circumventing pveceph. While that is
not exactly something we promote, but it's not really hard, and
packaging is often a good place to take care of such things like
directory ownership

> 
> For setups (still) affected by #7011 it is required that ownership of
> ceph logs is set to ceph:ceph (either manually or due to some
> ceph-common upgrade), followed by a monitor restart.


> 
> Signed-off-by: Dominik Rusovac <d.rusovac@proxmox.com>
> ---
>  PVE/API2/Ceph/MON.pm | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/PVE/API2/Ceph/MON.pm b/PVE/API2/Ceph/MON.pm
> index 70fc158d..047337ea 100644
> --- a/PVE/API2/Ceph/MON.pm
> +++ b/PVE/API2/Ceph/MON.pm
> @@ -428,6 +428,12 @@ __PACKAGE__->register_method({
>                              $mon_keyring,
>                          ]);
>                          run_command(['chown', 'ceph:ceph', '-R', $mondir]);
> +
> +                        eval {
> +                            run_command('chown ceph:ceph /var/log/ceph');


For new usage of run_command it's nicer to be explicit and pass the command
directly as array, above can be transformed as is, but...

> +                            run_command('chown ceph:ceph /var/log/ceph/*.log*');

the one above here would need to be either wrapped in a shell for the GLOB
to still work, which is effectively happening if you pass commands as simple
string to run_command anyway, or alternatively:

- dir_glob_regex + the chown function [0] (syscall), which is much cheaper 
  than executing a new process. While speed/efficiency might no matter much
  here, it's IMO still good to try to leverage some relatively cheap
  approaches to avoid basic overhead (it can add up).

- Execute chown -R for the whole log directory - but is that actually
  sensible? If logs where written by a process that did neither run as
  ceph:ceph and thus created the logs as that user implicitly, nor run as
  root and created the log files with ceph:ceph explicitly, what point is
  there in "fixing them up once on a fresh create"?

As written at the top of my reply, I'd slightly prefer to fix this in ceph
packaging; that said, we do can create a workaround here, as a pve-manager
update is much quicker to roll out and backport to PVE 8, but ideally we
could remove doing that sometimes in a next release again, once all supported
ceph versions correctly create directories from their packaging itself.
For the workaround I currently wouldn't have any strong preference which
option to use, but, as mentioned, I'm not a fan of implicitly relying on
run_command wrapping strings in a "sh -c", and that being the only reason that
the glob above works.

[0]: https://perldoc.perl.org/functions/chown


> +                        };
> +                        warn "$@" if $@;
>                      };
>                      my $err = $@;
>                      unlink $monmap;



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  parent reply	other threads:[~2025-12-16  7:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12 13:05 Dominik Rusovac
2025-12-12 15:38 ` Maximiliano Sandoval
2025-12-16  7:25 ` Thomas Lamprecht [this message]
2025-12-16 12:06   ` Maximiliano Sandoval
2025-12-16 12:14     ` Thomas Lamprecht
2025-12-16 12:54       ` Maximiliano Sandoval
2025-12-17  7:33         ` Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5bdd343-b13d-48eb-bec2-1a925c6464e1@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.rusovac@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal