[ 
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569869#comment-15569869
 ] 

Jinmei Liao edited comment on GEODE-1986 at 10/13/16 6:23 AM:
--------------------------------------------------------------

The scenario you provided in the beginning of the bug is fixed by correcting 
setting the "enable-cluster-configuration" flag when starting an embedded 
locator. Cluster configuration is not a required service, if the locator does 
not have cluster configuration service running, then regardless of its 
security, a member can join with its own security manager. But if a locator has 
cluster config running and is secured, any member without use-cluster-config 
will be rejected. Are there other use cases that would fail with current 
implementation? We will add it to our Dunit test suite to uncover it and fix it.

Also, without our current implementation,  a server with correct credentials 
and use SSL would successfully join a secured locator  but itself can be 
unprotected. Client can directly connect to that server without any credential 
to get the data even though the locator is secured.


was (Author: jinmeiliao):
The scenario you provided in the beginning of the bug is fixed by correcting 
setting the "enable-cluster-configuration" flag when starting an embedded 
locator. Cluster configuration is not a required service, if the locator does 
not have cluster configuration service running, then regardless of its 
security, a member can join with its own security manager. But if a locator has 
cluster config running and is secured, any member without use-cluster-config 
will be rejected. Are there other use cases that would render this requirement 
unacceptable? We will add it to our Dunit test suite to accommodate it.

Also, a server with correct credentials and use SSL will successfully join the 
locator, but itself can be unprotected. Client can directly connect to that 
server.

> 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)

Reply via email to