Re: should we make --enable-tirpc the default in current nfs-utils?

Chuck Lever
2009-06-09T15:29:26Z

On Jun 9, 2009, at 10:48 AM, Steve Dickson wrote:

> Chuck Lever wrote:
>>
>> On Jun 9, 2009, at 8:06 AM, Steve Dickson wrote:
>>
>>> Chuck Lever wrote:
>>>>>
>>>>>>>
>>>>>>>> I guess I just don't see why there has to be two switches for
>>>>>>>> this feature...
>>>>>>>
>>>>>>> Because people seem to want to disable IPv6 support completely
>>>>>>> on
>>>>>>> their
>>>>>>> systems... Because there is a striking lack of infrastructure
>>>>>>> for
>>>>>>> IPv6
>>>>>>> support (including GUIs for configurating ip6tables, lack of
>>>>>>> IPv6
>>>>>>> support in NetworkManager, no IPv6 support in tcp_wrappers,
>>>>>>> inability to
>>>>>>> disable IPv6 support in the kernel without hacking it out of
>>>>>>> /etc/modprobe.conf, and so on)... Because TI-RPC is one level
>>>>>>> of
>>>>>>> complexity, and IPv6 adds more complexity...
>>>>>>>
>>>>>>> We can probably remove --enable-ipv6, and just stick with
>>>>>>> --enable-tirpc, which implies IPv6 support, if you prefer that.
>>>>>> Actually I would like to do just the opposite... remove --
>>>>>> enable-tirpc
>>>>>> and stick with --enable-ipv6...
>>>>>>
>>>>>>> But it's a strange argument, when we have --enable-mount,
>>>>>>> --enable-nfsv4,
>>>>>>> and on and on.
>>>>>> Well, your examples are all defining functionality... not
>>>>>> libraries...
>>>>>>
>>>>>
>>>>> Right. I agree with Steve here. I think it makes sense to keep the
>>>>> knobs we expect people to twiddle to be for features and not
>>>>> necessarily for libs.
>>>>
>>>> I really don't understand why having TI-RPC in a library is
>>>> important
>>>> here.
>>>>
>>>> --enable-tirpc is a feature knob. Forget that it happens to be
>>>> in a
>>>> library. Either nfs-utils supports TI-RPC or it supports legacy
>>>> RPC.
>>>> The external behavior of nfs-utils changes.
>>>>
>>>> Legacy RPC is in a library too. It happens to be in a library
>>>> that is
>>>> included by default, so configure doesn't have to figure out
>>>> where RPC
>>>> support is and whether it is installed.
>>>>
>>>> What's the difference?
>>> Following this theory there should have been an --enable-glibc
>>> which obviously misguided...
>>>
>>> All configuration flags define functionality not supporting parts
>>> of those functionalities....
>>
>> That is exactly what --enable-tirpc does. The fact that it is in a
>> separate library is completely incidental. Either you get the new
>> code
>> and new features (such as support for rpcbind v3/v4 and support for
>> IPv6) or you get the legacy behavior.
>>
>> --enable-tirpc does more than look for a library. It switches in a
>> bunch of new code in nfs-utils itself, and enables new features and
>> new
>> behavior.
> I think this is splitting hairs... my friend... the only reason
> libtirpc is even in the picture is because we need RPC library
> code that had IPv6 support. Remember we (i.e the NFS community) were
> told by the glibc people that under no circumstances would we
> be able add IPv6 support to the glibc code. So Bull came up with
> the answer of using libtirpc and rpcbind. So libtirpc is a means
> to an end... and that end is IPv6 support...

I think you are making my argument for me. The fact that TI-RPC
support could go into glibc (but hasn't because of politics) suggests
that --enable-tirpc has nothing to do with a particular library. It
is solely a feature knob, just like all the other --enable switches
in ./configure.

>> I honestly don't see a distinction between --enable-gss, which adds
>> additional features in nfs-utils, but requires an additional library,
>> and --enable-tirpc, which adds additional features, but requires an
>> additional library.
> -enable-gss cause two daemon to be build and get installed which
> adds the Secure NFS functionality. --enable-tirpc only causes code
> paths to change, it add no functionality unless Ipv6 is enabled.

TI-RPC is not just an IPv6 enabler. It also has interoperability
implications. Support for rpcbind v3/v4 has no dependence on IPv6.
You can use rpcbind v3 or v4 requests over IPv4, for example, which
provides a significantly richer set of functionality. One area of non-
IPv6 interest would be support for registering local services via
AF_UNIX -- this type of registering is actually authenticated, so it
is a good security feature.

> So that's way I think all that is needed is an --enable-ipv6 flag.

Actually, the new statd is built only if --enable-tirpc is set. So,
yes: new code _and_ new components are provided if --enable-tirpc is
set. TI-RPC is very similar to Secure NFS functionality. Secure NFS
provides support for new RPC features known as RPCSEC GSS, and --
enable-tirpc provides support for new RPC features known as TI-RPC.
So again, I don't see any philosophical difference between --enable-
gss and --enable-tirpc.

However, --enable-ipv6 is unnecessary because we want, and have, run-
time switches for that support. We are forced to, because nfs-utils
has to run on kernels which may or may not support IPv6.

I am continuing to argue this point because getting rid of --enable-
tirpc will make our jobs a lot harder. The reason this knob is there
is to firewall the new code and keep upstream nfs-utils stable as we
integrate more and more support for TI-RPC.

If we call it --enable-ipv6, many distributions will say "so what, i
don't need that" and leave it turned off. We won't get the kind of
soak time we really need.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com