Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package System Support for Corporate Firewall Configurations #2515

Closed
jmanos3 opened this issue Sep 3, 2014 · 62 comments
Closed

Package System Support for Corporate Firewall Configurations #2515

jmanos3 opened this issue Sep 3, 2014 · 62 comments

Comments

@jmanos3
Copy link

@jmanos3 jmanos3 commented Sep 3, 2014

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
Copy link
Member

@glasser glasser commented Sep 5, 2014

On what operating system?

@jmanos3
Copy link
Author

@jmanos3 jmanos3 commented Sep 5, 2014

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

@gdon
Copy link

@gdon gdon commented Sep 5, 2014

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
Copy link
Member

@glasser glasser commented Sep 6, 2014

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

@jhuenges
Copy link

@jhuenges jhuenges commented Sep 11, 2014

Any Update?

@glasser
Copy link
Member

@glasser glasser commented Sep 12, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Sep 12, 2014

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
Copy link
Member

@glasser glasser commented Sep 12, 2014

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
Copy link
Member

@glasser glasser commented Sep 12, 2014

This PR to a library we use is a first step: faye/faye-websocket-node#30

@glasser
Copy link
Member

@glasser glasser commented Sep 12, 2014

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

@jmanos3
Copy link
Author

@jmanos3 jmanos3 commented Sep 12, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Sep 12, 2014

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
Copy link

@gdon gdon commented Sep 12, 2014

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
#2515 (comment).

@jmanos3
Copy link
Author

@jmanos3 jmanos3 commented Sep 12, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Sep 12, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Sep 30, 2014

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
Copy link
Member

@n1mmy n1mmy commented Oct 2, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Oct 2, 2014

Nick,

Thanks for reviewing and for the update - much appreciated.

James

@FIRE-BRAIN
Copy link

@FIRE-BRAIN FIRE-BRAIN commented Oct 7, 2014

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 added a commit that referenced this issue Oct 7, 2014
We want to support running DDP through a corporate proxy, but the
higher-level faye-websocket can't support that and won't be changed to
allow that: faye/faye-websocket-node#30

Fair enough. Let's just switch to the lower-level module, since we don't
care about getting a browser-compatible websocket API.

This is a first step towards fixing #2515.
glasser added a commit that referenced this issue Oct 9, 2014
We want to support running DDP through a corporate proxy, but the
higher-level faye-websocket can't support that and won't be changed to
allow that: faye/faye-websocket-node#30

Fair enough. Let's just switch to the lower-level module, since we don't
care about getting a browser-compatible websocket API.

This is a first step towards fixing #2515.
@glasser
Copy link
Member

@glasser glasser commented Oct 10, 2014

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
Copy link
Member

@glasser glasser commented Oct 10, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Oct 11, 2014

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

@glasser glasser closed this in fb7921a Oct 11, 2014
@n1mmy n1mmy reopened this Oct 11, 2014
@n1mmy
Copy link
Member

@n1mmy n1mmy commented Oct 11, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Oct 12, 2014

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
Copy link
Member

@glasser glasser commented Oct 13, 2014

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

@jmanos3
Copy link
Author

@jmanos3 jmanos3 commented Oct 15, 2014

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
Copy link
Member

@glasser glasser commented Oct 15, 2014

Do you know what proxy you are using?

@glasser
Copy link
Member

@glasser glasser commented Oct 15, 2014

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

@glasser
Copy link
Member

@glasser glasser commented Oct 15, 2014

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

@xc8tlik
Copy link

@xc8tlik xc8tlik commented Oct 16, 2014

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
Copy link

@vikramrathore2512 vikramrathore2512 commented Oct 16, 2014

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

@xxronis
Copy link

@xxronis xxronis commented Oct 16, 2014

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
Copy link
Author

@jmanos3 jmanos3 commented Oct 16, 2014

@xxronis,

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

James

@glasser
Copy link
Member

@glasser glasser commented Oct 16, 2014

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

@xxronis
Copy link

@xxronis xxronis commented Oct 17, 2014

y sure

screenshot from 2014-10-17 10 39 52

@kanna462488
Copy link

@kanna462488 kanna462488 commented Oct 17, 2014

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/node_modules/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
Copy link
Member

@glasser glasser commented Oct 17, 2014

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

@glasser
Copy link
Member

@glasser glasser commented Oct 17, 2014

@xxronis Can you include the full stack trace?

@xxronis
Copy link

@xxronis xxronis commented Oct 20, 2014

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
Copy link
Member

@glasser glasser commented Oct 20, 2014

