Date   

JWT Authentication #rfc

Matthew Sykes
 

I have created a proposal for JWT based authentication that can be used with the channel participation API. The goal is enable the use of MSP identities on the API and remove the requirement for mutual TLS.

For those that are interested in this work, please take a look at https://github.com/hyperledger/fabric-rfcs/pull/41.

Thanks.


Peer logs filled with TLS handshake error #fabric #tls #ssl #fabric-questions

chintanr97@...
 

Hi Team, in peer logs we keep seeing following error messages:
```
2021-01-12 14:36:08.217 UTC [core.comm] ServerHandshake -> ERRO 2278 TLS handshake failed with error read tcp <ip1>:7052-><ip3>:60870: i/o timeout server=ChaincodeServer remoteaddress=<ip3>:60870
2021-01-12 14:36:08.218 UTC [core.comm] ServerHandshake -> ERRO 2279 TLS handshake failed with error read tcp <ip1>:7051-><ip3>:60872: i/o timeout server=PeerServer remoteaddress=<ip3>:60872
2021-01-12 14:36:08.573 UTC [core.comm] ServerHandshake -> ERRO 227a TLS handshake failed with error read tcp <ip1>:7052-><ip4>:54263: i/o timeout server=ChaincodeServer remoteaddress=<ip4>:54263
2021-01-12 14:36:08.575 UTC [core.comm] ServerHandshake -> ERRO 227b TLS handshake failed with error read tcp <ip1>:7051-><ip4>:54262: i/o timeout server=PeerServer remoteaddress=<ip4>:54262
2021-01-12 14:36:12.287 UTC [core.comm] ServerHandshake -> ERRO 227c TLS handshake failed with error EOF server=PeerServer remoteaddress=<ip2>:65264
2021-01-12 14:36:12.601 UTC [core.comm] ServerHandshake -> ERRO 227d TLS handshake failed with error read tcp <ip1>:7052-><ip2>:65265: i/o timeout server=ChaincodeServer remoteaddress=<ip2>:65265
2021-01-12 14:36:13.231 UTC [core.comm] ServerHandshake -> ERRO 227e TLS handshake failed with error EOF server=PeerServer remoteaddress=<ip3>:60887
2021-01-12 14:36:13.233 UTC [core.comm] ServerHandshake -> ERRO 227f TLS handshake failed with error EOF server=ChaincodeServer remoteaddress=<ip3>:60888
```

On our end, we verified the TLS certificates and they seem to be correctly configured with required SANs. I wanted to understand the implication of the "i/o timeout" error and "error EOF" messages.


Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

chintanr97@...
 

Hi David, That's correct! However, we found a minor fix in the chaincode and post that the latest error logs give following stack trace:

```

[34m2021-01-12 09:22:03.362 UTC [endorser] callChaincode -> INFO 10f7b [][] Entry chaincode: name:"<ccName>" 

[31m2021-01-12 09:22:41.290 UTC [chaincode] BuildQueryResponse -> ERRO [0m Failed to get query result from iterator

[31m2021-01-12 09:22:41.290 UTC [chaincode] HandleTransaction -> ERRO [0m [] Failed to handle QUERY_STATE_NEXT. error: net/http: request canceled (Client.Timeout exceeded while reading body)

error reading response body

github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).QueryDocuments

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:1072

github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*queryScanner).executeQueryWithBookmark

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:483

github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*queryScanner).Next

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:731

github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr.(*queryResultsItr).Next

/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr/helper.go:433

github.com/hyperledger/fabric/core/chaincode.(*QueryResponseGenerator).BuildQueryResponse

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/query_response_generator.go:32

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleQueryStateNext

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:824

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276

runtime.goexit

/opt/go/src/runtime/asm_amd64.s:1337

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleQueryStateNext

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:827

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276

runtime.goexit

/opt/go/src/runtime/asm_amd64.s:1337

QUERY_STATE_NEXT failed: transaction ID: <tid>

github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction

/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:280

runtime.goexit

/opt/go/src/runtime/asm_amd64.s:1337

[34m2021-01-12 09:22:41.291 UTC [<cc>] func2 -> INFO [0m 2021/01/12 09:22:41 error getting results for query response 

[34m2021-01-12 09:22:41.291 UTC [<cc>] func2 -> INFO [0m error: QUERY_STATE_NEXT failed: transaction ID: <tid>: error reading response body: net/http: request canceled (Client.Timeout exceeded while reading body)

[34m2021-01-12 09:22:41.291 UTC [endorser] callChaincode -> INFO [0m [<channel>][] Exit chaincode: name:"<ccName>"  (37928ms)
[31m2021-01-12 09:22:41.300 UTC [endorser] ProcessProposal -> ERRO [0m [<channel>][] simulateProposal() resulted in chaincode name:"<ccName>"  response status 500 for txid: <tid>
```

