[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Troubleshooting Subversion

From: Eric Lemings <lemings_at_roguewave.com>
Date: 2007-04-23 18:10:39 CEST

Greetings,

I was wondering if there is a step-by-step troubleshooting guide for
Subversion. The closest I've found is a random set of troubleshooting
FAQs on the Subversion web site and in the appedices of the Subversion
book and surprisingly :P none of them address my problem.

Like many others, I'm having problems remotely accessing my Subversion
server. Whenever I try to connect, I get permission errors like this
(details edited for anonymity):

        [user@remote ~]$ svn --username myname list
https://www.server.com/svn
        Error validating server certificate for
'https://www.server.com:443':
         - The certificate is not issued by a trusted authority. Use the
           fingerprint to validate the certificate manually!
        Certificate information:
         - Hostname: www.server.com
         - Valid: from Apr 17 21:52:19 2007 GMT until Apr 16 21:52:19
2008 GMT
         - Issuer: deptName, orgName, City, State, US
         - Fingerprint:
aa:bb:cc:dd:ee:ff:gg:hh:ii:jj:kk:ll:mm:nn:oo:pp:qq:rr:ss:tt
        (R)eject, accept (t)emporarily or accept (p)ermanently? t
        svn: PROPFIND request failed on '/svn'
        svn: PROPFIND of '/svn': 403 Forbidden (https://www.server.com)

As you can see, I've set up my Subversion server using Apache over HTTPS
from the packages distributed with Fedora Core 5. When run locally as
root
however, the command works:

        [root_at_server ~]# svn list file:///var/www/html/svn
        proj1/
        proj2/
        proj3/

Configuration files are shown below.

/etc/httpd/conf.d/subversion.conf files:
        LoadModule dav_svn_module modules/mod_dav_svn.so
        LoadModule authz_svn_module modules/mod_authz_svn.so

        #
        # Example configuration to enable HTTP access for a directory
        # containing Subversion repositories, "/var/www/svn". Each
repository
        # must be readable and writable by the 'apache' user. Note that
if
        # SELinux is enabled, the repositories must be labelled with a
context
        # which httpd can write to; this will happen by default for
        # directories created in /var/www. Use "restorecon -R
/var/www/svn"
        # to label the repositories if upgrading from a previous
release.
        #

        #
        # To create a new repository "http://localhost/repos/stuff"
using
        # this configuration, run as root:
        #
        # # cd /var/www/svn
        # # svnadmin create stuff
        # # chown -R apache.apache stuff
        #

        <Location /svn>
           DAV svn
           SVNParentPath /var/www/html/svn
           SSLRequireSSL

           # our access control policy
           AuthzSVNAccessFile /var/www/html/svn/conf/authz

           # only authenticated users may access the repository
           Require valid-user

           # how to authenticate a user
           AuthType Basic
           AuthName "Subversion Repository"
           AuthUserFile /var/www/html/svn/conf/htpasswd
        </Location>

/var/www/html/svn/conf/authz:
        ### This file is an example authorization file for svnserve.
        ### Its format is identical to that of mod_authz_svn
authorization
        ### files.
        ### As shown below each section defines authorizations for the
path and
        ### (optional) repository specified by the section name.
        ### The authorizations follow. An authorization line can refer
to a
        ### single user, to a group of users defined in a special
[groups]
        ### section, or to anyone using the '*' wildcard. Each
definition can
        ### grant read ('r') access, read-write ('rw') access, or no
access
        ### ('').

        [groups]
        develop = user1 user2

        [/]
        * = rw

/var/www/html/svn/conf/htpasswd:
        user1:AF(U(SDG&(*Y#RKL@#J%)@#(%RUOKLJDT)af1
        user2:SDLFKJSD)F(*)(U@#$%RKJLKSJDF_(*SDG:LK

Errors messages in the Apache log files could be greatly improved also.
They only give generic clues about the problem rather than specifics
(e.g. filenames, directives, etc.) Not exactly sure where these fairly
useless messages are coming from though.

Any help greatly appreciated.

Eric.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 23 18:11:34 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.