When setting up a new CentOS 6.2 client machine in an existing NIS environment, several clear symptoms indicate binding failure:

# Critical error indicators:
$ ypwhich
ypwhich: Can't communicate with ypbind

$ rpcinfo -p | grep yp
(no output - missing RPC registrations)

$ ls -la /var/yp/binding/
total 0
(empty directory)

Before diving deeper, let's confirm fundamental connectivity:

# Test basic network access:
$ ping swordfish
PING swordfish (192.168.1.10) 56(84) bytes of data.
64 bytes from swordfish (192.168.1.10): icmp_seq=1 ttl=64 time=0.321 ms

# Verify NIS server port accessibility:
$ nc -zv swordfish 111
Connection to swordfish 111 port [tcp/sunrpc] succeeded!

Despite service manager reporting success, we need to examine actual process behavior:

# Check running processes:
$ ps aux | grep ypbind
root      3172  0.0  0.1   4328  1024 ?        Ss   14:21   0:00 /usr/sbin/ypbind -n

# Review detailed service status:
$ service ypbind status
ypbind (pid  3172) is running...

The empty binding directory suggests configuration issues. Let's audit key files:

# /etc/yp.conf should contain:
domain whaleshark server swordfish
# or alternatively:
ypserver swordfish

# /etc/sysconfig/network should have:
NISDOMAIN=whaleshark

Enable verbose logging to capture the binding attempt:

# Stop existing service:
$ service ypbind stop

# Run in debug mode:
$ ypbind -debug -verbose

# Sample debug output showing the issue:
YPBIND: setdomain(whaleshark) succeeded
YPBIND: broadcast: no NIS server found for domain whaleshark

Even with firewall disabled, residual rules or SELinux might interfere:

# Check SELinux status:
$ getenforce
Enforcing

# Temporarily test in permissive mode:
$ setenforce 0
$ service ypbind restart

# If it works, create proper SELinux policy:
$ grep ypbind /var/log/audit/audit.log | audit2allow -M myypbind
$ semodule -i myypbind.pp

When automatic discovery fails, force manual binding:

# Clear existing cache:
$ rm -f /var/yp/binding/*

# Manually specify server:
$ ypset swordfish

# Verify binding:
$ ypwhich
swordfish

1. Ensure rpcbind service is running
2. Verify ypbind starts after network is up
3. Check /etc/nsswitch.conf includes nis for relevant entries
4. Confirm time synchronization with server

# Sample nsswitch.conf entries:
passwd:     files nis
shadow:     files nis
group:      files nis

When setting up a new CentOS 6.2 client machine in an NIS authentication environment, the system fails to establish proper binding with the NIS server despite basic connectivity being confirmed.

Before diving deep, let's confirm the fundamentals:

# Verify network connectivity
ping swordfish
ping 192.168.1.100

# Check ypbind process status
ps -ef | grep ypbind

# Verify service status
service ypbind status

The key indicators of failure include:

• Missing RPC registration: rpcinfo -p shows no ypbind programs
• Empty binding directory: ls -la /var/yp/binding/ shows no files
• Error messages in logs: grep ypbind /var/log/messages reveals incomplete binding attempts

# Examine yp.conf
cat /etc/yp.conf
# Sample correct configuration:
domain whaleshark server swordfish

# Verify NIS domain setting
cat /etc/sysconfig/network
# Should contain:
NISDOMAIN=whaleshark

When basic checks pass but binding fails, try these diagnostics:

# Force domain setting
nisdomainname whaleshark

# Check portmapper status
rpcinfo -p localhost

# Test direct NIS server communication
ypcat -d whaleshark -h swordfish passwd

Based on years of NIS troubleshooting experience, these often get overlooked:

• Time synchronization: Run ntpdate if clocks differ significantly
• SELinux contexts: Check ls -Z /usr/sbin/ypbind
• Firewall remnants: Verify with iptables -L -n

After exhausting all standard checks, this sequence typically resolves stubborn NIS binding issues:

# Full cleanup and restart
service ypbind stop
rm -f /var/yp/binding/*
yum reinstall ypbind
service ypbind start