SVN - HTTPS support not working

multix

multix

HI,

I need to access a SVN repository that has an https:// url (not SSH). When I try to access it, I get:
Code: 
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:
Code: 
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:

Code: 
     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:
Code: 
     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.
 
multix said:
HI,

I need to access a SVN repository that has an https:// url (not SSH). When I try to access it, I get:
Code: 
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".
Click to expand...

That may not be an HTTPS problem. It could caused by a firewall on the local or remote machine, or some other connection problem. If the repository supports it, try svn:// to see if the same error occurs.
 
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!).
 
It could be a firewall on the FreeBSD client itself. If it the plain svn:// works, it would verify that the problem is with HTTPS.
 
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.
 
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:

Code: 
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:

Code: 
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.
Click to expand...

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.
Click to expand...

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.
 
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.
Click to expand...

ipfw(8) and pf are installed by default, and can be enabled with a single setting in /etc/rc.conf. (It doesn't happen often, but sometimes.)

How about using an HTTPS-capable browser on the FreeBSD client to connect to the repository? www/lynx can do it if a graphical browser is not available.
 
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?
Click to expand...
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).
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top