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?
