Breaking svnsync mirrors

[Grierson, David (Lead Engineer)]

Hi,

We're in the process of migrating & upgrading our Subversion installation. In 
doing so we're encountering a handful of repos which were impacted by issue 
4129 (https://subversion.apache.org/docs/issue4129).

The fix for this (to dump & reload) has been successful with most of the repos, 
however to do this you need to have sufficient storage to duplicate the repos; 
and one of the repos in question is over 700GB in size!

As an alternative, I'm looking to use svnsync to fix this repository; I'm just 
looking to clarify the process for completing this.

On new host:
  1) svnadmin create /path/to/new-repo
  2) Create /path/to/new-repo/pre-revprop-change hook
  3) svnsync init file:///path/to/new-repo https://url/to/old-repo
  4) svnsync sync file:///path/to/new-repo

Allow the data to copy across ... then ...
  5) svnsync copy-revprops --skip-unchanged file:///path/to/new-repo

At this point there will be a copy of the existing repository. Periodically 
we'll then be able to run the 'svnsync sync' and 'svnsync copy-revprops' to 
copy across any new revisions.

We'll then schedule the cutover weekend so would perform something like:

  1) Disable access to repos on old host.
  2) Perform final 'svnsync sync ...' & 'svnsync copy-revprops ...' on new host.
  3) Shutdown Subversion on old host.
  4) Remove the following revision properties from revision 0 on 
/path/to/new-repo
   svn:sync-from-url
   svn:sync-from-uuid
   svn:sync-last-merged-rev
   svn:sync-lock

I just want to confirm that my process seems sensible and that what I've 
described regarding breaking the svnsync mirror is correct.

If anyone can see anything that I might have wrong or missed?

Thanks,

Dg.
--
David Grierson - Lead Engineer
Sky - UK Information Systems - Tools Team



Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky Limited and Sky International AG 
and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 
2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect 
subsidiaries of Sky Limited (Registration No. 2247735). All of the companies 
mentioned in this paragraph are incorporated in England and Wales and share the 
same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

Bug in authz exclusion markers

[Grierson, David (Lead Engineer)]

Hi,

I've just deployed Subversion v1.11.1 and have run into an issue with the use 
of the exclusion marker within authz files.

See the attached authz file for data for the test cases.

This file contains two groups:
  1. "user-group" is a list of users (which might be used for specific 
repository access later in the file); membership : namedUser
  2. "blocked-group" is a list of users who are to be blocked : membership: 
blockedUser

The authz file contains a rule for the top level access which declares that 
anyone NOT in the blocked-group should get read-write access. Users in the 
blocked-group should only get read-only access.

TEST CASES:
 1. What access does namedUser have?

$ svnauthz accessof svn_access_test --username namedUser
rw

Result: PASS

 2. What access does blockedUser have?

$ svnauthz accessof svn_access_test --username blockedUser
r

Result: PASS

 3. What access does unnamedUser (a user who is authenticated to access 
Subversion but not mentioned in the authz file) have?

$ svnauthz accessof svn_access_test --username unnamedUser
r

Result: FAIL

My interpretation of this is a bug in the authz validation - can anyone else 
confirm that my thinking on this is correct or am I missing something with this?

Thanks,

David.
--
David Grierson - Lead Engineer
Sky - UK Information Systems - Tools Team



Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky Limited and Sky International AG 
and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 
2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect 
subsidiaries of Sky Limited (Registration No. 2247735). All of the companies 
mentioned in this paragraph are incorporated in England and Wales and share the 
same registered office at Grant Way, Isleworth, Middlesex TW7 5QD


svn_access_test
Description: svn_access_test

RE: [EXTERNAL] Re: Bug in authz exclusion markers

[Grierson, David (Lead Engineer)]

> It's hard to say without seeing the actual authz and group definition
> files. The authnz handling is interesting enough that we really need
> complete information to reproduce and debug. Sometimes the correct
> behaviour is not intuitive.

The authz file was attached to the message sent to the group.

See attachments on the following archived message:

https://lists.apache.org/thread.html/b267384886526699530a1a4750db4aa631d9e8b5ddf56776848d84ce@%3Cusers.subversion.apache.org%3E

--
David Grierson - Lead Engineer
Sky - UK Information Systems - Tools Team




Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky Limited and Sky International AG 
and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 
2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect 
subsidiaries of Sky Limited (Registration No. 2247735). All of the companies 
mentioned in this paragraph are incorporated in England and Wales and share the 
same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

CollabNet Subversion devel packages

[Grierson, David (Lead Engineer)]

Hi,

I'm running an internal Subversion service making use of the CollabNet 
Subversion RPMs to provide this.

