The next thing to try is to run strace on the ypbind process - i.e. something like:
strace -f -o /path/to/output -s 128 ypbind -d
(Ctrl-C the strace after you get YPBIND_FAIL_VAL) - and upload the output file here
Sorry, may i ask how to upload non picture files in here?
Sorry - no idea …
I guess you might be able to upload the output to some free upload site ?
I run the following command on the client:
strace -f -o strace_result -s 128 ypbind -d
The result is attached.
I’m not an expert on rpc calls, but I think it looks like the NIS client is having problems talking UDP to port 111 on the NIS server ?
I don’t see any connections to port 944 on 10.6.126.20 - which I’m guessing is because connections to port 111/udp are not receiving any answer, so it never finds out which port to use for ypserv ?
e.g. running something like:
grep -A 1 'sendto.*10.6.126.20' strace_result
gives:
86567 sendto(6, "ap\206#\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\206\244\0\0\0\2\0\0\0\21\0\0\0\0", 56, 0, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("10.6.126.20")}, 16) = 56
86567 poll([{fd=6, events=POLLIN}], 1, 1000) = 0 (Timeout)
--
86575 sendto(8, "\0224N\332\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\206\244\0\0\0\2\0\0\0\21\0\0\0\0", 56, 0, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("10.6.126.20")}, 16) = 56
86575 poll([{fd=8, events=POLLIN}], 1, 1000) = 0 (Timeout)
--
86565 sendto(9, "P\36\\\276\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\206\244\0\0\0\2\0\0\0\21\0\0\0\0", 56, 0, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("10.6.126.20")}, 16) = 56
86565 poll([{fd=9, events=POLLIN}], 1, 1000) = 0 (Timeout)
...
i.e. the poll() is timing out
When I run a similar strace on a NIS client, I don’t get a timeout with poll() and followed by a recvfrom() - which I don’t see in your strace
However, I can reproduce your issue (similar strace output) by dropping 111/udp requests from a client on my NIS server
Do you have anything dropping port 111/udp requests on the NIS master ?
FirewallD defines service rpc-bind as ports: 111/tcp 111/udp.
The NIS – or port 944/tcp – are not listed on /etc/services.
Presumably, the NIS server uses next available port and informs RPC about that.
The clients do then ask from RPC that listens “well known” port 111, where the NIS is.
The NFS used to be similar before NFSv4; the clients had to find many NFS-services via RPC.
That was a nightmare for through-firewalls use.
I ran the folloing command on NIS master. But I am not sure whether it was normal.
/home/localadmin $sudo netstat -tuln | grep :111
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp6 0 0 :::111 :::* LISTEN
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp6 0 0 :::111 :::*
And I confirmed that the firewalld on NIS master was inactive.
First, the netstat has been superceded by ss. The latter can do a bit more. Presumably.
Second, the -tuln should be possible as regular user. It is the process names (option ‘p’) that require admin privileges.
Hence, sudo ss -tulnp | grep :111
You have something on the NIS master that does listen on port 111 both TCP and UDP, both IPv4 and IPv6. That is most likely the rpcpind (although it might look like systemd on el9).
The output of netstat/ss does not tell whether the firewall of the NIS master allows anything to reach these ports.
Is there any router/firewall appliance between the client and NIS master ?
You can check to see if any UDP traffic is getting to the master by running on the master something like:
tcpdump -tt -s 0 -w /path/to/master.pcap port 111 and host icetserver01
and on the client:
tcpdump -tt -s 0 -w /path/to/client.pcap port 111 and host 10.6.126.20
Then on the client run:
ypbind -d
and see if any 111/udp port traffic reaches the master from the client ?
I ran the following command on NIS master.
/home/localadmin $sudo ss -tulnp | grep :111
udp UNCONN 0 0 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=174130,fd=5),("systemd",pid=1,fd=307))
udp UNCONN 0 0 [::]:111 [::]:* users:(("rpcbind",pid=174130,fd=7),("systemd",pid=1,fd=338))
tcp LISTEN 0 128 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=174130,fd=4),("systemd",pid=1,fd=306))
tcp LISTEN 0 128 [::]:111 [::]:* users:(("rpcbind",pid=174130,fd=6),("systemd",pid=1,fd=318))
/home/localadmin $
When I ran tcpdump on both master and client, and ran “ypbind -d”, Only NIS master received the packets.
/home/localadmin 89 > sudo tcpdump -tt -s 0 -w ~/master.pcap port 111 and host 10.6.126.25
[sudo] password for localadmin:
dropped privs to tcpdump
tcpdump: listening on eno12399np0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C19 packets captured
20 packets received by filter
0 packets dropped by kernel
/home/localadmin 90 > ll ~/master.pcap
-rw-r--r--. 1 tcpdump tcpdump 2190 Oct 29 00:54 /home/localadmin/master.pcap
/home/localadmin 91 > tcpdump -r ~/master.pcap
reading from file /home/localadmin/master.pcap, link-type EN10MB (Ethernet)
00:54:24.219449 IP icetserver01.astri.org.sco-dtmgr > padnfs03.sunrpc: UDP, length 56
00:54:25.242246 IP icetserver01.astri.org.asia > padnfs03.sunrpc: UDP, length 56
00:54:27.399421 IP icetserver01.astri.org.passgo-tivoli > padnfs03.sunrpc: UDP, length 56
00:54:28.403931 IP icetserver01.astri.org.qmqp > padnfs03.sunrpc: UDP, length 56
00:54:29.408160 IP icetserver01.astri.org.3com-amp3 > padnfs03.sunrpc: UDP, length 56
00:54:30.414585 IP icetserver01.astri.org.rda > padnfs03.sunrpc: UDP, length 56
00:54:31.420023 IP icetserver01.astri.org.ipp > padnfs03.sunrpc: UDP, length 56
00:54:32.426110 IP icetserver01.astri.org.bmpp > padnfs03.sunrpc: UDP, length 56
00:54:33.432965 IP icetserver01.astri.org.servstat > padnfs03.sunrpc: UDP, length 56
00:54:34.437250 IP icetserver01.astri.org.ginad > padnfs03.sunrpc: UDP, length 56
00:54:35.442670 IP icetserver01.astri.org.rlzdbase > padnfs03.sunrpc: UDP, length 56
00:54:36.448523 IP icetserver01.astri.org.ldaps > padnfs03.sunrpc: UDP, length 56
00:54:37.453806 IP icetserver01.astri.org.lanserver > padnfs03.sunrpc: UDP, length 56
00:54:38.459248 IP icetserver01.astri.org.mcns-sec > padnfs03.sunrpc: UDP, length 56
00:54:40.466572 IP icetserver01.astri.org.msdp > padnfs03.sunrpc: UDP, length 56
00:54:41.471876 IP icetserver01.astri.org.entrust-sps > padnfs03.sunrpc: UDP, length 56
00:54:42.476961 IP icetserver01.astri.org.repcmd > padnfs03.sunrpc: UDP, length 56
00:54:43.482637 IP icetserver01.astri.org.esro-emsdp > padnfs03.sunrpc: UDP, length 56
00:54:44.487024 IP icetserver01.astri.org.sanity > padnfs03.sunrpc: UDP, length 56
/home/localadmin 92 >
But, there is no packet collected by client.
/localhome/localadmin 37 > sudo tcpdump -tt -s 0 -w ~/client.pcap port 111 and host 10.6.126.20
[sudo] password for localadmin:
tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C0 packets captured
0 packets received by filter
0 packets dropped by kernel
/localhome/localadmin 38 > ll ~/client.cap
ls: cannot access /localhome/localadmin/client.cap: No such file or directory
/localhome/localadmin 39 >
So, can I say that there is some problem for NIS master to reply the client with port 111?
Looks like you didn’t give the NIC interface device (with the -i option to tcpdump) on the NIS client ?
Make sure you use the ‘correct’ NIC device with tcpdump on the client and NIS master i.e. the NICs used when the NIS master and clients talk to each other
The client should have seen the packets that it did send out, since you saw those packets incoming to the server. Something wrong in the way you do listen, like @james-p said.
Possibilities:
- Firewall on NIS master did drop the incoming packets. (The tcpdump listens outside of firewall.)
- The portmapper did receive packets, but created no reply. (This seems highly unlikely.)
- The replies were not captured (did not match criteria) by the tcpdump
Are both machines on the same subnet (10.6.126.0/24 or something)?
Does either machine have multiple IP addresses? (Routing could be odd too.)
Sorry for missing that.
I rerun them again. Now, they had the same records. But still NIS master didn’t respond to the client.
On client:
/localhome/localadmin 52 > sudo tcpdump -i em4 -tt -s 0 -w ~/client.pcap port 111 and host 10.6.126.20
tcpdump: listening on em4, link-type EN10MB (Ethernet), capture size 262144 bytes
^C15 packets captured
15 packets received by filter
0 packets dropped by kernel
/localhome/localadmin 53 > tcpdump -r client.pcap
reading from file client.pcap, link-type EN10MB (Ethernet)
13:34:58.342442 IP icetserver01.astri.org.surf > padnfs03.sunrpc: UDP, length 56
13:34:59.365178 IP icetserver01.astri.org.1019 > padnfs03.sunrpc: UDP, length 56
13:35:04.214490 IP icetserver01.astri.org.1020 > padnfs03.sunrpc: UDP, length 56
13:35:05.220385 IP icetserver01.astri.org.exp1 > padnfs03.sunrpc: UDP, length 56
13:35:06.225994 IP icetserver01.astri.org.exp2 > padnfs03.sunrpc: UDP, length 56
13:35:07.232846 IP icetserver01.astri.org.1023 > padnfs03.sunrpc: UDP, length 56
13:35:08.237523 IP icetserver01.astri.org.ipcserver > padnfs03.sunrpc: UDP, length 56
13:35:09.241920 IP icetserver01.astri.org.syslog-conn > padnfs03.sunrpc: UDP, length 56
13:35:10.248411 IP icetserver01.astri.org.xmlrpc-beep > padnfs03.sunrpc: UDP, length 56
13:35:11.254024 IP icetserver01.astri.org.idxp > padnfs03.sunrpc: UDP, length 56
13:35:12.259737 IP icetserver01.astri.org.tunnel > padnfs03.sunrpc: UDP, length 56
13:35:13.267002 IP icetserver01.astri.org.soap-beep > padnfs03.sunrpc: UDP, length 56
13:35:14.271206 IP icetserver01.astri.org.urm > padnfs03.sunrpc: UDP, length 56
13:35:15.276942 IP icetserver01.astri.org.nqs > padnfs03.sunrpc: UDP, length 56
13:35:17.283727 IP icetserver01.astri.org.sift-uft > padnfs03.sunrpc: UDP, length 56
On NIS master:
/home/localadmin 125 > sudo tcpdump -i eno12399np0 -tt -s 0 -w ~/master.pcap port 111 and host 10.6.126.25
dropped privs to tcpdump
tcpdump: listening on eno12399np0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C15 packets captured
24 packets received by filter
0 packets dropped by kernel
/home/localadmin 126 > tcpdump -r master.pcap
reading from file master.pcap, link-type EN10MB (Ethernet)
13:24:04.661706 IP icetserver01.astri.org.surf > padnfs03.sunrpc: UDP, length 56
13:24:05.684455 IP icetserver01.astri.org.1019 > padnfs03.sunrpc: UDP, length 56
13:24:10.533841 IP icetserver01.astri.org.1020 > padnfs03.sunrpc: UDP, length 56
13:24:11.539677 IP icetserver01.astri.org.exp1 > padnfs03.sunrpc: UDP, length 56
13:24:12.545353 IP icetserver01.astri.org.exp2 > padnfs03.sunrpc: UDP, length 56
13:24:13.552230 IP icetserver01.astri.org.1023 > padnfs03.sunrpc: UDP, length 56
13:24:14.556922 IP icetserver01.astri.org.ipcserver > padnfs03.sunrpc: UDP, length 56
13:24:15.561325 IP icetserver01.astri.org.syslog-conn > padnfs03.sunrpc: UDP, length 56
13:24:16.567830 IP icetserver01.astri.org.xmlrpc-beep > padnfs03.sunrpc: UDP, length 56
13:24:17.573453 IP icetserver01.astri.org.idxp > padnfs03.sunrpc: UDP, length 56
13:24:18.579183 IP icetserver01.astri.org.tunnel > padnfs03.sunrpc: UDP, length 56
13:24:19.586451 IP icetserver01.astri.org.soap-beep > padnfs03.sunrpc: UDP, length 56
13:24:20.590614 IP icetserver01.astri.org.urm > padnfs03.sunrpc: UDP, length 56
13:24:21.596430 IP icetserver01.astri.org.nqs > padnfs03.sunrpc: UDP, length 56
13:24:23.603236 IP icetserver01.astri.org.sift-uft > padnfs03.sunrpc: UDP, length 56
Yes, both master and client are in 10.6.126.0/24. Both machines have only 1 IP address. And both machines inactivated their firewalld. I don’t know why the master didn’t reply it.
Also, in the original setting on NIS master, 945 is the port assigned for ypxfrd. But when I ran rpcinfo on the master, it didn’t show the port for ypxfrd. Is it normal? Also, how can I check whether the portmapper and ypserv are normal?
/home/localadmin 173 > rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 20048 mountd
100005 1 tcp 20048 mountd
100005 2 udp 20048 mountd
100005 2 tcp 20048 mountd
100005 3 udp 20048 mountd
100005 3 tcp 20048 mountd
100024 1 udp 38813 status
100024 1 tcp 45897 status
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
100021 1 udp 33481 nlockmgr
100021 3 udp 33481 nlockmgr
100021 4 udp 33481 nlockmgr
100021 1 tcp 34489 nlockmgr
100021 3 tcp 34489 nlockmgr
100021 4 tcp 34489 nlockmgr
100009 1 udp 950 yppasswdd
100009 1 tcp 950 yppasswdd
600100069 1 udp 946 fypxfrd
600100069 1 tcp 946 fypxfrd
100004 2 udp 944 ypserv
100004 1 udp 944 ypserv
100004 2 tcp 944 ypserv
100004 1 tcp 944 ypserv
Can you upload both pcap files?
In other words, you get in each something similar to:
$ ip ro
default via 10.6.126.1 dev eno1 proto dhcp src 10.6.126.55 metric 100
10.6.126.0/24 dev eno1 proto kernel scope link src 10.6.126.55 metric 100
$ sudo systemctl status
Starts with “State”. If it is “degraded”, then look at:
$ sudo systemctl
for what is in state “failed”.
You can also look at the logs for each service. For example:
$ sudo juornalctl -u ypxfrd.service
and look at what processes are listening, like you did before:
$ sudo ss -tulpn
$ sudo ss -tulpn | grep :945
$ sudo ss -tulpn | grep -E ":945|:111"
Furthermore, you can check the actual firewall rules with:
$ sudo nft list ruleset
The output should be (effectively) empty, if the firewall is really disabled.
Strange - rpcbind appears not to be responding to UDP requests
What happens if you restart rpcbind on the NIS master:
systemctl restart rpcbind
(or even restart the NIS master host) ?
I don’t think it is important, but the two hosts appear to have a time difference of about 10 minutes ?
After running ip ro, it is similar, but I am using static. And beside the main interface, both master and client have virbr0 which are in 192.168.122.0/24.
When I ran “sudo systemctl”, it was “degraded” and showed the following two items “failed”.
dnf-makecache.service loaded failed failed dnf makecache
ypbind.service loaded failed failed NIS/YP (Network Information Service) >
When I journal them:
sudo journalctl -u dnf-makecache.service
– Logs begin at Wed 2024-10-16 16:37:52 HKT, end at Tue 2024-10-29 20:56:51 HKT. –
Oct 16 17:12:53 padnfs03 systemd[1]: Starting dnf makecache…
Oct 16 17:12:59 padnfs03 dnf[21071]: Rocky Linux 8 - AppStream 0.0 B/s | 0 B 00:02
Oct 16 17:12:59 padnfs03 dnf[21071]: Errors during downloading metadata for repository ‘appstream’:
Oct 16 17:12:59 padnfs03 dnf[21071]: - Curl error (52): Server returned nothing (no headers, no data) for https://rocky-linux-asia-east2.production.gcp.mirrors.ct>
Oct 16 17:12:59 padnfs03 dnf[21071]: Error: Failed to download metadata for repo ‘appstream’: Cannot download repomd.xml: Curl error (52): Server returned nothing (>
Oct 16 17:12:59 padnfs03 systemd[1]: dnf-makecache.service: Main process exited, code=exited, status=1/FAILURE
Oct 16 17:12:59 padnfs03 systemd[1]: dnf-makecache.service: Failed with result ‘exit-code’.
Oct 16 17:12:59 padnfs03 systemd[1]: Failed to start dnf makecache.
Oct 16 19:00:53 padnfs03 systemd[1]: Starting dnf makecache…
Oct 16 19:00:53 padnfs03 dnf[36949]: Metadata cache refreshed recently.
Oct 16 19:00:53 padnfs03 systemd[1]: dnf-makecache.service: Succeeded.
Oct 16 19:00:53 padnfs03 systemd[1]: Started dnf makecache.
Oct 16 20:34:53 padnfs03 systemd[1]: Starting dnf makecache…
Oct 16 20:34:54 padnfs03 dnf[49801]: Rocky Linux 8 - AppStream 0.0 B/s | 0 B 00:01
Oct 16 20:34:54 padnfs03 dnf[49801]: Errors during downloading metadata for repository ‘appstream’:
Oct 16 20:34:54 padnfs03 dnf[49801]: - Curl error (52): Server returned nothing (no headers, no data) for https://rocky-linux-asia-east2.production.gcp.mirrors.ct>
Oct 16 20:34:54 padnfs03 dnf[49801]: Error: Failed to download metadata for repo ‘appstream’: Cannot download repomd.xml: Curl error (52): Server returned nothing (>
Oct 16 20:34:54 padnfs03 systemd[1]: dnf-makecache.service: Main process exited, code=exited, status=1/FAILURE
Oct 16 20:34:54 padnfs03 systemd[1]: dnf-makecache.service: Failed with result ‘exit-code’.
Oct 16 20:34:54 padnfs03 systemd[1]: Failed to start dnf makecache.
Oct 16 22:20:53 padnfs03 systemd[1]: Starting dnf makecache…
Oct 16 22:20:53 padnfs03 dnf[64004]: Metadata cache refreshed recently.
Oct 16 22:20:53 padnfs03 systemd[1]: dnf-makecache.service: Succeeded.
Oct 16 22:20:53 padnfs03 systemd[1]: Started dnf makecache.sudo journalctl -u ypbind.service
– Logs begin at Wed 2024-10-16 16:37:52 HKT, end at Tue 2024-10-29 21:09:44 HKT. –
Oct 19 15:50:51 padnfs03 systemd[1]: Starting NIS/YP (Network Information Service) Clients to NIS Domain Binder…
Oct 19 15:50:51 padnfs03 ypbind[638613]: No NIS server and no -broadcast option specified.
Oct 19 15:50:51 padnfs03 ypbind[638613]: Add a NIS server to the /etc/yp.conf configuration file,
Oct 19 15:50:51 padnfs03 ypbind[638613]: or start ypbind with the -broadcast option.
Oct 19 15:50:51 padnfs03 systemd[1]: ypbind.service: Main process exited, code=exited, status=1/FAILURE
Oct 19 15:50:51 padnfs03 systemd[1]: ypbind.service: Failed with result ‘exit-code’.
Oct 19 15:50:51 padnfs03 systemd[1]: Failed to start NIS/YP (Network Information Service) Clients to NIS Domain Binder.
It seems that beside ypbind, dnf-makecache is also abnormal.
/home/localadmin 184 > sudo ss -tulpn | grep -E “:945|:111”
udp UNCONN 0 0 0.0.0.0:111 0.0.0.0:* users:((“rpcbind”,pid=174130,fd=5),(“systemd”,pid=1,fd=307))
udp UNCONN 0 0 [::]:111 [::]:* users:((“rpcbind”,pid=174130,fd=7),(“systemd”,pid=1,fd=338))
udp UNCONN 0 0 :945 : users:((“ypserv”,pid=40593,fd=8))
tcp LISTEN 0 128 0.0.0.0:111 0.0.0.0: users:((“rpcbind”,pid=174130,fd=4),(“systemd”,pid=1,fd=306))
tcp LISTEN 0 128 [::]:111 [::]:* users:((“rpcbind”,pid=174130,fd=6),(“systemd”,pid=1,fd=318))
tcp LISTEN 0 128 *:945 : users:((“ypserv”,pid=40593,fd=9))
Check firewall by nft. But it seems no special.
/home/localadmin 185 > sudo nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}chain FORWARD {
type filter hook forward priority filter; policy accept;
}chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}chain FORWARD {
type filter hook forward priority filter; policy accept;
}chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table bridge filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}chain FORWARD {
type filter hook forward priority filter; policy accept;
}chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table ip security {
chain INPUT {
type filter hook input priority 150; policy accept;
}chain FORWARD {
type filter hook forward priority 150; policy accept;
}chain OUTPUT {
type filter hook output priority 150; policy accept;
}
}
table ip raw {
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
}chain OUTPUT {
type filter hook output priority raw; policy accept;
}
}
table ip mangle {
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
}chain INPUT {
type filter hook input priority mangle; policy accept;
}chain FORWARD {
type filter hook forward priority mangle; policy accept;
}chain OUTPUT {
type route hook output priority mangle; policy accept;
}chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
}
}
table ip nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
}chain INPUT {
type nat hook input priority 100; policy accept;
}chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
}chain OUTPUT {
type nat hook output priority -100; policy accept;
}
}
table ip6 security {
chain INPUT {
type filter hook input priority 150; policy accept;
}chain FORWARD {
type filter hook forward priority 150; policy accept;
}chain OUTPUT {
type filter hook output priority 150; policy accept;
}
}
table ip6 raw {
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
}chain OUTPUT {
type filter hook output priority raw; policy accept;
}
}
table ip6 mangle {
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
}chain INPUT {
type filter hook input priority mangle; policy accept;
}chain FORWARD {
type filter hook forward priority mangle; policy accept;
}chain OUTPUT {
type route hook output priority mangle; policy accept;
}chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
}
}
table ip6 nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
}chain INPUT {
type nat hook input priority 100; policy accept;
}chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
}chain OUTPUT {
type nat hook output priority -100; policy accept;
}
}
table bridge nat {
chain PREROUTING {
type filter hook prerouting priority dstnat; policy accept;
}chain OUTPUT {
type filter hook output priority out; policy accept;
}chain POSTROUTING {
type filter hook postrouting priority srcnat; policy accept;
}
}
When I have restarted rpcbind and ypserv, but it didn’t work.
Indeed. No rules.
The nf_tables has 0 chains by default. The netfilter had builtin chains.
If FirewallD is started (on el8) or tool iptables is used to list rules, then the equivalents of netfilter builtin chains are created. Those empty chains is what your server has.
That had happened already Oct 16. Probably an error was on that mirror server. Not relevant to your NIS issue.
You ss output shows that “ypserv” does listen on port 945. Is that how the “ypxfrd” works?
The NIS Client on the server has failed to start Oct 19 15:50:
The log message states the reason: config error. If you fix that, then you will see whether the ypbind on the machine can talk to the NIS server that is in that same host. If it cannot, then there is clearly an issue within the config of the NIS server.