Date   

Re: #raft #fabric #raft #fabric

Prehoda Balazs
 

Hi,

I attached the orderer logs.

Thanks again,
Balazs

On Fri, Nov 8, 2019 at 4:53 AM Jay G <guojiannan1101@...> wrote:
hi Balazs,

could you attach full orderer log so we could diagnose? or pls observe orderer log to see how long it took to elect a leader, some thing similar to "Raft leader changed: 0 -> x"

thx
- J


On Thu, Nov 7, 2019 at 11:03 PM Prehoda Balazs <prehoda.balazs@...> wrote:

Hi,

I tried raft recently, and ran into this strange behavior:

When I invoke peer channel create ..., I always get &{NOT_FOUND} first, then &{SERVICE_UNAVAILABLE} 4 or 5 times. After that, everything is OK, I can join the peers and update the anchor peers successfully. I get the same even if I wait 5-10 minutes before trying to create the channel, or if I reduce the number of both the peers and orderers from 3 to 1. In the orderer logs, I can see 4 or 5 warnings about rejecting deliver request for my CLI's IP because of consenter error.

This behavior does not block me and my project, but I am sure it is not expected, and I would like to know why it works this way, and how I could fix it.

Any help or suggestions would be much appreciated.

Thanks,
Balazs

P.S.:

The script used to create the channel, join peers and update the anchor peers is attached.
The output of the create-join-channel.sh script:


The orderer logs:


Re: #raft #fabric #raft #fabric

Jay Guo
 

hi Balazs,

could you attach full orderer log so we could diagnose? or pls observe orderer log to see how long it took to elect a leader, some thing similar to "Raft leader changed: 0 -> x"

thx
- J


On Thu, Nov 7, 2019 at 11:03 PM Prehoda Balazs <prehoda.balazs@...> wrote:

Hi,

I tried raft recently, and ran into this strange behavior:

When I invoke peer channel create ..., I always get &{NOT_FOUND} first, then &{SERVICE_UNAVAILABLE} 4 or 5 times. After that, everything is OK, I can join the peers and update the anchor peers successfully. I get the same even if I wait 5-10 minutes before trying to create the channel, or if I reduce the number of both the peers and orderers from 3 to 1. In the orderer logs, I can see 4 or 5 warnings about rejecting deliver request for my CLI's IP because of consenter error.

This behavior does not block me and my project, but I am sure it is not expected, and I would like to know why it works this way, and how I could fix it.

Any help or suggestions would be much appreciated.

Thanks,
Balazs

P.S.:

The script used to create the channel, join peers and update the anchor peers is attached.
The output of the create-join-channel.sh script:


The orderer logs:


Unable to debug smart contract from VS Code debugger

Siddharth Jain
 

I am unable to debug my smart contract from vs code debugger. Here is my setup:
  • peer node is started with CORE_CHAINCODE_MODE=dev
  • fabric-chaincode-node is run with --peer-chaincodedev=true
    $ npm start -- --peer.address localhost:17052 --chaincode-id-name asset-contract --peer-chaincodedev=true
  • a vs code debug session is started with Node.js Attach by process ID configuration 
  • debugger is attached to the fabric-chaincode-node process and I am able to set breakpoints which also show up as activated in vs code


  • I can invoke the chaincode from command line but the debugger does not break
anyone knows what is the problem and how to fix it? Using 1.4 of Fabric


Re: Peers with different heights #fabric #database #consensus

David Enyeart
 

In addition to CORE_PEER_GOSSIP_EXTERNALENDPOINT for exposing the peer endpoints to other orgs, make sure you understand how anchor peers are configured to bootstap the cross-org communication:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html#anchor-peers
https://hyperledger-fabric.readthedocs.io/en/release-1.4/build_network.html#create-a-channel-configuration-transaction
https://hyperledger-fabric.readthedocs.io/en/release-1.4/build_network.html#update-the-anchor-peers

That being said, cross-org configuration is not strictly needed for block sync... Blocks should be synched correctly from org leader to org followers without the cross-org communication configured. Or like I said, you may want to force each peer to get blocks from orderer:
CORE_PEER_GOSSIP_USELEADERELECTION = false
CORE_PEER_GOSSIP_ORGLEADER = true

The cross-org communication becomes necessary if you are using private data or service discovery. Good luck!


Dave Enyeart

"Joao Antunes" ---11/07/2019 11:57:46 AM---Hi Dave, You are right and thank you for sending the lines of the default behaviour.

From: "Joao Antunes" <joao.antunes@...>
To: fabric@...
Date: 11/07/2019 11:57 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Peers with different heights #fabric #database #consensus
Sent by: fabric@...





Hi Dave,

You are right and thank you for sending the lines of the default behaviour.


After some investigations, I think I'm missing CORE_PEER_GOSSIP_EXTERNALENDPOINT.

I have CORE_PEER_GOSSIP_BOOTSTRAP configured on both peer2 from org2 and org1 and they both communicate with peer1-org2 and peer1-org1 respectively. But there is no gossip between orgs. Currently checking the effect of both variables in this setup.





Re: CA keys and storing/sending them

Gari Singh <garis@...>
 

Private keys are never sent anywhere.  Only public keys are included with transactions.

