Slackware-current rpcbind issue
 

I have been following -current and the latest update to rpcbind seems to have broken my nfs automounts via autofs. Before the latest update, I had no issues with rpcbind and automount but since the update, /var/log/messages is flooded with this:

There has been no changes to any of my config files. This same issue happens on my server too which runs 14.2 stable. rpcbind was updated for -stable too. Getting the exact same message on the server logs too.

Also wanted to mention that I've been doing slackpkg install-new with every update so I'm pretty sure I'm not missing any new packages. Cursory Google search brings up issues that are 5-6 years old. Not sure what broke here.

Any thoughts?

Thanks,

[EDIT] I've also rebooted a few times and tried to manually restart rc.rpc and rc.autofs [/EDIT]

Interesting. I've also noticed the new log messages but nothing broke here. The more worrisome ones are in syslog:

See if adding "rpcbind: 127.0.0.1" to /etc/hosts.allow makes a difference for you.

Thanks Robby. I don't see any issue in syslog, only /var/log/messages complains. Anyway, your suggestion to add "rpcbind: 127.0.0.1" to /etc/hosts.allow on my stable server seems to have done the trick. I had added the same line to hosts.allow on my client machine but apparently I also needed the same line added to the server for NFS to work again. Now the NFS clients can access mounts via autofs. The curious thing is that I never had to add rpcbind line to /etc/hosts.allow before latest current update.

Anyhow, this is how my /etc/hosts.allow looks now:

Thanks!

I still think there's a problem though, but I don't know why. hosts_access(5) says this:
Did you have any entries in /etc/hosts.deny ? If not, then the entr(y|ies) in hosts.allow should be redundant (though that certainly doesn't seem to be the case).

I've looked through all of the git commits since 0.2.3 of rpcbind and I don't see anything obvious that should be causing a problem. Have you ever done a git bisection, or are you interested in doing one? I'd just do it myself, but everything is still working for me.

As an aside, I'm happy to see that other folks still depend on NFS heavily :-)

I'm not running -current, but I'll tell you that I am a constant user of NFS. It probably handles 90% of my LAN traffic (the other 10% being a mix of samba/cifs and sftp). So I definitely appreciate the time you and others take to ensure it's working great :)

Well, yes I did and /etc/hosts.deny has not changed since I started using NFS years back. Here's my /etc/hosts.deny
I don't really know git that well and but I'd be interested to do one...since this is a learning opportunity. I'll read up a bit and do some digging around. In the meantime, I noticed libtirpc is needed by rpcbind and has been bumped to version 1.0.2. Trying to build and install to see what happens.

I won't be able to function at home without NFS since all my media, data and relevant info is on my home server running NFS on RAID1. 3 client machines would only be half as useful without NFS.

Thanks,

Well, rpcbind isn't listed there, so the original conclusion is still valid - those connections should be accepted by default.

Well, first of all, I'd probably try rolling back to the previous packages one at at time to see which one (if only one) is actually causing the problem. The old package source are in the 14.2/ sources:
From there, if you're still interested in doing a git bisect, I'll walk you through the process. That would likely be easier if you can get on IRC, but if not, no worries - we'll work out something.

I'm downgrading all my systems to rpcbind 0.2.3 right now. I've got IPv6 everywhere and rpcbind 0.2.4 just dumps core.

Slackware-current rpcbind issue
 

I'm also having an issue with the most recent rpcbind update. I'll check hosts.allow asap

After many tests; the main problem is user nis authentication with rpcbind-0.2.4 (both server and client sides run the same version); but nfs network share works if you don't needs nis users.

From client side rpcbind-0.2.4 connects to server side rpcbind-0.2.3; need to modify rc.rpc script with "/sbin/rpcbind -h 0.0.0.0 -l" on the client side. (client sides are all x86_64, server side is 32bit)

On my server, only downgrade rpcbind package back to 0.2.3 with vanilla script, rest of library and package are the latest.

This will take a bit of time, but I'd appreciate it if you'd figure out exactly where things went wrong. There's no guarantee that this will find it, but it *should*, I think.

In case the README doesn't display correctly, here it is:

rworkman: I tested; all worked, but need "-h 0.0.0.0" parameter to works with userid, otherwise nis user has no username on client side.

Client side used 64bit versions, server side used i586 version. (nfs mounts works).

And just to make sure; I reinstalled 0.2.4 from current on server, the problem still remain; client 0.2.4 can not work with server 0.2.4 for user authentication.

Unless you had to add that "-h 0.0.0.0" parameter before (the patch hit 14.2 | the new package hit -current), then I'm not satisfied with the "Solved" nature of this thread. Maybe I'm misunderstanding though, as I've never used NIS, but from what I can tell, everything was fine until those new packages hit the tree. What I want to find out is *exactly* what changed in the rpcinfo source to cause the problem. In other words, put the system back just like it was before the new packages, try out the stuff I posted, and report back. It's okay if you don't want to do that - I understand that it's a lot of time/effort involved - but that's the only way to get meaningful results.

so you used 0.2.3 patches into current tree (0.2.4), try to figure out which one helped; eve though nocve works too. I am baffled as well.

I tried rebuild 0.2.4 with --enable-debug, but not much info from it. so back rpcbind server with 0.2.3 from 14.2 tree.

We had 0.2.3 before and jumped directly to 0.2.4+cvepatches. Am I correct in understanding that 0.2.4 *without* the cve patches works exactly as 0.2.3 did?