Date   

Proposal: add certificate expiration metrics

Konstantin Antipov
 

Hello everyone,

I'd like to propose new metric to monitor certificates expiration.

https://jira.hyperledger.org/browse/FAB-17497

Thanks for the "FAB-17000: Warn when certificates are about to expire", but this will not work in our case.
At a moment we have 4 different fabric environments, setted up at the different time and placed in different kubernetes clusters.
We need 100% accurate data when certificates are going to expire, better with different severities.

So, pretty simple (from my view) solution: every time any part of hyperledger fabric reads any certificate - it creates or updates metric with issuer and certificate CN as a labels and not_after as a value, in unixtime. Based on this data companies can setup any notification flow they need.


Kind regards,
Konstantin Antipov


Cancelled Event: Hyperledger Fabric Chaincode EVM - Wednesday, 19 February 2020 #cal-cancelled

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

Cancelled: Hyperledger Fabric Chaincode EVM

This event has been cancelled.

When:
Wednesday, 19 February 2020
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.backup

Organizer: Hyperledger Community Meetings linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0@...

Description:
Contact: Swetha Repakula srepaku@...

Topic: Hyperledger Fabric Chaincode EVM

Agenda: https://wiki.hyperledger.org/display/fabric/Meeting+Agenda

Join Zoom Meeting
https://zoom.us/j/6223336701

One tap mobile
+16699006833,,6223336701# US (San Jose)
+16465588656,,6223336701# US (New York)

Dial by your location
+1 669 900 6833 US (San Jose)
+1 646 558 8656 US (New York)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
Meeting ID: 622 333 6701
Find your local number: https://zoom.us/u/acTtmm3MX4

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=VIEW&eid=NHAwNjJlaXNnc2I3Zmg4OXYyanY3cDlpcW1fUjIwMTkwNTE1VDE1MDAwMCBmYWJyaWNAbGlzdHMuaHlwZXJsZWRnZXIub3Jn&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19uZjl1NjRnOWs5cnZkOWY4dnA0dnVyMjNiMEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tMzU5NTM3MDhlMTNlOTNhNDA1NDJmYjNjNTQ5OTc3NmQ0MzgzMjhjNg&ctz=America%2FLos_Angeles&hl=en&es=1.
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-


Re: registeruser.js - 1.4 v 2.0

Bret Harrison <beharrison@...>
 

With NodeSDK v2 beta.3 you will get the required admin `User` object instance for calling the `register` of fabric-ca-client from the fabric-network `Wallet` rather than from the underlying Client object instance of the Gateway.