If you are using the fabric-ca-client or any of the SDKs, by default privates keys are created on the local file system of the host in which enroll.  You can also choose to use the PKCS11 provider to have the private generated and stored in an HSM.

If you do generate it on the local file system, then you should set the permissions to 0400 on *nix based OS’s.  You should also encrypt the file system ( especially when running in a public cloud)

Gari Singh
garis@...
978-846-7499



On Nov 7, 2019, at 11:32 AM, Trevor Lee Oakley <trevor@...> wrote:


 
Hi 
 
I understand that HLF  uses a client server CA and each member has its own CA. But txn approvals I have a question about securely storing and sending keys. Are there any guidelines for this? 
 
Trevor
 


Documentation Workgroup: Agenda for Friday, 08 November

Anthony O'Dowd <a_o-dowd@...>
 

Hello All,

We hold our regular documentation workgroup call this week, both Eastern and Western hemispheres. All US and European clocks have now moved back to standard time from daylight savings, so call times have returned to normal!

As is now usual, you can read the summary minutes for last week's call :https://wiki.hyperledger.org/display/fabric/2019+11+01+DWG+Agenda
Note that we've added a recordings page where you can catch up: https://wiki.hyperledger.org/display/fabric/Recordings  
A particular highlight was Chris Gabriel's demo: https://wiki.hyperledger.org/download/attachments/24773827/2109.11.01.DWG.part2.mp4?api=v2

Please feel free to contribute to the agenda for this week: https://wiki.hyperledger.org/display/fabric/2019+11+08+DWG+Agenda

We've also added an outline agenda for next week's meeting : https://wiki.hyperledger.org/display/fabric/2019+11+15+DWG+Agenda Again, feel free to add items.

Best regards,

Anthony, Pam, Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 104A: Friday 01 Nov
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 104B: Friday 01 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Peers with different heights #fabric #database #consensus

Joao Antunes
 

Hi Dave,

You are right and thank you for sending the lines of the default behaviour.


After some investigations, I think I'm missing CORE_PEER_GOSSIP_EXTERNALENDPOINT.

I have CORE_PEER_GOSSIP_BOOTSTRAP configured on both peer2 from org2 and org1 and they both communicate with peer1-org2 and peer1-org1 respectively. But there is no gossip between orgs. Currently checking the effect of both variables in this setup.


Re: Peers with different heights #fabric #database #consensus

David Enyeart
 

'peer node reset' should only be used if you suspect your peer's data is corrupted - it resets all channels to genesis block so that peer can re-pull/re-process blocks, but wouldn't change block dissemination behavior on your network.

If CORE_PEER_GOSSIP_USELEADERELECTION and CORE_PEER_GOSSIP_ORGLEADER environment variable overrides are not set, then it will fall back to the core.yaml configuration that is baked into the peer image, defaults can be found here:
https://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/core.yaml#L90-L100

Note that the private data reconciliation message is different... that is a background daemon thread that always runs to check whether there is any missing private data. It does not indicate a problem with block height or that there is actual missing private data, it's just checking, and in your case it found no problems.


Dave Enyeart

"Joao Antunes" ---11/07/2019 07:35:10 AM---Hi, Just making a small update.

From: "Joao Antunes" <joao.antunes@...>
To: fabric@...
Date: 11/07/2019 07:35 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Peers with different heights #fabric #database #consensus
Sent by: fabric@...





Hi,

Just making a small update.
I received another answer that suggested to do a peer node reset:
      1. Took a backup of peer docker container
      2. Took a backup of respective couchdb's data
      3. Stopped the chaincode container associated with this peer, if any
      4. Stopped the couchdb container of the peer
      5. Stopped the peer
      6. Since I was starting the peer using docker-compose file, I updated the peer startup command from 'peer node start' to 'peer node reset'. This will reset the peer's channel data to the genesis block.
      7. Next, again update the peer startup command from 'peer node reset' to 'peer node start'. This time since the peer does not have ledger data, it will pull the blocks from the other peers and rebuild its couchdb data.
(Thank you Mrudav Shukla)

Unfortunately, I don't have the 1.4.3 fabric version. So I scraped this solution.
I restart the peer and it's CouchDB. After the startup, the peer started to get the blocks that were missing and getting synchronized.

At the end of this, all the peers were in sync.


On another test that we did on the same setup, now it's peer1-org1 that is out os sync.

I checked docker-compose.yml and I have no CORE_PEER_GOSSIP_USELEADERELECTION and CORE_PEER_GOSSIP_ORGLEADER variables defined. So it's acting by default. Was is the default behaviour? (And thank you, David Enyeart, for the explanation).
I can see some gossip in logs, but peer1-org1 is still out of sync.

For example:

2019-11-07 12:29:08.498 UTC [gossip.privdata] reconcile -> DEBU 65a92e Reconciliation cycle finished successfully. no items to reconcile

(at this stage I know that is still out of sync).


One question that came up; If one peer is out of sync, and we have an OR policy for endorsement, where we require one member from Org1 or Org2 to endorse the transaction, why is there no block created and sent to orderer?

Thank you all.





CA keys and storing/sending them

Trevor Lee Oakley <trevor@...>
 

 
Hi 
 
I understand that HLF  uses a client server CA and each member has its own CA. But txn approvals I have a question about securely storing and sending keys. Are there any guidelines for this? 
 
