Beiträge von frank_m

    Warum würde man das wollen?

    Am Ende der Einrichtung des neuen Server werden die DNS Einträge umgesetzt auf die neue IP und alles ist gut.

    Wechselst du aber die IP des Servers, dann

    - musst du die Basiskonfiguration anpassen

    - Firewallregeln anpassen

    - Serverkonfigurationen anpassen

    - Zugänge bei dir zu Hause anpassen ...

    Im Grunde machst du die Neu-Einrichtung ein zweites mal. Es gibt nur wenige Sachen, die du nicht anfassen müsstest.

    Aber auch beim Debian 11 Server kann ich in der SSH-Konsole alles mit meiner deutschen Tastatur richtig eintippen.

    Ja, dafür ist auch das System verantwortlich, auf dem der SSH Client läuft. Die Einstellungen auf dem SSH Server sind dafür nicht relevant.

    Der Verdacht mit dem Tastatur-Layout auf dem Server dürfte also der entscheidende sein. Daran wird es liegen.

    frank_m:

    Da Du anscheinend eine funktionierende Lösung und Anleitungen hast, wäre es super, wenn Du diese auch teilen würdest:)

    Oh sorry, das seh ich erst jetzt.

    Ich benutze folgendes Script:

    https://github.com/trick77/ipset-blacklist

    Die Anleitung auf der Seite bis zu Ende lesen, das Erhöhen des ipset Limits war bei mir erforderlich. Zumindest für IPv4. Das Script beinhaltet auskommentiert auch die sed Aufrufe für IPv6. Da müssen iptables Einträge und ipset Listen natürlich angepasst werden. Ist aber kein großes Problem, das ganze für IPv4 und IPv6 aufzusetzen. Wobei IPv6 bei den Blocklisten im Moment noch keine wirkliche Rolle spielt.

    Dann ist es jetzt an der Zeit mit tcpdump zu schauen, was am Server ankommt. Und überprüfe mit netstat -tulpen, welche Ports auf welchen Interfaces offen sind.

    Übrigens Hinweis: Ich halte absolut gar nichts von diesen Installations-Scripten. Die fuhrwerken sonstowo in der Konfiguration rum, wo sie absolut gar nichts verloren haben. Wer weiß, was die angerichtet haben.

    Ja, die VM zeigt immer 2 GHz an. Die Frage ist, ob die Anzeige richtig ist. Leitet das Hostsystem den tatsächlichen Takt weiter? Immerhin ist die CPU virtualisiert und hat nichts mit der physikalischen CPU auf dem System zu tun. Es ist denkbar, dass dort immer nur der Basistakt gemeldet wird und keine dynamischen Anpassungen.

    Mit netfilter, also dem Linuxkernelmodul, das die eigentliche Firewall von Linux ist, ginge das sehr wahrscheinlich auch, habe da aber auch keine vernünftige Anleitung zur Hand.

    Ich mache das mit ipset. Es gibt einige nette Anleitungen dazu im Netz. Es gibt im Netz einige Blacklists mit bekannten "bösen" IP-Adressen, z.B. abuseipd. Einige bieten für Privatkunden kostenlose Listen an. Ich habe ein Script, dass aus 4 oder 5 solcher Quellen die Listen herunterlädt, zusammenfasst und dann die Backlist daraus generiert - im Moment gegen 172.000 IPv4 und 6.000 IPv6 Adressen.

    Naja, das ist halt wie mit deinem TurboBoost zu Hause. Die hohen Taktfrequenzen werden nur erreicht, wenn einzelne Cores benutzt werden. Bei hoher Auslastung aller oder vieler Cores des Prozessors bleibt es beim Basistakt.

    Ja, klar, Werbung hin oder her. DSL "bis zu 250 MBit/s" liefert auch nicht aus jeder Quelle 250 MBit/s, und ein BMW 320i hat weder 320 PS noch fährt er 320. "Max. 3,35 GHz" sind laut Prozessorspec ganz klar möglich - von daher stimmt die Aussage.

    Ich habe den RS 1000 G9 extra wegen der garantierten 1000Mbit-Anbindung und dem unlimitierten Traffic angemietet, aber mehr als 200-300Mbit kriege ich aus der Kiste einfach nicht raus, weil die CPU voll ausgelastet ist.

    Was machst du denn damit? Aus welcher Quelle kommen die Daten? Ich erreiche regelmäßig über 1000 MBit/s in der Anbindung zu schnellen Servern.

    In IMAP kann man Ordner ja markieren, u.a. ob sie bei jedem Abruf aktualisiert werden oder ob sie überhaupt abgerufen werden. Ist der Ordner vielleicht mal so markiert worden?

    Ich nutze IMAP nicht in Outlook, aber irgendwo in den Untiefen der Konfiguration kann man sich die Ordnerliste anzeigen lassen. Ich glaube, es gibt sogar eine extra Ansicht "Ordner" auf der Ebene, wo auch Kalender oder ToDos sind. Da sind üblicherweise noch haufenweise Ordner, die sonst nie angezeigt werden. Da kann man aber die Eigenschaften der Ordner verändern. Dort würde ich mal ansetzen.

    Hallo,

    Ich spiele gerade ein wenig mit lxd/lxc und einem ZFS Pool herum.

    Bei lxd hat man ja üblicherweise ein Image, aus dem man einen Container startet. Das Image kann z.B. ein Ubuntu-20.04 minimal sein, ich habs aus einem Online Repository geladen. Die Container kann man dann erweitern und u.a. spezifische Software für die jeweiligen Dienste installieren. Dabei wird aber meines Wissens nur die Differenz zum Image gespeichert. Alles, was sich nicht ändert, wird zur Laufzeit des Containers aus dem Image geladen und nicht noch mal separat gespeichert, was die Sache sehr effizient macht.

    Im ZFS Pool kann ich auch sehen, wie unter default/images das Image und unter "default/containers" die Container gespeichert sind, mit ihren jeweiligen Speicherplatz-Anforderungen.

    Nun wurde das Image automatisch aktualisiert. In der Folge wurde das veraltete Image unter "default/deleted/images" geschoben und bleibt da nun auch liegen, da es ja noch die Basis für die Container ist. Entsprechend hat sich der Speicherplatz-Bedarf im Pool deutlich erhöht, da nun eine zweite Instanz des Images gespeichert wurde, die im Grunde (zumindest bislang) nicht benötigt wird.

    Die Frage ist nun: Kann ich die Image Referenz der Container aktualisieren, so dass sie auf das neue Image zeigen und nicht mehr auf das alte? Dann könnte man das alte löschen. Mir ist klar, dass das nicht trivial ist, da der Inhalt der Images nicht 100% identisch ist. Eine Online Recherche hat nichts ergeben. Es gibt offensichtlich nur wenige Leute, die das Problem haben.

    (Aber irgendwie hätte ich trotzdem erwartet, dass es die Engpässen in Richtung vom Sever mit der besser Anbindung zu dem mit der geringeren gibt und nicht umgekehrt)

    Ja, das sollte man erwarten. Der schnellere Server kann den langsameren ja fluten. Aber ich glaube, dass es nicht so ist, ist der beste Beweis, dass die TCP Algorithmen funktionieren.

    Ich hab spaßeshalber den Congestion Algorithmus mal von CUBIC auf BBR umgestellt. Ergebnis: Katastrophe. Die Retransmissions sind genau so hoch, aber die Bandbreite G8 -> G9 bricht auf 300 MBit/s zusammen. Das hatte ich anders erwartet.

    Aber: Die Algorithmen scheinen Einfluss zu haben. Vielleicht ein Ansatzpunkt für weitere Untersuchungen.