This week we have a post about troubleshooting a new CAG 12.8.04 deployment on RHEL 8. As always, we present the reported issue, what we found during troubleshooting, and how the problem was remedied.
| Issue | CA Access Gateway (CAG) on RHEL 8: 503 Error After Installation |
| Symptoms | When attempting to access proxy protected resources, the users would receive an HTTP 503 error (Service Unavailable). |
| Troubleshooting | We reviewed the server.conf file and did not see any issues with the configuration of the application server. Next, we verified that the server was available and listening on the defined port using the following command: netstat -an | grep 8009. The results of the command showed that the server was indeed listening on that port. We then examined the Apache Tomcat Connector log (mod_jk.log) and searched for any error that would indicate a connection problem with the web application server. The search yielded the following error: “(ajp13) connecting to tomcat failed..)”. We knew that the server was running because of our earlier test and after reviewing the server.log, we found that there were no initialization errors. We ran one additional test; we executed the following command: ping localhost. Although, the server was configured with IPv4 and IPv6 addresses, the ping returned only the IPv6 loopback address of ‘::1’. This meant that the Apache Tomcat web application server was only servicing requests for IPv6. |
| Condition | The server was configured with at least one IPv6 address. |
| Cause | The Apache Tomcat connector uses localhost to connect to the Tomcat web application server, but the CAG was only servicing requests that were IPv6 bound. The server had a host file entry for the IPv6 loopback address for localhost, but it appears that the CAG services do not use it for the Apache Tomcat connector during the configuration. |
| Remedy | We had the client open the server.conf file in the /opt/CA/secure-proxy/proxy-engine/conf/ directory and then search for the line with ‘worker.ajp13.host=localhost’. We directed them to change this line to ‘worker.ajp13.host=::1’. After a service restart, the requests were routed as expected. |
As always, we hope that you have found this information useful. If you need IAM assistance, reach out to SIS today and we would be happy to assist you. And subscribe to our newsletter to be notified about the posting of future articles and other SIS news.
