Od kilku tygodni do zarządzania repozytoriami subversion używam całkiem sensownego narzędzia o nazwie SCM-Manager (i zgodnie z nazwą oprócz SVN wspiera też GITa i Mercuriala). Ponieważ cały ruch na zewnątrz chce mieć szyfrowany za SSL i ładne adresy odpowiada apache. Niestety pierwotna metoda podłączenia aplikacji odpalonej na jetty’m z apachem za pomocą mod_jk i AJP okazała się niestrawna dla SVNKita z którego korzysta SCM-Manager i kończyła się błędem 500 przy próbie checkoutu z repozytorium.

Rozwiązaniem lepszym, ba jak się okazuje polecanym w dokumentacji do serwera jetty jest wykorzystanie mod_proxy i HTTP zamiast AJP. Taka konfiguracja okazuje się stabilna, bezproblemowa i wymaga minimalny zmian w konfiguracji jetty i apache’a.

W pliku konfiguracyjnym jetty (przy instalacji z paczki .deb znajdziemy go w /opt/scm-manager/conf/server-config.xml) odkomentowujemy linijkę mówiącą o tym, że zapytania będą forwardowane przez proxy:

<Configure class="org.eclipse.jetty.server.Server">

  <Call name="addConnector">
    <Arg>
      <New class="org.eclipse.jetty.server.nio.SelectChannelConnector">
        <Set name="host">
          <SystemProperty name="jetty.host" />
        </Set>
        <Set name="Port">8090</Set>
        <Set name="requestHeaderSize">16384</Set>
        <!-- for mod_proxy -->
        <Set name="forwarded">true</Set>

      </New>
    </Arg>
  </Call>

A w samym apache’u uruchamiamy jeśli nie posiadaliśmy do tej pory moduł proxy (a2enmod proxy_http) a w konfiguracji VirtualHosta (w moim przypadku :443 z SSLem):

ProxyPass /scm http://localhost:8090/scm
ProxyPassReverse /scm http://localhost:8090/scm
<Location /scm>
Require all granted
RequestHeader set X-Forwarded-Proto "https" env=HTTPS
</Location>

Oczywiście port 8090 można zastąpić dowolnym innym otwartym portem, a X-Forwarded-Proto dodajemy tylko w przypadku gdy ruch będzie szedł HTTPSem.