> On Feb 14, 2022, at 2:40 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Mon, 2022-02-14 at 16:41 +0000, Chuck Lever III wrote: >> >> >>> On Feb 14, 2022, at 11:23 AM, Thomas Blume <tblume@xxxxxxxx> wrote: >>> >>> Hello Chuck, >>> >>> On Montag 2022-02-14 16:26, Chuck Lever III wrote: >>> >>>>> On Feb 14, 2022, at 4:26 AM, Thomas Blume via Libtirpc-devel >>>>> <libtirpc-devel@xxxxxxxxxxxxxxxxxxxxx> wrote: >>>>> >>>>> In some setups, it is necessary to try rpc protocol version 2 >>>>> first. >>>> >>>> Before applying this, I hope we can review previous discussions >>>> of >>>> this issue. I've forgotten the reason some users prefer it, or >>>> maybe I'm just imagining we've discussed it before :-) >>> >>> We've had a discussion about 1 year ago: >>> >>> https://sourceforge.net/p/libtirpc/mailman/message/37227894/ >>> >>> actually that encouraged me to send a patch, even though I >>> initially thought >>> is wasn't good enough for upstream. >> >> I agree that adding the sidecar file to toggle the rpcbind >> version order is a bit rough. >> >> >>>> The patch description, at the very least, has to have a lot more >>>> detail about why this change is needed. Can it provide a URL to >>>> threads in an email archive, for example? >>> >>> This goes back to an old SUSE bugreport following the change of rpc >>> protocol >>> version 2, 3, 4 to 4, 3, 2. >>> Below an description of issue the customer was seeing: >>> >>> --> >>> An 3rd party NFS Server is behind a F5 front end load balancer >>> device. >>> The F5 front end load balancer device is replacing IP addresses in >>> packets as >>> they head to a NFS server. >>> It replaces IP addresses in headers but as you might expect it does >>> not replace >>> the IP address within the RPC data payload, i.e. within RPC GETADDR >>> request, >>> which places an address there for the universal address or hint. >>> Without a >>> correct hint, the GETADDR reply which comes back gives an >>> unexpected address >>> which happens to be unroutable from the nfs client's point of view. >>> --< >>> >>> We agreed that this is rather an issue of the loadbalancer >>> hardware, but we >>> would have to address that anyway due to backward compatibility. >>> >>> So, the first question is, do we want to stay backward compatible >>> upstream? >>> We have to do that as distributor, but of course upstream is >>> different. >> >> Thanks for the reminder. I suggest that it should be included >> in the patch description if you post again so that it becomes >> part of the libtirpc commit history. >> >> >>>>> Creating the file /etc/netconfig-try-2-first will enforce >>>>> this. >>>> >>>> A nicer administrative API would enable you to update the whole >>>> rpcbind version order, but that might be more work than you want >>>> to pursue. >>>> >>>> It would be a nicer if, instead of a separate file, a line is >>>> added to /etc/netconfig to toggle this behavior, or provide the >>>> whole version order. E.g. >>>> >>>> # rpcbind 4 3 2 >>>> >>>> # rpcbind 2 4 >>>> >>>> Really, though, this isn't related to the transport definitions >>>> in /etc/netconfig, so a separate configuration file might be >>>> more appropriate. >>> >>> Thanks for the hints, if you deem a patch would be still desireable >>> I will work >>> on that. >> >> I'd like to hear other opinions. I'm not the maintainer of >> libtirpc, I'm just someone who is very opinionated :-) >> >> > > Quite frankly, if you're relying on the IP address in GETADDR being > correct, then you're going to be disappointed in a lot of > circumstances: the common practice of using NAT and MASQUERADING in > modern data centres (particularly when using virtualisation) typically > break it pretty badly. > In 1995, when RFC1833 was published, there wasn't that much widespread > use of NAT, and there certainly wasn't heavy use of containers for > hosting services like NFS, so it is understandable why this happened, > but today we should know better. Hi Thomas- Would it make sense to change the behavior of the libtirpc GETADDR implementation to ignore the embedded IP address and extract only the port number from the returned universal address? Then administrative intervention would be unnecessary. > So which applications are still relying on the address from GETADDR in > order to work correctly? As far as I know, 'mount' does not. I seem to > remember that 'showmount' is borken, and needs to be fixed. Others? -- Chuck Lever
