Beiträge von frostschutz

Zitat von m23

Ich kenne das bisher nicht - weder von netcup noch von anderen Providern.

Andere machen Video-Ident... das ist viel schlimmer. Zum Affen machen vor laufender Kamera... halten Sie den Perso an die Stirn, halten Sie hierhin, halten Sie dorthin, drehen Sie, winken Sie, …was zum. Nebenbei Wohnungsbesichtigung da der Mitarbeiter auf der anderen Seite frei zwischen Front- und Hauptkamera umschalten kann.

Und das machen tausende Menschen jeden Tag... für ne olle SIM-Karte...

Muss man nicht mögen aber "RAF Lösegeldforderung" ist doch etwas überzogen.

Zitat von frank_m

Es wird nicht gesendet, sondern im Browser ausgewertet, also bei dir lokal. Übertragen und gespeichert wird nur ein Hash.

Normalerweise wird es gesendet... anders wirds auch ziemlich kompliziert.

Die Fehlermeldung kommt im Forum quasi nicht vor, entweder du hast Glück oder du bist ein Extremfall. Wie groß sind die Cookies denn? Irgendwann ist halt Schluss. Cookies werden bei jedem Request mitgeschickt (nicht nur dort wo sie tatsächlich gebraucht werden), wenn man es hier allzu sehr übertreibt, hat man auch beim eigenen Server Probleme.

Zitat von EduLind

So ich hab das Problem in der auth.1 log Datei entdeckt, dort werden zahlreiche Anmeldeversuche auf verschiedenen Ports mit verschiedenen Usern und PWs aufgezeichnet. Kann mir jemand helfen, wie ich mich jetzt gegen diese Attacken schützen kann, weil es unters. IPs sind kann ich ja nicht per IP bannen.

Die Anmeldeversuche sind leider normal, auch bei geändertem SSH-Port. Da arbeiten sich ganze Botnetze daran ab...

Man kann sshd nur noch über Wireguard laufen lassen, oder Port Knocking einrichten, oder das Log einfach ausschalten.

Mit Wireguard überlebt eine SSH-Verbindung auch mal einen kurzen Reconnect des DSL-Routers. Man kann damit also auch kleinere Probleme im eigenen Netzwerk umgehen. Einen Versuch ist es vielleicht wert.

Mach die Keys auf jeden Fall nochmal neu.

Der von dir verlinkte Portchecker funktioniert bei mir auch nicht.

Aber Wireguard funktioniert einwandfrei...

Zitat von dMopp

Problem das ich zB mit Wireguard habe: Wireguard startet NACH ssh und somit muss ich nach jedem reboot den sshd Neustarten.

Benutzt du wg-quick? Wenn man das Netzwerk und Wireguard stattdessen von systemd-networkd aufsetzen lässt, klappt es.

... latin1?

und wenn du da vorher ein mysqli_query($db, 'SET NAMES utf8mb4;')?

bzw. mysqli_set_charset

sorry, mein PHP ist rostig

Falsches Charset in der Datenbank, falsches Charset in der Datenbank-Verbindung, irgendwo ein veraltetes mysqldump im Einsatz, ... es gibt viele Möglichkeiten. Hast du denn mal selber in den Dump geschaut ob die Umlaute dort überhaupt richtig stehen? Dann sollte sich das auch importieren lassen... lustig wirds wenn UTF-8 als Latin1 gespeichert wurde. Eine PHP-Anwendung kann auch nochmal ein eigenes Charset-Setting haben, falls das neu installiert und nicht übernommen wurde. Das muss dann auch wieder stimmen.

Musst also letztlich schauen, wie stehts in der alten Datenbank, wie stehts im Export, in der neuen Datenbank nach dem Import, ... also herausfinden an welchem Punkt der Umlaut flöten geht.

Denke es wird ziemlich aneinander vorbei geredet.

Beim vorher genannten rsync-Ansatz (und ähnliche Methoden) geht dd nicht. dd kann von sich kein Resume oder Tracking von Änderungen (man kanns basteln, mit LVM Snapshot, Copy-on-Write Overlays, aber... Aufwand).

Beim dd-Ansatz machst du also die gesamte Übertragung in einem Schritt offline und so lange wie das dauert, so lange dauert es dann eben. Wenn dir das lieber bzw. sicherer ist, dann ist das auch vollkommen in Ordnung. Da brauchen wir uns aber auch nicht den Mund fusselig reden zu Downtime und Optimierungsansätzen.

Deine Einwände mit Datenbank-Konsistenz, 2 Instanzen & Co. — das ist klar, diese Probleme hast du bei jeder anderen Anwendung doch auch, nicht nur bei Datenbanken. Aber es ist kein Problem, solange — der Zielserver die ganze Zeit nur im Rescue steht und brav Daten empfängt.

Erst im letzten Schritt geht der Quellserver ins Rescue, stellt die erforderliche Konsistenz her (Übertragung der letzten Änderungen von Rescue zu Rescue), und erst dann startet der Zielserver, mit den übertragenen, konsistenten Daten.

