[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
----------------------------------------
Description:
(note: the original description
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
was:
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
> SSL support in ZooKeeper Dynamic Reconfiguration
> ------------------------------------------------
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.5.5, 3.5.8, 3.6.2
> Reporter: zhaoyan
> Priority: Minor
>
> (note: the original description
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format could be extended with the secure client ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port. And also we can choose to have both unsecure and secure ports open in
> parallel. (It is even possible to use the same port as secure and unsecure,
> if port unification is enabled)
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