@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
Copy link

@xxronis xxronis commented Oct 24, 2014

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
Copy link

@nicejwjin nicejwjin commented Oct 25, 2014

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

@glasser
Copy link
Member

@glasser glasser commented Oct 25, 2014

@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
Copy link
Author

@jmanos3 jmanos3 commented Oct 26, 2014

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.

@nicejwjin
Copy link

@nicejwjin nicejwjin commented Oct 26, 2014

@glasser I've tested it on the 1.0-rc.8 version and it works fine.
But I'm wondering to know it would be working well continuously because the issue was occurred frequently, not always also.
I'll let you know if I got some data about this~

@xxronis
Copy link

@xxronis xxronis commented Nov 4, 2014

In the end i was getting the error:14077410:SSL routines:SSL23_GET_SERVER_HELLO output...
with version 1.0
Finally i got this working in the corp ubuntu, by setting the $HTTP_PROXY to a non https location! like

export HTTPS_PROXY=http://proxy.<company>:8080/

following http://stackoverflow.com/a/26612808/1735250.

But why?
Cheers

@jmanos3
Copy link
Author

@jmanos3 jmanos3 commented Nov 6, 2014

@xxronis - I do not have a direct answer to the question of why. However, I have the same situation in that the corporate proxy for both HTTP and HTTPS traffic are HTTP internally - meaning my $HTTP_PROXY and $HTTPS_PROXY environment variables point to the same place - http://servername:port. In fact, in my testing, I only had to set the $HTTPS_PROXY environment variable for Meteor to connect properly through the corporate proxy.

@glasser
Copy link
Member

@glasser glasser commented Nov 11, 2014

@xxronis What this means is: it's the HTTPS_PROXY because it's what we use in order to make a connection to Meteor's secure https package server. But you put the http value into it because your company's proxy server exposes a non-secure http interface. So this is working as expected.

@xxronis
Copy link

@xxronis xxronis commented Nov 11, 2014

Thanks for the detailed explanation @glasser !

@normanhh3
Copy link

@normanhh3 normanhh3 commented Dec 10, 2014

I just installed the latest Meteor release 1.0.1 via curl with the appropriate http(s)_proxy (also added HTTP(S)_PROXY - upper-case) environment variables set and working (successful curl install).

I am getting the following stack trace trying to do ANYTHING with meteor at the moment.

meteor create --example localmarket

/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:206
                        throw(ex);
                              ^
