Did a restart of rpcinfo (or reboot) on the NIS master help ?
If not, can you re-run the tcpdumps on the client and NIS master, but this time use -i any i.e. on the NIS master:
tcpdump -i any -tt -s 0 -w /path/to/master.pcap port 111
and on the client:
tcpdump -i any -tt -s 0 -w /path/to/client.pcap port 111
Then on the client run:
ypbind -d
and upload to pcap files
There was no difference even after reboot or restart rpcbind on NIS master.
Also about the failure in ypbind on NIS master, after I setup the yp.conf file, the failure in “systemctl” was cleared. (For I know that, i.e. on the NIS master, I setup a ypbind as the NIS client on this server.) Then now, I can run “ypwhich -x” on this NIS master and get the passwd and other NIS information.
With the above response, can I assume that the problem is coming from the connection between the NIS master server and other client servers? Since, the ypbind on the local NIS master can get the passwd information from the local ypserv (i.e. not through the router - 10.6.126.1) by ypwhich.
If my above understanding was correct, one more possible firewall (inside the router) might be there. However, I could not log in to the router today. (The router is quite old.)
Is it possible?
Why would the traffic go through the router, if both machines are on the same subnet?
They should be talking directly with each other.
Yes, they are under 10.6.126.0/24 (which is managed by that router). So, do you mean that even there was a firewall inside the router, it could not influence the communication between two servers?
Router forwards traffic between different subnets. Router is a gateway between subnets. The firewall in the router affects the routed traffic.
If this is a many-in-one home router, then it probably has about four “LAN” ports for wired clients in one subnet. That part of the device is a switch. The routing (and filtering) is between switch and the “WAN” port.
The new pcap files didn’t show any more info - have you restarted rpcbind on the NIS master ?
If so, has it made any difference ?
If not, then maybe an strace of the rpcbind process on the NIS master may give more clues:
strace -tt -o /path/to/output -f -s 128 -p $(pidof /usr/bin/rpcbind)
and then run on the client:
ypbind -d
After restart the rpcbind, there is no difference. (Remark: 1956290 is the result of pidof /usr/bin/rpcbind)
sudo strace -tt -o ~/master_rpcbind.txt -f -s 128 -p 1956290
strace: Process 1956290 attached
vi ~/master_rpcbind.txt
1956290 15:25:15.736709 restart_syscall(<... resuming interrupted poll ...> <detached ...>
Strange you don’t get any strace output ?
You could try something like this on the NIS master:
systemctl stop rpcbind.socket
strace -tt -o ~/master_rpcbind.txt -f -s 128 /usr/bin/rpcbind -w -d -f
Then run on the client:
systemctl stop ypbind
ypbind -d
You will need to restart rpcbind on the NIS master after doing the above:
systemctl restart rpcbind.socket
Yes.
And the attached file is the result of the above command
strace -tt -o ~/master_rpcbind.txt -f -s 128 /usr/bin/rpcbind -w -d -f
I can’t see any sign of requests from 10.6.126.25 in that strace - so it looks like the UDP requests are not getting as far as the rpcbind process ?
Is it just this client that is having problems - does NIS work OK on other clients ?
No, I set another NIS client on another machine (Ubuntu 20). But it showed the following error message:
YPBINDPROC_DOMAIN: Domain not bound
YPBINDPROC_DOMAIN: Domain not bound
While it could be set to use another NIS server.
I suspect your Ubuntu 20 client is also failing to ypbind for the same reason as your CentOS 7 client
There appears to be something wrong with your NIS master and rpcbind - if you haven’t already, I suggest you reboot the NIS master and see if that makes a difference ?
No, it still could not work after reboot the NIS master server.
Do you think whether it is related to the ypserv service on the NIS master? Would it help if I reinstall the ypserv (and related packages)?
Do you mind if I make a comment here ?
You appear to have been trying to get NIS to work for the last three weeks and are seemingly no nearer than when you started. NIS is dead and has been removed from Rocky Linux 9. I take it you require the uidNumber & gidNumbers that NIS can supply, A Samba AD DC, or an LDAP server, or freeipa can supply these. You could have set up any of those and gone on a fortnights holiday by now 
Thanks, hortimech. Sorry that I may not be very familiar with the samilar services. NIS is the one we already used. As jlehtone suggested in the above post, there may be some better choices other than NIS. I just see whether there is any way to quickly fix and recover the NIS service. Then, it may involve less change to me. But I understood that using other tools may finally be my best solution for the existing issue.
How do you get the IDs from NIS, via nss or ldap, or something else ?
I don’t think your issue is related to the ypserv install - clients don’t get as far as talking to ypserv - they can’t talk to rpcbind on the server over UDP
As to what the actual problem is, I have now exhausted all my suggestions …
I understood. It is too strange. Anyway, thanks everyone. I also learnt much from all of you.
I am using the default NIS master in Rocky 8. And I have not set LDAP. So, I think it should be nss.
Okay, so I think what you are saying is that if you run ‘getent passwd $USER’ you get something like this returned:
getent passwd fred
fred:*:11104:10513:Fred Bloggs:/home/fred:/bin/bash
The first number is the user ID and the second is his group ID
If that is the case, then it should be pretty easy to setup a Samba AD DC to replace your NIS server. You just need a list of your users (with their IDs & group membership) and a list of your groups (with the groups ID), with that and a bit of scripting, you should be good to go.
That is, if you go down the AD DC route, I cannot help you with freeipa (I do not use it), or ldap (Samba doesn’t recommend using it any more).