Copy files with timestamp

rsync -t source_file_or_directory destination_file_or_directory

Change LiteIDE file type tab spacing

LiteIDE is a nice IDE for developing golang program, but there is one thing which made me cringing. The tab is most default to 4 spaces, but in some situation, you do not want it to be 4 spaces, but 2. To change that, you will need to find this file liteeditor.xml from this directory /Applications/LiteIDE.app/Contents/Resources/liteapp/mimetype, then make changes to that file to add your new type for example jinja2 template file. You can simply add the extention like *.j2 to one of the existing entries just like this one:

<glob pattern="*.j2"/>

Then you can open up LiteIDE and change the tab space to 2 or whatever number you desire.

Only get git repository file without any git metadata

1. Do a git pull to get latest from the repo
2. Run the following command to get the latest code into /var/tmp/junk directory

git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)

How to use pep8 to check trailing white spaces in files

Install pep8

sudo pip install pep8

Then run the following command

pep8 --select=W291,W293 --filename=*.yml *

The above command will check trailing white spaces and lines with only white spaces in the files ending with .yml in the current and sub directories.

How to start up openldap container and test it.

Start up the openldap containe

docker run --name ldap --hostname ldap.fabric-ca 
  -e LDAP_ORGANISATION="Fabric CA"
  -e LDAP_DOMAIN="fabric-ca"
  -e LDAP_ADMIN_PASSWORD="ps" -d osixia/openldap:1.1.9

The above procedure will enable tls and create server certificate and private, they can be found inside the container at this location:

/container/service/slapd/assets/certs

In the above directory, you can see ldap.crt and ldap.key file. Regardless what hostname or cn you might choose, the container seems will always use the name ldap.crt and ldap.key as the certificate name and key. There will be also ca.crt, but that certificate actually links to following directory which comes with the container.

/container/service/:ssl-tools/assets/default-ca 

Test the container

docker exec ldap ldapsearch -x -H ldap://localhost
  -b dc=fabric-ca -D "cn=admin,dc=fabric-ca" -w ps

How to check if zookeeper and kafka are running correctly

Check on zookeeper:

telnet ipaddress port
stats

For example:

telnet 172.16.21.3 2181
Trying 172.16.21.3...
Connected to 172.16.21.3.
Escape character is '^]'.
stats
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.16.21.4:58476[1](queued=0,recved=321,sent=327)
 /172.16.38.0:55630[1](queued=0,recved=245,sent=245)
 /172.16.39.0:38124[1](queued=0,recved=240,sent=240)
 /172.16.21.1:39190[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/14
Received: 807
Sent: 812
Connections: 4
Outstanding: 0
Zxid: 0x100000033
Mode: leader
Node count: 31
Connection closed by foreign host.

To check if the kafka nodes actually all registered, do the following:

1. docker exec -it zookeeper1st bash
2. cd /zookeeper-3.4.9/bin/zkCli.sh  ls /brokers/ids

WatchedEvent state:SyncConnected type:None path:null
[1, 2, 3]

or

1. docker exec -it kafka3rd bash
2. ./kafka-topics.sh --list --zookeeper zookeeper1st:2181
3. ./kafka-topics.sh --describe --zookeeper zookeeper1st:2181

Some thing about orderer joining the party

tongli 11:28 PM
@jimthematrix so there is no way at all to add a user or an orderer or a peer?

jimthematrix 11:31 PM  
@tongli not with the cryptogen tool right now. but you can use the resulting ca certs and key to initialize a fabric-ca server to issue additional certs for user/orderer/peer identities, or use a tool like openssl to do the same
@CarlXK 对的，想支持扩展就需要这么做

tongli 11:35 PM
@jimthematrix right, I guess the missing pieces are after ca got your what needed, how do you make a new peer joining in an existing channel? can we do that? and how do you make an orderer join?

jimthematrix 11:52 PM
adding a new peer of an existing org to a channel is pretty straightforward: you get the latest channel config from the orderer and send that to the peer. this doesn't require modifying the channel. If you want to add a whole new org to the channel, then you first have to follow a process to update the channel config with the orderer, then send the updated channel config to the new peers of the new org
i actually don't know what is involved in adding new orderers to an existing network. it's a some combination of starting the new orderer node with the genesis block, and updating the consortium definition in the system channel. for details you'd have to ask @jyellick

jyellick 11:59 PM
> you get the latest channel config from the orderer and send that to the peer.
This actually isn't true. The peer only supports joining through the genesis block.

jyellick 12:01 AM
> i actually don't know what is involved in adding new orderers to an existing network.
Generally, simply start the orderer with the same genesis block that the other orderers were started with. The orderer will catch up from the Kafka broker logs. Then, once the orderer is up to date, second a reconfiguration transaction on any channels you wish to use the new orderer updating the set of orderer addresses.

chenxuan 5:07 AM
@baohua peer 节点的/etc/hyperledger/fabric是怎么制定的

baohua 8:23 AM
哦 可以通过配置指定：$FABRIC_CFG_PATH

chenxuan 8:41 AM
当我执行make docker的时候 我看到里面的里面指定了
FABRIC_CFG_PATH 是不是这个环境变量打包到了镜像当中去
？

baohua 9:35 AM
if in dockerfile, then it is.

tongli 1:21 PM
@jyellick thanks for your explanation on how the orderer joining the party. That actually makes a lot of sense to me.
👍 1 
@jyellick jason, what if the orderer comes from different org which was never part of the genesis block when it was created?
When genesis block gets created, it uses Orderer profile , I assumed that takes in the organizations which orderers belong to.
when a new orderer from a new org wants to jump in, the genesis block would not have any idea about the new org, right?

jyellick 1:39 PM
For now, you would still bootstrap the new orderer with the old genesis block. And the new orderer would play the chain forward until it got to the current state.
This approach has many drawbacks, and it is a planned feature in the future to allow the orderer to be bootstrapped from a later config block (and to generally allow data pruning)
But for v1, the only option is to start with the true genesis block.
As an alternative, you may copy the ledger from an already current orderer, and use that as the seed for a new orderer, this might be preferable in some devops scenarios.

tongli 1:59 PM
@jyellick thanks, but I do not think I am clear on how the authentication is done for the new orderer, I mean how does everybody in the party already know this new guy and consider the new orderer legit? I mean how is the authentication done? or it does not really matter?

jyellick 2:02 PM
The Kafka orderers do not speak directly to eachother. They only interact via Kafka. So, if Kafka authorizes the new orderer (generally because of TLS), then this new orderer will be able to participate in ordering. Peers also authenticate via TLS, but additionally, when receiving a block, they verify that it has been signed by one of the ordering orgs per the BlockValidation policy. By default, this policy allows anyone from the ordering orgs to sign the blocks. Adding a new orderer org would extend this policy to allow this new org to sign blocks.

tongli 2:04 PM
Excellent. Thanks so much!