From owner-freebsd-current@freebsd.org Mon Jun 18 21:55:21 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85E3B1024FF0 for ; Mon, 18 Jun 2018 21:55:21 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21AF575B06 for ; Mon, 18 Jun 2018 21:55:21 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from lrrr.mouf.net (cpe-24-163-43-246.nc.res.rr.com [24.163.43.246]) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id w5ILtD2b033735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Jun 2018 21:55:19 GMT (envelope-from swills@FreeBSD.org) Subject: Re: ESXi NFSv4.1 client id is nasty To: Rick Macklem , "freebsd-current@freebsd.org" Cc: "andreas.nagy@frequentis.com" References: From: Steve Wills Message-ID: <8ceea008-f827-580b-8ca6-4a5fcb028e83@FreeBSD.org> Date: Mon, 18 Jun 2018 17:55:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 18 Jun 2018 21:55:19 +0000 (UTC) X-Spam-Status: No, score=1.3 required=4.5 tests=RCVD_IN_RP_RNBL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99.2 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:55:21 -0000 Hi, On 06/18/18 17:42, Rick Macklem wrote: > Steve Wills wrote: >> Would it be possible or reasonable to use the client ID to log a message >> telling the admin to enable a sysctl to enable the hacks? > Yes. However, this client implementation id is only seen by the server > when the client makes a mount attempt. > > I suppose it could log the message and fail the mount, if the "hack" sysctl isn't > set? I hadn't thought of failing the mount, just defaulting not enabling the hacks unless the admin chooses to enable them. But at the same time being proactive about telling the admin to enable them. I.E. keep the implementation RFC compliant since we wouldn't be changing the behavior based on the implementation ID, only based upon the admin setting the sysctl, which we told them to do based on the implementation ID. Just an idea, maybe Warner's suggestion is a better one. Steve