Unable to update batchtimeout in orderer configuration?

Question

I have created a network of fabric and it running fine. I want to update the oderer configuration such as batchtimeout in running network. I have followed this tutorial to update the channel configuration at runtime. This tutorial works for adding a new org. But when i am updating orderer configuration then i am getting error as

Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/Orderer/BatchTimeout 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 sigining the envelope.pb file from all the org admins such as org1 and org2. Kindly help me with this.

Note: I have used fabric-samples first-network for this.

EDIT: I have signed pb file with org1 and org2.I have also signed it with orderer by exporting below variables

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin\@example.com/msp/

CORE_PEER_ADDRESS=orderer.example.com:7050

CORE_PEER_LOCALMSPID=OrdererMSP

CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt

Logs

11-28 09:13:57.207 UTC [policies] Manager -> DEBU cc4 Manager Channel/Orderer looking up path []
2019-11-28 09:13:57.207 UTC [policies] Manager -> DEBU cc5 Manager Channel/Orderer has managers OrdererOrg
2019-11-28 09:13:57.207 UTC [policies] Evaluate -> DEBU cc6 == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Admins ==
2019-11-28 09:13:57.207 UTC [policies] Evaluate -> DEBU cc7 This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-11-28 09:13:57.207 UTC [policies] Evaluate -> DEBU cc8 == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Admins ==
2019-11-28 09:13:57.207 UTC [cauthdsl] deduplicate -> WARN cc9 De-duplicating identity [OrdererMSP95598fd8d4ea9aa73dad2aee5bc32375d01e3ed9da0a25c2f64ae1067af7ac74] at index 1 in signature set
2019-11-28 09:13:57.207 UTC [cauthdsl] deduplicate -> WARN cca De-duplicating identity [OrdererMSP95598fd8d4ea9aa73dad2aee5bc32375d01e3ed9da0a25c2f64ae1067af7ac74] at index 2 in signature set
2019-11-28 09:13:57.208 UTC [cauthdsl] func1 -> DEBU ccb 0xc000c99ef0 gate 1574932437208001961 evaluation starts
2019-11-28 09:13:57.208 UTC [cauthdsl] func2 -> DEBU ccc 0xc000c99ef0 signed by 0 principal evaluation starts (used [false false false])
2019-11-28 09:13:57.208 UTC [cauthdsl] func2 -> DEBU ccd 0xc000c99ef0 processing identity 0 with bytes of a1f390
2019-11-28 09:13:57.208 UTC [msp] satisfiesPrincipalInternalV143 -> DEBU cce Checking if identity has been named explicitly as an admin for OrdererMSP
2019-11-28 09:13:57.208 UTC [msp] satisfiesPrincipalInternalV143 -> DEBU ccf Checking if identity carries the admin ou for OrdererMSP
2019-11-28 09:13:57.208 UTC [msp] Validate -> DEBU cd0 MSP OrdererMSP validating identity
2019-11-28 09:13:57.208 UTC [msp] getCertificationChain -> DEBU cd1 MSP OrdererMSP getting certification chain
2019-11-28 09:13:57.208 UTC [msp] hasOURole -> DEBU cd2 MSP OrdererMSP checking if the identity is a client
2019-11-28 09:13:57.208 UTC [msp] getCertificationChain -> DEBU cd3 MSP OrdererMSP getting certification chain
2019-11-28 09:13:57.208 UTC [cauthdsl] func2 -> DEBU cd4 0xc000c99ef0 identity 0 does not satisfy principal: The identity is not an admin under this MSP [OrdererMSP]: The identity does not contain OU [ADMIN], MSP: [OrdererMSP]
2019-11-28 09:13:57.208 UTC [cauthdsl] func2 -> DEBU cd5 0xc000c99ef0 principal evaluation fails
2019-11-28 09:13:57.208 UTC [cauthdsl] func1 -> DEBU cd6 0xc000c99ef0 gate 1574932437208001961 evaluation fails
2019-11-28 09:13:57.208 UTC [policies] Evaluate -> DEBU cd7 Signature set did not satisfy policy /Channel/Orderer/OrdererOrg/Admins
2019-11-28 09:13:57.208 UTC [policies] Evaluate -> DEBU cd8 == Done Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Admins
2019-11-28 09:13:57.208 UTC [policies] func1 -> DEBU cd9 Evaluation Failed: Only 0 policies were satisfied, but needed 1 of [ OrdererOrg/Admins ]
2019-11-28 09:13:57.208 UTC [policies] Evaluate -> DEBU cda Signature set did not satisfy policy /Channel/Orderer/Admins
2019-11-28 09:13:57.208 UTC [policies] Evaluate -> DEBU cdb == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Admins
2019-11-28 09:13:57.208 UTC [orderer.common.broadcast] ProcessMessage -> WARN cdc [channel: mychannel] Rejecting broadcast of config message from 172.25.0.7:42570 because of error: error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/BatchTimeout not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
2019-11-28 09:13:57.208 UTC [orderer.common.server] func1 -> DEBU cdd Closing Broadcast stream
2019-11-28 09:13:57.208 UTC [comm.grpc.server] 1 -> INFO cde streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Broadcast grpc.peer_address=172.25.0.7:42570 grpc.code=OK grpc.call_duration=1.864323ms
2019-11-28 09:13:57.209 UTC [grpc] warningf -> DEBU cdf transport: http2Server.HandleStreams failed to read frame: read tcp 172.25.0.3:7050->172.25.0.7:42570: read: connection reset by peer
2019-11-28 09:13:57.209 UTC [grpc] infof -> DEBU ce0 transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2019-11-28 09:13:57.209 UTC [grpc] infof -> DEBU ce1 transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2019-11-28 09:13:57.209 UTC [common.deliver] Handle -> WARN ce2 Error reading from 172.25.0.7:42568: rpc error: code = Canceled desc = context canceled
2019-11-28 09:13:57.209 UTC [orderer.common.server] func1 -> DEBU ce3 Closing Deliver stream
2019-11-28 09:13:57.209 UTC [comm.grpc.server] 1 -> INFO ce4 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.25.0.7:42568 error="rpc error: code = Canceled desc = context canceled" grpc.code=Canceled grpc.call_duration=4.921585ms

