Solved [Solved] Is there a problem with the svn0-us-east mirror?

Today I tried to update my source tree (FreeBSD 9.2-p2) by using svn update but was surprised to see the following results:

Code:
root@smtp2:/usr/src # svn update
Updating '.':
svn: E120171: Unable to connect to a repository at URL 'https://svn0.us-east.freebsd.org/base/releng/9.2'
svn: E120171: Error running context: An error occurred during SSL communication
I quick investigation learned me that this site is using a self-signed certificate, but that has always been the case as far as I know. When trying to use the --trust-server-cert (together with --non-interactive) nothing changes; it keeps complaining about the error.

So then I tried a full check out (as test) using the EU mirror (svn0.eu.FreeBSD.org) and that works like a charm. As such I can only conclude that something weird is going on with the US East mirror.

Can anyone confirm this?
 
Re: Is there a problem with the svn0-us-east mirror?

Tried with a web browser just now and it worked. Maybe a temporary outage?
 
Re: Is there a problem with the svn0-us-east mirror?

It seems fine here (NYC), running svnlite co. I also went in with a web browser, and it seemed fine.
 
Re: Is there a problem with the svn0-us-east mirror?

Thanks for your quick responses guys, much appreciated.

I did some more testing in the mean time. This time I've also tried to check out a full source tree using my (only) Linux server and from there I can also simply perform the operation without any problems. Also using Lynx to access the repository works as expected (also on the server which is giving me this problem).

So then I tried the SVN protocol, that too works as expected and without problems. So it seems to be focussed around HTTPS. But because I can access other HTTPS repositories without incidents I'm now suspecting a cache of some sort. The only problem is that I can't find out where.

I did some more digging (somewhat literally ;)) and discovered that svn0.us-east.freebsd.org is actually an alias (CNAME) for svnmir.nyi.freebsd.org. So then I used this hostname to check out the source tree (to a new location) and that worked without incidents as well. So it's definitely not something related to the remote server itself.

But although I still suspect an issue with a cache of some sort I can't find it. Removing ~/.subversion for example hasn't helped, even though it had the self signed certificate stored in there.

So then I tried using ktrace to see if I could find something peculiar. Going over the dump file showed me a few things, for starters some files which it couldn't find, but those turned out to be non-issues because the program goes over several locations before it finds something. For example, while it can't find /usr/local/lib/libssl.so.6 it then later successfully finds /usr/lib/libssl.so.6.

And the weird thing is that it does seem to be making a connection:

