![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
root@hostname:~> /etc/init.d/iptables stop
root@hostname:~> /etc/init.d/ip6tables stoproot@hostname:~> iptables --list INPUTYeah. Now you're into more investigating then. The following may still be more basic than what you're looking for though.
root@hostname:~> chkconfig |grep iptables
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:offroot@hostname:~> iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination-bash-4.1# chkconfig | grep iptables
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:offYeah. Now you're into more investigating then. The following may still be more basic than what you're looking for though.
First stop would be to run chkconfig and make sure the saved behavior is indeed correct for your run level. Sometimes you can get tripped up on runlevel if you're usually SSH'd into some box and don't have the obviousness of a GUI staring at you.
3 should be off if run level 3, 5 should be off if run level 5, etc..
Code:root@hostname:~> chkconfig |grep iptables iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
After a boot, check if you're actually getting some IPTables rules set.
If you have any entries showing, then you know it's in your init scripts... somewhere.Code:root@hostname:~> iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
I'd take a look at /etc/rc.local and see if something was added there. Then review your scripts in /etc/init.d/. It'd be worth checking over /var/log/boot.log to see if you can tell where it's firing.
If it's empty (as above), and your cluster still does not communicate, I'd give SELinux a cursory check with the 'sestatus' command. When it blocks processes, they can error out in ways that don't really lead you to the cause.
[B]-bash-4.1# sestatus
[/B]SELinux status: disabled[B]-bash-4.1# cat /etc/selinux/config
[/B]
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted[B]-bash-4.1# service iptables status
[/B]Table: filter
Chain INPUT (policy ACCEPT)
num target prot opt source destination
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination[B]-bash-4.1# service iptables stop
[/B]iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
-bash-4.1# service iptables status
iptables: Firewall is not running.-bash-4.1# chkconfig | grep iptables
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:offyes, Selinux stays disabled. Iptables is active after a reboot, I know because nodes begin to have communication issues
and it shows it as active until I kill it. Disabling the firewall works properly on my other RHEL systems, which is weird.
iptables -P INPUT ACCEPT
iptables -F INPUT
service iptables save