SVNKit troubles in 1.75

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

SVNKit troubles in 1.75

Eric Crahen-3
I have some questions on the new SVNKit integration.

#1) Connection Error?

I upgraded from using an external svn binary in hudson 1.6.8, to hudson version 1.75 which uses SVNKit. When I create a new project and place my svn url in the field, I an given the following error.

"Unable to access http://myserver/svn/myproject : svn: Unable to create SVNRepository object for 'http://myserver/svn/myproject' (Maybe you need to enter credential ?)"

I was previously able to access this URL with my external client. I'm not sure what when wrong, I looked at stdout, I looked in my servlet container logs and I checked the "Manage Hudson" system log and I did not find any output that would help me understand the error. There is no credential required to check out of this respository, anonymous access is perfectly OK.

What can I do to find the source of the error? Is there a way to make the real error more obvious to the user? (I think SVNKit must have produced some sort of useful error message we could use.)

#2) Trust?

Another thing I have a question about is how can I provide SVNKit with the set of certificates I trust? My repository requires an SSL login in order to perform updates, which I would want to do after the fact tagging. My repository uses a self-signed certificate which is not going to trusted without extra work. The way I told my svn binary to trust my servers certificate was by first using the user account I ran hudson as to do an:

svn https://myserver/svn/myproject

This would cause the svn binary to prompt me that this server has a self-signed cert and asks me if I should trust it. I would select yes permanently and svn would save some info in ~/.subversion to say trust this certificate. Later when I used hudson, I ran svn as the user and svn remebered to trust this server because of the data in ~/.subversion

With the SVNKit integration, its not immediately obvious to me how to associate a trusted certificate with an SVN connection. I suppose one method would be to manually create a jks trust store and run hudson with the correct - Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePassword options.

Since I haven't gotten past my first problem I can't confirm this works, but it ought to.


#3) Username / Password the only credential?

I can also configure my subversion repository to use SSL client identification as a credential, instead of or along with user/name password. I'm not doing this, but it would be an interesting thing for the TODO list.


--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Kohsuke Kawaguchi-2
Eric Crahen wrote:

> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson 1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
> need to enter
> credential<http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject>
> ?)"
>
> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
I think this is the same issue reported in #245. I need to take a look
at this.

>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions.
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
I actually tell svnkit to accept any server certificate without any
check, so this should work just fine.

> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.

I see. I guess I don't have the environment to test this, so I could use
some help.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Kohsuke Kawaguchi-2
In reply to this post by Eric Crahen-3

Hi, I updated the issue 245. If you can try the latest snapshot and let
me know what error you get, that would be really helpful.

Eric Crahen wrote:

> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson 1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
> need to enter
> credential<http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject>
> ?)"
>
> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions.
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
>
>
> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Eric Crahen-3
I expanded the show details link and I got this,


org.tmatesoft.svn.core.SVNException: svn: Unable to create SVNRepository object for ' https://myserver/svn/myproject'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:48)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:143)
at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
at hudson.util.FormFieldValidator.process(FormFieldValidator.java :33)
at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:588)
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:597)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java :50)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.Stapler.invoke (Stapler.java:169)
at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java :181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle (Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext (HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java :329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)


On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:

Hi, I updated the issue 245. If you can try the latest snapshot and let
me know what error you get, that would be really helpful.

Eric Crahen wrote:

> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson 1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
> need to enter
> credential< http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject>
> ?)"
>

> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions .
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
>
>
> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Eric Crahen-3
I get the same thing when I try a plain http:// based repo as well.

On 1/25/07, Eric Crahen <[hidden email]> wrote:
I expanded the show details link and I got this,



