Lab8: Subsequent issues of (Error when creating new channel: "Attempted to include a membe" )

eecszc

When doing lab 8, firstly i met this error
Error: got unexpected status: BAD_REQUEST -- Attempted to include a member which is not in the consortium

Then i do as the solution in another discussion

after that, i got this 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 anyone give some clues.
thanks

eecszc

i use "configtxgen -printOrg Org" to get the org1 and org2's definition. their main difference is like

there is no value in "admins" of org2. i'm not sure if this is the reason.

eecszc

Finally, i found this is caused by adding the line "EnableNodeOUs: true" under Org2 section in crypto-config.yaml.
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