Klappt alles mit rsync ohne Probleme, vorausgesetzt man hat ein Dateisystem mit ordentlichen Timestamps. Und nicht FAT32 mit 2-Sekunden-Taktung. Ohne Timestamps weiß rsync nicht, was nochmal zu kopieren ist und was nicht…

Die Konsistenz spielt erst im letzten Schritt eine Rolle.

Zitat von isa

Da es sich um einen Dienst handelt, der auf eine Datenbank aufsetzt lässt sich das nicht im Livebetrieb erledigen, die muss dafür aus.

Du kannst alles im Livebetrieb mit rsync kopieren - du darfst es dann nur nicht verwenden. Also kopiert man im Livebetrieb dreimal mit rsync, anschließend der Reboot ins Rescuesystem. Im Rescuesystem kopiert rsync dann nur noch die wenigen Änderungen, die zwischen dem letzten Live-rsync und Reboot passiert sind - und nur das ist dann die Downtime. Meistens ist das akzeptabel...

Remote DB ist eben so. Latenz gilt für jedes Query einzeln, bei Seitenaufrufen mit vielen Queries summiert sich das dementsprechend. Obendrauf kommt dann noch die Bandbreite, die jedes Query benötigt. Hier wird oft zuviel abgefragt (SELECT * ohne Limit) was dann tatsächlich gar nicht benötigt wurde. Lokal fällt das oft nicht weiter auf, Remote tut es sehr schnell ziemlich weh. Da hast du dir mit mehreren Servern dann keine zusätzliche Performanz geschaffen, sondern nur einen schönen Flaschenhals gebaut.

Wenn deine Anwendung nicht speziell darauf optimiert worden ist, bist du mit der Remote DB auf dem Holzweg.

Mache ich so wie in EDIT2 vorgeschlagen, mit Partitionen gleicher Größe (250GB, 500GB oder 1TB) und obendrauf dann LVM.

Synology macht das auch so und nennt diesen Ansatz "Hybrid Raid".

Ansonsten kannst du dein Glück mit dateisystembasiertem RAID also ZFS odgl. versuchen. Klassisches RAID hält auch freien Speicher und unwichtige Dateien redundant, beim Dateisystem kannst du hier vielleicht etwas besser regulieren.

Wenn du eine scharfe DNS TTL eingestellt hattest, könntest du kurzfristig umsatteln. Alternativ wenn deine App es selbst unter mehreren alternativen URLs versucht. Ansonsten gibt es nicht viel, was du tun kannst. Ausfälle gibts auch bei Servern, und auch in der Cloud. Ausfallsicherheit gibt es nur mit entsprechender Vorbereitung.

Du kannst mit sshd -T testen welche Konfiguration tatsächlich gilt

# sshd -T | grep -i passwordauthentication
passwordauthentication no

yes dürfte da eigentlich nur heraus kommen, wenn das obere auskommentiert ist

aber in dem Fall braucht man es eigentlich auch gar nicht, da yes ohnehin der Default ist

irgendwie macht es also in beiden Fällen keinen Sinn und es bleibt dabei, daß das einfach nur Quark ist

Wenn das von Netcup her so kommt kannst du Netcup fragen wozu das gut sein soll...

Wenn Netcup das explizit auf yes setzen möchte wärs schöner das mit awk/sed an Ort und Stelle zu machen statt da einfach Sachen unten anhängen wo man nicht damit rechnet. Aber damit muss man bei vorgefertigten Images eben leben.

Ich benutze nie den Installer des Hosters sondern installiere immer selbst von den offiziellen Distro Images bzw. per debootstrap & Co.

Das PasswordAuthentication ist da ein Fremdkörper und war ursprünglich nicht Teil des Beispiels für den Match Block. Das wurde der Datei einfach nur angehängt.

Die Einrückung ist auch nur für den Menschen da, für den Match Block selbst spielt diese keine Rolle. Der Match Block geht bis zum nächsten Match Block oder bis zum Dateiende. Deswegen stehen die wenn dann auch ganz unten... irgendwo mitten rein geht nicht, auch wenn die Einrückung das an sich so suggerieren könnte.

Da gibts nicht viel zu erklären, das ist einfach Quark.

Bzw. wenn es ganz unten am Dateiende steht oft das Ergebnis von irgendwelchen Tutorials die nach dem Schema 'echo zeug >> datei' anhängen arbeiten weil Einzeiler sind toll und editieren ist ja zu kompliziert...

In der sshd_config manpage steht, "For each keyword, the first obtained value will be used." die letzte Zeile dürfte daher in deinem Fall ignoriert werden. Aber eine Garantie dafür gibts nicht, daher - lieber korrigieren so daß es keine doppelten Einträge gibt.

bei parted kannst du das mit resizepart vergrößern

Bist du sicher daß das der korrekte Wert ist?