-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2019_at_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.
Received on 2019-08-08 23:12:43 CEST