From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 29DD89DFF5 for ; Mon, 30 Oct 2023 12:06:31 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0C165E5FD for ; Mon, 30 Oct 2023 12:06:01 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 30 Oct 2023 12:05:59 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id BDDA241E60 for ; Mon, 30 Oct 2023 12:05:59 +0100 (CET) Message-ID: Date: Mon, 30 Oct 2023 12:05:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Content-Language: en-US To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20231018103911.3798182-1-d.csapak@proxmox.com> <20231018103911.3798182-2-d.csapak@proxmox.com> <9f41a51d-e6ca-49bf-a959-e989d3ec8bad@proxmox.com> From: Dominik Csapak In-Reply-To: <9f41a51d-e6ca-49bf-a959-e989d3ec8bad@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.498 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 NICE_REPLY_A -2.972 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [RFC proxmox 1/3] new proxmox-server-config crate X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2023 11:06:31 -0000 On 10/25/23 18:38, Thomas Lamprecht wrote: > Would name it "proxmox-rest-server-config" or "proxmox-api-config", and here > I'm asking myself (without really trying to answer it myself): why isn't > this part of proxmox-rest-server, it's only relevant when used in combination > of there, simply to allow use-sites that do not depend on the rest of that > crates code? > you're right that it's currently only used together with the rest-server, but i though it might bite us in the future if we put that together. We might want to have some daemons that does not have a rest part in the future? e.g. like we now have a few of them in PVE (pvestatd, qmeventd, spiceproxy) also having more smaller crates does improve compile time for boxes with many cores (not really an argument for or against, just a side effect) > Also, mostly important for the other two crates: did you check the history > of the files you mode? If there's anything relevant, I'd favor isolating that > and then merging it in, like I did when splitting out rest-server, but it can > sometimes be a bit of a PITA, so can be decided case-by-case for those new > crates.. > i'll look into it. I did not spend much time on such things for the RFC. just wanted to see how others feel about the general approach > Am 18/10/2023 um 12:39 schrieb Dominik Csapak: > >> diff --git a/proxmox-server-config/src/lib.rs b/proxmox-server-config/src/lib.rs >> new file mode 100644 >> index 0000000..8377978 >> --- /dev/null >> +++ b/proxmox-server-config/src/lib.rs >> @@ -0,0 +1,302 @@ >> +//! A generic server config abstraction >> +//! >> +//! Used for proxmox daemons to have a central point for configuring things > > "Used for API daemons of Proxmox projects as a central point for configuring their > base environment, like ..." > > (Proxmox is our TM and is not a project itself) yes, of course > >> +//! like base/log/task/certificate directories, user for creating files, etc. >> + >> +use std::os::linux::fs::MetadataExt; >> +use std::path::{Path, PathBuf}; >> +use std::sync::OnceLock; >> + >> +use anyhow::{format_err, Context, Error}; >> +use nix::unistd::User; >> + >> +use proxmox_sys::fs::{create_path, CreateOptions}; > > this alone here is probably causing 90% compile time ^^ > we really need to split proxmox-sys more, but that's orthogonal to this > series > true, IMHO at least the 'fs' part would warrant it's own crate >> + [snip] >> +pub struct ServerConfig { > > Lacks doc comments for members, please add some even if they're > private. sure > >> + name: String, >> + base_dir: PathBuf, >> + user: User, >> + privileged_user: OnceLock, >> + >> + task_dir: OnceLock, > > not sure if this should be an option, e.g., for simple CRUD > API daemons there might not be any worker tasks at all. > that's one reason i used OnceLock, since it's only created when either one sets it manually, or access it the first time but Option would work too ofc if that's preferred > >> + log_dir: OnceLock, > > maybe: access_log_dir (as this is the api access log that other if we move it to rest server i agree, but otherwise i'd leave it more generic (other daemons might have logging needs besides the access log) > >> + cert_dir: OnceLock, >> + state_dir: OnceLock, >> + run_dir: OnceLock, >> + config_dir: OnceLock, >> +} >> + >