I'm looking to introduce rate limiting to my Subversion service and so want to 
build mod_evasive for use within the Apache component of Subversion, to do so I 
need to use apxs to compile this, however the CollabNet packages don't include 
the "-devel" RPM and so this isn't possible.

Does anyone know where I can get this or will I have to revert to building from 
Subversion from source against the system Apache?

Cheers,

David.
--
David 
Grierson
 - Lead Engineer
Sky Broadcasting - UK Information Systems  - UKIS 
Tools
Tel: +44 1506 325100 / Email: 
david.grier...@sky.uk
Watermark Building, Alba Campus, Livingston, EH54 7HH

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky Limited and Sky International AG 
and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 
2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect 
subsidiaries of Sky Limited (Registration No. 2247735). All of the companies 
mentioned in this paragraph are incorporated in England and Wales and share the 
same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

RE: [EXTERNAL] Re: CollabNet Subversion devel packages

[Grierson, David (Lead Engineer)]

Hi,

(Firstly apologies for the top posting - Outlook is a PIA for that)

Yes - you're correct we're running RHEL, specifically we're on RHEL7. When the 
hosts were built they were replacing RHEL5 and RHEL7 was the latest distro 
which was being supported internally. In order to get an up-to-date 
installation of Subversion we looked to continue to use the CollabNet 
Subversion RPMs which we'd previously been using.

Unfortunately moving the Subversion service to RHEL8 would be a significant 
chunk of work (and cost) so that seems unlikely. It also looks like the RHEL8 
distribution is only at SVN 1.10, whereas the CollabNet RPMs we're on are 1.11 
(and in fact 1.12 is out).

My suspicion is that the -devel RPM is only made available to CollabNet's 
paying customers (which makes sense).

The specific issue we're having isn't actually caused by Subversion. We have 
configured the Apache httpd component of Subversion to also provide a proxy to 
a Nexus (NXRM) service providing Maven and Node repository hosting. We've 
noticed that some users seem to be making use of some kind of massively 
parallel (like 150+ connections from a single IP) download mechanism (possibly 
"yarn" - https://yarnpkg.com/). When we receive more than a couple of these 
they are in effect causing a DoS on the Apache httpd service. This then 
prevents users from accessing either the Subversion or Nexus services.

As Subversion generally operates via a single connection (for transfer of 
commits, etc.) this wouldn't be affected by mod_evasive, as I'd only be looking 
to limit the number of _simultaneous_ connections from a single IP.

The alternative I'd be looking at would be splitting off the Subversion and 
Nexus services then placing nginx in front of both of them and using that to 
rate limit.

For now I've tuned the Apache parameters to increase the MaxClients parameter 
to accept more connections. This seems to have alleviated the issue for now 
which should give us time to look at alternative solutions.

Thanks for the swift response.

Dg.

-Original Message-----
From: Mark Phippard 
Sent: 14 December 2021 12:33
To: Grierson, David (Lead Engineer) 
Cc: Subversion 
Subject: [EXTERNAL] Re: CollabNet Subversion devel packages

On Tue, Dec 14, 2021 at 7:00 AM Grierson, David (Lead Engineer)
 wrote:
>
> Hi,
>
> I'm running an internal Subversion service making use of the CollabNet 
> Subversion RPMs to provide this.
>
> I'm looking to introduce rate limiting to my Subversion service and so want 
> to build mod_evasive for use within the Apache component of Subversion, to do 
> so I need to use apxs to compile this, however the CollabNet packages don't 
> include the "-devel" RPM and so this isn't possible.
>
> Does anyone know where I can get this or will I have to revert to building 
> from Subversion from source against the system Apache?

In theory if you got a version of the module built against the same
httpd and apr versions it might work but it would probably be a good
time to look to change things up. I assume you are on a CentOS/RedHat
distro? Are the upstream packages new enough to use? For example, if
you have moved to the RHEL 8.x line then the LTS version of Subversion
is provided by the distro and would make your life a lot easier.

Do you have any reason to believe mod_evasive will do what you want? A
Subversion client doing a checkout can look a bit like a DoS attack in
terms of sending a lot of GET requests in a short timespan.

You could also stick a proxy in front of your server and do the rate
limiting there. That could be a good way to trial this out too. As you
could just point a specific client at the proxy to make sure svn
operations all work OK.

Mark

This email is from an external source. Please do not open attachments or click 
links from an unknown or suspicious origin. Phishing attempts can be reported 
by using the report message button in Outlook or sending them as an attachment 
to phish...@sky.uk. Thank you


Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky Limited and Sky International AG 
and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Lim