jbe with proxy authentication
Hi all,
We're thinking of getting our RTC/RQM Servers externally hosted. We're using RTC v3 and RQM 2.x
However, we'll have a few PCs on site that we will want to do builds on. Our access to the internet is through an authenticated proxy (I have no idea of the details - just the hostname and port number)
Does anyone know how we can set up the jbe process to access an externally hosted repository in this scenario?
I've come accross this: https://jazz.net/forums/viewtopic.php?t=2026 and I've looked at the referenced defect but that was delivered in version 1.x
I can find no other references to this on the project wiki, the rtc v3 information center or in these forums.
Any assistance would be gratefully received.
Many Thanks,
Robin
We're thinking of getting our RTC/RQM Servers externally hosted. We're using RTC v3 and RQM 2.x
However, we'll have a few PCs on site that we will want to do builds on. Our access to the internet is through an authenticated proxy (I have no idea of the details - just the hostname and port number)
Does anyone know how we can set up the jbe process to access an externally hosted repository in this scenario?
I've come accross this: https://jazz.net/forums/viewtopic.php?t=2026 and I've looked at the referenced defect but that was delivered in version 1.x
I can find no other references to this on the project wiki, the rtc v3 information center or in these forums.
Any assistance would be gratefully received.
Many Thanks,
Robin
19 answers
Hi Nick,
I tried changing the proxyhost line to:
-Dhttps.proxyHost=proxyhostname
(taking the https:// off)
and I get a whole new set of errors thus:
Could be a red herring but.... it's the first thing that I've tried that's managed to change the error message.
I tried changing the proxyhost line to:
-Dhttps.proxyHost=proxyhostname
(taking the https:// off)
and I get a whole new set of errors thus:
2010-12-17 13:24:04 [Jazz build engine] Running build loop...
2010-12-17 13:24:05 [Jazz build engine] Using proxy proxyhost:proxyport to reach https://repohost:9443/jazz
17-Dec-2010 13:24:05 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:05 org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
INFO: ntlm authentication scheme selected
17-Dec-2010 13:24:05 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpConnection releaseConnection
WARNING: HttpConnectionManager is null. Connection cannot be released.
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:06 org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
INFO: ntlm authentication scheme selected
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpConnection releaseConnection
WARNING: HttpConnectionManager is null. Connection cannot be released.
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:06 org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
INFO: ntlm authentication scheme selected
17-Dec-2010 13:24:06 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
17-Dec-2010 13:24:07 org.apache.commons.httpclient.HttpMethodBase processCookieHeaders
WARNING: Cookie rejected: "$Version=0; BCSI-CS-F11F777FF3AE6443=2; $Path=/". Illegal path attribute "/". Path of origin: "repohost:9443"
2010-12-17 13:24:07 [Jazz build engine] CRRTC3524W: Repository connection failed: CRJAZ1247I The request to the server failed. The server returned th
e http error 407 with error text "Proxy Authentication Required". Examine any further details here or look in the server log files for more informati
on on how to resolve the issue.17-Dec-2010 13:24:07 org.apache.commons.httpclient.HttpConnection releaseConnection
WARNING: HttpConnectionManager is null. Connection cannot be released.
2010-12-17 13:24:07 [Jazz build engine]
2010-12-17 13:24:07 [Jazz build engine] Sleeping for 30 seconds...
Could be a red herring but.... it's the first thing that I've tried that's managed to change the error message.
The https.proxyHost property should have just the host name, not the protocol, as in your last attempt.
With that change, the command line and JBE look OK (though you might want to avoid the duplication of the -vm arg though, and just have it in the jbe.ini, with '\java' at the end).
I'm not sure where the rejected cookies are coming from. Jazz/RTC itself doesn't use cookies, except for the web container's use of them for form-based authentication, and these cookies don't like like those ones. What are you using as your web container (the default included with RTC is Tomcat)?
I've filed a work item to see if the Repository team can help:
148391: Rejected cookies when using proxy with JBE.
With that change, the command line and JBE look OK (though you might want to avoid the duplication of the -vm arg though, and just have it in the jbe.ini, with '\java' at the end).
I'm not sure where the rejected cookies are coming from. Jazz/RTC itself doesn't use cookies, except for the web container's use of them for form-based authentication, and these cookies don't like like those ones. What are you using as your web container (the default included with RTC is Tomcat)?
I've filed a work item to see if the Repository team can help:
148391: Rejected cookies when using proxy with JBE.
Interestingly, I tried to make jbe work with a proxy forever and could not. Finally, I created a build engine on a box that has a squid proxy. The squid proxy's HTTP port is the same port as the CCM server's port (443 in our installation).
My JBE command line is:
Notice that the repository host and the proxyHost are the same.
In the squid.conf file, our Jazz CCM server is defined in the cache_peer statement:
This works, but it contradicts what I read on jazz.net. According to this thread, it shouldn't work.
What am I doing wrong?
My JBE command line is:
/opt/IBM/jazz/client/eclipse/jdk/bin/java -Djava.protocol.handler.pkgs=com.ibm.net.ssl.www2.protocol \
-Xmx300m \
-Dosgi.requiredJavaVersion=1.5 \
-jar /opt/IBM/jazz/buildsystem/buildengine/eclipse/plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar \
-repository https://build1.ipc.com/jazz \
-data /opt/bld/build1jbe/data \
-userId rtcuser \
-passwordFile /opt/IBM/jazz/buildsystem/buildengine/eclipse/jbepass.txt \
-engineId build1jbe \
-vmargs \
-Dhttps.proxyHost=build1.ipc.com \
-Dhttps.proxyPort=443
Notice that the repository host and the proxyHost are the same.
In the squid.conf file, our Jazz CCM server is defined in the cache_peer statement:
cache_peer jazzhost.ipc.com parent 443 0 no-query originserver name=httpsAccel ssl login=PROXYPASS sslflags=DONT_VERIFY_PEER
This works, but it contradicts what I read on jazz.net. According to this thread, it shouldn't work.
What am I doing wrong?
The -vmargs only comes into play when using the JBE executable. Likewise for JBE.ini. When launching java directly, as in your snippet, the -D options need to go after 'java' but before -jar, like the one for osgi.requiredVersion.
Hello Nick,
Thanks for the answer. But what about the repository host? Again, my concern is that I put the name of the local machine (running JBE and Squid) in the repository URL, and it runs fine, whereas instructions in jazz.net say the repository host should be the Jazz server.
Shouldn't the jazz.net article be checked?
I agree that the -repository arg to JBE should be the actual repo URL, and the proxy should be specified via -Dhttps.proxyHost=. Does that configuration work for you too?
It may be that the Squid configuration is such that it always talks to the 'cache peer' regardless of the original URL, so the -repository would essentially get ignored. I'll check with the authors of the proxy article.
It may be that the Squid configuration is such that it always talks to the 'cache peer' regardless of the original URL, so the -repository would essentially get ignored. I'll check with the authors of the proxy article.
I agree that the -repository arg to JBE should be the actual repo URL, and the proxy should be specified via -Dhttps.proxyHost=. Does that configuration work for you too?
It may be that the Squid configuration is such that it always talks to the 'cache peer' regardless of the original URL, so the -repository would essentially get ignored. I'll check with the authors of the proxy article.
Yes, this configuration is what we are currently running on two Squid+JBE machines, and it works: the JBE loads its workspace from Squid, not from the Jazz server.
I'll fix the -vmargs option, which seems ignored (luckily for us), and update this thread.
It'd be nice if jazz.net had tried-and-true instructions about configuring JBE to work with Squid.
You are configuring squid to run in reverse proxy mode and then trying to use it as a forward proxy. This is why it doesn't matter what hostname you specify for the repository connection, the request gets forwarded to the correct server regardless. This kind of setup would usually work, however it is not compliant to the HTTP spec, so will potentially break if either squid or the app server decides to enforce the spec.
If you are going to continue running squid in reverse proxy mode, then you can just connect directly to it. Do NOT specify -Dhttps.proxyHost at all.
If you want to use squid as a forward proxy, then you need to reconfigure it. In that case the hostname you use for the repository will start mattering.
If you are going to continue running squid in reverse proxy mode, then you can just connect directly to it. Do NOT specify -Dhttps.proxyHost at all.
If you want to use squid as a forward proxy, then you need to reconfigure it. In that case the hostname you use for the repository will start mattering.
page 2of 1 pagesof 2 pages