Morning Mark
Thanks a lot for the quick suggestion. I don't have a proxy in front
of the SVN though. The svn client (Which is also subversion 1.14)
connects to apache server that is running mod_dav_svn to serve a svn
repo. I am not sure if this apache server can then be called a proxy,
as all http based svn would then have a proxy. The same apache is the
one that handles ssl termination.
I do have two DNS A records. Not sure if this can cause this
breakage. The hostname is called repo.example.com. So there is a
DNS A record of repo.example.com pointing to 192.168.20.6. However to
allow easy server migration, the svn clients use another A record
that points carbon.example.com to the current SVN server, in this case
carbon.example.com point to 192.168.20.6. I can't honestly see this
being a problem but sharing in case it's a problem and I am in the
dark.
I just thought sharing my actual configurations could also help.
Below is how apache config looks like:
<VirtualHost *:443>
ServerName carbon.example.com
Header always set Strict-Transport-Security "max-age=31536000;
includeSubDomains"
<FilesMatch "\.pdf$">
Header set Content-Disposition inline
</FilesMatch>
MaxKeepAliveRequests 1000
<IfModule dav_svn_module>
SVNCacheRevProps on
SVNInMemoryCacheSize 3145728
SVNCacheTextDeltas On
SVNAllowBulkUpdates Prefer
SVNCacheFullTexts On
SVNUseUTF8 On
</IfModule>
<Location /svn>
DAV svn
SVNParentPath /var/repos/svn
SVNListParentPath On
SVNReposName "SVN Repositories"
LimitXMLRequestBody 0
LimitRequestBody 0
AuthType GSSAPI
AuthName "SVN Account"
GssapiConnectionBound On
GssapiBasicAuth On
GssapiNegotiateOnce On
GssapiLocalName on
BrowserMatch Windows gssapi-no-negotiate
AuthzSendForbiddenOnFailure On
GssapiCredStore keytab:/etc/httpd/conf.d/httpd.keytab
GssapiSignalPersistentAuth On
GssapiSSLonly On
AuthzSVNReposRelativeAccessFile authz
AuthzSVNGroupsFile /var/repos/svn/glacier/conf/groups
Require expr %{REMOTE_USER} =~ /@example.com$/
</Location>
<Location /svn/svn-status>
SetHandler svn-status
</Location>
RewriteEngine on
RewriteCond %{HTTP_HOST} !^carbon\.example\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) https://carbon.example.com/$1 [L,R,NE]
RewriteCond "%{QUERY_STRING}" "^$"
RewriteRule "^/$"
https://example.sharepoint.com/IT/SitePages/Repositories.aspx
[L,R=301]
</VirtualHost>
Regards,
William
On Fri, 18 Feb 2022 at 18:11, Mark Phippard <[email protected]> wrote:
>
> On Fri, Feb 18, 2022 at 5:52 PM William Muriithi
> <[email protected]> wrote:
> >
> > Hello,
> >
> > I have this setup:
> > - httpd-2.4.37-43
> > - subversion-1.14.1-1
> > - mod_dav_svn-1.14.1-1
> > - openssl-1.1.1k-5
> >
> > The svn on Rocky Linux that is accessible only over https (Apache) and
> > everything works fine with exemption of "svn mv" command. Below is a
> > series of commands on how to trigger the error.
> >
> > svn mv xyz.txt abc.txt
> > svn ci -m 'Renaming a dummy file for changes"
> > Adding abc.txt
> > svn: E175002: Commit failed (details follow):
> > svn: E175002: Unexpected HTTP status 502 'Bad Gateway' on
> > '/svn/pro/!svn/rvr/4748/abc.txt'
> >
> > However, a new file abc.txt will get committed without any problem.
> >
> > The problem seems to match a problem reported here.
> > https://community.opalstack.com/d/608-svn-unexpected-http-status-502-bad-gateway/3
>
> That is a very common problem. It happens when the server is sitting
> behind some kind of load balancer or proxy that is terminating the SSL
> connection. The issue is that the svn copy and move commands use
> WebDAV HTTP methods. These include the HTTP "Destination" header and
> it needs to be rewritten by the proxy to change the https to http.
>
> Here is one example:
> https://stackoverflow.com/questions/2479346/502-bad-gateway-with-nginx-apache-subversion-ssl-svn-copy
>
> The answer will depend on the Proxy being used.
>
> Mark