Explanation on configtx.yaml details
Hi guys!
I am trying to make a right relation between theory and the approach Hyperledger Fabric took for configurations, etc.
In the official sample for configtx.yaml, we can see this structure on the section "Organizations":
Organizations:
- &SampleOrg
Name: SampleOrg
ID: SampleOrg
MSPDir: msp
We have also this explanation for the "MSPDir":
"MSPDir is the filesystem path which contains the MSP configuration."
For whom is this configuration (MSP path)? The admin of the company?
In the example of the course the MSPDir points to an MSP having the root CA and the admin.
Let me explain my question. When we create identities on a certain CA we are identifying nodes, users or whoever (machines or people) will have access to the network. Therefore, the identity should be related to some player of the network. Company is a more broad and abstract concept. So, who will use the identity to personify the organization? The admin identity is the representation of a company?
Thanks!
Comments
-
Hi hanesoliveira,
Interesting question, I will try to answer it according to my understanding.
First, I would like to emphasize that this is indeed the MSP config of the channel: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#channel-msp-setup
It's sure that the admin is a special identity in the organization, and so in the Fabric channel network configuration. Fabric must know the identity of the admin to allow him to perform admin operations.
But the admin will not be obviously the only identity to operate on the network, the peers nodes and the users must be authorized too, for others operations. And Instead of putting the identities of all others users in the channel MSP, we put just the CA of their identities.
And Fabric even allows to classify identities as “peers” or “clients”: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification.
It would be more interesting to look at the content of a channel config in JSON format. Below, I extracted just the MSP section for the Org1 in an example of channel config. In this JSON, we can see:
- the admin certificate
- the “fabric_node_ous” certificates, that classify identities as “peers” or “clients”.
- the root certificate
- the TLS root certificate.
"value": { "config": { "admins": [ "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNRRENDQWVlZ0F3SUJBZ0lSQU15SDdjYWJVT003RlBPSFBGbTArZEV3Q2dZSUtvWkl6ajBFQXdJd2dZRXgKQ3pBSkJnTlZCQVlUQWxWVE1STXdFUVlEVlFRSUV3cERZV3hwWm05eWJtbGhNUll3RkFZRFZRUUhFdzFUWVc0ZwpSbkpoYm1OcGMyTnZNU0F3SGdZRFZRUUtFeGR2Y21jeExtRmliM1ZpWVd0aGNtdHZhWFJoTG1OdmJURWpNQ0VHCkExVUVBeE1hWTJFdWIzSm5NUzVoWW05MVltRnJZWEpyYjJsMFlTNWpiMjB3SGhjTk1UZ3hNakUyTVRNME9UQXcKV2hjTk1qZ3hNakV6TVRNME9UQXdXakJ6TVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVQTUEwR0ExVUVDeE1HWTJ4cFpXNTBNU1l3CkpBWURWUVFEREIxQlpHMXBia0J2Y21jeExtRmliM1ZpWVd0aGNtdHZhWFJoTG1OdmJUQlpNQk1HQnlxR1NNNDkKQWdFR0NDcUdTTTQ5QXdFSEEwSUFCR3l6bzAvRXY4ZTd2N3RjVEFXOWEzaWdLM3pjb00xMzBlcXNVMW8xT05KKworNUY1ZURDRkt6Um5xdjVVM0RWbE9ZbWpWOXlNeTE3Z0NENjE3a0NsUFIralRUQkxNQTRHQTFVZER3RUIvd1FFCkF3SUhnREFNQmdOVkhSTUJBZjhFQWpBQU1Dc0dBMVVkSXdRa01DS0FJRDVqRXpVQ1lTTEJUcEFSSEt6QkxpaTMKcng2QXEzMnZyT0JydEdqSnJyNC9NQW9HQ0NxR1NNNDlCQU1DQTBjQU1FUUNJRGI0ZnBydWNidzUzUmxaRU9JcQpjdm15emJSaTdsT2NrYmpZMEU4SWhMaU1BaUJmZjNnL043dnFQZHo1cU5EYm9CWVAzZ1dnQXpPOGhHeXBIblkzClpDclFldz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" ], "crypto_config": { "identity_identifier_hash_function": "SHA256", "signature_hash_family": "SHA2" }, "fabric_node_ous": { "client_ou_identifier": { "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNZRENDQWdlZ0F3SUJBZ0lRTGt4aEZUTXFuc1pvWm84a21GUkdCREFLQmdncWhrak9QUVFEQWpDQmdURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TTXdJUVlEClZRUURFeHBqWVM1dmNtY3hMbUZpYjNWaVlXdGhjbXR2YVhSaExtTnZiVEFlRncweE9ERXlNVFl4TXpRNU1EQmEKRncweU9ERXlNVE14TXpRNU1EQmFNSUdCTVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVnTUI0R0ExVUVDaE1YYjNKbk1TNWhZbTkxClltRnJZWEpyYjJsMFlTNWpiMjB4SXpBaEJnTlZCQU1UR21OaExtOXlaekV1WVdKdmRXSmhhMkZ5YTI5cGRHRXUKWTI5dE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXJoTTRSOEJ5bXVvZXZlRXdHOW9HWU1KZwpkRjYyTDdUYTREL2JmZ01YYTVYOWRjMWRweVQzdkhrQkczblhJQ2tWU3FCL3F1eGFRNnQ1MFhjSGNUY2g3cU5mCk1GMHdEZ1lEVlIwUEFRSC9CQVFEQWdHbU1BOEdBMVVkSlFRSU1BWUdCRlVkSlFBd0R3WURWUjBUQVFIL0JBVXcKQXdFQi96QXBCZ05WSFE0RUlnUWdQbU1UTlFKaElzRk9rQkVjck1FdUtMZXZIb0NyZmErczRHdTBhTW11dmo4dwpDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOY1VWSHhHZWUva2RMRzM2N045dHI1d0pBd1VOZDJuREFLOEw1cFNMCm05Y0NJRjdaVzJ3YXZTNndPb2JMVHZvZmc1Q2o4M0hSSVI3S3ZFK0JqZ2JyU3UwWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==", "organizational_unit_identifier": "client" }, "enable": true, "peer_ou_identifier": { "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNZRENDQWdlZ0F3SUJBZ0lRTGt4aEZUTXFuc1pvWm84a21GUkdCREFLQmdncWhrak9QUVFEQWpDQmdURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TTXdJUVlEClZRUURFeHBqWVM1dmNtY3hMbUZpYjNWaVlXdGhjbXR2YVhSaExtTnZiVEFlRncweE9ERXlNVFl4TXpRNU1EQmEKRncweU9ERXlNVE14TXpRNU1EQmFNSUdCTVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVnTUI0R0ExVUVDaE1YYjNKbk1TNWhZbTkxClltRnJZWEpyYjJsMFlTNWpiMjB4SXpBaEJnTlZCQU1UR21OaExtOXlaekV1WVdKdmRXSmhhMkZ5YTI5cGRHRXUKWTI5dE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXJoTTRSOEJ5bXVvZXZlRXdHOW9HWU1KZwpkRjYyTDdUYTREL2JmZ01YYTVYOWRjMWRweVQzdkhrQkczblhJQ2tWU3FCL3F1eGFRNnQ1MFhjSGNUY2g3cU5mCk1GMHdEZ1lEVlIwUEFRSC9CQVFEQWdHbU1BOEdBMVVkSlFRSU1BWUdCRlVkSlFBd0R3WURWUjBUQVFIL0JBVXcKQXdFQi96QXBCZ05WSFE0RUlnUWdQbU1UTlFKaElzRk9rQkVjck1FdUtMZXZIb0NyZmErczRHdTBhTW11dmo4dwpDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOY1VWSHhHZWUva2RMRzM2N045dHI1d0pBd1VOZDJuREFLOEw1cFNMCm05Y0NJRjdaVzJ3YXZTNndPb2JMVHZvZmc1Q2o4M0hSSVI3S3ZFK0JqZ2JyU3UwWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==", "organizational_unit_identifier": "peer" } }, "intermediate_certs": [], "name": "Org1MSP", "organizational_unit_identifiers": [], "revocation_list": [], "root_certs": [ "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNZRENDQWdlZ0F3SUJBZ0lRTGt4aEZUTXFuc1pvWm84a21GUkdCREFLQmdncWhrak9QUVFEQWpDQmdURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TTXdJUVlEClZRUURFeHBqWVM1dmNtY3hMbUZpYjNWaVlXdGhjbXR2YVhSaExtTnZiVEFlRncweE9ERXlNVFl4TXpRNU1EQmEKRncweU9ERXlNVE14TXpRNU1EQmFNSUdCTVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVnTUI0R0ExVUVDaE1YYjNKbk1TNWhZbTkxClltRnJZWEpyYjJsMFlTNWpiMjB4SXpBaEJnTlZCQU1UR21OaExtOXlaekV1WVdKdmRXSmhhMkZ5YTI5cGRHRXUKWTI5dE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXJoTTRSOEJ5bXVvZXZlRXdHOW9HWU1KZwpkRjYyTDdUYTREL2JmZ01YYTVYOWRjMWRweVQzdkhrQkczblhJQ2tWU3FCL3F1eGFRNnQ1MFhjSGNUY2g3cU5mCk1GMHdEZ1lEVlIwUEFRSC9CQVFEQWdHbU1BOEdBMVVkSlFRSU1BWUdCRlVkSlFBd0R3WURWUjBUQVFIL0JBVXcKQXdFQi96QXBCZ05WSFE0RUlnUWdQbU1UTlFKaElzRk9rQkVjck1FdUtMZXZIb0NyZmErczRHdTBhTW11dmo4dwpDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOY1VWSHhHZWUva2RMRzM2N045dHI1d0pBd1VOZDJuREFLOEw1cFNMCm05Y0NJRjdaVzJ3YXZTNndPb2JMVHZvZmc1Q2o4M0hSSVI3S3ZFK0JqZ2JyU3UwWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==" ], "signing_identity": null, "tls_intermediate_certs": [], "tls_root_certs": [ "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNaekNDQWcyZ0F3SUJBZ0lRSGkyWngzbTNMRk1uR3lqUmorV0MrREFLQmdncWhrak9QUVFEQWpDQmhERUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TWXdKQVlEClZRUURFeDEwYkhOallTNXZjbWN4TG1GaWIzVmlZV3RoY210dmFYUmhMbU52YlRBZUZ3MHhPREV5TVRZeE16UTUKTURCYUZ3MHlPREV5TVRNeE16UTVNREJhTUlHRU1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGcwphV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeVlXNWphWE5qYnpFZ01CNEdBMVVFQ2hNWGIzSm5NUzVoClltOTFZbUZyWVhKcmIybDBZUzVqYjIweEpqQWtCZ05WQkFNVEhYUnNjMk5oTG05eVp6RXVZV0p2ZFdKaGEyRnkKYTI5cGRHRXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFb3I0UjQ0YWM0MUl0R055dgpYU0xhTVJCUFFiMms3UmNTc0RCL000UEdOTGRwWE1acVVNNTkybTlieW04RmRmTkZiQkNSamhCQTFFRlVHU3k5CkFlT0ltcU5mTUYwd0RnWURWUjBQQVFIL0JBUURBZ0dtTUE4R0ExVWRKUVFJTUFZR0JGVWRKUUF3RHdZRFZSMFQKQVFIL0JBVXdBd0VCL3pBcEJnTlZIUTRFSWdRZzZ6cXEzMFJGTG1SMHd0cmZGMkJjNENPemh5Q1NVcjJ2dUtFVAozSU1UN3I0d0NnWUlLb1pJemowRUF3SURTQUF3UlFJaEFNL2JRaGxjSTZmTWhEWlloTGE3aE9nYjJGaGx5RzBRCnU3blpkWkJ2bmEyTUFpQmJnTmpha0QzUDF3Z2RIK1ZudWxsMUxBdWJnS2JoTDNhOXh6RU12d1pzbHc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==" ] }, "type": 0 },
0 -
To @hanesoliveira,
Comments are inline.
Q.) For whom is this configuration (MSP path)? The admin of the company?_**
A.) MSP is at Organization level, not for a specific peer.
Q.) Let me explain my question. When we create identities on a certain CA we are identifying nodes, users or whoever (machines or people) will have access to the network. Therefore, the identity should be related to some player of the network. Company is a more broad and abstract concept. So, who will use the identity to personify the organization? The admin identity is the representation of a company?
A.) I'm still not sure if Im necessarily following your question, but let me explain...Certificate Authorities create, issue, and manage certificates for personal identification of a peer or orderer. The MSP is (once again) an organization level identifier responsible for identifying which certificates are able to do what, be apart of the organization, etc. For example, one role of MSP's can be that it is responsible for identifying which cert is an admin of the organization. But the actual certificate inside of that specific area of the msp dir represents the actual peer.
I would also suggest you check out the key concepts section of the Fabric Docs to learn more about MSP, as it can also help your understanding.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/key_concepts.html0 -
Thanks for the feedback @akoita I'll take a careful look!
To @kmyatt:
Thanks for going on every key point. But I'll try to simplify my question and by the way I think this is a very valuable discussion. I've read the whole material of Fabric already before this course and I got back there many times to check the idea of the MSP, CA, etc. What I understood is this:
We have channel and local MSPs.
Every node/machine in the network will have its own MSP structure (local MSP), where along with other directories and files, will have its CA certificate (msp/cacerts), certificates for admins (msp/admincerts) that will access that node and certificates for signing transactions (msp/signcerts) that represent the node's identity on the CA.
With that in mind and to better understand how to define companies and the genesis block, I created another project.
1) I created from scratch an image of the CA, defining directories, binary files, etc. I redefined the self-signed certificate putting another structure for the organizations (not the default org1 and org2), so that I could make the right affiliations later on.
affiliations:
company-a:
- dept
company-b:
- dept
company-c:
- dept2) I started to create one by one of the cryptographic material for peers, administrators and orderer, making the right affiliation under those companies defined inside the CA. In this structure company-a is the orderer company and will have an orderer and an administrator.
Directories with crypto material in my computer:
/fabric-ca-client
/company-a
/admin
/orderer
/company-b
/admin
/peer
/company-c
/admin
/peer3) I created from scratch an image of the orderer, redefining everything as well.
4) Lastly I populated the configtx.yaml with values that were related to the MSP companies. Inside configtx.yaml we need to define organizations in order to reference them in other parts of the same config file:
Organizations:
- &company-a
Name: company-a
ID: company-a
MSPDir: /Users/hanesoliveira/Workspace/hyperledger/fabric-ca-client/company-a/admin/mspSo I pointed MSPDir to a MSP in my filesystem containing just the /admincerts and /cacerts directories with the related certificates. I could only create the genesis block when I pointed to a MSP that had the related admin certificate in /admincerts. The admin is registered under certain company by the CA. Therefore I think that the system is checking that affiliation to define the org.
So, I was curious to understand: what the system is taking into consideration (certificate, MSP structure, whatever) to define the organization in this part of configtx.yaml?
Hopefully I could be less confusing, but if not so let me know. My goal is to nail this properly.
Thanks!
0 -
Hi @kmyatt, thanks for answering. I'll prepare again an answer to continue the discussion, because I already lost two answers on this forum after editing. I am writing it now again.
0 -
Hi @kmyatt!
Thanks for carefully answering my points. This subject is very important and can cause confusion, so I appreciate your help.
I have read the whole official material before taking the course, but I feel that every tutorial or course take just a glance over the initial definitions of the genesis block and establishment of companies by the CA and further relation with the configtx.yaml. So I'll share the background for the question. Sorry if it takes too long.
We know that we have local and channel MSPs. Therefore we'll have, at least for nodes, peers, etc, a local structure of the MSP. There we have the, along with other things, the CA certificate, certificates for admins of that node and its own certificate to sign transactions. The channel MSP, on the other hand, will be defined for the channel and everybody that have the rights will have a copy of that.
So, in order to understand better the intricate relationships of MSPs I started a parallel project. My actions:
1) I created a Docker image from scratch, based on Ubuntu and started to organize the CA step by step. At the end, I recreated the definitions for companies at the fabric-ca-server-config.yaml and generated the self-signed certificate. The structure for organizations follows:
affiliations:
company-a:
- dept
company-b:
- dept
company-c:
- dept2) I generated the whole crypto material directly with the CA. Then I could register and enroll the peers, admins and so forth. The "company-a" was chosen to be the orderer company. The structure of directories for the crypto material:
../fabric-ca-client
/company-a
/admin
/orderer
/company-b
/admin
/peer
/company-c
/admin
/peer3) Then, I filled the configtx.yaml with the definition used in the CA affiliations and pointed MSPDir to the respective directory for the admin of company-a. Every company was defined as well.
Organizations:
- &company-a
Name: company-a
ID: company-a
MSPDir: ../fabric-ca-client/company-a/admin/mspFinally, I could generate the genesis block. This admin MSP for company-a has the CA certificate (cacerts) and the admin certificate (admincerts). So, at this point I am wondering:
Does the system check if the ID described in configtx.yaml (organizations) match the definition contained into the CA section (affiliations) to define the company? Is this the verification to create the MSP channel?
0 -
Hi @kmyatt!
Thanks for carefully answering my points. This subject is very important and can cause confusion, so I appreciate your help.
I have read the whole official material before taking the course, but I feel that every tutorial or course take just a glance over the initial definitions of the genesis block and establishment of companies by the CA and further relation with the configtx.yaml. So I'll share the background for the question. Sorry if it takes too long.
We know that we have local and channel MSPs. Therefore we'll have, at least for nodes, peers, etc, a local structure of the MSP. There we have the, along with other things, the CA certificate, certificates for admins of that node and its own certificate to sign transactions. The channel MSP, on the other hand, will be defined for the channel and everybody that have the rights will have a copy of that.
So, in order to understand better the intricate relationships of MSPs I started a parallel project. My actions:
1) I created a Docker image from scratch, based on Ubuntu and started to organize the CA step by step. At the end, I recreated the definitions for companies at the fabric-ca-server-config.yaml and generated the self-signed certificate. The structure for organizations follows:
affiliations:
company-a:
- dept
company-b:
- dept
company-c:
- dept2) I generated the whole crypto material directly with the CA. Then I could register and enroll the peers, admins and so forth. The "company-a" was chosen to be the orderer company. The structure of directories for the crypto material:
../fabric-ca-client
/company-a
/admin
/orderer
/company-b
/admin
/peer
/company-c
/admin
/peer3) Then, I filled the configtx.yaml with the definition used in the CA affiliations and pointed MSPDir to the respective directory for the admin of company-a. Every company was defined as well.
Organizations:
- &company-a
Name: company-a
ID: company-a
MSPDir: ../fabric-ca-client/company-a/admin/mspFinally, I could generate the genesis block. This admin MSP for company-a has the CA certificate (cacerts) and the admin certificate (admincerts). So, at this point I am wondering:
Does the system check if the ID described in configtx.yaml (organizations) match the definition contained into the CA section (affiliations) to define the company? Is this the verification to create the MSP channel?
0 -
Hi @kmyatt!
Thanks for carefully answering my points. This subject is very important and can cause confusion, so I appreciate your help.
I have read the whole official material before taking the course, but I feel that every tutorial or course take just a glance over the initial definitions of the genesis block and establishment of companies by the CA and further relation with the configtx.yaml. So I'll share the background for the question. Sorry if it takes too long.
We know that we have local and channel MSPs. Therefore we'll have, at least for nodes, peers, etc, a local structure of the MSP. There we have the, along with other things, the CA certificate, certificates for admins of that node and its own certificate to sign transactions. The channel MSP, on the other hand, will be defined for the channel and everybody that have the rights will have a copy of that.
So, in order to understand better the intricate relationships of MSPs I started a parallel project. My actions:
1) I created a Docker image from scratch, based on Ubuntu and started to organize the CA step by step. At the end, I recreated the definitions for companies at the fabric-ca-server-config.yaml and generated the self-signed certificate. The structure for organizations follows:
affiliations:
company-a:
- dept
company-b:
- dept
company-c:
- dept2) I generated the whole crypto material directly with the CA. Then I could register and enroll the peers, admins and so forth. The "company-a" was chosen to be the orderer company. The structure of directories for the crypto material:
../fabric-ca-client
/company-a
/admin
/orderer
/company-b
/admin
/peer
/company-c
/admin
/peer3) Then, I filled the configtx.yaml with the definition used in the CA affiliations and pointed MSPDir to the respective directory for the admin of company-a. Every company was defined as well.
Organizations:
- &company-a
Name: company-a
ID: company-a
MSPDir: ../fabric-ca-client/company-a/admin/mspFinally, I could generate the genesis block. This admin MSP for company-a has the CA certificate (cacerts) and the admin certificate (admincerts). So, at this point I am wondering:
Does the system check if the ID described in configtx.yaml (organizations) match the definition contained into the CA section (affiliations) to define the company? Is this the verification to create the MSP channel?
0
Categories
- All Categories
- 206 LFX Mentorship
- 206 LFX Mentorship: Linux Kernel
- 733 Linux Foundation IT Professional Programs
- 339 Cloud Engineer IT Professional Program
- 165 Advanced Cloud Engineer IT Professional Program
- 66 DevOps Engineer IT Professional Program
- 132 Cloud Native Developer IT Professional Program
- 119 Express Training Courses
- 119 Express Courses - Discussion Forum
- 5.9K Training Courses
- 40 LFC110 Class Forum - Discontinued
- 66 LFC131 Class Forum
- 39 LFD102 Class Forum
- 219 LFD103 Class Forum
- 17 LFD110 Class Forum
- 32 LFD121 Class Forum
- 17 LFD133 Class Forum
- 6 LFD134 Class Forum
- 17 LFD137 Class Forum
- 70 LFD201 Class Forum
- 3 LFD210 Class Forum
- 2 LFD210-CN Class Forum
- 2 LFD213 Class Forum - Discontinued
- 128 LFD232 Class Forum - Discontinued
- 1 LFD233 Class Forum
- 3 LFD237 Class Forum
- 23 LFD254 Class Forum
- 684 LFD259 Class Forum
- 109 LFD272 Class Forum
- 3 LFD272-JP クラス フォーラム
- 10 LFD273 Class Forum
- 96 LFS101 Class Forum
- LFS111 Class Forum
- 2 LFS112 Class Forum
- 1 LFS116 Class Forum
- 3 LFS118 Class Forum
- 2 LFS142 Class Forum
- 3 LFS144 Class Forum
- 3 LFS145 Class Forum
- 1 LFS146 Class Forum
- 2 LFS147 Class Forum
- 8 LFS151 Class Forum
- 1 LFS157 Class Forum
- 10 LFS158 Class Forum
- 4 LFS162 Class Forum
- 1 LFS166 Class Forum
- 3 LFS167 Class Forum
- 1 LFS170 Class Forum
- 1 LFS171 Class Forum
- 2 LFS178 Class Forum
- 2 LFS180 Class Forum
- 1 LFS182 Class Forum
- 4 LFS183 Class Forum
- 30 LFS200 Class Forum
- 737 LFS201 Class Forum - Discontinued
- 2 LFS201-JP クラス フォーラム
- 17 LFS203 Class Forum
- 112 LFS207 Class Forum
- 1 LFS207-DE-Klassenforum
- LFS207-JP クラス フォーラム
- 301 LFS211 Class Forum
- 55 LFS216 Class Forum
- 49 LFS241 Class Forum
- 43 LFS242 Class Forum
- 37 LFS243 Class Forum
- 13 LFS244 Class Forum
- 1 LFS245 Class Forum
- 45 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- LFS251 Class Forum
- 143 LFS253 Class Forum
- LFS254 Class Forum
- LFS255 Class Forum
- 6 LFS256 Class Forum
- LFS257 Class Forum
- 1.2K LFS258 Class Forum
- 9 LFS258-JP クラス フォーラム
- 114 LFS260 Class Forum
- 152 LFS261 Class Forum
- 41 LFS262 Class Forum
- 82 LFS263 Class Forum - Discontinued
- 15 LFS264 Class Forum - Discontinued
- 11 LFS266 Class Forum - Discontinued
- 23 LFS267 Class Forum
- 18 LFS268 Class Forum
- 29 LFS269 Class Forum
- 199 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- LFS274 Class Forum
- 3 LFS281 Class Forum
- 2 LFW111 Class Forum
- 257 LFW211 Class Forum
- 176 LFW212 Class Forum
- 12 SKF100 Class Forum
- SKF200 Class Forum
- 791 Hardware
- 199 Drivers
- 68 I/O Devices
- 37 Monitors
- 98 Multimedia
- 174 Networking
- 91 Printers & Scanners
- 85 Storage
- 754 Linux Distributions
- 82 Debian
- 67 Fedora
- 16 Linux Mint
- 13 Mageia
- 23 openSUSE
- 147 Red Hat Enterprise
- 31 Slackware
- 13 SUSE Enterprise
- 351 Ubuntu
- 464 Linux System Administration
- 39 Cloud Computing
- 70 Command Line/Scripting
- Github systems admin projects
- 91 Linux Security
- 78 Network Management
- 101 System Management
- 47 Web Management
- 56 Mobile Computing
- 17 Android
- 28 Development
- 1.2K New to Linux
- 1K Getting Started with Linux
- 365 Off Topic
- 113 Introductions
- 171 Small Talk
- 20 Study Material
- 523 Programming and Development
- 292 Kernel Development
- 213 Software Development
- 1.1K Software
- 212 Applications
- 180 Command Line
- 3 Compiling/Installing
- 405 Games
- 311 Installation
- 79 All In Program
- 79 All In Forum
Upcoming Training
-
August 20, 2018
Kubernetes Administration (LFS458)
-
August 20, 2018
Linux System Administration (LFS301)
-
August 27, 2018
Open Source Virtualization (LFS462)
-
August 27, 2018
Linux Kernel Debugging and Security (LFD440)