org.tmatesoft.svn.core.SVNException: svn: Unable to create SVNRepository object for '<a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:48)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:143)
at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
at hudson.util.FormFieldValidator.process(FormFieldValidator.java
:33)
at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:588)
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:597)
at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java
:50)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.Stapler.invoke
(Stapler.java:169)
at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :491)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java
:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle
(ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle
(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext
(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at org.mortbay.io.nio.SelectChannelEndPoint.run (SelectChannelEndPoint.java
:329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)


On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:

Hi, I updated the issue 245. If you can try the latest snapshot and let
me know what error you get, that would be really helpful.

Eric Crahen wrote:

> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson 1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access <a href="http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for '<a href="http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://myserver/svn/myproject ' (Maybe you
> need to enter
> credential< <a href="http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject >
> ?)"
>

> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn <a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions .
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
>
>
> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric



--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Eric Crahen-3
I think its not resolving the URL fully.

When I enter https://myserver.mydomain.org/svn/myproject it works fine. When I use the preferred shorthand, https://myserver/svn/myproject I get the error. The machine I run hudson in is also in domain.org, and if I were to drop to a shell and nslookup mysever it resolves just fine, so I don't think its a nameserver/default domain configuration issue on my workstation.


On 1/25/07, Eric Crahen <[hidden email]> wrote:
I get the same thing when I try a plain http:// based repo as well.


On 1/25/07, Eric Crahen <[hidden email]> wrote:
I expanded the show details link and I got this,




org.tmatesoft.svn.core.SVNException: svn: Unable to create SVNRepository object for '<a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:48)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)

at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:143)
at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
at hudson.util.FormFieldValidator.process(FormFieldValidator.java

:33)
at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:588)
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:597)
at org.kohsuke.stapler.Function$InstanceFunction.invoke (Function.java

:50)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke (Stapler.java:224)

at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.Stapler.invoke

(Stapler.java:169)
at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java
:491)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle
(SessionHandler.java
:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle

(ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle

(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext

(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at org.mortbay.io.nio.SelectChannelEndPoint.run
(SelectChannelEndPoint.java
:329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)


On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:

Hi, I updated the issue 245. If you can try the latest snapshot and let
me know what error you get, that would be really helpful.

Eric Crahen wrote:

> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson 1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access <a href="http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for '<a href="http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://myserver/svn/myproject ' (Maybe you
> need to enter
> credential< <a href="http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject >
> ?)"
>

> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn <a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions .
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
>
>
> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric



--

- Eric



--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Eric Crahen-3
I'm not sure if SVNKit is supposed to resolve the URLs completely or not. If not, I guess you could plunk each URL you get from the form into a java.net.URL, grab the host portion, resolve it fully, create a new URL and feed that to SVNKit...

On 1/25/07, Eric Crahen <[hidden email]> wrote:
I think its not resolving the URL fully.

When I enter <a href="https://myserver.mydomain.org/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://myserver.mydomain.org/svn/myproject it works fine. When I use the preferred shorthand, <a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject I get the error. The machine I run hudson in is also in <a href="http://domain.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">domain.org, and if I were to drop to a shell and nslookup mysever it resolves just fine, so I don't think its a nameserver/default domain configuration issue on my workstation.



On 1/25/07, Eric Crahen <[hidden email]> wrote:
I get the same thing when I try a plain http:// based repo as well.


On 1/25/07, Eric Crahen <[hidden email]> wrote:
I expanded the show details link and I got this,





org.tmatesoft.svn.core.SVNException: svn: Unable to create SVNRepository object for '<a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:48)
at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)


at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:143)
at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
at hudson.util.FormFieldValidator.process(FormFieldValidator.java


:33)
at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:588)
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:597)
at org.kohsuke.stapler.Function$InstanceFunction.invoke
(Function.java

:50)
at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke
(Stapler.java:224)

at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
at org.kohsuke.stapler.Stapler.invoke


(Stapler.java:169)
at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java

:491)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle

