Svnsync with changed url and ssl certificate?

[Bo Berglund <bo...@gmail.com>]

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.

Best Regards, 

Bo Berglund 
email: bo.berglund@gmail.com

RE: Svnsync with changed url and ssl certificate?

[Bo Berglund <bo...@gmail.com>]

On Sun, 11 Aug 2019 22:21:24 -0500, Ryan Schmidt <su...@ryandesign.com> wrote:

>> svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
>> svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
>> svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
>> Only the syncuser user may change revision properties
>> 
>> How can I force a different svnsync user than the one apparently erroneously cached 
>> somewhere when I test svnsync on the command line?
>
> Ah yes. You must've told Subversion to save the username and password when you first set it up. 
> Saved passwords are saved not by UUID but by URL, since it is possible for an administrator to 
> set up different authentication for different URLs, even if they go to the same repository.
>
> So, on the repository server where you run the batch script, you need to log in as (or use 
> whatever the Windows equivalent of "sudo" is to temporarily become) whatever operating system 
> user runs your svnsync batch script, and then, as that user, run svnsync or the batch script. 
> It should prompt you for the password and maybe the username, which you can enter, and tell 
> it to save, which it should then save, and which svnsync, when run automatically via the batch 
> script as that user in the future, should be able to read and use.
>

Thanks, I ended up doíng this to clean up the mess I created by misinterpreting the prompts
when I tried to run the svnsync command manually:

I added the --sync-username parameter to the command to force the correct username:

svnsync synchronize --sync-username syncuser https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse

I then ran this command manually and was prompted for the password of user "syncuser" after which 
it completed successfully.

Then I made a small change to a file, committed it and waited for the automated sync to run via Windows scheduler.
This revision was successfully backed up via the nightly batch file so I think I am good now!

Thanks again for your help!

--
Bo Berglund

Re: Svnsync with changed url and ssl certificate?

[Ryan Schmidt <su...@ryandesign.com>]

On Aug 11, 2019, at 03:30, Bo Berglund wrote:

> H:\>svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
> Authentication realm: <https://svn.xxxxxxxx.com:443> Subversion Repository
> Password for 'Bosse': *********
> Authentication realm: <https://svn.xxxxxxxx.com:443> Subversion Repository
> Username: bosse
> Password for 'bosse': *********
> svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
> svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
> Only the syncuser user may change revision properties
> 
> "syncuser" is the synchronization user I have created on the backup server to write to the repo (it is otherwise read only).
> It has been put into the master server as the sync user during initialization of svnsync.
> It is the only backup server user with write permissions.
> 
> So I tried to repeat the command and planned to enter "syncuser" at the second login prompt, 
> but this time the prompts did not re-appear so I got the error message directly:
> 
> svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
> svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
> svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
> Only the syncuser user may change revision properties
> 
> How can I force a different svnsync user than the one apparently erroneously cached somewhere when I test svnsync on the command line?

Ah yes. You must've told Subversion to save the username and password when you first set it up. Saved passwords are saved not by UUID but by URL, since it is possible for an administrator to set up different authentication for different URLs, even if they go to the same repository.

So, on the repository server where you run the batch script, you need to log in as (or use whatever the Windows equivalent of "sudo" is to temporarily become) whatever operating system user runs your svnsync batch script, and then, as that user, run svnsync or the batch script. It should prompt you for the password and maybe the username, which you can enter, and tell it to save, which it should then save, and which svnsync, when run automatically via the batch script as that user in the future, should be able to read and use.

RE: Svnsync with changed url and ssl certificate?

[Bo Berglund <bo...@gmail.com>]

On Thu, 8 Aug 2019 23:12:22 +0200, "Bo Berglund" <bo...@gmail.com> wrote:

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

UPDATE:
So now I have used certbot on the backup server to get a certificate covering the new svn.xxxx domain address.
Installed it into Apache by editing the sites-available/default-ssl.conf file where the self-signed cert was defined.
I used the full path to the /etc/letsencrypt/live folder where the cert was placed.

After reloading apache2 everything seemed to work, like accessing the web interface of the repositories
both from my local PC and from across the world where the production server is located.
The padlock symbol which was previously marked as insecure is now green!

I could check out a wc of a project from the backup server on the master server using the command line.

BUT! Now svnsync has stopped working.....
I have edited the batch file that runs the backup process and replaced the subdomain "home" with "svn"
in all svnsync calls.
It should have updated the backup server with a single revision on a test project overnight but it did not.
And when I look at the log file from the sync batch file it shows it to still be running hours afterwards.
Normally it takes less than 30 min to complete depending on the number of changes to handle.
Maybe it is waiting for some user input?

So I looked at TaskManager and found svnsync to still be in a running state. Used TaskManager to end it.
Then on a command line on the main server I issued the command at the top of the batch file to see what could have gone wrong.
This is what I see:

H:\>svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
Authentication realm: <https://svn.xxxxxxxx.com:443> Subversion Repository
Password for 'Bosse': *********
Authentication realm: <https://svn.xxxxxxxx.com:443> Subversion Repository
Username: bosse
Password for 'bosse': *********
svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
Only the syncuser user may change revision properties

"syncuser" is the synchronization user I have created on the backup server to write to the repo (it is otherwise read only).
It has been put into the master server as the sync user during initialization of svnsync.
It is the only backup server user with write permissions.

So I tried to repeat the command and planned to enter "syncuser" at the second login prompt, 
but this time the prompts did not re-appear so I got the error message directly:

svnsync synchronize https://svn.xxxxxxxx.com/svn/bosse https://engineering/svn/bosse
svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0':
svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output:
Only the syncuser user may change revision properties

How can I force a different svnsync user than the one apparently erroneously cached somewhere when I test svnsync on the command line?

Any other suggestions?

RE: Svnsync with changed url and ssl certificate?

[Bo Berglund <bo...@gmail.com>]

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2019@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.

Re: Svnsync with changed url and ssl certificate?

[Ryan Schmidt <su...@ryandesign.com>]

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.