Vlastimil Cudek (1●1●2●2)
| asked Jul 02 '12, 12:31 p.m.
edited Jul 02 '12, 9:47 p.m. by Geoffrey Clemm (30.1k●3●30●35)
RTC4 installation with SQUID reverse proxy installed - going into forwarding loop and can not finalize /admin installation.
RTC4 topology - using 2 WAS servers: Client <> SQUID Reverse Proxy Cache <> JTS WAS server / CCM WAS server <> DB2 server SQUID proxy configuration file: acl jts urlpath_regex ^/jts acl admin urlpath_regex ^/admin acl clmhelp urlpath_regex ^/clmhelp acl ccm urlpath_regex ^/ccm https_port 443 cert=/etc/squid/cert/server.pem key=/etc/squid/cert/privkey.pem accel vhost cache_peer WAS1.server.com parent 9443 0 no-query no-digest originserver name=jts_srv ssl login=PASS sslflags=DONT_VERIFY_PEER cache_peer_access jts_srv allow jts cache_peer_access jts_srv allow admin cache_peer_access jts_srv allow clmhelp cache_peer_access jts_srv deny ccm http_access allow all cache_peer WAS2.server.com parent 9443 0 no-query no-digest originserver name=ccm_srv ssl login=PASS sslflags=DONT_VERIFY_PEER cache_peer_access ccm_srv deny jts cache_peer_access ccm_srv deny admin cache_peer_access ccm_srv deny clmhelp cache_peer_access ccm_srv allow ccm http_access allow all visible_hostname CLM.server.com http_access deny all acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 memory_replacement_policy heap GDSF cache_replacement_policy heap GDSF cache_store_log none cache_dir aufs /opt/squid/cache 12288 256 256 cache_mem 6144 MB coredump_dir /opt/squid/var/cache refresh_pattern . 0 20% 4320 cachemgr_passwd disable all maximum_object_size 2048 MB maximum_object_size_in_memory 32 MB buffered_logs on First forwarding loops in SQUID log during finalizing /ccm app: 2012/07/02 18:00:49| WARNING: Forwarding loop detected for: Follow with:GET /jts/service/com.ibm.team.repository.service.internal.IServerConfigurationRestService/serviceConfiguration?implementationClassName=com.ibm.team.repository.service.internal.ServletConfigurationService HTTP/1.1 X-com-ibm-team-configuration-versions: LATEST Accept: text/json X-jazz-downstream-auth-client-level: 4.0 Content-Type: application/x-www-form-urlencoded; charset=utf-8 X-Requested-With: XMLHttpRequest Referer: https://clm.server.com/ccm/customSetup Accept-Language: en-US Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) Via: 1.1 clm.server.com (squid/3.1.10) Surrogate-Capability: unset-id="Surrogate/1.0 ESI/1.0" 2012/07/02 18:05:28| WARNING: Forwarding loop detected for: No error in client, so continue. But going to /admin and receive error in web browser:GET /jts/service/com.ibm.team.repository.service.internal.IServerConfigurationRestService/serviceConfiguration?implementationClassName=com.ibm.team.datawarehouse.service.internal.RemoteDatabaseService HTTP/1.1 2012/07/02 18:05:28| WARNING: Forwarding loop detected for: GET /jts/service/com.ibm.team.repository.service.internal.IServerConfigurationRestService/serviceConfiguration?implementationClassName=com.ibm.team.datawarehouse.service.internal.InternalDataWarehouseService HTTP/1.1 |
Curtis d'Entremont (1.3k●3)
| answered Jul 04 '12, 11:42 a.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Jul 04 '12, 11:43 a.m.
I don't have experience with SQUID in particular, but here are some things I would look for:
- Make sure the proxy is accessible at the public URL as configured in the RTC server, with exact case. - The RTC server must be able to make requests to itself - make sure it can access the proxy and make requests to, for example, <public_url>/ccm/rootservices. It may seem odd that the server talks to itself, but it is required for distributed deployments. - Make sure the proxy server does not rewrite the Host header. It should be allowed through unmodified. This header represents the intended target of requesting client and is required by the server. - Compare the headers incoming to the proxy to the ones received by the RTC server, and make sure none of them are modified or omitted. It should be ok if extra ones are added. - Try disabling all the features of the proxy, including caching, adding custom headers, etc, until you have a transparent pass-through proxy that works, then add them back one by one to find out which one is causing the trouble. |
I am also seeing this error using WAS 8.0.0.5 with Squid 3 v26. I am unable to complete the jts/setup due to the admin/setup throwing a CRJCA0146E The Lifecycle Project Administration (LPA) application could not communicate with the application at the following URL: https://<URL>/qm/friends.
Did you find a solution to this problem? |
|
Well... I hacked it. I ended up putting an entry for the proxy server in /etc/hosts on the WAS box with CLM such that the proxy server DNS hostname resolve to the CLM box hostname! I then configured the WAS server port to be the same as the proxy server port (443). Now, the CLM server can no longer ask the proxy server questions - it only asks itself (which prevents squid from complaining).
What is happening is the server is configured with the proxy server hostname. So, when CLM needs to "ask itself a question" it actually sends a request to the proxy server, and the proxy server then notices the request is going back to the origin - and blocks it as a forwarding loop. By "hacking" the hostname entry on the CLM server for the proxy server, you essentially prevent the CLM server from asking the proxy server any questions. Unfortunately, this means your proxy server port and WAS port must be the same, but I couldn't get a different port working anyways. I highly doubt this is the correct answer, but it is a "good enough" answer for now. I'd love to know the correct answer if there is one! |