(SessionHandler.java
:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle


(ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle


(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java :751)
at org.mortbay.jetty.HttpParser.parseNext


(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java :357)
at org.mortbay.io.nio.SelectChannelEndPoint.run

(SelectChannelEndPoint.java
:329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)


On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:

Hi, I updated the issue 245. If you can try the latest snapshot and let
me know what error you get, that would be really helpful.

Eric Crahen wrote:

> I have some questions on the new SVNKit integration.
>
> #1) Connection Error?
>
> I upgraded from using an external svn binary in hudson 1.6.8, to hudson
> version 1.75 which uses SVNKit. When I create a new project and place my svn
> url in the field, I an given the following error.
>
> "Unable to access <a href="http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://myserver/svn/myproject : svn: Unable to create
> SVNRepository object for '<a href="http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://myserver/svn/myproject ' (Maybe you
> need to enter
> credential< <a href="http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject >
> ?)"
>

> I was previously able to access this URL with my external client. I'm not
> sure what when wrong, I looked at stdout, I looked in my servlet container
> logs and I checked the "Manage Hudson" system log and I did not find any
> output that would help me understand the error. There is no credential
> required to check out of this respository, anonymous access is perfectly OK.
>
> What can I do to find the source of the error? Is there a way to make the
> real error more obvious to the user? (I think SVNKit must have produced some
> sort of useful error message we could use.)
>
> #2) Trust?
>
> Another thing I have a question about is how can I provide SVNKit with the
> set of certificates I trust? My repository requires an SSL login in order to
> perform updates, which I would want to do after the fact tagging. My
> repository uses a self-signed certificate which is not going to trusted
> without extra work. The way I told my svn binary to trust my servers
> certificate was by first using the user account I ran hudson as to do an:
>
> svn <a href="https://myserver/svn/myproject" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://myserver/svn/myproject
>
> This would cause the svn binary to prompt me that this server has a
> self-signed cert and asks me if I should trust it. I would select yes
> permanently and svn would save some info in ~/.subversion to say trust this
> certificate. Later when I used hudson, I ran svn as the user and svn
> remebered to trust this server because of the data in ~/.subversion
>
> With the SVNKit integration, its not immediately obvious to me how to
> associate a trusted certificate with an SVN connection. I suppose one method
> would be to manually create a jks trust store and run hudson with the
> correct -Djavax.net.ssl.trustStore, -Djavax.net.ssl.trustStorePasswordoptions .
>
> Since I haven't gotten past my first problem I can't confirm this works, but
> it ought to.
>
>
> #3) Username / Password the only credential?
>
> I can also configure my subversion repository to use SSL client
> identification as a credential, instead of or along with user/name password.
> I'm not doing this, but it would be an interesting thing for the TODO list.
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric



--

- Eric



--

- Eric



--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Kohsuke Kawaguchi-2
In reply to this post by Eric Crahen-3

Thanks. I think I know what's going on.

Code that registers the protocol handler (the ones that understands http
https, svn, etc) needs to be registered before svnkit works
successfully, and yet I suspect it's not run at the right moment.

 From looking at svnkit source code, it should understand your URL just
fine.

Continuous build #2124 should have a fix for this. If you can try that,
that would be really appreciated.

Eric Crahen wrote:

> I expanded the show details link and I got this,
>
>
> org.tmatesoft.svn.core.SVNException: svn: Unable to create
> SVNRepository object for 'https://myserver/svn/myproject'
> at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:48)
> at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)
> at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:143)
> at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
> at hudson.util.FormFieldValidator.process(FormFieldValidator.java:33)
> at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(SubversionSCM.java:588)
> 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:597)
> at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:50)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
> at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
> at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
> at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:169)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
> at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
> at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
> at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
> at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
> at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
> at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
>
>
>
> On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>>
>>
>> Hi, I updated the issue 245. If you can try the latest snapshot and let
>> me know what error you get, that would be really helpful.
>>
>> Eric Crahen wrote:
>> > I have some questions on the new SVNKit integration.
>> >
>> > #1) Connection Error?
>> >
>> > I upgraded from using an external svn binary in hudson 1.6.8, to hudson
>> > version 1.75 which uses SVNKit. When I create a new project and place my
>> svn
>> > url in the field, I an given the following error.
>> >
>> > "Unable to access http://myserver/svn/myproject : svn: Unable to create
>> > SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
>> > need to enter
>> > credential<
>> http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject
>> >
>> > ?)"
>> >
>> > I was previously able to access this URL with my external client. I'm
>> not
>> > sure what when wrong, I looked at stdout, I looked in my servlet
>> container
>> > logs and I checked the "Manage Hudson" system log and I did not find any
>> > output that would help me understand the error. There is no credential
>> > required to check out of this respository, anonymous access is perfectly
>> OK.
>> >
>> > What can I do to find the source of the error? Is there a way to make
>> the
>> > real error more obvious to the user? (I think SVNKit must have produced
>> some
>> > sort of useful error message we could use.)
>> >
>> > #2) Trust?
>> >
>> > Another thing I have a question about is how can I provide SVNKit with
>> the
>> > set of certificates I trust? My repository requires an SSL login in
>> order to
>> > perform updates, which I would want to do after the fact tagging. My
>> > repository uses a self-signed certificate which is not going to trusted
>> > without extra work. The way I told my svn binary to trust my servers
>> > certificate was by first using the user account I ran hudson as to do
>> an:
>> >
>> > svn https://myserver/svn/myproject
>> >
>> > This would cause the svn binary to prompt me that this server has a
>> > self-signed cert and asks me if I should trust it. I would select yes
>> > permanently and svn would save some info in ~/.subversion to say trust
>> this
>> > certificate. Later when I used hudson, I ran svn as the user and svn
>> > remebered to trust this server because of the data in ~/.subversion
>> >
>> > With the SVNKit integration, its not immediately obvious to me how to
>> > associate a trusted certificate with an SVN connection. I suppose one
>> method
>> > would be to manually create a jks trust store and run hudson with the
>> > correct -Djavax.net.ssl.trustStore, -
>> Djavax.net.ssl.trustStorePasswordoptions.
>> >
>> > Since I haven't gotten past my first problem I can't confirm this works,
>> but
>> > it ought to.
>> >
>> >
>> > #3) Username / Password the only credential?
>> >
>> > I can also configure my subversion repository to use SSL client
>> > identification as a credential, instead of or along with user/name
>> password.
>> > I'm not doing this, but it would be an interesting thing for the TODO
>> list.
>> >
>> >
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
>>
>>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Eric Crahen-3
I just gave it a try and there was no trouble this time.

