I updated a development hyperledger fabric network from 1.4.1 to 1.4.4 and can no longer create channels or interact with the network because a channel policy fails that was not failing in v1.4.1
The following is what happens when I try to create a channel via node sdk
Errors from node sdk
error: Status: BAD_REQUEST
Info: error validating channel creation transaction for new channel 'mychannel', could not successfully 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
Errors from Orderer Docker container
[orderer.common.broadcast] ProcessMessage -> WARN 00e [channel: farm] Rejecting broadcast of config message from 172.18.0.1:40866 because of error: error validating channel creation transaction for new channel 'farm', 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
crypto-config section
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
I think there were some Channel Policy and Channel Capability changes in 1.4.3
I solved the problem by getting the configtx.yaml from first-network the 1.4.3 fabric-samples and applying my changes (org names etc) to that new yaml file. Then generating a new genesis block etc.
After using the fabric-samples configtx.yaml for v1.4.4 as a template I found the only difference was this Capabilities section
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
Capabilities:
<<: *ApplicationCapabilities
Related
I'm trying to create an application channel for a hyperledger fabric network which consists of:
certificate authority for all participants
TLS certificate authority for ordering nodes and peers
one ordering node
one peer node
Below is my configtx.yaml:
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererOrg
# ID to load the MSP definition as
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
MSPDir: path/to/orderers/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies: &SampleOrgPolicies
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- "localhost:7050"
# Anchor node (Anchor Peer)： Each organization can specify Anchor Peer, Nodes of other organizations can Gossip Message sent to this Anchor Peer On , , in turn, Anchor Peer Will get the whole network information , Block broadcast to the organization ;
AnchorPeers:
- Host: localhost
Port: 7051
- &Org1
Name: Org1MSP
ID: Org1MSP
MSPDir: path/to/peer1/msp
Policies: &Org1Policies
Readers:
Type: Signature
Rule: "OR('Org1MSP.member')"
Writers:
Type: Signature
Rule: "OR('Org1MSP.member')"
Admins:
Type: Signature
Rule: "OR('Org1MSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('Org1MSP.peer')"
- &Org2
Name: Org2MSP
ID: Org2MSP
MSPDir: path/to/peer2/msp
Policies: &Org2Policies
Readers:
Type: Signature
Rule: "OR('Org2MSP.member')"
Writers:
Type: Signature
Rule: "OR('Org2MSP.member')"
Admins:
Type: Signature
Rule: "OR('Org2MSP.admin')"
Endorsment:
Type: Signature
Rule: "OR('Org2MSP.peer')"
# AnchorPeers:
# - Host: localhost
# Port: 7051
################################################################################
#
# SECTION: Capabilities
#
# - This section defines the capabilities of fabric network. This is a new
# concept as of v1.1.0 and should not be utilized in mixed networks with
# v1.0.x peers and orderers. Capabilities define features which must be
# present in a fabric binary for that binary to safely participate in the
# fabric network. For instance, if a new MSP type is added, newer binaries
# might recognize and validate the signatures from this type, while older
# binaries without this support would be unable to validate those
# transactions. This could lead to different versions of the fabric binaries
# having different world states. Instead, defining a capability for a channel
# informs those binaries without this capability that they must cease
# processing transactions until they have been upgraded. For v1.0.x if any
# capabilities are defined (including a map with all capabilities turned off)
# then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
# Channel capabilities apply to both the orderers and the peers and must be
# supported by both.
# Set the value of the capability to true to require it.
Channel: &ChannelCapabilities
# V2_0 capability ensures that orderers and peers behave according
# to v2.0 channel capabilities. Orderers and peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 capability.
# Prior to enabling V2.0 channel capabilities, ensure that all
# orderers and peers on a channel are at v2.0.0 or later.
V2_0: true
# Orderer capabilities apply only to the orderers, and may be safely
# used with prior release peers.
# Set the value of the capability to true to require it.
Orderer: &OrdererCapabilities
# V2_0 orderer capability ensures that orderers behave according
# to v2.0 orderer capabilities. Orderers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 orderer capability.
# Prior to enabling V2.0 orderer capabilities, ensure that all
# orderers on channel are at v2.0.0 or later.
V2_0: true
# Application capabilities apply only to the peer network, and may be safely
# used with prior release orderers.
# Set the value of the capability to true to require it.
Application: &ApplicationCapabilities
# V2_0 application capability ensures that peers behave according
# to v2.0 application capabilities. Peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 application capability.
# Prior to enabling V2.0 application capabilities, ensure that all
# peers on channel are at v2.0.0 or later.
V2_0: true
################################################################################
#
# SECTION: Application
#
# - This section defines the values to encode into a config transaction or
# genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies: &ApplicationPolicies
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
################################################################################
#
# SECTION: Orderer
#
# - This section defines the values to encode into a config transaction or
# genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults
# Orderer Type: The orderer implementation to start
OrdererType: etcdraft
# Addresses used to be the list of orderer addresses that clients and peers
# could connect to. However, this does not allow clients to associate orderer
# addresses and orderer organizations which can be useful for things such
# as TLS validation. The preferred way to specify orderer addresses is now
# to include the OrdererEndpoints item in your org definition
Addresses:
- localhost:7050
EtcdRaft:
Consenters:
- Host: raft0
Port: 7050
ClientTLSCert: path/to/signcerts/raft0-tls-cert.pem
ServerTLSCert: path/to/signcerts/raft0-tls-cert.pem
# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 2s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 10
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 99 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 KB
# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Orderer policies, their canonical path is
# /Channel/Orderer/<PolicyName>
Policies: &OrdererPolicies
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# BlockValidation specifies what signatures must be included in the block
# from the orderer for the peer to validate it.
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
Capabilities:
<<: *OrdererCapabilities
################################################################################
#
# CHANNEL
#
# This section defines the values to encode into a config transaction or
# genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
# Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/<PolicyName>
Policies:
# Who may invoke the 'Deliver' API
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
# Who may invoke the 'Broadcast' API
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
# By default, who may modify elements at this config level
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# Capabilities describes the channel level capabilities, see the
# dedicated Capabilities section elsewhere in this file for a full
# description
Capabilities:
<<: *ChannelCapabilities
################################################################################
#
# Profile
#
# - Different configuration profiles may be encoded here to be specified
# as parameters to the configtxgen tool
#
################################################################################
Profiles:
TwoOrgsApplicationGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Capabilities: *ApplicationCapabilities
First, I create a genesis block with the following command:
./bin/configtxgen -profile TwoOrgsApplicationGenesis -configPath ./testConfigs -outputBlock ./channel-artifacts/genesis_block.pb -channelID mychannel
Next, I create a transaction to create an application channel:
./bin/osnadmin channel join --channelID $CHANNEL_NAME --config-block ./channel-artifacts/genesis_block.pb -o localhost:7050 --ca-file "$ORDERER_CA" --client-cert "$ORDERER_ADMIN_TLS_SIGN_CERT" --client-key "$ORDERER_ADMIN_TLS_PRIVATE_KEY"
Every time I create an app channel, I get the following error:
Error: Post "https://localhost:7050/participation/v1/channels": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x06\x04\x00\x00\x00\x00\x00\x00\x05\x00\x00#\x00"
Please tell me what is wrong?
The symptom for my problem was the same:
"Error: Post "https://localhost:7050/participation/v1/channels": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x06\x04\x00\x00\x00\x00\x00\x00\x05\x00\x00#\x00"
What I did wrong was to connect to the Orderer on its general listen address and missed to configure the Admin.* settings as described here.
Once I connected to the Admin Listenaddress the osnadmin command worked correctly. The general port serves GRPC while the Admin one uses http(s). I think this explains the malformed error.
I am trying to install chaincode (Using a new chaincode life cycle) in hyper ledger fabric 2.0.
Fabric image versions: 2.1.0
In my network I have
Two organization (two peers each)
3 Orders (Raft as order service)
During the commit chaincode step, i m getting the following error
2021-08-04 06:36:29.803 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [ebca06fc317ef078d896182e7814f3d9e847266b2fa4a80ae443e17a9ad976da] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1.base.left:8003
2021-08-04 06:36:29.816 UTC [chaincodeCmd] ClientWait -> INFO 002 txid [ebca06fc317ef078d896182e7814f3d9e847266b2fa4a80ae443e17a9ad976da] committed with status (ENDORSEMENT_POLICY_FAILURE) at peer1.base.right:8004
Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE)
While inspecting the peer logs i can see the following error
2021-08-04 06:36:29.755 UTC [committer.txvalidator] validateTx -> ERRO 004 Dispatch for transaction txId = ebca06fc317ef078d896182e7814f3d9e847266b2fa4a80ae443e17a9ad976da returned error: validation of endorsement policy for chaincode _lifecycle in tx 8:0 failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 2 of the 'Endorsement' sub-policies to be satisfied
Not sure why this is happening
UPDATE configtx.yaml file
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererOrg
# ID to load the MSP definition as
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
MSPDir: crypto-config/ordererOrganizations/base.order/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- orderer1.base.order:8000
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: LeftOrgMSP
# ID to load the MSP definition as
ID: LeftOrgMSP
MSPDir: crypto-config/peerOrganizations/base.left/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('LeftOrgMSP.admin', 'LeftOrgMSP.peer', 'LeftOrgMSP.client')"
Writers:
Type: Signature
Rule: "OR('LeftOrgMSP.admin', 'LeftOrgMSP.client')"
Admins:
Type: Signature
Rule: "OR('LeftOrgMSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('LeftOrgMSP.peer')"
- &Org2
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: RightOrgMSP
# ID to load the MSP definition as
ID: RightOrgMSP
MSPDir: crypto-config/peerOrganizations/base.right/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('RightOrgMSP.admin', 'RightOrgMSP.peer', 'RightOrgMSP.client')"
Writers:
Type: Signature
Rule: "OR('RightOrgMSP.admin', 'RightOrgMSP.client')"
Admins:
Type: Signature
Rule: "OR('RightOrgMSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('RightOrgMSP.peer')"
################################################################################
#
# SECTION: Capabilities
#
# - This section defines the capabilities of fabric network. This is a new
# concept as of v1.1.0 and should not be utilized in mixed networks with
# v1.0.x peers and orderers. Capabilities define features which must be
# present in a fabric binary for that binary to safely participate in the
# fabric network. For instance, if a new MSP type is added, newer binaries
# might recognize and validate the signatures from this type, while older
# binaries without this support would be unable to validate those
# transactions. This could lead to different versions of the fabric binaries
# having different world states. Instead, defining a capability for a channel
# informs those binaries without this capability that they must cease
# processing transactions until they have been upgraded. For v1.0.x if any
# capabilities are defined (including a map with all capabilities turned off)
# then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
# Channel capabilities apply to both the orderers and the peers and must be
# supported by both.
# Set the value of the capability to true to require it.
Channel: &ChannelCapabilities
# V2_0 capability ensures that orderers and peers behave according
# to v2.0 channel capabilities. Orderers and peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 capability.
# Prior to enabling V2.0 channel capabilities, ensure that all
# orderers and peers on a channel are at v2.0.0 or later.
V2_0: true
# Orderer capabilities apply only to the orderers, and may be safely
# used with prior release peers.
# Set the value of the capability to true to require it.
Orderer: &OrdererCapabilities
# V2_0 orderer capability ensures that orderers behave according
# to v2.0 orderer capabilities. Orderers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 orderer capability.
# Prior to enabling V2.0 orderer capabilities, ensure that all
# orderers on channel are at v2.0.0 or later.
V2_0: true
# Application capabilities apply only to the peer network, and may be safely
# used with prior release orderers.
# Set the value of the capability to true to require it.
Application: &ApplicationCapabilities
# V2_0 application capability ensures that peers behave according
# to v2.0 application capabilities. Peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 application capability.
# Prior to enabling V2.0 application capabilities, ensure that all
# peers on channel are at v2.0.0 or later.
V2_0: true
################################################################################
#
# SECTION: Application
#
# - This section defines the values to encode into a config transaction or
# genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
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
################################################################################
#
# SECTION: Orderer
#
# - This section defines the values to encode into a config transaction or
# genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults
# Orderer Type: The orderer implementation to start
OrdererType: etcdraft
# Addresses used to be the list of orderer addresses that clients and peers
# could connect to. However, this does not allow clients to associate orderer
# addresses and orderer organizations which can be useful for things such
# as TLS validation. The preferred way to specify orderer addresses is now
# to include the OrdererEndpoints item in your org definition
Addresses:
- orderer1.base.order:8000
- orderer2.base.order:8000
- orderer3.base.order:8000
EtcdRaft:
Consenters:
- Host: orderer1.base.order
Port: 8000
ClientTLSCert: crypto-config/ordererOrganizations/base.order/orderers/orderer1.base.order/tls/server.crt
ServerTLSCert: crypto-config/ordererOrganizations/base.order/orderers/orderer1.base.order/tls/server.crt
- Host: orderer2.base.order
Port: 8000
ClientTLSCert: crypto-config/ordererOrganizations/base.order/orderers/orderer2.base.order/tls/server.crt
ServerTLSCert: crypto-config/ordererOrganizations/base.order/orderers/orderer2.base.order/tls/server.crt
- Host: orderer3.base.order
Port: 8000
ClientTLSCert: crypto-config/ordererOrganizations/base.order/orderers/orderer3.base.order/tls/server.crt
ServerTLSCert: crypto-config/ordererOrganizations/base.order/orderers/orderer3.base.order/tls/server.crt
# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 2s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 10
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 99 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 KB
# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Orderer policies, their canonical path is
# /Channel/Orderer/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# BlockValidation specifies what signatures must be included in the block
# from the orderer for the peer to validate it.
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
################################################################################
#
# CHANNEL
#
# This section defines the values to encode into a config transaction or
# genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
# Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/<PolicyName>
Policies:
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "ANY Endorsement"
# Who may invoke the 'Deliver' API
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
# Who may invoke the 'Broadcast' API
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
# By default, who may modify elements at this config level
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# Capabilities describes the channel level capabilities, see the
# dedicated Capabilities section elsewhere in this file for a full
# description
Capabilities:
<<: *ChannelCapabilities
################################################################################
#
# Profile
#
# - Different configuration profiles may be encoded here to be specified
# as parameters to the configtxgen tool
#
################################################################################
Profiles:
MainChannel:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities: *OrdererCapabilities
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
Capabilities: *ApplicationCapabilities
Consortiums:
BaseConsortium:
Organizations:
- *Org1
- *Org2
AnyOrgsChannel:
<<: *ChannelDefaults
Consortium: BaseConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Org1
- *Org2
You need to collect endorsement from a peer from both Orgs in order to meet the LifeCycle endorsement policy. This error could be because you are not targeting either peer, or because your orgs have not approved the same chaincode definition as the one you are trying to commit
In your config.tx file you have mentioned LifecycleEndorsement as MAJORITY Endorsement that means your transaction should be endorse by a peer from both organizations.
to achive this make sure
your chaincode is approved by both the organizations
while running commit command pass the peer connection parameters (--peerAddresses $CORE_PEER_ADDRESS --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE) for any peer from both organizations.
I need to spin up orderer without genesis block as I don't have information about the consortium at the time of orderer bootstrap.
Is there a way to do this?
According to orderer.yaml file, we can set ORDERER_GENERAL_GENESISMETHOD=none to bootstrap orderer without genesis block. I tried that, but it doesn't work. Throws this error:
orderer.example.com | 2020-05-30 16:46:03.446 UTC [orderer.common.server] initializeServerConfig -> INFO 003 Starting orderer with TLS enabled
orderer.example.com | 2020-05-30 16:46:04.246 UTC [fsblkstorage] NewProvider -> INFO 004 Creating new file ledger directory at /var/hyperledger/production/orderer/chains
orderer.example.com | panic: unable to bootstrap orderer. Error reading genesis block file: open /etc/hyperledger/fabric/genesisblock: no such file or directory
orderer.example.com |
orderer.example.com | goroutine 1 [running]:
orderer.example.com | github.com/hyperledger/fabric/orderer/common/bootstrap/file.(*fileBootstrapper).GenesisBlock(0xc00038e400, 0xc00038e400)
orderer.example.com | /go/src/github.com/hyperledger/fabric/orderer/common/bootstrap/file/bootstrap.go:39 +0x1c0
orderer.example.com | github.com/hyperledger/fabric/orderer/common/server.extractBootstrapBlock(0xc0001c2d80, 0xc0001249c0)
orderer.example.com | /go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:595 +0x139
orderer.example.com | github.com/hyperledger/fabric/orderer/common/server.Main()
orderer.example.com | /go/src/github.com/hyperledger/fabric/orderer/common/server/main.go:128 +0x129a
orderer.example.com | main.main()
orderer.example.com | /go/src/github.com/hyperledger/fabric/cmd/orderer/main.go:15 +0x20
I tried generating a genesis block without consortium information. But it gave me a warning while generating the genesis block. WARN 007 Genesis block does not contain a consortiums group definition. This block cannot be used for orderer bootstrap
2020-05-30 21:26:01.892 IST [common.tools.configtxgen] main -> INFO 001 Loading configuration
2020-05-30 21:26:01.897 IST [common.tools.configtxgen.localconfig] completeInitialization -> INFO 002 Orderer.Addresses unset, setting to [127.0.0.1:7050]
2020-05-30 21:26:01.897 IST [common.tools.configtxgen.localconfig] completeInitialization -> INFO 003 orderer type: etcdraft
2020-05-30 21:26:01.897 IST [common.tools.configtxgen.localconfig] completeInitialization -> INFO 004 Orderer.EtcdRaft.Options unset, setting to tick_interval:"500ms" election_tick:10 heartbeat_tick:1 max_inflight_blocks:5 snapshot_interval_size:16777216
2020-05-30 21:26:01.897 IST [common.tools.configtxgen.localconfig] Load -> INFO 005 Loaded configuration: /home/nitish/work/hyperledger/research-network/configtx.yaml
2020-05-30 21:26:01.898 IST [common.tools.configtxgen] doOutputBlock -> INFO 006 Generating genesis block
2020-05-30 21:26:01.898 IST [common.tools.configtxgen] doOutputBlock -> WARN 007 Genesis block does not contain a consortiums group definition. This block cannot be used for orderer bootstrap.
2020-05-30 21:26:01.898 IST [common.tools.configtxgen] doOutputBlock -> INFO 008 Writing genesis block
Sample config for genesis block generation:
---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererOrg
# ID to load the MSP definition as
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
MSPDir: ./ordererorganization/msp
# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Writers:
Type: Signature
Rule: "OR('OrdererMSP.member')"
Admins:
Type: Signature
Rule: "OR('OrdererMSP.admin')"
OrdererEndpoints:
- orderer.example.com:7050
################################################################################
#
# SECTION: Capabilities
#
# - This section defines the capabilities of fabric network. This is a new
# concept as of v1.1.0 and should not be utilized in mixed networks with
# v1.0.x peers and orderers. Capabilities define features which must be
# present in a fabric binary for that binary to safely participate in the
# fabric network. For instance, if a new MSP type is added, newer binaries
# might recognize and validate the signatures from this type, while older
# binaries without this support would be unable to validate those
# transactions. This could lead to different versions of the fabric binaries
# having different world states. Instead, defining a capability for a channel
# informs those binaries without this capability that they must cease
# processing transactions until they have been upgraded. For v1.0.x if any
# capabilities are defined (including a map with all capabilities turned off)
# then the v1.0.x peer will deliberately crash.
#
################################################################################
Capabilities:
# Channel capabilities apply to both the orderers and the peers and must be
# supported by both.
# Set the value of the capability to true to require it.
Channel: &ChannelCapabilities
# V2_0 capability ensures that orderers and peers behave according
# to v2.0 channel capabilities. Orderers and peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 capability.
# Prior to enabling V2.0 channel capabilities, ensure that all
# orderers and peers on a channel are at v2.0.0 or later.
V2_0: true
# Orderer capabilities apply only to the orderers, and may be safely
# used with prior release peers.
# Set the value of the capability to true to require it.
Orderer: &OrdererCapabilities
# V2_0 orderer capability ensures that orderers behave according
# to v2.0 orderer capabilities. Orderers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 orderer capability.
# Prior to enabling V2.0 orderer capabilities, ensure that all
# orderers on channel are at v2.0.0 or later.
V2_0: true
# Application capabilities apply only to the peer network, and may be safely
# used with prior release orderers.
# Set the value of the capability to true to require it.
Application: &ApplicationCapabilities
# V2_0 application capability ensures that peers behave according
# to v2.0 application capabilities. Peers from
# prior releases would behave in an incompatible way, and are therefore
# not able to participate in channels at v2.0 application capability.
# Prior to enabling V2.0 application capabilities, ensure that all
# peers on channel are at v2.0.0 or later.
V2_0: true
################################################################################
#
# SECTION: Application
#
# - This section defines the values to encode into a config transaction or
# genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
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
################################################################################
#
# SECTION: Orderer
#
# - This section defines the values to encode into a config transaction or
# genesis block for orderer related parameters
#
################################################################################
Orderer: &OrdererDefaults
# Orderer Type: The orderer implementation to start
OrdererType: etcdraft
EtcdRaft:
Consenters:
- Host: orderer.example.com
Port: 7050
ClientTLSCert: ./ordererorganization/orderers/orderer.example.com/tls/server.crt
ServerTLSCert: ./ordererorganization/orderers/orderer.example.com/tls/server.crt
# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 2s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 10
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 99 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 KB
# Organizations is the list of orgs which are defined as participants on
# the orderer side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Orderer policies, their canonical path is
# /Channel/Orderer/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# BlockValidation specifies what signatures must be included in the block
# from the orderer for the peer to validate it.
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
################################################################################
#
# CHANNEL
#
# This section defines the values to encode into a config transaction or
# genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
# Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/<PolicyName>
Policies:
# Who may invoke the 'Deliver' API
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
# Who may invoke the 'Broadcast' API
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
# By default, who may modify elements at this config level
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# Capabilities describes the channel level capabilities, see the
# dedicated Capabilities section elsewhere in this file for a full
# description
Capabilities:
<<: *ChannelCapabilities
################################################################################
#
# Profile
#
# - Different configuration profiles may be encoded here to be specified
# as parameters to the configtxgen tool
#
################################################################################
Profiles:
TwoOrgsOrdererGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Capabilities:
<<: *OrdererCapabilities
I know that there is someway to achieve this as I have seen some HLF Blockchain service providers spins up sample ordering service and later add a consortium to it. I couldn't find any references though. I would really appreciate any help w.r.t this. I am stuck in a deadlock.
Consortium definition is required for bootstraping an orderer service. You may try defining a consortium with an empty organization list. The organization list of the consortium can be operated dynamicly.
Sample profile:
SampleSingleMSPSolo:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
I am having HLF network with two orgs (one peer each) and 3 order nodes with order type as a raft. For the first org joining and the peer, updates work without any problem, but for the second org I am getting some troubles in the peer update
Here is the command i've used for the peer update
peer channel update \
-o orderer1.base.order:7050 \
-c basechannel \
-f ./channel-artifacts/BaseRightOrg.tx \
--tls \
--cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/base.order/orderers/orderer1.base.order/msp/tlscacerts/tlsca.base.order-cert.pem
The error I am getting is
Error: got unexpected status: BAD_REQUEST -- error applying config
update to existing channel 'basechannel': error authorizing update:
error validating DeltaSet: policy for [Group]
/Channel/Application/RightOrgMSP not satisfied: signature set did not
satisfy policy
Here is the configtx section of the above org
- &Org2
Name: RightOrgMSP
ID: RightOrgMSP
MSPDir: crypto-config/peerOrganizations/base.right/msp
Policies:
Readers:
Type: Signature
Rule: "OR('RightOrgMSP.admin', 'RightOrgMSP.peer', 'RightOrgMSP.client','RightOrgMSP.member')"
Writers:
Type: Signature
Rule: "OR('RightOrgMSP.admin','RightOrgMSP.peer', 'RightOrgMSP.client','RightOrgMSP.member')"
Admins:
Type: Signature
Rule: "OR('LeftOrgMSP.admin','RightOrgMSP.peer')"
Endorsement:
Type: Signature
Rule: "OR('RightOrgMSP.peer')"
AnchorPeers:
- Host: peer1.base.right
Port: 9051
The file (./channel-artifacts/BaseRightOrg.tx) should be signed by all/majority of admins of the organizations that are part of the channel sequentially(that is one after other the same file). Then only the update will be success.
Try using below command with every peer of the channel:
peer channel signconfigtx -f ./channel-artifacts/BaseRightOrg.tx
After signing, you can update the channel.
cafile
/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/base.order/orderers/orderer1.base.order/msp/tlscacerts/tlsca.base.order-cert.pem
In above line change the certificate location and key.
In your configtx under organisation you should only specify the admin for that organisation not both.
&Org2
Name: RightOrgMSP
ID: RightOrgMSP
MSPDir: crypto-config/peerOrganizations/base.right/msp
Policies:
Readers:
Type: Signature
Rule: "OR('RightOrgMSP.admin', 'RightOrgMSP.peer', 'RightOrgMSP.client','RightOrgMSP.member')"
Writers:
Type: Signature
Rule: "OR('RightOrgMSP.admin','RightOrgMSP.peer', 'RightOrgMSP.client','RightOrgMSP.member')"
Admins:
Type: Signature
Rule: "OR('RightOrgMSP.admin')"
Endorsement:
Type: Signature
Rule: "OR('RightOrgMSP.peer')"
AnchorPeers:
- Host: peer1.base.right
Port: 9051
Problem is not with this though check your channel application policy section, if it is MAJORITY Admins under admins that this channel update must be signed by both the organisations. Once signed by all the transaction which is majority in this case your update will work.
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
If you are still not able to perform it then share your complete configtx.
I am extending the first network example with raft consensus on multiple hosts. When I try to start the orderers, the first orderer starts up but, I can not start any other orderers from both the same organisation and other organisation. The error I get as follows
[common.deliver] deliverBlocks -> WARN 019 [channel:
orderersyschannel] Client authorization revoked for deliver request
from 172.18.0.5:45506: implicit policy evaluation failed - 0
sub-policies were satisfied, but this policy requires 1 of the
'Readers' sub-policies to be satisfied: permission denied 2019-09-23
07:22:52.937 UTC [comm.grpc.server] 1 -> INFO 01a streaming call
completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver
grpc.peer_address=172.18.0.5 :45506
grpc.peer_subject="CN=ord1-org2,OU=orderer,O=Hyperledger,ST=North
Carolina,C=US" grpc.code=OK grpc.call_duration=1.590709ms
2019-09-23 07:22:52.945 UTC [orderer.common.cluster.replication]
fetchLastBlockSeq -> WARN 01b Received status:FORBIDDEN from
ord1-org2.local:7050: forbidden pullin g the channel
2019-09-23 07:22:52.945 UTC [orderer.common.cluster.replication] func1
-> WARN 01c Received error of type 'forbidden pulling the channel' from {ord1-org2.local:7050
I also checked my policies in 'configtx.yaml'
In Organisations section:
Readers:
Type: Signature
Rule: "OR('org2MSP.member', 'org2MSP.admin', 'org2MSP.peer', 'org2MSP.client')"
Writers:
Type: Signature
Rule: "OR('org2MSP.member', 'org2MSP.admin', 'org2MSP.client')"
Admins:
Type: Signature
Rule: "OR('org2MSP.admin')"
in Orderer section I have:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# BlockValidation specifies what signatures must be included in the block
# from the orderer for the peer to validate it.
BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers"
I am not sure why the policies or not met. Can anyone help me troubleshoot this?
Try by editing this block in your configtx.yaml file and regenerate genesis block.
Profiles:
TwoOrgsOrdererGenesis:
<<: *ChannelDefaults
Orderer:
<<: *OrdererDefaults
Organizations:
- *Org1
**- *Org2**
Capabilities:
<<: *OrdererCapabilities
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2