Welcome to the new Linux Foundation Forum!

Lab 8. Advanced Channel Management - Error when creating new channel: "Attempted to include a membe"

Hi,

I'm working on the Lab 8 of the document LFS272 - Labs_5.09.2019.pdf, an I'm failing to understand a blocking error.

In the Lab, we must create multiple channels:
1. All Org1 peers & All Org 2 peers
2. All Org2 peers Only
3. All Org1 Peers only

We must first generate the channels transactions, and I successfully did that. But, after have an issue when I try to create the channel 1(Org1 & Org2).

The command is:
configtxgen -profile OrgOneChannel -outputCreateChannelTx ./config/OrgOneChannel.tx -channelID orgonechannel

And the error message is:
Error: got unexpected status: BAD_REQUEST -- Attempted to include a member which is not in the consortium

The error message is rather explicite, Org2 is indeed not in the consortium defined in the profile section of the file configtx.yaml. In the previous Lab(Lab 7), we added Org2 only in the existing application channel allarewelcome, not in the system channel.

My supposition is that in order to be able to create the channel including Org1 and Org2, Org2 must may be be present in the consortium defined in the system channel profile in the file configtx.yaml.

Do you have an idea?

Comments

  • I need a solution for this to..

  • akoitaakoita Posts: 10

    Sorry, there is an error in the issue description in my previous message, about the commands executed.

    So I resume.

    The command to generate the transaction of the channel between Org1 and Org2 is:

    configtxgen -profile AllAreWelcomeTwo -outputCreateChannelTx ./config/AllAreWelcomeTwo.tx -channelID allarewelcometwo
    

    The command to create the channel is then:

    peer channel create -o orderer.example.com:7050 -f ./config/AllAreWelcomeTwo.tx -c allarewelcometwo
    

    This does not work, and produces the error message:

    Error: got unexpected status: BAD_REQUEST -- Attempted to include a member which is not in the consortium
    

    The error message is rather explicite, Org2 is indeed not in the consortium defined in the profile section of the file configtx.yaml. In the previous Lab(Lab 7), we added Org2 only in the existing application channel allarewelcome, not in the orderer system channel.

    My supposition is that in order to be able to create the channel including Org1 and Org2, Org2 must maybe be present in the consortium defined in the system channel profile in the file configtx.yaml.

    And it would also be very useful to explain in Fabric doc how the definition of the configuration of the consortium can cause this error.

    Ah, this error is well mentioned in the lab 8, and the lab 8 asks to switch to Org2 environment variables in order to fix it. I did that, and executed the channel creation command again, but it did not fixed the error.

  • akoitaakoita Posts: 10

    An update.

    So I went on the hypotheses that Org2 must be added to the system channel consortium. For that, two possibilities:

    1. Update the configtx.yaml an recreate the network
    2. Update dynamically the system channel, like in the Lab 7.

    The first option is not very interesting because I think that at this point, the goal is to learn how to dynamically update the network. So I had to update the system channel like in Lab 7, with a slightly difference. I performed the following operations for that:

    export CORE_PEER_LOCALMSPID=OrdererMSP
    export CORE_PEER_ADDRESS=orderer.example.com:7050
    export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/[email protected]/msp
    peer channel fetch config genesis.pb -o orderer.example.com:7050 -c testchainid
    configtxlator proto_decode --input genesis.pb --type common.Block | jq .data.data[0].payload.data.config > genesisBlock.json
    jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"SampleConsortium":{"groups":{"Org2MSP":.[1]}}}}}}}' genesisBlock.json ./config/org2_definition.json > genesisBlockChanges.json
    configtxlator proto_encode --input genesisBlock.json --type common.Config --output genesisBlock.pb
    configtxlator proto_encode --input genesisBlockChanges.json --type common.Config --output genesisBlockChanges.pb
    configtxlator compute_update --channel_id testchainid --original genesisBlock.pb --updated genesisBlockChanges.pb --output genesisBlocProposal_Org2.pb
    configtxlator proto_decode --input genesisBlocProposal_Org2.pb --type common.ConfigUpdate | jq . > genesisBlocProposal_Org2.json
    echo '{"payload":{"header":{"channel_header":{"channel_id":"testchainid", "type":2}},"data":{"config_update":'$(cat genesisBlocProposal_Org2.json)'}}}' | jq . > genesisBlocProposalReady.json
    configtxlator proto_encode --input genesisBlocProposalReady.json --type common.Envelope --output genesisBlocProposalReady.pb
    peer channel update -f genesisBlocProposalReady.pb -c testchainid -o orderer.example.com:7050
    

    The update worked well. An after the update I could create the channel allarewelcometwo with success.

    However, I dont know if this was the right solution to the problem.

  • @akoita , thanks alot. This fixed the issue for me!

  • akoitaakoita Posts: 10

    Glad to hear that @benjamin.verhaegen :)

  • indirajithindirajith Posts: 42

    From the following link, https://hyperledger-fabric.readthedocs.io/en/release-1.4/glossary.html?highlight=configtx.yaml

    it says "Consortium
    A consortium is a collection of non-orderer organizations on the blockchain network. These are the organizations that form and join channels and that own peers. While a blockchain network can have multiple consortia, most blockchain networks have a single consortium. At channel creation time, all organizations added to the channel must be part of a consortium. However, an organization that is not defined in a consortium may be added to an existing channel."

    From the above paragraph, it seems like, an organisation can be added to a channel even if it is not in the consortium. If so why do we get the error you have mentioned?

    Second doubt: How did you come to know the system channel ID (orderer system channel) is 'testchainid'? Can you please explain how to know this?

    3rd: As Akoita said above, "Org2 is indeed not in the consortium defined in the profile section of the file configtx.yaml" that means the first profile, which is the orderer system channel profile (genesis), right?

    Even though I have completed this lab yet, I don't feel confident. I think I need more explanation need to be added to the materials provided.

    Can anyone please help me understand these things? Thanks in advance!

  • akoitaakoita Posts: 10

    @indirajith

    From the above paragraph, it seems like, an organisation can be added to a channel even if it is not in the consortium. If so why do we get the error you have mentioned?

    Yes, I also find that the concept of a "consortium" is not well enough explained. I underline this in my comments above.

    Second doubt: How did you come to know the system channel ID (orderer system channel) is 'testchainid'? Can you please explain how to know this?

    Yes, the default name of the system channel is not clearly mentioned in the Fabric documentation(<=1.3). But by following the tutorials, you can find places where it is mentioned. For example in this tutorial of version 1.3: https://hyperledger-fabric.readthedocs.io/en/release-1.3/upgrading_your_network_tutorial.html#orderer-system-channel_your_network_tutorial.html#orderer-system-channel

    However, it is now recommended to give the name of the system channel when generating the genesis block (option -channelID): https://hyperledger-fabric.readthedocs.io/en/release-1.4/build_network.html#create-a-channel-configuration-transaction

    Otherwise, by converting the genesis block to json for example, you can also see the name of the system channel in readable format.

  • @akoita said:
    An update.

    So I went on the hypotheses that Org2 must be added to the system channel consortium. For that, two possibilities:

    1. Update the configtx.yaml an recreate the network
    2. Update dynamically the system channel, like in the Lab 7.

    The first option is not very interesting because I think that at this point, the goal is to learn how to dynamically update the network. So I had to update the system channel like in Lab 7, with a slightly difference. I performed the following operations for that:

    export CORE_PEER_LOCALMSPID=OrdererMSP
    export CORE_PEER_ADDRESS=orderer.example.com:7050
    export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/[email protected]/msp
    peer channel fetch config genesis.pb -o orderer.example.com:7050 -c testchainid
    configtxlator proto_decode --input genesis.pb --type common.Block | jq .data.data[0].payload.data.config > genesisBlock.json
    jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"SampleConsortium":{"groups":{"Org2MSP":.[1]}}}}}}}' genesisBlock.json ./config/org2_definition.json > genesisBlockChanges.json
    configtxlator proto_encode --input genesisBlock.json --type common.Config --output genesisBlock.pb
    configtxlator proto_encode --input genesisBlockChanges.json --type common.Config --output genesisBlockChanges.pb
    configtxlator compute_update --channel_id testchainid --original genesisBlock.pb --updated genesisBlockChanges.pb --output genesisBlocProposal_Org2.pb
    configtxlator proto_decode --input genesisBlocProposal_Org2.pb --type common.ConfigUpdate | jq . > genesisBlocProposal_Org2.json
    echo '{"payload":{"header":{"channel_header":{"channel_id":"testchainid", "type":2}},"data":{"config_update":'$(cat genesisBlocProposal_Org2.json)'}}}' | jq . > genesisBlocProposalReady.json
    configtxlator proto_encode --input genesisBlocProposalReady.json --type common.Envelope --output genesisBlocProposalReady.pb
    peer channel update -f genesisBlocProposalReady.pb -c testchainid -o orderer.example.com:7050
    

    The update worked well. An after the update I could create the channel allarewelcometwo with success.

    However, I dont know if this was the right solution to the problem.

    Thank you for the answer @akoita ! This worked for me too.

    However, I have to ask - how are we supposed to understand by ourselves when it is not mentioned in the lab documents?

  • akoitaakoita Posts: 10

    Glad to hear that @Niklaskkkk!

    However, I have to ask - how are we supposed to understand by ourselves when it is not mentioned in the lab documents?

    I don't see any indication in the lab document suggesting that this solution is the right one, I said it in the message that you quoted. I was just motivated and found that it would be a good exercise to try this solution.

  • @akoita said:
    Glad to hear that @Niklaskkkk!

    However, I have to ask - how are we supposed to understand by ourselves when it is not mentioned in the lab documents?

    I don't see any indication in the lab document suggesting that this solution is the right one, I said it in the message that you quoted. I was just motivated and found that it would be a good exercise to try this solution.

    Yes. It is mentioned in the course video I found out, but not in the PDF document. Could be a future improvement to next upgrade of course documentation. :)

  • Thank you @akoita , but I receive this error
    Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'myordererchannel': error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Consortiums/SampleConsortium not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
    Is there a way to know what's the current policy? I have not explicitly mentioned any policy in my configtx.yaml. Its a very basic one. I have also signed the transaction update with orderer org admin and org1 admin still, I get the aforementioned error. I believe the genesis block has all these details, but as it is a huge json file after decoding, is there any tutorial on how to understand this file ?

  • akoitaakoita Posts: 10

    You're welcome @indirajith.

    Is there a way to know what's the current policy?
    ...
    I believe the genesis block has all these details, but as it is a huge json file after decoding, is there any tutorial on how to understand this file ?

    This documentation explains a little the logic of the structure of the configuration of a channel: https://hyperledger-fabric.readthedocs.io/en/release-1.4/config_update.html
    An example of configuration is included in the doc, you have to click on the arrow to make it appear. From this doc:

    A config might look intimidating in this form, but once you study it you’ll see that it has a logical structure.

    It may be less accessible, but I find that this doc also helps to understand the logic of the structure of the configurations: https://hyperledger-fabric.readthedocs.io/en/release-1.4/configtx.html

    I am far from having understood everything about this configuration, but this is basically how it should be read. Each node of this JSON is a "group". And the structure of a group is:

    • If any, the "included groups" in the group
    • The group's "modification policy"
    • If any, the group's "policies definitions"
    • If any, the "values" of the group
    • The update version of the group

    From this explanation, you should be able to find the consortium modification policy appearing in the JSON.

    I'm not sure what action you were trying when you had this error. If you were trying to add Org2 to the consortium, it seems to me that the corresponding policy is "mod_policy": "/Channel/Orderer/Admins" , at least in my configuration, in which case the transaction would need to be signed with only the orderer admin, which is done automatically when submitting the transaction.

    Otherwise, can you provide the exact commands you are executing?

  • Thank you @akoita , but still I get the same problem.
    [grpc] HandleSubConnStateChange -> DEBU 04a pickfirstBalancer: HandleSubConnStateChange: 0xc0004a7930, READY Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'ordererchannel': error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Consortiums/SampleConsortium not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
    I signed the .pb file with orderer admin, org1 admin and org1 peer2 admin, still I get the above error. I don't know how to verify the policy from the block. The structure kind of okay but extracting exact values from the genesis block is still I find it difficult. There are two kinds of admins, one is the admin for the org and other is the admin of individual peers. who should sign the block?

    Thank you for your patience!

  • Finally it worked. I think I used not the right principal for the operation. But, I have one more doubt, when we specify the msp for admin user, the msp has the same certificate in its sign cert and also the admin cert. Is it the correct way of doing it? Thank you Akoita for your help!

  • The genesis (orderer) block file doesn't have Org2 in the Consortium and you'll receive BAD_REQUEST -- Attempted to include a member which is not in the consortium when you try to create the channel.

    You can inspect that block file with ../bin/configtxgen -inspectBlock ./config/genesis.block

    Info: If you check the orderer environment variables, you'll notice it points to:
    ORDERER_GENERAL_GENESISFILE=/etc/hyperledger/configtx/genesis.block

    Try this:
    1. Edit the configtx.yaml file and add Org2 to the SampleConsortium section

    Profiles:

    OneOrgOrdererGenesis:
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    
    1. Exit and save the file and issue this command to overwrite the file.
      ../bin/configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block

    Inspect if you wish:
    ../bin/configtxgen -inspectBlock ./config/genesis.block

    1. remove the docker container with the force option (for sanity)
      docker container rm orderer.example.com -f

    2. Start the container
      docker-compose -f docker-compose.yml up -d orderer.example.com

    3. Then docker exec into CLI using Org2's identity and issue the create channel command:
      peer channel create -o orderer.example.com:7050 -f ./config/AllAreWelcomeTwo.tx -c allarewelcometwo

  • koakhkoakh Posts: 11

    thanks @GregMead this works :), another solution for all the problems that we encounter trying to follow the pdf

  • <

    blockquote class="Quote UserQuote">

    <

    div class="QuoteText">

    <

    p>
    The genesis (orderer) block file doesn't have Org2 in the Consortium and you'll receive BAD_REQUEST -- Attempted to include a member which is not in the consortium when you try to create the channel.

    You can inspect that block file with ../bin/configtxgen -inspectBlock ./config/genesis.block

    Info: If you check the orderer environment variables, you'll notice it points to:
    ORDERER_GENERAL_GENESISFILE=/etc/hyperledger/configtx/genesis.block

    Try this:
    1. Edit the configtx.yaml file and add Org2 to the SampleConsortium section

    Profiles:

    OneOrgOrdererGenesis:
    Orderer:
    <<: *OrdererDefaults
    Organizations:
    - *OrdererOrg
    Consortiums:
    SampleConsortium:
    Organizations:
    - *Org1
    - *Org2
    Exit and save the file and issue this command to overwrite the file.
    ../bin/configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block
    Inspect if you wish:
    ../bin/configtxgen -inspectBlock ./config/genesis.block

    remove the docker container with the force option (for sanity)
    docker container rm orderer.example.com -f

    Start the container
    docker-compose -f docker-compose.yml up -d orderer.example.com
    [url=http://www.rachat-de-credit-simulation.com/comparatif] meilleur taux [/url]
    Then docker exec into CLI using Org2's identity and issue the create channel command:
    peer channel create -o orderer.example.com:7050 -f ./config/AllAreWelcomeTwo.tx -c allarewelcometwo


    Hello, can I find out more? by the way thanks for this info> @indirajith said:

    Thank you @akoita , but still I get the same problem.
    [grpc] HandleSubConnStateChange -> DEBU 04a pickfirstBalancer: HandleSubConnStateChange: 0xc0004a7930, READY Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'ordererchannel': error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Consortiums/SampleConsortium not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
    I signed the .pb file with orderer admin, org1 admin and org1 peer2 admin, still I get the above error. I don't know how to verify the policy from the block. The structure kind of okay but extracting exact values from the genesis block is still I find it difficult. There are two kinds of admins, one is the admin for the org and other is the admin of individual peers. who should sign the block?

    Thank you for your patience!

    Hello, can I find out more? by the way thanks for this info

  • eecszceecszc Posts: 11

    @GregMead said:
    The genesis (orderer) block file doesn't have Org2 in the Consortium and you'll receive BAD_REQUEST -- Attempted to include a member which is not in the consortium when you try to create the channel.

    You can inspect that block file with ../bin/configtxgen -inspectBlock ./config/genesis.block

    Info: If you check the orderer environment variables, you'll notice it points to:
    ORDERER_GENERAL_GENESISFILE=/etc/hyperledger/configtx/genesis.block

    Try this:
    1. Edit the configtx.yaml file and add Org2 to the SampleConsortium section

    Profiles:

    OneOrgOrdererGenesis:
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    
    1. Exit and save the file and issue this command to overwrite the file.
      ../bin/configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block

    Inspect if you wish:
    ../bin/configtxgen -inspectBlock ./config/genesis.block

    1. remove the docker container with the force option (for sanity)
      docker container rm orderer.example.com -f

    2. Start the container
      docker-compose -f docker-compose.yml up -d orderer.example.com

    3. Then docker exec into CLI using Org2's identity and issue the create channel command:
      peer channel create -o orderer.example.com:7050 -f ./config/AllAreWelcomeTwo.tx -c allarewelcometwo

    Hi, GregMead.
    after doing this, i got the error:
    Error: got unexpected status: BAD_REQUEST -- error validating channel creation transaction for new channel 'orgtwochannel', could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied

    i'v check the genesis.block and the channelcreationpolicy is as below
    "values": {
    "ChannelCreationPolicy": {
    "mod_policy": "/Channel/Orderer/Admins",
    "value": {
    "type": 3,
    "value": {
    "rule": "ANY",
    "sub_policy": "Admins"
    }
    },
    "version": "0"
    }
    },

    i think "any" means Org1 and Org2 both can create new channel by itself.
    can you give some clues.
    thanks

  • The channel you listed 'orgtwochannel' has a consortium of just Org2.
    Try:
    export CORE_PEER_LOCALMSPID="Org2MSP"

    export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp

    export CORE_PEER_ADDRESS=peer0.org2.example.com:7051

    Warning** the above variables are just for the lab.

    Then issue:
    peer channel create -o orderer.example.com:7050 -f ./config/OrgTwoChannel.tx -c orgtwochannel

    I tested this on the BYFN example (creating the .tx file, etc).

    Below is me using the Org1 or Orderer Admin first to show the error, then swtiching over to Org2 admin to show success.

    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel create -o orderer.example.com:7050 -c orgtwochannel -f channel-artifacts/OrgTwoChannel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
    2019-12-19 20:08:31.088 UTC [channelCmd] InitCmdFactory ->** INFO 001 Endorser and orderer connections initialized
    Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining**
    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer# export CORE_PEER_LOCALMSPID="Org2MSP"
    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer#** export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt**
    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer# export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]org2.example.com/msp
    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer# export CORE_PEER_ADDRESS=peer0.org2.example.com:9051
    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel create -o orderer.example.com:7050 -c orgtwochannel -f channel-artifacts/OrgTwoChannel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
    2019-12-19 20:12:22.633 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
    2019-12-19 20:12:22.662 UTC [cli.common] readBlock ->** INFO 002 Received block: 0**
    [email protected]:/opt/gopath/src/github.com/hyperledger/fabric/peer#

  • eecszceecszc Posts: 11

    Thanks Greg.
    I'v check my "env" and they are set correctly.

    Finally, i found this is caused by adding the line "EnableNodeOUs: true" under Org2 section in crypto-config.yaml.

    here is my Org2 section in crypto-config.yaml file
    - Name: Org2 Domain: org2.example.com EnableNodeOUs: true Template: Count: 2 Users: Count: 1

    with this line, it won't generate any cert in path: "startFiles/crypto-config/peerOrganizations/org2.example.com/msp/admincerts"
    after running
    ../bin/cryptogen generate --config=./crypto-config.yaml

    i'm ambiguous about the usage of this cert. but literally we can assume that without it the Org2 doesn't have admin authorization.

    For "EnableNodeOUs"

    the introduction in official tutorial

    Identity Classification
    The default MSP implementation allows to further classify identities into clients and peers, based on the OUs of their x509 certificates. An identity should be classified as a client if it submits transactions, queries peers, etc. An identity should be classified as a peer if it endorses or commits transactions. In order to define clients and peers of a given MSP, the config.yaml file needs to be set appropriately. Here is an example:

    NodeOUs:
    Enable: true
    ClientOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
    PeerOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer"

    As shown above, the NodeOUs.Enable is set to true, this enables the identify classification. Then, client (peer) identifiers are defined by setting the following properties for the NodeOUs.ClientOUIdentifier (NodeOUs.PeerOUIdentifier) key:

    a.OrganizationalUnitIdentifier: Set this to the value that matches the OU that the x509 certificate of a client (peer) should contain.
    b.Certificate: Set this to the CA or intermediate CA under which client (peer) identities should be validated. The field is relative to the MSP root folder. It can be empty, meaning that the identity’s x509 certificate can be validated under any CA defined in the MSP configuration.
    When the classification is enabled, MSP administrators need to be clients of that MSP, meaning that their x509 certificates need to carry the OU that identifies the clients. Notice also that, an identity can be either a client or a peer. The two classifications are mutually exclusive. If an identity is neither a client nor a peer, the validation will fail.

    Finally, notice that for upgraded environments the 1.1 channel capability needs to be enabled before identify classification can be used.

    and you can check this link for more details https://stackoverflow.com/questions/49924937/meaning-of-enablenodeous-in-crypto-config-yaml

    it seems that i enable this classification but don't set the value

  • I got the same error.

    Add org to the consoritum https://github.com/yeasy/docker-compose-files/issues/51#issuecomment-514131951
    AND remove EnableNodeOUs: true

    It looks like EnableNodeOUs does not work correctly with hyperledger fabric 1.4.3 or 1.4.4 version...

  • @akoita said:
    An update.

    So I went on the hypotheses that Org2 must be added to the system channel consortium. For that, two possibilities:

    1. Update the configtx.yaml an recreate the network
    2. Update dynamically the system channel, like in the Lab 7.

    The first option is not very interesting because I think that at this point, the goal is to learn how to dynamically update the network. So I had to update the system channel like in Lab 7, with a slightly difference. I performed the following operations for that:

    export CORE_PEER_LOCALMSPID=OrdererMSP
    export CORE_PEER_ADDRESS=orderer.example.com:7050
    export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/[email protected]/msp
    peer channel fetch config genesis.pb -o orderer.example.com:7050 -c testchainid
    configtxlator proto_decode --input genesis.pb --type common.Block | jq .data.data[0].payload.data.config > genesisBlock.json
    jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"SampleConsortium":{"groups":{"Org2MSP":.[1]}}}}}}}' genesisBlock.json ./config/org2_definition.json > genesisBlockChanges.json
    configtxlator proto_encode --input genesisBlock.json --type common.Config --output genesisBlock.pb
    configtxlator proto_encode --input genesisBlockChanges.json --type common.Config --output genesisBlockChanges.pb
    configtxlator compute_update --channel_id testchainid --original genesisBlock.pb --updated genesisBlockChanges.pb --output genesisBlocProposal_Org2.pb
    configtxlator proto_decode --input genesisBlocProposal_Org2.pb --type common.ConfigUpdate | jq . > genesisBlocProposal_Org2.json
    echo '{"payload":{"header":{"channel_header":{"channel_id":"testchainid", "type":2}},"data":{"config_update":'$(cat genesisBlocProposal_Org2.json)'}}}' | jq . > genesisBlocProposalReady.json
    configtxlator proto_encode --input genesisBlocProposalReady.json --type common.Envelope --output genesisBlocProposalReady.pb
    peer channel update -f genesisBlocProposalReady.pb -c testchainid -o orderer.example.com:7050
    

    The update worked well. An after the update I could create the channel allarewelcometwo with success.

    However, I dont know if this was the right solution to the problem.

    Why is the channel called testchainid? Can we name this anything we want?

  • NiklaskkkkNiklaskkkk Posts: 71
    edited January 10

    Why is the channel called testchainid? Can we name this anything we want?

    Hi @antonimassomola ,
    testchainid is set when creating the genesis block with configtxgen for the configuration channel, usually this is done during the bootstrap. However, you can do it manually when using the configtxgen tool by adding the --channelID parameter and there set your channel name

    Here is an example syntax:

    configtxgen -profile GenesisProfilePresetGoesHere -channelID
    SystemChannelNameGoesHere -outputBlock GenesisBlockNameGoesHere

  • Hi @Niklaskkkk ,
    Thanks for the reply!
    So when I create the genesis block transaction like this:
    configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block
    If I don't add the GenesisBlockNameGoesHere parameter by default HF sets it to testchainid?

  • @antonimassomola said:
    Hi @Niklaskkkk ,
    Thanks for the reply!
    So when I create the genesis block transaction like this:
    configtxgen -profile OneOrgOrdererGenesis -outputBlock ./config/genesis.block
    If I don't add the GenesisBlockNameGoesHere parameter by default HF sets it to testchainid?

    Correct @antonimassomola ! The configtxgen tool is hard-coded so that if channelId paramter is not set, the default value is testchainid.

    If you are unsure about what the name of the orderer channel is, you can always go into the CLI container, go into the channel-artifacts folder, then look at a JSON version of the genesis.block. At the bottom of the block you see the channel id setting:
    "channel_header": {
    "channel_id": "byfn-sys-channel",
    "epoch": "0",
    "extension": null,
    "timestamp": "2020-01-14T17:44:18Z",
    "tls_cert_hash": null,

    The command for looking at the block is: configtxgen -inspectBlock genesis.block

  • Thank you @Niklaskkkk !

Sign In or Register to comment.