Error 'tunneling socket' while executing npm install - npm

I'm getting the error shown below while trying to execute 'npm install' command.
Error: tunneling socket could not be established, cause=connect ECONNREFUSED 10.232.207.137:8080
What do I miss?

If you are behind a proxy, set it correctly in npm.
>npm config set proxy http://proxyhost:proxyport
>npm config set https-proxy http://proxyhost:proxyport
Notes:
For SSL/https proxies, the protocol in URL should be http not https
If your set up is on a Docker/Vagrant instance or a hosted VM, use IP address instead of hostname for proxy as the later might not be resolvable.
If there is no proxy , remove proxy config from npm
>npm config set proxy null
>npm config set https-proxy null

I know this is way too late but if someone has a similar issue in the future and you are sure you have no proxy set but you have an environment variable called http_proxy. Please delete it and try again. I had set a proxy for Fiddler.

according to this it's proxy isssues, try to disable ssl and set registry to http instead of https . hope it helps!
npm config set registry=http://registry.npmjs.org/
npm config set strict-ssl false

Following commands may solve your issue:
npm config set proxy false
npm cache clean
It solved my same issue.

In my case helped delete .npmrc config file
rm ~/.npmrc

Removing the proxy settings resolved the issue:
If you are no using any proxy:
npm config rm proxy
npm config rm https-proxy
If you are using Proxy:
npm config set proxy http://proxyhostname:proxyport
npm config set https-proxy https://proxyhostname:proxyport
Hopefully this will solve your problem :)

remember to set you username and password if required:
http://USERNAME:passwd#proxyserver.co.uk:8080
Example:
npm config set proxy http://USERNAME:passwd#proxyserver.co.uk:8080

If in case you are using ubuntu trusty 14.0 then search for Network and select Network Proxy and make it none. Now proxy may still be set in system environment variables. check
env|grep -i proxy
you may get output as
http_proxy=http://192.168.X.X:8080/
ftp_proxy=ftp://192.168.X.X:8080/
socks_proxy=socks://192.168.X.X:8080/
https_proxy=https://192.168.X.X:8080/
unset these environment variable as:
unset(http_proxy)
and in this way unset all. Now run npm install ensuring user must have permission to make node_modules folder where you are installing module.

Next to what has described #Roshith in his answer here:
If you are behind a proxy, set it correctly in npm.
npm config set proxy http://proxyhost:proxyport
npm config set https-proxy http://proxyhost:proxyport
I had to change also the file ~.bashrc which also contained a wrong proxy setting in my case. I changed those settings here:
export HTTP_PROXY="http://proxyhost:proxyport"
export HTTPS_PROXY="http://proxyhost:proxyport"
Use the following command to verify the proxy settings:
env | grep -i proxy

An important point to remember is if you're behind a corporate firewall and you get you're corporate proxy settings from a .pac file, then be sure to use the value for global proxy.

I lost a day trying to make this work.
Worked with this steps.
I opened Fiddler and checked the option Rules > Automatically Autenticate.
After, search for file .npmrc, usually in c:\users\ and used it as configuration:
registry=https://registry.npmjs.org/
proxy=http://username:password#127.0.0.1:8888
https-proxy=http://username:password#127.0.0.1:8888
http-proxy=http://username:password#127.0.0.1:8888
strict-ssl=false
ca=null
Hope help someone!

I also ran into the similar issue and was using CNTLM for proxy configuration. In my case HTTP_PROXY and HTTPS_PROXY are taking higher precedence over http_proxy and https_proxy so be aware of changing all proxy variables.
env|grep -i proxy
and make sure all of the below proxy variables should point to the same proxy.
HTTP-PROXY = "http://localhost:3128"
HTTPS-PROXY = "https://localhost:3128"
HTTPS_PROXY = "http://localhost:3128"
HTTP_PROXY = "http://localhost:3128"
PROXY = "http://localhost:3128"
http-proxy = "http://localhost:3128"
http_proxy = "http://localhost:3128"
https-proxy = "https://localhost:3128/"
https_proxy = "https://localhost:3128"
proxy = "http://localhost:3128/"
I know some variables are unneccessary but I'm not sure which is using what.

