From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 3A0581FF17C for ; Tue, 16 Dec 2025 08:24:54 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1A3F177AD; Tue, 16 Dec 2025 08:25:38 +0100 (CET) Message-ID: Date: Tue, 16 Dec 2025 08:25:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox VE development discussion , Dominik Rusovac References: <20251212130531.116019-1-d.rusovac@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20251212130531.116019-1-d.rusovac@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1765869922851 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [mon.pm, perl.org] Subject: Re: [pve-devel] [PATCH pve-manager] fix #7011: ceph monitor: set ownership of monitor logs X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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 > --- > 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