Nach Apache + php-update parsed php nur noch ~50%??

[drfuture]

Moin,

Ich habe gestern Apache + php5 geupdated (php5 von 5.2.0 auf 5.2.4, apache auch ein paar bugfix-versionen neuer...)

Auf dem System läuft confixx.

Das wunderbare ist nun das auf 2 vhosts php funktioniert.

beim 1. (web0) über http - über https nicht.
beim 2. geht php auf ner subdomain die permanent auf https umgeleitet wird.

sonst scheint php nirgends zu gehen - auch beim Standard-Host nicht.

Nicht funktionieren heißt das die php datei gar nicht erst geparsed wird.
Ok - erste Idee war natürlich AddHandler - der mimetype wird aber global angezeigt. Testweise habe ich ihn auch noch einmal direkt in die httpd.conf eingetragen.

error_log meldet ein warning von ssl-host konflickten. An der Config wurde aber seit dem Update nichts geändert.

[Mon Oct 29 23:44:53 2007] [warn] Init: SSL server IP/port conflict: web2.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web2.conf:40) vs. web3.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web3.conf:40)
[Mon Oct 29 23:44:53 2007] [warn] Init: SSL server IP/port conflict: web1.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web1.conf:40) vs. web3.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web3.conf:40)
[Mon Oct 29 23:44:53 2007] [warn] Init: SSL server IP/port conflict: web0.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web0.conf:29) vs. web3.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web3.conf:40)
[Mon Oct 29 23:44:53 2007] [warn] Init: SSL server IP/port conflict: xx.cx:443 (/etc/apache2/confixx_mhost.conf:172) vs. web3.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web3.conf:40)
[Mon Oct 29 23:44:53 2007] [warn] Init: SSL server IP/port conflict: 85.xx.xx.xx:443 (/etc/apache2/confixx_mhost.conf:125) vs. web3.xx.serverkompetenz.net:443 (/etc/apache2/confixx_vhosts/web3.conf:40)
[Mon Oct 29 23:44:53 2007] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!

Mir fällt leider nichts ein wieso php zum Teil funktioniert und zum Teil nicht - und dann noch nicht mal wirklich Fehler auftauchen... - also serverseitig ....

Evtl. hat ja jemand einen Rat - sonst werde ich wohl Backups zurückspielen müssen :(

[Joe User]

Code: Select all

[Mon Oct 29 23:44:53 2007] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!

Deutlicher geht es doch gar nicht mehr?!

[thelaw]

Funktioniert bei mir aber eigentlich bestens.
Da ich nicht unendliche viele IPs habe und nicht auf alternative Ports ausweichen möchte, bleibt mir auch wenig anderes übrig.

[Joe User]

Schade dass der Apache hier keinen gerechtfertigten Error schmeisst...

SuFu: SSL-Proxy

[thelaw]

Welche gerechtfertigen Errors?

Ich konfiguriere in der Standardconfig für den Webserver auf Port 443 ein Zertifkat das für alle Vhosts gilt. Dieses Zertifikat enthält die alle (wichtigen) Domains als CN (bzw. SubjAltName).
Der Client stellt dann eine Verbindung zum Webserver her, handelt eine SSL-Verbindung auf Basis des global konfigurierten Zertifkats aus, parst dann die HTTP-Header und liefert aufgrund des Host: <domain> Headers den entsprechenden Vhost aus. Man muss nur beachten, dass die SSL-Verbindung ausgehandelt wird, bevor der Vhost berücksichtigt wird. Ansonsten kann dies zu unerwarteten Ergebnissen führen.

Die Lösung mit dem SSL-Proxy erachte ich als weniger schön, da ich damit eine Weiterleitung auf eine zentrale Domain habe. Ich würde das aber gerne transparent lösen.

Nachtrag: Was heißt eigentlich SuFu? Habe die Abkürzung weder bei Wikipedia noch in der FAQ finden können...

[drfuture]

Code: Select all

[Mon Oct 29 23:44:53 2007] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!

Deutlicher geht es doch gar nicht mehr?!

Ja sicher - nur wie von mir gesagt - und auch ein paar anderen im Thread - das läuft theo. ja trotzdem, und lief auch bisher.

Sicher kommt dann nen popup mit der falschen Domain, für manche zwecke reicht es aber so - wenn ich einen Onlineshop oder ähnliches Betreibe kaufe ich ein Zertifikat ;)

aber z.B. für den eigenen Webmaildienst reicht das alle mal...

Oder sperrt die neue apache-version dann auf einmal div. Funktionen wegen doppelbelegung?? - und wieso gehts dann zum Teil?

Ich sollte noch hinzufügen, das http über die anderen vhosts sehr wohl funktioniert - bzw. auch über https daten ausgeliefert werden...

jedoch beim Aufruf von .php eben der phpcode nicht der geparste Inhalt.
Wenn der Apache mit der config (doppelte ssl Belegung) nicht zurecht kommt, würde er dann nicht gar nicht starten, oder nichts anzeigen beim Aufruf der Adresse?

@TheLaw SuFu = SuchFunktion



----------
edit:
habe eben mal alle vhosts:443 außer einem gelöscht, damit der Fehler nicht mehr kommt - und das Ergebnis ist genau das gleiche - daran lag es also wohl wirklich nicht ...

[Joe User]

Wie hast Du PHP und Apache upgedatet? Distributionspakete, selbst kompiliert oder 3rd-Party-Pakete (Quelle?)?

[drfuture]

Packetmanager Smart

Quellen aus denen die neuen Packete waren:

[Apache]
type = rpm-md
name = Apache
baseurl = http://repos.opensuse.org/Apache/openSUSE_10.2/

[PHP]
type = rpm-md
name = PHP
baseurl = http://repos.opensuse.org/server:/php/openSUSE_10.2/


Und nu sacht nichts zu Suse.. ich steh dazu ;P

[drfuture]

Code: Select all

short_open_tag = off

war der Fehler... nachdem auch ein paar bekannte Scripte nich <?php schreiben können... geht dann nur noch die hälfte ....

mit = on passt nu alles ;)

[oxygen]

"eigentlich" ist short_open_tag = off auch zu empfehlen. sonst fliegen einem xml dokumente um die ohren.