I had this same error when trying to install Cypress via npm. I tried many of the above solutions as I am behind a proxy, but was still seeing the same error. In the end I found that my WIndows system configuration(can be checked by entering 'set' in command prompt) had HTTP and HTTPS proxys set that differed from the ones vonfigure in npm. I deleted these proxys and it downloaded staright away.

I have faced similar issue and none of the above solution worked as I was in protected network.
To overcome this, I have installed "Fiddler" tool from Telerik, after installation start Fiddler and start installation of Protractor again.
Hope this will resolve your issue.
Thanks.

If you using gnome, and turned off the proxy at the network level, you also need to make sure you don't have proxy enabled in your terminal
➜ gconftool-2 -a /system/http_proxy
host = http://localhost/
port = 2000
use_http_proxy = false
use_authentication = false
authentication_password =
authentication_user =
ignore_hosts = [localhost,127.0.0.0/8]
You can drop it with
gconftool-2 -t string -s /system/http_proxy/host ""
gconftool-2 -u /system/http_proxy/port
gconftool-2 -u /system/http_proxy/host
unset http_proxy

After looking at all of the answers, the one that helped me was providing proxy values in-line with the install command. One of my frustrations was adding the domain to my username. This is not needed. I used the following example to install a specific version of Angular:
npm install -g #angular/cli#1.7.3 --proxy "http://username:password#proxy_server:proxy_port" --registry http://registry.npmjs.org

I spent days trying all the above answers and ensuring I had the proxy and other settings in my node config correct. All were and it was still failing. I was/am using a Windows 10 machine and behind a corp proxy.
For some legacy reason, I had HTTP_PROXY and HTTPS_PROXY set in my user environment variables which overrides the node ones (unknown to me), so correcting these (the HTTPS_PROXY one was set to https, so I changed to HTTP) fixed the problem for me.
This is the problem when we can have the Same variables in Multiple places, you don't know what one is being used!

npm config set registry http://registry.npmjs.org/
above code solved my issue :)

I faced similar and tried some of the techniques mentioned here. To overcome,
I performed a cleanup of duplicate entries in c:\users\<user name>\.npmrc
Hope it helps someone.
Thanks,

If you are using a VPN on a secure network (like a VPN for working-from-home), you may have an issue with permissions. For me, I solved this using sudo to initialize a ReactJS development environment...
sudo npm install

If you're trying all of the above and still having issues, make sure your local path does not contain spaces. (There are ways to allow spaces but mine wasn't set up that way.) In my case, I was using MAMP with a Server Document root of /Users/myusername/My Site. Changing this to /Users/myusername/My-Site resolved the issue.

For windows
If you are not using any proxy (search proxy in start menu search bar to see settings) then
npm config set proxy null
npm config set https-proxy null
npm cache clean
If above does not work, you might need to do it by force, but only if you are sure cache clean does not cause any other installation problem for you
npm cache clean --force
delete http_proxy from environment variables
Try now and it should be fine

Related

Minishift: Could not resolve: *.192.168.64.2.nip.io

I have installed minishift on OSX with brew:
brew cask install minishift-beta
...
$ minishift version
Minishift version: 1.0.0
I have sucessfuly started minishift, and created node-ex example application and exported it:
$ oc get route
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
nodejs-ex nodejs-ex-myproject.192.168.64.2.nip.io nodejs-ex 8080-tcp None
However I can not reach .192.168.64.2.nip.io:
$ curl nodejs-ex-myproject.192.168.64.2.nip.io
curl: (6) Could not resolve host: nodejs-ex-myproject.192.168.64.2.nip.io
$ dig +short nodejs-ex-myproject.192.168.64.2.nip.io
$
All is working with minishift web console and oc command, but I can not reach the application domain.
Thank you #enj. The explanation at http://nip.io is clear about how it works.
I have seen that queries to 8.8.8.8 and to my ISP DNS are resolved to my private IP. But it is my router (my primary DNS) which do respond nip.io
My router run DD-WRT and has enabled
Rebind protection Discard upstream RFC1918 responses
then I add nip.io at
Domain whitelist nip.io
and now I resolve queries:
≻ dig +short test.10.0.0.1.nip.io
10.0.0.1
Is something on your machine or network blocking DNS queries to nip.io?
When playing with Minishift at home, where I am connected to the internet via Deutsche Telekom's VDSL and Speedport-Router, I cannot resolve these xip.io or nip.io addresses.
My workaround is to put 8.8.8.8 into /etc/resolv.conf
I had the same issue on Windows 10. My workaround was to add an entry in C:\Windows\System32\drivers\etc\hosts file. Here is an example
192.160.90.101 nodejs-ex-nodejs-echo.192.160.90.101.nip.io # needed for minishift to work

