Apache: Einzelne URL anders routen/redirecten

[tme]

Hallo,

mir ist sozusagen die Pflege einer größeren Applikation in die Hände gefallen. Diese wird mittels Apache und Tomcat gehostet, wobei es in meinem Problem nur um den Apache geht.

Verbindungen werden bei uns bisher größtenteils von Apache einfach an Tomcat weitergeleitet und vom Tomcat verarbeitet. Dies passiert mit der folgenden Konfiguration (anonymisiert):

Code: Select all

<VirtualHost *:80>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /var/www
  ServerName www.domain1.de
  ServerAlias *.domain1.de

  SetEnvIf Request_URI "/home/*" no-jk

  JkMount /* ajp13_worker
</VirtualHost>

<VirtualHost *:80>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /var/www
  ServerName www.domain2.de
  ServerAlias *.domain2.de

  SetEnvIf Request_URI "/home/*" no-jk

  JkMount /* ajp13_worker
</VirtualHost>

<VirtualHost *:80>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /home/images
  ServerName www.domain3.de
  ServerAlias *.domain3.de
</VirtualHost>

<VirtualHost 192.168.43.38:443>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /var/www
  ServerName www.domain2.de
  ServerAlias *.domain2.de
   
  SSLEngine on
  SSLCertificateFile /home/sslZertifikate/x_domain2_de.crt
  SSLCertificateKeyFile /home/sslZertifikate/x_domain2_de.key

  SetEnvIf Request_URI "/home/*" no-jk
  JkMount /* ajp13_worker
</VirtualHost>

<VirtualHost 192.168.43.14:443>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /var/www
  ServerName www.domain1.de
  ServerAlias *.domain1.de

  SSLEngine on
  SSLCertificateFile /home/sslZertifikate/x_domain1_de.crt
  SSLCertificateKeyFile /home/sslZertifikate/x_domain1_de.key

  SetEnvIf Request_URI "/home/*" no-jk
  JkMount /* ajp13_worker
</VirtualHost>


Wie man sehen kann, werden neben den 2 normalen Domains auch Bilder von dieser Apache-Instanz ausgeliefert. Ich wollte diese Auslieferung über eine dritte Domäne jetzt anpassen und diese auch von derselben Domain serven lassen. Dazu habe ich folgende Einträge zu dieser Datei hinzugefügt:

Code: Select all

<VirtualHost *:80>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /home/images
  ServerName images.domain1.de
</VirtualHost>

<VirtualHost *:80>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /home/images
  ServerName images.domain2.de
</VirtualHost>


Starte ich nun den Apache (ohne Fehlermeldungen) neu, kann ich unter images.domain1.de und images.domain2.de die Bilderverzeichnisse abrufen, während alle weiteren Subdomains weiterhin an Tomcat weitergereicht werden. Leider stoße ich mit dieser Konfiguration, angewendet auf HTTPS, auf Probleme. Füge ich jetzt das HTTPS-Äquivalent dieser beiden Einträge hinzu

Code: Select all

<VirtualHost *:443>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /home/images
  ServerName images.domain1.de

  SSLEngine on
  SSLCertificateFile /home/sslZertifikate/x_domain1_de.crt
  SSLCertificateKeyFile /home/sslZertifikate/x_domain1_de.key
</VirtualHost>

<VirtualHost *:443>
  ServerAdmin mailadresse@adresse.de
  DocumentRoot /home/images
  ServerName images.domain2.de
 
  SSLEngine on
  SSLCertificateFile /home/sslZertifikate/x_domain2_de.crt
  SSLCertificateKeyFile /home/sslZertifikate/x_domain2_de.key
</VirtualHost>


kommt es beim Start des Apache zu folgender Fehlermeldung:

[warn] _default_ VirtualHost overlap on port 443, the first has precedence
[warn] _default_ VirtualHost overlap on port 443, the first has precedence

Natürlich hat der Apache damit Recht. Aber warum tritt das Problem nicht auch bei derselben Konfiguration über Port 80/HTTP auf? Dort scheint diese Art der Konfiguration hervorragend zu funktionieren.

Leider ist mein Wissen über die Konfiguration von Apache derzeit noch begrenzt und obwohl ich meine Englischkenntnisse als ziemlich gut einschätze, halte ich die Apache-Dokumentation für ziemlich undurchsichtig (benutzt in den relevanten Abschnitten zu VirtualHost und NameVirtualHost ziemlich viel weitere Apache-Lingo, die Erklärung bedarf).

Hat jemand eine Idee?

Danke,

Thomas

[Nobbie]

Natürlich hat der Apache damit Recht. Aber warum tritt das Problem nicht auch bei derselben Konfiguration über Port 80/HTTP auf? Dort scheint diese Art der Konfiguration hervorragend zu funktionieren.

Ne, Du siehst den Wald vor lauter Bäumen nicht. Außerdem zeigst Du uns eine unvollständige Konfiguration, irgendwo weiter oben steht todsicher die Zeile "NameVirtualHost *:80".

Das gleiche steht nicht für den Port 443 in der Konfiguration. D.h. also für den Port 80 gibt es auschließlich NameBased VirtualHosts, egal welche IP der VirtualHost hat (*:80).

Für den Port 443 gibt es aber dagegen keine NameBased VirtualHosts, sondern (bis dato) nur IP-Based VirtualHosts (und zwar für die IPs 192.168.43.14 und 192.168.43.38 jeweils auf Port 443). Und nun definierst Du auf einmal eine Wildcard *:443, die sich natürlich mit den vorhandenen IP-Based VirtualHosts schneidet. Das geht so nicht und das ist das, was Dir Apache eigentlich mitteilen will.

Ergo: Du hast noch Nachholbedarf in der Dokumentation über virtuelle Hosts. Siehe http://httpd.apache.org/docs/2.2/vhosts/

Lies die Kapitel über virtuelle Hosts durch, insbesondere die Unterscheidung zwischen IP-Based und NameBased und entscheide dann, welche Virtuellen Hosts Du einsetzen willst. Das hängt von Eurer Infrastruktur ab. Du wirst allerdings feststellen, dass die nächsten Probleme auftauchen, wenn dieser Fehler behoben ist, denn Du brauchst für Deinen neuen virtuellen Host (der zur Zeit ignoriert wird) ein eigenes Zertifikat (man kann Zertifikate nicht in mehreren Hosts benutzen, zumindest wahrscheinlich nicht die vorhandenen).

[tme]

Huhu Nobbie,

danke erstmal für deine Antwort.

Ne, Du siehst den Wald vor lauter Bäumen nicht. Außerdem zeigst Du uns eine unvollständige Konfiguration, irgendwo weiter oben steht todsicher die Zeile "NameVirtualHost *:80".

Tatsächlich habe ich die gesamte "/etc/apache2/sites-available/defaults"-Datei gepostet, es gibt keine weiteren Zeilen, die ich unterschlagen habe. Die Konfigurationsdatei stammt ja auch nicht von mir, mir ist sozusagen die Pflege des Projektes in die Hände gegeben worden.

Ergo: Du hast noch Nachholbedarf in der Dokumentation über virtuelle Hosts. Siehe http://httpd.apache.org/docs/2.2/vhosts/

Danke für den Hinweis, aber wie ich oben bereits erwähnte, stehe ich derzeit wegen komplexer Thematik mit der Dokumentation auf Kriegsfuß und hoffte, jemand mit mehr Materienverständnis würde ein wenig Licht in's Dunkel bringen können. Gefunden habe ich die Dokumentation auch, wobei witzigerweise zu erwähnen ist, dass das Material über IP-based VHost Support trotz "de"-Link (http://httpd.apache.org/docs/2.0/de/vho ... based.html) in Englisch ist.

Namensbasierte virtuelle Hosts können aufgrund der Natur des SSL-Protokolls nicht mit SSL-gesicherten Servern verwendet werden.

Daraus schließe ich, dass es also auf IP-basierte virtuelle Hosts hinauslaufen muß. Muß ich dann für die Auslieferung der Bilddateien einen weiteren virtuellen Host einrichten? Dann käme ich wohl nicht um ein weiteres Zertifikat herum. Dabei gilt das Zertifikat, welches unserer Seite hinterliegt, doch für alle Subdomains von domain1.de, man sollte doch also auch diesen Pfad über das Zertifikat bedienen können. Läßt sich das per IP-Basierung dem Catchall weiter unten in der Konfiguration nicht vorschalten?

Danke,

Thomas

Edit: Wenn ich das richtig verstehe, nutztest du die Wald-Bäume-Analogie für den Sachverhalt, dass wir zwar fast überall IP-Basierung nutzen, aber plötzlich mittels *:80 für domain3 auf Namensbasierung umschalten. Wenn ja, so frage ich mich natürlich direkt, warum der Spaß funktioniert: Hinter der 3. Domäne liegt keine interne IP-Adresse, die Netzwerkkarte hat nur die beiden angesprochenen IPs für domain1 und domain2. Eine korrekte mögliche Lösung wäre also, der Netzwerkkarte eine 3. IP-Adresse zu verpassen, diese hier korrekt analog der ersten 2 Adressen zu hinterlegen und dann für die 3. Domäne auch ein Zertifikat zu generieren. Gibt es auch eine Möglichkeit, die Bilder mittels der bestehenden Zertifikate zu serven?

[Nobbie]

Tatsächlich habe ich die gesamte "/etc/apache2/sites-available/defaults"-Datei gepostet, es gibt keine weiteren Zeilen, die ich unterschlagen habe.

Irgendwo MUSS die genannte Zeile stehen, sonst funktioniert das mit den NameBased VirtualHosts gar nicht. Das äußert sich dann nicht in einer Fehlermeldung, sondern darin, dass IMMER der erste VirtualHost zieht (also DocumentRoot usw.), egal wie die Eingabe URL lautet.

Danke für den Hinweis, aber wie ich oben bereits erwähnte, stehe ich derzeit wegen komplexer Thematik mit der Dokumentation auf Kriegsfuß und hoffte, jemand mit mehr Materienverständnis würde ein wenig Licht in's Dunkel bringen können.

Du erwartest doch jetzt aber sicherlich nicht ein ausführliches Tutorial inkl tiefgehender Erläuterungen? Davon gibt es tausende im Internet und wenn Du noch Defizite hast, solltest Du einige dieser Tutorials durcharbeiten. Die Konfiguration von Apache ist nun einmal sehr komplex und umfangreich, da hilft nur üben üben üben.

Gefunden habe ich die Dokumentation auch, wobei witzigerweise zu erwähnen ist, dass das Material über IP-based VHost Support trotz "de"-Link (http://httpd.apache.org/docs/2.0/de/vho ... based.html) in Englisch ist.

Englisch sollte doch heutzutage kein Problem darstellen, das lernt seit man vielen Jahren jeder in der Schule. In der IT Branche ist gutes Englisch Pflicht.

Muß ich dann für die Auslieferung der Bilddateien einen weiteren virtuellen Host einrichten?

Weiß ich nicht, das mußt Du den fragen, der das von Dir will.

Dabei gilt das Zertifikat, welches unserer Seite hinterliegt, doch für alle Subdomains von domain1.de, man sollte doch also auch diesen Pfad über das Zertifikat bedienen können.

Wenn das so ist (es gibt solche Zertifikate, aber die meisten benutzen Zertifikate ohne Wildcards), dann sollte das gehen.

Wenn ich das richtig verstehe, nutztest du die Wald-Bäume-Analogie für den Sachverhalt, dass wir zwar fast überall IP-Basierung nutzen, aber plötzlich mittels *:80 für domain3 auf Namensbasierung umschalten.

Nein, das meinte ich nicht. Ich meinte die Tatsache, dass Du bei Port 80 Namensbasierte Hosts benutzt (kein Problem), bei Port 443 aber eine ungültige Mischung aus Namensbasierten und IP-basierten Hosts. Man kann Namensbasierte und IP-basierte Hosts mischen, aber dann muss man eben aufpassen, dass sich die IPs nicht überlappen (das ist nur bei Namensbasierten Hosts möglich).

[tme]

Irgendwo MUSS die genannte Zeile stehen, sonst funktioniert das mit den NameBased VirtualHosts gar nicht. Das äußert sich dann nicht in einer Fehlermeldung, sondern darin, dass IMMER der erste VirtualHost zieht (also DocumentRoot usw.), egal wie die Eingabe URL lautet.

Wenn du mit "irgendwo" die angesprochene Datei meinst, kann ich dir versichern, dass ich keine Zeilen aus dieser Datei unterschlagen habe.

Danke für den Hinweis, aber wie ich oben bereits erwähnte, stehe ich derzeit wegen komplexer Thematik mit der Dokumentation auf Kriegsfuß und hoffte, jemand mit mehr Materienverständnis würde ein wenig Licht in's Dunkel bringen können.

Du erwartest doch jetzt aber sicherlich nicht ein ausführliches Tutorial inkl tiefgehender Erläuterungen? Davon gibt es tausende im Internet und wenn Du noch Defizite hast, solltest Du einige dieser Tutorials durcharbeiten. Die Konfiguration von Apache ist nun einmal sehr komplex und umfangreich, da hilft nur üben üben üben.

Wie kommst du von meiner freundlichen Formulierung "hoffte" auf die unfreundliche "erwartest"? Ich erwarte überhaupt nichts und freue mich, dass jemand antwortet. Selbstverständlich ist es unproblematisch, wenn du nicht die Fähigkeit, die Zeit oder den Willen hast, mir zu helfen, ich hoffte aber eben auf Jemanden, der mich nicht nur in die Richtung der Dokumentation schubst (die ich ja, wie bereits im Eingangspost bereits besprochen, gefunden habe).

Gefunden habe ich die Dokumentation auch, wobei witzigerweise zu erwähnen ist, dass das Material über IP-based VHost Support trotz "de"-Link (http://httpd.apache.org/docs/2.0/de/vho ... based.html) in Englisch ist.

Englisch sollte doch heutzutage kein Problem darstellen, das lernt seit man vielen Jahren jeder in der Schule. In der IT Branche ist gutes Englisch Pflicht.

Wenn ich etwas nicht verstehe, dann entferne ich zuerst die Sprachbarriere. Auch wenn ich sehr gut englisch verstehe, so ist es doch nicht meine Muttersprache, und die Unterscheidung zwischen "Verstehe ich nicht, weil ich die englische Terminologie nicht verstehe" und "Verstehe ich generell nicht" nicht möglich ist.

Muß ich dann für die Auslieferung der Bilddateien einen weiteren virtuellen Host einrichten?

Weiß ich nicht, das mußt Du den fragen, der das von Dir will.

Wer das von mir will, ist ein Kunde, der ein Problem damit hat, dass die Seite zwar sauber verschlüsselt ankommt, aber durch das Laden der Bilder aus einer unverschlüsselten Verbindung Warnmeldungen erzeugt. Niemand schreibt mir vor, wie ich dies zu lösen habe. Fehlen denn für Entscheidung, ob dies ein gangbarer Weg und technisch machbar wäre, noch Fakten?

Dabei gilt das Zertifikat, welches unserer Seite hinterliegt, doch für alle Subdomains von domain1.de, man sollte doch also auch diesen Pfad über das Zertifikat bedienen können.

Wenn das so ist (es gibt solche Zertifikate, aber die meisten benutzen Zertifikate ohne Wildcards), dann sollte das gehen.

Ja, es handelt sich um ein Wildcard-Zertifikat. Wir bedienen die einzelnen Bereiche als Subdomains, also z.B. "kunde1.domain1.de".

Ich skizziere nochmal die Situation, falls diese noch nicht ausreichend beschrieben war, und klarifiziere die Frage erneut. Die Situation:

Request: http://www.domain1.de(80 oder 443) -> [externe IP 1] -> [interne IP 1 (192.168.43.38)] -> Apache -> mod_jk -> Tomcat -> Unsere Applikation
Request: http://www.domain2.de(80 oder 443) -> [externe IP 2 (eth0:1)] -> [interne IP 1 (192.168.43.14)] -> Apache -> mod_jk -> Tomcat -> Unsere Applikation

Gibt es eine technisch machbare Konfiguration für den Apache, der folgende Requests zuläßt, ohne die vorherigen Beispiele zu stören und der auch SSL unterstützt:

images.domain1.de(80 oder 443) -> [externe IP 1] -> [interne IP 1] -> Apache liefert /home/images aus
images.domain2.de(80 oder 443) -> [externe IP 2] -> [interne IP 2] -> Apache liefert /home/images aus

Danke,

Thomas

[Xardas der Dunkle]

Wenn du mit "irgendwo" die angesprochene Datei meinst, kann ich dir versichern, dass ich keine Zeilen aus dieser Datei unterschlagen habe.

Bei mir steht die Zeile z.B. mal in der /etc/apache2/ports.conf

[externe IP 1]...[externe IP 2 (eth0:1)]

Nein zumindest nicht für den Port 80. Hier zeigen beide Domains auf JEDE IP-Adresse. Das ist hier nur möglich weil in irgendeiner einer Datei eben die NameVirtualHost-Directive steht und dafür sorgt das der Apache den VHost über den Host-Header bestimmt und nicht nur über die IP.

Anders bei den bereits existierenden SSL-VHosts. Hier ist ist für jeden VHost eine IP angegeben. Ist auch korrekt da ein SSL-Zertifikat immer nur für eine IP gültig ist.
Um deine beiden neuen VHosts SSL-Fähig zu machen brauchst du also noch 2 weitere IP-Adressen und 2 weitere Zertifikate.

Oder da images.* immer auf das selbe Verzeichnis zu zeigen scheint würde auch eine IP + ein Wildecard-Zertifikat reichen. Diese sind aber nicht besonders billig und vor allem kommt meines Wissens auch nicht jeder Browser damit klar.

[tme]

Bei mir steht die Zeile z.B. mal in der /etc/apache2/ports.conf

Ich habe diese Zeile in der /etc/apache2/ports.conf:

Code: Select all

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

NameVirtualHost *:80
Listen 80

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    Listen 443
</IfModule>


[externe IP 1]...[externe IP 2 (eth0:1)]

Nein zumindest nicht für den Port 80. Hier zeigen beide Domains auf JEDE IP-Adresse. Das ist hier nur möglich weil in irgendeiner einer Datei eben die NameVirtualHost-Directive steht und dafür sorgt das der Apache den VHost über den Host-Header bestimmt und nicht nur über die IP.

Ich bin mir nicht sicher, ob du dich hier verquotet hast oder das Absicht ist. Die oben angegebene Konfiguration läuft bereits produktiv und servt derzeit 2 Shopsysteme, sowohl über 80 als auch 443.

Anders bei den bereits existierenden SSL-VHosts. Hier ist ist für jeden VHost eine IP angegeben. Ist auch korrekt da ein SSL-Zertifikat immer nur für eine IP gültig ist. Um deine beiden neuen VHosts SSL-Fähig zu machen brauchst du also noch 2 weitere IP-Adressen und 2 weitere Zertifikate.

Wenn ich die Informationen aus unterschiedlichen Quellen jetzt richtig zusammengepuzzelt habe, dann handelt es sich bei Name Based Virtual Host und IP Based Virtual Host nicht um Arten, die Konfiguration in den Konfigurationsdateien zu hinterlegen, sondern definiert sich über die IP-Ausstattung der Server.

Wir haben dann also eine IP Based Virtual Host-Ausstattung. 2 IP-Adressen zeigen auf 2 NIC-Devices und sollen über eine Konfiguration an Tomcat weitergeleitet werden.

Das Root des Tomcats liegt auf /var/lib/tomcat6/webapps. Das zusätzliche Verzeichnis /home/images soll in irgendeiner Form mittels 80 und 443 vom Apache zur Verfügung gestellt werden, ohne es physikalisch irgendwie umzubewegen. Eine Rücksprache mit einem IIS-Admin bestätigt mir, dass der IIS dies könnte, ich kann also davon ausgehen, dass es keinen technischen Grund gibt, dass dies nicht möglich sein sollte.

Der alte Admin wußte sich nicht besser zu helfen, als die Bilder über eine weitere Domain (oben domain3 genannt) anzubinden und auszuliefern, was jedoch auf die angesprochenen Probleme mit den SSL-Zertifikaten stößt, da für diese Domäne kein Zertifikat existiert. Hauptsächlich geht es jedoch darum, die Bilder irgendwie über 80 und 443 zur Verfügung zu stellen. Deswegen dachte ich daran, Request auf z.B. images.domain1.de per ausnahmeregel vom Apache serven zu lassen, aber jeden anderen Request wie bisher an den Tomcat weiterzuleiten.

Danke,

Thomas

[Nobbie]

Wenn ich die Informationen aus unterschiedlichen Quellen jetzt richtig zusammengepuzzelt habe, dann handelt es sich bei Name Based Virtual Host und IP Based Virtual Host nicht um Arten, die Konfiguration in den Konfigurationsdateien zu hinterlegen, sondern definiert sich über die IP-Ausstattung der Server.

Jain. Ein NameBased VirtualHost richtet sich nach dem ServerName (Bestandteil des HTTP Protocolls 1.1, bei HTTP/1.0 funktioniert das nicht, aber das benutzt auch kein Mensch mehr), das ist die Host: Komponente im Header. Damit kann man erreichen, dass auf ein- und derselben IP mehrere Domains angemeldet sind. Bei IP Based VirtualHost richtet sich die Auflösung nach der IP des Servers. Wenn man verschiedene Server mit verschiedene IPs bedienen muss, kann man sowohl NameBased als auch Ip Based VirtualHosts benutzen (und die Direktive NameVirtualHost definiert den IP-Umfang, es werden alle dort definierten IPs "unter einen Teppich gefegt"). Wenn man nur eine IP hat und mehrere VirtualHosts bedienen will, dann MUSS man NameBased VirtualHosts nehmen.

Wir haben dann also eine IP Based Virtual Host-Ausstattung. 2 IP-Adressen zeigen auf 2 NIC-Devices und sollen über eine Konfiguration an Tomcat weitergeleitet werden.

Wenn Ihr pro IP und Server nur eine Domain bedient (also ein 1:1 Verhältnis), dann würde ich IP-Based VirtualHosts vorziehen. Dort ist die NameVirtualHost Direktive nicht notwendig (einfach auskommentieren) und Du gibst dann konkret in der <VirtualHost> Direktive die jeweilige IP an.

Das zusätzliche Verzeichnis /home/images soll in irgendeiner Form mittels 80 und 443 vom Apache zur Verfügung gestellt werden, ohne es physikalisch irgendwie umzubewegen. Eine Rücksprache mit einem IIS-Admin bestätigt mir, dass der IIS dies könnte, ich kann also davon ausgehen, dass es keinen technischen Grund gibt, dass dies nicht möglich sein sollte.

Dafür ein eigenen VirtualHost anzulegen ist natürlich mit Kanonen auf Spatzen schießen. Ein einfacher ALIAS tut es. Beispielsweise definierst Du im jeweiligen VirtualHost für Port 80 und Port 443 der Domain www.domain1.com den gleichen ALIAS (die müssen zwar nicht gleich sein, aber wenn man die ungleich macht, verwirrt es allenfalls die Anwender). Also einfach in den jeweiligen Blocks (am besten gleich unter der DocumentRoot Anweisung) schreibst Du:

Code: Select all

Alias /bilder /home/images

Außerdem mußt Du dann noch für /home/images in einem <Directory ..> Block für Apache den Zugriff erlauben ("Allow From All" o.ä.). Sonst bekommst Du einen 403er Fehler.

Und dann kann man einfach via http://www.domain1.com/bilder auf diesen Ordner /home/images zugreifen, bzw. eben auch über https://www.domain1.com/bilder. Du kannst natürlich für das Wort /bilder jeden beliebigen anderen Begriff wählen, das ist ein virtueller Ordner (ein Alias), der auf den physikalischen Ordner /home/images verweist.

Der alte Admin wußte sich nicht besser zu helfen, als die Bilder über eine weitere Domain (oben domain3 genannt) anzubinden und auszuliefern, was jedoch auf die angesprochenen Probleme mit den SSL-Zertifikaten stößt, da für diese Domäne kein Zertifikat existiert

Grausam.

Hauptsächlich geht es jedoch darum, die Bilder irgendwie über 80 und 443 zur Verfügung zu stellen. Deswegen dachte ich daran, Request auf z.B. images.domain1.de per ausnahmeregel vom Apache serven zu lassen, aber jeden anderen Request wie bisher an den Tomcat weiterzuleiten.

S.o., einen Alias einrichten. Nur muss wahrscheinlich die JkMount Anweisung auch aus dem VirtualHost ausgelagert werden, sinnvollerweise in den <Directory...> Block des DocumentRoot. Letzteres muss ich raten, weil ich kein Tomcat benutze. Aber sonst zieht sicherlich die Alias Anweisung nicht, denn so wie ich diese JkMount Anweisung an dieser Stelle verstehe, leitet die einfach alles weiter (soll sie ja nicht, bzw. nur das, was zum DocumentRoot gehört). Den <Directory> Block musst Du ggf. neu anlegen, ich sehe keinen in Deiner Konfiguration.

[tme]

Ein einfacher ALIAS tut es.

Und das ist jetzt auch die Lösung:

Code: Select all

  Alias /images /home/images
  <Directory /home/images>
    Order Allow,Deny
    Allow from all
  </Directory>

  SetEnvIf Request_URI "/images/*" no-jk


reichte, um dieses Problem zu lösen. Entsprechender Block geht (nach Revision des Nutzerrechtekonzepts) in jeden VHost-Zweig der bisherigen Konfiguration ein. Damit werden die Bilder korrekt ausgeliefert.

Auskommentieren kann ich das

Code: Select all

NameVirtualHost *:80

noch nicht, danach funktioniert die 3. "Schummel"-Domäne nicht mehr (keine 3. IP-Adresse), Bilder werden darüber dann nicht mehr ausgeliefert. Wenn diese nicht mehr gebraucht wird, stelle ich die eigentliche Konfiguration auf saubere IP-Adressen um und entferne die NameVirtualHost.

Vielen lieben Dank,

Thomas

[Xardas der Dunkle]

Nein ich habe mich nicht verquoted ich wollte dich nur darauf hinweisen das für domain1, domain2 und domain3 über port 80 eben keine IP angegeben ist sondern diese alle über die Namensauflösung laufen. Zumindest entnehme ich das deiner Config-Datei die du oben gepostet hast.

Code: Select all

<VirtualHost *:80>
[...]
  ServerName www.domain1.de
[...]

<VirtualHost *:80>
[...]
  ServerName www.domain2.de
[...]

<VirtualHost *:80>
[...]
  ServerName www.domain3.de
[...]


du kannst die Zeile

Code: Select all

NameVirtualHost *:80

also nicht entfernen, da sie für diese 3 VHosts benötigt wird.

Es werden laut deiner Config-Datei nämlich nur die beiden SSL-VHosts direkt auf eine IP "gelinkt":

Code: Select all

<VirtualHost 192.168.43.38:443>
[...]
<VirtualHost 192.168.43.14:443>

Wenn es aber nur noch 2 Domains welche jeweils auf Port 80 und 443 lauschen und der Server 2 IP-Adressen besitzt kannst du natürlich die beiden ersten Name-Based-VHosts auf die beiden IPs umbiegen.