we are able to update peer and orderer components to the latest version but while updating the channel capababilities to fetch the config block,peers are not able to connect with the orderer
Error: could not not connect to ordering service:could not dial endpoint:dial tcp:lookup orderer.example.com on 192.168.0.1:53 :no such host channel=mychannel
peer logs
you'll need to backup the msp and tls folders and load them in your the upgraded containers!
the official documentation mentions that you need to backup the msp but they don't do it.
Related
I'm working with hyperledger fabric on the IBM Blockchain Platform service. I've been able to test chain codes with no problems, however, after the last update, I started to get the error required chain codes are not installed on sufficient peers that looks simple but the problem is that the chaincode is in fact installed in all peers.
Log for Peer1
2021-10-28 20:12:53.535 UTC [lifecycle] CheckCommitReadiness -> INFO 111c Successfully
checked commit readiness of chaincode name 'test-cc' on channel 'testchannel2' with
definition {sequence: 5, endorsement info: (version: '0.0.9', plugin: 'escc', init
required: false), validation info: (plugin: 'vscc', policy:
'12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: ()}
Log for Peer2
2021-10-28 20:12:25.575 UTC [lifecycle] CheckCommitReadiness -> INFO 7bf1 Successfully
checked commit readiness of chaincode name 'test-cc' on channel 'testchannel2' with
definition {sequence: 5, endorsement info: (version: '0.0.9', plugin: 'escc', init
required: false), validation info: (plugin: 'vscc', policy:
'12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: ()}
However, when I execute the newly committed chaincode, I get:
2021-10-28 20:20:00.004 UTC [discovery] chaincodeQuery -> ERRO 1126 Failed constructing
descriptor for chaincode chaincodes:<name:"test-cc" > ,: required chaincodes are not
installed on sufficient peers
Any ideas?
CheckCommitReadiness only checks if the chaincode definition has been approved. It does not check if the chaincode has actually been installed on the peers. Use queryinstalled for that. If you find that the chaincode is indeed installed on each peer, then the next thing to check is that the discovery service can see each of the peers where the chaincode is installed. To check that, look in the peer logs for the "Membership view" messages. If the "Membership view" is incomplete, then it is likely a gossip configuration issue across the peers.
The problem was related to how I was deploying the CC. IBM Blockchain platform has a way to install CC on peer copying from another, simply uploading the CC again (for each peer). I tried again using the "copy from another" peer method and it worked. So, perhaps I was choosing a different version when uploading from my laptop.
I have created a sample HLF network with 3 organizations. I have taken an orderer and a peer from each organization ( total 3 orderers, 3 peers, 3 fabric-CA, 3 CouchDB instances).
I have successfully created the certificates, system channel, channel configuration, application channel and also successfully deployed the chaincode on each peer.
I am able to invoke/query any chaincode using peer binary in docker cli but not able to invoke/query the same chaincode through fabric Node SDK.
I have created the connection profile as per the template provided in the test network and also able to register any user for a specific organization. But whenever I am trying to query any chaincode function I am getting the below error:
[ServiceEndpoint]: Error: Failed to connect before the deadline on
Committer- name: orderer.example.com:7050, url:grpcs://localhost:7050,
connected:false, connectAttempted:true [ServiceEndpoint]: waitForReady
Failed to connect to remote gRPC server orderer.example.com:7050 url:grpcs://localhost:7050 timeout:3000
When I check the orderer logs I found this error:
ServerHandshake -> ERRO 087 Server TLS handshake failed in 2.085859ms
with error EOF server=Orderer remoteaddress=172.23.0.1:45678
**Why I am getting this error?
I am trying to just query so why it's connecting to the orderer?
If there is any TLS issue then why I am able to query it through peer binary?**
This link might help Hyperledger Fabric CA releasing wrong certificates (wrong issuer) to Node SDK when TLS enabled
If you are not running as a test network on your local machine, then you will need to specify the connection option of discovery.asLocalhost as false
I'm trying to upgrade my Hyperledger Fabric network from v1.4.7 to v2.1. Upgrading peers and orderers is done smoothly and already instantiated chaincodes work well. (Channel capabilities still remaining v1.x.) However, when I try to upgrade the new version of my chaincode, it keeps failed.
In v1.4.7, I built a server to install/instantiate/upgrade a chaincode using Fabric SDK v1.4.x. However, I found that all APIs related to installing/instantiating/upgrading a chaincode had been removed from Fabric SDK v2.1. So, as the doc said, I tried to upgrade a chaincode using peer CLI.
First, I packaged my chaincode using peer lifecycle chaincode ... command. At this time, I set FABRIC_CFG_PATH to a core.yaml in fabric-samples folder (I don't understand why I do this for only packaging a chaincode, but anyway I did what the doc said). And I set CORE_PEER_MSPCONFIGPATH to my admin user msp folder.
After I got my chaincode package, I connect to my first peer, peer0.identity.bpl, using docker exec -it peer0.identity.bpl /bin/sh command. My docker container doesn't open the port outside in the production mode, so I need to connect the container inside.
Then, I typed the following command and I got the error message:
/artifacts # peer lifecycle chaincode install identity_cc_v1.2.0.tar.gz
Error: chaincode install failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [The identity is not an admin under this MSP [BPLMSP]: The identity does not contain OU [ADMIN], MSP: [BPLMSP]]
So, I think I need some 'admin' identity, so I copied my admin msp folder to this peer. Then, I set CORE_PEER_MSPCONFIGPATH to this copied admin msp folder. Then I got:
/artifacts # export CORE_PEER_MSPCONFIGPATH=/artifacts/org-admin/msp
/artifacts # peer lifecycle chaincode install identity_cc_v1.2.0.tar.gz
2020-05-26 07:21:47.020 UTC [main] InitCmd -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /artifacts/org-admin/msp: administrators must be declared when no admin ou classification is set
Now, I thought that maybe the OU setting had some problem. So, I disabled OU setting from the config.yaml file. But, I got the same error message again.
So, I changed CORE_PEER_MSPCONFIGPATH setting to original setting again, but now it said this is not an admin identity.
/artifacts # export CORE_PEER_MSPCONFIGPATH=/artifacts/msp
/artifacts # peer lifecycle chaincode install identity_cc_v1.2.0.tar.gz
Error: chaincode install failed with status: 500 - Failed to authorize invocation due to failed ACL check: Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]
I understand. This identity is just a peer identity, not an admin identity. So, I tried to enroll admin in this peer, but this fabric-peer docker image doesn't contain fabric-ca-client binary. So, I thought I did something wrong and this is not the intended way.
At this point, how can I install and instantiate the new version of my chaincode?
After I set OU config to admin msp that is copied to peer, every problem has been solved and installing/committing a chaincode works well.
I'm trying to create a channel from the test-network sample of Hyperledger Fabric v2.1. I have installed all the latest fabric binaries & Docker images. The channel-artifacts, 2 peers and a ordering node were successfully created.
However, the command ./network.sh createChannel gives the following error.
Error: failed to create deliver client for orderer: failed to load config for OrdererClient: unable to load orderer.tls.rootcert.file: open /home/fabric/HLF/fabric-sample: no such file or directory
!!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!!
I believe CreateChannel is roughly 5 steps.
Generate a CreateChannel Transaction
Generate an Anchor peer transaction
Create the channel with the genesis block
Join the peers to the channel and
Update one peer in each organization to Anchor peer.
Any chance you can share the output of ./network.sh createChannel, I'd like to see how far you got before you ran into this error.
I was able to solve this issue by removing the spaces from name of parent directory in which the "fabric-samples" repo were installed. This was the final output was:
2020-05-14 16:56:04.064 IST [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2020-05-14 16:56:04.130 IST [channelCmd] update -> INFO 002 Successfully submitted channel update
===================== Anchor peers updated for org 'Org2MSP' on channel 'mychannel' =====================
========= Channel successfully joined ===========
In my opinion, The problem is with the directory fabric-samples kindly re-download the binaries and try again.
Download using curl via:
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/release-2.1/scripts/bootstrap.sh | bash -s -- 2.1.0 1.5.2
Hope this helps, otherwise see the directory structures and path exports.
I have a multi-org network fabric network up and running from different hosts.
The docker containers for the peers have TLS enabled. The build configuration of the peer:
- CORE_PEER_TLS_ENABLED=true
- CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt
- CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key
- CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crt
While creating and joining the channel I followed byfn docs and did not supply the TLS cert/file of the peer while joining the channel. All the peers were able to join the channel.
However, when I tried to fetch the newest block using peer channel fetch newest -o orderer.example.com:7050 -c examplechannel, I got the error:
Serve failed to complete security handshake from "ip:43402": tls: first record does not look like a TLS handshake
Further, I referred this doc on TLS and this doc
on passing TLS certs of the peer with the above fetch command:
peer channel fetch newest -o orderer.example.com:7050 -c examplechannel --tls --certfile $CORE_PEER_TLS_CERT_FILE --keyfile $CORE_PEER_TLS_KEY_FILE --cafile $CORE_PEER_TLS_ROOTCERT_FILE
This gave a new error:
grpc: Server.Serve failed to complete security handshake from "ip:43496": remote error: tls: bad certificate
Debugging TLS issues doc states that this happens when the server does not trust the client certificate. So in my case, I infer that the orderer is not trusting the certificate that the peer is passing.
So
Does it mean that I was supposed to pass TLS_CERT, TLS_KEY and TLS_ROOT cert while proposing a channel join from this peer?
If #1 is true, can I pass these certificates without bringing down the network and rejoining the channel with certs?
While creating the channel, it uses orderer's ca-cert. Also, when submitting anchor peer transaction, it uses orderer's ca cert? So am I supposed to use Orderer's ca cert for peer fetch command as well?
If #3 is true, then in a production environment, do we need to build up the peer containers such that it contains orderer's ca-cert?
There are multiple concepts baked into your questions. It's important to understand that there is a difference between using the peer to run a peer node--peer node start-- and using the peer as a CLI (e.g. peer channel fetch).
When the peer is running as a server, there's no need to pass in crypto material for the channels as the peer actually extracts the required TLS certificate information from the config block passed in the peer channel join ... command.
When the peer is running in CLI mode, you do need to provide the the TLS certificate information to connect to the various endpoints. When communicating with peers, this information is extracted from the peer config (either in core.yaml or from the corresponding CORE_ environment variables). When communicating with the orderer, there are specific command line flags for setting the TLS material.