When I try to install yarn, I've got the following output:
Internal Error: Error when performing the request
at ClientRequest.<anonymous> (C:\Program Files\nodejs\node_modules\corepack\dist\corepack.js:3937:20)
at ClientRequest.emit (node:events:390:28)
at TLSSocket.socketErrorListener (node:_http_client:447:9)
at TLSSocket.emit (node:events:390:28)
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
TL;DR
Create a custom CA certificate file (in this example c:\temp\combo.ca.cer) containing BASE64-encoded DERs of all certs your corporate network security solution is presenting to Node.js when Node.js makes HTTPS requests
I used advice from https://stackoverflow.com/a/44726189 to create my custom CA cert file
set NODE_EXTRA_CA_CERTS=c:\temp\combo.ca.cer
corepack enable
yarn set version stable
Root Cause Analysis
I had the "Internal Error: Error when performing the request" at "corepack.js:3937:20" like everyone who's been here so I looked in line 3937 and discovered it was a vanilla https.get call. I stuck in some extra debugging into corepack.js to see what was being accessed and discovered it was failing trying to reach "https://registry.npmjs.com/pnpm".
I navigated to "https://registry.npmjs.com/pnpm" in my web browser and discovered my corporate environment let it load up with no errors. So I fired up Node JS and issued to see what would happen:
https.get("https://registry.npmjs.com/pnpm", {}, res => console.log(res));
I received a "unable to get local issuer certificate" error. In my corporate environment, there's a security solution that injects it's own self-signed certificates into responses from any outbound https requests. What that means for me is that I need to instruct anything issuing https requests (eg Node.js and curl) to use a custom CA certificate file.
To get corepack to work, I first hard-coded a custom CA certificate file into corepack.js and while it's pretty ugly, it did work. A bit of further digging around I found the NODE_EXTRA_CA_CERTS environment variable option used by Node.js so also tried the following in a Administrator-privileged cmd session with success (also removing the corepack.js hack I made earlier):
set NODE_EXTRA_CA_CERTS=c:\temp\combo.ca.cer
corepack enable
yarn set version stable
The combo.ca.cer was constructed by navigating to https://registry.npmjs.com/pnpm and exporting all the CA certs (root and any intermediate CA certs) to text files and copy-pasting the contents of all the CA cert files into a single text file called combo.ca.cer. I used advice from https://stackoverflow.com/a/44726189 to create my custom CA cert file.
As part of the initial setup of a work computer, I got this same error. Even a clean run of yarn (yarn init -2 in an empty folder) would cause the error.
Turning off my VPN made yarn work as expected.
Googling the error lead me to this page which got me to suspect the VPN. https://github.com/nodejs/corepack/issues/67
I had the same problem and for me it was solved by running yarn set version stable.
Using the following installation on Ubuntu Server 20.04 :
sudo apt-get update
sudo apt-get install nodejs
sudo apt install python2
sudo apt install npm
npm install ganache-cli
npm install node-gyp#3.6.2
npm install truffle#5.1.39
sudo npm install create-react-app#3.3.1 -global
npm install
I am having the error
Failed to load resource: net::ERR_CONNECTION_REFUSED 127.0.0.1:8545/:1
I am running ganache with the command line interface:
I can test the connection via node command prompt
To which I am able to verify a connection to ganache private blockchain
Then I try App.js in React
obtaining the following error:
I have tried the following:
1.) Setting up a proxy under package.json : http://127.0.0.1:8545
2.) Trying http://0.0.0.0:8545
3.) Setting up a middleware proxy account as presented in the following solution:
https://medium.com/bb-tutorials-and-thoughts/react-how-to-proxy-to-backend-server-5588a9e0347
"proxy": "http://127.0.0.1:8545"
4.) addressing cache related issues through rm -r package-lock.json node_modules and npm install updating react.js to latest version
5.) trying different port: 7545
6.) updating react to latest version on ubuntu
I figured it out - thanks to all who reviewed my problem. - hopefully this will help someone in the same situation. To connect to an ec2 instance with React.js / blockchain dapp you need to follow five steps:
1.) set appropriate security rules (you will need to allow access for an instance to reach your server) I set the following rules in a very liberal fashion since this was only a test:
you need to start ganache with explicit chainId specified and a direct reference to your public domain IPv4 DNS domain e.g (
http://ec2-54-186-149-26.us-west-2.compute.amazonaws.com)
the command should look as follows:
3.) the same domain mnemonic needs to be specified in metamask (along with an imported account from your ganache server ) It should look as follows:
4.) React.js also needs to access the domain from EC2 directly (do not use localhost ,even you are running on the server the loopback will not work! - also do not use a shortcut with or (||) condition as that also produced errors for me ). It should look similar to below:
5.) your smart contracts also need this domain specified explicitly - so you will also need to edit your truffle-config.js as follows:
Finally i can read my blockchain via React.js on a test network (ganache) via EC2.
Below is blockchain data presented to screen.
I hope this helps someone out there - this was not found easily.
regards
John D.
Google compute engine console return 399 error code already asks my question but the solution is not as suggested there. Since the URL is little old starting a new thread.
I am trying to do a wget using:
wget https://console.developers.google.com/m/cloudstorage/b/m-lab/o/ndt/2012/05/23/20120523T000000Z-mlab1-ams01-ndt-0000.tgz
I see the error:
Resolving console.developers.google.com (console.developers.google.com)... 216.239.32.27
Connecting to console.developers.google.com (console.developers.google.com)|216.239.32.27|:443... connected.
HTTP request sent, awaiting response... 399 Internal Server Error
2014-08-26 20:02:18 ERROR 399: Internal Server Error.
I am new to Linux commands so wanted to know if am missing something obvious.
The address works when I use Chrome downloader but fails with wget with me as well
I have never seen this behaviour before
You can also use cURL to download files, I used the -v switch and got a dns error(no idea why)
curl -v http://console.developers.googlO.com/m/cloudstorage/b/m-lab/o/ndt/2012/05/23/20120523T000000Z-mlab1-ams01-ndt-0000.tgz
We cannot download with traditional tools we have to use gsutil utility provided by google, using which automation is possible.
You need to use the following URI pattern:
http://storage.googleapis.com/<bucket>/<object>
In this case, you can download that file using the command:
wget http://storage.googleapis.com/m-lab/ndt/2012/05/23/20120523T000000Z-mlab1-ams01-ndt-0000.tgz
Trying to run my web2py app from the development server using GoogleAppEngineLauncher
Not sure if the on-line tutorials are out of date or I'm just missing something, but when I follow the link to download the GoogleAppEngine pythonSDK for OSX I get a dmg for the GoogleAppEngineLauncher.
I download and use that, which installs the proper executables, however after I setup my app.yaml file and run "dev_appserver.py myApp" I get this error:
fancy_urllib.InvalidCertificateException: Host appengine.google.com returned an invalid certificate (_ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed):
I don't get the error if I try and launch the app from the launcher itself, however I can't launch the app because it says the directory already exists and I don't have write permissions. I even tried chmod 777 on the myApp directory.
Should I not be using the GoogleAppLauncher?
additionally I tried using the linux SDX and received the same "certificate" error. The error message directs me to a link mentioning that I need the "ssl" module, but that is included in python 2.7.2 which I am using.
The link also mentions: "appcfg uses SSL when connecting to the Admin Console by default, unless the --insecure flag is passed." But I cannot find that flag in the help menu.
Found this answer which solves the problem.
Basically:
rm google_appengine/lib/cacerts/cacerts.txt
From the SDK
I am trying to selfupdate my Macports, but I am getting the following message:
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing
MacPorts sources: command execution failed
I checked my /opt/local/bin/macports and the directory does not exist. Instead, it is in /opt/local/var. Could that be the issue?
Running with -dt, I get the following:
[Users/user] > selfupdate
DEBUG: MacPorts sources location: /opt/local/var/macports/sources/rsync.macports.org/release/base
---> Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Connection refused (61)
rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-42/rsync/clientserver.c(105) [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzv --delete-after rsync://rsync.macports.org/release/base/ /opt/local/var/macports/sources/rsync.macports.org/release/base
Exit code: 10
DEBUG: Error synchronizing MacPorts sources: command execution failed
while executing
"macports::selfupdate [array get global_options] base_updated"
Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing MacPorts sources: command execution failed
What is error 61? Any ideas how I can fix that?
I had this same problem recently, and I forgot to run the command under root. If anyone else is having the problem, be sure to run command as so:
sudo port selfupdate
I was behind a firewall. Tried on a different network and it worked.
There is no /opt/local/bin/macports. The executable you need is /opt/local/bin/port. (Port files are in /opt/local/var/..., which is correct.)
Based on the command execution failed:
you might have forgotten to run as root.
port forks the following programs: rsync, tclsh, openssl, tar, chmod, chown.
Are these executable and in the PATH? (Is /opt/local/bin in your PATH as well?)
If that doesn't help, run port with -dt to get all sorts of debug info. That might help with finding the problem. Append the interesting parts to your question, maybe.
I faced the same issue.But I used to this method in the after.
Go to:
$prefix/etc/macports/sources.conf
(my path is like this):
/opt/local/etc/macports/sources.conf
comment out the rsync entry, and add a new entry as follows:
#rsync://rsync.macports.org/release/tarballs/ports.tar [default]
https://distfiles.macports.org/ports.tar.gz [default]
After that you can run:
sudo port -d sync
It's also explained on MacPorts.com.
Update for Mavericks: to ensure the XCode command line tools are installed, open a terminal and run xcode-select –-install, then follow the instructions in the resulting pop-up window:
accept license
Of course, this is in addition to the other tips such as making sure to run sudo port selfupdate.
If anybody else is having this issue and they've recently updated XCode, the root of my problem was that Command Line Tools had been omitted from the latest build.
Opening XCode and installing Command Line Tools via the XCode preference panel fixed this error being thrown by MacPorts.
If your company block the access via rsync you can use the http tarball. Explained here
Hope this helps.
EDIT: Now prefer to use homebrew
I too had the same error. It is because the network connection is rejected. If you are using University/Company WiFi or public connection, firewall would be refusing the connection.
As you can see from the output of -dt "rsync: failed to connect to rsync.macports.org: Connection refused (61)"
There are workarounds available which are provided on the macports site:
1) Using svn.
2) If svn fails too, you can try using Daily tarball.
You can test the changes by running "sudo port -d sync"
Note: If the https fails, you can replace it with http. But doing so is not recommended, as you will be fetching from insecure connection.
I faced the same issue.
The main problem was my network. Because the NETWORK Port was blocked for;
rsync://rsync.macports.org/release/tarballs/ports.tar
Try to use use another network.
for someone who's problem still exists, maybe you've forgot agree the Xcode license:
# sudo xcodebuild license
remember to look through and type 'agree' in the end.
In my case, the problem was internal to Macports! I updated rsync (the one delivered by Apple is old) with Macports and then Macports failed to use it (/opt/local/bin/rsync) but asked instead to use /usr/bin/rsync which does not exist (or has been erased to force using Macports rsync ?). I created a soft link between the two and now it works again.