Error: tunneling socket could not be established, cause=socket hang up
    at Object.Future.wait (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/dev_bundle/lib/node_modules/fibers/future.js:326:15)
    at _.extend._createSocket (packages/ddp/stream_client_nodejs.js:265)
    at _.extend._launchConnection (packages/ddp/stream_client_nodejs.js:142)
    at new LivedataTest.ClientStream (packages/ddp/stream_client_nodejs.js:28)
    at new Connection (packages/ddp/livedata_connection.js:52)
    at Object.DDP.connect (packages/ddp/livedata_connection.js:1581)
    at new ServiceConnection (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/service-connection.js:54:37)
    at Object.exports.openServiceConnection (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/auth-client.js:24:10)
    at openPackageServerConnection (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/package-client.js:24:21)
    at _updateServerPackageData (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/package-client.js:122:14)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/package-client.js:100:12
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:313:18
    at _.extend.withValue (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:312:36
    at _.extend.withValue (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at Object.enterJob (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:303:26)
    at Object.exports.updateServerPackageData (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/package-client.js:99:23)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog-remote.js:767:36
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:313:18
    at _.extend.withValue (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:312:36
    at _.extend.withValue (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at Object.enterJob (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:303:26)
    at _.extend.refresh (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog-remote.js:766:18)
    at _.extend.refreshOfficialCatalog (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog.js:390:23)
    at Object.catalog.refreshOrWarn (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog.js:60:22)
    at catalog.Refresh.OnceAtStart.beforeCommand (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/catalog.js:33:16)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/main.js:1349:32
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:313:18
    at _.extend.withValue (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:312:36
    at _.extend.withValue (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/fiber-helpers.js:112:14)
    at Object.enterJob (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/buildmessage.js:303:26)
    at /Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/tools/main.js:1348:20
    - - - - -
    at ClientRequest.onError (/Users/nharebottl/.meteor/packages/meteor-tool/.1.0.36.690ab6++os.osx.x86_64+web.browser+web.cordova/meteor-tool-os.osx.x86_64/isopacks/ddp/npm/node_modules/tunnel-agent/index.js:168:17)
    at ClientRequest.g (events.js:180:16)
    at ClientRequest.emit (events.js:95:17)
    at CleartextStream.socketErrorListener (http.js:1547:9)
    at CleartextStream.emit (events.js:95:17)
    at SecurePair.<anonymous> (tls.js:1395:15)
    at SecurePair.emit (events.js:95:17)
    at SecurePair.error (tls.js:1015:27)
    at EncryptedStream.CryptoStream._done (tls.js:700:22)
    at CleartextStream.read [as _read] (tls.js:496:24)
    at CleartextStream.Readable.read (_stream_readable.js:323:10)
    at EncryptedStream.onCryptoStreamFinish (tls.js:301:47)
    at EncryptedStream.g (events.js:180:16)
    at EncryptedStream.emit (events.js:117:20)
    at finishMaybe (_stream_writable.js:360:12)
    at endWritable (_stream_writable.js:367:3)
    at EncryptedStream.Writable.end (_stream_writable.js:345:5)
    at EncryptedStream.CryptoStream.end (tls.js:638:31)
    at Socket.onend (_stream_readable.js:485:10)
    at Socket.g (events.js:180:16)
    at Socket.emit (events.js:117:20)
    at _stream_readable.js:929:16
    at process._tickCallback (node.js:419:13)

My firewall is a Cisco IronPort Cisco-WSA/8.0.6-119. The Cisco proxy may be doing SSL connection rewriting on this particular connection - I do NOT know for sure, I have seen it do it on other SSL encrypted connections. 👎

In ~/.npmrc strict-ssl = false was set according to https://docs.npmjs.com/misc/config but that didn't seem to make any difference.

The WebSocket tests at: http://www.websocket.org/echo.html worked just fine.

I was also able to successfully access the login button url listed previously.

Thoughts?

@jmanos3
Copy link
Author

@jmanos3 jmanos3 commented Dec 10, 2014

@normanhh3 ,

I just tested this and it worked fine in my corporate environment.

Not sure what to say at this point.

james

@glasser
Copy link
Member

@glasser glasser commented Dec 11, 2014

.npmrc shouldn't be relevant at all here.

Maybe your env vars are configured wrong? Most users have found that they want to set HTTPS_PROXY (with s) to an URL that has an http:// URL (no s).

@normanhh3
Copy link

@normanhh3 normanhh3 commented Dec 11, 2014

I'll try that trick, thanks for the pointer.

On Thu, Dec 11, 2014 at 12:57 PM, David Glasser notifications@github.com
wrote:

.npmrc shouldn't be relevant at all here. Maybe your env vars are
configured wrong? Most users have found that they want to set HTTPS_PROXY
(with s) to an URL that has an http:// URL (no s).


Reply to this email directly or view it on GitHub
#2515 (comment).

@normanhh3
Copy link

@normanhh3 normanhh3 commented Dec 11, 2014

Looks like that did the trick with my corporate firewall as well. Thanks
for the pointer!

On Thu, Dec 11, 2014 at 3:07 PM, Norman Harebottle III normanh@gmail.com
wrote:

I'll try that trick, thanks for the pointer.

On Thu, Dec 11, 2014 at 12:57 PM, David Glasser notifications@github.com
wrote:

.npmrc shouldn't be relevant at all here. Maybe your env vars are
configured wrong? Most users have found that they want to set HTTPS_PROXY
(with s) to an URL that has an http:// URL (no s).


Reply to this email directly or view it on GitHub
#2515 (comment).

@liuxihua
Copy link

@liuxihua liuxihua commented May 26, 2016

when i install the bootstrap with meteor in windows 7. And, i worked behind a proxy, and i already do as what https://github.com/meteor/meteor/wiki/Using-Meteor-behind-a-proxy said.

when i use "meteor update", it works fine,

when I install packages , got a error like below :

C:\Studio\microscope>meteor add  twbs:bootstrap@3.3.6

Unable to update package catalog (are you offline?)

If you are using Meteor behind a proxy, set HTTP_PROXY and HTTPS_PROXY
environment variables or see this page for more details:
https://github.com/meteor/meteor/wiki/Using-Meteor-behind-a-proxy

=> Errors while adding packages:

While downloading twbs:bootstrap@3.3.6...:
error: UNABLE_TO_VERIFY_LEAF_SIGNATURE

Your package catalog may be out of date.
Please connect to the internet and try again.

when i use npm it works fine, because i set the proxy and set the "strict-ssl = false" also in the npm config (.npmrc).

So what should i do to fix this problem, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
14 participants