minifabric icon indicating copy to clipboard operation
minifabric copied to clipboard

Multi server / multi org setup - cannot join org

Open nikolas-digitalBabylon opened this issue 3 years ago • 6 comments

Hi,

I am trying to set the following up:

Server A - ordering org (ca + 3 ordering peers) Server B - org1 (ca + 1 peer) Server C - org2 (ca + 1 peer)

Server A spec.yaml: `fabric: cas:

  • "ca.orderers.example.com" orderers:
  • "orderer1.orderers.example.com"
  • "orderer2.orderers.example.com"
  • "orderer3.orderers.example.com"`

Server B spec.yaml: `fabric: cas:

  • "ca.org0.example.com" peers:
  • "peer1.org0.example.com"`

Server C spec.yaml: `fabric: cas:

  • "ca.org1.example.com" peers:
  • "peer1.org1.example.com"`

The scenario is that:

  1. ordering org is NOT controlled by either org0 or org1 operators
  2. org0 joins the network of ordering org
  3. org1 joins the network
  4. org0 creates channel and adds org1

How can I do that with minifabric ? In the examples provided, it is always assumed that orderers are at least under the control of the same operator, on same server. I would appreciate any hints.

nikolas-digitalBabylon avatar Feb 20 '22 15:02 nikolas-digitalBabylon

you can setup server A with your orgs, then setup B and C separately, then join B to A, then join C to A+B.

Tong Li IBM Open Technology

From: "Nikolas" @.> To: "hyperledger-labs/minifabric" @.> Cc: "Subscribed" @.***> Date: 02/20/2022 10:38 AM Subject: [EXTERNAL] [hyperledger-labs/minifabric] Multi server / multi org setup - cannot join org (Issue #329)

Hi, I am trying to set the following up: Server A - ordering org (ca + 3 ordering peers) Server B - org1 (ca + 1 peer) Server C - org2 (ca + 1 peer) Server A spec.yaml: `fabric: cas: "ca.orderers.example.com" orderers: ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Hi,

I am trying to set the following up:

Server A - ordering org (ca + 3 ordering peers) Server B - org1 (ca + 1 peer) Server C - org2 (ca + 1 peer)

Server A spec.yaml: fabric: cas: "ca.orderers.example.com" orderers: "orderer1.orderers.example.com" "orderer2.orderers.example.com" "orderer3.orderers.example.com"

Server B spec.yaml: fabric: cas: "ca.org0.example.com" peers: "peer1.org0.example.com"

Server C spec.yaml: fabric: cas: "ca.org1.example.com" peers: "peer1.org1.example.com"

The scenario is that: ordering org is NOT controlled by either org0 or org1 operators org0 joins the network of ordering org org1 joins the network org0 creates channel and adds org1

How can I do that with minifabric ? In the examples provided, it is always assumed that orderers are at least under the control of the same operator, on same server. I would appreciate any hints.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

litong01 avatar Feb 21 '22 13:02 litong01

But if I do that, it is assumed that the operator of server A, has the crypto material generated for org0 and org1, right? If yes, it is exactly what I want to avoid, the scenario is that they are separated organizations with different operators. Private keys should only be accessible to the operator of each org. Did I get something wrong?

Thank you!

nikolas-digitalBabylon avatar Feb 21 '22 19:02 nikolas-digitalBabylon

@nikolas-digitalBabylon i guess if we operate the different organizations in different servers and make the other channel to join the main channel , it will not have the crypto material and the private keys of the other organization it will just change the channel configuration file and make the nodes to connect to each other , the private keys and all the other crypto keys will be available to that private network only , so one organization can do transaction on behalf of other organization , but they can query the committed block and see the transactions from other peers.

rupam150 avatar Jun 02 '22 10:06 rupam150

@nikolas-digitalBabylon You can follow the expand your network under docs in the repo to try so .

rupam150 avatar Jun 02 '22 10:06 rupam150

Hi,

thank you for your response. The point is the following: Normally, one org should not have the secret crypto material of other orgs. With this in mind, the flow should be:

  1. some operator sets up the ordering service (e.g. a service provider)
  2. org A is permitted to use the ordering service by the provider, so org A sends its public crypto material (the "join-request.json") to the orderer op, who ads them to the network / consortium.
  3. org B follows same way with org A, so they are both part of the consortium under the same ordering service. Now org A and org B can engage using the ordering service. With the above, nobody shares his secret crypto material. This flow though, doesn't seem to be enabled by minifab. Am I missing something? Do maintainers see it otherwise? is another approach suggested?

nikolas-digitalBabylon avatar Jun 02 '22 19:06 nikolas-digitalBabylon

Hi @nikolas-digitalBabylon , if you can see the steps in the expand network (docs folder github repo ) the join request is used is used in the Minifab before adding any organization to an existing network , and the endpoints.yaml (share the ordering service to new organization) , the main point of concern is the transactions and query to the ledger which is done using the private key which is only available to each user , no one has acess to that key , so without having access to these make is secure , i geuss . I don'nt how much i followed up your query , @litong01 may answer it in better way !!!!!!!!

rupam150 avatar Jun 03 '22 07:06 rupam150