Bug 1053639
| Summary: | Following deployment instructions for OSE2.0 node seems to cause iptables issues with openshift-iptables-port-proxy service start | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Ian Lawson <ian.lawson> |
| Component: | Documentation | Assignee: | Julie <juwu> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ecs-bugs |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 2.0.0 | CC: | alyoung, bleanhar, chris, jokerman, libra-onpremise-devel, mmasters, mmccomas |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: |
Build Name: 20635, Deployment Guide-2-1.0
Build Date: 14-01-2014 10:00:13
Topic ID: 20601-567325 [Latest]
|
|
| Last Closed: | 2014-01-29 00:21:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ian Lawson
2014-01-15 14:46:40 UTC
Can you provide the contents of the problematic /etc/sysconfig/iptables? I've seen that error if the iptables service is not running when openshift-iptables-port-proxy starts up. Here's what is in there after the 'sed' commands: --------------------------------------------------------------- # Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :rhc-app-comm - [0:0] -A INPUT -j rhc-app-comm -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 8000 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT ------------------------------------------------------------- Looks fine to me - I *think* it may be something to do with the iptables-restore action and not the iptables conf at all? I've done a reboot of the node and the same error message appears - checked the iptables service is running beforehand. Odd. Can we check the output of iptables-save before you run `service openshift-iptables-port-proxy start` to see whether the system is indeed failing to load the configuration in /etc/sysconfig/iptables? Output of iptables-save: ----------------------------------------------------------------- [root@openshift2-node1 ~]# iptables-save # Generated by iptables-save v1.4.7 on Wed Jan 15 15:02:26 2014 *nat :PREROUTING ACCEPT [1:84] :POSTROUTING ACCEPT [20:1400] :OUTPUT ACCEPT [20:1400] COMMIT # Completed on Wed Jan 15 15:02:26 2014 # Generated by iptables-save v1.4.7 on Wed Jan 15 15:02:26 2014 *filter :INPUT ACCEPT [2254:173627] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1380:191463] COMMIT # Completed on Wed Jan 15 15:02:26 2014 ----------------------------------------------------------------- What does `chkconfig --list iptables` show? If you run `chkconfig iptables on` and reboot, does openshift-iptables-port-proxy then start properly? Maybe we just need to add `chkconfig iptables on` to the Deployment Guide. [root@openshift2-node1 ~]# chkconfig --list iptables iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off On reboot: [root@openshift2-node1 ~]# service iptables status Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination Chain POSTROUTING (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 rhc-app-comm all -- 0.0.0.0/0 0.0.0.0/0 2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 6 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:8000 9 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination Chain rhc-app-comm (1 references) num target prot opt source destination That looks better..... I think it was just a case of 'chkconfig iptables on' missing.... The `chkconfig --list iptables` command output that you provided shows that iptables was enabled; is that the output after running `chkconfig iptables on`? Or to ask what I really want to know, was `chkconfig --list iptables` showing that iptables was enabled even _before_ running `chkconfig iptables on`? I manually tried 'chkconfig iptables on' myself as fix between following the instructions and trying changes, so I *think* I must have manually set the iptables to start myself between reboots. The answer is that you need to do a 'chkconfig iptables on' before doing the iptables updates I guess. Can we please get some clarification and details as to what exactly we need to update or change in the docs? Thanks. Deployment guide, section 7.11: When it suggests to do 'chkconfig openshift-iptables-port-proxy on' you appear to need to ensure that iptables is active and enabled for restart before hand, i.e. chkconfig iptables on service iptables start Otherwise the port-proxy throws the error shown at the start of this bug. Hope that helps. (In reply to Ian Lawson from comment #15) > chkconfig iptables on > service iptables start When I do that, I get the following: iptables: Applying firewall rules: iptables-restore v1.4.7: Couldn't load target `rhc-app-comm':/lib64/xtables/libipt_rhc-app-comm.so: cannot open shared object file: No such file or directory Error occurred at line: 7 Try `iptables-restore -h' or 'iptables-restore --help' for more information. The file in question is, in fact, missing: -bash-4.1$ ls /lib64/xtables/libipt_rhc* ls: cannot access /lib64/xtables/libipt_rhc*: No such file or directory The file doesn't exist on my system. Furthermore, I can't identify which package was supposed to install it: -bash-4.1$ sudo yum provides "*libipt_rhc*" Loaded plugins: amazon-id, priorities, rhui-lb, security 13209 packages excluded due to repository priority protections jb-eap-6-for-rhel-6-server-rpms/filelists_db | 1.0 MB 00:00 jb-ews-2-for-rhel-6-server-rpms/filelists_db | 106 kB 00:00 rhel-6-server-cf-tools-1-rpms/filelists_db | 11 kB 00:00 rhel-6-server-ose-2.0-jbosseap-rpms/filelists_db | 3.3 kB 00:00 rhel-6-server-ose-2.0-node-rpms/filelists_db | 237 kB 00:00 rhel-6-server-rhev-agent-rpms/filelists_db | 7.2 kB 00:00 rhel-6-server-rpms/filelists_db | 14 MB 00:01 rhel-server-rhscl-6-rpms/filelists_db | 1.1 MB 00:00 rhui-REGION-client-config-server-6/filelists_db | 2.7 kB 00:00 rhui-REGION-rhel-server-releases/filelists_db | 14 MB 00:00 rhui-REGION-rhel-server-releases-optional/filelists_db | 4.5 MB 00:00 rhui-REGION-rhel-server-rh-common/filelists_db | 14 kB 00:00 rhui-REGION-rhel-server-rhscl/filelists_db | 1.1 MB 00:00 No Matches found (In reply to Chris Baker from comment #16) > (In reply to Ian Lawson from comment #15) > > chkconfig iptables on > > service iptables start > > When I do that, I get the following: > > iptables: Applying firewall rules: iptables-restore v1.4.7: Couldn't load > target `rhc-app-comm':/lib64/xtables/libipt_rhc-app-comm.so: cannot open > shared object file: No such file or directory > Error occurred at line: 7 > Try `iptables-restore -h' or 'iptables-restore --help' for more information. > Turns out, the sed commands were resulting in my /etc/sysconfig/iptables file containing: :OUTPUT ACCEPT [0:0] -A INPUT -j rhc-app-comm :rhc-app-comm - [0:0] instead of :OUTPUT ACCEPT [0:0] :rhc-app-comm - [0:0] -A INPUT -j rhc-app-comm When I switched the order of the rhc-app-comm lines, everything started up fine. I think the sed commands in our documentation for configuring the rhc-app-comm chain are wrong: It should be the following (to match our installation script): sed -i '/:OUTPUT ACCEPT \[.*\]/a :rhc-app-comm - [0:0]' /etc/sysconfig/iptables sed -i '/-A INPUT -i lo -j ACCEPT/a -A INPUT -j rhc-app-comm' /etc/sysconfig/iptables Looking at the current docs I can see how the problem in Comment #17 could happen. |