I am working composer v0.16.2. I am having an error while I try to reconnect to composer-rest-server.
I am using this command:
composer-rest-server -c admin#mynetwork -n always -a true -m true -w true -t true -e /home /.nvm/versions/node/v8.9.3/lib/node_modules/composer-rest-server/cert.pem -k /home /.nvm/versions/node/v8.9.3/lib/node_modules/composer-rest-server/key.pem
Whatever the option I set it works fine first time but when I need to reconnect with the same command, I need to restart fabric and deploy the business network again otherwise it will show this error:
Discovering types from business network definition ...
Connection fails:
Error: Error trying to ping.
Error: Error trying to query business network.
Error: Connect Failed It will be retried for the next request.
Exception: Error: Error trying to ping.
Error: Error trying to query business network.
Error: Connect Failed Error: Error trying to ping.
Error: Error trying to query business network.
Error: Connect Failed at _checkRuntimeVersions.then.catch (/home/.../.nvm/versions/node/v8.9.1/lib/node_modules/composer-rest-server/node_modules/composer-connector-hlfv1/lib/hlfconnection.js:713:34)
at <anonymous>
Hyperledger Composer v0.16.0 network start error
I found a similar question on this link but I need to start fabric again when this error comes and again deploying network archive help to start the rest server.
My question is how can I remove this error without starting fabric again when I need to start rest server?
The first action of the REST server is to 'Discover' the Business Network using the admin#mynetwork Card. So you can simplify testing here by not using the REST server, but by issuing a simpler command composer network ping -c admin#mynetwork or composer network list -c admin#mynetwork.
When your admin#mynetwork card is created (when you deploy the business network), then imported BEFORE you use it try the command composer card list --name admin#mynetwork - at the bottom of the output you should see:
secretSet: Secret set
credentialsSet: Credentials not set
After you use the card for the first time with a composer network ping or list, redo the composer card list --name admin#mynetwork and you should see a change in the output with Credentials set.
This is important because when the Card is created, it is created with a One Time secret, and when it is first used the Certificates are downloaded - Credentials Set. The problem you are seeing with a failure of the REST server the second time you use it suggests that the certificates needed for the second use are not present.
Related
When trying to get a psql shell (not using iam user) I am receiving:
> gcloud alpha sql connect pg-instance --database mydb --user myuser --project my-project
Starting Cloud SQL Proxy: [/Users/me/google-cloud-sdk/bin/cloud_sql_proxy -instances my-project:us-central1:pg-instance=tcp:9470 -credential_file /Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json]]
2022/03/15 14:47:59 Rlimits for file descriptors set to {Current = 8500, Max = 9223372036854775807}
2022/03/15 14:47:59 using credential file for authentication; path="/Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json"
2022/03/15 14:48:00 Listening on 127.0.0.1:9470 for my-project:us-central1:pg-instance
2022/03/15 14:48:00 Ready for new connections
Connecting to database with SQL user [myuser].Password:
psql: error: connection to server at "127.0.0.1", port 9470 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
I had the same error message when connecting to Postgres(Cloud Sql) using a service account.
In my setup I did run cloud_sql_proxy inside docker container.
In order to make it work I had to add extra configuration defined in step #9 https://cloud.google.com/sql/docs/sqlserver/connect-docker#connect-client
docker run -d \
-v <PATH_TO_KEY_FILE>:/config \
-p 127.0.0.1:5432:5432\
gcr.io/cloudsql-docker/gce-proxy:1.33.1 /cloud_sql_proxy \
-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:5432 -credential_file=/config
The missing bits were: host ip on port mapping and 0.0.0.0: in cloud_sql_proxy command
There are a few things I would like to point out. The best starting point for me would be the About connection options page; both the Overview and the Before you begin sections are very helpful to get the full idea of the process and how to properly configure the user. But the most important part is the Connection Options, for the message connection to server at "127.0.0.1" I’m guessing it is a private IP, but please make sure this section is covered before starting to debug.
In your case, the logs are saying there was an error in the connection to the server…
I used the Troubleshoot guide that includes the Diagnose issues link to get to the Debug connection issues page that has a lot of useful information on how to debug any connectivity issue.
Generally, connection issues fall into one of the following three areas:
Connecting - are you able to reach your instance over the network?
Authorizing - are you authorized to connect to the instance?
Authenticating - does the database accept your database credentials?
Each of those can be further broken down into different paths for investigation.
Once determining the connection method, there are different questions that will help to guide you through the possible troubleshooting paths.
If using these guides doesn’t get you a solution, please make sure to update your answer with the results, steps, and information followed to provide further help. This would be a good example, as it has the same log error, and this other question shows that there are a few different troubleshooting paths for this specific log message, plus they have useful information for you.
We have been trying to setup concourse 5.0.0 (we already set up 4.2.2) in our AWS. We have created two instances one is for web and another is for worker. We are able to see the site up and running but we are not able to run our pipeline. we checked the logs and noticed that worker throwing the below error.
Workerr.beacon.forward-conn.failed-to-dial","data":{"addr":"127.0.0.1:7777","error":"dial tcp 127.0.0.1:7777: connect: connection refused","network":"tcp","session":"9.1.4"}}
We are assuming worker is struggling to connect to web instance and wondering if this could be due to missing gdn configuration. Concourse 5.0.0 release included both concourse and gdn binaries. we want to try --garden-config file to see if that fixes the problem.
can somebody suggest how do we write garden config file ?
I had this same problem and solved it using #umamaheswararao-meka's answer. (Using ubuntu 18.04 on EC2)
Also had a problem with containers not being able to resolve domain names (https://github.com/docker/libnetwork/issues/2187). Here is the error message:
resource script '/opt/resource/check []' failed: exit status 1
stderr:
failed to ping registry: 2 error(s) occurred:
* ping https: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
* ping http: Get http://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
What I did:
sudo apt-get install resolvconf -y
# These are cloudflare's DNS servers
sudo echo "nameserver 1.1.1.1" >> /etc/resolvconf/resolv.conf.d/tail
sudo echo "nameserver 1.0.0.1" >> /etc/resolvconf/resolv.conf.d/tail
sudo resolvconf -u
cat /etc/resolv.conf # just to make sure changes are in place
# restart concourse service
Containers make use of resolv.conf and as the file is generated dynamically on ubuntu 18.04 this was the easiest way of making containers inherit this configuration.
Also relevant snippets from man resolvconf
-u Just run the update scripts (if updating is enabled).
/etc/resolvconf/resolv.conf.d/tail
File to be appended to the dynamically generated resolver configuration file. To append
nothing, make this an empty file. This file is a good place to put a resolver options
line if one is needed, e.g.,
it was the issue with gdn(garden binary) which was not configured. we had to include CONCOURSE_BIND_IP=xx.xx.x.x ( IP where your gdn is located) and CONCOURSE_BIND_PORT=7777( gdn's port) in wroker.env file. Which solved the problem for us.
Am trying to execute the following winexe command, but it throws 'ERROR: Cannot connect to svcctl pipe. NT_STATUS_ACCESS_DENIED.'
winexe -U domain/username%password //windows_machine ipconfig
debug info shows,
ERROR: smb_raw_open_recv - NT_STATUS_ACCESS_DENIED
ERROR: on_ctrl_pipe_error - NT_STATUS_ACCESS_DENIED
ERROR: Cannot open control pipe - NT_STATUS_ACCESS_DENIED
When i have 'winexesvc.exe' in Windows machine, the command works.
My understanding according to http://opensourceinfo.blogspot.com/ is that winexe itself creates winexesvc service, starts it and tries to connect to control pipe. If that's the case, what setting should i have in Windows to resolve Access Denied error and get the service installed successfully? Please correct me if am wrong.
I also came across similar issue in https://sourceforge.net/p/winexe/bugs/35/ post, but am unable to understand the given resolution 'I was trying to log on via a domain user, but only local users were configured'
Note that I have already set,
1. Network Access: Sharing and security model for
local accounts" to "Classic – local users authenticate as themselves
2. LocalAccountTokenFilterPolicy to 1.
So do we need to manually place winexesvc.exe in Windows machine for winexe to work or can we fix the above Access Denied error?
Thanks in advance.
I have deployed hyperledger composer over docker swarm following this article https://medium.com/#drakshayani7/hi-i-have-deployed-hyperledger-composer-application-over-docker-swarm-f54089d2ed7a. Everything is working perfect.
Now I'm going one step further by adding rest server with passport-google-strategy in the current docker swarm network.
But Its giving me error as "Exception: Error: Error trying to ping. Error: No peers available to query. last error was Error: 14 UNAVAILABLE: Connect Failed Error: Error trying to ping. Error: No peers available to query. last error was Error: 14 UNAVAILABLE: Connect Failed at _checkRuntimeVersions.then.catch (/home/composer/.npm-global/lib/node_modules/composer-rest-server/node_modules/composer-connector-hlfv1/lib/hlfconnection.js:813:34)
at "
Currently in rest server card's connection.json file I have kept service names. I even tried host name and docker ip address. But still it showing the same error.
Can anyone please guide me on this...
Following the tutorial and tool setup as outlined here;
https://hyperledger.github.io/composer/installing/development-tools.html
On the very last step, I executed the script to download and install local Fabric runtime:
cd ~/fabric-tools
./downloadFabric.sh
The resulting log in the console contained this error at the very end:
# Pull and tag the latest Hyperledger Fabric base image.
docker pull hyperledger/fabric-peer:$ARCH-1.0.4
Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.35/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/images/create?fromImage=hyperledger%2Ffabric-peer&tag=x86_64-1.0.4: dial unix /var/run/docker.sock: connect: permission denied
What should I do about this warning?
So your issue is a Docker issue - not a Hyperledger Composer issue FYI. I think this may help you https://techoverflow.net/2017/03/01/solving-docker-permission-denied-while-trying-to-connect-to-the-docker-daemon-socket/
Possibly a docker install issue - didn't install correctly? See here https://superuser.com/questions/835696/how-solve-permission-problems-for-docker-in-ubuntu where it talks about being in the docker group. Or else you can find an answer on Google.
I think this answer might be the reason behind it. The shell keeps your session stored. SO, in order to get the updates working, you have to close the shell and restart it again. That's why it worked after the restart.
Please correct me if I'm wrong!