Bugzilla – Full Text Bug Listing
| Summary: | [transport][director] Unable to use headless director when proxies are required | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Michal Ruzicka <michal.ruza> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | eckart.langhuth, filip.hrbek, Kenn.Hussey, mikaelpetterson, pascal, pawel.pogorzelski1, slewis, Szymon.Brandys, thomas |
| Version: | 3.6 | ||
| Target Milestone: | 3.7 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Michal Ruzicka
Those jobs have been created with the requested access permissions: https://hudson.eclipse.org/hudson/job/buckminster-head/ https://hudson.eclipse.org/hudson/job/buckminster-maintenance/ Closing as fixed; please reopen if you need anything else. Something is wrong. When i run on on the master, p2 is not able to find repositories at: http://download.cloudsmith.com/buckminster/external-3.6 The repositories are there though, I can access it from other sites. It seems like it's somehow related to restricted outgoing access. On the master, the failure is quick (seconds) but on a slave the request to access the repository hangs indefinitely. > Something is wrong.
The problem is that your build is not using the proxy server to access the Internet.
Your build seems to spawn a second java process -- I'm guessing this is because of ant. Although the second process has the correct proxy settings in the ANT_OPTS and ANT_ARGS environment variables, the proxy server settings are not featured on the command line like the Hudson job process shows them.
This is the java process that Hudson launches (pardon the lack of spaces).
/shared/common/sun-jdk1.6.0_21_x64/jre/bin/java-Dhttp.proxyHost=proxy.eclipse.org-Dhttp.proxyPort=9898-Dhttps.proxyHost=proxy.eclipse.org-Dhttps.proxyPort=9898-Dhttp.nonProxyHosts=*.eclipse.org-Dhttps.nonProxyHosts=*.eclipse.org-Dftp.proxyHost=proxy.eclipse.org-Dftp.proxyPort=9898-Dftp.nonProxyHosts=*.eclipse.org-classpath/shared/stp/apps/apache-ant-1.7.1/lib/ant-launcher.jar-Dant.home=/shared/stp/apps/apache-ant-1.7.1-Dant.library.dir=/shared/stp/apps/apache-ant-1.7.1/liborg.apache.tools.ant.launch.Launcher-Dhttp.proxyHost=proxy.eclipse.org-Dhttp.proxyPort=9898-Dhttps.proxyHost=proxy.eclipse.org-Dhttps.proxyPort=9898-Dhttp.nonProxyHosts=*.eclipse.org-Dhttps.nonProxyHosts=*.eclipse.org-Dftp.proxyHost=proxy.eclipse.org-Dftp.proxyPort=9898-Dftp.nonProxyHosts=*.eclipse.org-cp-DBUCKMINSTER_LOGLEVEL=WARNING-DANT_TARGET=promote.sites-Dbuckminster.loglevel=WARNINGpromote.siteshudson
The second process is this one. Notice how it uses eclipse.p2.mirrors=false, as well as no settings for proxyHost and proxyPort.
/opt/public/common/sun-jdk1.6.0_21_x64/jre/bin/java-Declipse.p2.mirrors=false-jar/opt/users/hudsonbuild/workspace/buckminster-maintenance/tools/director/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar-rfile:/home/data/httpd/download.eclipse.org/tools/buckminster/headless-3.6-rhttp://download.cloudsmith.com/buckminster/external-3.6-d/opt/users/hudsonbuild/workspace/buckminster-maintenance/tools/buckminster-pBuckminster-iorg.eclipse.buckminster.cmdline.product-iorg.eclipse.buckminster.core.headless.feature.feature.group-iorg.eclipse.buckminster.pde.headless.feature.feature.group-iorg.eclipse.buckminster.cvs.headless.feature.feature.group-iorg.eclipse.buckminster.subclipse.headless.feature.feature.group-iorg.eclipse.buckminster.emma.headless.feature.feature.group
Although I don't understand why the second process does not have the proxy settings in the command line as parameters, could you add these two parameters t your build.xml (or wherever you have defined eclipse.p2.mirrors)?
http.proxyHost=proxy.eclipse.org
http.proxyPort=9898
.. just to see if that solves the problem?
You would also likely have to remove download.cloudsmith.com from your noproxy property in build.xml:
<condition property="no.proxy" value="${env.no_proxy}, dev.eclipse.org, download.cloudsmith.com" else="dev.eclipse.org, download.cloudsmith.com">
(In reply to comment #3) > Although I don't understand why the second process does not have the proxy > settings in the command line as parameters, could you add these two parameters > t your build.xml (or wherever you have defined eclipse.p2.mirrors)? > > http.proxyHost=proxy.eclipse.org > http.proxyPort=9898 > These are added now. But why would you expect them to be there? I spawn a new JVM from ant with explicit parameters. It used to work but something is undoubtedly different now. If anyone has said something about proxy parameters, I've missed it completely. > .. just to see if that solves the problem? > It doesn't seem to. It still hangs on the same spot. > You would also likely have to remove download.cloudsmith.com from your noproxy > property in build.xml: > <condition property="no.proxy" value="${env.no_proxy}, dev.eclipse.org, > download.cloudsmith.com" else="dev.eclipse.org, download.cloudsmith.com"> I added that as an experiment when things didn't work. It's removed now. (In reply to comment #4) > (In reply to comment #3) > > > Although I don't understand why the second process does not have the proxy > > settings in the command line as parameters, could you add these two parameters > > t your build.xml (or wherever you have defined eclipse.p2.mirrors)? > > > > http.proxyHost=proxy.eclipse.org > > http.proxyPort=9898 > > > These are added now. But why would you expect them to be there? I spawn a new > JVM from ant with explicit parameters. It used to work but something is > undoubtedly different now. If anyone has said something about proxy parameters, > I've missed it completely. I wouldn't expect those settings to be in your build job since we have defined them globally. In fact, I wouldn't expect you to be required to set them since they are defined in the environment, but for some reason that sub-process isn't using those values that we have defined. > > > .. just to see if that solves the problem? > > > It doesn't seem to. It still hangs on the same spot. The process now shows the parameters: /opt/public/common/sun-jdk1.6.0_21_x64/jre/bin/java -Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Declipse.p2.mirrors=false -jar /opt/users/hudsonbuild/workspace/buckminster-maintenance/tools/director/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar -r file:/home/data/httpd/download.eclipse.org/tools/buckminster/headless-3.6 -r http://download.cloudsmith.com/buckminster/external-3.6 -d /opt/users/hudsonbuild/workspace/buckminster-maintenance/tools/buckminster -p Buckminster -i org.eclipse.buckminster.cmdline.product -i org.eclipse.buckminster.core.headless.feature.feature.group -i org.eclipse.buckminster.pde.headless.feature.feature.group -i org.eclipse.buckminster.cvs.headless.feature.feature.group -i org.eclipse.buckminster.subclipse.headless.feature.feature.group -i org.eclipse.buckminster.emma.headless.feature.feature.group However, according to my proxy logs, the proxy is not even being contacted, so it appears it's still trying to fetch your external dependencies directly. Do you know if anything else could be overriding these settings? (In reply to comment #5) > I wouldn't expect those settings to be in your build job since we have defined > them globally. In fact, I wouldn't expect you to be required to set them since > they are defined in the environment, but for some reason that sub-process isn't > using those values that we have defined. > Not sure if we're talking (or writing) past each other here. The -Dxxx=yyy options are properties, not environment, and I pass them explicitly in the ant-script. There's no automatic passing of properties when calling java from ant. The environment is inherited of course but its invisible in the ps listing. > However, according to my proxy logs, the proxy is not even being contacted, so > it appears it's still trying to fetch your external dependencies directly. Do > you know if anything else could be overriding these settings? No, I'm sorry. I don't have a clue. This is a call to the headless p2 director and whatever symptoms it shows should also be apparent when attempting to access the repository from any other running Eclipse instance. (In reply to comment #6) > Not sure if we're talking (or writing) past each other here. The -Dxxx=yyy > options are properties, not environment, and I pass them explicitly in the > ant-script. There's no automatic passing of properties when calling java from > ant. The environment is inherited of course but its invisible in the ps > listing. ant, the 'executable', is nothing more than a shell script that grabs $ANT_OPTS from the environment and passes it to the commandline (hence visible to ps) droy@build:~> file /opt/public/common/apache-ant-1.7.1/bin/ant /opt/public/common/apache-ant-1.7.1/bin/ant: POSIX shell script text That script contains: ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS -classpath \"$LOCALCLASSPATH\" -Dant.home=\"$ANT_HOME\" -Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts org.apache.tools.ant.launch.Launcher $ANT_ARGS -cp \"$CLASSPATH\" $ant_exec_args" If you're calling ant another way, you'll need to pass the proxy values for http, https and ftp as needed. proxy.eclipse.org port 9898 Closing as NOT_ECLIPSE but do reopen if there is anything I can assist you with. Since I now, on your recommendation indeed do pass the needed options, and it still doesn't work, I'm not inclined to consider this resolved, nor as a NOT_ECLIPSE since the actual utility that I'm using is the p2 director. I'm in a position where my build has stopped working and I have no clue what to do about it. The only thing I have done is to follow your advice and move it to another machine. This machine does not permit access to the outside world. So please help me resolve this. Also, please note that I'm not calling ant at all, Hudson does. I'm using ant to call java but a qualified guess is that I'm far from the only one that does that. > This machine does not permit access to the outside world. All the Hudson machines have unrestricted access to the outside world -- but you must use a proxy server. > the actual utility that I'm using is the p2 director. Is p2 director aware of our proxies? http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04705.html We have defined the proxy settings in the OS environment, in the Hudson environment and in the Java variables; as you can see below, I needn't tell wget to use a proxy. hudsonbuild@hudson-slave2:~> wget http://www.google.com --2010-10-06 08:38:27-- http://www.google.com/ Resolving proxy.eclipse.org... 206.191.52.57 Connecting to proxy.eclipse.org|206.191.52.57|:9898... connected. Proxy request sent, awaiting response... 302 Found Location: http://www.google.ca/ [following] --2010-10-06 08:38:27-- http://www.google.ca/ Connecting to proxy.eclipse.org|206.191.52.57|:9898... connected. Proxy request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html' [ <=> ] 9,346 --.-K/s in 0.007s 2010-10-06 08:38:27 (1.36 MB/s) - `index.html' saved [9346] http://www.eclipse.org/forums/index.php?t=msg&th=181615 If anyone can confirm that the p2 director cannot/does not use proxies I will rig something up on our local Hudson instances to allow Thomas' builds to run. Raising the priority on this since it blocks our builds completely. We cannot use the p2 (i.e. the director app) at the hudson build server to access repositories outside of eclipse.org. It doesn't matter what options or environment settings we use. This has to be resolved! Why doesn't the director honor the normal proxy settings? Is the ECF httpclient doing something special here. Does it honor some other settings? We are passing the settings below but it doesn't seem to help. -Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -DftpnonProxyHosts=*.eclipse.org (In reply to comment #12) > Raising the priority on this since it blocks our builds completely. > > We cannot use the p2 (i.e. the director app) at the hudson build server to > access repositories outside of eclipse.org. It doesn't matter what options or > environment settings we use. This has to be resolved! > > Why doesn't the director honor the normal proxy settings? Is the ECF httpclient > doing something special here. Does it honor some other settings? We are passing > the settings below but it doesn't seem to help. > > -Dhttp.proxyHost=proxy.eclipse.org > -Dhttp.proxyPort=9898 > -Dhttps.proxyHost=proxy.eclipse.org > -Dhttps.proxyPort=9898 > -Dftp.proxyHost=proxy.eclipse.org > -Dftp.proxyPort=9898 > -DhttpnonProxyHosts=*.eclipse.org > -DhttpsnonProxyHosts=*.eclipse.org > -DftpnonProxyHosts=*.eclipse.org I haven't had a chance to look at all of the comments on this bug (as I've just been made aware of it), but just to clarify...what ECF does WRT proxy configuration is that it uses the proxy configuration specified in org.eclipse.core.net proxy API (as it must for Eclipse) rather than from the JRE system properties. It sounds like you may need to a) add the (optional) org.eclipse.core.net bundle to the headless director...if it's not already there...and b) setup the proxy configuration you want with org.eclipse.core.net proxy API. 1) If the org.eclipse. Thanks for rapid reply Scott. (In reply to comment #13) > It sounds like you may need to a) add the (optional) > org.eclipse.core.net bundle to the headless director...if it's not already > there... It's there. > and b) setup the proxy configuration you want with org.eclipse.core.net > proxy API. > That is problematic since the director is a headless application and this is a headless build. The director is downloaded as part of the build. I think in general, this highlights a problem with the Eclipse proxy support in that it doesn't default to the settings for the standard proxy properties. Is there any way to get around that? Next problem is of course when I use the director to install Buckminster and then use Buckminster to access repositories outside of Eclipse. How do I configure the Eclipse ProxyManager in that situation? (In reply to comment #15) > Next problem is of course when I use the director to install Buckminster and > then use Buckminster to access repositories outside of Eclipse. How do I > configure the Eclipse ProxyManager in that situation? Not quickly/easily, unfortunately. The changeover to httpclient as the primary filetransfer provider (and it's http/https proxy configuration) necessitated depending upon the core.net Proxy api for the proxy configuration. I'm looking to see if there are any Apache httpclient 3.1.0 proxy system properties to set the default...in the case where the proxy API isn't present...but I don't remember that there are. Could I ask...why did this come up all of a sudden? Was there some change in the proxy config at Eclipse.org? I believe the proxy API uses the preference store to persist the proxy preferences...perhaps the director could use a preference store with the correct values in it. I know this isn't the right permanent solution...but just producing ideas. (In reply to comment #15) > Next problem is of course when I use the director to install Buckminster and > then use Buckminster to access repositories outside of Eclipse. How do I > configure the Eclipse ProxyManager in that situation? I think the director should probably be enhanced to pass in proxy config for headless operation...and use the core.net proxy API to set that config appropriately prior to use. (In reply to comment #16) > Could I ask...why did this come up all of a sudden? Was there some change in > the proxy config at Eclipse.org? > Yes. The new Hudson build server is using a proxy. The old one didn't. > I believe the proxy API uses the preference store to persist the proxy > preferences...perhaps the director could use a preference store with the > correct values in it. I know this isn't the right permanent solution...but > just producing ideas. Thanks. I'm using that now. Let's see if it works. (In reply to comment #17) > I think the director should probably be enhanced to pass in proxy config for > headless operation...and use the core.net proxy API to set that config > appropriately prior to use. I think that whatever is changed should apply to all headless commands and not just the director. We have the same problem in Buckminster. I guess that anyone who uses the ant-launcher or similar will face the same issue. The right thing to do IMO, would be to fall back to the standard System properties when nothing has been declared in the preferences. That doesn't happen now though. (In reply to comment #19) > (In reply to comment #17) > > I think the director should probably be enhanced to pass in proxy config for > > headless operation...and use the core.net proxy API to set that config > > appropriately prior to use. > > I think that whatever is changed should apply to all headless commands and not > just the director. We have the same problem in Buckminster. I guess that anyone > who uses the ant-launcher or similar will face the same issue. The right thing > to do IMO, would be to fall back to the standard System properties when nothing > has been declared in the preferences. That doesn't happen now though. That's true...this fallback to the jre system properties doesn't happen now...and I agree it probably should (although I vaguely remember that there are some subtleties WRT the httpclient proxying, jre 1.5 vs. 1.4 support in Equinox, proxy authentication, and the proxy API). Neither I nor Henrich Kraemer (the ECF contributor who has done most of the recent work with proxy API) had the resources to take on this extra task when the httpclient proxy work was done...so it wasn't done. I tried adding a <install>/configuration/.settings/org.eclipse.core.net.prefs that was preconfigured using my IDE. For some reason that doesn't help either. So I'm back at square one. (In reply to comment #21) > I tried adding a <install>/configuration/.settings/org.eclipse.core.net.prefs > that was preconfigured using my IDE. For some reason that doesn't help either. > So I'm back at square one. I'll do what I can to help Thomas. I've added Szymon and Pawel to this bug...they are the experts on the core.net proxy API that I'm aware of. Szymon and Pawel: Thomas is trying to run the p2 director app headlessly behind a proxy, and so needs to configure the proxy API preferences for running the director (which uses p2, which uses ECF filetransfer, which uses the core.net proxy API). Could you help him with the configuration of the proxy API in headless environment? (In reply to comment #7) As far as I know Thomas has tried to run the build using the Buckminster plugin for Hudson (http://wiki.hudson-ci.org//display/HUDSON/Buckminster+PlugIn). There was a serious bug in this plugin (until its version 1.0.2 inclusively) which caused that the spawned Buckminster process did not inherit environment variables added by Hudson (see http://issues.hudson-ci.org/browse/HUDSON-6488). If the Buckminster plugin for Hudson installed at hudson.eclipse.org is old enough to contain the bug, it might be related to the issue. In any case could you please upgrade the plugin to its latest version (if it is not the case already)? As perticularly the problem with not propagating the environment variables has other serious consequences like making it difficult to run anything that requires GUI (and thus Xvnc plugin) from within Buckminster spawned by the plugin (because the DISPLAY environment variable defined by the Xvnc plugin is not propagated). Where are we at on this issue? Could someone do a recap? Thx. Hi, I am facing similar problem for Eclipse 3.5 (Linux). http://www.eclipse.org/forums/index.php?t=msg&th=207598&start=0&S=716ec12771544c9785fa8027caac6e3a Any solution to the problem? br, //mike (In reply to comment #24) > Where are we at on this issue? Could someone do a recap? Thx. My understanding is the following: 1) ECF uses the proxy API (as per bug 181544) to get proxy settings 2) For headless usage (of director and/or other apps), there is a desire to be able to specify proxy settings via system properties, as per comment 3. There would be at least a couple of ways to achieve 2: a) ECF filetransfer could use both the proxy API and/or system properties to specify proxy settings...for the apache httpclient-based provider (primary) and other providers (secondary). b) Another way to achieve the same thing would be for the proxy API to read some/these system properties and populate itself based upon these values...and then ECF filetransfer would just use the appropriate/correct values (by using whatever is exposed by the proxy API). 'b' seems to me a more general solution...because then the handling of system-property-specified proxy information has to only be done once (by the proxy API), rather than reproduced separately for each ECF provider (which would be necessary if ECF handled the proxy system properties directly). Also the proxy API can be responsible for dealing with proxy data conflicts, etc. Also...in the near future...and assuming no contributions...ECF has no resources to apply to doing a...so that's another reason why b would be preferred from our perspective. Where can the source for the proxy API be found? //mike I've just tried the director.application included in the RC1 build of the eclipse SDK and it works fine in the context of proxy (I have a windows VM that connect to the external world through a pfsense VM that is used as the proxy). I have been able to successfully install egit from indigo. I'm starting to wonder if the issue is not caused by the absence of the platform specific fragments in the configuration that you are running or maybe the proxy type itself. I also seem to remember that the org.eclipse.core.net bundle (that contains the proxy code) sometimes try to use the standard java system properties for specifying proxy (e.g. http.proxy). http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.6.1/org.eclipse.core/net/1.2.100/org/eclipse/core/internal/net/ProxyManager.java#ProxyManager Can someone indicate where we are at? Closing as worksforme. Please reopen with details (maybe a complete p2 director app used), or details about the proxy itself. It doesn't work for me. Following the http://wiki.eclipse.org/Eclipse_b3/aggregator/manual and using http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/products/director_latest.zip there is no way to provide required http proxy setting to the director application using the system properties http.proxyHost, http.proxyPort. I tried setting these properties and providing them in the director.ini as vmargs. I would assume this to work for a command line application. There is a workaround. Define the required settings in the Network Setting preference page of an Eclipse installation. The information will be persisted in configuration/.settings/org.eclipse.core.net.prefs Copying this file to the related .setting folder in the director installation works. (In reply to comment #30) > It doesn't work for me. > Following the http://wiki.eclipse.org/Eclipse_b3/aggregator/manual and using > http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/products/director_latest.zip > there is no way to provide required http proxy setting to the director > application using the system properties http.proxyHost, http.proxyPort. > I tried setting these properties and providing them in the director.ini as > vmargs. > I would assume this to work for a command line application. No...Eclipse has it's own proxy settings via the core proxy API. > > There is a workaround. Define the required settings in the Network Setting > preference page of an Eclipse installation. > The information will be persisted in > configuration/.settings/org.eclipse.core.net.prefs > Copying this file to the related .setting folder in the director installation > works. Just to be clear...what you specify as the workaround is the supported way of specifying proxy information (i.e. using the proxy API...which is the proxy information used by the ECF transport...as required by bug 181544). It is possible to support using *both* the proxy API and normal system properties, but ECF has not had sufficient resources to do it. If you would like to contribute such an enhancement, please open an enhancement request against ECF filetransfer component, and I/we will happily work with you on it. |