From nobody Sat Jul 22 03:50:42 2023 X-Original-To: freebsd-fs@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 ESMTP id 4R7CBY2JMbz4p260 for ; Sat, 22 Jul 2023 03:50:45 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R7CBY1bncz3NWg; Sat, 22 Jul 2023 03:50:45 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689997845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QwEZn38aWA1ZYngcmgILZXVZkb1Kj7EbHp23sXsXqRU=; b=ur4F5AVVK/sXqQ25/BlrK272nisD9BvFgLb+vCZvGXwf7+zM8LTackw6YaU5R7dWpub3oq jR2h1QfgXrpk1Hl7i0jkNF3cG50F+AKdsmwXOQbyG9xEEzMHns85vhmius3VYmObEbiLfG dATkAR+8N7JBqVHvgjN0syVmQpijxroRDVos+4/zSDnMKhSkG7Iqfv//lr5Kgiw9IHmAOl En/WPqq6fQ9XHqxsat/j+ZKC6dBR8KMxD34L5a1DW7lMgPqT2O8eRCADs9lgfTndLT1SKK uxMc6RxvtwzsjlojWLb67C1N9mOGxHaLW2se+5NwF4urc/Rr2yIALTO1QuBUkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689997845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QwEZn38aWA1ZYngcmgILZXVZkb1Kj7EbHp23sXsXqRU=; b=Pxj32EgTScm6qo1YQWVAgfnEkFYJ8Rdhc1X1H2owUHYkWhaGHSgajbdIPBy4ElDwAO8wir MALAo0YKZ/6i1W7kRo9OWiyJmfKjHWtDNp0Befxs0t1dS7JrozpfSGW1ll8Zp5urrCb6n8 U5XpV9D+fFfAEGWVb/KOaCKXQSipkkiHEHoWHMounTk0r8PmhV+nT4MoKCktvFQ6PS9lYx efdcsLQ34EmQa1zs5QZa7amsjwg3kdEixPPDhLb85yAuYcOp+I/Cw1zp6LRS+knynghB/T Cn2AVhE8FajCnvW0mNfrx1PcxlnpNYDeWd5YaLlTOVKFY5Opmpyxgfc9FOrGjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689997845; a=rsa-sha256; cv=none; b=LcDSYUSQ0KgPsyw05OljMRpwTXxuj3YCqaM5+GAnGolFGe+9JEnY/HO/BaydGqieW+OTEo 4aCnmS9BBFzhUZeiI0tnxQWGUxMr/QXP7A6JKSU5fS2WdLBk7ewQ5d1XPJ0Ns1e2XI/Wjs urF9qdwCWvGCZIBINLjVYK8my8nOmoiKIVwFCpyUN4GA5/oWDABcmptFzpXbEQ9gZXuSyw L9Wovm7kmVnCyZcwOB+SIZf5GfvzKYfUAFdH98RLFBitaokaL3wgyJe3vgTzLM4t/RwQn1 0GXdJBI6I6DNSu27eDp/VzuM/OIts2BtXfq0DjYBm95VEbtA/bI7pgjluH9QyA== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4R7CBX5mmVzGw0; Sat, 22 Jul 2023 03:50:44 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <19330773-51dd-d3ed-5cff-c4a139b130ee@FreeBSD.org> Date: Fri, 21 Jul 2023 22:50:42 -0500 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: RFC: Patch for mountd to handle a database for exports Content-Language: en-US To: Rick Macklem , Peter Eriksson Cc: FreeBSD FS References: <2D8B626E-82BB-410C-B7C7-35B4D3834A44@lysator.liu.se> From: Kyle Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 7/21/23 18:07, Rick Macklem wrote: > On Fri, Jul 21, 2023 at 1:33 PM Peter Eriksson wrote: >> >> >> I did try to fix that but the code quickly got hairy so I didn’t like it. If we really want/need that I’m thinking of creating a special case for the V4: handling, sort of like prefixing the database key with a NUL byte or something (so that it will be sorted first). >> >> Does the ZFS share property generate a V4: line? >> I doubt anyone will convert a non-ZFS /etc/exports file to a DB file, >> so support of that does not seem to be needed. >> >> I see this as useful for the ZFS share property case, >> so if that works correctly, I do not see the above as a concern. >> >> >> No, the ZFS share property stuff never generates the V4: line(s) so it’s not a problem for the /etc/zfs/exports.db case. >> >> And converting /etc/exports to /etc/exports.db is not really necessary from a performance point since I doubt it ever will be very long. >> However I bet some enthusiastic fellow is bound to try to do it sometime in the future just because it can be done :-) >> > Yep. Capturing this in a man page update when the time comes needs > to be done, I think? (That the V4: line doesn't work in the DB.) > >> >> >> Multiline options - well, the current ZFS code doesn’t support it either so no change from the current setup but it would be nice to have. >> Ie, support for things like: >> /export -sec=krb5 >> /export -sec=sys ro >> >> Yes. There is at least one PR that requests that the ZFS share property >> be enhanced to do this. Part of the reason for getting this patch in main >> is so that this can be pursued. >> >> Again, I only see this as a ZFS share property issue because I do not >> see any reason to convert /etc/exports flat files to db files? >> >> >> I agree that the need probably isn’t there. >> >> The current DB code will generate a syslog(LOG_ERR) warning if it detects anything not starting with / in the keys (and ignores it). >> >> Perhaps there should be a warning in the manual for mountd about not trying to convert /etc/exports into a DB (if it uses NFSv4 / the “V4:” line(s)). >> Or should we just special-case /etc/exports and forbid the check for /etc/exports.db? >> >> - Peter >> >> rick >> >> >> >> >> >> >> (I also agree that the USE_SHAREDB probably should be removed, I just have that here for now so that I can quickly disable the code) >> >> Regarding the patch to the zfs part - I’m not sure which way to go there - the current patch switches to always use the DB. But one could argue that the code could check for an existing /etc/zfs/exports.db and only use the DB-writing code if that already exists. That way it will support both the old way and the new way, but it requires an empty /etc/zfs/exports.db to be pre-created at initial boot time for it to start using it. > > That's up to the ZFS folk. Hopefully kevans@ can figure it out. > I was going to massage it a bit before passing it up for review; my preference (that I think will make it fairly easy to accept upstream) is that we simply prefer exports.db if it exists but otherwise don't change anything for the folks happy with their current setup -- at least for an interim period, at a minimum. Thanks, Kyle Evans