reposoft / docker-svn Goto Github PK

https://github.com/Reposoft/docker-svn/blob/v0.6.1/httpd/conf/rweb/load-fpm.conf#L10

for https://github.com/Reposoft/rweb/tree/master/repos-web/errors

Dynamic error pages is a quite bad idea, if errors are caused by httpd<->rweb issues. Therefore the docker build must generate static error pages for apache.

For example with RWEB=fpm we can't use the e.mkdir service on any path that has a read-only descendant. See Reposoft/rweb@7f8a12d

My initial reaction is that this is a bug with mod_authz_svn, as they handle GET but not POST. True, POST may affect a subtree. However it'd have to be converted, server side like rweb does, to a Subversion operation first.

@takesson Do you have ideas? The only thing I can come up with now is to separate external and internal hosts (again) and load the mod_authz_svn module only on the internal host.

Tried to add ini files in 0b7ba88 but I don't think it had the intended effect

We do build the svn cli, though not strictly needed, so we should either stop doing that or add ra_serf for https:// svn capabilities.

By design we call svn -> rweb -> svn to serve ?rweb= stuff. With docker-compose this works if services are named like that, or one of them is and the other has a links: entry.

For example the svn container tends to respond Proxy Error DNS lookup failure for: rweb if the following strings don't match:

• https://github.com/Reposoft/docker-svn/blob/v0.6.0/build-contracts/docker-compose.yml#L4
• https://github.com/Reposoft/docker-svn/blob/v0.6.0/build-contracts/docker-compose.yml#L32
• https://github.com/Reposoft/rweb/blob/v1.6.0/test/conf-svn/rweb-services.conf#L16

In Kubernetes you typically run svn and rweb containers in the same pod, which means that svn will reach rweb on 127.0.0.1:9000, but not rweb:9000.

Happens for large file commit when running current https://hub.docker.com/r/solsson/svn-httpd/ behind https://hub.docker.com/r/solsson/ssl-proxy-letsencrypt/