agowa338
Goto Top

Apache migration und SNI

Hallo,

ich habe hier ein komisches problem. Ich möchte meinen Webserver von Server A auf Server B migrieren (gleiche Version von apache2 und os). Jedoch ist das eine von älteren Versionen geupgraded worden und der neue frisch installiert.
Dafür habe ich die Ordner /etc/apache2, /etc/ssl und /var/www auf Server B mittels rsync kopiert.

Nun das Komische, wenn ich auf die neue Seite zugreife, erhalte ich nur "SSL_ERROR_RX_RECORD_TOO_LONG" in Firefox und "ERR_SSL_PROTOCOL_ERROR" in google chrome.

Wenn ich jetzt alle bis auf eine VirtualHost Datei in /etc/apache2/sites-enabled entferne und in dieser die Zeile
"<VirtualHost myDomain.com:443>" in "<VirtualHost *:443>" ändere, funktioniert der Seitenaufruf ohne Probleme, jedoch nur für diese eine Webseite und nicht für die anderen.

Außerdem bekomme ich auf dem neuen Server diese Warnungen:
AH00557: apache2: apr_sockaddr_info_get() failed for apache2
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message

Einträge in den Logfiles gibt es hierzu ebenfalls nicht.
Ein apache2-ctl configtest liefert ein ok zurück.

Unterschiede neuer und alter server:
Auf dem neuen Server läuft apache in einem Container mit einen iptables DNAT davor, das port 443 vom host auf port 443 im Container weiterleitet.

Den Container habe ich mit den folgenden Befehlen erstellt (%i steht hier für den Nahmen des Containers):
/usr/sbin/debootstrap --include=systemd,dbus,libpam-systemd,traceroute,ca-certificates,openssl --arch=amd64 stable /var/lib/machines/%i
/bin/ln -s /lib/systemd/system/systemd-networkd.service /var/lib/machines/%i/etc/systemd/system/multi-user.target.wants/systemd-networkd.service
/bin/mkdir -p /var/lib/machines/%i/etc/systemd/system/sockets.target.wants/systemd-networkd.socket
/bin/mkdir -p /var/lib/machines/%i/sys/fs/selinux
/bin/ln -s /lib/systemd/system/systemd-networkd.socket /var/lib/machines/%i/etc/systemd/system/sockets.target.wants/systemd-networkd.socket
/usr/bin/systemd-run --machine %i --wait /bin/hostname apache2
/usr/bin/systemd-run --machine %i --wait /bin/bash -c "echo apache2 > /etc/hostname"  
/usr/bin/systemd-run --machine %i --wait /usr/bin/dpkg --configure -a
/usr/bin/systemd-run --machine %i --wait /usr/bin/apt -q update
/usr/bin/systemd-run --machine %i --wait /bin/bash -c 'DEBIAN_FRONTEND=noninteractive /usr/bin/apt -yq install openssh-server wget apt-transport-https vim nano'  
/usr/bin/systemd-run --machine %i --wait /usr/bin/apt -q update
/usr/bin/systemd-run --machine %i --wait /usr/bin/apt -yq install apache2 php libapache2-mod-php
/usr/bin/systemd-run --machine %i --wait /usr/bin/apt -yq upgrade
/usr/bin/systemd-run --machine %i --wait /usr/bin/apt -yq dist-upgrade

Hat noch jemand eine Idee, was hier schief laufen könnte? Oder zumindest wie ich anständige logs von dem Ereignis bekommen kann?

Content-Key: 350566

Url: https://administrator.de/contentid/350566

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: LordGurke
LordGurke 01.10.2017 um 12:19:17 Uhr
Goto Top
Das deutet darauf hin, dass du nicht global die SSLEngine eingeschaltet hast.
Das müsstest du in der globalen Konfiguration machen, in der Regel gibt es dafür eine separate Datei in der auch das SSL-Modul geladen wird und z.B. die Cipherlisten angelegt werden.
Da müsste dann ein "SSLEngine On" mit hinein.
Wichtig für SNI ist auch, dass "NameVirtualHost *:443" definiert ist.
Mitglied: agowa338
agowa338 01.10.2017 um 14:43:23 Uhr
Goto Top
Danke für den tipp, das habe ich gerade noch einmal überprüft, aber daran kann es nicht liegen.
Der Apache funktioniert mit der glichen Konfiguration ja auch auf dem alten Server.
Außerdem habe ich jetzt auch keinen generischen NameVirtualHost Eintrag. Nur mehrere spezifische Einträge.
Ich habe um das auszuschließen bereits den Apache auf dem alten Server komplett neugestartet und dieser Funktioniert.
Außerdem funktioniert es selbst dann nicht, wenn ich zusätzlich einen generischen NameVirtualHost anlege.

Ich gehe aktuell von einer fehlenden Dependency oder einen Konfigurationsfehler in einem anderen Packet aus.
Jedoch finde ich keine entsprechenden Logs.