Troubleshooting
Use this Go community space to get help troubleshooting any product related issues.
Post
SVN https authentication
Post posted August 1, 2008 by Bil Simser
4035 Views, 5 Comment
Topic:
SVN https authentication
Body:
Getting a little further with setup. Dont’ know what the previous error is but when I restart the cruise sevice, it takes a few minutes before I can bring up the console in the browser. Trying to create a new pipeline that simply checks the code out and compiles. In the setup of the project I have subversion setup and it verified itself. The cruise service is running under a domain account and I’ve previously used that account in command line mode to connect to SVN and do a SVN action that would bring down the token authentication (we access SVN via HTTPS but not using integrated authentication). So a) I’ve run “svn list https://server/project/trunk” under the same domain account that cruise is running under (I had to do this for Mingle/JIRA to work). b) the project when setup in cruise allowed me to enter the url to the subversion repository and even verified it. c) Subversion access is working as the pipeline picked up the last change and has displayed the log message. I have a stage setup called code-compilation with a job called compile that is supposed to invoke nant with a target after getting the code from svn. Here’s the error message when my first pipeline tries to run:java.lang.RuntimeException: org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication required for ‘<https://server:8443>‘ Not sure who it is that the authentication is needed for?
Comment
Cruise ships with an embedded SVN client. So it doesn’t use the authentication of the user account that is running the cruise server. You need to add valid account information (in the <materials /> definition of the pipeline in the administration tab.
The configuration reference for svn is here
chris
@Chris: I have this already in my svn section:
<svn username="cruise" url="https://server:8443/svn/project/trunk/" password="cruise" />The problem is that “cruise” isn’t a machine account, it’s a svn account so I can’t login and store any credentials. The service is running under a domain account which I can login as. Not sure how to resolve this?
Hi Bill,
It seems that the authentication information of your svn server is not cached correctly on the agent box. Can you please try the following steps and let us know how it goes?
- Log into the agent box using the same domain account that cruise agent runs under
- Make sure svn does cache authentication information on your agent box by double checking a file named config under /Documents and Settings/<the runs under username domain that agent cruise>/Application Data/subversion/. Make sure store-auth-creds is set to yes.
- Connect to svn server via svn command. If there is a prompt to accept the certification from svn server, accept it permanently so that the authentication information is cached locally
- Double check your local cache by opening auth/svn.ssl.server folder. By default the certificates are encryped so you need to open each file under that folder, look for the target url of your svn server under the bottom of the file. It should appear in one of the files.
- Once you are done with the above, try to trigger a build. Cruise agent should be able to authenticate itself against the remote svn server.
This is due to a bug in one of the library that we use. We are planning to remove that dependency in the near future so you won’t run into this situation again.
Please don’t hesitate to let us know how this goes.
Derek
@Derek
I went through the steps you mentioned. By default (at least according to the config file) store-auth-creds is defaulted to yes. I changed the file to be explicit.
The cache contained certificates for my svn server url so that was fine.
Still fails with the authorization message.
I’ll maybe come back to this another day, I’ve already spent too much time trying to get it running in our environment now and have no success. Maybe I’ll try to get a sandbox running in isolation, but that’s really not going to help me much.
Thanks.
FWIW, after talking to Bobby it seems https with subversion is a problem for Cruise. We’ve switched over to http so it works fine now.