You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kevin Duling <kd...@pivotal.io> on 2016/10/13 21:50:18 UTC
Starting the server, prompt for username/password
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?
Re: Starting the server, prompt for username/password
Posted by Jinmei Liao <ji...@pivotal.io>.
member can provide an auth-init method to get those credentials instead of
explicitly specify username/password as well. So you will need to check for
that as well.
On Thu, Oct 13, 2016 at 3:20 PM, Kevin Duling <kd...@pivotal.io> wrote:
> security-username and security-password appear to be the properties most
> commonly set/checked. I could base prompting off of their existence and
> null value.
>
> On Thu, Oct 13, 2016 at 2:55 PM, Kirk Lund <kl...@apache.org> wrote:
>
> > I think we should avoid using an exception for normal flow control. I'd
> > provide a link to Ward Cunningham's wiki but his wiki is currently down.
> >
> > There should be a way to determine if the user has credentials before
> > trying to connect.
> >
> > -Kirk
> >
> >
> > On Thu, Oct 13, 2016 at 2:50 PM, Kevin Duling <kd...@pivotal.io>
> wrote:
> >
> > > 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.DefaultServerLauncherCacheProv
> > > ider.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?
> > >
> >
>
--
Cheers
Jinmei
Re: Starting the server, prompt for username/password
Posted by Kevin Duling <kd...@pivotal.io>.
security-username and security-password appear to be the properties most
commonly set/checked. I could base prompting off of their existence and
null value.
On Thu, Oct 13, 2016 at 2:55 PM, Kirk Lund <kl...@apache.org> wrote:
> I think we should avoid using an exception for normal flow control. I'd
> provide a link to Ward Cunningham's wiki but his wiki is currently down.
>
> There should be a way to determine if the user has credentials before
> trying to connect.
>
> -Kirk
>
>
> On Thu, Oct 13, 2016 at 2:50 PM, Kevin Duling <kd...@pivotal.io> wrote:
>
> > 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.DefaultServerLauncherCacheProv
> > ider.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?
> >
>
Re: Starting the server, prompt for username/password
Posted by Kirk Lund <kl...@apache.org>.
I think we should avoid using an exception for normal flow control. I'd
provide a link to Ward Cunningham's wiki but his wiki is currently down.
There should be a way to determine if the user has credentials before
trying to connect.
-Kirk
On Thu, Oct 13, 2016 at 2:50 PM, Kevin Duling <kd...@pivotal.io> wrote:
> 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.DefaultServerLauncherCacheProv
> ider.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?
>