In the total 4 iterations of query we did, the timestamp in the second last log line, "Exit chaincode: name: ..." was: 49695ms, 55657ms, 37928ms (above) snippet, and 38826ms.

So, I am not sure now if it is "ledger.state.couchDBConfig.requestTimeout" (which has been set to 35 s), or if it is "CORE_CHAINCODE_EXECUTETIMEOUT" (updated to 300s).


Re: Operations Smart Contract for Hyperledger Fabric v2.x

Sato, Tatsuya
 

Thank you for your email.

Are you going to update the tool accordingly?
Yes, we are going to update this tool.
Support for channel participation without system channel is one of the future features.

Tatsuya Sato

-----Original Message-----
From: fabric@... <fabric@...> On Behalf Of Yueming Xu
Sent: Tuesday, January 12, 2021 8:10 AM
To: fabric@...
Subject: [EXT] Re: [Hyperledger Fabric] Operations Smart Contract for Hyperledger Fabric v2.x

I like your idea of managing chaincode and channels using blockchain. Fabric v2.3 has removed the dependency of system channel and consortium. Are you going to update the tool accordingly?




[-----WARNING-----] This email originated outside of Hitachi. [-----WARNING-----] DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.


Write Fabric chaincode with zero code #fabric #fabric-chaincode

Yueming Xu
 

If you do not like to write boilerplate code repeatedly, or spend time to learn a new programming language supported by the Fabric chaincode.  You may want to check this out: https://github.com/open-dovetail/fabric-chaincode.git.  It is completely open source, and you can develop chaincode without any programming.  You need to know only JSON data format, and everything else is taken care of by the visual programming environment.  Please let me know if you see any issues.  I would also appreciate recommendations for improvement.


Re: Operations Smart Contract for Hyperledger Fabric v2.x

Yueming Xu
 

I like your idea of managing chaincode and channels using blockchain. Fabric v2.3 has removed the dependency of system channel and consortium. Are you going to update the tool accordingly?


