Short branch #1277
Short branch #1277
Conversation
# Conflicts: # packages/composer-website/jekylldocs/installing/quickstart.md
# Conflicts: # packages/composer-website/jekylldocs/installing/manual_prerequisites.md # packages/composer-website/jekylldocs/installing/prerequisites.md
|
|
||
| In {{site.data.conrefs.hlf_full}} Beta peers now enforce the concepts of admins and members. Admin user's identities and crypto material must be available to the peer at deployment. To make that identity and its crypto material available, your must import it to your local `keyValStore` directory before deploying the business network. To import the identity, use the [`composer identity import` command](../reference/composer.identity.import.html). When importing an identity, you do not assign it a secret, however the `composer network deploy` command requires a secret. If you are using an imported identity, you can enter any value for the secret. | ||
|
|
||
| When connecting to the peer you must specify an identity which contains the userID `admin`, for example, `PeerAdmin`, `myadmin`, or `AdminPeer` are all valid userID's. Peers in different organizations may have different admin users. Only an admin user of peer's organization will be able to deploy a business network to their peers. |
There was a problem hiding this comment.
you must specify an identity which contains the userID admin
it's not so much containing the userid as the userid you choose containing the text 'admin'.
|
|
||
| When connecting to the peer you must specify an identity which contains the userID `admin`, for example, `PeerAdmin`, `myadmin`, or `AdminPeer` are all valid userID's. Peers in different organizations may have different admin users. Only an admin user of peer's organization will be able to deploy a business network to their peers. | ||
|
|
||
| Once a user has deployed a business network to one or more peers, they must also be the user to instantiate the business network. Any subsequent deploys requests will only install the business network on those peers. |
There was a problem hiding this comment.
When a user deploys a business network to their peers, it will first install the business network then if the business network has never been instantiated before it will be instantiated. If later on someone deploys to another peer as the business network has already been instantiated it will only be installed to the peer and that peer will then be able to participate in the business network
|
|
||
| Once a user has deployed a business network to one or more peers, they must also be the user to instantiate the business network. Any subsequent deploys requests will only install the business network on those peers. | ||
|
|
||
| These security changes mean that {{site.data.conrefs.hlf_full}} Beta is not compatible with any fabric that is running an older version. |
There was a problem hiding this comment.
With composer moving to support hlfv1 beta. It will not be compatible with older versions of hlfv1
| ## Connecting to a {{site.data.conrefs.hlf_full}} Beta | ||
|
|
||
|
|
||
| In {{site.data.conrefs.hlf_full}} Beta peers now enforce the concepts of admins and members. Admin user's identities and crypto material must be available to the peer at deployment. To make that identity and its crypto material available, your must import it to your local `keyValStore` directory before deploying the business network. To import the identity, use the [`composer identity import` command](../reference/composer.identity.import.html). When importing an identity, you do not assign it a secret, however the `composer network deploy` command requires a secret. If you are using an imported identity, you can enter any value for the secret. |
There was a problem hiding this comment.
Do we really want to replicate this again ?
There was a problem hiding this comment.
For the time being. Next week will implement some steps explaining how and what to do, but for something which came in so late in the day...
| "maxRecvSize": 15 | ||
| } | ||
|
|
||
| If you are connecting to {{site.data.conrefs.hlf_full}} v1.0 and are not using TLS or if you don't need the trustedRoots and verify options of the Certificate Authority definition you can use the following simplified connection profile: |
There was a problem hiding this comment.
The simplified version defines the "ca" as a single line. This will only work if the ca has no name defined. If it does then you will have to use the more complex definition of a ca
"ca": {
"url:" "http://",
"name": ""
},
| - `maxSendSize` is an optional property which defines the size limit of outbound grpc messages being send to orderers and peers. The value is defined in megabytes. If this is not set, grpc sets a default. Setting this property to `-1` results in no size restriction. | ||
| - `maxRecvSize` is an optional property which defines the size limit of inbound grpc messages being received from orderers and peers. The value is defined in megabytes. If this is not set, grpc sets a default. Setting this property to `-1` results in no size restriction. | ||
|
|
||
| *Please note: If you are connecting to an instance of {{site.data.conrefs.hlf_full}} v1.0 the `keyValStore` property must be `home/.hfc-key-store`* |
There was a problem hiding this comment.
The comment
Please note: If you are connecting to an instance of {{site.data.conrefs.hlf_full}} v1.0 the keyValStore property must be home/.hfc-key-store
can now be removed, thank goodness.
|
@EdProsser you are going to have trouble getting this to merge, suggest you talk to Caroline to help you rebase this branch, Ok, maybe not. But highly recommend you rebase before merging. |
davidkel
left a comment
davidkel
left a comment
There was a problem hiding this comment.
difficult to see how this will flow until published to website so approving so we can get it in and review again.
4 participants
Updates for Security, Queries, Connection profiles and other minor tweaks.