[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569704#comment-15569704
]
John Blum edited comment on GEODE-1986 at 10/12/16 8:02 PM:
------------------------------------------------------------
{quote}
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
{quote}
No, this cannot (or rather, should not) be a requirement as it will adversely
affect peer cache application deployments, regardless of the
"recommended/suggested/whatever" architecture/topology suggested by the
(Pivotal) EA teams; it does (and will) not change how it is actually used in
certain use cases.
If it is requirement because the "security manager (configuration)" is obtained
from the Cluster Configuration (service running in the "secured" Locator) in
order to enforce the "same" (as you say in #1) security configuration on all
joining members of the cluster, then this is an unacceptable technical
limitation imposed on the users vs. an actual good, carefully thought-out,
design decision.
{quote}
"a server can join a secured locator but itself is not secured."
{quote}
Not likely, since it will fail the SSL handshake. I would assume that security
credentials (including configuration) would also need to be secured during
transit. Therefore, while authentication/authorization is not necessarily
required for secure transport (i.e. SSL), it would seem logical that SSL is a
prerequisite (or requirement) for auth.
was (Author: jblum):
{quote}
2. If a locator is secured, a server who wants to join has to set
use-cluster-configuration to be true in order to join,
{quote}
No, this cannot (or rather, should not) be a requirement as it will adversely
affect peer cache application deployments, regardless of the
"recommended/suggested/whatever" architecture/topology suggested by the
(Pivotal) EA teams; it does (and will) not change how it is actually used in
certain use cases.
If it is requirement because the "security manager (configuration)" is obtained
from the Cluster Configuration (service running in the "secured" Locator) in
order to enforce the "same" (as you say in #1) security configuration on all
joining members of the cluster, then this is an unacceptable technical
limitation imposed on the users vs. an actual good, carefully thought-out,
design decision.
{quote}
"a server can join a secured locator but itself is not secured."
{quote}
Not likely, since it will fail the SSL handshake. I would assume that security
credentials (including configuration) would also need to be secured during
transit, therefore while authentication/authorization is not necessarily
required for secure transport (i.e. SSL) it would seem logical that SSL is a
prerequisite (or requirement) for auth.
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> -------------------------------------------------------------------------------
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
> Reporter: John Blum
> Assignee: Jinmei Liao
> Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
