On Jan 6, Dirk Hoffmann wrote:

I installed SL7 yesterday from the standard DVD in "Computing node" flavour.
"yum update" ran correctly, then I needed YP/NIS. Network configured and
working (one if out of six activated). Connection from and to my new host
working correctly.

Problem solved. I had configured my network on command line with ip(1) and set the (for now) only connected interface to NM_CONTROLLED="no" in /etc/sysconfig/network-scripts/ in order to avoid interferences.

However, the present (SL7) version of ypbind(8) uses dbus-daemon(1) to be notified (by NetworkManager(8)) when a network connection becomes available. Otherwise it assumes that network is down and does not register with rpcbind(8). This can be avoided with the -no-dbus switch of ypbind(8) (and made permanent in /etc/sysconfig/ypbind with OTHER_YPBIND_OPTS=-no-dbus).

I saw that NetworkManager(8) has a nice commandline interface nmcli(1) now, which allows all network configurations without need for gnome-control-center or other graphical interfaces, but is still more compatible than hand-editing /etc/sysconfig/network-scripts/ (which I did in the first place).

Hence, I learned a lot and cannot blame SL7 not to work with ypbind … if you don't tamper too much with system settings using too-low-level tools. ;-)

In particular no disabling of SELinux or iptables or other voodoo trick is needed for ypbind.

Thanks for your swift answers everybody!
                                                                        Dirk


PS: For the sake of it, I answer or comment previous questions below, where relevant. Please note that in my case I have to integrate a single special-purpose PC into existing lab infrastructure, which excludes opening roads towards LDAP or IPA.

On Jan 6, Stephen Berg (Contractor) wrote:

Does /usr/bin/ypwhich return the name of one of your NIS master's or slave's?

No, as long as rpcinfo(8) does not show ypbind, all yp-tools yield errors like
"ypwhich: Can't communicate with ypbind".

On Jan 6, Stephen John Smoogen wrote:

You forgot portmap restart. That is the one that I found usually fixed this
issue.

I discovered that ypbind(8) service automagically starts rpcbind(8) as a service, if not up yet. There are various and reliable options in for example
 /etc/systemd/system/multi-user.target.wants/ypbind.service
alike
 After=syslog.target network.target rpcbind.service ypserv.service 
NetworkManager-wait-online.service
 Requires=rpcbind.service
 ExecStartPre=/usr/libexec/ypbind-pre-setdomain
ExecStartPre=-/usr/sbin/setsebool allow_ypbind=1 It is off-topic, but quite intuitive to guess what they do. Amazing, anyway!

There is no such thing as portmap on my SL7. I understood that it is rpcbind(8) or part of it now.

After that I usually check to see that the box knows what the domain server
is. Is DNS working, is it in /etc/hosts.

It is not absolutely necessary (in case I try to start ypbind manually
again later). But it is good practice, indeed, to put some vital IPs
into that file (which I hadn't). I figure the "NetworkManager-wait-online" mention in ypbind.service is supposed to handle that also (i.e. wait until network/DNS are visible to ypbind). But it does not seem to do always in my case.

On Jan 6, Konstantin Olchanski wrote:

I can confirm that NIS does work (can be made to work) in SL7, but out of the box, it will not work. I do not have all the steps written down yet, but at the least, you have to turn off the firewall.

I am not able to confirm this (any longer) 100%.

Well, if LDAP is light-weight, I hate to see what they consider as normal-weight.

"LDAP is a "lightweight" (smaller amount of code) version of Directory Access Protocol (DAP), which is part of X.500, a standard for directory services in a network. LDAP is lighter because in its initial version it did not include security features [...] accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack." dixit Google :-)

Reply via email to