Re: chaincode 2.0 problems


David Enyeart
 

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








Join fabric@lists.hyperledger.org to automatically receive all group messages.