const adminIdentity = await wallet.get('admin');
const provider = wallet.getProviderRegistry().getProvider(adminIdentity.type);
const adminUser = await provider.getUserContext(adminIdentity, 'admin’);
const secret = await ca.register({
affiliation: 'org1.department1',
enrollmentID: 'user1',
role: 'client'
}, adminUser);
const enrollment = await ca.enroll({
enrollmentID: 'user1',
enrollmentSecret: secret
});
const x509Identity = {
credentials: {
certificate: enrollment.certificate,
privateKey: enrollment.key.toBytes(),
},
mspId: 'Org1MSP',
type: 'X.509',
};
await wallet.put('user1', x509Identity);


Re: registeruser.js - 1.4 v 2.0

Trevor Lee Oakley <trevor@...>
 

I did more checks and it looks like fabric-ca-client was used before and now a Gateway is used. It also looks like getClient does not work with the instance of Gateway. This looks like a coding error unless the fabcar install has the wrong versions for the require('fabric-network').
 
I am unclear how this got to this level and somehow the docs need changing, a coding change, or a change in the install.
 
Trevor
 
 
 

From: "Trevor Lee Oakley" <trevor@...>
Sent: 18 February 2020 01:41
To: fabric@...
Subject: [Hyperledger Fabric] registeruser.js - 1.4 v 2.0
 
I email yesterday about an error in 2.0 and registeruser. I understand it is now under peer review. What is the recommended course of action to register a user in 2.0?
 
I checked 1.4 and saw the code is very different for registeruser. Can anyone explain why registeruser changed so much? I was thinking of using the 1.4 registeruser.js but I am unclear whether that would actually register the user and for the user to have all the required access.
 
Trevor Oakley 
 
 


registeruser.js - 1.4 v 2.0

Trevor Lee Oakley <trevor@...>
 

I email yesterday about an error in 2.0 and registeruser. I understand it is now under peer review. What is the recommended course of action to register a user in 2.0?
 
I checked 1.4 and saw the code is very different for registeruser. Can anyone explain why registeruser changed so much? I was thinking of using the 1.4 registeruser.js but I am unclear whether that would actually register the user and for the user to have all the required access.
 
Trevor Oakley 
 
 


Re: chaincode 2.0 problems

indirajith
 

Yes, I have defined Endorsement policies for my peer orgs. But not for the orderer org.
Endorsement:
            Type: Signature
            Rule: "OR('org1MSP.peer')"
Endorsement:
            Type: Signature
            Rule: "OR('org2MSP.peer')"
These are the endorsement policies for the orgs in my configtx.yaml. Don't they get endorsed when we commit the package? The peer orgs show both peers have successfully endorsed the transaction. 

Thank you verymuch for the response.
Kind regards,
Indirajith.


On Mon, 17 Feb 2020 at 16:12, Nikhil E Gupta <negupta@...> wrote:
Hi,

Your logs say zero of the endorsement sub-policies were defined. Did you define the endorsement sub policies in configtx.yaml for your organizations?




-----fabric@... wrote: -----
To: David Enyeart <enyeart@...>
From: "indirajith"
Sent by: fabric@...
Date: 02/17/2020 09:28AM
Cc: fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal 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 tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


    On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
    I'm using byfn w/o any modification

    - J

    On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - J

          On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
          Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

          1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
          2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
          a.) one peer in the org can only approve the chaincode one time
          b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
          c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

          2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

          Thanks so much for your response.


          Tong Li
          IBM Open Technology

          Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

          From: "Nikhil Gupta" <negupta@...>
          To: "David Enyeart" <enyeart@...>
          Cc: "Tong Li" <litong01@...>, fabric@...
          Date: 01/08/2020 08:53 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...




          The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

          The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



          -----fabric@... wrote: -----
          To: "Tong Li" <litong01@...>
          From: "David Enyeart"
          Sent by: fabric@...
          Date: 01/08/2020 12:28AM
          Cc: fabric@...
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

          1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

          1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

          {
          "approvals": {
          "org0examplecom": true,
          "org1examplecom": true
          }
          }

          That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

          peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
          2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
          2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

          2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

          ---
          Organizations:
          - &examplecom
          Name: examplecom
          ID: examplecom
          MSPDir: keyfiles/ordererOrganizations/example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Writers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Admins:
          Type: Signature
          Rule: "OR('examplecom.admin')"
          - &org0examplecom
          Name: org0examplecom
          ID: org0examplecom
          MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org0examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org0examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org0.example.com
          Port: 7051
          - Host: peer2.org0.example.com
          Port: 7051
          - &org1examplecom
          Name: org1examplecom
          ID: org1examplecom
          MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org1examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org1examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org1.example.com
          Port: 7051
          - Host: peer2.org1.example.com
          Port: 7051

          Capabilities:
          Channel: &ChannelCapabilities
          V2_0: true

          Orderer: &OrdererCapabilities
          V2_0: true

          Application: &ApplicationCapabilities
          V2_0: true

          Application: &ApplicationDefaults
          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"
          Endorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          Capabilities:
          <<: *ApplicationCapabilities

          Orderer: &OrdererDefaults
          OrdererType: etcdraft

          Addresses:
          - orderer1.example.com:7050
          - orderer2.example.com:7050
          - orderer3.example.com:7050

          BatchTimeout: 2s

          BatchSize:
          MaxMessageCount: 10
          AbsoluteMaxBytes: 99 MB
          PreferredMaxBytes: 512 KB

          EtcdRaft:
          Consenters:
          - Host: orderer1.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          - Host: orderer2.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          - Host: orderer3.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          BlockValidation:
          Type: ImplicitMeta
          Rule: "ANY Writers"

          Channel: &ChannelDefaults
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

          Capabilities:
          <<: *ChannelCapabilities

          Profiles:
          OrgChannel:
          Consortium: SampleConsortium
          <<: *ChannelDefaults
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - *org0examplecom
          - *org1examplecom
          Capabilities:
          <<: *ApplicationCapabilities

          OrdererGenesis:
          <<: *ChannelDefaults
          Capabilities:
          <<: *ChannelCapabilities
          Orderer:
          <<: *OrdererDefaults
          Organizations:
          - *examplecom
          Capabilities:
          <<: *OrdererCapabilities
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - <<: *examplecom
          Consortiums:
          SampleConsortium:
          Organizations:
          - *org0examplecom
          - *org1examplecom


          Tong Li
          IBM Open Technology










Re: chaincode 2.0 problems

Nikhil Gupta
 

Hi,

Your logs say zero of the endorsement sub-policies were defined. Did you define the endorsement sub policies in configtx.yaml for your organizations?