Trevor
 


#raft #fabric #raft #fabric

Prehoda Balazs
 

Hi,

I tried raft recently, and ran into this strange behavior:

When I invoke peer channel create ..., I always get &{NOT_FOUND} first, then &{SERVICE_UNAVAILABLE} 4 or 5 times. After that, everything is OK, I can join the peers and update the anchor peers successfully. I get the same even if I wait 5-10 minutes before trying to create the channel, or if I reduce the number of both the peers and orderers from 3 to 1. In the orderer logs, I can see 4 or 5 warnings about rejecting deliver request for my CLI's IP because of consenter error.

This behavior does not block me and my project, but I am sure it is not expected, and I would like to know why it works this way, and how I could fix it.

Any help or suggestions would be much appreciated.

Thanks,
Balazs

P.S.:

The script used to create the channel, join peers and update the anchor peers is attached.
The output of the create-join-channel.sh script:


The orderer logs:


Re: Alternative of cryptogen for Prod

Clément Gautier
 

Hello there,

As an operator in a Hyperledger Fabric network I can ensure you that I won't allow cryptogen issued organizations to join any channel :D

Even during development process we encourage generating the materials through fabric-ca in order to be familiar with the process. We built some tools to help transfer the cert materials accross the organizations when you have access to the entire network (for dev purpose). We made an umbrella chart for Kubernetes if you want to have a look (it's poorly documented, we just open sourced it, so don't expect too much) https://github.com/SubstraFoundation/hlf-k8s/tree/dev/charts/hlf-k8s


Re: Peers with different heights #fabric #database #consensus

Joao Antunes
 

Another note regarding this:

Currently org2 is way more active in terms of gossip. Org1 is really "inactive".

Org1 logs:

2019-11-07 12:51:40.979 UTC [gossip.discovery] periodicalSendAlive -> DEBU 1ae61c Sleeping 5s

2019-11-07 12:51:41.581 UTC [gossip.election] waitForInterrupt -> DEBU 1ae61d 95c0c964c47844451090a1af28e3c7d4b500863398588989e20b33d80f9ac0c3 : Exiting

2019-11-07 12:51:41.581 UTC [gossip.election] IsLeader -> DEBU 1ae61e 95c0c964c47844451090a1af28e3c7d4b500863398588989e20b33d80f9ac0c3 : Returning true

2019-11-07 12:51:41.581 UTC [msp] GetDefaultSigningIdentity -> DEBU 1ae61f Obtaining default signing identity

2019-11-07 12:51:41.581 UTC [msp.identity] Sign -> DEBU 1ae620 Sign: plaintext: 1209666C6F7762696B65731804A20133...0D08F8DCBFD9EDA1A9EA1510B1691801 

2019-11-07 12:51:41.581 UTC [msp.identity] Sign -> DEBU 1ae621 Sign: digest: 86AEA3E8696FBCD622DCAC0DF058D2DED739D83A130EACB331613CDC0603DA22 

2019-11-07 12:51:41.581 UTC [gossip.election] waitForInterrupt -> DEBU 1ae622 95c0c964c47844451090a1af28e3c7d4b500863398588989e20b33d80f9ac0c3 : Entering

2019-11-07 12:51:42.869 UTC [msp] GetDefaultSigningIdentity -> DEBU 1ae623 Obtaining default signing identity

2019-11-07 12:51:42.869 UTC [msp.identity] Sign -> DEBU 1ae624 Sign: plaintext: 18012A340A221A2095C0C964C4784445...120E08DEA9878EEDA1A9EA15108FED01 

2019-11-07 12:51:42.869 UTC [msp.identity] Sign -> DEBU 1ae625 Sign: digest: 1904663DAC194AC78E09C68FD30771E22BAB35EADAFF4FEFE12D84A9872A26A0 

2019-11-07 12:51:42.869 UTC [msp] GetDefaultSigningIdentity -> DEBU 1ae626 Obtaining default signing identity

2019-11-07 12:51:42.869 UTC [msp.identity] Sign -> DEBU 1ae627 Sign: plaintext: 0A0F70656572322D6F7267313A37303531 

2019-11-07 12:51:42.869 UTC [msp.identity] Sign -> DEBU 1ae628 Sign: digest: B555158106298CB4B91D0A101BF545F9F577BABE611C2B0FDBE06D2DA984B1B9 

2019-11-07 12:51:43.759 UTC [gossip.discovery] periodicalReconnectToDead -> DEBU 1ae629 Sleeping 25s

2019-11-07 12:51:45.979 UTC [msp] GetDefaultSigningIdentity -> DEBU 1ae62a Obtaining default signing identity

2019-11-07 12:51:45.979 UTC [msp.identity] Sign -> DEBU 1ae62b Sign: plaintext: 18012A340A221A2095C0C964C4784445...120E08DEA9878EEDA1A9EA151090ED01 

2019-11-07 12:51:45.979 UTC [msp.identity] Sign -> DEBU 1ae62c Sign: digest: BFD957895083A6ED5971A01E47BE41BC04F0BCA940347DEE76A643F118E772B1 

2019-11-07 12:51:45.980 UTC [msp] GetDefaultSigningIdentity -> DEBU 1ae62d Obtaining default signing identity

