You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/05/09 01:26:39 UTC
[ApacheDS] SASL Branch
Enrique,
I started to take a look at the sasl branch so you can merge it into the
trunk however
it seems the SaslBindTest fails for some reason. Also if this is an
integration test that
starts up the server you should use SaslBindITest (note ITest instead of
Test) so this
test is run when you include a -Dintegration on the command line. Since
these tests
which start the server repeatedly for each test case can take a while to run
we use
a maven profile to trigger then when this integration property is defined.
BTW where was that document which you wrote describing the SASL work you did
on this branch. I just want to read it before continuing to review the code
here.
Alex
Re: [ApacheDS] SASL Branch
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
> Enrique,
>
> I started to take a look at the sasl branch so you can merge it into the
> trunk however
> it seems the SaslBindTest fails for some reason. Also if this is an
> integration test that
> starts up the server you should use SaslBindITest (note ITest instead of
> Test) so this
> test is run when you include a -Dintegration on the command line. Since
> these tests
> which start the server repeatedly for each test case can take a while to run
> we use
> a maven profile to trigger then when this integration property is defined.
> ...
OK, renamed 2 Test's to ITest.
Enrique
Re: [ApacheDS] SASL Branch
Posted by Alex Karasulu <ak...@apache.org>.
On 5/9/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> Actually, because of the Kerberos port issue, I isolated the Kerberos
> integration tests in SaslGssapiBindTest, so any failure should have
> occurred there. If SaslBindTest failed, it would be a different
> reason. Again, the maven test log would be helpful.
Yep see my earlier email: it was SaslGssapiBindTest that cause the
failure. The other test just printed out the stack trace which confused
me into thinking it was at fault.
Alex
Re: [ApacheDS] SASL Branch
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
> > I started to take a look at the sasl branch so you can merge it into the
> > trunk however
> > it seems the SaslBindTest fails for some reason.
>
> Test log would be helpful but I suspect it is the Kerberos port
> binding issue I mentioned, namely that the JDK Kerberos client doesn't
> allow you to specify port in code, so it will default to the Kerberos
> port, 88, which requires root to bind.
>
> I just ran the tests OK ... as root.
Actually, because of the Kerberos port issue, I isolated the Kerberos
integration tests in SaslGssapiBindTest, so any failure should have
occurred there. If SaslBindTest failed, it would be a different
reason. Again, the maven test log would be helpful.
Enrique
Re: [ApacheDS] SASL Branch
Posted by Alex Karasulu <ak...@apache.org>.
Let me get that to you tomorrow ... getting late here (3am).
Alex
On 5/9/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
> > > I started to take a look at the sasl branch so you can merge it into
> the
> > > trunk however
> > > it seems the SaslBindTest fails for some reason.
> >
> > Test log would be helpful but I suspect it is the Kerberos port
> > binding issue I mentioned, namely that the JDK Kerberos client doesn't
> > allow you to specify port in code, so it will default to the Kerberos
> > port, 88, which requires root to bind.
> >
> > I just ran the tests OK ... as root.
>
> The other thing to keep in mind is that SASL is picky about the host
> name. So, all the integration tests expect 'localhost' to be
> configured. I have the following in my hosts file:
>
> 127.0.0.1 localhost localhost.localdomain
>
> Enrique
>
Re: [ApacheDS] SASL Branch
Posted by Alex Karasulu <ak...@apache.org>.
On 5/9/07, Enrique Rodriguez <en...@gmail.com> wrote:
SNIP ...
The other thing to keep in mind is that SASL is picky about the host
> name. So, all the integration tests expect 'localhost' to be
> configured. I have the following in my hosts file:
>
> 127.0.0.1 localhost localhost.localdomain
I have this entry as well. Again tho the problem is due to the need for
root
access to port 88. This is what we must find a work around for. Perhaps we
might just write that simple kerberos client if it would not be too
difficult?
Alex
Re: [ApacheDS] SASL Branch
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
> > I started to take a look at the sasl branch so you can merge it into the
> > trunk however
> > it seems the SaslBindTest fails for some reason.
>
> Test log would be helpful but I suspect it is the Kerberos port
> binding issue I mentioned, namely that the JDK Kerberos client doesn't
> allow you to specify port in code, so it will default to the Kerberos
> port, 88, which requires root to bind.
>
> I just ran the tests OK ... as root.
The other thing to keep in mind is that SASL is picky about the host
name. So, all the integration tests expect 'localhost' to be
configured. I have the following in my hosts file:
127.0.0.1 localhost localhost.localdomain
Enrique
Re: [ApacheDS] SASL Branch
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/9/07, Alex Karasulu <ak...@apache.org> wrote:
> On 5/9/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > ...
> > Test log would be helpful but I suspect it is the Kerberos port
> > binding issue I mentioned, namely that the JDK Kerberos client doesn't
> > allow you to specify port in code, so it will default to the Kerberos
> > port, 88, which requires root to bind.
>
> That's going to present a problem for us. We cannot perform this test if it
> has to run as root:
> those checking out the code to build the server and test the server are not
> going to want to
> have to run as root to make the tests pass. You can imagine the problems
> this will cause us.
> Is there no other way? I'd hate to disable the test overall since it's
> great to have if we wind
> up breaking the SASL mechanism with changes.
1) I looked into the JDK to see if there was config for the Kerberos
port, but couldn't find one. There could still be some way to set it,
in code.
2) I thought about passing byte[] captures into the handler to test,
but the issue comes up that validity periods are tested and we run
into the same issue of not being able to easily extend any validity
periods.
3) We can still run the non-GSSAPI SASL tests, which do test most of
the SASL Bind code.
4) As you noted, the best option is a Kerberos client with some
visibility into its inner workings. I just started in on a client for
key export. I can look at working on a basic Kerberos client at the
same time. Perhaps at least one with the minimum capability to
resolve this test. This won't be a 1-weekend project, though.
> BTW I just ran this test again not as root tho and it passed this time but
> produced
> the following stack trace on the command line. I guess you're dumping the
> trace
> in your test case out to stderr. We might not want to do that.
We definitely don't want to do that. I missed cleaning that test case
of stacktraces and System.out/err. I committed the changes.
Enrique
Re: [ApacheDS] SASL Branch
Posted by Alex Karasulu <ak...@apache.org>.
On 5/9/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
> > I started to take a look at the sasl branch so you can merge it into the
> > trunk however
> > it seems the SaslBindTest fails for some reason.
>
> Test log would be helpful but I suspect it is the Kerberos port
> binding issue I mentioned, namely that the JDK Kerberos client doesn't
> allow you to specify port in code, so it will default to the Kerberos
> port, 88, which requires root to bind.
That's going to present a problem for us. We cannot perform this test if it
has to run as root:
those checking out the code to build the server and test the server are not
going to want to
have to run as root to make the tests pass. You can imagine the problems
this will cause us.
Is there no other way? I'd hate to disable the test overall since it's
great to have if we wind
up breaking the SASL mechanism with changes.
BTW I just ran this test again not as root tho and it passed this time but
produced
the following stack trace on the command line. I guess you're dumping the
trace
in your test case out to stderr. We might not want to do that.
Running org.apache.directory.server.SaslBindTest
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
response]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:2985)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2732)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2646)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java
:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java
:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(
LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(
LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(
NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java
:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at javax.naming.directory.InitialDirContext.<init>(
InitialDirContext.java:82)
at
org.apache.directory.server.SaslBindTest.testSaslCramMd5BindBadPassword(
SaslBindTest.java:499)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(
JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(
SurefireBooter.java:244)
at org.apache.maven.surefire.booter.SurefireBooter.main(
SurefireBooter.java:814)
I ran this test using the following command within the server-unit directory
of the sasl branch:
mvn -Dintegration -Dtest=SaslBindTest test
So it turns out that you were right. This SaslBindTest just blows the stack
but does not fail it's the
SaslGssapiBindTest that does fail. I have included the surefire report for
this test below just in
case even though we know the problem is due to permissions for binding on
port 88:
-------------------------------------------------------------------------------
Test set: org.apache.directory.server.SaslGssapiBindTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 95.495 sec
<<< FAILURE!
testSaslGssapiBind(org.apache.directory.server.SaslGssapiBindTest) Time
elapsed: 95.436 sec <<< FAILURE!
junit.framework.AssertionFailedError: Authentication failed: Receive timed
out
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.directory.server.SaslGssapiBindTest.testSaslGssapiBind
(SaslGssapiBindTest.java:246)
at org.apache.directory.server.SaslGssapiBindTest.testSaslGssapiBind
(SaslGssapiBindTest.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(
JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(
AbstractDirectoryTestSuite.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(
SurefireBooter.java:244)
at org.apache.maven.surefire.booter.SurefireBooter.main(
SurefireBooter.java:814)
I just ran the tests OK ... as root.
Yep the test does run ok as root for me as well. BTW as non-root when I
run just that test
using the -Dtest=SaslGssapiBindTest parameter to maven the test hangs for
me.
SNIP ...
> Looks like Christine moved it to 1.0? Did you guys discuss
> backporting this at AC EU? I was expecting this to go into 1.5.1.
>
> Direct SASL page:
>
> http://cwiki.apache.org/confluence/display/DIRxSRVx10/SASL+Authentication+to+ApacheDS
>
> 1.0 AUG:
>
> http://cwiki.apache.org/confluence/display/DIRxSRVx10/ApacheDS+v1.0+Advanced+User%27s+Guide
Hmmm yeah that's probably why I could not find it. I guess it should be
moved back
into the 1.5 area. Christine is this possible.
Enrique, we have to find some work around for this failing test and quiet
down the one
that spits out the stack trace. Perhaps you can come up with some
recommendations.
Alex
Re: [ApacheDS] SASL Branch
Posted by Enrique Rodriguez <en...@gmail.com>.
On 5/8/07, Alex Karasulu <ak...@apache.org> wrote:
> I started to take a look at the sasl branch so you can merge it into the
> trunk however
> it seems the SaslBindTest fails for some reason.
Test log would be helpful but I suspect it is the Kerberos port
binding issue I mentioned, namely that the JDK Kerberos client doesn't
allow you to specify port in code, so it will default to the Kerberos
port, 88, which requires root to bind.
I just ran the tests OK ... as root.
> Also if this is an
> integration test that
> starts up the server you should use SaslBindITest (note ITest instead of
> Test) so this
> test is run when you include a -Dintegration on the command line. Since
> these tests
> which start the server repeatedly for each test case can take a while to run
> we use
> a maven profile to trigger then when this integration property is defined.
Good point, I will adjust that if you don't before me. Yes, it is an
integration test.
> BTW where was that document which you wrote describing the SASL work you did
> on this branch. I just want to read it before continuing to review the code
> here.
Looks like Christine moved it to 1.0? Did you guys discuss
backporting this at AC EU? I was expecting this to go into 1.5.1.
Direct SASL page:
http://cwiki.apache.org/confluence/display/DIRxSRVx10/SASL+Authentication+to+ApacheDS
1.0 AUG:
http://cwiki.apache.org/confluence/display/DIRxSRVx10/ApacheDS+v1.0+Advanced+User%27s+Guide
Enrique