-----fabric@... wrote: -----
To: David Enyeart <enyeart@...>
From: "indirajith"
Sent by: fabric@...
Date: 02/17/2020 09:28AM
Cc: fabric <fabric@...>
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal 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 tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


    On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
    I'm using byfn w/o any modification

    - J

    On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - J

          On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
          Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

          1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
          2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
          a.) one peer in the org can only approve the chaincode one time
          b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
          c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

          2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

          Thanks so much for your response.


          Tong Li
          IBM Open Technology

          Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

          From: "Nikhil Gupta" <negupta@...>
          To: "David Enyeart" <enyeart@...>
          Cc: "Tong Li" <litong01@...>, fabric@...
          Date: 01/08/2020 08:53 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...




          The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

          The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



          -----fabric@... wrote: -----
          To: "Tong Li" <litong01@...>
          From: "David Enyeart"
          Sent by: fabric@...
          Date: 01/08/2020 12:28AM
          Cc: fabric@...
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

          1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

          1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

          {
          "approvals": {
          "org0examplecom": true,
          "org1examplecom": true
          }
          }

          That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

          peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
          2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
          2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

          2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

          ---
          Organizations:
          - &examplecom
          Name: examplecom
          ID: examplecom
          MSPDir: keyfiles/ordererOrganizations/example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Writers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Admins:
          Type: Signature
          Rule: "OR('examplecom.admin')"
          - &org0examplecom
          Name: org0examplecom
          ID: org0examplecom
          MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org0examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org0examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org0.example.com
          Port: 7051
          - Host: peer2.org0.example.com
          Port: 7051
          - &org1examplecom
          Name: org1examplecom
          ID: org1examplecom
          MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org1examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org1examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org1.example.com
          Port: 7051
          - Host: peer2.org1.example.com
          Port: 7051

          Capabilities:
          Channel: &ChannelCapabilities
          V2_0: true

          Orderer: &OrdererCapabilities
          V2_0: true

          Application: &ApplicationCapabilities
          V2_0: true

          Application: &ApplicationDefaults
          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"
          Endorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          Capabilities:
          <<: *ApplicationCapabilities

          Orderer: &OrdererDefaults
          OrdererType: etcdraft

          Addresses:
          - orderer1.example.com:7050
          - orderer2.example.com:7050
          - orderer3.example.com:7050

          BatchTimeout: 2s

          BatchSize:
          MaxMessageCount: 10
          AbsoluteMaxBytes: 99 MB
          PreferredMaxBytes: 512 KB

          EtcdRaft:
          Consenters:
          - Host: orderer1.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          - Host: orderer2.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          - Host: orderer3.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          BlockValidation:
          Type: ImplicitMeta
          Rule: "ANY Writers"

          Channel: &ChannelDefaults
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

          Capabilities:
          <<: *ChannelCapabilities

          Profiles:
          OrgChannel:
          Consortium: SampleConsortium
          <<: *ChannelDefaults
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - *org0examplecom
          - *org1examplecom
          Capabilities:
          <<: *ApplicationCapabilities

          OrdererGenesis:
          <<: *ChannelDefaults
          Capabilities:
          <<: *ChannelCapabilities
          Orderer:
          <<: *OrdererDefaults
          Organizations:
          - *examplecom
          Capabilities:
          <<: *OrdererCapabilities
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - <<: *examplecom
          Consortiums:
          SampleConsortium:
          Organizations:
          - *org0examplecom
          - *org1examplecom


          Tong Li
          IBM Open Technology










Re: chaincode 2.0 problems

indirajith
 

Thank you David Enyeart,

As you have suggested, the problem was with credentials and I have fixed them. Now the problem is during the commit stage. Even though both Orgs approved the CC package and they both endorse the commit, it fails with ' (ENDORSEMENT_POLICY_FAILURE) '. The reason behind this is statebased validator fails. I don't know how to meet this state-based endorsement policy. The peer logs are as follows:

PEER1_ORG2

