Mit kleineren Anpassungen an der NGINX und PHP-FPM Config kommst du ohne weiteres auf die gleiche Performance wie mit Apache MPM.
Das gibt sich also nicht viel (da kommt es einfach mehr auf FPM an).
Jetzt hast du gerade mein Weltbild erschüttert. Ich höre hier den ganzen Tag (und nachts mit Beleuchtung), wieviel besser und schneller nginx ist als Apache. Und jetzt schafft man es immerhin, auf die gleiche Performance zu kommen. Da bin ich jetzt aber schon einigermaßen desillusioniert 
.
Da sind mir zu viele "-dev" dabei. aber wird ja sowieso jeden Monat eine neue Sau durchs Dorf getrieben 
. Und statische Dateien sind sowieso nicht wirklich das große Problem. Bei manchen Hostern wäre man ja schon froh, wenn man mittlerweile HTTP/2 hätte. Aber immerhin scheinen ja wenigstens gut 70% der verwendeten Browser mittlerweile HTTP/3 zu unterstützen.
Alles anzeigenDanke Super!
jetzt habe ich das verstanden.
Den Beitrag bei Wikipedia werde ich mir auch durchlesen.
tab > Die Erklärung ist klasse!
KB19 > Den Port 22 werde ich dann mal umlegen. Hoffentlich sperre ich mich nicht aus
VG Mario
Wirklich aussperren wirst du dich wohl nicht, weil es ja immer noch den Zugang über die Konsole im SCP gibt. Da kann man sich dann anmelden und das Problem beseitigen, auch mit Root-Passwort, weil es ja keine SSH-Verbindung ist.
Alle diese Anmeldeversuche sind ursprünglich über Port 22 reingekommen, die entsprechenden Verbindungen können freilich nicht alle über ein und denselben Socket laufen, die dürfen also auch soweit durchkommen, weil Port 22 ja nicht geblockt wird. Also kein Grund zur Sorge, das ist normal. Der sshd lauscht auf Port 22, wenn aber eine Verbindung zustande kommt, dann wird für diese ein neuer Socket erstellt und verwendet, während der sshd weiterhin auf Port 22 auf neue Verbindungen wartet. Nur so können ja auch mehrere gleichzeitig bestehende Verbindungen zustandekommen. Eine Verbindung muss also in jedem Fall erst einmal zustandekommen, wenn man nicht grundsätzlich jede SSH-Verbindung blocken will. Sonst könnte sich der Client ja auch nicht authentifizieren. Wenn die Authentifizierung nicht erfolgreich ist, also z.B. der User gar nicht existiert (wie in deinem Log-Auszug) oder ggf der public key nicht passt, gibt es eben einen entsprechenden Logeintrag in der auth.log und die Verbindung wird beendet. Erst auf den Logeintrag reagiert dann wiederum fail2ban je nach Einstellung eben z.B. durch bannen der IP nach 5 erfolglosen Authentifizierungsversuchen. Die IP ist also nicht wirklich "bis zu fail2ban durchgekommen". Sie hat es nur zu einem Logeintrag in der auth.log gebracht, worauf dann wiederum fail2ban reagiert.
Also ich komme beim Aufruf von gopma.de auf http://www.gopma.de
Die Domain ist ja kein Installationspfad. Der Pfad ist eher die document root aka Dokumentenstamm-Verzeichnis, das für die Domain eingestellt ist. Wenn da überall httpdocs eingetragen ist ...
Es gibt bei den allermeisten Hostern nur eine einzige MySQL-Server Version, so auch hier. Damit betrifft das alle MySQL-Datenbanken, seien sie von 1965 
oder 2021. Alte MySQL-Dumps werden beim Import in eine aktuelle Datenbank zwingend auf den aktuellen Stand gebracht oder sie können erst gar nicht importiert werden - oder eventuell nur unvollständig. Der sql_mode, den deine Version von PHP Fusion setzen will existiert nicht mehr, wenn der entsprechende MySQL-Server eben Version 8 ist. Wenn du nicht updaten kannst, dann musst du eben deine Version entsprechend patchen (eventuell die Stelle(n) suchen, wo dieser sql_mode gesetzt wird und den durch einen noch existierenden sql_mode ersetzen) oder PHP Fusion muss einen entsprechenden Patch bereitstellen. Die einzigen Alternative dazu sind entweder ein Update auf eine Version von PHP Fusion, die zu MySQL 8 kompatibel ist oder der Umzug der zu MySQL 8 inkompatiblen Version zu einem anderen Hoster oder bei netcup auf einen Server, auf dem du dann noch eine Weile MySQL 5.x verwenden kannst inklusive dem gewünschten sql_mode. Oder auch MariaDB. Eventuell kann sich der Umzug auch auf die Datenbank beschränken, mit allen Performance-Problemen, die das mit sich bringen mag. Das müsste man dann eben ausprobieren. Weitere Alternativen sehe ich nicht.
Dieser Wert für sql_mode wird von MySQL 8 m.E. nicht mehr unterstützt. Das heißt, du solltest da mal bei PHP-Fusion prüfen, wie es mit der MySQL 8 Kompatibilität aussieht oder ggf. auf eine neuere Version updaten, welche MySQL 8 unterstützt.
Dazu müsste man die Bildchen erst mal sehen.Mir jedenfalls gelingt das nicht.
Ja, hatte ich auch mal mit einer Domain, die ich woandershin umgezogen hatte. Support hatte ich damals gar nicht eingeschaltet, weil es für mich nicht besonders wichtig war.
Edit: Das betraf bei mir aber nicht Sogo, ich konnte die Domain halt nicht als externe Domain in einem anderen Webhosting einbinden/nutzen.
PHP-Anwendungen, die auf Frameworks wie z.B Laravel oder Symfony basieren, sind mittlerweile weit verbreitet und benötigen in der Regel Zugriffsrechte für PHP auf das Verzeichnis "oberhalb" der document root. Nun ist es in dieser Hinsicht zwar schon positiv, dass sich hier in den PHP-Einstellungen (open_basedir) der gesamte Webspace freigeben lässt, aber letztlich hat man damit den Schutz aller anderen Projekte und auch Dokumente im selben Webspace gegen eine fehlerhafte oder eventuell gar gehackte Anwendung ausgehebelt. Deswegen würde ich es besser finden, dafür eine dritte Auswahlmöglichkeit für open_basedir in den PHP-Einstellungen zur Verfügung zu stellen, die das Verzeichnis über der document root freigibt. Damit wäre es dann möglich, die Verzeichnisse anderer Projekte im Webspace oder vertrauliche Dokumente, die eigentlich gar nicht über den Webserver zugreifbar sein sollten, vor dem Zugriff einer fehlerhaft programmierten/gehackten Laravel/Symfony/...-Anwendung zu schützen, was derzeit leider nicht möglich ist.
Das dürfte die Einstellung von open_basedir in den PHP-Einstellungen sein. Da musst du in einem solchen Fall die mit {WEBSPACEROOT} beginnende Einstellung auswählen.
Tja, so eine Lösung dann tatsächlich zu finden, kann auch mal 350 Jahre dauern, siehe großer Fermatscher Satz. Hoffen wir mal, dass es dir schneller gelingt. 
So einen schlechten Upload habe ich beim netcup RS aber bisher nie erlebt
Also der Vergleich mit dem Autofahren hinkt natürlich erst mal. Der Fahrlehrer sitzt neben dir und hat die Verantwortung für alles was passiert. Deswegen hat er auch einen eigenen Pedalsatz um z.B. jederzeit bremsen zu können. Vorgefertigte Skripte, egal von wem, sind kein Ersatz dafür. Ein Skript von irgendjemand hier ist auch nicht garantiert besser/sicherer als das Setup-Skript des nächstbesten Panels. Ein Auto und auch ein Server können gefährliche Waffen sein. Ordentliche Schäden kann man jedenfalls mit beiden anrichten, ob gewollt oder nicht.
Ich sage nicht, dass man es nicht schaffen kann, als Anfänger einen Server nach dem "state of the art" abzusichern. Aber es ist zumindest die Gefahr gegeben, dass, durch fehlendes Wissen gepaart mit Ungeduld, Risiken eingegangen werden, die man besser nicht eingehen sollte. Da wird schon mal die Firewall geöffnet oder ein Dateirecht auf 777 gesetzt, "nur um mal eben zu checken ob es prinzipiell schon funktioniert". Man darf nie vergessen, dass eine VM auf einem lokalen PC im heimischen LAN in aller Regel durch den Router einem großen Teil der unablässigen Angriffsversuche von "außen" auf jede öffentliche IP-Adresse gar nicht erst ausgesetzt ist. Wenn man es nicht selbst gesehen hat macht man sich keine Vorstellung, was da ab der ersten Sekunde auf einen frisch von netcup (und natürlich auch anderen Anbietern) bereitgestellten vServer an Verbindungsversuchen auf den "gängigen" Ports hereinprasselt! Wäre der vServer nicht schon halbwegs sicher voreingestellt (immerhin ist das voreingestellte root-Passwort nicht "123456", sondern hat immerhin 15 Stellen, allerdings keine Sonderzeichen), könnte es leicht passieren, dass, wenn man am Morgen den vServer bestellt und ihn abends nach der Arbeit einrichten will, dieser bereits gehackt ist. Denn leider werden vServer hier immer noch in gestartetem Zustand ausgeliefert, sofern sich das nicht in allerletzter Zeit geändert hat. Ein völlig unnötiges Risiko, auch wenn es vielleicht nicht besonders groß ist. Ein gestoppter Server startet bei Bedarf innerhalb weniger Sekunden. Wenn ich nicht sofort Zeit habe, einen neuen Server abzusichern, ist meine erste Aktion nach Erhalt der "Bereitstellungsbenachrichtigung", den Server zu stoppen. Als Anfänger sollte man sich in jedem Fall zumindest erst mal über die vordringlichen Absicherungsmaßnahmen schlau machen und diese dann zügig(!) umsetzen, bevor man mit dem Server rumspielt oder weitere Software installiert.
Ja. Wenn laut netcup (E-Mail Benachrichtigung, Domaindaten im CCP, ...) die Domain erfolgreich zu Netcup transferiert wurde und in den DNS-Einstellungen der Domain im CCP Nameserver eingetragen sind, dann ist es die Aufgabe von netcup dafür zu sorgen, dass dies auch bei der DENIC entsprechend aktualisiert wird.
Also Support kontaktieren. Es kann nicht deine Aufgabe sein, hierüber mit der DENIC zu kommunizieren, man würde dich dort sowieso an deinen Registrar - netcup - verweisen.
Also ich habe zumindest schon mal 1.8 GBit/s erreicht bei der Übertragung von einem Webhosting zum Server. Hätte auf seiten des Webhostings gar nicht funktionieren dürfen.
Hast du für beide Domains die Bestätigungsmail erhalten, dass die Domain erfolgreich zu netcup transferiert wurde? Wenn da jetzt noch bei der DENIC die alten Nameserver drin sind und du das nicht selbst irgendwie beim Umzug so eingetragen hast, dann ist da wohl was schiefgelaufen und das wird dann eher der Support überprüfen/korrigieren müssen.
Bekommst du auch schon Mails beim neuen Hoster oder kommt noch alles beim alten Hoster an? Grundsätzlich kann es bis zu ca 48 Stunden dauern, bis auch der letzte Nameserver im australischen Busch die aktuellen DNS Einträge mitbekommt. Aber wenn jetzt, nach mehr als 13 Stunden, noch gar nichts beim neuen Hoster ankommt, dann würde ich die DNS-Einträge der Domains nochmal kontrollieren. Nach meinen Erfahrungen bei Umzügen von einem deutschen Hoster zu einem anderen deutschen Hoster hat das eigentlich selten länger als 8 Stunden gedauert, bis Mails zum allergrößten Teil beim neuen Hoster ankamen.
Und die These, dass nginx 2.5 mal so schnell sei wie Apache ist vermutlich ziemlich steil. Ohne die Benchmarks im Detail zu sehen, speziell die verwendeten Apache Einstellungen, bezweifle ich das jedenfalls. Ich bezweifle aber nicht, dass nginx schneller ist. Apache ist aber bestimmt auch 2x schneller als Apache , wenn man den ganzen Overhead mit .htaccess usw durch AllowOverride None komplett abschaltet und - wie nginx - nur noch die statischen Konfigurationsdateien benutzt, die eben nur einmal beim Start des Apache gelesen werden müssen. Dann muss er nicht mehr bei jedem Request in jeder Verzeichnisebene bis runter zum aktuellen Verzeichnis nachschauen, ob es eine .htaccess gibt, diese ggf lesen und auswerten unter Berücksichtigung der darüberliegenden .htaccess-Dateien und was auch sonst noch immer dranhängt. Dann ist er aber wahrscheinlich auch nicht mehr so furchtbar viel flexibler als nginx. Irgendwann, wenn mir mal furchtbar langweilig ist, mache ich mal den Benchmark Apache2 vs Apache2. Und nginx vs Litespeed, ... vs ..., ... Denn ich glaube keinem Test, den ich nicht selbst gefälscht habe.