On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:

Thanks. I think I know what's going on.

Code that registers the protocol handler (the ones that understands http
https, svn, etc) needs to be registered before svnkit works
successfully, and yet I suspect it's not run at the right moment.

From looking at svnkit source code, it should understand your URL just
fine.

Continuous build #2124 should have a fix for this. If you can try that,
that would be really appreciated.

Eric Crahen wrote:

> I expanded the show details link and I got this,
>
>
> org.tmatesoft.svn.core.SVNException: svn: Unable to create
> SVNRepository object for 'https://myserver/svn/myproject'
>       at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error (SVNErrorManager.java:48)
>       at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java:194)
>       at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(SVNRepositoryFactory.java :143)
>       at hudson.scm.SubversionSCM$DescriptorImpl$1.check(SubversionSCM.java:597)
>       at hudson.util.FormFieldValidator.process(FormFieldValidator.java:33)
>       at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck (SubversionSCM.java:588)
>       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:597)
>       at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:50)
>       at org.kohsuke.stapler.MetaClass$1.doDispatch (MetaClass.java:59)
>       at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>       at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
>       at org.kohsuke.stapler.MetaClass$9.doDispatch (MetaClass.java:207)
>       at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:30)
>       at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
>       at org.kohsuke.stapler.Stapler.invoke (Stapler.java:169)
>       at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>       at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:491)
>       at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
>       at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
>       at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>       at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
>       at org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:391)
>       at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
>       at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java :114)
>       at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
>       at org.mortbay.jetty.Server.handle(Server.java:285)
>       at org.mortbay.jetty.HttpConnection.handleRequest (HttpConnection.java:457)
>       at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
>       at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
>       at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
>       at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
>       at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java :329)
>       at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
>
>
>
> On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>>
>>
>> Hi, I updated the issue 245. If you can try the latest snapshot and let
>> me know what error you get, that would be really helpful.
>>
>> Eric Crahen wrote:
>> > I have some questions on the new SVNKit integration.
>> >
>> > #1) Connection Error?
>> >
>> > I upgraded from using an external svn binary in hudson 1.6.8 , to hudson
>> > version 1.75 which uses SVNKit. When I create a new project and place my
>> svn
>> > url in the field, I an given the following error.
>> >
>> > "Unable to access http://myserver/svn/myproject : svn: Unable to create
>> > SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
>> > need to enter
>> > credential<
>> http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject
>> >
>> > ?)"
>> >
>> > I was previously able to access this URL with my external client. I'm
>> not
>> > sure what when wrong, I looked at stdout, I looked in my servlet
>> container
>> > logs and I checked the "Manage Hudson" system log and I did not find any
>> > output that would help me understand the error. There is no credential
>> > required to check out of this respository, anonymous access is perfectly
>> OK.
>> >
>> > What can I do to find the source of the error? Is there a way to make
>> the
>> > real error more obvious to the user? (I think SVNKit must have produced
>> some
>> > sort of useful error message we could use.)
>> >
>> > #2) Trust?
>> >
>> > Another thing I have a question about is how can I provide SVNKit with
>> the
>> > set of certificates I trust? My repository requires an SSL login in
>> order to
>> > perform updates, which I would want to do after the fact tagging. My
>> > repository uses a self-signed certificate which is not going to trusted
>> > without extra work. The way I told my svn binary to trust my servers
>> > certificate was by first using the user account I ran hudson as to do
>> an:
>> >
>> > svn https://myserver/svn/myproject
>> >
>> > This would cause the svn binary to prompt me that this server has a
>> > self-signed cert and asks me if I should trust it. I would select yes
>> > permanently and svn would save some info in ~/.subversion to say trust
>> this
>> > certificate. Later when I used hudson, I ran svn as the user and svn
>> > remebered to trust this server because of the data in ~/.subversion
>> >
>> > With the SVNKit integration, its not immediately obvious to me how to
>> > associate a trusted certificate with an SVN connection. I suppose one
>> method
>> > would be to manually create a jks trust store and run hudson with the
>> > correct -Djavax.net.ssl.trustStore, -
>> Djavax.net.ssl.trustStorePasswordoptions.
>> >
>> > Since I haven't gotten past my first problem I can't confirm this works,
>> but
>> > it ought to.
>> >
>> >
>> > #3) Username / Password the only credential?
>> >
>> > I can also configure my subversion repository to use SSL client
>> > identification as a credential, instead of or along with user/name
>> password.
>> > I'm not doing this, but it would be an interesting thing for the TODO
>> list.
>> >
>> >
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
>>
>>
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]





