Red Hat Bugzilla – Bug 483650
ypbind binding fails after f10 -> rawhide upgrade
Last modified: 2009-06-11 07:47:24 EDT
After upgrading to rawhide, ypbind binds fail at ypbind service start, and remote users can no longer log in.
On the nis server, I get these logged errors:
Feb 2 14:15:28 server2 ypserv: refused connect from 192.168.0.89:56329 to procedure ypproc_match (nisavtech,shadow.byname;-1)
Downgrading to the F10 ypbind rpm fixes the problem. Has something changed in ypbind rawhide that affect nis shadow files?
My nsswitch.conf file is below.
passwd: files nis
shadow: files nis
group: files nis
hosts: files nis dns
bootparams: nisplus [NOTFOUND=return] files
netgroup: files nis
automount: files nis
aliases: files nisplus
More info - the F10 nis server has this ypserv.conf:
* : * : shadow.byname : port
* : * : passwd.adjunct.byname : port
Thanks for report. Your configuration files are OK. As I investigated it right now, I bet you don't use NetworkManager. There's fix of https://bugzilla.redhat.com/show_bug.cgi?id=480096 in Rawhide and it seems breaking ypbind functionality without NM. I'll look at it...
As you say, I don't use NetworkManager.
I have reverted back to F10, because rawhide created more problems than it solved for me. So I can't provide much more feedback...
*** Bug 484848 has been marked as a duplicate of this bug. ***
There's workaround - you should use "-no-dbus" option and binding works fine.
Creating the file /etc/sysconfig/ypbind containing the line
and doing a "service ypbind restart" works around the problem I was seeing with ypbind-1.20.4-13.fc11.i386 , and yes, I don't use NetworkManager.
Just to confirm comment #6. I am not using NetworkManager either, and using the "
-no-dbus" fixes my problems.
So what's the expected resolution in F11? "-no-dbus" on every client?
ypbind-1.20.4-19.fc11 has been submitted as an update for Fedora 11.
ypbind-1.20.4-19.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 504840 has been marked as a duplicate of this bug. ***