LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 07-11-2017, 04:00 PM   #1
tuxrules
Senior Member
 
Registered: Jun 2004
Location: Chicago
Distribution: Slackware64 -current
Posts: 1,152

Rep: Reputation: 60
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:

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]

Last edited by tuxrules; 07-11-2017 at 04:03 PM. Reason: additional info
 
Old 07-12-2017, 03:53 AM   #2
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,221

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
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.
 
1 members found this post helpful.
Old 07-12-2017, 08:39 AM   #3
tuxrules
Senior Member
 
Registered: Jun 2004
Location: Chicago
Distribution: Slackware64 -current
Posts: 1,152

Original Poster
Rep: Reputation: 60
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!
 
1 members found this post helpful.
Old 07-12-2017, 10:42 AM   #4
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,221

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
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 :-)

Last edited by rworkman; 07-12-2017 at 10:44 AM.
 
2 members found this post helpful.
Old 07-12-2017, 03:38 PM   #5
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,302

Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278
Quote:
Originally Posted by rworkman View Post
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
 
Old 07-12-2017, 05:48 PM   #6
tuxrules
Senior Member
 
Registered: Jun 2004
Location: Chicago
Distribution: Slackware64 -current
Posts: 1,152

Original Poster
Rep: Reputation: 60
Quote:
Originally Posted by rworkman View Post
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,
 
Old 07-12-2017, 06:15 PM   #7
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,221

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
Quote:
Originally Posted by tuxrules View Post
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.
 
Old 07-12-2017, 06:26 PM   #8
voegelas
LQ Newbie
 
Registered: Nov 2015
Location: Stuttgart, Germany
Distribution: Slackware, OpenBSD
Posts: 13

Rep: Reputation: Disabled
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.

Last edited by voegelas; 07-12-2017 at 06:27 PM. Reason: Wrong version numbers
 
Old 07-12-2017, 09:41 PM   #9
slacker1337
Member
 
Registered: Jun 2012
Location: Connecticut, USA
Distribution: Slackware
Posts: 115

Rep: Reputation: 36
Slackware-current rpcbind issue

I'm also having an issue with the most recent rpcbind update. I'll check hosts.allow asap
 
Old 07-13-2017, 09:12 PM   #10
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 276
Blog Entries: 6

Rep: Reputation: Disabled
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.

Last edited by number22; 07-13-2017 at 09:15 PM.
 
Old 07-14-2017, 01:53 AM   #11
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,221

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
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.

Last edited by rworkman; 07-19-2017 at 06:33 PM. Reason: Removed URL
 
Old 07-14-2017, 12:11 PM   #12
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 276
Blog Entries: 6

Rep: Reputation: Disabled
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.

Last edited by number22; 07-14-2017 at 12:13 PM.
 
Old 07-14-2017, 12:41 PM   #13
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,221

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
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.
 
2 members found this post helpful.
Old 07-14-2017, 02:58 PM   #14
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 276
Blog Entries: 6

Rep: Reputation: Disabled
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.

Last edited by number22; 07-14-2017 at 03:05 PM.
 
Old 07-14-2017, 03:18 PM   #15
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 2,221

Rep: Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709Reputation: 709
Quote:
Originally Posted by number22 View Post
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?
 
  


Reply

Tags
autofs, automount, nfs, rpcbind


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] slackware-14.2 -> last slackware-current upgrade python VTE issue suprateam Slackware 10 05-27-2017 08:21 AM
[SOLVED] Can anybody reason preferring rpcbind-0.2.3 + patches over rpcbind-0.2.4 louigi600 Slackware 7 02-25-2017 04:49 AM
[SOLVED] Can anybody reason preferring rpcbind-0.2.3 + patches over rpcbind-0.2.4 louigi600 Slackware - ARM 4 02-23-2017 02:27 AM
Rogue power off issue on slackware current 64 MarioMaster100 Slackware 19 07-19-2016 10:05 AM
Slackware current + gcc issue vexer Slackware 2 08-11-2003 12:05 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:42 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration