Package System Support for Corporate Firewall Configurations

[jmanos3]

With the new packaging system in 0.9.0, the 'meteor add' and 'meteor search' commands fail to work when behind a corporate firewall. When issuing the commands, I am receiving the message that the server could not be reached at wss://packages.meteor.com/websocket.

I had to setup my HTTP_PROXY / HTTPS_PROXY shell environment variables so that the 'curl' command would work when installing meteor. However, I have not been able to find a means of telling the DDP configuration to use the corporate proxy.

Working from the understanding that DDP is using SOCKS, I did try setting up the environment variable SOCKS_PROXY which did not affect the results. I also looked at the meteor code and confirmed that SOCKSJS was being used also.

[glasser]

On what operating system?

[jmanos3]

Oracle Enterprise Linux 5. I can test it on OSX if you need me too.

[gdon]

I have the same problem. I can't run 'meteor add' or 'meteor login', and every time I run a meteor application I get the following message:
Error connecting to package server: DDP connection timed out Warning: could not connect to package server

I'm behind a corporate fireall/proxy. I'm working on Ubuntu 14.04 64bits. All proxy variables are setted: http_proxy, https_proxy, HTTP_PROXY, HTTPS_PROXY. I'm able to run 'npm' and 'curl' and 'git' without problems.

[glasser]

Yeah, we have code to do this in tools/http-helpers.js and we need DDP to do it too.

[jhuenges]

Any Update?

[glasser]

Folks who are facing this issue: do you know what proxy is in use? I'm curious if the proxies in question will allow you to make a HTTPS connect to packages.meteor.com:443 (tunneled through the proxy) at all. For example, can you connect to https://packages.meteor.com/ in your browser at all? (The site is minimal and just consists of a login button.)

[jmanos3]

David,

I was not yet able to identify the specific proxy my company is using. However, I was able to complete your test request and I was able to reach https://packages.meteor.com/ in my browser and I was presented with the login button.

Also, I was able to replicate the issue using NGINX in my own local environment. In short, I setup a basic NGINX proxy on OS X and set my proxy environment variables appropriately. I was able to download and install meteor but package commands would fail.

According to this link (http://nginx.com/blog/websocket-nginx/), it is possible to setup NGINX to support websockets and I will try this tonight and report back when completed.

Regardless, I will not have enough influence to change corporate policy so if the new package system is going to stay dependent upon DDP, I may be out of luck.

I have identified a work around where we grab packages off the corporate network and then zip-up the .meteor directory. I then copy and un-zip as required on the servers on the corporate network. Not ideal but it gets the job done.

[glasser]

Ooh, can you describe your setup with nginx? This is a reproduction that you were able to run not on your corp network that shows the same problem?

[glasser]

This PR to a library we use is a first step: https://github.com/faye/faye-websocket-node/pull/30

[glasser]

(and we should use http://npmjs.org/package/tunnel and specifically its createSocket method (not the full Agent implementation))

[jmanos3]

David,

My apologies for I mis-spoke above. The test proxy I had setup was using SQUID on OEL5 (Oracle Enterprise Linux 5). It was not NGINX.

I had used the SQUID/OEL5 combo because I thought it might have been used as the corporate network setup I am dealing with. The instructions I used are at : http://computernetworkingnotes.com/network-administrations/squid-server.html

Also, I knew that SQUID did not support WebSockets according to http://wiki.squid-cache.org/SquidFaq/InterceptionProxy. So, the purpose of my test was to validate I could create the same error condition in an environment I controlled and could turn the proxy on and off.

I am in the process of setting up an Ubuntu 14.04 virtual machine with SQUID, NGINX, APACHE, and METEOR so that I can do some additional testing and provide you with some configuration details.

I mainly used Parallels for virtual machine setups. However, if it would help, I can do everything in a Virtual Box setup and can make the VM available for download.

I will have more to report on Friday.

[jmanos3]

David,

I have successfully setup a Parallels VM of Ubuntu 14.04 and installed SQUID, NGINX, and METEOR.

I was able to configure SQUID per the previous note and confirmed I can re-create the error condition. While nice, this does not help us as SQUID can not handle WebSockets.

I was also able to configure NGINX as a forward proxy and get HTTP traffic to properly flow using the following references.

https://ef.gy/using-nginx-as-a-proxy-server http://plonexp.leocorn.com/leocornus/leocornus.buildout.cfgrepo/xps33

However, I was not able to get NGINX to handle HTTPS forwards. Per the following posts, it would appear that this not something that is supported.

http://superuser.com/questions/604352/nginx-as-forward-proxy-for-https https://www.ruby-forum.com/topic/4499344

I did find where someone stated they had it working at http://truongtx.me/2014/03/16/config-nginx-for-https-proxy-server/. However, I did not test it.

[gdon]

Hi! https://packages.meteor.com/ works for me.

2014-09-11 22:02 GMT-03:00 jmanos3 notifications@github.com:

David,

I was not yet able to identify the specific proxy my company is using. However, I was able to complete your test request and I was able to reach https://packages.meteor.com/ in my browser and I was presented with the login button.

Also, I was able to replicate the issue using NGINX in my own local environment. In short, I setup a basic NGINX proxy on OS X and set my proxy environment variables appropriately. I was able to download and install meteor but package commands would fail.

According to this link (http://nginx.com/blog/websocket-nginx/), it is possible to setup NGINX to support websockets and I will try this tonight and report back when completed.

Regardless, I will not have enough influence to change corporate policy so if the new package system is going to stay dependent upon DDP, I may be out of luck.

I have identified a work around where we grab packages off the corporate network and then zip-up the .meteor directory. I then copy and un-zip as required on the servers on the corporate network. Not ideal but it gets the job done.

— Reply to this email directly or view it on GitHub https://github.com/meteor/meteor/issues/2515#issuecomment-55349839.

[jmanos3]

Just wanted to report an additional test I completed.

Websocket.org provides some testing pages to validate if your browser / connection supports websockets. The URL is http://www.websocket.org/echo.html.

One of our corporate proxies allowed me to establish both WS an WSS connections using FireFox. However, another one only allowed me to establish WSS connections.

So, at least for my situation, I can confirm that the proxy servers are support websockets to some level.

[jmanos3]

And one more follow-up from additional testing....

In my local environment, when using SQUID as a forward proxy, I was able to use WSS with http://www.websocket.org/echo.html. However, I was not able to use WS. This was a surprise given that some of the postings suggested that SQUID would not support websockets at all.

In my local environment, when using NGINX as a forward proxy, i was not able to use either WS or WSS with http://www.websocket.org/echo.html. This was not a surprise.

In my local environment, when using SQUID as a forward proxy, I still ran into the error using 'meteor add'.

[jmanos3]

David,

It's been awhile and I know you have other issues of higher priority. However, can you provide any update and or direction on what is happening with this issue?

Not to add any pressure but my CTO title is on the line. My team has informed me that I will be demoted to marketing manager if my recommended platform of the future can not download packages behind the firewall. :)

Sincerely,

James

[n1mmy]

Hi James,

That sounds very frustrating -- I wish we could address this right away, but as you say in your message we also have other priorities and other users that we're also accountable to. This is very much on our list of issues to address, however I can't yet give you a time estimate as to when we might ship it.

Perhaps you could try one of the various apps that forces traffic through a proxy:

http://www.proxifier.com/mac/ http://www.proxycap.com/ http://tsocks.sourceforge.net/

Cheers, -- Nick

[jmanos3]

Nick,

Thanks for reviewing and for the update - much appreciated.

James

[FIRE-BRAIN]

I am now having this issue. Wasn't having it previously on the same app I am working on. I might have to wait before using it for work as well.

[glasser]

Hi @jmanos3 . Sorry for the radio silence --- just got back from my honeymoon.

As you can see I've started working on this again (notably, changing the library we use to one that can be compatible with proxy tunneling). And I'm pretty sure I know how to write the actual necessary code. But I'm still stymied by having no way to test this feature.

It sounds like you have managed to set up a good test-bed VM for this issue. Is that something you could share with me somehow? Either by somehow directly sharing the VM, or letting me ssh into it, or very specific setup instructions? I didn't find that the links you gave were clear enough to help me set up the precise setup required for this issue.

[glasser]

I did come up with a test scenario, which hopefully is at least something like the issues that users are facing; see the message on fb7921a.

[jmanos3]

Congrats David on your marriage and honeymoon! A perfect reason for radio silence :)

I have been traveling the past few days but will have time this weekend / next week to document in more detail how I setup SQUID in my VM.

I saw your post and reference to Proxy Bananza and would agree if that works it should work for other proxy setups. The real question is on my end in that will my corporate proxy handle it properly. I do not have control over that proxy server (in comparison to my test proxy) but I am looking forward to testing it.

While I will be out of office for the next week, I will have time to test and I have access to the corporate network via VPN so if you want me to test specifics, just let me know.

James

[n1mmy]

Hey @jmanos3,

We've got a first version of HTTP[S]_PROXY support in release 0.9.4-rc.6.

Can you please give it a whirl behind your firewall with meteor --release 0.9.4-rc.6 or check out the 0.9.4 branch from git and run from there?

Thanks! -- Nick

[jmanos3]

Nick / David,

A couple of updates for you.

1. I was able to update my OS X environment to 0.9.4-rc.6 and validate that proxy support is working by using my own SQUID proxy. With the proxy active, I was able to search and add packages fine. When I stopped the proxy service, I received errors that a connection could not be achieved.
2. With the same OS X environment connected via VPN and HTTPS_PROXY set, I was able to search and add packages correctly. This is great news as it shows both the release candidate is working and our corporate proxy is not preventing secured web socket connections.
3. I was NOT able to update my test Ubuntu 14.04 environment to 0.9.4-rc.6 as I received the following error:

Could not springboard to release: METEOR@0.9.4-rc.6: could not download tool in meteor-tool@1.0.34-rc.8

1. Because of issue 3 above, I was not able to test the actual Enterprise Linux server hosting our meteor apps on the corporate network. I was planning to download 0.9.4-rc.6 on my test linux environment (off the VPN) and then copy it over to the Enterprise Linux server and then test the release candidate.

So, great progress on this issue - very pleased :)

