502 Bad Gateway mit nginx + apache + subversion + ssl (SVN COPY)

Question

Ich habe Probleme, Apache + Subversion mit SSL hinter einem Nginx-Proxy auszuführen, und ich hoffe, dass jemand die Antwort kennt. Ich habe stundenlang im Internet nach der Antwort auf mein Problem gesucht und kann es einfach nicht herausfinden. Was ich sehe, sind "502 (Bad Gateway)"-Fehler beim Versuch, über Subversion zu MOVE oder zu COPY; jedoch funktionieren Checkouts und Commits einwandfrei. Hier sind die relevanten Teile (denke ich) der betroffenen nginx- und Apache-Konfigurationsdateien:

Nginx

upstream subversion_hosts {
    server 127.0.0.1:80;
}

server {
        listen       x.x.x.x:80;
        server_name  hostname;

        access_log   /srv/log/nginx/http.access_log main;
        error_log    /srv/log/nginx/http.error_log info;

        # Alle Anfragen auf https umleiten
        rewrite ^/(.*)$ https://hostname/$1 redirect;
}

# HTTPS-Server
server {
        listen       x.x.x.x:443;
        server_name  hostname;

        passenger_enabled    on;
        root /path/to/rails/root;

        access_log   /srv/log/nginx/ssl.access_log main;
        error_log    /srv/log/nginx/ssl.error_log info;

        ssl                  on;
        ssl_certificate      server.crt;
        ssl_certificate_key  server.key;

        add_header Front-End-Https on;

        location /svn {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                set $fixed_destination $http_destination;
                if ( $http_destination ~* ^https(.*)$ )
                {
                    set $fixed_destination http$1;
                }
                proxy_set_header Destination $fixed_destination;

                proxy_pass http://subversion_hosts;
        }
}

Apache

Listen 127.0.0.1:80

        # Um COPY und MOVE etc. über https (443) zu unterstützen,
        # muss ServerName mit dem nginx Servernamen übereinstimmen
        # http://trac.edgewall.org/wiki/TracNginxRecipe
        ServerName hostname
        UseCanonicalName on

                DAV svn
                SVNParentPath "/srv/svn"
                Order deny,allow
                Deny from all
                Satisfy any
                # Einige Konfigurationen ausgelassen ...

        ErrorLog /var/log/apache2/subversion_error.log

        # Mögliche Werte sind: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/subversion_access.log combined

Nach meinen Recherchen zu diesem Problem muss der Servername sowohl auf dem Apache-Server als auch auf dem Nginx-Server übereinstimmen, was ich getan habe. Darüber hinaus scheint dieses Problem bestehen zu bleiben, auch wenn ich die Konfiguration auf die Verwendung nur von http ändere.

Answer 1

Ich stand heute genau vor diesem Problem.

Das Hinzufügen des folgenden Codes in der Apache2-Konfiguration hat es behoben:

RequestHeader edit Destination ^https http early

Viele Grüße,
  Ignace M

---

Quelle:

• https://secure.bonkabonka.com/blog/2008/01/04/nginx_fronting_for_subversion.htm

Answer 2

Die vorherigen Lösungen haben bei mir nicht funktioniert, ich musste die nginx-Konfiguration ändern und folgendes im location-Block hinzufügen, bevor die proxy_pass-Anweisung steht:

set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ ) {
    set $fixed_destination http$1;
}
proxy_set_header Destination $fixed_destination;
proxy_set_header Host $http_host;

Answer 3

Ich fand heraus, dass die Ursache meines Problems nicht der Proxy zwischen nginx und Apache war, sondern ein Problem mit Apache selbst.

Was ich in der ursprünglichen Frage nicht erwähnt habe, war, was sich im # Einige Konfigurationen ausgelassen befand. Dieser Block enthielt Folgendes:

AuthType Basic
AuthName "Redmine SVN-Repository"
Require valid-user
PerlAccessHandler Apache::Authn::Redmine::access_handler
PerlAuthenHandler Apache::Authn::Redmine::authen_handler

Für Suberversion kontrolliere ich den Benutzerzugriff mithilfe des Authentifizierungshandlers von Redmine. Nachdem ich Optionen ein- und ausgeschaltet und das Problem eingegrenzt habe, habe ich festgestellt, dass ihr Authentifizierungsmodul nicht threadsicher ist. Ich bin auf den Fehler gestoßen, weil Apache den Worker MPM verwendet hat. Der Wechsel zum Prefork MPM (sudo aptitude install apache2-mpm-prefork in Ubuntu) hat das Problem behoben.

Answer 4

In meinem Fall habe ich RouixSVN benutzt und musste nur die SVN-Authentifizierungsdaten auf meinem Computer löschen und mich erneut anmelden, dann hat es funktioniert. Hoffe, es hilft jemand anderem.