2019-11-07 12:51:45.980 UTC [msp.identity] Sign -> DEBU 1ae62e Sign: plaintext: 0A0F70656572322D6F7267313A37303531 

 

2019-11-07 12:51:45.980 UTC [msp.identity] Sign -> DEBU 1ae62f Sign: digest: B555158106298CB4B91D0A101BF545F9F577BABE611C2B0FDBE06D2DA984B1B9 


Re: Peers with different heights #fabric #database #consensus

Joao Antunes
 

Hi,

Just making a small update.
I received another answer that suggested to do a peer node reset:

  1. Took a backup of peer docker container
  2. Took a backup of respective couchdb's data
  3. Stopped the chaincode container associated with this peer, if any
  4. Stopped the couchdb container of the peer
  5. Stopped the peer
  6. Since I was starting the peer using docker-compose file, I updated the peer startup command from 'peer node start' to 'peer node reset'. This will reset the peer's channel data to the genesis block.
  7. Next, again update the peer startup command from 'peer node reset' to 'peer node start'. This time since the peer does not have ledger data, it will pull the blocks from the other peers and rebuild its couchdb data.

(Thank you Mrudav Shukla)

Unfortunately, I don't have the 1.4.3 fabric version. So I scraped this solution.
I restart the peer and it's CouchDB. After the startup, the peer started to get the blocks that were missing and getting synchronized. 

At the end of this, all the peers were in sync.


On another test that we did on the same setup, now it's peer1-org1 that is out os sync.

I checked docker-compose.yml and I have no CORE_PEER_GOSSIP_USELEADERELECTION and CORE_PEER_GOSSIP_ORGLEADER variables defined. So it's acting by default. Was is the default behaviour? (And thank you, David Enyeart, for the explanation).
I can see some gossip in logs, but peer1-org1 is still out of sync.

For example:

2019-11-07 12:29:08.498 UTC [gossip.privdata] reconcile -> DEBU 65a92e Reconciliation cycle finished successfully. no items to reconcile

(at this stage I know that is still out of sync).


One question that came up; If one peer is out of sync, and we have an OR policy for endorsement, where we require one member from Org1 or Org2 to endorse the transaction, why is there no block created and sent to orderer?

Thank you all.


Hyperledger Fabric helps fighting modern slavery.

Marta Piekarska <mpiekarska@...>
 

Dear Community Members,
I recently met a professor from Manchester University who together with her team built a wonderful platform helping to fight modern slavery using Hyperledger Fabric. On Thursday November 28th at 14:30 to 16:30 there will be a meeting with a live demo of their platform. Below you can find a description of the solution. If you would like to join the webex meeting please let us know (Ser-Huang is included in this email).

Modern slavery is a complex crime and there are many organisations, viz. charities, NGOs, law enforcement agencies etc., involved in tackling it. This, when combined with the extreme sensitivity of the data, poses major challenges in the communication between organisations. We believe that a trusted decentralised network, based on the blockchain distributed ledger technology, can greatly facilitate such communication making collaborations more effective in the respective local networks, with the strong potential of producing a separate global network as a natural outcome over time.

A blockchain, as implemented here, is an immutable collection of time ordered records, called the “ledger”, submitted by network participants. Each participant has an identical copy of the “ledger” that is updated in real time, hence the system is free from single-point failure.  The blockchain is managed by consensus, so new participants can join the network based an agreed protocol.  Its legacy does not depend on any specific participant(s) so long as, at all time, there are a minimum of two participants in the network. Indeed, creating a self-sustaining network of information exchange to fight the blight of modern slavery is the drive underlying the proposed project.  Together with minimal barriers to entry, robust self-governing structure, absolute control over confidential data, and minimum demand on network connectivity should allow an initially established network to organically expand its reach.

To this end, we formed a pivotal partnership with the Greater Manchester Police’s specialist anti-slavery unit, Programme Challenger, to produce a realistic deployable prototype, "Enduring Net Communication Organiser ENv.1" which is basically a "WhatsApp lookalike" sitting on a blockchain. The demo will include
- hyperledger fabric installation
- admin: manage organisations and users on the network
- operations: add/manage records/incidents, request for actions, view notifications and history
- all other functionalities (e.g. case management, link/unlink records/incidents, victim/survivor personal details) will be on a "mock up" version only.

This meeting is mainly scheduled for the Greater Manchester Police key personnel. We are in the process of reaching out to Street Support which includes several NGOs working with homeless people in Manchester. There will be Manchester researchers and visitors from outside university. But due to the technical nature of the demo, the meeting will be restricted to 16 on site participants; no restrictions on participants joining via webEx. 

--
----
Marta Geater-Piekarska
Director of Ecosystem, Hyperledger
 
SCHEDULE A MEETING WITH ME:  calendly.com/mpiekarska

marta@...
+447802336641 (U.K) - Signal and Whatsapp
Wickr: martap
Skype: martapiekarska
 
Based in the U.K.


Re: Alternative of cryptogen for Prod

Gari Singh <garis@...>
 

I'd suggest reading the membership section of the documentation:

https://hyperledger-fabric.readthedocs.io/en/release-1.4/membership/membership.html
https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html


