I'm working on GEODE-1959
<https://issues.apache.org/jira/browse/GEODE-1959> and
the use case goes like this:

Create your gemfire.properites with a security manager.  For example:

> security-manager=org.apache.geode.security.templates.SampleSecurityManage

But do not provide a username and password within it.  Point to a
security.json file that contains users and roles.  My startup line within
gfsh goes like this:

*gfsh>*start locator --name=loc --classpath=/Users/kduling/geode/run
> --properties-file=./gemfire.properties


Then start a server with security:

*gfsh>*start server --name=secured --classpath=/Users/kduling/geode/run
> --properties-file=./gemfire.properties --locators=127.0.0.1[10334]


This produces a GemFireSecurityException because there are no login
credentials set.  The entire stacktrace goes:

objc[2117]: Class JavaLaunchHelper is implemented in both
> /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/bin/java
> and
> /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/libinstrument.dylib.
> One of the two will be used. Which one is undefined.
> Exception in thread "main"
> org.apache.geode.security.GemFireSecurityException: Failed to find
> credentials from [10.0.2.35(secured:2117):1025]
>     at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.attemptToJoin(GMSJoinLeave.java:416)
>     at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.join(GMSJoinLeave.java:314)
>     at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:662)
>     at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:749)
>     at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:183)
>     at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:104)
>     at
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:92)
>     at
> org.apache.geode.distributed.internal.DistributionManager.<init>(DistributionManager.java:1092)
>     at
> org.apache.geode.distributed.internal.DistributionManager.<init>(DistributionManager.java:1144)
>     at
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:521)
>     at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:657)
>     at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:297)
>     at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:237)
>     at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:229)
>     at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:55)
>     at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:783)
>     at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:703)
>     at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:633)
>     at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:184)


To resolve this, I was planning on catching the exception at
DistributedSystem.connect() and then prompting for the username/password
similar to what is done in ShellCommands.jmxConnect().

Does anyone see a problem with this or have a recommendation for a better
approach?

Reply via email to