Beiträge von mainziman

    es läuft wahrscheinlich darauf hinaus, sich den eigenen DNS-Server samt DDNS-Update-Mechanismen sparen zu können;

    wobei ein Tipp:


    verwende den DynDNS-Anbieter Deiner Wahl und trage bei Deiner Domain z.B. sowas wie


    home CNAME host.dyndns.com


    ein; und IPv6 mit dynamischen IPs ist weder vernünftig noch sinnvoll; hier mein Skript welches auf meinem Router läuft, ich verwende als DynDNS Hoster DNShome und habe auch einen IPv6-Tunnel, da mein ISP IPv4only

    dieses Skript läuft per cronjob 5 mal pro Stunde (alle 12 Minuten); und es aktualisiert auch die eigene DNS-Zone, kein Hexenwerk;


    eine Detailfrage: bei den Root-Servern steht


    Sicheres und schnelles RAID10 (Hardware-RAID-Controller)


    beim Storage Server steht


    Sicheres und schnelles RAID 6 (Hardware-RAID-Controller)


    hier ist aber der Hase im Detail: bei Raid 6 können glzt. 2 Platten ausfallen, hingegen bei Raid 10

    ist es beim Ausfall von 2 Platten zu 1/3 wahrscheinlich, daß die Daten futsch sind ...

    (in beiden Fällen sind Netto-Nutzdaten bei 4 Festplatten jeweils die Hälfte)

    d.h. wenn man mit weniger Speicher (½ TB statt 1½ TB) sein auslangen findet,

    kann man auch einen Root-Server nehmen und hat dabei dann mehr ...

    (RS 2000 hat ja auch 480 GB)

    oder hab ich da was übersehen?

    Hallo,


    was kann im so eine Storage-Distribution, welche gibt es?

    oder ist das ein Linux wo man selbst installiert was man haben will - ownCloud, ...?

    wodurch unterscheidet sich dieser virtuelle Server - da ja auch KVM - im wesentlichen (jetzt nicht in Bezug auf Speichermenge) von einem Root-Server od. vServer (VPS)?


    header_checks funktionieren schon, es ist nur eine Frage

    wie du sie anwendest ...


    f. den Fall, daß Du es so gemacht hast

    header_checks = pcre:/etc/postfix/hdr_chks.pcre


    dann handelt es sich um regular expressions

    also in etwa so:

    /^from:[[:space:]].*(\<)?xxx\@xxx.de(\>)?.*$/ REDIRECT xxx@gmail.com


    wobei mit header_checks kannst Du es in der Form nicht lösen, weil Du nur eine Zeile

    jeweils betrachtest;


    Du kannst aber einen Pipe-Filter definieren, dieser in Kombination mit

    header_checks macht genau das ...

    das glaube ich weniger, Dir ist schon klar, um es mal mit einem korrektem Vergleich - der ja weiter oben von jemand anders mißlungen ist - wenn Du das ESP (hat nichts mit dem 32-bit Stack-Pointer Register der x86-Architektur zu tun) eines deaktivierst,

    ist das definitiv nicht die Schuld des Herstellers, wenn das Heck ausbricht ...


    so auch hier: wenn OS-Entwickler durch Schlamperei oder Vereinfachung - ohne böse Absichten - Features nicht oder nur teilweise verwenden, ist das nicht die Schuld des CPU-Herstellers ..., wenn dadurch andere genutzte Features zu Schwachstellen werden ...


    zum anderen Thema dieses Testtools: weil es vielleicht gar nicht möglich ist, weil dieses Problem gar nicht existiert; weil entsprechende Voraussetzungen am OS fehlen(!)


    vgl. das mit einem Tool, welches Dir sagt ob das System bei Framework X angreifbar ist,

    und es sein kann, daß Framework X gar nicht vorhanden ist, dann hier zu schlußfolgern, angreifbar zu sein,

    das ist dann kein gühender Aluhut mehr sondern ein geschmolzener Aluhut ...


    und windige Argumente sehen anders aus ...


    So seltsam es auch scheinen mag, aber die Testroutine

    https://github.com/ionescu007/SpecuCheck

    welche einem sagt, ob man tatsächlich mit Meltdown (unter anderem) ein Problem hat,

    läuft mit älteren Windows Versionen gar nicht ...

    Ist das wirklich ein Problem der CPU?

    (z.B. WinXP kann mit SSE gar kein Problem haben,

    es verwendet diesen Instruction Set gar nicht; WinXP x64 hingegen schon)

    Hay,


    richtig.

    Die Laufzeiteinbußen kommen, weil die OS jetzt um Intels Schlamperei herumprogrammieren müssen. Ob es mit der Prüfung durch die CPU selbst jetzt schneller wäre als durch angepasste Software, ist erst einmal Spekulation - die CPU-interne Prüfung wird auch ein paar Taktzyklen zusätzlich brauchen.

    mit Schlamperei meinte ich übrigens nicht die von Intel ...

    macht einen Unterschied, ob Du der Schlamperwei wegen alles nur FLAT machst,

    weil performant oder segmentierst und damit die internen Prüfmechanismen¹ der CPU richtig ausspielst;

    ist es ja nicht Intel alleine sondern auch ARM und bei AMD ist man sich auch nicht sicher,

    ob auch hier Probleme existieren ...


    nebenbei: der Vergleich mit dem FDIV-Bug hinkt


    ¹ die Existenz des 'Execute Disable Bits' machte erst Microsoft notwendig;

    intel hat für ein Security Problem in ihren Prozessoren keine Schuld, sondern die OS-Entwickler, weil sie nicht alle Kapazitäten des Prozessors nutzen?



    Auch das mit den schnelleren Laufzeiten... Techniken verändern sich, $Dinge werden optimiert. Das hat eigentlich seine Richtigkeit so.

    Genau; nur das mit den schnelleren Laufzeiten ... und Techniken verändern sich, widerspricht sich etwas ...

    oder anders gesagt: die Laufzeiteinbußen, welche diese Bugfixes jetzt mit sich bringen,

    wurde vorher durch Schlamperei gewonnen ...

    wobei die Meltdown Geschichte um es sarkastisch zu formulieren, hausgemacht ist;


    es sollte einem schon zu denken geben, daß bereits der i386er mit 64 TByte virt. Speicher umgehen konnte

    (auch der i286er mit 16-bit auch deutlich mehr virt. Speicher adressieren konnte als damals überhaupt denkbar war: 1 GByte)

    aber keine einzige OS-Implementierung - auch nicht Linux/Unix - das auch nur in Ansätzen verwendete;


    ich will hier Intel nicht in Schutz nehmen, aber Schuld an dem Ganzen hat hier Intel keine;


    auch sollte man sich hinterfragen, wie es sein kann, daß unter einem aktuelles OS - z.B. Windows 10 - Anwendungen kürzere Laufzeiten haben, wo doch das OS - der OS-Kern - deutlich schwerfälliger ist, als ältere OS Varianten - z.B. Windows XP;


    ebenfalls hinterfragen sollte man sich, bei Betrachtung der CPU-Spezifikationen aktuellerer CPUs, was es mit dem 'Execute Disable Bit' auf sich hat ...

    (es wär mir neu, daß ein Datensegment ausführbar wäre - aus der Reinheit der Lehre des Protected-mode aus Zeiten des i386er, der von einem 'Execute Disable Bits' nichts wußte ...)

    mein vServer (CentOS) hat folgende Dienste

    - named (DNS)

    - httpd (Apache)

    - opendkim

    - opendmarc

    - openvpn

    - squid

    - mysqld

    - postfix

    wenn ich den mit shutdown -r now neu starte ist der binnen 1-2 minuten wieder neu gestartet ...


    ..., ob das nur dessen Vermutung aufgrund beschädigter Dienste ist, oder ob sie wirklich im Syslog keinen Eintrag für das erhaltene ACPI-Signal stehen haben ...

    wenn dem so ist, daß zwar alle das Signal bekommen, und eben manche schneller sind, und das System derart beanspruchen, dann wäre es durchaus denkbar, daß zwar das Signal ankommt, aber es im Syslog nicht auftaucht, weil durch die Beanspruchung des Wirtsystems kaum Resourcen an den einen oder anderen Gast verteilt werden, und diese dann hart abgeschalten werden ...

    von daher wäre es von Vorteil das Signal nicht glztg. an alle vServer sondern in Tranchen versetzt um 20-30 Sekunden;


    wobei wieviele Gastsysteme sind auf einem Knoten/Wirtsystem?

    klar ein wesentlicher Unterschied besteht, ein 'Suspend-to-Disk' kann bei großen vServern in Summe länger dauern, weil nicht zwingend parallelisiert werden kann,

    aber das ACPI-Signal zum Shutdown bekommen alle glztg. und nach 5 Minuten und ein paar Sekunden kann der eigentliche Reboot des Wirtsystems stattfinden;

    da ja im Zuge dieser kritischen Updates (Meltdown, Spectre), die Wirtsysteme rebootet werden müssen, und dies auch einen Einfluß auf die Gastsysteme hat,

    mal die Frage: würde es denn Sinn machen, die Gastsysteme nicht zu rebooten, sondern in den 'Suspend-to-Disk' zu schicken?


    ich denke, wenn das die kleineren Gastsysteme (z.B. VPS100, VPS, RS1000, RS2000) sind,

    und diese auch nur einen Teil vom zugesicherten RAM verwenden, kann dies deutlich schneller gehen als ein Reboot,


    oder ist dies keine gute Idee?


    Probleme, daß Gastsysteme auf den Reboot nicht reagieren und echt hart abgeschaltet werden müssen, wäre damit aus dem Weg gegangen ...

    Der Vorgang ist mir noch nicht ganz klar, ein Reboot der Root-Server bring ja erst dann etwas wenn der Server und damit meine ich die VM/OS selbst den entsprechenden Patch erhalten hat. Dafür ist ja jeder Nutzer eines Root-Server selbst verantwortlich und kann nicht von netcup gesteuert werden.

    Ja und Nein, eine VM hat keinen direkten CPU-Zugriff,

    von daher ist es hinreichend, wenn das Host-System gefixt ist;

    da aber auch die VM sich - weil eigener Kernel - auf die CPU einstellt,

    macht dies schon Sinn, weil durch das Bugfixen des Host-Systems,

    auch der Guest eine gefixte CPU bekommt ...