-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: Nye Liu <nye@...>
From: "Abhijeet Bhowmik"
Sent by: fabric@...
Date: 11/07/2019 01:13AM
Cc: hakan eryargi <hakan.eryargi@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod

Hello Everyone.

I have followed this thorough discussion on crypto operations in HLF. Very enlightening. I would like to have a deep dig into internal working of CA's and significance of each type of certificates/keys/artifacts present in the folder structure of peer's crypto material. It really confuses me how in an ensemble of N organizations, 1 organization proves his authenticity and control over an entity and how other N-1 orgs verify it's signature on txn. I simply take this as how SSL works. Signing the hash with private key to create digitally signed Entity which is verifiable using Public Key. But now I am really confused as while using crypto-gen, I never bothered about placing public keys of different orgs at every orgs and then configure them to use it. It would be very much appreciated if someone points me towards the right direction to learn how HLF pulls off Blockchain magic at atomic level. I don't intend to bring up a HLF architecture as a black box. I need an insight.

Thanks and Regards
Abhijeet Bhowmik

On Wed, Nov 6, 2019 at 9:53 PM Nye Liu <nye@...> wrote:

If this is truly the case, using two instances of ca-server (one for TLS, one for non-tls) should be trivial, as well as generating self signed root certs to bootstrap the ca server, as well as distributing the public root and intermediates to the various components.
fabric-ca-client enroll can be used for literally everything else (including TLS generation).


On 11/6/2019 8:18 AM, hakan eryargi wrote:


Hi Nye,


Well, being the author of these Helm charts, I believe I have a quite good understanding of what cryptogen generates and where to mount them ;)

https://github.com/APGGroeiFabriek/PIVT


For extending the network, ”cryptogen extend” command does a very good job, only creates what is missing, either new organizations or new peers in the organization.


I still fail to see any real issue for using cryptogen.


It creates self signed certificates, not an issue for us.
It doesnt support intermediate certificates: not a requirement for us.
It puts San Fransisco or sth to some value in the certificates, not nice but not a real issue.


So, still, it’s the most convenient way as of now for us.


I also need to say, it’s easy to say “dont use it in production” without providing a good alternative. As mentioned earlier, I just dont want to create certificates manually, neither want to write some scripts for that.




Best,
Hakan




On Wed, 6 Nov 2019 at 16:39, Nye Liu <nye@...> wrote:

Either way, a network is not static. At some point you are going to have to issue new MSPs, and in order to do that, you have to have an understanding of both the ca-server and the structure and purpose of every part of an MSP.

cryptogen both hides this from you, and does not permit easily adding new credentials and orginizations.
In addition, cryptogen does some other very questionable things when it fires up a bunch of credentials as well (in the name of PoC and unit testing) - in particular, the overlap of TLS and non-transport credentials/CAs which is never recommended.

Do not use it for production networks.



On 11/6/2019 5:47 AM, Hakan Eryargi wrote:


Hi Jean-Gaël and Joe,


This is not my understanding.


1. Fabric doesnt care about if root certificate is self-signed or not. Root certificate of an organization is encoded in the genesis block, Fabric only cares about it.
2. CA doesnt create the root certificate, you need feed it the root certificate so it can create other certificates. Peer, user, admin etc.


So either using CA or not, one needs to create the root certificate. IMHO doesnt really matter if self-signed or not. After that, it's a matter of choice use CA or cryptogen to create other certificates.


Please correct me if i am wrong about above.


Otherwise I dont see a real issue about using cryptogen in production.


In our flow, we create all the initial certificates with cryptogen, launch the network including CA's, then use CA to register users. Our intention is using the same flow in production too unless someone provides a more convenient tool to create the initial certificates.


Best,
Hakan


On Wed, Nov 6, 2019 at 2:36 PM Joe Alewine <joe.alewine@...> wrote:


Hakan,

Generating certificates using a Certificate Authority (and not cryptogen) is a fact of life for Hyperledger Fabric users who are interested in deploying something in production. Cryptogen is a handy tool for application developers who only want to deploy a network they can test smart contracts and apps against and explicitly not meant (or supported) for production networks. It's analogous to printing your own identification card at home and expecting that government agencies and businesses will accept it as being valid.

The sooner you get used to creating certificates and MSPs using a CA, the better off you will be.

Regards,






Joe Alewine
IBM Blockchain, Raleigh

rocket chat: joe-alewine
slack: joe.alewine


----- Original message -----
From: hakan eryargi <hakan.eryargi@...>
To: Abhijeet Bhowmik <abhijeet@...>
Cc: Joe Alewine <joe.alewine@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod
Date: Wed, Nov 6, 2019 7:29 AM

Hi,

To my knowledge, cryptogen is the most convenient tool for now to create the initial certificates.

I dont want to create the certificates manually, nor want to write some scripts for certificate creation. Maybe cryptogen is not intended for this purpose but best option for now, especially if you dont need additional stuff in certificates.
So, if there is no real issue with it, like a security threat or whatever, we plan to go production with cryptogen .
It will also be nice if cryptogen is even more developed to cover other needs too :)

Best,

Hakan

On Tue, Nov 5, 2019 at 4:40 AM Abhijeet Bhowmik <abhijeet@...> wrote:
Hey,

Thanks to all for the help. I am extremely grateful to everyone.

