[FAB-15648] hints to document: Non-TLS orderer with etcdraft usage #1678
Conversation
davidkhala
changed the title
docs/source/raft_configuration.md
Outdated
|
|
||
| Note: `ListenPort`, `ListenAddress`, `ServerCertificate`, `ServerPrivateKey` must | ||
| be either set together or unset together. | ||
| If they are unset, they are inherited from the general TLS section, | ||
| in example `general.tls.{privateKey, certificate}`. | ||
| In the use case when general TLS is disabled, these parameters must be set while: |
There was a problem hiding this comment.
| In the use case when general TLS is disabled, these parameters must be set while: | |
| In the use case when general TLS is disabled, these parameters must be set: |
small typo I think
davidkhala
force-pushed
the
master
branch
2 times, most recently
from
109894f
to
a95e17b
Compare
| * `ListenPort`: The port the cluster listens on. If blank, the port is the same | ||
| port as the orderer general port (`general.listenPort`) | ||
| * `ListenPort`: The port the cluster listens on. | ||
| It must be same as `consenters[i].Port` in Channel configuration. |
There was a problem hiding this comment.
Not sure if this is the best place to mention this. It feels like this belongs in the section describing the Consenters but that would require reordering some sections of this doc. The natural flow to me would be to describe the configuration of a single raft node and then how it fits into the channel configuration, not vice versa.
There was a problem hiding this comment.
Agree, I see this difficulty in how to express how they are bound. If another maintainer also agree on we are better to reorganize sections then I am glad to change accordingly.
docs/source/raft_configuration.md
Outdated
|
|
||
| Note: `ListenPort`, `ListenAddress`, `ServerCertificate`, `ServerPrivateKey` must | ||
| be either set together or unset together. | ||
| If they are unset, they are inherited from the general TLS section, | ||
| in example `general.tls.{privateKey, certificate}`. | ||
| In the use case when general TLS is disabled, these parameters must be set: |
There was a problem hiding this comment.
| In the use case when general TLS is disabled, these parameters must be set: | |
| When general TLS is disabled: |
docs/source/raft_configuration.md
Outdated
|
|
||
| Note: `ListenPort`, `ListenAddress`, `ServerCertificate`, `ServerPrivateKey` must | ||
| be either set together or unset together. | ||
| If they are unset, they are inherited from the general TLS section, | ||
| in example `general.tls.{privateKey, certificate}`. | ||
| In the use case when general TLS is disabled, these parameters must be set: | ||
| - use different `ListenPort` than the orderer general port |
There was a problem hiding this comment.
| - use different `ListenPort` than the orderer general port | |
| - use a different `ListenPort` than the orderer general port |
docs/source/raft_configuration.md
Outdated
|
|
||
| Note: `ListenPort`, `ListenAddress`, `ServerCertificate`, `ServerPrivateKey` must | ||
| be either set together or unset together. | ||
| If they are unset, they are inherited from the general TLS section, | ||
| in example `general.tls.{privateKey, certificate}`. | ||
| In the use case when general TLS is disabled, these parameters must be set: | ||
| - use different `ListenPort` than the orderer general port | ||
| - Properly configure TLS root CAs. Search scope includes |
There was a problem hiding this comment.
Why would we need to configure the TLS root CAs when TLS is disabled? I've never tried to use the orderer without TLS enabled but this seems odd.
There was a problem hiding this comment.
I imagine this is if you aren't defining the TLS CAs in the channel config? Although seems better to define them in the channel config even if TLS is disabled generally.
There was a problem hiding this comment.
I see consenters mutual connection errors when TLS root CAs could not be found in anywhere. I am not 100% sure of the search scope, but indeed we should have at least once.
There was a problem hiding this comment.
How about re-statement as Properly configure TLS root CAs. For instance, define them for each orderer organization in channel config @jyellick
There was a problem hiding this comment.
Sorry for losing track of this.
Yes, that sentence is better. Though I think it would be superior to say "Properly configure TLS root CAs in the channel configuration." I do not believe that recent versions of Fabric will even allow you to define Raft endpoints if their TLS certificate is not valid according to some TLS CA in the channel config.
|
It looks like this PR hasn't been touched in some time. @jyellick can you review @davidkhala's last question? |
davidkhala
force-pushed
the
master
branch
2 times, most recently
from
f3c0217
to
c1ec1d2
Compare
- Notes about configure TLSCARoot - Notes about configure non-general-TLS orderer with etcdraft mode Signed-off-by: davidliu <[email protected]>
|
@jyellick update and look for review again |
|
@Mergifyio backport release-2.3 |
|
@Mergifyio backport release-2.2 |
|
Command
|
- Notes about configure TLSCARoot - Notes about configure non-general-TLS orderer with etcdraft mode Signed-off-by: davidliu <[email protected]> (cherry picked from commit 0744363)
|
Command
|
- Notes about configure TLSCARoot - Notes about configure non-general-TLS orderer with etcdraft mode Signed-off-by: davidliu <[email protected]> (cherry picked from commit 0744363)
- Notes about configure TLSCARoot - Notes about configure non-general-TLS orderer with etcdraft mode Signed-off-by: davidliu <[email protected]> (cherry picked from commit 0744363)
- Notes about configure TLSCARoot - Notes about configure non-general-TLS orderer with etcdraft mode Signed-off-by: davidliu <[email protected]> (cherry picked from commit 0744363)
Type of change
Description
Additional details
Signed-off-by: davidliu [email protected]
Related issues
FAB-15648