Monday, August 24, 2009

Redmine with Subversion 1.6

Recently I updated SVN client to 1.6.x from 1.5.x on the machine where Redmine was installed. After this change Redmine stopped fetching further revisions from SVN repositories for existing projects and for new projects it was showing following error message on 'Repository' tab-

The entry or revision was not found in the repository.
In Redmine log file I could not find any worthwhile information. There was just one liner-
Completed in 0.34931 (2 reqs/sec) | Rendering: 0.01537 (4%) | DB: 0.01871 (5%) | 500 Internal Server Error [http://myhost/redmine/repositories/show/myproject]
Then I looked inside Apache (Redmine was fronted by Apache + Passenger) error log file, it had error messages like given below-

    -----------------------------------------------------------------------
    ATTENTION!  Your password for authentication realm:

      <http://serverIP:80=""> My SVN

    can only be stored to disk unencrypted!  You are advised to configure
    your system so that Subversion can store passwords encrypted, if
    possible.  See the documentation for details.

    You can avoid future appearances of this warning by setting the value
    of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
    '/home/appsupport/.subversion/servers'.
    -----------------------------------------------------------------------
    Store password unencrypted (yes/no)? svn: Can't read stdin: End of file found


So svn client was asking whether to save the password or not and there was no one to answer that question, leading to abortion of the operation. Uncommenting following two lines in ~/.subversion/config file-
store-passwords = no
store-auth-creds = no
resolved this issue.

Saturday, August 15, 2009

Hudson: svn authentication cancelled

The Hudson was building all projects without any issues since it was installed. All of a sudden yesterday my inbox was filled with failure reports, Hudson was not able to build any of the projects. Logs were having stacktrace like mentioned below-

ERROR: svn: authentication cancelled
org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
    at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:200)
    at hudson.scm.FilterSVNAuthenticationManager.getNextAuthentication(FilterSVNAuthenticationManager.java:42)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:537)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273)
    at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)
    at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:97)
    at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1686)
    at hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1826)
    at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:506)
    at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:469)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:898)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:391)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:340)
    at hudson.model.Run.run(Run.java:1090)
    at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:301)
    at hudson.model.ResourceController.execute(ResourceController.java:93)
    at hudson.model.Executor.run(Executor.java:122)
Skipping sonar analysis due to bad build status FAILURE
Finished: FAILURE


The stack trace talks about authentication cancellation not failure, which is quite strange. I still thought that it might be an authentication failure and tried to authenticate against SVN server using same credentials as used by Hudson. Authentication was successful using various methods (browser, command line client, TortoiseSVN). Google search did not provided any relevant information and I was running out of clues :-(

After putting lots of pondering I remembered that day before I did a manual (from console) project checkout on the same machine and during checkout svn client (1.6.4) asked to save the password and I said 'no'. Will that make any difference? I think it should not.

Just for the sake of trial I deleted the '~/.subversion' directory and did a Hudson build after that. Now Hudson was able to do SVN checkout/update and build project. After several trials, I concluded that if password is not saved during manual checkout, Hudson will fail with above-mentioned error. Though it will wok fine if password was saved. Another observation was that Hudson SVN client (SVNKit 1.3.0) does not create '~/.subversion/auth', while 'svn' command does, irrespective of one chooses to save the password or not.

Though I do not know why Hudson (SVNKit) cancels the SVN authentication but removing the '~/.subversion' directory solves the issue.

Tuesday, July 29, 2008

SVN with Apache + LDAP

We have been using CVS at work for long, though personally I am a big fan of SVN. Lately we thought to catch up with the SVN buzz and I was asked to have a Proof Of Concept before we officially move to SVN. Installation of SVN with Apache was pretty straightforward. Though LDAP integration was also simpler but at times it failed without any obvious reasons. Here are the steps for the entire process on Windows XP-

1. Install Apache 2.2.
2. Install SVN 1.5 by unzipping the distribution.
3. Add SVN\bin folder to PATH.
4. Copy mod_dav_svn.so to modules directory of Apache.
5. Add following line in Apache conf file-
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so

# Following are required for LDAP authentication
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule ldap_module modules/mod_ldap.so

6. Download [svnindex.css and svnindex.xsl] from http://svn.collab.net/repos/svn/trunk/tools/xslt/
and put them in 'htdocs' folder of Apache. This will do nice listing of SVN contents.

7. Add the repository location in http conf file, this will have LDAP auth as well

#Location of repository
<Location>
DAV svn

SVNParentPath C:\svn
SVNListParentPath on
SVNIndexXSLT "/svnindex.xsl"

AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthName "My SVN Setup"
AuthLDAPURL ldap://host:3268/dc=X,dc=Y?sAMAccountName?sub?(objectClass=user) NONE
AuthLDAPBindDN myUserID
AuthLDAPBindPassword myPassword
Require valid-user
</Location>

7. Run 'httpd' command from Apache

VOILA! YOU ARE DONE

I gave it a try on Fedora 4 as well, which comes with Apache 2.2 and SVN 1.4 pre-installed. Only thing that was missing was there 'mod_dav_svn'. Getting that to with YUM is pretty simple, just do-
yum install mod_dav_svn

Here we were using Active Directory as our LDAP server. Initially I used the port 389 in the AUthLDAPURL shown above and it worked fine for first 2 weeks but after that it failed without any obvious reasons with this error message in Apache log files-
[ldap_search_ext_s() for user failed][Operations Error]

It made it to work for brief periods by re-starting the Apache. Re-starting is not an option in production. After googling for some time I found suggestions to use port 3268 instead of 389. More than 2 weeks has been passed since I switched to port 3268 and it is working fine till date :-)

My next step will be to convert some CVS repositories to SVN. Will update soon about the results of this conversion.