As soon I can get the release candidate working on Linux, I will test more.

Thanks,

James

[glasser]

Are you still seeing the "could not download tool" error? Are you seeing it even with the HTTPS_PROXY set?

[jmanos3]

David,

Yes I am still seeing the error on Ubunutu 14.04. Same error with or without using a proxy. Here are the details.

Ubuntu 14.04 server with Meteor 0.9.3.1 installed. I issue the command 'meteor update --release 0.9.4-rc.6'. Screenshot attached.

Thanks,

James

[glasser]

Hmm. I'm not sure why you're seeing that, if you'd been able to install previous versions successfully.

That said, this support has now been released in Meteor 0.9.4, so a fresh curl https://install.meteor.com/ | sh run in your real environment should install Meteor for you! Let me know if this fixes your issue in the real environment.

[jmanos3]

David,

I was able to install 0.9.4 on both my Ubuntu 14.04 VM and on my Enterprise Linux server at work. In addition, I was able to successfully search and add packages in both environments using proxies. I consider this a huge success and this issue CLOSED.

Thanks to you, Nick, and the whole MDG team for addressing this issue. Very much appreciated.

James

[n1mmy]

You're welcome. Glad to hear it works for you. Thanks for using Meteor, and best of luck with your app!

[vikramrathore2512]

Hi, I am behind a corporate proxy, have both http_proxy and https_proxy variables set and working. I updated my meteor distribution to 0.9.4. Created a new project and tried to add a package. Got the following error. meteor add googlemaps

/root/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:206 throw(ex); ^ Error: tunneling socket could not be established, cause=139837791274784:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:787: at Object.Future.wait (/root/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:326:15)

Did I miss anything?

[xxronis]

got the same exact issue as @vikramrathore2512 , is it our npm config?

[jmanos3]

I would suggest trying a full install of 0.9.4 using the 'curl' method versus the 'meteor update' method and see if you get different results. On my Mac, the meteor update worked for me. However, on my Ubunutu and Enterprise Linux environments, I had to full install using curl.

If that does not fix the issue, you will need to identify how your proxies handle websockets. Back on Sep 12, I made a post in this issue log about a site to test websockets - http://www.websocket.org/echo.html. Try it and see what results you get.

Finally, double check that your HTTP_PROXY and HTTP_PROXYS environment variables are correct. There have been a few times in my testing I have incorrectly set them.

[glasser]

Do you know what proxy you are using?

[glasser]

Also, does meteor deploy work for you? (ie, just make an empty app and deploy it to a random site name.)

[glasser]

Also, does curl https://packages.meteor.com/ work for you?

[xc8tlik]

Could not springboard to release: METEOR@0.9.4-rc.6: could not download tool in meteor-tool@1.0.34-rc.8

This was a problem for me on Debian 6.0.8 (squeeze) until I changed my http_proxy and https_proxy variables from the form <proxy_ip>:<proxy_port> to http://<proxy_ip>:<proxy_port>. All the curl commands were perfectly happy with the former.

[vikramrathore2512]

The websockets echo test failed for me. I'll try to get that sorted and report back.

[xxronis]

Hi all, thanks for meteor!!

on my corporate ubuntu 12.04 machine:

updated meteor distribution usign curl proxy variables are correct curl https://packages.meteor.com/ works for me

but now i got another error for an app that surely works on my mac: please advise

$ todos/ $ meteor

/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:206
                        throw(ex);
                              ^