Abhijeet Bhowmik

On Mon, Nov 4, 2019 at 9:51 PM Joe Alewine <joe.alewine@...> wrote:

Abhijeet,

Certificate Authorities --- specifically, the Fabric CA --- should be used to create all of the certificates in a production scenario (it is a best practice tp stand up one CA for each organization and the organization's related identities, MSP, and nodes).

Consult the Fabric CA User's Guide for more information: https://hyperledger-fabric-ca.readthedocs.io/en/latest/

Regards,






Joe Alewine
IBM Blockchain, Raleigh

rocket chat: joe-alewine
slack: joe.alewine


----- Original message -----
From: "Nye Liu" <nye@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod
Date: Sun, Nov 3, 2019 7:43 AM
It is described in the Operations Guide.

On 11/3/2019 1:11 AM, Abhijeet Bhowmik wrote:
Hey,

Just to be specific, I was referring to the certificates that we set up at peers and place public keys at orderer. From where do we obtain that folder structure (MSP and TLS)?

Thanks and Regards
Abhijeet Bhowmik

On Sun, Nov 3, 2019 at 10:44 AM Mrudav Shukla <mrudavshukla@...> wrote:

Hi Abhijeet,

For prod, you’ll need to generate certs from CAs. References:


https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/operations_guide.html
Cheers,
Mrudav


On Sun, 3 Nov 2019 at 10:22 AM, Abhijeet Bhowmik <abhijeet@...> wrote:
Greetings Everyone,

I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.


Thanks and Regards
Abhijeet Bhowmik


Re: Alternative of cryptogen for Prod

Vishal
 


Nothing beats cryptogen when it comes to convenience of creating crypto materials. If the auto generated self signed CA authority is preventing you from using cryptogen, then I would recommend a hack.
With a small modification to its source code, cryptogen would start making use of user-supplied CA certificates for generating crypto-material instead of using auto generated CA certificates.

Replace occurrences of :
```
// generate signing CA
signCA, err := ca.NewCA(caDir, orgName, orgSpec.CA.CommonN....)

```
with
```
signCA := getCA(caDir, orgSpec, orgSpec.CA.CommonName)
```

After above change, cryptogen signs the crypto-material with user supplied CA instead of creating its own.
Do remember to save your CA certificates in caDir i.e. crypto-config --> peerOrganizations -->org1 -->ca before running this tool. 
Other MSP folders would be populated after crytogen generate run.
Also, main.go has very good documentation under comments on various csr attributes.

Best,
Vishal  



On Thu, Nov 7, 2019 at 12:26 PM Yueming Xu via Lists.Hyperledger.Org <yxu=tibco.com@...> wrote:
This is exactly what I am doing, using 2 CA servers, one for CA, another for TLS, in this utility project: https://github.com/yxuco/fabric-operation

The project shows you how to generate crypto using ca-servers, and how to deploy fabric networks in Kubernetes locally or in cloud, AWS or Azure. You can get a fabric network running and tested in EKS or AKS with only a handful script calls!

I chose to use simple bash scripts in this project, so it does not have any unnecessary dependencies. comments are welcome. 

Yueming Xu


Re: Alternative of cryptogen for Prod

Yueming Xu
 

This is exactly what I am doing, using 2 CA servers, one for CA, another for TLS, in this utility project: https://github.com/yxuco/fabric-operation

The project shows you how to generate crypto using ca-servers, and how to deploy fabric networks in Kubernetes locally or in cloud, AWS or Azure. You can get a fabric network running and tested in EKS or AKS with only a handful script calls!

I chose to use simple bash scripts in this project, so it does not have any unnecessary dependencies. comments are welcome. 

Yueming Xu


Re: Alternative of cryptogen for Prod

Abhijeet Bhowmik <abhijeet@...>
 

Hello Everyone.

I have followed this thorough discussion on crypto operations in HLF. Very enlightening. I would like to have a deep dig into internal working of CA's and significance of each type of certificates/keys/artifacts present in the folder structure of peer's crypto material. It really confuses me how in an ensemble of N organizations, 1 organization proves his authenticity and control over an entity and how other N-1 orgs verify it's signature on txn. I simply take this as how SSL works. Signing the hash with private key to create digitally signed Entity which is verifiable using Public Key. But now I am really confused as while using crypto-gen, I never bothered about placing public keys of different orgs at every orgs and then configure them to use it. It would be very much appreciated if someone points me towards the right direction to learn how HLF pulls off Blockchain magic at atomic level. I don't intend to bring up a HLF architecture as a black box. I need an insight.

Thanks and Regards
Abhijeet Bhowmik

On Wed, Nov 6, 2019 at 9:53 PM Nye Liu <nye@...> wrote:

If this is truly the case, using two instances of ca-server (one for TLS, one for non-tls) should be trivial, as well as generating self signed root certs to bootstrap the ca server, as well as distributing the public root and intermediates to the various components.

fabric-ca-client enroll can be used for literally everything else (including TLS generation).

On 11/6/2019 8:18 AM, hakan eryargi wrote:
Hi Nye,

Well, being the author of these Helm charts, I believe I have a quite good understanding of what cryptogen generates and where to mount them ;)

