On Tue, Dec 14, 2021 at 1:10 PM Grierson, David (Lead Engineer) <david.grier...@sky.uk> wrote: > > 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).
This is a very old issue. RHEL releases lag, a *lot*, and Red Hat is very hesitant to update them to avoid regression surprises. I used to publish RPMs over at repoforge years ago, but repoforge hasn't updated anything in years. Unfortunately, porting subversion-1.14 has a lot of dependencies, While it's theoretically possible to take fhe subveraion-1.14 from RHEL 8, there's a missing sqlite version dependency that is resolved with sqlite-amalgamation that is a pain in the keister. Unfortunately, Collabnet doesn't elect to publish the SRPMs for their software, which is a bit of a pain to do. You're welcome to my old tweaked tools at https://github.com/nkadel/subversion-1.11.x-srpm , which include those hooks for sqlite-amalgamation. > 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 <markp...@gmail.com> > Sent: 14 December 2021 12:33 > To: Grierson, David (Lead Engineer) <david.grier...@sky.uk> > Cc: Subversion <users@subversion.apache.org> > Subject: [EXTERNAL] Re: CollabNet Subversion devel packages > > On Tue, Dec 14, 2021 at 7:00 AM Grierson, David (Lead Engineer) > <david.grier...@sky.uk> 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 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
