尝试将对等体加入频道时,发生 "this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied" 错误
When trying to join a peer to a channel, "this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied" error occurs
我正在尝试 Fabric v2.2,但由于某些策略问题(我猜),无法加入对等通道。为了获得排序者和同行的 MSP,我使用了排序者组织和同行组织(有一个同行组织)的 CA。
fabric-ca-client register -d --id.name ${PEERS[$i]} --id.secret ${PEER_ADMIN_PWS[$i]} --id.type peer -u https://$CA_NODE:7054
…
fabric-ca-client register -d --id.name $ORG_ADMIN_ID --id.secret $ORG_ADMIN_PW --id.type admin -u https://$CA_NODE:7054
….
fabric-ca-client register -d --id.name ${ORDERERS[$i]} --id.secret ${ORDERER_ADMIN_PWS[$i]} --id.type orderer -u https://$CA_NODE:7054
…
fabric-ca-client enroll -d -u https://${NODES[$i]}:${NODE_ADMIN_PWS[$i]}@$CA_NODE:7054
我认为 MSP 还可以,因为网络运行良好。
然后,我启动了一个 CLI 容器并创建了一个名为 identitych
的通道。我认为它运行良好,因为我检查了 identitych
目录已在所有订购者的 chains
目录下创建。
在那之后,当我提议使用以下命令将节点加入通道时,由于权限被拒绝,排序节点无法将块交付给节点,节点无法从排序节点检索块,因为禁止问题。
peer channel join -b /channel-artifacts/identitych.block
我的 configtx.yaml
文件如下所示:
Organizations:
- &BPLOrdererOrg
Name: BPLOrdererMSP
ID: BPLOrdererMSP
MSPDir: ./orderers/org-msp
Policies:
Readers:
Type: Signature
Rule: "OR('BPLOrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('BPLOrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('BPLOrdererMSP.admin')"
OrdererEndpoints:
- orderer0.common.bpl:7050
- &BPLOrg
Name: BPLMSP
ID: BPLMSP
MSPDir: ./peers/org-msp
Policies:
Readers:
Type: Signature
Rule: "OR('BPLMSP.admin', 'BPLMSP.peer', 'BPLMSP.client')"
Writers:
Type: Signature
Rule: "OR('BPLMSP.admin', 'BPLMSP.client')"
Admins:
Type: Signature
Rule: "OR('BPLMSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('BPLMSP.peer')"
NodeOUs
通过将 config.yaml
放置在每个排序节点和节点的 msp 目录中来启用。
# config.yaml
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"
AdminOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
PeerOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"
OrdererOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "orderer"
订购者反复打印以下警告:
2020-08-20 11:35:08.041 UTC [comm.grpc.server] 1 -> INFO 0c3 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.24.0.11:42642 grpc.code=OK grpc.call_duration=792.5µs
2020-08-20 11:35:15.176 UTC [common.deliver] deliverBlocks -> WARN 0c4 [channel: identitych] Client 172.24.0.8:60236 is not authorized: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied
同时,一个peer也重复打印如下警告:
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] DeliverBlocks -> WARN 02b Got error while attempting to receive blocks: received bad status FORBIDDEN from orderer channel=identitych orderer-address=orderer0.common.bpl:7050
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] func1 -> WARN 02c Encountered an error reading from deliver stream: EOF channel=identitych orderer-address=orderer0.common.bpl:7050
我发现了一个类似的问题和答案 (link),我对以下引述感到好奇:
Check for the Reader policies that you have defined in your configtx.yaml this error is generated because of the policy mismatch. You have defined some specific user type(admin, peer, client) in your Reader policies but this specific user type is not passed into certificates that you have generated for your peer.
我同意我的问题是因为政策不匹配,但我不明白下面提到的:
but this specific user type is not passed into certificates that you have generated for your peer.
我该如何解决我的问题?提前谢谢。
您似乎没有为通道配置中包含的 MSP 定义启用 NodeOU。
NodeOUs is enabled by placing config.yaml on msp directory of each orderer and peer.
这将在节点和排序节点的 'local MSP' 中启用 NodeOU 支持,但对于通道操作,如调用 Deliver
API,通道 MSP 定义是利用。
确保您已将 config.yaml
放在 configtx.yaml
引用的 MSP 目录中(例如,在您的情况下 ./peers/org-msp
)before 为排序系统通道生成创世块。
补充说明:
您可以通过更改 configtx.yaml
中的读者策略来确认它与 NodeOU 相关,以引用您的同行组织的 member
,就像您对订购者组织所做的那样。如果事情适用于成员策略,那么这肯定与 NodeOU 相关。
您还可以通过设置 FABRIC_LOGGING_SPEC=info:cauthdsl=debug:policies=debug:msp=debug
为策略评估打开调试。这对于正常操作来说通常过于冗长,但会让您更清楚地了解导致失败的确切原因。
我正在尝试 Fabric v2.2,但由于某些策略问题(我猜),无法加入对等通道。为了获得排序者和同行的 MSP,我使用了排序者组织和同行组织(有一个同行组织)的 CA。
fabric-ca-client register -d --id.name ${PEERS[$i]} --id.secret ${PEER_ADMIN_PWS[$i]} --id.type peer -u https://$CA_NODE:7054
…
fabric-ca-client register -d --id.name $ORG_ADMIN_ID --id.secret $ORG_ADMIN_PW --id.type admin -u https://$CA_NODE:7054
….
fabric-ca-client register -d --id.name ${ORDERERS[$i]} --id.secret ${ORDERER_ADMIN_PWS[$i]} --id.type orderer -u https://$CA_NODE:7054
…
fabric-ca-client enroll -d -u https://${NODES[$i]}:${NODE_ADMIN_PWS[$i]}@$CA_NODE:7054
我认为 MSP 还可以,因为网络运行良好。
然后,我启动了一个 CLI 容器并创建了一个名为 identitych
的通道。我认为它运行良好,因为我检查了 identitych
目录已在所有订购者的 chains
目录下创建。
在那之后,当我提议使用以下命令将节点加入通道时,由于权限被拒绝,排序节点无法将块交付给节点,节点无法从排序节点检索块,因为禁止问题。
peer channel join -b /channel-artifacts/identitych.block
我的 configtx.yaml
文件如下所示:
Organizations:
- &BPLOrdererOrg
Name: BPLOrdererMSP
ID: BPLOrdererMSP
MSPDir: ./orderers/org-msp
Policies:
Readers:
Type: Signature
Rule: "OR('BPLOrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('BPLOrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('BPLOrdererMSP.admin')"
OrdererEndpoints:
- orderer0.common.bpl:7050
- &BPLOrg
Name: BPLMSP
ID: BPLMSP
MSPDir: ./peers/org-msp
Policies:
Readers:
Type: Signature
Rule: "OR('BPLMSP.admin', 'BPLMSP.peer', 'BPLMSP.client')"
Writers:
Type: Signature
Rule: "OR('BPLMSP.admin', 'BPLMSP.client')"
Admins:
Type: Signature
Rule: "OR('BPLMSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('BPLMSP.peer')"
NodeOUs
通过将 config.yaml
放置在每个排序节点和节点的 msp 目录中来启用。
# config.yaml
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"
AdminOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "admin"
PeerOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"
OrdererOUIdentifier:
Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "orderer"
订购者反复打印以下警告:
2020-08-20 11:35:08.041 UTC [comm.grpc.server] 1 -> INFO 0c3 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.24.0.11:42642 grpc.code=OK grpc.call_duration=792.5µs
2020-08-20 11:35:15.176 UTC [common.deliver] deliverBlocks -> WARN 0c4 [channel: identitych] Client 172.24.0.8:60236 is not authorized: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied
同时,一个peer也重复打印如下警告:
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] DeliverBlocks -> WARN 02b Got error while attempting to receive blocks: received bad status FORBIDDEN from orderer channel=identitych orderer-address=orderer0.common.bpl:7050
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] func1 -> WARN 02c Encountered an error reading from deliver stream: EOF channel=identitych orderer-address=orderer0.common.bpl:7050
我发现了一个类似的问题和答案 (link),我对以下引述感到好奇:
Check for the Reader policies that you have defined in your configtx.yaml this error is generated because of the policy mismatch. You have defined some specific user type(admin, peer, client) in your Reader policies but this specific user type is not passed into certificates that you have generated for your peer.
我同意我的问题是因为政策不匹配,但我不明白下面提到的:
but this specific user type is not passed into certificates that you have generated for your peer.
我该如何解决我的问题?提前谢谢。
您似乎没有为通道配置中包含的 MSP 定义启用 NodeOU。
NodeOUs is enabled by placing config.yaml on msp directory of each orderer and peer.
这将在节点和排序节点的 'local MSP' 中启用 NodeOU 支持,但对于通道操作,如调用 Deliver
API,通道 MSP 定义是利用。
确保您已将 config.yaml
放在 configtx.yaml
引用的 MSP 目录中(例如,在您的情况下 ./peers/org-msp
)before 为排序系统通道生成创世块。
补充说明:
您可以通过更改 configtx.yaml
中的读者策略来确认它与 NodeOU 相关,以引用您的同行组织的 member
,就像您对订购者组织所做的那样。如果事情适用于成员策略,那么这肯定与 NodeOU 相关。
您还可以通过设置 FABRIC_LOGGING_SPEC=info:cauthdsl=debug:policies=debug:msp=debug
为策略评估打开调试。这对于正常操作来说通常过于冗长,但会让您更清楚地了解导致失败的确切原因。