2020-02-17 13:40:32.589 UTC [lifecycle] CheckCommitReadiness -> INFO 0c6 Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [lifecycle] CommitChaincodeDefinition -> INFO 0c7 Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.595 UTC [endorser] callChaincode -> INFO 0c8 finished chaincode: _lifecycle duration: 24ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.596 UTC [comm.grpc.server] 1 -> INFO 0c9 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:37306 grpc.code=OK grpc.call_duration=26.626315ms
2020-02-17 13:40:34.650 UTC [gossip.privdata] StoreBlock -> INFO 0ca [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.651 UTC [vscc] Validate -> ERRO 0cb VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] validateTx -> ERRO 0cc Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.651 UTC [committer.txvalidator] Validate -> INFO 0cd [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.652 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0ce Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.652 UTC [valimpl] preprocessProtoBlock -> WARN 0cf Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.713 UTC [kvledger] CommitLegacy -> INFO 0d0 [twoorgschannel] Committed block [15] with 1 transaction(s) in 61ms (state_validation=0ms block_and_pvtdata_commit=43ms state_commit=15ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0d1 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.599Z grpc.peer_address=192.168.176.103:37308 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125516881s

PEER2_ORG1

2020-02-17 13:40:32.563 UTC [lifecycle] CheckCommitReadiness -> INFO 09d Successfully checked commit readiness of chaincode name 'cctest' on channel 'twoorgschannel' with
definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [lifecycle] CommitChaincodeDefinition -> INFO 09e Successfully endorsed commit for chaincode name 'cctest' on channel 'twoorgschannel' with definition {sequence: 1, endorsement info: (version: '1', plugin: 'escc', init required: true), validation info: (plugin: 'vscc', policy: '12202f4368616e6e656c2f4170706c69636174696f6e2f456e646f7273656d656e74'), collections: (<nil>)}
2020-02-17 13:40:32.566 UTC [endorser] callChaincode -> INFO 09f finished chaincode: _lifecycle duration: 80ms channel=twoorgschannel txID=9cae9eca
2020-02-17 13:40:32.567 UTC [comm.grpc.server] 1 -> INFO 0a0 unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=192.168.176.103:56972 grpc.code=OK grpc.call_duration=82.034915ms
2020-02-17 13:40:34.657 UTC [gossip.privdata] StoreBlock -> INFO 0a1 [twoorgschannel] Received block [15] from buffer
2020-02-17 13:40:34.658 UTC [vscc] Validate -> ERRO 0a2 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] validateTx -> ERRO 0a3 Dispatch for transaction txId = 9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521 returned error: validation of endorsement policy for chaincode _lifecycle in tx 15:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
2020-02-17 13:40:34.659 UTC [committer.txvalidator] Validate -> INFO 0a4 [twoorgschannel] Validated block [15] in 1ms
2020-02-17 13:40:34.659 UTC [gossip.privdata] prepareBlockPvtdata -> INFO 0a5 Successfully fetched all eligible collection private write sets for block [15] channel=twoorgschannel
2020-02-17 13:40:34.659 UTC [valimpl] preprocessProtoBlock -> WARN 0a6 Channel [twoorgschannel]: Block [15] Transaction index [0] TxId [9cae9eca8ff21e30bbf8e9be2afeef63c88a76178b7e9da077b4012b322c6521] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
2020-02-17 13:40:34.720 UTC [kvledger] CommitLegacy -> INFO 0a7 [twoorgschannel] Committed block [15] with 1 transaction(s) in 60ms (state_validation=0ms block_and_pvtdata_commit=41ms state_commit=17ms) commitHash=[9d588ecb38fbb6e9b566d58287c642ca7cde5c0fa7d4e354027724eceb7248e9]
2020-02-17 13:40:34.724 UTC [comm.grpc.server] 1 -> INFO 0a8 streaming call completed grpc.service=protos.Deliver grpc.method=DeliverFiltered grpc.request_deadline=2020-02-17T13:41:02.598Z grpc.peer_address=192.168.176.103:56974 error="context finished before block retrieved: context canceled" grpc.code=Unknown grpc.call_duration=2.125825689s

Approvals:
{ "approvals": { "org1MSP": true, "org2MSP": true } }

Thank you.
Indirajith


On Thu, 6 Feb 2020 at 14:27, David Enyeart <enyeart@...> wrote:

This is not an issue with the submitting client credentials, it is an issue with the peer credentials not matching the org credentials in the channel config.

You must approve on a peer of your own org, before continuing on to the commit step (only the commit step is bound by the configured lifecycle endorsement policy).

So ENDORSEMENT_POLICY_FAILURE on approve step means that the credentials that the peer signed the endorsed approve transaction with, was not issued by that org's CA, as defined in the channel config.

It happens to me when I'm switching environments around. Double check the msp credentials specified in your peer's config against the org msp specified in your channel config transaction.

The msp locations for the org and peer are specified at:

https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml#L38
and
https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/core.yaml#L302

Note, the msp paths above are relative to the local FABRIC_CFG_PATH. This can get confusing... to better understand it, you can instead use a fully qualified msp path to ensure you are pointing to the correct credentials. e.g. to re-use cryptogen credentials from first-network sample, use:

<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/msp
and
<PATH TO SAMPLES>/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp


Dave Enyeart

"indirajith" ---02/06/2020 02:51:39 AM---Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful insta

From: "indirajith" <indirajithv@...>
To:
Cc: fabric <fabric@...>
Date: 02/06/2020 02:51 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
Sent by: fabric@...





Hi all, I am facing the same problem as Tong Li mentioned in the first email. After successful installation of  CC package on peers, the documents and other samples, get approval with in their org before committing the chaincode. But for me I can not get the installed package approved from the org. It says, 

` txid [f2d81371e4b62a37c32de0506643629cafaa4d7d4b73c4012bf7b24c3251cbf7] committed with status (ENDORSEMENT_POLICY_FAILURE) at 
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)` 

The LifeCycle endorsement policy says, org1MSP.peer. So, when I use peer's msp instead of org admin, it says, 

` Error: proposal 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 tried it on both peers of og org1. Getting endorsement policy failure from both. Or should I commit the package before getting approval? 

Thank you!
BR,
Indirajith.

On Fri, 10 Jan 2020 at 05:05, Jay Guo <guojiannan1101@...> wrote:
    Jason pointed out the problem:

    > You tried to approve the same definition twice, completely unmodified. This produced an empty write-set, because nothing changed. Since there was no change to a specific collection, but because we had to pick _some_ endorsement policy to validate your tx with, you get the default for `_lifecycle`.

    opened FAB-17371 for this

    - J


    On Fri, Jan 10, 2020 at 1:02 AM Jay Guo via Lists.Hyperledger.Org <guojiannan1101=gmail.com@...> wrote:
    I'm using byfn w/o any modification

    - J

    On Thu, Jan 9, 2020 at 9:25 PM <email4tong@...> wrote:
      Jay, how does your policy look like for both org and channel? Thanks.




      On Thursday, January 9, 2020, 4:47 AM, Jay Guo <guojiannan1101@...> wrote:
          I could reproduce this by approving the same definition twice (with same seq). It seems that the first approval is validated with /Channel/Application/Org1MSP/Endorsement, although the second is validate with /Channel/Application/LifecycleEndorsement

          - J

          On Thu, Jan 9, 2020 at 12:46 AM Tong Li <litong01@...> wrote:
          Thanks David and Nikhil for your response. I took David's suggestion and sent to multiple peers for commit which went through successfully. Then I tried the lifecycle chaincode approveformyorg command and lifecycle chaincode install few more times, here is what I found.

          1. Chaincode can be installed multiple times, if the chaincode package never changes, the returned package id will be the same. No errors.
          2. Command chaincode lifecycle approveformyorg behaves like this (at least from what I can figure):
          a.) one peer in the org can only approve the chaincode one time
          b.) the other peer in the org can also approve the chaincode but the sequence number has to increase by 1, this is after chaincode has been committed.
          c.) once the chaincode gets approved by a peer, that peer can not approve it the 2nd time. If you try the 2nd time, it will give you the same error like below:

          2020-01-08 16:31:53.754 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [af84dab09c428471a87aad3e9f921b8f876ecdc69b6b0b05fdf42d621cd3e31a] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          The behavior at 2 is a bit different from what David suggested earlier, I wonder if I misunderstood David's point. My endorsement policy is using the Majority.

          Thanks so much for your response.


          Tong Li
          IBM Open Technology

          Inactive hide details for"Nikhil Gupta" ---01/08/2020 08:53:34 AM---The approval is at the Org level. You only need to target one peer, and then the approval is distrib

          From: "Nikhil Gupta" <negupta@...>
          To: "David Enyeart" <enyeart@...>
          Cc: "Tong Li" <litong01@...>, fabric@...
          Date: 01/08/2020 08:53 AM
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...




          The approval is at the Org level. You only need to target one peer, and then the approval is distributed to other peers using gossip.

          The endorsement error also pops up if you try to commit a different chaincode definition than the one that was approved.



          -----fabric@... wrote: -----
          To: "Tong Li" <litong01@...>
          From: "David Enyeart"
          Sent by: fabric@...
          Date: 01/08/2020 12:28AM
          Cc: fabric@...
          Subject: [EXTERNAL] Re: [Hyperledger Fabric] chaincode 2.0 problems

          1. You should be able to re-approveformyorg on the same peer, and the other peer (although it only needs to be done on one peer per org). I've tried this and it works in my environment... I can't think of a reason why you'd get ENDORSEMENT_POLICY_FAILURE on subsequent trials, as the approveformyorg transaction only requires endorsement on the org's own peer. See if you can re-approveformyorg on the same peer as before, just to help narrow down the problem...

          2. Your LifecycleEndorsement policy is:

          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          This will require the chaincode commit to be endorsed by both orgs (majority of '2' is '2'). I suspect you only sent the chaincode commit to one of the org peers. Alternatively, you could update your config to indicate that either org can endorse the commit of a new chaincode, e.g.:

          LifecycleEndorsement:
          Type: Signature
          Rule: "OR('org0examplecom.admin.peer','org1examplecom.peer')"


          Dave Enyeart

          Inactive hide details for"Tong Li" ---01/07/2020 11:19:18 PM---Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincod

          From: "Tong Li" <litong01@...>
          To: fabric@...
          Date: 01/07/2020 11:19 PM
          Subject: [EXTERNAL] [Hyperledger Fabric] chaincode 2.0 problems
          Sent by: fabric@...





          Have been trying to use the new peer lifecycle command to approve and eventually commit the chaincode but I have found two problems.

          1. with 2 orgs and total of 4 peers, I can only do approveformyorg exactly two approvals. Once I have two approvals, see below output from checkcommitreadiness

          {
          "approvals": {
          "org0examplecom": true,
          "org1examplecom": true
          }
          }

          That shows that I have two approvals from two different orgs. Then I tried to use two other peers to do the approval, when I tried that, I got an error below.

          peer lifecycle chaincode approveformyorg --channelID mychannel --name simple2 --version 1.0 --package-id simple2_1.0:46b05e58222be471f9c305ad2ca3374e25343076502adcc82159865986dc3288 --init-required --sequence 1 --tls true --cafile $ORDERER_TLS_CA
          2020-01-08 04:04:50.026 UTC [cli.lifecycle.chaincode] setOrdererClient -> INFO 001 Retrieved channel (mychannel) orderer endpoint: orderer1.example.com:7050
          2020-01-08 04:04:52.130 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [2fb5dafa70316b2d69a736ab8a1be399668f724646e66241ab4c2ce28f873c80] committed with status (ENDORSEMENT_POLICY_FAILURE) at
          Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)

          Though I already have two approvals, I expect more approval from different peers wont fail, but it did, I do not know if that is expected behavior, please someone confirm one way or the other.

          2. With two approvals from both orgs, I should have already met the majority requirement, but when I tried to do the commit, I was getting the exact same error as the approveformyorg process. Can someone please help with this problem? Please see the configtx.yaml file below if that can give a bit of clue. Thanks very much.

          ---
          Organizations:
          - &examplecom
          Name: examplecom
          ID: examplecom
          MSPDir: keyfiles/ordererOrganizations/example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Writers:
          Type: Signature
          Rule: "OR('examplecom.member')"
          Admins:
          Type: Signature
          Rule: "OR('examplecom.admin')"
          - &org0examplecom
          Name: org0examplecom
          ID: org0examplecom
          MSPDir: keyfiles/peerOrganizations/org0.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.peer', 'org0examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org0examplecom.admin', 'org0examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org0examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org0examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org0.example.com
          Port: 7051
          - Host: peer2.org0.example.com
          Port: 7051
          - &org1examplecom
          Name: org1examplecom
          ID: org1examplecom
          MSPDir: keyfiles/peerOrganizations/org1.example.com/msp
          Policies:
          Readers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.peer', 'org1examplecom.client')"
          Writers:
          Type: Signature
          Rule: "OR('org1examplecom.admin', 'org1examplecom.client')"
          Admins:
          Type: Signature
          Rule: "OR('org1examplecom.admin')"
          Endorsement:
          Type: Signature
          Rule: "OR('org1examplecom.peer')"

          AnchorPeers:
          - Host: peer1.org1.example.com
          Port: 7051
          - Host: peer2.org1.example.com
          Port: 7051

          Capabilities:
          Channel: &ChannelCapabilities
          V2_0: true

          Orderer: &OrdererCapabilities
          V2_0: true

          Application: &ApplicationCapabilities
          V2_0: true

          Application: &ApplicationDefaults
          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          LifecycleEndorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"
          Endorsement:
          Type: ImplicitMeta
          Rule: "MAJORITY Endorsement"

          Capabilities:
          <<: *ApplicationCapabilities

          Orderer: &OrdererDefaults
          OrdererType: etcdraft

          Addresses:
          - orderer1.example.com:7050
          - orderer2.example.com:7050
          - orderer3.example.com:7050

          BatchTimeout: 2s

          BatchSize:
          MaxMessageCount: 10
          AbsoluteMaxBytes: 99 MB
          PreferredMaxBytes: 512 KB

          EtcdRaft:
          Consenters:
          - Host: orderer1.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer1.example.com/tls/server.crt
          - Host: orderer2.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/server.crt
          - Host: orderer3.example.com
          Port: 7050
          ClientTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt
          ServerTLSCert: keyfiles/ordererOrganizations/example.com/orderers/orderer3.example.com/tls/server.crt

          Organizations:
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"
          BlockValidation:
          Type: ImplicitMeta
          Rule: "ANY Writers"

          Channel: &ChannelDefaults
          Policies:
          Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
          Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
          Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

          Capabilities:
          <<: *ChannelCapabilities

          Profiles:
          OrgChannel:
          Consortium: SampleConsortium
          <<: *ChannelDefaults
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - *org0examplecom
          - *org1examplecom
          Capabilities:
          <<: *ApplicationCapabilities

          OrdererGenesis:
          <<: *ChannelDefaults
          Capabilities:
          <<: *ChannelCapabilities
          Orderer:
          <<: *OrdererDefaults
          Organizations:
          - *examplecom
          Capabilities:
          <<: *OrdererCapabilities
          Application:
          <<: *ApplicationDefaults
          Organizations:
          - <<: *examplecom
          Consortiums:
          SampleConsortium:
          Organizations:
          - *org0examplecom
          - *org1examplecom


          Tong Li
          IBM Open Technology









Re: 7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Trevor Lee Oakley <trevor@...>
 

Is there a work around for this?

--------------Original Message--------------

From: "Bret Harrison" <beharrison@...>
Sent: Monday, February 17, 2020 08:37:AM
To: fabric@...
Subject: Re: [Hyperledger Fabric] 7.1.3 of the Tutorial (page 188) v2.0.0
pdf

We have a PR in review to fix the following issue
Failed to register user "user1": TypeError: gateway.getClient is not a
function

See https://github.com/hyperledger/fabric-samples/pull/117


Re: Proposal : Hyperledger Fabric block archiving

nekia <atsushin@...>
 

Hi,

I figured out that it's quite difficult to estimate maximum size in advance to align metadata size on each orderer. So we've decided to change to handle archive data at block level, not at blockfile level. By managing archived data at block level, we can avoid the following issues:
  • The layout of blockfile with same suffix is not always identical among peers in an organization
  • Because of this variance of the layout, each peer can't get access to archived data by using original block location info recorded in block index DB
I've put together overview of the new approach in the following slide.
HLF Block Archiving - Google Slides

In the feedbacks we got in this thread, implementing separately from fabric core has been mentioned several times. We have not been able to offer this feature as a pluggable module for ledger layer of fabric so far. One of the main reasons of it is that we need to hook the local file access when reading block data from local file system.

Do you think this project can compensate or coexist the functionality offered by 'ledger checkpoint and pruning' feature which is planned to be added to v2.x?

Cheeers,
Atsushi


Re: 7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Bret Harrison <beharrison@...>
 

We have a PR in review to fix the following issue
Failed to register user "user1": TypeError: gateway.getClient is not a function


Next Hyperledger Fabric Application Developer Community call - this Thursday, Feb 20th @ 4pm UTC (4pm UK) - 11am ET, 8am PT

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday Feb 20th @ 4pm UTC (4pm UK) - 11am ET (-5 hrs), 8am PT(-8 hrs) - see time zones.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc -  NodeJS/TypeScript, Java, Go etc etc) 
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


#fabric #configtxgen #fabric-orderer #fabric #configtxgen #fabric-orderer

Jean-Gaël Dominé <jgdomine@...>
 

Hi,

Until now, to set up a Raft Fabric network, I had a batch in charge of registering and enrolling all the identities (admin, orderers and peers), creating the system and application channel genesis blocks.
What I'd like to do is to move the enrollment part to each component (peers and orderers) when they start up so that the batch is now only in charge of the enrolling of admins and creating the genesis blocks.
But the issue is that with Raft as the genesis block must contain each orderer TLS certificate. So the orderer can't enroll itself before startup because it will need the system channel genesis block to start and I can't create this genesis block without having the TLS certificates.

So it's a vicious circle and I don't see a nice way to fix this.

Any idea of how to do that? In your cases, how did you automate this part (generation of certificates and genesis blocks creation) in a nice way?

Thanks

JG


divya.s@...
 

I have installed hyperledger fabric 2.0.0. When I try to run the fabcar example, I am getting an error like this "Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded".

When I checked in docker logs using docker logs peer0.org1.example.com, It shows warning "Retrying couchdb request in 250ms. Error:Get http://couchdb0:5984/: dial tcp 172.22.0.8:5984: connect: connection refused".

I pruned all the docker images,volumes, networks and installed again. I have tried adding dns search in .yml files. And tried checking docker network inspect. But nothing resolves. Kindly help to solve this


7.1.3 of the Tutorial (page 188) v2.0.0 pdf

Trevor Lee Oakley <trevor@...>
 

I am working via the fabcar examples and I have an error; I can register the admin user and I get the wallet entry. But when I try and use node registerUser.js I get an error (below) - not a function. I did not change anything and the network is running, it has the CA working. 
 
 
:~/fabric-samples/fabcar/javascript/wallet$ ll
total 12
drwxrwxr-x 2 ubuntu ubuntu 4096 Feb 17 03:40 ./
drwxrwxr-x 4 ubuntu ubuntu 4096 Feb 17 03:46 ../
-rw-rw-r-- 1 ubuntu ubuntu    0 Feb 15 08:00 .gitkeep
-rw-rw-r-- 1 ubuntu ubuntu 1121 Feb 16 12:07 admin.id
 
 
~/fabric-samples/fabcar/javascript$ node registerUser.js 
Wallet path: /home/ubuntu/fabric-samples/fabcar/javascript/wallet
Failed to register user "user1": TypeError: gateway.getClient is not a function
 
 
     const gateway = new Gateway();
        await gateway.connect(ccpPath, { wallet, identity: 'admin', discovery: { enabled: true, asLocalhost: true } });
        // Get the CA client object from the gateway for interacting with the CA.
        const client = gateway.getClient();
        const ca = client.getCertificateAuthority();
        const adminUser = await client.getUserContext('admin', false);
 
 
I get this for Gateway for a console.log -
 
Gateway {
  client: Client {
    type: 'Client',
    name: 'gateway client',
    mspid: null,
    _tls_mutual: {
      selfGenerated: true,
      clientKey: '-----BEGIN PRIVATE KEY-----\r\n' +
        'MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgZVYzMEW42hnKm2D5\r\n' +
        'LsjRAMK3iQG34lrB1oF3j6C/n06hRANCAAR6es5QJNc1WdgC9hVRyEnl/YHeYtk4\r\n' +
        'lexkh++nGRtspkmb0UIB/EY9E5LPh/SXEcbTZm6II81TZNdm3e3NASjO\r\n' +
        '-----END PRIVATE KEY-----\r\n',
      clientCert: '-----BEGIN CERTIFICATE-----\r\n' +
        'MIIBVTCB+6ADAgECAgEEMAoGCCqGSM49BAMCMBgxFjAUBgNVBAMMDWZhYnJpYy1j\r\n' +
        'b21tb24wIhgPMjAyMDAyMTcwMjMxMjhaGA8yMDIwMDIxNzIwMzQ0OFowGDEWMBQG\r\n' +
        'A1UEAwwNZmFicmljLWNvbW1vbjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABHp6\r\n' +
        'zlAk1zVZ2AL2FVHISeX9gd5i2TiV7GSH76cZG2ymSZvRQgH8Rj0Tks+H9JcRxtNm\r\n' +
        'bogjzVNk12bd7c0BKM6jMjAwMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgbAMBMG\r\n' +
        'A1UdJQQMMAoGCCsGAQUFBwMCMAoGCCqGSM49BAMCA0kAMEYCIQCQkeSzqt3LI747\r\n' +
        'NG7WWP9hNU+aVi82+XT1eyfbzjgriwIhAOnXOCVrAmQtpANJFXs/4sDbQ7ozQlBy\r\n' +
        'U4/YRulyQXUN\r\n' +
        '-----END CERTIFICATE-----\r\n'
    },
    endorsers: Map {},
    committers: Map {},
    channels: Map {},
    centralizedOptions: null
  },
  wallet: null,
  identityContext: IdentityContext {
    type: 'IdentityContext',
    client: Client {
      type: 'Client',
      name: 'gateway client',
      mspid: null,
      _tls_mutual: [Object],
      endorsers: Map {},
      committers: Map {},
      channels: Map {},
      centralizedOptions: null
    },
    user: User {
      type: 'User',
      _name: 'admin',
      _roles: null,
      _affiliation: '',
      _enrollmentSecret: '',
      _identity: [Identity],
      _signingIdentity: [SigningIdentity],
      _mspId: 'Org1MSP',
      _cryptoSuite: [CryptoSuite_ECDSA_AES]
    },
    options: {},
    name: 'admin',
    mspid: 'Org1MSP',
    transactionId: null,
    nonce: null
  },
  networks: Map {},
  options: {
    query: { timeout: 30, strategy: [Function: MSPID_SCOPE_SINGLE] },
    transaction: {
      endorseTimeout: 30,
      commitTimeout: 300,
      strategy: [Function: MSPID_SCOPE_ALLFORTX]
    },
    discovery: { enabled: true, asLocalhost: true },
    wallet: Wallet {
      providerRegistry: [IdentityProviderRegistry],
      store: [FileSystemWalletStore]
    },
    identity: 'admin'
  }
}
Failed to register user "user1": TypeError: gateway.getClient is not a function
ubuntu@ip-10-0-1-151:~/fabric-samples/fabcar/javascript$ 
 


Re: How does the client know which are the EPs?

Trevor Lee Oakley <trevor@...>
 

I think I have an answer - use EXTERNALENDPOINTS and the discovery service.
 
 
 

From: "Trevor Lee Oakley" <trevor@...>
Sent: 16 February 2020 22:44
To: fabric@...
Subject: [Hyperledger Fabric] How does the client know which are the EPs?
 
I understand the client sends the proposal to all endorsing peers, but how are these identified to the client?
 
I assume the client needs to query a service in the network to find out the EPs or hold a local copy of the EPs; then somehow identify how to reach them by a network identifier or address.
 
Trevor
 
 


Re: How does the client know which are the EPs?

Joe Alewine <joe.alewine@...>
 

 
Might be what you're looking for.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Trevor Lee Oakley" <trevor@...>
Sent by: fabric@...
To: <fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] How does the client know which are the EPs?
Date: Sun, Feb 16, 2020 10:17 PM
 
I understand the client sends the proposal to all endorsing peers, but how are these identified to the client?
 
I assume the client needs to query a service in the network to find out the EPs or hold a local copy of the EPs; then somehow identify how to reach them by a network identifier or address.
 
Trevor
 
 
 


How does the client know which are the EPs?

Trevor Lee Oakley <trevor@...>
 

I understand the client sends the proposal to all endorsing peers, but how are these identified to the client?
 
I assume the client needs to query a service in the network to find out the EPs or hold a local copy of the EPs; then somehow identify how to reach them by a network identifier or address.
 
Trevor
 
 


Re: How to error check for wrong Admin MSP certificate on network #fabric #docker #fabric-ca

Gari Singh <garis@...>
 

BatchSize actually falls under the Orderer group and not the Application group.
Therefore, you need a majority of the orderer admins to sign the config update.
Given you state this is a simple network, I'll assume you only have a single orderer org, so you just need to sign the config update using an orderer admin identity.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Niklas Krohn"
Sent by: fabric@...
Date: 02/15/2020 09:43AM
Subject: [EXTERNAL] [Hyperledger Fabric] How to error check for wrong Admin MSP certificate on network #fabric #docker #fabric-ca

Hi all,

I have the most simple fabric-network, and wanted to make a simple channel-config update of the batchsize (https://hyperledger-fabric.readthedocs.io/en/release-1.4/config_update.html)

Everything is fine, until I want to post the modified config to the orderer/network, then I receive the following error inside CLI container, as peer0.org1 adm:



Orderer log:




So according to google-searches, I found this topic which states that there migth be two possible reasons (https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails)
- the MSP ID that was passed as a parameter with the request was not recognized by the ordering service
- If you are updating an application channel, this error could occur if your organization is not yet a member of the channel you are trying to update

The Org1 is indeed part of the channel already, as it created and joined the channel with the bootstrap:






So then I expect the issue to be a mismatch between MSP-ID somewhere. The topic of certificates are somewhat new to me, can anybody guide me in direction of error checking this myself, which files should I compare to see what MSP-file is wrong?

This is the cert-file inside the CLI container for peer0.org1 admin:



This is the Admin-file on the host machine:



CA-related info for Org1:




This is the policy settings inside the channel-config block:



Thanks for any input that can help me compare the rigth certificates, to spot the wrong one and why it is wrong.


How to error check for wrong Admin MSP certificate on network #fabric #docker #fabric-ca

Niklas Krohn
 

Hi all, 

I have the most simple fabric-network, and wanted to make a simple channel-config update of the batchsize (https://hyperledger-fabric.readthedocs.io/en/release-1.4/config_update.html)

Everything is fine, until I want to post the modified config to the orderer/network, then I receive the following error inside CLI container, as peer0.org1 adm: 



Orderer log:




So according to google-searches, I found this topic which states that there migth be two possible reasons (https://stackoverflow.com/questions/57662562/when-i-try-to-create-a-channel-using-hyperledger-fabric-the-request-fails)
the MSP ID that was passed as a parameter with the request was not recognized by the ordering service
If you are updating an application channel, this error could occur if your organization is not yet a member of the channel you are trying to update

The Org1 is indeed part of the channel already, as it created and joined the channel with the bootstrap: 






So then I expect the issue to be a mismatch between MSP-ID somewhere. The topic of certificates are somewhat new to me, can anybody guide me in direction of error checking this myself, which files should I compare to see what MSP-file is wrong?

This is the cert-file inside the CLI container for peer0.org1 admin: 



This is the Admin-file on the host machine: 



CA-related info for Org1: 




This is the policy settings inside the channel-config block: 



Thanks for any input that can help me compare the rigth certificates, to spot the wrong one and why it is wrong. 

3801 - 3820 of 11527