Updated env

CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt
    CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
    CORE_PEER_LOCALMSPID=OrdererMSP
    CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
    CORE_PEER_TLS_ENABLED=true
    CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/users/Admin@example.com/msp/
    CORE_PEER_ID=cli
    CORE_PEER_ADDRESS=orderer.example.com:7050

score 6 · Answer 1 · answered Nov 28 '19 at 11:41

I am facing the same issue, but on BatchSize updating.

You can see the orderer log below:

2019-11-28 11:28:42.768 UTC [policies] Evaluate -> DEBU d6e This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2019-11-28 11:28:42.768 UTC [policies] Evaluate -> DEBU d6f == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Admins ==
2019-11-28 11:28:42.768 UTC [cauthdsl] deduplicate -> WARN d70 De-duplicating identity [OrdererMSPde02f61469eb325656c1a87232aeff9f44728b59015fccc5995bd849935812cb] at index 1 in signature set
2019-11-28 11:28:42.768 UTC [cauthdsl] deduplicate -> WARN d71 De-duplicating identity [OrdererMSPde02f61469eb325656c1a87232aeff9f44728b59015fccc5995bd849935812cb] at index 2 in signature set
2019-11-28 11:28:42.768 UTC [cauthdsl] func1 -> DEBU d72 0xc000453620 gate 1574940522768302200 evaluation starts
2019-11-28 11:28:42.768 UTC [cauthdsl] func2 -> DEBU d73 0xc000453620 signed by 0 principal evaluation starts (used [false false false])
2019-11-28 11:28:42.768 UTC [cauthdsl] func2 -> DEBU d74 0xc000453620 processing identity 0 with bytes of fd5830
2019-11-28 11:28:42.768 UTC [cauthdsl] func2 -> DEBU d75 0xc000453620 identity 0 does not satisfy principal: The identity is not an admin under this MSP [OrdererMSP]: The identity does not contain OU [ADMIN], MSP: [OrdererMSP]
2019-11-28 11:28:42.768 UTC [cauthdsl] func2 -> DEBU d76 0xc000453620 principal evaluation fails
2019-11-28 11:28:42.768 UTC [cauthdsl] func1 -> DEBU d77 0xc000453620 gate 1574940522768302200 evaluation fails
2019-11-28 11:28:42.768 UTC [policies] Evaluate -> DEBU d78 Signature set did not satisfy policy /Channel/Orderer/OrdererOrg/Admins
2019-11-28 11:28:42.768 UTC [policies] Evaluate -> DEBU d79 == Done Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererOrg/Admins
2019-11-28 11:28:42.768 UTC [policies] func1 -> DEBU d7a Evaluation Failed: Only 0 policies were satisfied, but needed 1 of [ OrdererOrg/Admins ]
2019-11-28 11:28:42.768 UTC [policies] Evaluate -> DEBU d7b Signature set did not satisfy policy /Channel/Orderer/Admins
2019-11-28 11:28:42.768 UTC [policies] Evaluate -> DEBU d7c == Done Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Admins
2019-11-28 11:28:42.768 UTC [orderer.common.broadcast] ProcessMessage -> WARN d7d [channel: mychannel] Rejecting broadcast of config message from 172.29.0.7:43756 because of error: error applying config update to existing channel 'mychannel': error authorizing update: error validating DeltaSet: policy for [Value]  /Channel/Orderer/BatchSize 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 have tried to add an OrganizationalUnit: ADMIN in the crypto-config.yaml file, in order to fix - The identity does not contain OU [ADMIN]. The OU was added but but this doesn't help me.

