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

Re: Svnsync with changed url and ssl certificate?

From: Ryan Schmidt <subversion-2019_at_ryandesign.com>
Date: Thu, 8 Aug 2019 12:24:35 -0500

On Aug 7, 2019, at 00:52, Bo Berglund wrote:

> I have a svn 1.9.7 system to maintain.
> The main server (on Windows Server 2016) is backed up using svnsync over the Internet to a backup server set up on Ubuntu Server 18 LTS.
> The backups are done using a batch file running once every night on the main server.
> Each repository is synced using a command line in the batch file as in the following example:
>
> SET SYNCCMD="C:\Program Files\VisualSVN Server\bin\svnsync.exe"
> %SYNCCMD% synchronize https://home.backupdomain.com/svn/cmp https://mainserver/svn/cmp
>
> (backupdomain and mainserver are placeholders for the real names)
>
> Now I am planning to change the domain part of the URL of the backup server to svn.backupdomain.com and also to change the SSL certificate on the server to a signed version (currently it is self-signed).
>
> My question is if the svnsync command will handle this without problems given that the source and target svn servers are the same as before, only the domain name and SSL certificate have changed.
> Obviously I have to edit the sync batch file on the server and replace "home" with "svn", but apart from that do I have to add/do something else? Does the SSL certificate change influence things?
>
> Note that each repository on the live server was initialized for sync using this command:
>
> svnsync initialize https://home.backupdomain.com/svn/<reponame> https://mainserver/svn/<reponame> --allow-non-empty --sync-username syncuser --sync-password [*****************]
>
> This indicates that the sync is initialized in each repo using the URL of the target, so can I just run this command again manually on all repos to change to the new URL?
>
> I don't want to use trial and error on a production system, hence my question.

Hi Bo,

Since you're using a self-signed certificate on the backup server, you presumably told the primary server at some point to accept that certificate. If you change the backup server's certificate to one that is not self-signed, for example one issued by Let's Encrypt using certbot, then as far as I know you won't need to change anything on the primary server; it should be able to verify the new certificate using the usual methods.

As far as I know, `svnsync initialize` should only be used in the initial setup; you shouldn't use it again now that the link between the master repo and its mirror has already been set up.

`svnsync initialize` records some revision properties in the mirror repository's 0th revision, so that the mirror knows what repository it's syncing from. As far as I know, the master does not keep any record of the fact that it is being mirrored. (You could even have multiple mirrors of a single master.) So the master repo does not care if you change the URL of the mirror repo(s).

If it were the other way around -- if the URL of the master had changed -- then you would want to go to each mirror and edit the svn:sync-from-url property of the mirror's 0th revision, just for the sake of good housekeeping. But that URL is only used if you are doing the sync while on the backup server and you haven't specified a master URL on the command line. It doesn't apply in your case since you're doing the sync on the master server. So all you should need to change is the URL of the backup server in the batch file on the server.

Subversion keeps track of repository identities not using URLs (since URLs can change, and since you could even have multiple URLs that refer to a single repository) but using UUIDs which are assigned at repository creation time. Since the UUIDs of the master and the mirror aren't changing there shouldn't be a problem.
Received on 2019-08-08 19:24:51 CEST

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.