Michael Schwendt wrote:
On the NFS Server.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 25 Apr 2003 18:55:34 -0400, Joseph Tate wrote:
I've got a RHL 9 install with all updates applied on a Dell Poweredge 2650 (Dual Xeon 2.0Ghz). I've got a couple of NFS mount points set up:
/nfs/redhat 10.2.2.0/255.255.255.240(async)
/nfs/home 10.2.2.0/255.255.255.240(rw,async,no_root_squash)
The server has dual BroadCom NetXtreme Gigabit Ethernet Adapters. It seems to like the tg3 driver module better than the bcm5700 drivers. eth0 is configured as a static IP as 10.2.2.2. Eth1 is currently set up using DHCP. I set up iptables using lokkit so that eth0 was trusted. /etc/sysconfig/iptables is included below:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Lokkit-0-50-INPUT - [0:0]
-A INPUT -j RH-Lokkit-0-50-INPUT
-A FORWARD -j RH-Lokkit-0-50-INPUT
-A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT
-A RH-Lokkit-0-50-INPUT -i eth0 -j ACCEPT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 0:1023 --syn -j REJECT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 2049 --syn -j REJECT
-A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 0:1023 -j REJECT
-A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 2049 -j REJECT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 7100 --syn -j REJECT
COMMIT
The NFS clients are RHL 7.3 with all updates applied and have 10.2.2.x static IPs on eth0 (identical hardware). They're running ipchains, but also have eth0 trusted. Their fstab entries look like:
cheetah-int:/nfs/home /home nfs defaults 0 0
cheetah-int:/nfs/redhat /redhat nfs defaults 0 0
cheetah-int is resolvable via /etc/hosts as:
10.2.2.2 cheetah-int
I've made sure that statd and portmapper are running on both systems.
When I boot the client servers, I get the following message during the mounting remote filesystems stage:
mount: RPC: Port mapper failure - RPC: Unable to receive
I receive it twice actually, once for each mount point. Nothing appears in /var/log/messages on the server.
Here's the kicker. After the server has finished booting, mount -a will usually succeed. No modification needed. Also, if I run "/sbin/service iptables stop" on the server, it will successfully mount the NFS directories during bootup. Sometimes mount -a will still fail, with the same message I receive at boot, continuously, but restarting ipchains or portmap will "fix" it so that mount -a succeeds.
I really need these file systems to be mounted at boot time. Eth1 will be connected to an external network, and therefore must have iptables protecting it. Any suggestions?
Having noticed your iptables bug report (bugzilla #90064), what
makes you think iptables is to blame? Can you give some details with
regard to your routing table (netstat -nr) and NIC config (ifconfig
- -a) for both server and a test-client and your attempts on debugging
whether iptables or ipchains (on the clients) is the cause of it?
[root@xxxxxxx root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.2.2.0 0.0.0.0 255.255.255.240 U 0 0 0 eth0
192.168.168.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.168.1 0.0.0.0 UG 0 0 0 eth1
[root@xxxxxxx root]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:06:5B:F8:16:E9
inet addr:10.2.2.2 Bcast:10.2.2.15 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:419379 errors:0 dropped:0 overruns:0 frame:0
TX packets:18812 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:49260701 (46.9 Mb) TX bytes:6243978 (5.9 Mb)
Interrupt:28
eth1 Link encap:Ethernet HWaddr 00:06:5B:F8:16:EA
inet addr:192.168.168.19 Bcast:192.168.168.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:425818 errors:0 dropped:0 overruns:0 frame:0
TX packets:16814 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:69444226 (66.2 Mb) TX bytes:1364159 (1.3 Mb)
Interrupt:29
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8387 errors:0 dropped:0 overruns:0 frame:0
TX packets:8387 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:942330 (920.2 Kb) TX bytes:942330 (920.2 Kb)On the 7.3 Clients:
[root@xxxxx root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.2.2.0 0.0.0.0 255.255.255.240 U 40 0 0 eth0
192.168.168.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 192.168.168.1 0.0.0.0 UG 40 0 0 eth1
[root@xxxxx root]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:06:5B:F8:0B:1C
inet addr:10.2.2.3 Bcast:10.2.2.15 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:409604 errors:0 dropped:0 overruns:0 frame:0
TX packets:10566 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:50459876 (48.1 Mb) TX bytes:1109856 (1.0 Mb)
Interrupt:28
eth1 Link encap:Ethernet HWaddr 00:06:5B:F8:0B:1D
inet addr:192.168.168.18 Bcast:192.168.168.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:400370 errors:0 dropped:0 overruns:0 frame:0
TX packets:1735 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:47304237 (45.1 Mb) TX bytes:154877 (151.2 Kb)
Interrupt:29
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3612 errors:0 dropped:0 overruns:0 frame:0
TX packets:3612 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:345662 (337.5 Kb) TX bytes:345662 (337.5 Kb)If I run chkconfig ipchains off on the 7.3 client machines, then reboot, the same errors occur.
Yes, tons of stuff.For instance, on the NFS server, if you add a log rule right after the "trust eth0" rule,
-A RH-Lokkit-0-50-INPUT -i eth0 -j ACCEPT -A RH-Lokkit-0-50-INPUT -i eth0 -j LOG --log-level alert
do you see anything in the logs upon booting an NFS client?
Or what makes you assume iptables blocks anything from eth0?I'm not assuming that, I'm just assuming that it's iptables that ultimately causes the problem because removing it from the equation fixes the boot error. If it is an iptables configuration issue that ultimately causes the problem, then lokkit needs to be fixed to give proper output. A trusted eth0 is a trusted eth0. No blocking should occur.
The NFS client machine. When it finishes booting, and I log in as root, I can usually run mount -a to mount the NFS points from the server without running any additional commands. Sometimes not though. Seems to be flaky.After the server has finished booting, mount -a will usually succeed.
Since you refer to "server" and "client servers", what server is referred to here?
Changing the REJECT iptables entries above to:
-A RH-Lokkit-0-50-INPUT -s ! 10.2.2.0/28 -p tcp -m tcp --dport 0:1023 --syn -j REJECT -A RH-Lokkit-0-50-INPUT -s ! 10.2.2.0/28 -p tcp -m tcp --dport 2049 --syn -j REJECT -A RH-Lokkit-0-50-INPUT -s ! 10.2.2.0/28 -p udp -m udp --dport 0:1023 -j REJECT -A RH-Lokkit-0-50-INPUT -s ! 10.2.2.0/28 -p udp -m udp --dport 2049 -j REJECT Allows the clients to boot properly. Therefore the eth0 line is not being evaluated correctly, or is not in the right position in the RH-Lokkit-0-50-INPUT chain. iptables -L would indicate that it's the former rather than the latter.
Yes.Also, if I run "/sbin/service iptables stop" on the server,
it will successfully mount the NFS directories during bootup.
it = client?