Code:
 47632 svn      CALL  connect(0x5,0x80507adc0,0x10)
 47632 svn      STRU  struct sockaddr { AF_INET, 96.47.72.118:443 }
 47632 svn      RET   connect -1 errno 36 Operation now in progress
 47632 svn      CALL  gettimeofday(0x7fffffffcc80,0)
 47632 svn      RET   gettimeofday 0
 47632 svn      CALL  open(0x802b81b77,0x2<O_RDWR>,<unused>0)
 47632 svn      NAMI  "/dev/crypto"
 47632 svn      RET   open -1 errno 2 No such file or directory
 47632 svn      CALL  getpid
 47632 svn      RET   getpid 47632/0xba10
 47632 svn      CALL  getpid
 47632 svn      RET   getpid 47632/0xba10
 47632 svn      CALL  open(0x802b8dca1,0x8004<O_NONBLOCK|O_NOCTTY>,<unused>0)
 47632 svn      NAMI  "/dev/urandom"
 47632 svn      RET   open 6
 47632 svn      CALL  fstat(0x6,0x7fffffffc920)
 47632 svn      STRU  struct stat {dev=1895890688, ino=7, mode=crw-rw-rw- , nlink=1, uid=0, gid=0, rdev=7, atime=1390720230, stime=1389247804, ctime=1389247804, birthtime=-1, size=0, blksize=4096, blocks=0, flags=0x0 }
 47632 svn      RET   fstat 0
 47632 svn      CALL  select(0x7,0x7fffffffc8a0,0,0,0x7fffffffc890)
 47632 svn      RET   select 1
 47632 svn      CALL  read(0x6,0x7fffffffca90,0x20)
 47632 svn      GIO   fd 6 read 32 bytes
       0x0000 b351 0337 0498 5c52 80df 0579 ef04 186d  |.Q.7..\R...y...m|
       0x0010 5249 1434 f017 7cd1 2869 0109 9112 8d3c  |RI.4..|.(i.....<|
 47632 svn      RET   read 32/0x20
 47632 svn      CALL  close(0x6)
 47632 svn      RET   close 0
 47632 svn      CALL  getuid
 47632 svn      RET   getuid 0
 47632 svn      CALL  clock_gettime(0xd,0x7fffffffc848)
 47632 svn      RET   clock_gettime 0
 47632 svn      CALL  getpid
 47632 svn      RET   getpid 47632/0xba10
 47632 svn      CALL  getpid
 47632 svn      RET   getpid 47632/0xba10
 47632 svn      CALL  open(0x802b8d91b,0<O_RDONLY>,<unused>0x1b6)
 47632 svn      NAMI  "/etc/ssl/cert.pem"
 47632 svn      RET   open 6
 47632 svn      CALL  fstat(0x6,0x7fffffffc7b8)
 47632 svn      STRU  struct stat {dev=66817305, ino=85093, mode=-r--r--r-- , nlink=1, uid=0, gid=0, rdev=4294967295, atime=1390719891.659185904, stime=1387304372, ctime=1387304373.788019529, birthtime=1387304373.778021937, size=836933, blksize=131072, blocks=1797, flags=0x0 }
 47632 svn      RET   fstat 0
 47632 svn      CALL  read(0x6,0x80525f000,0x20000)
 47632 svn      GIO   fd 6 read 4096 bytes
       "##
        ##  ca-root-nss.crt -- Bundle of CA Root Certificates
After it has read /etc/ssl/cert.pem it then tries to write some data to /usr/src92/.svn/wc.db after which it quits with the error mentioned above. A very peculiar issue (to me at least).
 
Re: Is there a problem with the svn0-us-east mirror?

Well, I couldn't bother with this any longer. Especially since it's obviously not something related to the remote server but something on my system. Perhaps some of my security settings are tight enough for Subversion not to be able to accept a changed certificate, I honestly don't know.

I fixed the issue by changing the protocol from https to svn as follows: # svn switch --relocate [url=https://svn0.us-east.freebsd.org/base/releng/9.2]https://svn0.us-east.freebsd.org/base/releng/9.2[/url] [url=svn://svn0.us-east.freebsd.org/base/releng/9.2]svn://svn0.us-east.freebsd.org/base/releng/9.2[/url], then I continued with the update ( # svn update) and now my source tree sits at revision 260647 or better put: I now got FreeBSD 9.2-p3 ready for setting up (which has some important updates).

Because I also care for encryption "just in case" I eventually changed the mirror to the EU one, something I probably should have done sooner anyway. So after the command above and updating my source I then used this command: # svn switch --relocate [url=svn://svn0.us-east.freebsd.org/base/releng/9.2]svn://svn0.us-east.freebsd.org/base/releng/9.2[/url] [url=https://svn0.eu.freebsd.org/base/releng/9.2]https://svn0.eu.freebsd.org/base/releng/9.2[/url].

So now I'm ready to rebuild the world and my kernel again :)
 
Re: [Solved] Is there a problem with the svn0-us-east mirror

Just as an additional data point...

I have been seeing the exact same problem here since at least Friday on more than a dozen stable/8 systems that use the svn0-us-east mirror. Things work if I switch to using the svn0-us-west mirror. This also happened on a newly installed 8.4-RELEASE system that had subversion compiled/installed from ports.

Cheers,

Scott
 
Re: [Solved] Is there a problem with the svn0-us-east mirror

There's definitely a problem here. During the week of the 13th I installed a dozen systems with the same setup script which uses svn0.us-east to get /usr/src with no problem. Suddenly this week it's not working. These are all new 9.2-RELEASE systems that have simply done a freebsd-update to get up to 9.2-RELEASE-p3, and build subversion from a portsnap'd ports tree.

I can use us-west as a workaround, but I don't consider that "solved." It's a workaround.
 
Re: [Solved] Is there a problem with the svn0-us-east mirror

If you can repeat the problem, please enter a PR. Then post a link to it here so that others don't duplicate it.
 
Re: [Solved] Is there a problem with the svn0-us-east mirror

The problem is now fixed, although I'm still hoping to get an explanation (in the PR) of what the problem was.
 
Back
Top