--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: SVNKit troubles in 1.75

Kohsuke Kawaguchi-2

Yay!

And thank you very much for your excellent turn-around time.

OK, time to release 1.76...

Eric Crahen wrote:

> I just gave it a try and there was no trouble this time.
>
> On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>>
>>
>> Thanks. I think I know what's going on.
>>
>> Code that registers the protocol handler (the ones that understands http
>> https, svn, etc) needs to be registered before svnkit works
>> successfully, and yet I suspect it's not run at the right moment.
>>
>> From looking at svnkit source code, it should understand your URL just
>> fine.
>>
>> Continuous build #2124 should have a fix for this. If you can try that,
>> that would be really appreciated.
>>
>> Eric Crahen wrote:
>> > I expanded the show details link and I got this,
>> >
>> >
>> > org.tmatesoft.svn.core.SVNException: svn: Unable to create
>> > SVNRepository object for 'https://myserver/svn/myproject'
>> >       at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(
>> SVNErrorManager.java:48)
>> >       at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(
>> SVNRepositoryFactory.java:194)
>> >       at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(
>> SVNRepositoryFactory.java:143)
>> >       at hudson.scm.SubversionSCM$DescriptorImpl$1.check(
>> SubversionSCM.java:597)
>> >       at hudson.util.FormFieldValidator.process(FormFieldValidator.java
>> :33)
>> >       at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(
>> SubversionSCM.java:588)
>> >       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:597)
>> >       at org.kohsuke.stapler.Function$InstanceFunction.invoke(
>> Function.java:50)
>> >       at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
>> >       at org.kohsuke.stapler.NameBasedDispatcher.dispatch(
>> NameBasedDispatcher.java:30)
>> >       at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
>> >       at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
>> >       at org.kohsuke.stapler.NameBasedDispatcher.dispatch(
>> NameBasedDispatcher.java:30)
>> >       at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
>> >       at org.kohsuke.stapler.Stapler.invoke(Stapler.java:169)
>> >       at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
>> >       at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> >       at org.mortbay.jetty.servlet.ServletHolder.handle(
>> ServletHolder.java:491)
>> >       at org.mortbay.jetty.servlet.ServletHandler.handle(
>> ServletHandler.java:367)
>> >       at org.mortbay.jetty.security.SecurityHandler.handle(
>> SecurityHandler.java:185)
>> >       at org.mortbay.jetty.servlet.SessionHandler.handle(
>> SessionHandler.java:181)
>> >       at org.mortbay.jetty.handler.ContextHandler.handle(
>> ContextHandler.java:689)
>> >       at org.mortbay.jetty.webapp.WebAppContext.handle(
>> WebAppContext.java:391)
>> >       at org.mortbay.jetty.handler.ContextHandlerCollection.handle(
>> ContextHandlerCollection.java:146)
>> >       at org.mortbay.jetty.handler.HandlerCollection.handle(
>> HandlerCollection.java:114)
>> >       at org.mortbay.jetty.handler.HandlerWrapper.handle(
>> HandlerWrapper.java:139)
>> >       at org.mortbay.jetty.Server.handle(Server.java:285)
>> >       at org.mortbay.jetty.HttpConnection.handleRequest(
>> HttpConnection.java:457)
>> >       at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
>> HttpConnection.java:751)
>> >       at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
>> >       at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java
>> :209)
>> >       at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java
>> :357)
>> >       at org.mortbay.io.nio.SelectChannelEndPoint.run(
>> SelectChannelEndPoint.java:329)
>> >       at org.mortbay.thread.BoundedThreadPool$PoolThread.run(
>> BoundedThreadPool.java:475)
>> >
>> >
>> >
>> > On 1/25/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>> >>
>> >>
>> >> Hi, I updated the issue 245. If you can try the latest snapshot and let
>> >> me know what error you get, that would be really helpful.
>> >>
>> >> Eric Crahen wrote:
>> >> > I have some questions on the new SVNKit integration.
>> >> >
>> >> > #1) Connection Error?
>> >> >
>> >> > I upgraded from using an external svn binary in hudson 1.6.8, to
>> hudson
>> >> > version 1.75 which uses SVNKit. When I create a new project and place
>> my
>> >> svn
>> >> > url in the field, I an given the following error.
>> >> >
>> >> > "Unable to access http://myserver/svn/myproject : svn: Unable to
>> create
>> >> > SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
>> >> > need to enter
>> >> > credential<
>> >>
>> http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject
>> >> >
>> >> > ?)"
>> >> >
>> >> > I was previously able to access this URL with my external client. I'm
>> >> not
>> >> > sure what when wrong, I looked at stdout, I looked in my servlet
>> >> container
>> >> > logs and I checked the "Manage Hudson" system log and I did not find
>> any
>> >> > output that would help me understand the error. There is no
>> credential
>> >> > required to check out of this respository, anonymous access is
>> perfectly
>> >> OK.
>> >> >
>> >> > What can I do to find the source of the error? Is there a way to make
>> >> the
>> >> > real error more obvious to the user? (I think SVNKit must have
>> produced
>> >> some
>> >> > sort of useful error message we could use.)
>> >> >
>> >> > #2) Trust?
>> >> >
>> >> > Another thing I have a question about is how can I provide SVNKit
>> with
>> >> the
>> >> > set of certificates I trust? My repository requires an SSL login in
>> >> order to
>> >> > perform updates, which I would want to do after the fact tagging. My
>> >> > repository uses a self-signed certificate which is not going to
>> trusted
>> >> > without extra work. The way I told my svn binary to trust my servers
>> >> > certificate was by first using the user account I ran hudson as to do
>> >> an:
>> >> >
>> >> > svn https://myserver/svn/myproject
>> >> >
>> >> > This would cause the svn binary to prompt me that this server has a
>> >> > self-signed cert and asks me if I should trust it. I would select yes
>> >> > permanently and svn would save some info in ~/.subversion to say
>> trust
>> >> this
>> >> > certificate. Later when I used hudson, I ran svn as the user and svn
>> >> > remebered to trust this server because of the data in ~/.subversion
>> >> >
>> >> > With the SVNKit integration, its not immediately obvious to me how to
>> >> > associate a trusted certificate with an SVN connection. I suppose one
>> >> method
>> >> > would be to manually create a jks trust store and run hudson with the
>> >> > correct -Djavax.net.ssl.trustStore, -
>> >> Djavax.net.ssl.trustStorePasswordoptions.
>> >> >
>> >> > Since I haven't gotten past my first problem I can't confirm this
>> works,
>> >> but
>> >> > it ought to.
>> >> >
>> >> >
>> >> > #3) Username / Password the only credential?
>> >> >
>> >> > I can also configure my subversion repository to use SSL client
>> >> > identification as a credential, instead of or along with user/name
>> >> password.
>> >> > I'm not doing this, but it would be an interesting thing for the TODO
>> >> list.
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Kohsuke Kawaguchi
>> >> Sun Microsystems                   [hidden email]
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
>>
>>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment