[didn't think to subscribe to this bug, so I didn't see this until now] On Thu, 24 Dec 2015 10:57:02 +0100 Laurent Bigonville <bi...@debian.org> wrote: > > nis can't be the only rpc service that talks to rpcbind over inet rather > > than unix sockets, and custom rpc services are probably more likely > > to use inet. The path of least surprise is clearly to start rpcbind > > on inet socket access as well. > > > > You could argue that it should only start on access from localhost, > > unfortunately binding the loopback address from systemd prevents > > rpcbind from receiving remote calls, so that doesn't work. > > > > Therefore I propose /lib/systemd/system/rpcbind.socket be changed as > > follows: > > > > - --- /lib/systemd/system/rpcbind.socket.orig 2015-12-14 > 20:19:36.018585993 +0100 > > +++ /lib/systemd/system/rpcbind.socket 2015-12-14 20:14:32.905673475 > +0100 > > @@ -3,6 +3,11 @@ > > > > [Socket] > > ListenStream=/run/rpcbind.sock > > +ListenStream=[::]:111 > > +ListenStream=0.0.0.0:111 > > +ListenDatagram=[::]:111 > > +ListenDatagram=0.0.0.0:111 > > +BindIPv6Only=ipv6-only > > > > [Install] > > WantedBy=sockets.target > > Has this been tested? I actually don't think this is enough, the code > that manage the fd passed by systemd should also be adjusted. Not 100% > sure, but I'm afraid that if the activation is done by the inet socket, > the unix one will not work (and the opposite)
Yes, I'm running it on my nis clients, and I haven't seen any adverse effects. I suppose that clients trying to connect to the unix socket fall back to tcp or udp if it fails, but I think I checked with rpcinfo that I could talk to rpcbind over all transports. I can check again to be certain (though not right now). /Anders
