-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] 
Sent: den 8 augusti 2019 19:25
To: Bo Berglund
Cc: Subversion Users
Subject: Re: Svnsync with changed url and ssl certificate?



>> 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.

Thanks a lot for your explanation!
It makes things much easier.
I have created and configured the svn domain with ddcli set up to manage the IP 
updates now.
My initial test on the backup server shows that it connects properly from a 
browser even using the new
domain name (same IP address).

So I am probably good to go as soon as I have figured out how to obtain a 
signed cert via certbot
without first having to open up the site to port 80 (http://) access...
I had to do that when I used certbot for my other site on the same server. 
During certbot's process
it seems to need access via port 80 to validate the site location.
And I don't want to open it even for a very short time...

But this is of course not a subversion problem, rather a certbot and apache one.

Reply via email to