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