[SOLVED] Slackware-current rpcbind issue

tuxrules · 07-11-2017, 04:00 PM

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:

Code:

Jul 11 15:52:53 shakal rpcbind[26286]: connect from 127.0.0.1 to getport/addr(status)

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]

rworkman · 07-12-2017, 03:53 AM

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

Code:

Jul 12 08:51:08 darkstar rpcbind[14685]: connect from 127.0.0.1 to getport/addr(status): request from unauthorized host

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

tuxrules · 07-12-2017, 08:39 AM

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:

Code:

# rpcbind line added post -stable and -current update on 7/10/2017
rpcbind: 127.0.0.1
portmap: 192.168.2.6 , 192.168.2.4 , 192.168.2.8
lockd: 192.168.2.6 , 192.168.2.4 , 192.168.2.8
mountd: 192.168.2.6 , 192.168.2.4 , 192.168.2.8
statd: 192.168.2.6 , 192.168.2.4 , 192.168.2.8
rquotad: 192.168.2.6 , 192.168.2.4 , 192.168.2.8

Thanks!

rworkman · 07-12-2017, 10:42 AM

I still think there's a problem though, but I don't know why. hosts_access(5) says this:

Code:

     The access control software consults two files. The search stops at the first match:
       ·      Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.
       ·      Otherwise, access will be denied when a (daemon,client) pair matches an entry in the /etc/hosts.deny file.
       ·      Otherwise, access will be granted.

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 :-)

bassmadrigal · 07-12-2017, 03:38 PM

Quote:

Originally Posted by rworkman

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

tuxrules · 07-12-2017, 05:48 PM

Quote:

Originally Posted by rworkman

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).

Well, yes I did and /etc/hosts.deny has not changed since I started using NFS years back. Here's my /etc/hosts.deny

Code:

portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

Quote:

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.

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.

Quote:

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

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,

rworkman · 07-12-2017, 06:15 PM

Quote:

Originally Posted by tuxrules

Well, yes I did and /etc/hosts.deny has not changed since I started using NFS years back. Here's my /etc/hosts.deny

Code:

portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

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

Quote:

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.

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:

Code:

https://mirrors.slackware.com/slackware/slackware-14.2/source/n/libtirpc/
https://mirrors.slackware.com/slackware/slackware-14.2/source/n/rpcbind/

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.

anon074 · 07-12-2017, 06:26 PM

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.

slacker1337 · 07-12-2017, 09:41 PM

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

number22 · 07-13-2017, 09:12 PM

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.

rworkman · 07-14-2017, 01:53 AM

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.

Code:

Removed URL because the contents will go away now that they're not needed any more

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

Code:

These packages are for testing this issue:
http://www.linuxquestions.org/questions/slackware-14/slackware-current-rpcbind-issue-4175609662/

There are five directories here:
  14.2-i586
  14.2-x86_64
  current-i586
  current-x86_64
  rpcbind  (build script, source, patches)

Each package has a TAG of _rlw_something where "something" indicates
what has been removed. 

The "nocve" package removes the three CVE patches.
The "no8" package removes patch 0008-*
The "no6" package removes patch 0006-* and 0008-*
The "no5" package removes patch 0005-* 0006-* and 0008-*
The "no4" package removes patch 0004-* 0005-* 0006-* 0008-*
The "no2" package removes patch 0002-* 0004-* 0005-* 0006-* 0008-*
The "no1" package removes *all* of the patches from 0.2.3 to 0.2.4.

The only exceptions are patch 0007 (it added a systemd unit file)
and patch 0003 (it is required to build against newer libtirpc).

Try these packages in reverse order that they're listed; in other 
words, try nocve first, then no8, then no7, and so on until you
find that things work as expected before the update to Slackware.

number22 · 07-14-2017, 12:11 PM

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.

rworkman · 07-14-2017, 12:41 PM

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.

number22 · 07-14-2017, 02:58 PM

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.

rworkman · 07-14-2017, 03:18 PM

Quote:

Originally Posted by number22

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?