Svn error running context

HI,

I need to access a SVN repository that has an https:// url (not SSH). When I try to access it, I get:

svn: E120171: Unable to connect to a repository at URL 'https://xxxxxxxxx/trunk'
svn: E120171: Error running context: An error occurred during SSL communication

The URL is right, it works with other systems and I even copied a working repository from another machine and did «update».

I think it is failing to get WebDAV support? The

serf

library is installed. I have:

serf-1.3.2_1        Serf HTTP client library
subversion-1.8.5    Version control system

What could be missing?

neon

? Does

subversion

have options in the build?

Thanks.

That the required library is installed on your system isn’t proof that Subversion is actually using it

Which brings me to the important question here: how did you install Subversion on this machine? And also; which version of FreeBSD are you using?

The most common way to determine if Subversion is up to the challenge is to use this command: # make -C /usr/ports/devel/subversion showconfig. That should at least list the following line:

     SERF=on: WebDAV/Delta-V (HTTP/HTTPS) repo access module

However, if you installed Subversion using binary packages then my guess is that it doesn’t support this feature. I’m not sure because I don’t use binary packages myself, but I do know that they often don’t provide the full amount of features.

Hi,

I am running FreeBSD 9.2-RELEASE. Packages are installed by compiling from current ports, updated as today with

portsnap

. My configuration is as follows:

     BDB=off: Berkeley DB support
     DOCS=on: Build and/or install documentation
     FREEBSD_TEMPLATE=on: FreeBSD Project log template
     GNOME_KEYRING=off: Build with GNOME Keyring auth support
     KDE_KWALLET=off: Build with KDE KWallet auth support
     MAINTAINER_DEBUG=off: Build debug version
     MOD_DAV_SVN=off: mod_dav_svn module for Apache 2.X
     NLS=on: Native Language Support
     P4_STYLE_MARKERS=on: Perforce-style conflict markers
     SASL=off: SASL support
     SERF=on: WebDAV/Delta-V (HTTP/HTTPS) repo access module
     STATIC=off: Build static version (no shared libs)
     SVNSERVE_WRAPPER=off: Enable svnserve wrapper (umask setter)
     TEST=off: Run subversion test suite
     TOOLS=off: Install several tools (svnauthz-validate and mod_dontdothat are among them)

Serf itself has no meaningful configuration. Which tells me the SERF module should be there, thus I wonder even more why it is not working.

Thanks.

It is not a firewall problem. It works from the same place, from a computer in the same subnet using HTTPS with other OSs (I got it to work con NetBSD, OpenBSD, Linux and even

mingw

!).

Then my guess is that something went wrong somewhere in the past with the upgrade of some of your ports. This is an assumption mind you, but some of the Subversion dependencies required specific steps to upgrade:

root@smtp2:/usr/ports/devel/subversion # make run-depends-list
/usr/ports/databases/db42
/usr/ports/databases/sqlite3
/usr/ports/devel/apr1
/usr/ports/devel/gettext
/usr/ports/textproc/expat2
/usr/ports/www/serf
root@smtp2:/usr/ports/devel/subversion # make -C ../../www/serf run-depends-list
/usr/ports/devel/apr1

And when looking at

devel/apr1

in

/usr/ports/UPDATING

:

20130706:                                                                         AFFECTS: users of devel/apr1
  AUTHOR: ohauer@FreeBSD.org

  APR was updated to 1.4.8 and APR-util was updated to 1.5.2.

  Please rebuild all ports which are using functions from APR/APR-util
  such as Apache, Subversion, etc.

  # portmaster -r apr
    or
  # portupgrade -r devel/apr1
    or
  # pkg install -fR devel/apr1

Note that I’m not claiming that

devel/apr1

is the cause of all this, but it is most certainly a very reasonable assumption. Because this port provides HTTPS support for several other programs (like

www/apache22

for example).

As such my question: how well have you been paying attention to

/usr/ports/UPDATING

as of late?

When all else fails my suggestion, though it is a bit drastic, would be to enforce a rebuild of Subversion and everything it depends on. So basically using a command such as this: # portmaster -f devel/subversion.

However, if you haven’t been following the instructions which I quoted above then that would be a better approach. Because that will also rule out any issues which other ports might run into.

multix said:

The repository works HTTPS only, sadly. I use SVN successfully with other repositories which have SSH. Firewall, like what? I don’t have installed anything willingly on my laptop. Perhaps it is there and I don’t know… does it come from base? I didn’t install anything explicitly from ports.

Does this mean that you have successfully connected to these «other repositories» from this laptop? If the answer is yes, then I would suspect you might be dealing with an SSL certificate problem.

Well, since I had problems with

seamonkey

crashing, I removed with pkg_delete ALL packages, I removed

/usr/local

,

/var/db/pkg

and

/var/db/ports

and reinstalled everything from scratch, thus the current

subversion

client is clean (

seamonkey

is still building, as it apparently pulls in whole

gcc

4.6)

SVN wasn’t working before, but isn’t yet either, but it is a clean build and shouldn’t be an upgrade problem.

ljboiler said:

Does this mean that you have successfully connected to these «other repositories» from this laptop? If the answer is yes, then I would suspect you might be dealing with a SSL certificate problem.

The certificate is most certainly self-signed. On other OS’s I get asked if I want to permanently accept it and then if I want to save my password.
I

Then I can think of only one option to determine what is happening here. Install

www/lynx

and be sure to enable support for SSL. Then use

lynx

to access the HTTPS URL. If that also fails then the cause of the problem isn’t so much Subversion but lies elsewhere.

Thanks for the support, investigation is continuing.

1. I don’t have ipfwor pf enabled in /etc/rc.conf, checked.
2. I was able to connect to the repository using Seamonkey, this means that 1) is confirmed and the problem is on the svnside.

Before connecting though, Seamonkey asked to add the certificate with a security exception (it is self-signed, I suppose, internal server). Perhaps SVN needs a way to do that too? On other systems I got asked about the certificate and if to accept it permanently, on FreeBSD not. Perhaps there is a configuration to change somewhere, a different default?

wblock@ said:

If svn does not already know the server’s certificate, it will prompt as shown in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn-mirrors.html. If accepted permanently, that information is stored in

~/.subversion

. Maybe that directory is not readable or writable for the user?

It is. I touched a file inside and I can do that. Everything is correctly user:group owned. Could it be possible that for some reason SVN is not using or detecting the module I need? Is there a command to print out at runtime? That would also allow me to check against Linux and NetBSD where I have it working.

multix said:

Before connecting though, Seamonkey asked to add the certificate with a security exception (it is self-signed, I suppose, internal server).

Now we’re getting somewhere!

This does indeed put the focus completely on Subversion and it’s apparent inability to use the HTTP protocol. First of all; there is more to the

~/.subversion

directory than merely the entry itself. Start by checking if there are any entries in the

~/.subversion/auth/svn.ssl.server

directory (where

~

is of course an alias for your home directory).

Be sure to check the right directory I’m just mentioning this because I started to check my personal home directory for this message (

~peter

) while in fact I should have been looking at

/root/.subversion

instead .

If there are any entries there: remove them and try again.

But at this stage I think your best option to get rid of this problem is to rebuild Subversion and the ports it depends on, as I already mentioned in an earlier message.