I am working on composer v0.16. I am trying to add 2 new nodes to an existing 2 node blockchain network. Everything works fine on the first 2 nodes. On the new nodes, when I try to ping the network with the peer Admin card or try to interact with the network using the card, the operation waits for a long time and then gives a "Error: Error trying invoke business network. Error: Error: REQUEST_TIMEOUT" error.
I have checked the composer version is same on all 4 nodes. The state of the identity is "Bound" not "Active". Anything else that can be done to check version mismatch. What else can be checked?
It was trying to find the Orderer using the Orderer alias name in the connection.json and failing. Hence the timeout. Replacing the Orderer alias with the actual hostname resolved the issue.
Related
I am getting an timeout error when trying to deploy to an VM instance hosted on AWS. Manually I can log ing using
ssh -i myKeyFile.pem myuser#IP
Once I accessed the remote machine I can execute some docker commands and everything works fine. But now that I need to automated that on the CD pipeline is where I am getting the following error:
2020-06-02T21:37:12.6877276Z Trying to establish an SSH connection to ***#IP:port
2020-06-02T21:38:52.4629461Z ##[error]Failed to connect to remote machine. Verify the SSH service connection details. Error: Error: Timed out while waiting for handshake.
2020-06-02T21:38:52.4685976Z ##[section]Finishing: Run shell commands on remote machine
The steps I follow to make the SSH connection are:
I created a SSH service connection on the project settings in Azure DevOps
I created the CD pipeline
I added a SSH task with the following parameters
When I manually trigger it to test if it works, the release start working fine but after 1:43 minutes more or less is when I got the error:
Then, when I review the logs, it is the same error I pasted at the beginning:
[error]Failed to connect to remote machine. Verify the SSH service connection details. Error: Error: Timed out while waiting for handshake
I've increase the handshake timeout settings from the default one (20000) to 90000, but no luck.
Any one has face this problem before?
Seems there is an ongoing error with the default agent pools from Azure DevOps. Lot of people have been reported this and Azure DevOps teams is working on it at the time this post is been written (I couldn't find the post where all that is details. I will add this later on).
The workaround is
To create a self-hosted agent.
After this has been created you will need to re-create your CD pipeline using the new self-hosted agent.
The rest of the SSH task configuration depends on your needs. But if you want to test the SSH connection works, just print something:
echo 'I'm connected'
After this you CD pipeline should be working fine.
More details on how to created the Self-Hosted Agent on Windows. There are also links for Linux and Mac.
I had a similar issue with a VM in Azure. It turned out I had set the security group to only allow SSH in from my local network and Azure Dev-Ops agents obviously run in a Microsoft network and were coming from a different IP Address range. The solution was to open up SSH to all source IP Addresses. You can get the list of IP address ranges Dev-Ops agents use but they appear to change every week which isn't very helpful.
See https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops#microsoft-hosted-agents
Afer using hyperledger-composer for several months, now suddenly the following problem is happening:
Whenever I want to start a business network, using the command:
composer network start --networkName mynetwork --networkVersion 0.0.1 --card PeerAdmin#hlfv1 --networkAdmin admin --networkAdminEnrollSecret adminpw
... I get (after waiting for an eternity) the following error message:
Error: Error trying to start business network. Error: No valid
responses from any peers. Response from attempted peer comms was an
error: Error: REQUEST_TIMEOUT Command failed
I uninstalled the whole hyperledger-composer development environment and then reinstalled everything. I still get the same error message.
Does anybody know what the hell is going on here?
P.S.: here's the result of running "composer archive list -a mynetwork#0.0.1.bna":
Listing Business Network Archive from mynetwork#0.0.1.bna
Identifier:mynetwork#0.0.1
Name:mynetwork
Version:0.0.1
Ok, I re-installed the developer environment again AND restarted my computer. Now it works again.
We're thinking about migration from Hyperledger Composer v0.13.0 to the latest one (v0.16.5), so I have tried to create and deploy business network according tutorial below.
https://hyperledger.github.io/composer/latest/tutorials/developer-tutorial
But at the Step 4, composer runtime install command doesn't work.
Here is the error occured.
✖ Installing runtime for business network <<MY_BUSINESS_NETWORK>>. This may take a minute...
Error: Error trying to ping. Error: Error trying to query business network. Error: could not find chaincode with name '<<MY_BUSINESS_NETWORK>>' - make sure the chaincode <<MY_BUSINESS_NETWORK>> has been successfully instantiated and try again
Command failed
But I'm not sure where instantiation should be done.
I guess that composer runtime install and composer network start are counterparts of composer network deploy in v0.13.0, but is it wrong? In v0.13.0, I didn't need to execute "instantiate" command explicitly.
I would appreciate any suggestions or information, thanks.
My procedure
1. prepare credentials,channenl-artifacts and connection profile then start dockers.
2. create channel and make peers joined.
3. create BNA & card Files.
4. import the card of PeerAdmin then confirm with composer card list command.
5. execute composer install runtime command.
Environment
Ubuntu : 16.04
hyperledger composer : 0.16.5
ibmblockchain/fabric-tools 1.0.5
ibmblockchain/fabric-ca 1.0.5
ibmblockchain/fabric-peer 1.0.5
ibmblockchain/fabric-orderer 1.0.5
ibmblockchain/fabric-couchdb 1.0.5
the runtime install and network start (as you correctly understood) are two separate tasks that are likely to be performed by a Peer administrator and a network administrator (two separate roles) and hence why they are broken out - demarcation of duty. network deploy is deprecated from old days.
On tutorial - I suggest to do a 'teardown' from the fabric-tools directory and clear out your $HOME/.composer cards directory. I assume you downloaded a new fabric tools afresh? Did you also make sure to update your pre-requisites if/as required per the documentation https://hyperledger.github.io/composer/latest/installing/installing-prereqs.html
The error you posted related to << MY_BUSINESS NETWORK >> I assume, is because you've obfuscated the real network name - understandable) otherwise is an unusual error and not the name given in the tutorial - if you follow the tutorial it should deployed as follows (ie cut and paste from tutorial):
runtime install:
composer runtime install --card PeerAdmin#hlfv1 --businessNetworkName tutorial-network
network start:
composer network start --card PeerAdmin#hlfv1 --networkAdmin admin --networkAdminEnrollSecret adminpw --archiveFile tutorial-network#0.0.1.bna --file networkadmin.card
https://hyperledger.github.io/composer/latest/tutorials/developer-tutorial.html and this has been working fine for ages.
Are you trying to build your own Fabric network, single-org or multi-org, on same virtual host or across different physical/virtual machines ? Because the Fabric Dev server setup provided by Composer does 1 and 2 for you. You can also create the PeerAdmin card for that, as instructed in our docs (run a script).
Based on your procedure I would add first:
Do a teardown and remove old cards (as mentioned above)
do your steps 1 and 2 (and then create your Fabric network if that's what you want to do)
After your [custom] Fabric is up and running:
step 3. Test your custom Fabric Network to validate the configuration using the Fabric marbles sample chaincode. If that works, proceed to build your own PeerAdmin card
step 4. deploy the Business network by installing Composer runtime on all peers first then doing a network start of the bna on the channel you configured
step 5. Create Composer BN cards, connection profiles, identities and participants etc
I am testing a a business network I created, I ran the Composer-rest-server and all worked fine, then shut the server as suggested in the developers guide , then I proceeded use the yo hyperledger composer to create the skeleton of the angular app, however, now the angular app is showing in the local browser, however, the composer-rest- server is not.
Expected Behavior:
I should start the composer-rest- server in localhost:3000 and the angular app as well
Actual Behavior:
I get this message;
scovering types from business network definition ...
Connection fails: Error: Error trying to ping. Error: Error trying to query chaincode. Error: Connect Failed
It will be retried for the next request.
Exception: Error: Error trying to ping. Error: Error trying to query chaincode. Error: Connect Failed
Error: Error trying to ping. Error: Error trying to query chaincode. Error: Connect Failed
at _checkRuntimeVersions.then.catch (/home/node/.nvm/versions/node/v6.11.2/lib/node_modules/composer-rest-server/node_modules/composer-connector-hlfv1/lib/hlfconnection.js:696:34)
Your Environment
composer-cli#0.11.3
generator-hyperledger-composer#0.11.3
composer-rest-server#0.11.3
Docker version 17.06.0-ce, build 02c1d87
docker-compose version 1.13.0, build 1719ceb
The Problem
If you kill your fabric instance using ./stopFabric that you started using the ./startFabric command then all the containers that were apart of the business network were killed as well and therefore you need to reinstall the .bna and start the network again. (the development flow provided is purposely volatile for rapid development)
The Solution
1.) Type docker ps to see all of your running containers. You should see none if you are getting that error because your peer is not responding to pings
2.) Open a separate terminal and navigate to where you have fabric-dev-servers in the terminal and run ./fabricStart. This will start all the containers like your network Certificate Authority, the peer, the orderer, etc.
3.) Return to your project in another terminal. Do Step 1 & 2 found at the developer tutorial (you likely won't need to do step 3 since you likely already imported the network administrator identity going through the tutorial)
4.) Run composer network ping --card admin#tutorial-network. The ping should go through.
5.) Run docker ps. You should see 4 containers running
6.) Run composer-rest-server and follow the steps from the tutorial.
7.) Run cd tutorial-network-app to switch to where your angular application is (or wherever you generated it with the yo command)
8.) Navigate to http://localhost:3000 and everything should work.
Any other questions or problems just reply here and I can help.
The expected behaviour is that the REST server is already running (the the generator uses Loopback to spin up a REST server already (that's why you shut down the previous REST server)). Its described here https://hyperledger.github.io/composer/unstable/tutorials/developer-guide.html under 'Generate your Skeleton Web Application'.
After you created the application - following completion of the yo hyperledger-composer questions (and after providing the answers) you run your application using npm start from within the generated application directory. Your app is accessible at http://localhost:4200.
I have two Windows Server 2012 R2 machines located in one of the client's datacenters. Both servers are domain-joined. They both have RabbitMQ 3.6.0. installed on them. RabbitMQ is running as Windows Service on both machines. I've tried to cluster these two machines for a long time now without success. I always get the following error when I try to cluster them.
One the first machine nodeA I run the command 'rabbitmqctl join_cluster rabbit#nodeB'. This is what I get:
Clustering node 'rabbit#nodeA' with 'rabbit#nodeB' ...
Error: unable to connect to nodes ['rabbit#nodeB']: nodedown
`DIAGNOSTICS`
===========
attempted to contact: ['rabbit#nodeB']
rabbit#nodeB:
* connected to epmd (port 4369) on nodeB
* epmd reports node 'rabbit' running on port 25672
* TCP connection succeeded but Erlang distribution failed
* suggestion: hostname mismatch?
* suggestion: is the cookie set correctly?
* suggestion: is the Erlang distribution using TLS?
current node details:
- node name: 'rabbitmq-cli-3892#nodeA'
- home dir: C:\Users\mydirectory
- cookie hash: l+SSu57+cRyAQ03AJdwAbQ==
I've tried this setup with Azure Virtual Machines within Azure Virtual Network and I succeeded to cluster the two VM's, however it seems I cannot connect these two (customer's machines) together.
This is what I have done and ensured:
There isn't any firewall blocking connections
Added host names to hosts file located on C:\Windows\system32\drivers\etc
Tried to refer to host names as FQDN without adding anything to hosts file
Tried to refer to host names with CAPITAL letters and without
Copied the same exact .erlang.cookie to C:\Windows and C:\Users\mydirectory on both machines.
I've read, understood and applied RabbitMQ Clustering Guide https://www.rabbitmq.com/clustering.html
Stopped, restarted, reinstalled RabbitMQ on both machines.
It seems I can't get it to work. On Azure machines, which were not domain-joined clustering worked beautifully. I am really running out of options... Any help?
i had the same problem you need to install rabbitmq as a admin. uninstall then reinstall as admin and it should work fine
Try to connect to each of RabbitMQ nodes via remote shell and check if value of cookie is the same (cookie can be set in 3 different ways: .erlang.cookie is one of them).
erl -remsh 'rabbitmq-cli-3892#nodeA' -name 'test#nodeA'
erlang:get_cookie().