Beiträge von voja

    das hier habe ich auf die Schnelle gefunden ...

    http://ietf.org/mail-archive/web/tls/current/msg11727.html

    Das ist ja auch schon älter und betrifft nicht TLS 1.3 als Protokoll. Da geht es doch um eine bestimmte Library, die EC implementiert. In kommerziellen Versionen der lib haben sie wohl die Verschlüsselung geschwächt. Nimmst Du eine andere Implementierung hast Du das nicht. Und ich finde jetzt im TLS 1.3 Standard nichts direktes dazu.

    von wo aus wird geprüft, also was ist die QuellIP? bitte mal mit MTRs in beide Richtungen an den Support wenden

    Ich habe tagsüber immer wieder ins Monitoring geschaut. Dort waren relativ viele IPv6 Aussetzer zu sehen, die immer so 5-10 Minuten gingen. Ich habe den Fehler aber nie „live“ gesehen. Wenn das Monitoring grün ist, bringt das mtr ja nichts. In der Historie waren Probleme zu Zielen innerhalb von Netcup und auch nach extern sichtbar. Es hat sich jetzt aber wieder alles beruhigt.

    Wie wichtig ist Ihnen eigentlich unsere doch recht hohe garantierte Mindestverfügbarkeit von 99,6% bei unseren VPS? Würde jemand von Ihnen VPS mit 98% Mindestverfügbarkeit kaufen, wenn der Preis dafür halbiert wäre?

    Ich habe nur einen VPS als Backup Speicherplatz. Ansonsten bevorzuge ich die Root Server wegen der hohen Verfügbarkeit und besseren garantierten Ressourcen. Ich nehme also nur beim Backup-System Abstriche bei der Mindestverfügbarkeit hin, nicht bei Produktiv Servern.

    Ich hatte eben gerade das Vergnügen mit FeFe. Was ist denn bei dem Typen falsch gelaufen?

    Wegen so einem Müll lese ich das Blog schon lange nicht mehr. Ich rate inzwischen auch davon ab.

    Ich weiß ja nicht ob er die Mail von Linus gelesen hat, aber ich würde die ganz anders verstehen. Es geht hier um die Art und Weise wie Leute behandelt wurden, die mitarbeiten möchten. Wenn man Code aus welchen Gründen auch immer nicht in den Kernel lassen will, sollte man das sachlich begründen können. Es sollte dann nicht darum gehen jemanden persönlich anzugreifen oder unsachlich fertig zu machen. Man kann auch durch die Blume sagen, dass Kernel Contributer sich an Regeln zu halten haben.

    Linus will soweit ich das verstanden habe eben so eine Sprechweise nicht mehr an den Tag legen, die in dem Zitat oben verwendet wurde.

    wenn ich hier das so lese von den unheimlich vielen Mails die da manche auf Grund irgend eines Monitorings erhalten,

    stelle ich schon die Frage in den Raum, ob die nicht 'failure by design' sind;

    die sind ja fast wie selbsterfüllende Prophezeiungen:

    "Netzverbindungen zusammengebrochen" -> des Netz bricht bei den vielen Alarmierungen garaniert zusammen :D

    Der Traffic, der von den Monitoring Nachrichten verursacht wird, ist zu vernachlässigen. Selbst wenn alle Monitoring Nachrichten synchron über die Leitung fliegen würden, könnte diese nicht mal annähernd ausgelastet werden, da die Nachrichten dafür viel zu klein sind. Selbst wenn man den TCP Overhead mit einrechnet, wird das der Anbindung noch nicht mal ein müdes Lächeln entlocken.

    Gibt es keine garantierte Bandbreite für vServer oder Rootserver mehr?

    Bei den Root-Servern findest Du die Infos in der Vergleichsübersicht, wenn Du bei Traffic-Flatrate auf das ? klickst.

    Die VPS haben „ungedrosselten“ Inklusivtraffic und danach 10 MBit/s. Es sind aber keine weiteren Verfügbarkeitsaussagen getroffen.

    traefik eignet sich perfekt als Reverseproxy für docker-compose. nginx hat definitiv auch Stärken als Reverse Proxy, vor allem in kniffeligen Fällen.

    HAProxy setzen wir in der Firma ein (teilweise auch zusammen mit nginx, das muss sich ja nicht ausschließen), das ist für manche Anwendungsfälle die einzig mögliche Lösung, da das haproxy Protokoll von den Serveranwendungen benötigt werden.

    Mir fehlt in der Liste noch Caddy, das eine leichtgewichtige Alternative ist. Für manche Anwendungen viel einfacher.

    Fazit: ich suche mir je nach Anwendungsfall die Software raus, die jeweils am Besten passt. Ich fahre mehrgleisig. Das erspart mir jede Menge Ärger.

    Wir reden jetzt aber nicht über diesen netplan.yaml Müll.

    Zum Thema netplan möchte ich noch loswerden, dass ich die grundlegende Idee gut finde, vor allem, wenn man die Alternative anschaut. netplan kann systemd-networkd konfigurieren. Das möchte ich weniger gerne direkt konfigurieren. Desweiteren kann netplan direkt Routing abbilden, was einige Scripte überflüssig macht, die ich auf Hostsystemen brauche. Dass yaml und Co. als Grundlage verwendet werden hat wohl damit zu tun, dass eine Verschachtelung benötigt wird, die man mit Section/Key/Value nicht übersichtlich abbilden kann. Das Teil kann halt viel.

    ABER: die Technik ist so neu, dass sie Bugs hat. Einer davon hat mich schon getroffen und verhindert für mich komplett den Einsatz von Ubuntu 18.04 als Hostsystem Betriebssystem. Wobei der wohl auch systemD mit angekreidet werden muss, aber systemD war nicht das Thema.