Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft


Faisal
 

Environment

HLF (1.4.2)
Orderer (RAFT 3 Node)
2 Orgs (adding 3rd Org)
Running on multiple hosts (Docker Swarm Cluster)

Steps Followed
Configtx.yaml file contents

# 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:
- &SFDA
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: SFDAMSP

# ID to load the MSP definition as
ID: SFDAMSP

MSPDir: crypto-config/peerOrganizations/sfda.example.com/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('SFDAMSP.admin', 'SFDAMSP.peer', 'SFDAMSP.client')"
Writers:
Type: Signature
Rule: "OR('SFDAMSP.admin', 'SFDAMSP.client')"
Admins:
Type: Signature
Rule: "OR('SFDAMSP.admin')"

# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.sfda.example.com
Port: 7051



crypto-config.yaml

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org3
# ---------------------------------------------------------------------------
- Name: SFDA
Domain: sfda.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1


1- Generated Certs

cryptogen generate --config=./crypto-config.yaml


2- Generated Configuration

configtxgen -printOrg SFDAMSP > ./SFDA.json


3- Copied Certs and configuration file into cli

4- Set environment variables for Orderer in CLI and channel name

5- Ran the following set of commands

```
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config >config.json
```

Append the configuration of the new org in **SFDA.json** file into the **config.json** file. Change the file name and MSP in the below command accordingly.
```
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"SFDAMSP":.[1]}}}}}' config.json ./SFDA.json > modified_config.json
```
Verify that the file has been updated
```
diff config.json modified_config.json
```

Package updated configuration into a block and then create a block that is delta of the old and new configuration
```
# Pack config again, create a delta of new and old config
configtxlator proto_encode --input config.json --type common.Config >original_config.pb
configtxlator proto_encode --input modified_config.json --type common.Config >modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original original_config.pb --updated modified_config.pb >config_update.pb
```
Convert the Delta Block **config_update.pb** block to JSON again, append the header to it and create a package again. Modify the channel name in the second command accordingly
```
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate >config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope >update-block-env.pb
```


6- Set the environment for Peer0 Org1 and Signed the update-block-env.pb

peer channel signconfigtx -f update-block-env.pb


7- Set the environment for Peer0 Org2 and send the transaction to orderer

peer channel update -f update-block-env.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA


8- Deployed the peer and couchdbs
9- Installed chaincode on all peers including new peers added
10- Upgraded the chaincode with the new endorsement policy
11- Sent a transaction and received the following warning.


What would be the implications of this warning in the future or can it can be ignored?


Yacov
 

Ignore it, it's a transient warning.

It happens if you get a state info message signed from a node which you did not yet receive its certificate.
You will eventually receive the certificate and be able to validate the signature.



From:        "Faisal" <mfaisaltariq@...>
To:        fabric@...
Date:        03/24/2020 03:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft
Sent by:        fabric@...




Environment

HLF (1.4.2)
Orderer (RAFT 3 Node)
2 Orgs (adding 3rd Org)
Running on multiple hosts (Docker Swarm Cluster)


Steps Followed

Configtx.yaml file contents

# 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:
-&SFDA
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name:SFDAMSP

# ID to load the MSP definition as
ID:SFDAMSP

MSPDir:crypto-config/peerOrganizations/sfda.example.com/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('SFDAMSP.admin', 'SFDAMSP.peer', 'SFDAMSP.client')"
Writers:
Type:Signature
Rule:"OR('SFDAMSP.admin', 'SFDAMSP.client')"
Admins:
Type:Signature
Rule:"OR('SFDAMSP.admin')"

# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
-Host:peer0.sfda.example.com
Port:7051



crypto-config.yaml

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org3
# ---------------------------------------------------------------------------
-Name:SFDA
Domain:sfda.example.com
EnableNodeOUs:true
Template:
Count:2
Users:
Count:1


1- Generated Certs

cryptogen generate --config=./crypto-config.yaml


2- Generated Configuration

configtxgen -printOrg SFDAMSP > ./SFDA.json


3- Copied Certs and configuration file into cli

4- Set environment variables for Orderer in CLI and channel name

5- Ran the following set of commands

```
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config >config.json
```

Append the configuration of the new org in **SFDA.json**file into the **config.json**file. Change the file name and MSP in the below command accordingly.
```
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"SFDAMSP":.[1]}}}}}' config.json ./SFDA.json > modified_config.json
```
Verify that the file has been updated
```
diff config.json modified_config.json
```

Package updated configuration into a block and then create a block that is delta of the old and new configuration
```
# Pack config again, create a delta of new and old config
configtxlator proto_encode --input config.json --type common.Config >original_config.pb
configtxlator proto_encode --input modified_config.json --type common.Config >modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original original_config.pb --updated modified_config.pb >config_update.pb
```
Convert the Delta Block **config_update.pb**block to JSON again, append the header to it and create a package again. Modify the channel name in the second command accordingly
```
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate >config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope >update-block-env.pb
```


6- Set the environment for Peer0 Org1 and Signed the update-block-env.pb

peer channel signconfigtx -f update-block-env.pb


7- Set the environment for Peer0 Org2 and send the transaction to orderer

peer channel update -f update-block-env.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA


8- Deployed the peer and couchdbs
9- Installed chaincode on all peers including new peers added
10- Upgraded the chaincode with the new endorsement policy
11- Sent a transaction and received the following warning.



What would be the implications of this warning in the future or can it can be ignored?





Faisal
 

Is this fixed in the 1.4.4 version LTS as we plan to upgrade the network in the coming weeks?


Yacov
 

this is not a "bug", this is a natural product of messages being gossiped out of order which is how gossip works.
This is a warning, not an error... if you see it repeatedly only then you should be worried



From:        "Faisal" <mfaisaltariq@...>
To:        fabric@...
Date:        03/24/2020 09:04 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft
Sent by:        fabric@...




Is this fixed in the 1.4.4 version LTS as we plan to upgrade the network in the coming weeks?