From nobody Fri Dec 02 10:18:21 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with UTF8SMTP id 4NNpn44sT1z4j0mC for ; Fri, 2 Dec 2022 10:18:32 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from cm0.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with UTF8SMTPS id 4NNpn36T9Lz4CZS for ; Fri, 2 Dec 2022 10:18:31 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd-current@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-current@dino.sk; dmarc=none Received: from zeta.dino.sk ([84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by cm0.netlabit.sk with ESMTPSA id 00000000025A8264.000000006389D0EF.000050F2; Fri, 02 Dec 2022 11:18:23 +0100 Date: Fri, 2 Dec 2022 11:18:21 +0100 From: Milan Obuch To: freebsd-current@freebsd.org Subject: Re: RFC: nfsd in a vnet jail Message-ID: <20221202111821.08d94524@zeta.dino.sk> In-Reply-To: <1955021.aDjkhKmpDe@ravel> References: <20221201110137.08b2b68c@zeta.dino.sk> <1955021.aDjkhKmpDe@ravel> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[dino.sk]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NNpn36T9Lz4CZS X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Fri, 02 Dec 2022 11:03:01 +0100 Olivier Certner wrote: > Hi, > > > (snip) > > > > #2 - Require separate file systems and run mountd inside the > > jail(s). > > > > I think that allowing both alternatives would be too confusing > > and it seems that most want mountd to run within the jail(s). > > As such, unless others prefer #1, I think #2 is the way to go. > > Just to be sure I've understood correctly: You plan to make a > separate filesystem as jail's root a requirement but only in the case > of using mountd(8) in the jail? Or in general? > > While I think doing so in the NFSv4/mountd case is indeed a good > idea, I don't think enforcing it in general is. It would generally > degrade the multiple jails management experience on UFS (in the > absence of a volume manager), where all jails have roots in the same > filesystem (to avoid allocating/deallocating space as jails come and > go or must be resized). > Exactly my thoughts. If forced generally, it would mean jails are no longer usable, effectively, for UFS based devices. Or, possibly, 'entry costs' for using jails would be much higher and thus less used. In my eyes, they will be no longer lightweight virtualisation tool, main jail selling point for me. Regards, Milan