For extending the network, ”cryptogen extend” command does a very good job, only creates what is missing, either new organizations or new peers in the organization.

I still fail to see any real issue for using cryptogen.

It creates self signed certificates, not an issue for us.
It doesnt support intermediate certificates: not a requirement for us.
It puts San Fransisco or sth to some value in the certificates, not nice but not a real issue.

So, still, it’s the most convenient way as of now for us.

I also need to say, it’s easy to say “dont use it in production” without providing a good alternative. As mentioned earlier, I just dont want to create certificates manually, neither want to write some scripts for that.


Best,
Hakan


On Wed, 6 Nov 2019 at 16:39, Nye Liu <nye@...> wrote:

Either way, a network is not static. At some point you are going to have to issue new MSPs, and in order to do that, you have to have an understanding of both the ca-server and the structure and purpose of every part of an MSP.

cryptogen both hides this from you, and does not permit easily adding new credentials and orginizations.

In addition, cryptogen does some other very questionable things when it fires up a bunch of credentials as well (in the name of PoC and unit testing) - in particular, the overlap of TLS and non-transport credentials/CAs which is never recommended.

Do not use it for production networks.

On 11/6/2019 5:47 AM, Hakan Eryargi wrote:
Hi Jean-Gaël and Joe,

This is not my understanding.

1. Fabric doesnt care about if root certificate is self-signed or not. Root certificate of an organization is encoded in the genesis block, Fabric only cares about it.
2. CA doesnt create the root certificate, you need feed it the root certificate so it can create other certificates. Peer, user, admin etc.

So either using CA or not, one needs to create the root certificate. IMHO doesnt really matter if self-signed or not. After that, it's a matter of choice use CA or  cryptogen to create other certificates.

Please correct me if i am wrong about above. 

Otherwise I dont see a real issue about using cryptogen in production.

In our flow, we create all the initial certificates with cryptogen, launch the network including CA's, then use CA to register users. Our intention is using the same flow in production too unless someone provides a more convenient tool to create the initial certificates.

Best,
Hakan

On Wed, Nov 6, 2019 at 2:36 PM Joe Alewine <joe.alewine@...> wrote:
Hakan,
 
Generating certificates using a Certificate Authority (and not cryptogen) is a fact of life for Hyperledger Fabric users who are interested in deploying something in production. Cryptogen is a handy tool for application developers who only want to deploy a network they can test smart contracts and apps against and explicitly not meant (or supported) for production networks. It's analogous to printing your own identification card at home and expecting that government agencies and businesses will accept it as being valid.
 
The sooner you get used to creating certificates and MSPs using a CA, the better off you will be.
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: hakan eryargi <hakan.eryargi@...>
To: Abhijeet Bhowmik <abhijeet@...>
Cc: Joe Alewine <joe.alewine@...>, fabric@...
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod
Date: Wed, Nov 6, 2019 7:29 AM
 
Hi,
 
To my knowledge, cryptogen is the most convenient tool for now to create the initial certificates.  

I dont want to create the certificates manually, nor want to write some scripts for certificate creation. Maybe cryptogen is not intended for this purpose but best option for now, especially if you dont need additional stuff in certificates.  

So, if there is no real issue with it, like a security threat or whatever, we plan to go production with cryptogen . 

It will also be nice if cryptogen is even more developed to cover other needs too :) 

Best,

Hakan
 
On Tue, Nov 5, 2019 at 4:40 AM Abhijeet Bhowmik <abhijeet@...> wrote:
Hey,
 
Thanks to all for the help. I am extremely grateful to everyone.
 
Abhijeet Bhowmik
 
On Mon, Nov 4, 2019 at 9:51 PM Joe Alewine <joe.alewine@...> wrote:
Abhijeet,
 
