Skip to main content

I am just getting started setting up a testing environment for working with the RC API. One of the first steps was to get the JavaScript SDK (https://github.com/ringcentral/js-sdk) on my development server. I already have npm and Bower working, so the installation should have been a breeze... I would attempt it and kept getting: github.com[0: 192.30.252.128]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) After doing some research, I realized that as a normal practice, I pull from Git using the https protocol. Also, using the git protocol requires a port be open on the firewall (tcp/9418, udp/9418). My solution was to inform git to always use the https protocol when it encounters the git protocol. You can set that by adding a global setting to git:

git config --global url."https://".insteadOf git://

You can also manually edit your .gitconfig file to include these two lines:

[url "https://"]          insteadOf = git://

Only downside is that the https protocol is a bit slower than the git protocol. Hope that helps someone. Jim

Thanks for the share Jim.

I typically utilize an .ssh/config file which allows me to have multiple sets of keys dedicated to particular services. Then I can just use Github to register those SSH keys. I see your issue if the firewall is blocking the port that 'git' uses.

If you have the ability to add IP rules for your firewall, here is a helpful Stackoverflow issue which says port TCP 9418 is sufficient to open if you want to use the git protocol.

Since port 443 is typically open to nearly every firewall, it can make easier to just use the SSL (https) protocol to save time and headache.
Agreed, Ben, on the ssh configuration. I do that as well. And yes, I was in a hurry earlier (normal speed), but I fixed up the firewall. As far as SSL goes, it is becoming more the rule rather than the exception for most web access with folks' privacy concerns. (Warning! Soapbox) I still find, though, so many "broken locks" where the developers don't take the extra effort to make their code base secure. Now it is time for third party code providers to follow suit a bit better. Personally, I am dealing with a large corporation whose "widget" a client wants. While their web site is SSL-secured, they have a "we'll get around to it" attitude about what they want others to put up (which I won't). (End Soapbox) I am very glad that RC supports SSL! Jim

Reply


Terms & ConditionsCookie settings