I also have tried to copy the orderer sign certificate to the msp/admincerts in order to fix - The identity is not an admin under this MSP [OrdererMSP], e.g. cp ${ORG_ADMIN_HOME}/msp/signcerts/* ${ORG_ADMIN_HOME}/msp/admincerts

Hope the above steps will help someone, I am still investigating my issue with the channel configuration update. ✌️

score 1 · Answer 2 · answered Nov 28 '19 at 12:20

For you both.

https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification. If you are using NodeOUs, be sure to check the config.yaml in every MSP folder is correct, that the OU fields of the admin certificates include admin (as defined in your config.yaml and in your configtx.yaml organization policies), and that your configtx.yaml at least specifies:

Capabilities:
    Channel: &ChannelCapabilities
        V1_4_3: true
        V1_1: true

@TechChain, you are now signing with a non-admin OrdererMSP, when you have a first policy check expecting any (non-OrdererMSP) organization writer signature and a second policy check expecting an admin OrdererMSP.

score 1 · Answer 3 · edited Feb 12 '22 at 00:21

Try this:

Export orderer organization environment:

export CH_NAME=<your-channel>
export CORE_PEER_LOCALMSPID="OrdererMSP"
export CORE_PEER_MSPCONFIGPATH=<ca-client-path>/organizations/ordererOrganizations/orderer.com/users/admin@orderer.com/msp/    <OR>    <your-orderer-admin-msp-path>
export ORDERER_CONTAINER=localhost:7050
export ORDERER_CA=../../ca/fabric-ca-client/organizations/ordererOrganizations/orderer.com/msp/tlscacerts/<your-tls-cert>.pem    <OR>        <your-orderer-tlscert-path>
export FABRIC_CFG_PATH=../../peers/<your-org-peer>

Sign-in using the signconfigtx tool:

peer channel signconfigtx -f <your-enveloped-config>.pb

Try to send the config update again:

peer channel update -f <your-enveloped-config>.pb -c $CH_NAME -o $ORDERER_CONTAINER --tls --cafile $TLS_ROOT_CA

kekomal · Answer 4 · 2019-11-28T09:15:21.927

0

Then, the transaction maybe also needs to be signed the orderer's admin.

The way to know what signature is missing is setting FABRIC_LOGGING_SPEC=DEBUG in the orderer and looking for the orderer DEBUG messages previous to the error. There you can see every signature certificate received in pem format and which organizations and roles are checked an passed (or not). I know that logs allergy spreads among many StackOverflow users, but it's the only way to find out what's going on.

EDIT:

What I mean:

Set FABRIC_LOGGING_SPEC=DEBUG in your orderer/s.
Relaunch your orderers so the new environment variable is applied.
Debug the process of checking the policies painstakingly and patiently.
- docker logs -f --tail 200 myorderercontainer 2>&1 | grep ERRO -B100 -A10

edited Nov 28 '19 at 09:15

answered Nov 28 '19 at 08:07

kekomal

2,179
11
12

Ok let me check – TechChain Nov 28 '19 at 08:41
The most interesting log is `Only 0 policies were satisfied, but needed 1 of [ OrdererOrg/Admins ]`. So your update transaction only needs to be signed by an OrdererOrg admin (the others are left over, but they don't interfere), and it is not. None of the signatures you added belong to OrdererOrg or are admins of that organization. The DEBUG logs previous to those you have copied clarify what of the 2 issues is happening (I bet the first one). Invoke the transaction from an OrdererOrg admin client (or at least make that client sign it). – kekomal Nov 28 '19 at 09:34
What i did is exported mspconfigpath rootcert of oderer into cli and tried to sign with orderer but it dod not work. – TechChain Nov 28 '19 at 09:57
`docker exec -it yourclientcontainer bash` to enter your client container. What shows `env | grep CORE_PEER_`? What shows `openssl -text -noout -in $CORE_PEER_MSPCONFIGPATH/signcerts/cert.pem`? – kekomal Nov 28 '19 at 10:08
Makes sense. Try to force the orderer's signature before invoking: `peer channel signconfigtx -f envelope.pb`. It should not be necessary, but if your envelope has already been signed (by org's admins), it is possible that your orderer's client decides not to sign it. – kekomal Nov 28 '19 at 10:37
so you are trying to say i should exec as ordrerer admin into cli and create enevelope ? – TechChain Nov 28 '19 at 10:41
Of course. If your policy requires that your transaction is signed by an OrdererOrg admin, an OrdererOrg client with admin role must sign the transaction. So you must configure `CORE_PEER_MSPCONFIGPATH` to point to your OrdererOrg admin MSP to get `peer` command sign suitably. – kekomal Nov 28 '19 at 10:49
well, it still does not work. Tried it with the signing by orderermsp also – TechChain Nov 28 '19 at 11:09
`docker logs -f --tail 200 myorderercontainer 2>&1 | grep WARN -B150 -A10`. Copy the logs from the PEM certificates. – kekomal Nov 28 '19 at 11:18
Mmm... in the logs received BEFORE the logs you pasted, I expected to see the received certificates in pem format and some more checks. Are you sure you are signing the transaction? – kekomal Nov 28 '19 at 11:43
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/203238/discussion-between-techchain-and-kekomal). – TechChain Nov 28 '19 at 11:51

score 0 · Answer 5 · answered Nov 28 '19 at 13:23

0

Thanks, @kekomal!

I have checked config.yaml files in every MSP folder.For example the one for the OrderereMSP looks like this:

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.example.com-cert.pem
    OrganizationalUnitIdentifier: orderer

I have updated and the channel capabilities section with:

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
        # V1.4.3 for Channel is a catchall flag for behavior which has been
        # determined to be desired for all orderers and peers running at the v1.4.3
        # level, but which would be incompatible with orderers and peers from
        # prior releases.
        # Prior to enabling V1.4.3 channel capabilities, ensure that all
        # orderers and peers on a channel are at v1.4.3 or later.
        V1_4_3: true
        # V1.3 for Channel enables the new non-backwards compatible
        # features and fixes of fabric v1.3
        V1_3: true
        # V1.1 for Channel enables the new non-backwards compatible
        # features and fixes of fabric v1.1
        V1_1: true

The end result is the same, failed channel update tx.

If you have any other suggestions, please share.

answered Nov 28 '19 at 13:23

Vladislav Ivanov

61
2

You have regenerated the genesis block and restarted the network from scratch with the new genesis block, haven't you? – kekomal Nov 28 '19 at 14:22
Yes I have, ```./byfn down``` and right after that ```./byfn up```. – Vladislav Ivanov Nov 28 '19 at 14:32
OK, you'll now. I have ever avoided `byfn`, so I don't really know what it performs. It is the best way to start with Hyperledger Fabric quickly without learning anything. I build my networks manually. As long as your docker services are not persisting the state in volumes or `./byfn down` clears the volumes, it is OK. Otherwise, the changes will not be applied. – kekomal Nov 28 '19 at 14:56
The ```./byfn down``` script clears volumes. The steps on down command are: Bring down the network, deleting the volumes, Delete any ledger backups, Cleanup the chaincode containers, cleanup images, remove orderer block and other channel configuration transactions and certs, remove the docker-compose yaml file that was customized to the example. So I believe that all of the suggested changes are applied after down/up process. – Vladislav Ivanov Nov 28 '19 at 15:46
@kekomal I use the BYFN when I want to validate something quickly. For example, updating a channel configuration. If you have time please take a look at this tutorial, which I have followed and if you see some potential problems, please share - https://medium.com/coinmonks/hyperledger-fabric-updating-channel-configs-45082a5dc9b2 – Vladislav Ivanov Nov 28 '19 at 16:07
Not much time... Anyway, your current problem seems to be related to NodeOUs, more than the update itself. Your request should be signed by an OrdererMSP admin, but it is signed by a non-admin OrdererMSP. Center on that. – kekomal Nov 28 '19 at 16:31
Has anyone got the solution ? I – TechChain Nov 29 '19 at 04:26
@TechChain, the silly temporary solution is to remove ```EnableNodeOUs: true``` from the ```crypto-config.yaml``` for the orderer organization. The update transaction is successfully executed. Currently I am trying to resolve the problem when the NodeOU is enabled(all configuration files look good), will update you if I have some progress there. Cheers! – Vladislav Ivanov Nov 29 '19 at 12:05
As @kemomal mentioned some comments above, the problem is with NodeOUs, another proof of that is - when I change a OrdererOrg Amin policy(```configtx.yaml```) to ``` Admins: Type: Signature Rule: "OR('OrdererMSP.client')"``` The update is done. For some reason identity is associated with Client role, instead of Admin. @kemomal, please give some advice how to proceed with the investigation of the problem – Vladislav Ivanov Nov 29 '19 at 13:32

Unable to update batchtimeout in orderer configuration?

5 Answers5