Certificate Authorities --- specifically, the Fabric CA --- should be used to create all of the certificates in a production scenario (it is a best practice tp stand up one CA for each organization and the organization's related identities, MSP, and nodes).
 
Consult the Fabric CA User's Guide for more information: https://hyperledger-fabric-ca.readthedocs.io/en/latest/
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: "Nye Liu" <nye@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod
Date: Sun, Nov 3, 2019 7:43 AM
 

It is described in the Operations Guide.

On 11/3/2019 1:11 AM, Abhijeet Bhowmik wrote:
Hey,
 
Just to be specific, I was referring to the certificates that we set up at peers and place public keys at orderer. From where do we obtain that folder structure (MSP and TLS)?
 
Thanks and Regards
Abhijeet Bhowmik
 
On Sun, Nov 3, 2019 at 10:44 AM Mrudav Shukla <mrudavshukla@...> wrote:
Hi Abhijeet,
 
For prod, you’ll need to generate certs from CAs. References:
Cheers,
Mrudav 
 
On Sun, 3 Nov 2019 at 10:22 AM, Abhijeet Bhowmik <abhijeet@...> wrote:
Greetings Everyone,
 
I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.
 
 
Thanks and Regards
Abhijeet Bhowmik
 
 

 

 

 

 

 


Which cert should be copied for TLS( ca-cert.pem or tls-cert.pem) #fabric-ca

Jeehoon Lim
 

Hi all.

I' m studying the use of fabric CA.

If Fabric CA Server without 'TLS Enabled' option, it generates ca-cert.pem file.
If Fabric CA Server with 'TLS Enabled' option, it generates both ca-cert.pem and tls-cert.pem files.

I thought the tls-cert.pem file should be copied to the fabric clients for use TLS communication with CA Server .

But in the 'Setup TLS Server' section of  operation guide , it says like below :

   you would need to acquire the file located at /tmp/hyperledger/tls/ca/crypto/ca-cert.pem on the machine running the TLS CA server and copy this file over to the host where you will be running the CA client binary.

 
Which cert should be copied for TLS -  ca-cert.pem or tls-cert.pem ?


Regards,
Jeehoon Lim


Re: Peers with different heights #fabric #database #consensus

David Enyeart
 

Meant to say "Restart the two peers in org1"...


Dave Enyeart

"David Enyeart" ---11/06/2019 08:07:14 PM---Often times issues like this are related to gossip misconfiguration. Restart the two peers in org2 a

From: "David Enyeart" <enyeart@...>
To: "Joao Antunes" <joao.antunes@...>
Cc: fabric@...
Date: 11/06/2019 08:07 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Peers with different heights #fabric #database #consensus
Sent by: fabric@...





Often times issues like this are related to gossip misconfiguration.

Restart the two peers in org2 and then look at the peer logs. You should see some messages like this if everything is working well:

2019-11-06 19:30:35.997 EST [gossip.state] NewGossipStateProvider -> INFO 022 Updating metadata information, current ledger sequence is at = 7, next expected block is = 8
2019-11-06 19:30:38.002 EST [gossip.service] func1 -> INFO 032 Elected as a leader, starting delivery service for channel mychannel
2019-11-06 19:30:38.003 EST [deliveryClient] StartDeliverForChannel -> DEBU 033 This peer will pass blocks from orderer service to other peers for mychannel
2019-11-06 19:30:38.006 EST [deliveryClient] RequestBlocks -> DEBU 037 Starting deliver with block [8] for channel mychannel
2019-11-06 19:30:59.423 EST [gossip.channel] reportMembershipChanges -> INFO 047 Membership view has changed. peers went online: [[ 10.79.1.107:7053]] , current view: [[ 10.79.1.107:7053]]

In the above example, the peer is acting as the org leader and is disseminating blocks to other peers in the org. If the other peer is not in the 'membership view' (e.g. due to gossip misconfiguration or a network partition) then it won't be able to disseminate the blocks. You may see an error in peer logs explaining the reason.

If you are unsure about the gossip configuration, you could also force all peers to retrieve blocks from orderer by using the following config:
CORE_PEER_GOSSIP_USELEADERELECTION = false
CORE_PEER_GOSSIP_ORGLEADER = true

Note, two of the messages above were debug messages, so you'd have to set the logging as follows to see them:
FABRIC_LOGGING_SPEC=info:deliveryClient=debug


These messages should probably be promoted to Info messages so that it is more clear how peers are receiving blocks. I've pushed a change to do just that: https://gerrit.hyperledger.org/r/#/c/fabric/+/34275/.



Dave Enyeart

"Joao Antunes" ---11/06/2019 09:25:40 AM---Hi to all, Currently, in my setup, I have 2 organizations with 2 peers each. Also have 2 Orderers, o

From:
"Joao Antunes" <joao.antunes@...>
To:
fabric@...
Date:
11/06/2019 09:25 AM
Subject:
[EXTERNAL] [Hyperledger Fabric] Peers with different heights #fabric #database #consensus
Sent by:
fabric@...




Hi to all,

Currently, in my setup, I have 2 organizations with 2 peers each. Also have 2 Orderers, one per each organization, and a CA per Organization too.
They have a Kafkas and Zookeepers consensus mechanism.
Running the `peer channel getinfo -c mychannel` command on all peers I receive the following:


Peer 1 org 1 -

Blockchain info: {"height":4120,"currentBlockHash":"rmA39fxfCBU5AcGEOq6gErwtBILcucnhcAbnPQ7y2m0=","previousBlockHash":"toGGvdXZZwiCg2ncC7jcWkbUvfmuohEtT45YSUutZLA="}

Peer 2 org 1 -

Blockchain info: {"height":2875,"currentBlockHash":"mz7qXXPLXNNMY5WMbOiuQdMebURa9NZL9FQsOu6Io3w=","previousBlockHash":"kfM/90uFTho48EXzphOX2ZFhIjgFKNzTjKK/z53hrhc="}

Peer 1 org 2 -

Blockchain info: {"height":4120,"currentBlockHash":"rmA39fxfCBU5AcGEOq6gErwtBILcucnhcAbnPQ7y2m0=","previousBlockHash":"toGGvdXZZwiCg2ncC7jcWkbUvfmuohEtT45YSUutZLA="}

Peer 2 org 2 -

Blockchain info: {"height":4120,"currentBlockHash":"rmA39fxfCBU5AcGEOq6gErwtBILcucnhcAbnPQ7y2m0=","previousBlockHash":"toGGvdXZZwiCg2ncC7jcWkbUvfmuohEtT45YSUutZLA="}



Peer 2 org 1 has a different height. Is there something that we can configure for it to be updated automatically? Is Kafka badly set up? Is something on the peer configs?

Currently running the network on 1.4 version.






4401 - 4420 of 11525