Apache script config with loggly

I am trying to configure loggly in apache in my ubuntu machine.
What I have done is
curl -O https://www.loggly.com/install/configure-apache.sh
sudo bash configure-apache.sh -a XXXXXX -u XXXXXX
After entering the last line it's saying
ERROR: Apache logs did not make to Loggly in time. Please check network and firewall settings and retry.
Manual instructions to configure Apache2 is available at https://www.loggly.com/docs/sending-apache-logs/. Rsyslog troubleshooting instructions are available at https://www.loggly.com/docs/troubleshooting-rsyslog/
Any idea why it's showing and how to solve it?
This is likely a network issue or a delay in sending the logs or even an issue with the script. Check out the following link that has the manual instructions. https://www.loggly.com/docs/sending-apache-logs/ that you can follow and use to verify the script created the configuration files correctly.

svn:// not working but http:// is

If I try to checkout a repo from a Debian server via svn://example.com/svn/repo I get the following error:
Unable to connect to a repository at URL
'svn://example.com/svn/repo'
No repository found in 'svn://example.com/svn/repo'
I get the same same error when trying to checkout from the server via the shell.
It works if I use "http://example.com/svn/repo" and the repo definitely exists.
svnserve is running as a daemon listening on port 3690 (UDP/TCP).
What am I missing?
I am pretty sure that you are accessing the wrong URL. Note that the path component of the svn:// URL (srv/repo in your case) is interpreted relative to what you pass to the -r argument of svnserve.
Other possible reasons are:
svnserve is not configured properly,
there is a firewall in the way.
I know it has been already answered but for future references, enabling port 3690 in firewall worked for me.
firewall-cmd --zone=public --add-port=3690/tcp --permanent
firewall-cmd --zone=public --add-port=3690/udp --permanent
firewall-cmd --reload

Jenkins - j_acegi_security_check

