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

akoita

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?

benjamin.verhaegen

I need a solution for this to..

akoita

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.

akoita

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/Admin@example.com/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.

benjamin.verhaegen

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

akoita

Glad to hear that @benjamin.verhaegen

indirajith

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!

akoita

@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.

Niklaskkkk

@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/Admin@example.com/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?

akoita

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.

Niklaskkkk

@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.

indirajith

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 ?

akoita

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?

indirajith

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!

indirajith

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!

GregMead

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

2. 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

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

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

5. 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

koakh

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

edmond66

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:

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

eecszc

@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

2. 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

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

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

5. 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

GregMead

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/Admin@org2.example.com/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.

root@6536a4782695:/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**
root@6536a4782695:/opt/gopath/src/github.com/hyperledger/fabric/peer# export CORE_PEER_LOCALMSPID="Org2MSP"
root@6536a4782695:/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**
root@6536a4782695:/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/Admin@org2.example.com/msp
root@6536a4782695:/opt/gopath/src/github.com/hyperledger/fabric/peer# export CORE_PEER_ADDRESS=peer0.org2.example.com:9051
root@6536a4782695:/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**
root@6536a4782695:/opt/gopath/src/github.com/hyperledger/fabric/peer#

eecszc

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

GuillaumeCisco

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...

antonimassomola

@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/Admin@example.com/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?

Niklaskkkk

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

antonimassomola

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?

Niklaskkkk

@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

antonimassomola

Thank you @Niklaskkkk !

danielechirivi

In the video, you can see that in configtx.yaml, there is also Org2 under OneOrgOrdererGenesis, so this is the right way to go, although it isn0t explained in the documentation.

praveents

@eecszc said:

@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

2. 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

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

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

5. 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

Hi @eecszc , I am also getting the same error, "allarewelcometwo" channel creation after updating the configtx.yaml. Did you solve the problem.

praveents

@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/Admin@example.com/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.

I tried the above steps and it worked well, able to create orgtwochannel and allarewelcometwo channels and join peer0 and peer1 of Org2. However, peer1 of org1 was able to join orgtwochannel, i think that shouldn't be allowed.

praveents

36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.oga=00;36:.opus=00;36:.spx=00;36:*.xspf=00;36:
LESSCLOSE=/usr/bin/lesspipe %s %s
CORE_PEER_LOCALMSPID=Org1MSP
LANG=en_US.UTF-8
FABRIC_CFG_PATH=/etc/hyperledger/fabric
HOSTNAME=5059d066e30e
JAVA_HOME=/opt/java/openjdk
JAVA_TOOL_OPTIONS=-XX:+IgnoreUnrecognizedVMOptions -XX:+UseContainerSupport -XX:+IdleTuningCompactOnIdle -XX:+IdleTuningGcOnIdle
CORE_LOGGING_LEVEL=info
CORE_CHAINCODE_KEEPALIVE=10
JAVA_VERSION=jdk8u222-b10_openj9-0.15.1
GOPATH=/opt/gopath
PWD=/opt/gopath/src/github.com/hyperledger/fabric/peer
CORE_PEER_ID=cli
HOME=/root
GOROOT=/opt/go
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/
TERM=xterm
SHLVL=1
LANGUAGE=en_US:en
PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/go/bin:/opt/gopath/bin
CORE_PEER_ADDRESS=peer1.org1.example.com:7051
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
LESSOPEN=| /usr/bin/lesspipe %s
_=/usr/bin/env
root@5059d066e30e:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel join -o orderer.example.com:7050 -b ./allarewelcometwo.block
2020-08-23 14:57:24.936 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2020-08-23 14:57:24.939 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2020-08-23 14:57:24.941 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2020-08-23 14:57:27.295 UTC [channelCmd] executeJoin -> INFO 004 Successfully submitted proposal to join channel
root@5059d066e30e:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel list
2020-08-23 14:57:30.732 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2020-08-23 14:57:30.735 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2020-08-23 14:57:30.737 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
Channels peers has joined:
allarewelcome
orgtwochannel
allarewelcometwo