[object Object]
    at Object.Future.wait (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:326:15)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:534:31
    at Array.forEach (native)
    at Function._.each._.forEach (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:532:9
    ....
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:236:23
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at Object.capture (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:235:19)
    at main.registerCommand.name [as func] (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/commands.js:963:31)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/main.js:1255:23

Thanks

[jmanos3]

@xxronis,

Can you share a screenshot of what your environment variables are set to from your Ubuntu environment?

James

[glasser]

Did you insert that '....' yourself? It's cutting off the actually important part of the stacktrace.

[xxronis]

y sure

[kanna462488]

Hi

I am a newbie to meteor, have smilar issue like this,i am trying to run meteor on my ubutnu personal laptop i am getting following issue kanna@kanna-VPCEB3QFX:~/Desktop/testhtml5/testhtml5/testHTML$ sudo meteor

[sudo] password for kanna: [[[[[ ~/Desktop/testrschtml5/rschtml5/testHTML ]]]]]

=> Started proxy. => Started MongoDB. W20141017-13:19:19.659(5.5)? (STDERR) W20141017-13:19:19.737(5.5)? (STDERR) /home/kanna/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/nodemodules/fibers/future.js:173 W20141017-13:19:19.738(5.5)? (STDERR) throw(ex); W20141017-13:19:19.739(5.5)? (STDERR) ^ W20141017-13:19:19.739(5.5)? (STDERR) TypeError: Cannot call method 'add' of undefined W20141017-13:19:19.739(5.5)? (STDERR) at app/server/route.js:8:15 W20141017-13:19:19.740(5.5)? (STDERR) at app/server/route.js:930:3 W20141017-13:19:19.740(5.5)? (STDERR) at /home/kanna/Desktop/testhtml5/testhtml5/testHTML/.meteor/local/build/programs/server/boot.js:168:10 W20141017-13:19:19.740(5.5)? (STDERR) at Array.forEach (native) W20141017-13:19:19.741(5.5)? (STDERR) at Function..each._.forEach (/home/kanna/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11) W20141017-13:19:19.741(5.5)? (STDERR) at /home/kanna/Desktop/rschtml5/rschtml5/testhtml5/.meteor/local/build/programs/server/boot.js:82:5 => Exited with code: 8

please help me to slove this Best Regards kanna

[glasser]

@kanna462488 that does not seem to be a related issue. Please open a new issue

[glasser]

@xxronis Can you include the full stack trace?

[xxronis]

apologies, here is the full stack

/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:206
                        throw(ex);
                              ^
[object Object]
    at Object.Future.wait (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:326:15)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:534:31
    at Array.forEach (native)
    at Function._.each._.forEach (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:532:9
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:340:18
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:333:34
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:331:23
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at enterJob (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:307:26)
    at Object.forkJoin (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:503:3)
    at _.extend.downloadMissingPackages (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/tropohouse.js:314:18)
    at _.extend.setVersions (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/project.js:771:41)
    at _.extend._ensureDepsUpToDate (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/project.js:242:23)
    at _.extend.getVersions (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/project.js:551:10)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/commands.js:177:13
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:254:13
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:247:29
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:245:18
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:236:23
    at _.extend.withValue (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/fiber-helpers.js:112:14)
    at Object.capture (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/buildmessage.js:235:19)
    at doRunCommand [as func] (/home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/commands.js:176:31)
    at /home/user/.meteor/packages/meteor-tool/.1.0.34.1atmdl8++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/tools/main.js:1255:23

[glasser]

@xxronis Your issue is unrelated to this bug (it's not the connection that this bug is about); thanks for the report, I'm already planning to work on this error message today.

[xxronis]

Should i expect any updates on this one in this issue? This is my test app that fails only on my corp ubuntu https://github.com/xxronis/todos thanks a lot

[nicejwjin]

I got the same issue also but it runs well still. Any updates here? Error connecting to package server: DDP connection timed out

[glasser]

@nicejwjin Can you try with meteor --release 1.0-rc.8 ?

@xxronis It looked like your bug was an error downloading packages over HTTPS (not DDP). We haven't changed that code recently... Can you try with the 1.0 RC as well?

[jmanos3]

I just completed a test of 1.0-rc.8 on both Mac OS X 10.10 and Ubuntu 14.04. In both cases the communications through my SQUID3 proxy worked / acted appropriately.

In my testing I start my SQUID3 proxy and set my HTTPS_PROXY environment variable. I then test Meteor using the proxy. I then turn the proxy service off and test again. When the proxy service is down, meteor fails to communicate properly. When I turn the proxy service back on, all works as expected.