I am trying to setup jenkins, but I cant get the authentication to work. I am running jenkins on Tomcat6 on CentOS 6.2. I enable logging in, and everything goes fine until I try to log in. After giving my credential and pressing login, tomcat gives me a error:
"HTTP Status 404 - The requested resource () is not available." on http://myserver:8080/jenkins/j_acegi_security_check
By googling I can find this:
https://issues.jenkins-ci.org/browse/JENKINS-3761
Two suggested fixes I have found:
Run jenkins on tomcat instead of running the standalone version - I
am already doing so.
Edit a file: WEB-INF/security/SecurityFilters.groovy - I tried to
edit, but I can't get it to change anything
Is there something I could do to make this work?
Spent ages wrestling with this one, make sure a Security Realm is set when you are choosing your Authorization method in Jenkins.
That is, in Manage Jenkins → Configure Global Security select an option in the Security Realm list.
For example:
You may have forgotten to select a Security Realm as specified below
https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup
In case you have locked yourself out, you can revert the Jenkins config.xml file to set <useSecurity>true</useSecurity> node value to false by following instructions here
https://wiki.jenkins-ci.org/display/JENKINS/Disable+security
As mentioned on the bug page:
The error was caused by a proxy pass rule "/jenkins http://localhost:9080/jenkins/" which led to the incomming (jenkins) request "/jenkins//j_acegi_security_check" (double //). So the login page was rejected with 404 (while all other pages where served).
Make sure your /jenkins ProxyPass does not end with a trailing slash in the destination URL.
I had the same problem with 404 on the "/jenkins/j_acegi_security_check" page.
Using Jenkins with Tomcat, after a lot of tries to solve it, I came to following solution - I´m using 18080 as default port without SSL-redirection.
It´s related to the redirection, but in that case (as using Tomcat) it has to be changed in the tomcat-server-configuration:
Look in /conf/server.xml for the following entry:
<Connector port="18080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Just commenting out the redirectPort helped for me:
<Connector port="18080" protocol="HTTP/1.1"
connectionTimeout="20000" />
I had the same HTTP 404 on the "/jenkins/j_acegi_security_check" URI problem .
And the same issue as pointed out by pga above: Tomcat was being started as user root.
This was because I had setup tomcat to restart automatically by creating a startup tomcat script at "/etc/init.d/".
Fixed the issue with:
su - tomcatuser - c /cde/pkgs/../tomcat/start.sh
I was facing the same issue on Ubuntu as well as on AIX, where I desperately needed it to work in production settings. I even tried Tomcat and Apache web servers, still the same issue.
Finally changing the class loader as follows made it work in stand-alone mode:
java -jar jenkins.war --httpPort=79802 --preferredClassLoader=java.net.URLClassLoader &
By the way, this is default settings in standard Jenkins distribution for Ubuntu, from where I got the clue.
Probably the issue is related with packaging, but for now this solution works. Check if this resolves similar issues.
My bookmarked jenkins login url was: https://jenkins.foo.com/login?from=%2F
If security is disabled and you hit that url with any credentials or blank ones, it brings up the j_acegi error.
Instead, use https://jenkins.foo.com/ and it will take you straight to the dashboard.
I had the same HTTP 404 on the "/jenkins/j_acegi_security_check" URI.
In my case, Jenkins was running on a Tomcat started by user 'root'. Stopped Tomcat, and started it again by the proper separate application user. Problem solved.
Seeing vote down: I did the steps again on fresh server.
There were ** characters and I removed that
There were missing $sign for tomcat like this $TOMCAT_VERSION
(Both corrected and it is working) (updated on 28.03.2016)
Disable the security as given below:
http://markunsworth.com/2012/02/13/locked-yourself-out-of-jenkins/
Unable to login jenkins, and can't disable login option either
Or
Locked in login with Jenkins on Tomcat.
http://xx.xxx.xxx.xxx:8080/jenkins/login?from=/jenkins/ and after filling the userId Password, which was not set up at all, will always take to this page
http://xx.xxx.xxx.xxx:8080/jenkins/j_acegi_security_check
HTTP Status 404 - description The requested resource is not available.
I had .war file installed in tomcat
It took me long to fix this issue.
I had many times completely removed Tomcat, Jenkins all folders .jenkins etc reinstalled and what not...
Remove both Tomcat and Jenkins completely once again...
The solution is proper use of user and group, let us see how to it by running the following commands one by one.
You are logged in with user(e.g. vimal) with sudo permission.
vimal#h123:~$ sudo apt-get update
vimal#h123:~$ BASE_USER=vimal
vimal#h123:~$ sudo chown -Rf $BASE_USER:$BASE_USER /opt/
vimal#h123:~$ USER=apache-tomcat
vimal#h123:~$ GROUP=myjenkins
vimal#h123:~$ TOMCAT_INSTALL_DIR=/opt
vimal#h123:~$ TOMCAT_VERSION=apache-tomcat-8.0.23
vimal#h123:~$ TOMCAT_URL=http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.23/bin/apache-tomcat-8.0.23.zip
For TOMCAT_URL, copy the link that you need from archive/src (.zip) of tomcat download site
vimal#h123:~$ mkdir -p $TOMCAT_INSTALL_DIR
vimal#h123:~$ cd $TOMCAT_INSTALL_DIR
vimal#h123:~$ wget $TOMCAT_URL
vimal#h123:~$ unzip -q $TOMCAT_VERSION.zip
vimal#h123:~$ rm $TOMCAT_VERSION.zip
Before running command below you need to have JAVA_HOME set up in like JAVA_HOME="/usr/lib/jvm/java-8-oracle/" by adding this into
sudo nano /etc/environment
vimal#h123:~$ sudo chmod +x $TOMCAT_INSTALL_DIR/$TOMCAT_VERSION/bin/*.sh
vimal#h123:~$ $TOMCAT_INSTALL_DIR/$TOMCAT_VERSION/bin/catalina.sh start
vimal#h123:~$
vimal#h123:~$ cd $TOMCAT_INSTALL_DIR/$TOMCAT_VERSION/webapps/
vimal#h123:~$ wget http://mirrors.jenkins-ci.org/war-stable/latest/jenkins.war
Wait for a couple of minutes till Jenkins is fully loaded. Needs 2GB memory.
Try going to the browser on http://xx.xxx.xxx.xxx:8080/jenkins/ and it will work...
Took me one day to find the solution.
Here is how I resolved this issue:
# service tomcat status
tomcat start/running, process 996
# service tomcat stop
tomcat stop/waiting
# service jenkins status
Jenkins Continuous Integration Server is not running
# service jenkins restart
* Restarting Jenkins Continuous Integration Server jenkins [ OK ]
# service tomcat start
tomcat start/running, process 3839
# service jenkins status
Jenkins Continuous Integration Server is running with the pid 3694
Refresh your browser and Jenkins should be up and running.
Hope this helps!

fabric appears to start apache2 but doesn't

I'm using fabric to remotely start a micro aws server, install git and a git repository, adjust apache config and then restart the server.
If at any point, from the fabfile I issue either
sudo('service apache2 restart') or run('sudo service apache2 restart') or a stop and then a start, the command apparently runs, I get the response indicating apache has started, for example
[ec2-184-73-1-113.compute-1.amazonaws.com] sudo: service apache2 start
[ec2-184-73-1-113.compute-1.amazonaws.com] out: * Starting web server apache2
[ec2-184-73-1-113.compute-1.amazonaws.com] out: ...done.
[ec2-184-73-1-113.compute-1.amazonaws.com] out:
However, if I try to connect, the connection is refused and if I ssh into the server and run
sudo service apache2 status it says that "Apache is NOT running"
Whilst sshed in, if run
sudo service apache start, the server is started and I can connect. Has anyone else experienced this? Or does anyone have any tips as to where I could look, in log files etc to work out what has happened. There is nothing in apache2/error.log, syslog or auth.log.
It's not that big a deal, I can work round it. I just don't like such silent failures.
Which version of fabric are you running?
Have you tried to change the pty argument (try to change shell too, but it should not influence things)?
http://docs.fabfile.org/en/1.0.1/api/core/operations.html#fabric.operations.run
You can set the pty argument like this:
sudo('service apache2 restart', pty=False)
Try this:
sudo('service apache2 restart',pty=False)
This worked for me after running into the same problem. I'm not sure why this happens.
This is an instance of this issue and there is an entry in the FAQ that has the pty answer. Unfortunately on CentOS 6 doesn't support pty-less sudo commands and I didn't like the nohup solution since it killed output.
The final entry in the issue mentions using sudo('set -m; service servicename start'). This turns on Job Control and therefore background processes are put in their own process group. As a result they are not terminated when the command ends.
When connecting to your remotes on behalf of a user granted enough privileges (such as root), you can manage system services as shown below:
from fabtools import service
service.restart('apache2')
https://fabtools.readthedocs.org/en/0.13.0/api/service.html
P.S. Its requires the installation of fabtools
pip install fabtools
Couple of more ways to fix the problem.
You could run the fab target with --no-pty option
fab --no-pty <task>
Inside fabfile, set the global environment variable always_use_pty to False, before your target code executes
env.always_use_pty = False
using pty=False still didn't solve it for me. The solution that ended up working for me is doing a double-nohup, like so:
run.sh
#! /usr/bin/env bash
nohup java -jar myapp.jar 2>&1 &
fabfile.py
...
sudo("nohup ./run.sh &> nohup.out", user=env.user, warn_only=True)
...