Private Chaincode Lab - Tue, 01/12/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 12 January 2021
8:00am to 9:00am
(GMT-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

David Enyeart
 

Your first log snippet showed CouchDB queries timing out after 35 seconds each. This is the core.yaml ledger.state.couchDBConfig.requestTimeout of 35s. It means that CouchDB is still processing the query when the peer client gives up on it.


Dave Enyeart

chintanr97---01/12/2021 09:31:22 AM---Thanks a lot David for your response. So digging deeper into the logs, we found that peer was return

From: chintanr97@...
To: fabric@...
Date: 01/12/2021 09:31 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric
Sent by: fabric@...





Thanks a lot David for your response. So digging deeper into the logs, we found that peer was returning below error:
[chaincode] BuildQueryResponse -> ERRO Failed
to get query result from iterator [chaincode] HandleTransaction -> ERRO Failed to handle QUERY_STATE_NEXT. error: net/http: request canceled (Client.Timeout exceeded while reading body) error reading response body

I wanted to understand the "Client.Timeout" meaning here. I am understanding that the "Client" could be either the peer to Couch DB connection or it could be the Fabric SDK client to peer connection.

IMO, this looks like the peer to Couch DB connection, where the error is getting logged in peer logs within <60s (from the timeout query request comes to the time it errors out), even when CORE_CHAINCODE_EXECUTETIMEOUT is set to 300s. So, this does not look like a timeout issue. Couch DB is returning error much before the set timeout config on the peer. Health of Couch DB and peer containers seem to be good as well.




Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

chintanr97@...
 

Thanks a lot David for your response. So digging deeper into the logs, we found that peer was returning below error:
[chaincode] BuildQueryResponse -> ERRO Failed to get query result from iterator [chaincode] HandleTransaction -> ERRO Failed to handle QUERY_STATE_NEXT. error: net/http: request canceled (Client.Timeout exceeded while reading body) error reading response body

I wanted to understand the "Client.Timeout" meaning here. I am understanding that the "Client" could be either the peer to Couch DB connection or it could be the Fabric SDK client to peer connection.

IMO, this looks like the peer to Couch DB connection, where the error is getting logged in peer logs within <60s (from the timeout query request comes to the time it errors out), even when CORE_CHAINCODE_EXECUTETIMEOUT is set to 300s. So, this does not look like a timeout issue. Couch DB is returning error much before the set timeout config on the peer. Health of Couch DB and peer containers seem to be good as well. 


Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

David Enyeart
 

Adding workarounds such as longer timeouts will only prolong your pain. You must address the root cause of the slow query in CouchDB. Troubleshoot it in a separate CouchDB environment until you have figured it out why the query/index are slow in CouchDB.
But honestly, if you expect to get back 20,000 records, you should consider the pattern of querying a downstream data store built from block events. Chaincode is optimized for transactions, not large queries.


Dave Enyeart

chintanr97---01/11/2021 11:50:53 PM---Hi David, The chaincode is performing a select query on the CouchDB documents, and the fields set fo

From: chintanr97@...
To: fabric@...
Date: 01/11/2021 11:50 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric
Sent by: fabric@...





Hi David,

The chaincode is performing a select query on the CouchDB documents, and the fields set for filtering the results are indexed while installing and instantiating the chaincode. The single query using the Fabric Node SDK client might be reading around 20K-30K records.

We tried by overriding the peer configuration for following default values with the new values: "CORE_CHAINCODE_EXECUTETIMEOUT=300s" and CORE_PEER_KEEPALIVE_CLIENT_TIMEOUT=300s". We also tried with the SDK connection profile using a property: "grpc.keepalive_timeout_ms": "300000"

So I am not understanding, what we could be missing here. Because the other chaincodes in same channel are able to query the maximum limit of 100K records!




Re: #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:" #fabric-ca #fabric-orderer #hyperledger-fabric

Marek Malik <info@...>
 

Anyone could help with this one?

I was thinking I have something wrong with the volume what I’m connecting to the container in k8s, but it looks correct.

 

This is the files structure in the container:

/var/hyperledger
/var/hyperledger/channel-artifacts
/var/hyperledger/channel-artifacts/genesis.block
/var/hyperledger/production
/var/hyperledger/production/orderer
/var/hyperledger/production/orderer/index
/var/hyperledger/production/orderer/index/MANIFEST-000000
/var/hyperledger/production/orderer/index/CURRENT
/var/hyperledger/production/orderer/index/000001.log
/var/hyperledger/production/orderer/index/LOG
/var/hyperledger/production/orderer/index/LOCK
/var/hyperledger/production/orderer/chains
/var/hyperledger/orderer
/var/hyperledger/orderer/msp
/var/hyperledger/orderer/msp/signcerts
/var/hyperledger/orderer/msp/signcerts/cert.pem
/var/hyperledger/orderer/msp/config.yaml
/var/hyperledger/orderer/msp/keystore
/var/hyperledger/orderer/msp/keystore/34830a9ce7333287709c65a71ccbeda86998cfd7f57e68b29360247015ebba02_sk
/var/hyperledger/orderer/msp/IssuerPublicKey
/var/hyperledger/orderer/msp/tlscacerts
/var/hyperledger/orderer/msp/tlscacerts/hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/msp/user
/var/hyperledger/orderer/msp/IssuerRevocationPublicKey
/var/hyperledger/orderer/msp/cacerts
/var/hyperledger/orderer/msp/cacerts/hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/tls
/var/hyperledger/orderer/tls/server.crt
/var/hyperledger/orderer/tls/signcerts
/var/hyperledger/orderer/tls/signcerts/cert.pem
/var/hyperledger/orderer/tls/keystore
/var/hyperledger/orderer/tls/keystore/b66d2e77cd826f965ea18d4d14d4d3815fa9fd1635469558f05b10e64a466ed7_sk
/var/hyperledger/orderer/tls/IssuerPublicKey
/var/hyperledger/orderer/tls/server.key
/var/hyperledger/orderer/tls/tlscacerts
/var/hyperledger/orderer/tls/tlscacerts/tls-hlf-ca--amvoxdlt-7054.pem
/var/hyperledger/orderer/tls/user
/var/hyperledger/orderer/tls/IssuerRevocationPublicKey
/var/hyperledger/orderer/tls/cacerts
/var/hyperledger/orderer/orderer0.amvox-dlt.io.finished

 

Here is the config.yaml

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
    OrganizationalUnitIdentifier: orderer

 

In the attachment you will find the debug logging when starting the orderer.

 

I will be greatfull for any help, I’m not sure where is the problem, and all files seem to be located in the correct folders.

 

Best Regards,

Marek Malik

 

Od: <fabric@...> w imieniu użytkownika Marek Malik <info@...>
Data: piątek, 8 stycznia 2021 23:55
Do: Yacov Manevich <YACOVM@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Thanks Yacov, but I don’t intend to create the admincerts folder.

“define the admin OU in the config.yaml of the MSP folder”
This is exactly what I’m doing -> This is the config.yaml from the mail:

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer




The cert is stored in the cacerts folder in the MSP dir.
Anything else that I’m missing ?

 

 

Best Regards,

Marek Malik

 

Od: Yacov Manevich <YACOVM@...>
Data: piątek, 8 stycznia 2021 22:58
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Put admin certificates in the admin folder, or define the admin OU in the config.yaml of the MSP folder



From:        "Marek Malik" <info@...>
To:        fabric@...
Date:        01/08/2021 11:49 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"
Sent by:        fabric@...





Hello Guys, 

I'm trying to setup my network to work in Kubernetes cluster, but my Orderer keeps failing. I'm getting the following error: 
Main -> PANI 005 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set
panic: Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set

Could anyone help?


I'm following a similar setup as the test-network from the samples: I have the Fabric-CA generating the certificates & using the NodeOUs (it is enabled in crypto-config.yaml): 

This is the configtx.yaml that I'm using to generate the genesis.block. It is also located in the msp folder when running the Orderer.

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer

Orderer: &OrdererDefaults

 # Orderer Type: The orderer implementation to start
 OrdererType: etcdraft

 Addresses:
   - orderer0.amvox-dlt.io:7050

 # Batch Timeout: The amount of time to wait before creating a batch
 BatchTimeout: 3s

 # Batch Size: Controls the number of messages batched into a block
 BatchSize:

   # Max Message Count: The maximum number of messages to permit in a batch
   MaxMessageCount: 500

   # Absolute Max Bytes: The absolute maximum number of bytes allowed for
   # the serialized messages in a batch.
   AbsoluteMaxBytes: 99 MB

   # Preferred Max Bytes: The preferred maximum number of bytes allowed for
   # the serialized messages in a batch. A message larger than the preferred
   # max bytes will result in a batch larger than preferred max bytes.
   PreferredMaxBytes: 512 KB

 EtcdRaft:
   Consenters:
     - Host: orderer0.amvox-dlt.io
       Port: 7050
       ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
       ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt


 # Organizations is the list of orgs which are defined as participants on
 # the orderer side of the network
 Organizations:

 # Policies defines the set of policies at this level of the config tree
 # For Orderer policies, their canonical path is
 #   /Channel/Orderer/<PolicyName>
 Policies:
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"
   # BlockValidation specifies what signatures must be included in the block
   # from the orderer for the peer to validate it.
   BlockValidation:
     Type: ImplicitMeta
     Rule: "ANY Writers"

 # Capabilities describes the orderer level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *OrdererCapabilities

################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
 # Policies defines the set of policies at this level of the config tree
 # For Channel policies, their canonical path is
 #   /Channel/<PolicyName>
 Policies:
   # Who may invoke the 'Deliver' API
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   # Who may invoke the 'Broadcast' API
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   # By default, who may modify elements at this config level
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"

 # Capabilities describes the channel level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *ChannelCapabilities

################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:

 amvox-channel:
   Consortium: AmvoxConsortium
   <<: *ChannelDefaults
   Application:
     <<: *ApplicationDefaults
     Organizations:
       - *Amvox
       - *Org2
       - *Org3
     Capabilities:
       <<: *ApplicationCapabilities

 OrdererGenesis:
   <<: *ChannelDefaults
   Orderer:
     <<: *OrdererDefaults
     OrdererType: etcdraft
     EtcdRaft:
       Consenters:
         - Host: orderer0.amvox-dlt.io
           Port: 7050
           ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
           ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
     Addresses:
       - orderer0.amvox-dlt.io:7050

     Organizations:
       - *AmvoxDLT
     Capabilities:
       <<: *OrdererCapabilities

   Application:
     <<: *ApplicationDefaults
     Organizations:
       - <<: *AmvoxDLT

   Consortiums:
     AmvoxConsortium:
       Organizations:
         - *Amvox
         - *Org2
         - *Org3

Anyone has any ideas why ordered can not get started?

 





Re: Unable to Query data from Hyperledger Fabric #couchdb #fabric-chaincode #hyperledger-fabric

chintanr97@...
 

Hi David,

The chaincode is performing a select query on the CouchDB documents, and the fields set for filtering the results are indexed while installing and instantiating the chaincode. The single query using the Fabric Node SDK client might be reading around 20K-30K records. 

We tried by overriding the peer configuration for following default values with the new values: "CORE_CHAINCODE_EXECUTETIMEOUT=300s" and CORE_PEER_KEEPALIVE_CLIENT_TIMEOUT=300s". We also tried with the SDK connection profile using a property:  "grpc.keepalive_timeout_ms": "300000"

So I am not understanding, what we could be missing here. Because the other chaincodes in same channel are able to query the maximum limit of 100K records!


Operations Smart Contract for Hyperledger Fabric v2.x

Sato, Tatsuya
 

Hello,

 

We just released the first version of Operations Smart Contract (OpsSC) for Hyperledger Fabric v2.x.

This is a smart contract-based system operation tool for Hyperledger Fabric-based systems,

which aims to enable efficient decentralized system operations across multiple organizations.

 

The current version will help make the following end-to-end operational workflows more efficient:

  - Chaincode operations: Streamline typical chaincode deployment process

    (download, package, install, approve and commit a chaincode)

  - Channel operations: Streamline typical channel configuration updates process across multiple organizations

    (e.g., creating a channel, adding an organization, adding an orderer etc.)

 

Please see the following repository for more information.

https://github.com/satota2/fabric-opssc

 

 

We would like to contribute to the Fabric community with this OpsSC.

As the first step, we want to start this as a "hyperledger-labs" project.

So, we are looking for a sponsor who could help us open a repository in hyperledger-labs.

 

Also, if possible, we would like to introduce this OpsSC in the contributor meeting.

 

Thank you for your attention.

 

 

Regards,

Tatsuya Sato

 


Re: Fabric for Covid-19 Immunity Passports on Fabric deployed on multi-cloud (aws, azure, gcp)

Mark Rakhmilevich
 

Nathan,

   There are some solutions out there along these lines, including our partner Vottun’s PROOF OF HEALTH CREDENTIALS built on Fabric and available on Oracle Blockchain Platform, but could also be deployed on a multi-vendor/multi-cloud network of Fabric nodes.  There are other efforts focused on sharing testing & vaccination status gaining attention: e.g., Common Trust Network sponsored by WEF, but it doesn’t appear to leverage blockchain technology.

 

Mark

 

From: Nathan Aw <Nathan.mk.aw@...>
Sent: Sunday, January 10, 2021 12:54 AM
To: fabric@...
Subject: [Hyperledger Fabric] Fabric for Covid-19 Immunity Passports on Fabric deployed on multi-cloud (aws, azure, gcp)

 

Hi everyone,

 

Has anyone explored the use of fabric for covid-19 immunity passports purposes?

 

These peer nodes could be setup and managed by the various governments, the WHO, etc.

 

Once vaccinated, your details will be inputted into ledger. You could then be issued with a qr code. At the border, upon departure, you could present the qr code to customs. The qr code will then be verified against your passport details etc.

 

To ensure that the solution can be truly, truly resilient, the setup should be deployed on multi-cloud in all regions of the world and zones possible.

 

However, assuming the above can be achieved technically, the most pertinent question remains unanswered: how (1) scalable and (2) secure will this be? 

 

Given that all cross border travellers in the world will need be verified -- can fabric meet such rigorous and stringent requirements?

 

Anyone, any thoughts?

 

Thank you.

 

Regards,

 

Nathan Aw 


Re: API to get local MSPID in chaincode? #fabric #fabric-chaincode #fabric-questions

Yueming Xu
 

Thanks.  chaincode-go has the same API, shim.GetMSPID(), which returns the value of env CORE_PEER_LOCALMSPID.


Re: Assistance for planning design of a chaincode #couchdb #fabric #hyperledger-fabric

Tsvetan Georgiev
 

Hi Samyak Jain,

Just to add on top of the approach David suggested.
You can use the block event service to do much more like pushing important data to various systems (not just data stores). In the enterprise world, those may be CRM,ERP, BW/BI systems... In most of the cases, I would also consider integrating with a Message Queue to leverage the added benefits.

Regards,
Tsvetan


Fabric for Covid-19 Immunity Passports on Fabric deployed on multi-cloud (aws, azure, gcp)

Nathan Aw
 

Hi everyone,

Has anyone explored the use of fabric for covid-19 immunity passports purposes?

These peer nodes could be setup and managed by the various governments, the WHO, etc.

Once vaccinated, your details will be inputted into ledger. You could then be issued with a qr code. At the border, upon departure, you could present the qr code to customs. The qr code will then be verified against your passport details etc.

To ensure that the solution can be truly, truly resilient, the setup should be deployed on multi-cloud in all regions of the world and zones possible.

However, assuming the above can be achieved technically, the most pertinent question remains unanswered: how (1) scalable and (2) secure will this be? 

Given that all cross border travellers in the world will need be verified -- can fabric meet such rigorous and stringent requirements?

Anyone, any thoughts?

Thank you.

Regards,

Nathan Aw 


Re: API to get local MSPID in chaincode? #fabric #fabric-chaincode #fabric-questions

Tsvetan Georgiev
 

Hi,
If I get your questions right, you want to fetch the MSPID of the peer that starts/endorses the chaincode. For that purpose you can use the chaincode shim API. In case it is java based chaincode you can look at the method String getMspId(); of the shim: https://github.com/hyperledger/fabric-chaincode-java/blob/master/fabric-chaincode-shim/src/main/java/org/hyperledger/fabric/shim/ChaincodeStub.java
You have similar method in NodeJS shim: https://hyperledger.github.io/fabric-chaincode-node/release-2.1/api/fabric-shim.ChaincodeStub.html#getMspID__anchor

If you want to fetch the MSPID (as you mention above) of the user who requests for endorsement you can do that through the caller identity (CID) - see method getCreator() of the ChaincodeStub.


API to get local MSPID in chaincode? #fabric #fabric-chaincode #fabric-questions

Yueming Xu
 

when my chaincode wants to write to the implicit private data collection, I need to get the local MSPID where the chaincode is deployed.  What is a good way to get it? check the ENV of CORE_PEER_LOCALMSPID?  Or should I use the CID's MSPID, assuming the client must match the peer's MSPID for private data?  or send the designated MSPID as part of the request parameter?


Re: #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:" #fabric-ca #fabric-orderer #hyperledger-fabric

Marek Malik <info@...>
 

Thanks Yacov, but I don’t intend to create the admincerts folder.

“define the admin OU in the config.yaml of the MSP folder”
This is exactly what I’m doing -> This is the config.yaml from the mail:

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer



The cert is stored in the cacerts folder in the MSP dir.
Anything else that I’m missing ?

 

 

Best Regards,

Marek Malik

 

Od: Yacov Manevich <YACOVM@...>
Data: piątek, 8 stycznia 2021 22:58
Do: Marek Malik <info@...>
DW: "fabric@..." <fabric@...>
Temat: Re: [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"

 

Put admin certificates in the admin folder, or define the admin OU in the config.yaml of the MSP folder



From:        "Marek Malik" <info@...>
To:        fabric@...
Date:        01/08/2021 11:49 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] #fabric-ca #fabric-orderer #hyperledger-fabric Unable to start the Orderer, keep getting "initializing channelconfig failed: could not create channel Consortiums sub-group config:"
Sent by:        fabric@...





Hello Guys, 

I'm trying to setup my network to work in Kubernetes cluster, but my Orderer keeps failing. I'm getting the following error: 
Main -> PANI 005 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set
panic: Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: administrators must be declared when no admin ou classification is set

Could anyone help?


I'm following a similar setup as the test-network from the samples: I have the Fabric-CA generating the certificates & using the NodeOUs (it is enabled in crypto-config.yaml): 

This is the configtx.yaml that I'm using to generate the genesis.block. It is also located in the msp folder when running the Orderer.

NodeOUs:
   Enable: true
   ClientOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: client
   PeerOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: peer
   AdminOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: admin
   OrdererOUIdentifier:
     Certificate: cacerts/hlf-ca--amvoxdlt-7054.pem
     OrganizationalUnitIdentifier: orderer

Orderer: &OrdererDefaults

 # Orderer Type: The orderer implementation to start
 OrdererType: etcdraft

 Addresses:
   - orderer0.amvox-dlt.io:7050

 # Batch Timeout: The amount of time to wait before creating a batch
 BatchTimeout: 3s

 # Batch Size: Controls the number of messages batched into a block
 BatchSize:

   # Max Message Count: The maximum number of messages to permit in a batch
   MaxMessageCount: 500

   # Absolute Max Bytes: The absolute maximum number of bytes allowed for
   # the serialized messages in a batch.
   AbsoluteMaxBytes: 99 MB

   # Preferred Max Bytes: The preferred maximum number of bytes allowed for
   # the serialized messages in a batch. A message larger than the preferred
   # max bytes will result in a batch larger than preferred max bytes.
   PreferredMaxBytes: 512 KB

 EtcdRaft:
   Consenters:
     - Host: orderer0.amvox-dlt.io
       Port: 7050
       ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
       ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt


 # Organizations is the list of orgs which are defined as participants on
 # the orderer side of the network
 Organizations:

 # Policies defines the set of policies at this level of the config tree
 # For Orderer policies, their canonical path is
 #   /Channel/Orderer/<PolicyName>
 Policies:
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"
   # BlockValidation specifies what signatures must be included in the block
   # from the orderer for the peer to validate it.
   BlockValidation:
     Type: ImplicitMeta
     Rule: "ANY Writers"

 # Capabilities describes the orderer level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *OrdererCapabilities

################################################################################
#
#   CHANNEL
#
#   This section defines the values to encode into a config transaction or
#   genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
 # Policies defines the set of policies at this level of the config tree
 # For Channel policies, their canonical path is
 #   /Channel/<PolicyName>
 Policies:
   # Who may invoke the 'Deliver' API
   Readers:
     Type: ImplicitMeta
     Rule: "ANY Readers"
   # Who may invoke the 'Broadcast' API
   Writers:
     Type: ImplicitMeta
     Rule: "ANY Writers"
   # By default, who may modify elements at this config level
   Admins:
     Type: ImplicitMeta
     Rule: "MAJORITY Admins"

 # Capabilities describes the channel level capabilities, see the
 # dedicated Capabilities section elsewhere in this file for a full
 # description
 Capabilities:
   <<: *ChannelCapabilities

################################################################################
#
#   Profile
#
#   - Different configuration profiles may be encoded here to be specified
#   as parameters to the configtxgen tool
#
################################################################################
Profiles:

 amvox-channel:
   Consortium: AmvoxConsortium
   <<: *ChannelDefaults
   Application:
     <<: *ApplicationDefaults
     Organizations:
       - *Amvox
       - *Org2
       - *Org3
     Capabilities:
       <<: *ApplicationCapabilities

 OrdererGenesis:
   <<: *ChannelDefaults
   Orderer:
     <<: *OrdererDefaults
     OrdererType: etcdraft
     EtcdRaft:
       Consenters:
         - Host: orderer0.amvox-dlt.io
           Port: 7050
           ClientTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
           ServerTLSCert: /hlf_config/crypto-config/ordererOrganizations/amvox-dlt.io/orderers/orderer0.amvox-dlt.io/tls/server.crt
     Addresses:
       - orderer0.amvox-dlt.io:7050

     Organizations:
       - *AmvoxDLT
     Capabilities:
       <<: *OrdererCapabilities

   Application:
     <<: *ApplicationDefaults
     Organizations:
       - <<: *AmvoxDLT

   Consortiums:
     AmvoxConsortium:
       Organizations:
         - *Amvox
         - *Org2
         - *Org3

Anyone has any ideas why ordered can not get started?

 



2001 - 2020 of 11416