Bug 361475 – net-nds/rpcbind-0.2.0 should support USE=-ipv6

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Guido Jäkel 2011-03-31 14:17:55 UTC]

At boot time the start of rpcbind fails when module ipv6 isn't availble (by autoload feature), therefore NFS mounts will not come up.

At the moment, the whole system is build with USE="-ipv6".  But the ebuild of rpcbind don't provide a ipv6-useflag to disable this.


If i provide a ipv6 module after boot, a simple 'mount -a' will make things come up in a proper way. The module is loaded by this.

[Comment 1 SpanKY 2011-04-06 22:16:13 UTC]

Created attachment 268777 [details, diff]
rpcbind-0.2.0.ebuild.ipv6.patch

you can try this patch to the ebuild, although you really should get out of the stone age and support IPv6

and no, rpcbind itself does not attempt to load any module.  any autoloading is due to other configuration in your system.

[Comment 2 Guido Jäkel 2011-04-07 07:46:22 UTC]

Dear SpanKY,

thanks for support and your proposal, i'll check out your hint suggested by the patch asap.

Of course we all should get out of the stone age, but it seems to me that will be easier to introduce IPv6 outside in the internet than in a large companies intranet ;)

It's no great deal to enable ipv6 in the kernel despite of it's not used yet, but as long as Gentoo provides a global common use-flag to enable/disable ipv6 this should by respected as much as possible. I disabled it for security to avoid open backdoors, because no one will take care of ip6 configuration of applications yet.


An if rpcbind in fact isn't designed to be compiled or usable without the IPv6 stack available, it may be marked inside the ebuild.

I'm still a ebuild newbie but i notice some maybe appropriate inside the app-emulation/lxc ebuild: A declaration of CONFIG_CHECK="~foo" and corresponding error message declarations ERROR_foo="bar"

[Comment 3 Guido Jäkel 2011-04-07 11:07:26 UTC]

Dear SpanKY,

I have verified that the Makefile is patched through the prepare step.
But the resulting rcpbind still fails at startup with an

    FATAL: cannot create socket for udp6


This message is from  rpcbind.c, L. 308. I havn't figure it out yet, but at some part of the code a #ifdef INET6 clause is missing. This seems to cause something ipv6 related in the sockets to set up. Maybe the automatic binding to "::1"?

[Comment 4 Guido Jäkel 2011-04-07 13:22:17 UTC]

After adding IPV6 support to the kernel as static, the error messages of rpcbind disappears.

But the netmounts don't happen, however. It turns out, that the core reason for this is a issue in the /etc/init.d/netmount script. I fully confirm the situation if found described in bug #362331 a few minutes before.

If i disable the the test for the portmap service or change it to test for the rpcbind, the nfs keywords are not stripped from the file system type list.


I'll continue to figure out, if this "FATAL" error messages of rpcbind in case of absence of the ipv6 stack are not only cosmetical problems.

[Comment 5 Guido Jäkel 2011-04-08 10:19:23 UTC]

Dear SpanKY,

now, after get  /etc/init.d/netmount  working with rpcbind, it turns out that the *unmodified*  rpcbind-0.2.0  will output the two messages

  FATAL: cannot create socket for {udp,tcp}6

if the kernel have *no* support for ip6 included, but will be started nevertheless with the ip4-sockets opened. 

  # netstat -tulpn | grep rpcbind
  tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      6480/rpcbind        
  udp        0      0 0.0.0.0:111             0.0.0.0:*                           6480/rpcbind        
  udp        0      0 0.0.0.0:715             0.0.0.0:*                           6480/rpcbind  

All nfs are up and available, and i can't see any other regression in functionality, yet. From that, the error messages may be treated as "cosmetic".

Because the work derived so far -- to chain the use flag -ipv6 as a -DINET6 -- will not fix the issue because of upstream source code quality, you as the Gentoo maintainer may decide to close the bug as "won't fix here in Gentoo", may point the rpcbind maintainer to this.

And the efforts of the Gentoo team should be focused on #362331.


Thank you for quick support and suggestions

Guido

[Comment 6 SpanKY 2012-05-07 21:36:59 UTC]

*** Bug 415021 has been marked as a duplicate of this bug. ***

[Comment 7 Sam James 2021-08-19 18:42:54 UTC]

Thanks for your efforts. Let's call this UPSTREAM as it's not something we can handle.

[Comment 8 Guido Jäkel 2021-08-20 05:44:59 UTC]

Hi Sam,
it's OK to clean up the gruft here. But for the log: Even 10 years later, we don't use IPv6 -- but at least, still Gentoo ;)
Guido