Hide Forgot
Description of problem: Can't connect their db server from shell(or rockmongo,phpmyadmin) after embedded mysql,phpmyadmin,mongodb,rockmongo into any type of application, it will return error messages "ERROR 2003 (HY000): Can't connect to MySQL server on '127.13.102.1' (113)", mongodb has also the same error messages.. Version-Release number of selected component (if applicable): rhc-0.87.8-1.el6_2.noarch How reproducible: Always Steps to Reproduce for mysql and mongodb: 1.Create any of application # rhc-create-app -a php31 -t php-5.3 -p xxx -l bzhao31 2. Embed mongodb or mysql #rhc-ctl-app -a php31 -p xxx -l bzhao31 -e add-mongodb-2.0 # rhc-ctl-app -a php31 -p xxx -e add-mysql-5.1 3. Embed rockmongo or phpmyadmin #rhc-ctl-app -a php31 -p xxx -l bzhao31 -e add-rockmongo-1.1 #rhc-ctl-app -a php31 -p xxx -e add-phpmyadmin-3.4 4. Access embeded mysql or mongodb server from shell(or by rockmongo and phpmyadmin) Actual results: Can't connect to mysql or mongodb server from shell(or by rockmongo and phpmyadmin) Expected results: The user should can access his mongodb or mysql from shell or database management tool,for example rockmongo and phpmyadmin Additional info: Observe their status after embedding db and database management tool. Mysql and mongodb has the same issue,but I just list the MYSQL and phpmyadmin's status. #rhc-ctl-app -a phptest2 -p xxx -e status-mysql-5.1 Contacting https://stg.openshift.redhat.com Response from server: DEBUG: Exit Code: 0 broker_c: namespacerhloginsshapp_uuiddebugaltercartridgecart_typeactionapp_nameapi api_c: placeholder API version: 1.1.2 RESULT: MySQL is running # rhc-ctl-app -a phptest2 -p xxx -e status-phpmyadmin-3.4 Contacting https://stg.openshift.redhat.com Response from server: DEBUG: Exit Code: 0 api_c: placeholder broker_c: namespacerhloginsshapp_uuiddebugaltercartridgecart_typeactionapp_nameapi API version: 1.1.2 RESULT: phpMyAdmin is either stopped or inaccessible
Reassigning to tdawson.
An updated iptables was causing this problem. We have reverted back to the original iptables. Everything appears to be back to normal now.
Was this due to the output of "rhc-iptables -s" for bugzilla ticket 798862?
rhc-iptables.sh had the wrong IP address offset, fixed in commit cd768b41ad.
Checking new rhc-iptables.sh now.
Staging area now has the updated iptables. It fixes this problem, as well as bug #798862 https://bugzilla.redhat.com/show_bug.cgi?id=798862
Passed verification on the current stage