Eine Stunde Finetuning und die DB rennt wie doof:
Und wir sind nicht am Anschlag
Eine Stunde Finetuning und die DB rennt wie doof:
Und wir sind nicht am Anschlag
Moin,
leider ist mir gestern in der Nacht irgendwann der Datenstrom gerissen, und ich kann nicht nachvollziehen an welcher Stelle genau. Da jetzt aber klar ist in welche Richtung ich gehen muss, werd ich das noch einmal bei null starten und sequentiell machen.
Daher wird das Forum dann vielleicht wirklich mal 1 bis 2 Tage offline sein, bzw. das neue Forum eben im Wartungsmodus zu sehen sein.
So wie ich den Fehler interpretiere liegt das an einem zerschossenen Index bei der Übernahme.
Schau ich mir ggf nächste Woche an.
Micha lass uns nächste Woche mal sprechen und ne Session machen, ich muss in jedem Fall wissen wie das im Front End aussehen wird und wie die Zuordnung gemacht werden muss.
Sonst bringt uns das ganze nichts, weil wirs nicht zur Anzeige bringen können.
Leider können wir nicht alte Welt und neue Welt parallel laufen lassen, die unterschiede sind einfach zu groß. Ergo, ich werd das alte Forum immer mal wieder offline nehmen müßen, um das neue Forum weiter zu bauen.
Sodele,
das meiste hab ich in den Griff bekommen, hier und da wird noch ein kleiner Fehler geworfen aber es wird.
SSL für eine Domain funktioniert, Multi-Domain mit eigenen Zertifikaten klappt leider nicht nicht, es wird immer die Hauptdomain gezogen, was logischerweise zu einem TLS Fehler führt. Wer hier Ideen hat, gerne her damit.... Win 2019 Server IIS und certify the web mit let's encrypt!
Gut wie dem auch sei...
Das neue Forum steht und die Bestandsdaten sind migriert. Allerdings nur auf Ebene der Datenbank, Forenstruktur muss erst gebaut werden, die wird nicht übernommen.
Micha, hier müßen wir telefonieren, das Ding bringt mich um den Verstand. Und ich hab für heute keine Lust mehr.
Guts Nächtle, mir reichts für heute.... und morgen [size=10] [/size]
[size=10] [/size]
Zitieren TESCHT
Also dafür kann ich nichts
Ich ziehe und rüttel mal am Stuhl, aber das wars dann auch.
Ich hab das jetzt mal ganz anders gemacht, dabei allerdings wohl einen Post von Manuel, verloren... tut mir Leid das war keine Absicht.
Ich würde das Forum jetzt mal gerne so auf dem neuen DB Server laufen lassen und sehen wie er mit der Last zurecht kommt.
Daneben gehts natürlich weiter.
Das ist mir bewusst, es liegt auch nicht an den Credentials, es sind einfach 3 Tabellen verloren gegangen.
HeidiSQL ist ein schönes Tool für MariaDB, kann auch Backup erstellen und einspielen mit detailierter Fehleranzeige.
Absolut, das Problem ist, Heidi lässt sich nicht überreden ein Backup des alten MySQL Servers zu machen. Sprich ich muss mit Dumps arbeiten. Die alternative wäre zu versuchen beide Server parallel auf unterschiedlichen Ports laufen zu lassen und dann direkt zu replizieren. Alternativ einen 3. Intermid DB lokal laufen lassen um die Daten einmal zu migrieren.
SSL für eine Domain mit dem IIS funktioniert prima. Zu mehreren bin ich noch nicht gekommen.
Die erste blanke Installation ist durchgelaufen!
Allerdings funktioniert unsere Registrierung nicht, hab dir ne WhatsApp geschickt.
Der Paketdownloader hat noch einen Curl Fehler und Probleme mit dem SSL, muss ich mir anschaun, wird aber bissi dauern.
Was ist ansonsten passiert?
Das Backup verliert auf dem Weg zur MariaDB 3 Tabellen, was ich mir gerade nicht erklären kann, wird auch bissi dauern...
Alles in allem wir haben angefangen und es wird. Dauert nur eben.
Von mir aus gerne, das sollte dir und Udo bestimmt helfen.
Für die tapfer Wartenden mal ein kurzes Update incl. ein paar einpaar Details.
Altes und neues Forum laufen auf unterschiedlichen php versionen, --> check
Alter Apache und neuer IIS laufen abwechselnd, Ich möchte nicht sämtliche Ports neu sortieren und immer wieder umstellen --> check
Neuer MariaDB Server läuft --> check
Alte Daten aus MYSQL migrieren, um zuerst den DB Server zu ersetzten --> Die Codierung passt noch nicht ganz, sollte aber in kürze passen
IIS und php8.3 auf alle Woltlab Requirements bringen --> check
SSL aktivieren --> ongoing
Als nächsten kommt eine Standalone Installation der neuen Software, wenn das soweit passt, plane ich die komplett migration.
Ich kann euch leider nicht ersparen das ich den Server immer mal wieder offline neben muss, aber ich finde keine vernünftige stabile Möglichkeit ein php3 und php8 simultan über den gleichen Webserver laufen zu lassen ohne ein Portschlamassel zu verursachen.
Ich kann euch nicht genau sagen wie lange ich noch brauchen werden, den Zeit ist leider das wenigste was ich habe, aber ich bemühe mich!
Viele Grüße,
Cris
1.) Absagen und an einem anderen Termin 2024 machen oder 2025 nachholen, wenn sich die Lage bei Audi bessert
+1
...hatte noch 2min und gerade ein Tablet,jetzt passt es wieder.
Ich melde keinen Fehler, sondern sende ganz herzlichen Dank an die Macher!!
Korrektur: Die Uhrzeit von Paras Beitrag stimmt nicht, er ist unserer Zeit voraus, bei ihm ist schon Montag, 02:28
...wird morgen früh direkt in der DB gefixt.
Will oder will net
Moin zusammen,
gestern Nacht lief ja schon deutlich besser, sehr schön. Für heute erwarte ich noch einmal eine Verbesserung.
geblockt im Sinne einer Umleitung sind sie schon (500er), das verhindert nur nicht dass der GET überhaupt beim Apache landet. Das wäre der Idealzustand.
Wir blocken auch schon halb Asien, das ist nicht Teil des Problems. Ich kann keine Länder und IP Ranges blocken wenn zum Teil Deutschland, Österreich, Schweiz, Belgien usw. verwendet werden.
Wie bereits erwähnt, die Attacken sind stümperhaft und bereiten mir keine Kopfschmerzen, es geht um den Load.
Die Linux / Windows Diskussion ist mühsam, es gibt ausreichend Gründe für beides. Zumal der Server nie gehackt wurde und auch sonst nicht unsicher in Erscheinung trat.
Der Tipp zur Versionsnummer ist Super, Danke!
Viele Grüße,
Cris
Moin Didi,
ich werte gerade die Access Logs aus [size=10] [/size];([size=10] [/size]
Im Prinzip ist ein Block der UserAgent's möglich. Das Problem daran besteht:
1. Den UserAgent kann man beliebig ändern und faken --> Tut jeder Handy Browser via "Desktop Seite anfordern".
2. Mit einem BLOCK auf bspw. Mozilla/5.0 würden wir alle Mozilla kompatiblen Browser aussperren --> dummerweise alle.
Was ich stand jetzt schon weis, uns machen auch einige inländische Bots Probleme [size=10] [/size][size=10] [/size]
Ich seh mal was ich hinbekommen kann.
Viele Grüße,
Cris
Update:
Etwa 6000 generierte Abfragen binnen 10 Minuten, also etwa 10 synchron in der Sekunde... Das schafft unser Server leider wirklich nicht, zumindest nicht über diese Dauer [size=10] [/size]X([size=10] [/size]
Update 2
Hat jetzt zwar etwas gedauert, aber war wohl auch mal wieder nötig [size=10] [/size][size=10] [/size]
[size=10]
[/size]
Das Böse und die Masse der Request stammt aus folgendem User Agent:
138.201.248.37(¹) - - [03/Feb/2019:01:00:09 +0100] "GET /index.php?page=PostsFeed&format=rss2&threadID=3190 HTTP/1.1" 404 7172 "-" "Mozilla/5.0 (compatible; um-IC/1.0; mailto: techinfo@ubermetrics-technologies.com; Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
¹Aus 2 Millionen Anfragen die ich analysiert habe kommen wir hier schon auf über 6000 verschiedene GLOBALE IP ADRESSEN.
Leider versteckt sich dahinter kein Bot (Die ROBOT.TXT wird eh ignoriert) sondern ein BruteForce Angriff.
Der Angriff alleine macht mir ehrlicher Weise keine Sorgen, die Methoden sind stümperhaft, wofür ich zur Zeit noch keine Lösung habe ist ein Block des Ganzen, so das weder eine RAM-TABLE noch der Server selbst dich machen.
Wer hier gute Ideen hat, gerne her damit. Einträge in der FW fallen raus, das es einfach wesentlich zu viele IP's sind, und ich keinen generischen Weg kennen diese zu pflegen.
Add-On's fallen raus, soweit geht mein Vertrauen nicht, um "fremden" Herstellern ein Türchen zum Server zu öffnen.
Viele Grüße,
Cris
[size=10]
[/size]
Hi Didi,
danke für den Tipp mit der HTACCESS, die nutzen wir schon um zig "dumme" Bots und Crawler aus dem asiatischen Raum auszusperren.
Unser Problem mit dem AhrefsBot ist, er wechselt nach jede Abfrage seine IP, daher müßten wir riesige Bereiche sperren und wissen noch nicht einmal über wie viele Ranges er verfügt. Incl. der Tatsache das wir dadurch auch User aussperren würden --> Bsp. wenn Deutsche IP's gespoofed werden.
Mann könnte via Fail2Ban auch die Logs permanent durchforsten lassen um die FW im gleichen Intervall zu aktualisieren, allerdings wären wir somit wieder "nur" einen Schritt hinten dran.
nachhaltige Lösungen können hier eigentlich nur vom Provider getroffen werden, denn unser Server hat nicht die Kapazität >1GB Logfiles permanent zu durchforsten.
Viele Grüße,
Cris