Login
Newsletter
Werbung

Thema: Debian-Server-Zertifikate gefährdet: Let's Encrypt schaltet TLS-SNI-01 ab

87 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von Debilian Profi am Mo, 21. Januar 2019 um 16:34 #

Hallo,

also das sollte jedem Debian-Admin schon lange bekannt sein.
Ich installiere schon seit ewigen Zeiten die Backport-Version.
Ist nun mal der Preis von zu abgehangener Software.

Ich hatte damals auch mal mit Pinning hantiert, kann ich nur von
abraten, das saugt danach immer mehr deps ins system.

Bleibt eventuell noch selber compilieren.

Aber backport ist am bequemsten.
Nutze ich auch für meinen Quassel-Core.

Debilian Profi :x

[
| Versenden | Drucken ]
  • 2
    Von Verfluchtnochmal-05995bd7b am Mo, 21. Januar 2019 um 16:44 #

    Es ist Schwachsinn und nicht der Preis von abgehangener Software wenn deren einziger Zweck schlichtweg wegbricht und das Probem nur durch ein update in stable zu lösen ist statt alle auf backports zu verweisen

    [
    | Versenden | Drucken ]
    1
    Von Ghul am Mo, 21. Januar 2019 um 19:09 #

    Mich wundert ja, dass man keine neue Version in stable eingebracht hat, wenn klar war, dass die alte Version eine nicht reparierbare Sicherheitslücke enthält weil man ganz andere Domain-Validierungsvarianten benötigt.

    Klar in Debian stable werden normalerweise keine Pakete mit neuen Funktionen eingebaut, aber hier ist das ein spezieller Fall, wo es nötig gewesen wäre.

    Backports sind natürlich eine feine Sache, aber in dem Fall sollte das anders gelöst werden als über Backports.

    [
    | Versenden | Drucken ]
    • 1
      Von klopskind am Mo, 21. Januar 2019 um 20:46 #

      Mal unabhängig davon, dass ich von Let's Encrypt nicht sonderlich viel halte, wundert mich das ebenfalls.

      Ich wette, dass die Lücke tausendfach auf Debian-Systemen ausgenutzt werden wird, falls die Lücke in stable bestehen bliebe.

      Bisher dachte ich, dass Pakete in Debian stable, die nur mit unvertretbar großem Aufwand auf der Version aus dem vorangehenden Freeze gehalten werden können, also wenn das Flicken bekannter Sicherheitslücken mangels Ressourcen zu müßig wird, auf eine neue Upstream-Version gehoben werden dürfen. Diese Pakete bedürfen allerdings einer Ausnahme gemäß der Debian-Paketrichtlinien. Zum Beispiel gilt das für firefox(-esr) (Finde leider die Liste jener Pakete nicht mehr.).
      Ist das nicht hier genau der Fall? Oder muss eine Entscheidung zu dieser Ausnahme bereits vor Release-Termin (Stretch) gefällt worden sein?

      Dann gibt es auch noch Pakete, die keine Sicherheitsgarantien seitens des Security-Teams erhalten. Dazu gehört mWn chromium. Leider finde ich auch diese Liste nicht mehr.
      Zählt acme etwa zu dieser Sorte Pakete, sodass Sicherheitslücken bestenfalls via backports behoben werden?

      Daher wirkt diese Entscheidung inkonsistent und nicht nachvollziehbar. Weiß hier jemand mehr über den Entscheidungsfindungsprozess, bzw. ob dieser in diesem Fall überhaupt stattfand?

      [
      | Versenden | Drucken ]
      • 1
        Von unreal am Di, 22. Januar 2019 um 07:48 #

        Es gibt seit vorgestern einen Bug Report dazu:
        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919933

        [
        | Versenden | Drucken ]
        1
        Von /o\ am Di, 22. Januar 2019 um 09:42 #

        "Ich wette, dass die Lücke tausendfach auf Debian-Systemen ausgenutzt werden wird, falls die Lücke in stable bestehen bliebe."

        So funktioniert das nicht. Die Lücke ist auf den let's encrypt-Servern, weshalb die das Protokoll abgeschaltet haben, womit sich diese ausnutzen lässt.

        Und es gibt durchaus immer mal wieder neue Software-Versionen in Stable, aber nur im Point-Release. Es kann also passieren, dass deshalb bald ein neues Point-Release angestrebt wird.

        [
        | Versenden | Drucken ]
        • 1
          Von Anon am Di, 22. Januar 2019 um 10:04 #

          Der Sta(b)le Zweig ist nicht umsonst so benannt.

          Da ist die Software selbst unmittelbar beim dem Release hoffnungslos veraltet, weshalb fälschlicherweise vermutet wird, dass sie weniger Bugs hat. Das gilt aber auch nur mit Einschschränkung und höchstens für ein paar Grundkomponenten wie den Linux Kernel.

          [
          | Versenden | Drucken ]
          • 1
            Von Anonymous am Di, 22. Januar 2019 um 13:33 #

            Das habe ich anders in Erinnerung.

            Der Stable-Zweig heisst nicht deshalb Stable, weil die Einzelkomponenten als besonders stabil gelten, sondern das ZUSAMMENSPIEL aller Pakete.

            Dass die Pakete gut abgehangen sind, ist nicht Ziel der Sache, sondern ein Nebeneffekt, weil die Stabilisierung des Gesamtkunstwerks so lange dauert.

            [
            | Versenden | Drucken ]
            • 1
              Von Anon am Di, 22. Januar 2019 um 16:06 #

              Sind wir doch mal ehrlich.

              Debian hat 50000 Pakete. Der Anteil hauptberuflich Beschäftigter liegt wahrscheinlich im unteren zweistelligen Bereich. Wahrscheinlicher ist er aber bei 10 - 20 Personen.

              Mit dieser Besetzung - unabhängig von Ihrer Qualifikation - kannst du nur wenige Pakete wie kernel, apt, apache, nginx usw. stable halten. Noch nicht einmal daran entwickeln. Es geht hier lediglich um die Integration in die Prozesse.

              Sobald du übliche Nutzung (Webserver, Datenbankserver, Printserver, etc.) verlässt, spürst du einen rasanten Stabilitätsabfall. Dieser rasante Abfall beginnt schon bei GNOME. Vom Remotedesktop ganz zu schweigen.

              [
              | Versenden | Drucken ]
              • 1
                Von 1ras am Di, 22. Januar 2019 um 18:16 #

                Ich merke vor allem einen rasanten Stabilitätsabfall bei Rolling Releases, weil da jedes kleine Update zur Überraschung wird. Reicht mir schon bei Android wo nach Update der Apps immer mal wieder was anderes nicht funktioniert. Produktiv arbeiten möchte ich damit nicht müssen. Auch Windows 10 Nutzer machen gerade die Erfahrung was es bedeutet, immer die aktuellsten Bugs zu erhalten.

                Ich hingegen will nicht die aktuellsten Bugs, mir sind gut abgehangene Bugs auf welche ich mich in Ruhe einstellen kann bei weitem lieber.

                [
                | Versenden | Drucken ]
                • 1
                  Von irgendwer am Di, 22. Januar 2019 um 20:57 #

                  Rolling Release hat seinen Reiz, aber man muss eben dran bleiben. Hier gehen Sicherheitsupdates oftmals mit neuen Versionen und damit nötigen Configänderungen, neuen Abhängigkeiten etc. einher.

                  Bei Debian kann man Jahre ohne größere Updates auskommen. Mal zwei Monate verpasst? Kein Problem, wenige bis ein paar hunder Megabytes Updates, 2-3 Minuten Zeit, das war's. Configänderungen muss man sich nur alle paar Jahre mal genauer ansehen.

                  Bei Rolling Release kann man immer aktuell bleiben, super, muss es aber auch. Mal ein halbes Jahr wenig Zeit und nur Sicherheitsupdates und keine neuen Features? Nö. gibt's nicht. Entweder du bist dann hoffnungslos veraltet und kriegst nicht einmal Sicherheitsaktualisierungen und hast dann, wenn du nochmal Zeit hast, wirklich die A*karte gezogen und brauchst viele Stunden Frickelei, um alles an Changes nachzuholen oder du bleibst permanent dabei.

                  Wer jedoch eh täglich seine Updates einspielt und jederzeit Zeit hat, evtl. nötige Configchanges mal eben auszuführen, für den ist das wirklich eine echt gute Wahl. (Und wer das bei hunderten betreuten Rechnern mal eben macht, den will ich sehen ;-) )

                  [
                  | Versenden | Drucken ]
                  • 1
                    Von 1ras am Di, 22. Januar 2019 um 22:33 #

                    Das ist alles richtig was du beschrieben hast, aber es reicht leider nicht. Es kommen nämlich auch immer wieder neue Bugs hinzu. Man braucht deshalb ein sehr gutes Backupsystem um jederzeit ein Rollback auf die Vorgängerversion machen zu können, wenn wieder mal eine für den eigenen Anwendungsfall wichtige Funktion nach dem Update plötzlich wegbricht.

                    Das beste Paketmanagementsystem hilft einem da in der Regel nicht weiter, weil im Zweifelsfall die neue Version die Konfigurationsdateien im Homeverzeichnis umgeschrieben hat und diese zur alten Version nicht mehr kompatibel sind.

                    Damit nicht genug, es kommt auch noch ein weiteres Problem hinzu, man muss eigentlich bei jedem Update sofort alle erforderlichen Funktionen der neuen Softwareversion durchtesten. Ansonsten fällt einem der Fehler irgendwann auf und man kann ihn zeitlich mit dem Update nicht mehr direkt in Verbindung bringen.

                    Rolling Release sind nett zum Spielen und Experimentieren aber disqualifizieren sich in meinen Augen für produktives Arbeiten. Ich bin deshalb froh, dass es mit Debian ein System gibt bei welchem die Versionsstände auf lange Zeit stabil bleiben. So tippe ich diesen Text gerade auf Jessie/oldstable.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von irgendwer am Mi, 23. Januar 2019 um 12:18 #

                      Ja, das schätze ich an Debian durchaus: Insbesondere wie dort mit Konfigurationsänderungen bei dist-upgrades umgegangen wird. Eine schöne Eskalationskette: Hinweis und Auswahlmöglichkeit bei Installation plus Sicherung beider.

                      Jessie find ich da aber schon recht alt. Es liegt in Kürze aus dem Standard-Support und das current stable ist schon deutlich länger da, als es bis zu diesem Zeitpunkt dauern wird. Mehr als ein Jahr lasse ich mir üblicherweise nicht für das Upgrade Zeit. (Jaja, Ausnahmen bestätigen da auch bei mir mal die Regel; immerhin OK, solang die Sicherheitsaktualisierungen fließen.)

                      Rolling Release ist übrigens nicht gleich Rolling Release. Was mich an Binärdistributionen ala Arch Linux da stört, ist dass man wirklich die Kette exakt so braucht, wie sie beim Distributor kompiliert wird. Updated man ein Paket, aber nicht eines in der Abhängigkeitskette, kann man auf Fehler stoßen, die so beim Distributor gar nicht auftreten können. Also Updated man wirklich immer alles.

                      Das ist bei Source-Distributionen ala Gentoo nicht notwendig. Das eigene Kompilat ist immer schön aufeinander abgestimmt, auch wenn kein anderer in der Welt die exakt gleichen Versionen in den Abhängigkeitsketten haben sollte.

                      Source-Distributionen haben dafür natürlich andere Nachteile... ;-)

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 12:45 #

                        Wenn "Was mich an Binärdistributionen ala Arch Linux da stört, ist dass man wirklich die Kette exakt so braucht, wie sie beim Distributor kompiliert wird. Updated man ein Paket, aber nicht eines in der Abhängigkeitskette, kann man auf Fehler stoßen" vorkommen kann ist eintweder das Paketformat oder der Maintainer scheisse

                        RPM kennt exakte Abhängigkeiten und die werden acnhegzogen oder das Paket lässt sich nicht installieren wie wenn zB Paket A und B verschiedene Versionen von Library C als Abhängigkeit haben lässt dnf/yum sowas nicht zu und einer der beiden Maintainer muss nachgeben, in der Regel wird das Paket dass die ältere version voraussetzt einfach neu gebaut

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von irgendwer am Do, 24. Januar 2019 um 13:07 #

                          Eben, das ist der Punkt : Mit Rolling Release benötigst du gerne mal das halbe System neu, wenn einzelne Pakete in neuen Versionen vorliegen. Denn alles andere wäre unsinnig und die Paketmanager sorgen daher dafür – wie du schon sagst – dass die Abhängigkeitskette umgehend mit aktualisiert wird. Und – wie du ja auch mit deinem letzten Satz schon sagst – zieht es nicht nur beim Endnutzer eine Menge neue Arbeit nach sich, sondern auch bei den Maintainern.

                          Du verdeutlichst hier meine Kritikpunkte noch einmal schön.

                          Wie gesagt, man kann das gerne haben, bei einzelnen Systemen. Es skaliert halt nur nicht.

                          [
                          | Versenden | Drucken ]
                        0
                        Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 12:47 #

                        "Das ist bei Source-Distributionen ala Gentoo nicht notwendig. Das eigene Kompilat ist immer schön aufeinander abgestimmt" ist im Zweifel einfach Unsinn weil wenn eine Library einen neue Major Version bekommt und warum auch immer alle sie benutzenden anderen Binaries nicht neu gebaut werden knallt es genauso und das wesentliuch fürher als bei korrekt versionisierten Binärpaketen

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von irgendwer am Do, 24. Januar 2019 um 13:03 #

                          Wenn die Source-Distribution ihre Pakete nicht korrekt versioniert und die Binärdistribution dagegen sehr gut versioniert, dann knallt es bei ersteren eher?

                          Gut, da mag etwas dran sein. Aber was hat das mit der Realität zu tun?

                          [
                          | Versenden | Drucken ]
                          • 0
                            Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 13:34 #

                            Viel!

                            Problem 1: package hplip-3.18.12-1.fc28.x86_64 requires libnetsnmp.so.30()(64bit), but none of the providers can be installed
                            - cannot install both net-snmp-libs-1:5.7.3-38.fc28.x86_64 and net-snmp-libs-1:5.8-3.fc28.x86_64
                            - cannot install both net-snmp-libs-1:5.7.3-36.fc28.x86_64 and net-snmp-libs-1:5.8-3.fc28.x86_64
                            - cannot install the best update candidate for package hplip-3.18.6-11.fc28.x86_64
                            - problem with installed package net-snmp-libs-1:5.8-3.fc28.x86_64
                            Problem 2: package hplip-3.18.12-1.fc28.x86_64 requires libnetsnmp.so.30()(64bit), but none of the providers can be installed
                            - cannot install both net-snmp-libs-1:5.7.3-38.fc28.x86_64 and net-snmp-libs-1:5.8-3.fc28.x86_64
                            - cannot install both net-snmp-libs-1:5.7.3-36.fc28.x86_64 and net-snmp-libs-1:5.8-3.fc28.x86_64
                            - package hplip-gui-3.18.12-1.fc28.x86_64 requires hplip(x86-64) = 3.18.12-1.fc28, but none of the providers can be installed
                            - cannot install the best update candidate for package net-snmp-libs-1:5.8-3.fc28.x86_64
                            - cannot install the best update candidate for package hplip-gui-3.18.6-11.fc28.x86_64

                            [
                            | Versenden | Drucken ]
                            • 0
                              Von irgendwer am Do, 24. Januar 2019 um 13:52 #

                              Ein Auszug aus einer Fehlermeldung einer Binärdistribution (Fedora 28) bzgl. Probleme bei der Auflösung von Abhängigkeiten soll jetzt zeigen, dass diese den Source-Distributionen bzgl. Auflösung von Abhängigkeiten überlegen sind und es weniger "knallt"? Ehm... ja.. ehm... das könntest du mal näher erklären.

                              [
                              | Versenden | Drucken ]
                              • 0
                                Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 14:23 #

                                Die so-namen werden AUTOMATISCH in den Dependencies generiert und es ist halt schon eine andere Hausnummer ob der Build in einem isolierten Buildroot läuft oder am Zielsystem "make install" im Spiel ist

                                Bei der Source-Distribution wird es im Zweifel lustig wenn irgendwo ein Fehler auftritt, ein Update von RPM-Paketen läuft in einer Transaktion die in mehreren Schritten geprüft wird

                                Im Beispiel schlägt schon der erste fehl noch vor einem Download

                                Wenn Deps formal erfüllt sind wird runter geladen und dann läuft erste einmal ein Transkationstest ob zB 2 der zu aktualisierenden bzw. installierenden Pakete meinen die selbe Datei mitzubringen was nicht oft aber doch vorkommtund ein Konflikt ist der bevor noch ein Bit angefasst wird die ganze Transaktion stoppt

                                [
                                | Versenden | Drucken ]
                                • 0
                                  Von irgendwer am Do, 24. Januar 2019 um 16:26 #

                                  Die so-namen werden AUTOMATISCH in den Dependencies generiert und es ist halt schon eine andere Hausnummer ob der Build in einem isolierten Buildroot läuft oder am Zielsystem "make install" im Spiel ist
                                  Warum sollte das eine das andere ausschließen? Es ist in beiden Fällen eine isolierte buildroot und es wird in beiden Fällen ein make install ausgeführt (natürlich parametrisiert).
                                  Bei der Source-Distribution wird es im Zweifel lustig wenn irgendwo ein Fehler auftritt, ein Update von RPM-Paketen läuft in einer Transaktion die in mehreren Schritten geprüft wird

                                  Meinst du etwa in einer Source-Distri wird das make install einfach ins root gelassen? Ehm... nope. Man ist hier nicht mehr in den 80ern. Du kennst offensichtlich keine modernen Source Distributionen.

                                  Es ist z.B. bei Gentoo schon seit Jahrzehnten möglich, Pakete zu deinstallieren, dabei als Binary (sein eigenes, höchst persönliches) zu sichern, und bei Bedarf einfach wieder zu installieren (ohne erneute Compilierung). Es ist echtes Paketmanagement und weit entfernt von einer einfachen Automatisierung von ./configure, make und make install... (Gentoo nur als Beispiel, es gibt andere)

                                  Im Beispiel schlägt schon der erste fehl noch vor einem Download

                                  Dependency checking - ist bei Source Distribitionen auch einer der ersten Schritte.
                                  Wenn Deps formal erfüllt sind wird runter geladen und dann läuft erste einmal ein Transkationstest ob zB 2 der zu aktualisierenden bzw. installierenden Pakete meinen die selbe Datei mitzubringen was nicht oft aber doch vorkommtund ein Konflikt ist der bevor noch ein Bit angefasst wird die ganze Transaktion stoppt
                                  Transaktionen sind beim Paket Management ein "nice to have" aber kein "must have". Letztendlich läuft es in beiden Fällen – ob mit oder ohne – auf's selbe hinaus. Der Paketmanager kennt alle Dateien eines Paketes und installiert dieses nur, wenn sie kein vorhandenes überschreiben (auch bei instantan aus Sourcen erstellten Paketen). Wenn nun im Prozess der Installation sich ein späteres Paket als solches inkompatibles Paket herausstellt (apropos, warum sollte das überhaupt vorkommen?) und daher nicht installiert wird, gibt es im System keine Daseinsberechtigung mehr für die Pakete, die nur wegen dieses Paketes installiert wurden -> sie können deinstalliert werden. Paketmanager erkennen das und sagen dem Ausführenden des Paketmanagers Bescheid, was zu tun ist (z.B. apt autoremove, emerge --depclean -a, etc.).

                                  Soweit ich weiß arbeitet auch rpm hier nicht anders. Yum macht einen Dep-Check (wie apt) und übergibt rpm die Paketinstallation, welches die Pakete der Reihe nach installiert und (das ist ist nun die "Transaktion" daran) automatisch vorhergehende Installationen rückgängig macht, wenn ein Paket aus irgend einem Grund nicht fehlerfrei installiert. (Genau das habe ich so schon beobachten können.)

                                  Letztendlich real nichts anderes als das, was auch andere Paketmanager machen. Nur dass diese orphaned packages mitunter erst einmal liegen lassen und dem Nutzer die Wahl überlassen, auch diese Installationen rückgängig zu machen – oder halt eben nicht. Das kann nämlich durchaus von Vorteil sein: Wenn man weiß, dass mit einer Änderung an anderer Stelle die Installation gut durchläuft., dann muss man nicht wieder alles von Vorne installieren.

                                  [
                                  | Versenden | Drucken ]
                                  • 0
                                    Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 17:07 #

                                    Transaktionen sind eben kein nice-to-have und orphaned files zu entfernen und das System sauber zu halten ist eine der wichtigsten Eigenschaften damit ein System auch nach 10 Jahren noch sauber ist

                                    Alle meine produktiven Maschinen wurden im August 2008 aufgesetzt bzw. der Master aus dem seit dem tag alles geklont wird

                                    [
                                    | Versenden | Drucken ]
                                    • 0
                                      Von irgendwer am Do, 24. Januar 2019 um 17:13 #

                                      Sag mal ließt du überhaupt was ich schreibe? Die Antwort ist als Antwort auf meinen Beitrag doch total sinnlos, da sie etwas voraussetzt (Transaktionen als Voraussetzung orphaned files zu entfernen), das eben gerade dort schon widerlegt wurde.

                                      [
                                      | Versenden | Drucken ]
                                      • 0
                                        Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 17:38 #

                                        Herrgott nochmal es geht nicht um die Transaktion als solches sondern um den Schritt Transaktionscheck BEVOR übehaupt daran gedacht wird ein Bit am System anzufassen und dazu ist nonaned eine Transatkion die Grundvoraussetzung statt "wir fangen mal an und bei Problemen rollen wir zurück und hoffen dabei ja niemals Fehler zu machen weil sonst endet das irgendwann in einem undefinierten Zustand"

                                        [
                                        | Versenden | Drucken ]
                                        • 0
                                          Von irgendwer am Do, 24. Januar 2019 um 18:03 #

                                          Und das ist, was ich schon vor zig Beiträgen gesagt habe: das macht jeder Paketmanager ungefähr gleich.

                                          Welcher Paketmanager installiert denn ein Paket und überschreibt damit Dateien eines anderen Paketes? Oder fängt damit an ein Paket ins System zu entpacken, welches Dateien überschreibt? Ich kenne keinen.

                                          Und diese Prüfung wiederum bewahrt einen auch nicht davor, Paketinstallationen zurückrollen zu müssen. Es kann alles mögliche schief gehen. Den Check gibt es nicht, der im Vorfeld alles abcheckt und alle etwaigen Fehler abdeckt. Auch bei Fedora o.ä. nicht. Auch Fedora muss es können, vorhergehendes deinstallieren zu können. Auch dort passiert es, dass es bei der Installation des x-ten Paketes plötzlich zu einem Fehler kommt (bzw. gerade da, rpm+yum bzw. dnf ist da alles andere, aber nicht das non-plus-ultra). Und wenn man das eh schon kann, kann man genau das auch nutzen.

                                          Dein "Transaktion" ist hier höchstens als Buzzword tauglich, ein Blender. Man nutzt einen toll klingenden Begriff, um sich abzuheben, weil der Begriff in ähnlichen anderen Produkten nicht auftaucht, die zwar ungefähr das gleiche machen (mitunter sogar besser), das dabei aber anders benennen.

                                          All das wurde so mehr oder weniger schon gesagt. Ist das denn so schwer zu verstehen?

                                          [
                                          | Versenden | Drucken ]
                                          • 0
                                            Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 18:20 #

                                            Meinetwegen - Damit du glücklich bist

                                            Bevor ich 40 Maschinen mit einer Source-Distribution verwalte schneide ich mir trotzdem die Pulsadern raus versus RPM-paket ins lokale Repo und ab gehts im Zweifel in Rollout-Schritten je nach Wichtigkeit der Zielmaschinen und auch noch 3 Tage später sieht jede Maschine ganz genau das gleiche Binary

                                            Und ja im echten Leben optimierst du auf Hardware-Baseline weil dir der Hypervisor dafür sorgt dass -march=native am ganzen Cluster läuft

                                            [
                                            | Versenden | Drucken ]
                                            • 0
                                              Von irgendwer am Fr, 25. Januar 2019 um 10:12 #

                                              Schon wieder eine total unverständliche Antwort.

                                              Erstens – wie kommst du hier jetzt auf Source-Distributionen für zig Maschinen? Mein Einstieg in den Thread war doch gerade eben das genaue Gegenteil!? (Ich setze durchaus Source Distris ein, aber eher privat und sicher nicht auf dutzenden Serversystemen.) Nur weil man zur effizienten Verwaltung nicht Fedora benötigt, heißt das doch nicht, dass man eine Source Distri nehmen sollte!? Da wären ja noch Debian und Derivate ala Ubuntu LTS, auch SLES und andere SuSE-Derivaten traue ich das zu, und auch aus der RH-Welt würde ich Fedora als letztes einsetzen (eher CentOS, SL, vielleicht noch RHEL wenn's denn sein muss).

                                              Und auch bei Binärdistributionen: wenn sie 3 Tage später exakt die gleichen Binaries sieht, fehlen mitunter aktuelle Sicherheitsupdates.

                                              Zweitens: "--march=native" in einer VM ist das selbe wie "--march=native" auf der nackten Hardware. Man kann den Virtualisierer natürlich auch so einstellen, dass er nicht-generische Features maskiert, so dass dem nicht so ist, aber das ist ja nun wirklich nicht sinnvoll, die Leistungsfähigkeit der CPU so bewusst zu beschneiden. Wer macht das denn? (Nur um das zu verifizieren hab ich das mal spaßeshalber innerhalb einer VM auf einem CentOS-Host gegengecheckt [CentOS weil du offensichtlich RH-basiertes vorziehst, Debian gäb es hier weit mehr]: gcc -march=native -Q --help=target | grep -- '-march=' | cut -f3 -> haswell bzw. core-avx2 je nach gcc-Version auf dieser Haswell-Host-CPU ... insofern: jepp, Standardeinstellung auch dort ist Host-native==VM-native)

                                              Und im echten Leben optimiere ich in einem Cluster daher sicher _nicht_ auf --march=native. Denn ich habe keine Lust, den Cluster komplett auszutauschen und alles neu zu kompilieren, sobald ich ein Stück Hardware erweitern möchte... (--march=native ist das Gegenteil von Portabilität: es kompiliert exakt auf die CPU, die der Compiler vorfindet; da können schon zwei verschiedene CPUs eines Herstellers der gleichen Generation Probleme machen, seit Intel Featuresets fleißig deaktiviert um Kaufanreize für teurere CPUs zu setzen; spätestens bei Generationswechseln oder gar CPUs anderer Hersteller hast du oftmals schlicht keine Chance. Da ist es wesentlich sinnvoller ein generisches march zu setzen und vielleicht noch eine etwas modernere Arch als mtune. Das stört dann nicht die Migration von Maschinen auf einen anderen Host.

                                              Und ja, heterogene Cluster zu betreiben, die verschiedene CPUs verschiedener Hersteller enthalten, kann durchaus sinnvoll sein. Zum Beispiel wenn über Generationen hinweg die CPU mit dem aktuell besten Preis-Leistungs-Verhältnis nicht immer vom gleichen Hersteller stammt. Man muss eben _nicht_ immer gleich den ganzen Cluster tauschen, ich kann auch dieses Jahr auf Epyc setzen, obwohl ich letztes Jahr noch Xeon nachgerüstet habe – oder umgekehrt. Man muss sich nicht dazu zwingen lassen, in Zukunft die schlechtere CPUs zu kaufen, nur weil man sich einmal dafür entschieden hat.

                                              Die Option "native" bleibt dabei natürlich jederzeit offen, wenn man bestimmte sehr hungrige VMs an eine Gruppe mit exakt gleicher CPU bindet... spätestens an dem Punkt ist ein Maskieren von CPU-Flags durch den Hypervisor von starkem Nachteil. Und ja, dann ist "--march=native" natürlich angebracht. Aber sicher nicht als Default und der Cluster gibt mir das sicher nicht vor.

                                              [
                                              | Versenden | Drucken ]
                                              • 0
                                                Von Verfluchtnochmal_5987109 am Fr, 25. Januar 2019 um 19:59 #

                                                Wer das macht? Jeder mit Hirn der hot-migration benutzt!

                                                Du kompilierst in dem Fall mit native um ausser der baseline im cluster nichts anfassen zu müssen wenn die älteste Kiste endlich weg ist und du selbige entsprechend hoch setzt

                                                Ganz ehrlich: Deine Einzelmaschine interessiert eigentlich keine Sau weil die in der Regel auch nichts zu tun hat wo du einen wirklichen Unterschied bemerkst, ist zwar nett zum rumspielen und Schwanz verlängern aber ansonsten irrelevant

                                                [
                                                | Versenden | Drucken ]
                                                • 0
                                                  Von irgendwer am Sa, 26. Januar 2019 um 11:24 #

                                                  Eine Clusterweite Baseline mit Hirn? Ich zweifel daran.

                                                  Es ist eine Wahl zusätzliche CPU-Features erst gar nicht abzubilden. Man verliert so insbesondere die modernsten Features seiner CPUs. Kann man durchaus mit leben, optimal ist es jedoch nicht.

                                                  Denn eine andere Wahl ist es, wie ich schon sagte, dies über Migrationsgruppen zu realisieren. Man verliert so hot-migration nicht generell, kann dennoch modernere Features in einem heterogenen Cluster fahren. Ich benötige schließlich die Migrationsmöglichkeit nicht ausschließlich und nicht für jede VM von jeder zu jeder Maschine. Bestimmte leistungsbedürftige VMs dürfen gerne nur mit einem Teil des Clusters kompatibel sein. Das inhouse-Wiki dagegen kann gerne mit der baseline da hin wandern, wo grad am wenigsten los ist.

                                                  Denn was ich an der Stelle wirklich nicht will: aktuelle, leistungsfähige Features moderner CPUs generell für alle ausklammern.

                                                  Beispiel: Der Cluster besteht zum größten Teil aus Skylake aus 2016+2017 – zu neu um sie zu ersetzen. Zusätzlich wurden 2017 und 2018 neuere Skylake-SP nachgerüstet (mehr Performancebedarf, zu altes ersetzt, weshalb auch immer). Sollte ich jetzt auf AVX-512 usw. verzichten, nur weil es nicht in der baseline ist? Außerdem ist aktuell vielleicht ein Epyc die bessere Wahl, besseres Preis-/Leistungsverhältnis, etc. insb. auch bei den Lizenzkosten (1-Socket wo sonst 2-Socket notwendig ist): Eine CPU eines anderen Herstellers drückt natürlich die Baseline ungemein, also auf die bessere CPU generell verzichten?

                                                  Da gibt's nen tollen Spruch zu: Dat kannste schon so machen, dann isses aber halt kacke. :-P

                                                  [
                                                  | Versenden | Drucken ]
                                                  • 0
                                                    Von genau am Sa, 26. Januar 2019 um 19:48 #

                                                    Wer braucht schon die vielen neuen cpu-flags, wenn man 10 Jahre alte Hardware nutzt.
                                                    Ich selber habe 12 Jahre gentoo intensiv genutzt, es ist schon genial.

                                                    Es gibt auch Admins die damit Tausende Server betreiben, aber die sind sicherlich Alle
                                                    Ahnungslos ;)

                                                    Noch wichtiger war mir aber das "USE=", damit kann man prima die Deps extrem veringern,
                                                    das bringt wirklich was.

                                                    Aber streitet euch gerne weiter :)

                                                    [
                                                    | Versenden | Drucken ]
                                                    • 0
                                                      Von irgendwer am So, 27. Januar 2019 um 09:38 #

                                                      Naja, richtig brauchen tut man's wohl nicht. Aber praktisch kann's sein. ;-)

                                                      Und auch vor 10 Jahren gab es da schon neues. Hauptsächlich zwar Intels Weggang von FSB (nix Flag), aber Flags kamen auch damals schon neue hinzu. Vorher schon mit und ohne x87, MMX, SSE, etc.; ... aesni kam doch so rund vor 10 Jahren, oder? Das ist mal echt was praktisches – Full Drive Encryption oder TLS-Verbindungen (openssl via Kernel-crypto, gerade am frontend-http-lb-proxy praktisch) nebenbei ohne Leistungsverlust (jaja, auch der ist verschmerzbar...). Könnte man schon in die VM durchreichen wollen.

                                                      Gentoo hat auch sicher seinen Anwendungszweck. Im Spezialfall auf jeden Fall. Ich hab's lange Zeit selber viel genutzt. Für tausende Server wäre mir der Aufwand jedoch zu hoch. Neben des reinen Wartungsaufwandes durch Rolling Release (halt Versionswechsel bei Sicherheitsupdates – eher keine reinen Sicherheitspatches ohne API-Wechsel) schon alleine der Kompilationsaufwand. Entweder bastelt man da quasi seine eigene Binärdistri, indem man die Binaries zentral sammelt und verteilt (binary package server) oder man verschwendet (1000 Rechner?) für's Compilieren so viel elektrische Leistung wie gleich mehrere Vollzeitstellen kosten. ;-)

                                                      USE-Flags sind da bei Gentoo extrem wichtig, weil man so weniger Libs kompilieren muss. Das ist aber etwas, das andere weniger trifft, weil man da ja nix kompiliert und ob man nun eine lib mehr oder weniger rein zieht... wen juckts. Bzw. ist vieles ja zur Laufzeit optional. Das heißt, es ist zwar beim Build der Distribution notwendig, man installiert es aber nachher nicht zwangsweise alles. USE-Flags sehe ich daher eher als Notwendigkeit einer Source-Distribution. Sehr praktisch für diese, aber größtenteils unnötig bei Binärdistributionen.

                                                      Und, naja, streiten... nennen wir es Meinungsaustausch. Ich liebe solche in dieser Form. Wär schon blöd, wenn alle immer der gleichen Meinung wären. :-D

                                                      [
                                                      | Versenden | Drucken ]
                                                      • 0
                                                        Von Verfluchtnochmal-05995bd7b am So, 27. Januar 2019 um 20:25 #

                                                        Und ja, AES-NI bzw. AVX gibt es seit SandyBridge, das meiste was danach gekommen ist reisst dich aber in der Praxis nicht raus +- in paar Prozent die du mit mehr pysischen Servern die für mehr als eine Baseline notwendig ist erstmal rechtfertigen musst

                                                        Da hab ich im Zweifel lieber weniger Hosts was sich auf Stromverbrauch/Kühlung und USV-Laufzeiten deutlich auswirkt

                                                        [
                                                        | Versenden | Drucken ]
                                                        • 0
                                                          Von irgendwer am Mo, 28. Januar 2019 um 09:00 #

                                                          Siehe: https://www.pro-linux.de/news/1/26688/comm/633021/re25-schon-lange-bekannt.html ... es sind - ein paar Prozent und das ist somit halt eben bares Geld + USV die man spart: ergo etwas, dem du hier ganz bewusst einen Wert gibst.

                                                          Bzw. man hat einfach Mehrleistung: AES, AVX1/2, AVX-512, FMA3/4, etc. sind ja durchaus nicht ohne Grund vorhanden.

                                                          Ja, richtig. Kann man drauf verzichten. Muss man aber nicht!

                                                          [
                                                          | Versenden | Drucken ]
                                                          • 0
                                                            Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 12:15 #

                                                            Nochmal: Bring belastbare Zahlen aus eigener Erfahrung und Erzählungen Dritter die auch gerne über die APectre/Meltfdown Pacthes heulen mit Schaerzahlen die ich nicht nachvollziehen kann

                                                            AES - Ja, gibts seit 11 jahren
                                                            AVX - Ja gibt es seit 11 jahren

                                                            AVX2 etc. nett aber leider keine paar Prozent, habe ich auch gehofft als der Cluster von SandyBridge auf Broadwell ging gibt die Praxis aber nicht her

                                                            [
                                                            | Versenden | Drucken ]
                                                            • 0
                                                              Von irgendwer am Mo, 28. Januar 2019 um 16:22 #

                                                              Du musst nicht nutzen, was du nicht willst. Wenn andere den Vorteil erkennen und nutzen wollen, ist es jedoch gut, dass es diese Möglichkeit gibt.

                                                              Apropos, dann sind ja die aktuellen AMD Epycs echt was für dich. Nackte Leistung mit vielen Kernen für viele VMs, halt nur bei AVX512 nicht ganz auf Intel-Niveau, aber das brauchst du ja nicht.

                                                              Ach ne, Intel und AMD haben ja auch bei gleicher Generation verschiedene Flags und wie du ja schon sagtest: " keine HA und Live-Migration zwichen Maschinen mit unterschiedlichen CPU-Flags"... Ist also nix für DICH*sic*, DU*sic* wirst damit ja DEIN*sic* HA verlieren.

                                                              *SCNR*...

                                                              [
                                                              | Versenden | Drucken ]
                                                              • 0
                                                                Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 16:39 #

                                                                Du Schwachkopf hast doch gefragt wer bitteschön eine Cluster-Basline fährt und ich habe es dir erklärt

                                                                Jeder der bei Verstand ist und in der Lage Benchmarks auf seinem Workload zu fahren um abzuschätzen ob ganz wenig mehr Performance Einschränkungen bei der Live-Migration aufwiegt

                                                                Normalerweise fährt man Nodes auch nicht auf 100% womit 2-5% in der Theorie praktisch nicht relevant sind

                                                                [
                                                                | Versenden | Drucken ]
                                                                • 0
                                                                  Von irgendwer am Mo, 28. Januar 2019 um 16:52 #

                                                                  Deine Ausdrucksweise spiegelt dein Kenntnisniveau herrlich wider. Dem lässt sich nichts mehr hinzufügen – zwecklos.

                                                                  [
                                                                  | Versenden | Drucken ]
                                                                  • 0
                                                                    Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 16:59 #

                                                                    lol - Glaub doch du was du willst, ich mache den Job schon einige Zeit abseits von Spielzeugumgebungen

                                                                    [
                                                                    | Versenden | Drucken ]
                                                                    • 0
                                                                      Von irgendwer am Mo, 28. Januar 2019 um 17:08 #

                                                                      Hehe, der Profi in Person.

                                                                      ... oder auch: die Auswirkungen des Dunning-Kruger-Effektes.

                                                                      [
                                                                      | Versenden | Drucken ]
                                                                      • 0
                                                                        Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 19:00 #

                                                                        *lol* nach über 10 Jahren Virtualisierung im Datacenter-Bereich und einem laufenden 365/24 Betrieb was willst du mir denn da erzählen?

                                                                        [
                                                                        | Versenden | Drucken ]
                                                                        • 0
                                                                          Von irgendwer am Di, 29. Januar 2019 um 09:30 #

                                                                          Oh, 10 Jahre, glaub ich dir! Ehlich. Aus der Zeit stammen ungefähr deine Erkenntnisse, die du hier an den Tag legst (auf die du zuletzt aber nicht mehr ganz so sehr gepocht hast). Stolz darauf sein musst du aber nicht. Jahre lang nix dazulernen ist jetzt nicht all zu besonders. Es ist sogar ein eher häufig anzutreffendes Phänomen.

                                                                          Nein ehrlich, guck dir den Thread doch nochmal an. Du hast von Vorn herein in eine Kerbe gehauen, dabei x-mal Beiträge nicht richtig gelesen (dennoch darauf hin wild mit Beschimpfungen um dich geworfen) und offensichtlich ein Problem mit neuen Features (ja nicht nur VM-Techniken, auch CPU-Features generell) bzw. dir fehlen (fehlten?) beim Hauptthema Virtualisierung eindeutig Kenntnisse, die so längst überholt sind (du hast ja noch zig Beiträge lang behauptet, Live-Migration würde dein Vorgehen erzwingen, was eindeutig nicht stimmt; redest ja noch immer von clusterweiter Baseline bzw. Flags pro Blech, als ob man das nicht von VM zu VM einzeln bestimmen könnte). Das ist so Stand der Technik bei bzw. vor der Einführung RHEL 6 gewesen und ja, es verwundert nicht, dass das grob 10 Jahre her ist.

                                                                          Was willst du noch mehr an Belegen, dass du deine vehemente Verteidigungsstrategie überdenken solltest?

                                                                          Tu dir selbst einen gefallen, LERNE daraus. Hier zuzugeben, dass du falsch lagst, ist natürlich schwer – für viele zu schwer. Von mir aus antworte gar nicht oder wieder in der Form wie zuletzt: "mimimi - immer 10-mal-mehr als du!!11einself". (Eine häufig anzutreffende Strategie wäre jetzt noch, Rechtschreibfehler zu finden und dich nur noch darauf zu beziehen; es lassen sich aber bestimmt auch noch andere Nebenschauplätze eröffnen).

                                                                          Aber wenn du hier schon nicht von deinem hohen Ross runter kommen kannst, dann informier dich doch einfach mal selber, was möglich und sinnvoll ist. VM- _und_ CPU-Techniken. Da wird nicht aus Jux und Dollerei weiter dran entwickelt. Da mit Vehemenz neue Techniken erst Jahre später zu adaptieren bringts nun wirklich nicht.

                                                                          [
                                                                          | Versenden | Drucken ]
                                                                          • 0
                                                                            Von Verfluchtnochmal-05995bd7b am Di, 29. Januar 2019 um 15:19 #

                                                                            "redest ja noch immer von clusterweiter Baseline bzw. Flags pro Blech, als ob man das nicht von VM zu VM einzeln bestimmen könnte" - Natürlich kannst du blöder Hund das aber du kannst eine Maschine die AVX2 aktiviert hat dann nur mehr auf Hosts migrieren die es unterstützen ohne sie neu zu starten

                                                                            Mach mal eine Live-Migration einer VM mit -march=skylake Binaries auf einen Haswell-Host du Vollpfosten und "illegal cpu instruction" Segfaults werden dein neuer Freund

                                                                            Natürlich sind neue CPU-Techniken sinnvoll aber eben nicht unconditional wenn du damit a) Einschränkungen bei der Migration in Kauf nehmen und b) mehr Aufwand bei der Pflege von Paketen hast

                                                                            Dann musst (oder solltest zumindest) du Genie nämlich den Gewinn neuer CPU-Flags in deinem echten Workload versus den Nachteilen gegenüberstellen und nur wenn der eindeutig höher ist bringt dir die Vorgehensweise auch nur im Ansatz was

                                                                            Im echten Leben laufen deine Kisten nicht auf 100% Last und das darfst du dann auch noch bei einem Gewinn von sagen wir mal 5% Broadwell versus Skylake mit einberechnen

                                                                            Der Sprung SandyBridge nach Broadwell ist in der Praxis nämlich weit geringer als man meinen möchte und die gesteigerte IPC kommt nicht nur von den neuen CPU-Flags - Einfach mal eigene Benchmarks fahren weil nur dass zB AVX512 verfügbar ist haeisst noch lange nicht dass dein Workload davon profitiert

                                                                            Wenn du Pech hast tut er das nur bei kurzen Peaks falls überhaupt weil eigentlich jedem bekannt sein müsste dass nicht alle Kerne im Dauerlauf mit AVX/AVX2/AVX512 die volle Leistung liefern sondern realtiv schnell runter regeln

                                                                            [
                                                                            | Versenden | Drucken ]
                                                                            • 0
                                                                              Von Verfluchtnochmal-05995bd7b am Di, 29. Januar 2019 um 15:23 #

                                                                              Und nein man bleibt nicht ewig auf einem alten Clustermode aber wenn man zB noch eine Machine hat deren geplanter Austausch in 1-2 Jahren stattfindet ist es eine Überlegung wert es hinaus zu zögern und im Anschluss nach dem Hochsetzen des Clustermode den Compiler nochmals anzuwerfen statt VMs zu fahren die nur auf bestimmten Nodes lauffähig sind

                                                                              Wenn dir dann nämlich einer deiner geilen Skylake Hosts wegbricht hast du ein weit grösseres Problem weil du die darauf laufenden VMs auf einen anderen konzentrieren musst und DANN hast du einen grösseren Leistungseinbruch als sie schlichtweg auf alle verbleibenden Nodes verteilen zu können

                                                                              [
                                                                              | Versenden | Drucken ]
                                                    0
                                                    Von Verfluchtnochmal-05995bd7b am So, 27. Januar 2019 um 19:18 #

                                                    Blöderweise brauchst du dann aber deutlich mehr Maschinen für das gleiche Redundanzlevel und musst dich auch noch entscheiden was auf welchen laufen soll

                                                    Die CPU-Flags sind ja nett aber du solltest vielleicht auch mal in der Praxis Vergleiche machen und da sind die Unterschiede oftmals nicht so gross dass sie zusätzliche Hosts rechtfertigen anstatt im 3-5 Jahres-Rythums einfach der Reihe nach auszutauschen und die Baseline auf den kleinsten gemeinsamen Nenner zu setzen

                                                    Geh mal weg von deiner schönen Theorie und dem Papier und verifiziere deine Aussagen im echten Leben!

                                                    [
                                                    | Versenden | Drucken ]
                                                    • 0
                                                      Von irgendwer am Mo, 28. Januar 2019 um 08:55 #

                                                      Blöderweise brauchst du dann aber deutlich mehr Maschinen für das gleiche Redundanzlevel und musst dich auch noch entscheiden was auf welchen laufen soll

                                                      Hä, warum? Warum sollte ich da nur ein einziges Extra-Blech benötigen? Das Durchreichen der Flags lässt sich per VM bestimmen. Ich habe 2 Bleche und die eine VM läuft mit dem einen Flag-Set und die andere mit einem anderen. Bei libvirt (Pacemaker+co.) z.B. via host-model und feature flags im Detail bestimmbar. Kann das deiner nicht? VMware?

                                                      Die CPU-Flags sind ja nett aber du solltest vielleicht auch mal in der Praxis Vergleiche machen und da sind die Unterschiede oftmals nicht so gross dass sie zusätzliche Hosts rechtfertigen anstatt im 3-5 Jahres-Rythums einfach der Reihe nach auszutauschen und die Baseline auf den kleinsten gemeinsamen Nenner zu setzen

                                                      Zusätzliche Hosts sind halt nich (s.o.). Ich nehme die gleichen Kisten wie du und konfiguriere den Virtualisierer anders – und damit natürlich einzelne VMs – um mehr Leistung herauszuholen. Und ja, der Unterschied kann enorm sein.

                                                      Und weil das fallspezifisch ist, halt eben _nicht_ das gleiche Flagset über den ganzen Cluster, weil ein großer Teil der Hosts da eben keinen Vorteil von hat und somit beliebig auch zwischen neu und alt migriert werden kann.

                                                      Geh mal weg von deiner schönen Theorie und dem Papier und verifiziere deine Aussagen im echten Leben!
                                                      Es ist vielleicht nicht _dein_ Leben, das mag sein. Hab ich auch nicht behauptet. Man kann – wie ich schon sagte – natürlich auch einfach Leistung verschenken. Ist ja üblich, also auch in anderen Bereichen nicht unüblich.

                                                      [
                                                      | Versenden | Drucken ]
                                                      • 0
                                                        Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 12:12 #

                                                        Weil du verdamm noch mal keine HA und Live-Migration zwichen Maschinen mit unterschiedlichen CPU-Flags machen kannst!

                                                        Schon mal einen Virtualisierungscluster im Produktivbetrieb gesehen?

                                                        [
                                                        | Versenden | Drucken ]
                                                        • 0
                                                          Von irgendwer am Mo, 28. Januar 2019 um 16:08 #

                                                          Du, ok, halten wir das fest, kannst das vielleicht nicht. Du bist aber – und das sagte ich schon mal – nicht die Welt. Nur weil du etwas nicht kannst, heißt das nicht, dass es nicht geht. Und wenn du trotz Hinweis darauf, dass es geht, es einfach nicht wahrhaben willst und dich auch nicht darüber informieren magst, dann ist das dein Problem und nicht meines.

                                                          Man kann einen Cluster aufbauen mit völlig unterschiedlichen CPUs und – ja nicht alle aber manche – Hypervisoren können nicht nur zwischen CPUs unterschiedlicher Generation sondern sogar verschiedenen Herstellern live migrieren (z.B: AMD vs. Intel). Welchen ich benutze nannte ich schon.

                                                          Das geht natürlich nicht von einer modernen Kiste auf eine ältere (die nicht alles der neueren kann) im host passthrough Modus (ala: VM sieht Host-CPU inkl. dem größten Teil der Flag). Natürlich nicht, soll ich das behauptet haben? Sicher nicht. Das hab ich aber so auch schon mehrfach gesagt.

                                                          Man kann auf diesem Cluster jedoch verschiedene VMs laufen lassen, die unterschiedliche Flags nutzen (wie ich schon sagte und sogar wie konkret). Und so die einen ausgiebiger und die anderen weniger ausgiebig migrierbar machen (wie ich auch schon sagte). Ich hab dir z.B. entsprechendes von zwei VMs gepostet: Völlig verschiedene Flagsets am gleichen Host. Aber du kannst ja nicht einmal richtig lesen und echauffierst dich herrlich über das vermeintliche Alter der Hosts mit diesen Flags. Lol.. was soll man da noch sagen...

                                                          Fazit: Raffste net, willste net.

                                                          Wenn du das nicht willst und dich auch einfach nicht darüber informieren willst, selbst wenn jemand dir sagt, dass das so geht, einfach weil du Recht behalten willst, dann ist das deine Sache. Soll mir doch egal sein. Bleib halt einfach auf deinem Wissensstand, wie du ihn dir vorstellst, wie so deine Welt funktioniert.

                                                          Ist nicht das erste Ding, das ich mache, von dem mir jemand weiß machen will, dass das gar nicht geht – ehrlich, bist da nicht der erste. :-P

                                                          [
                                                          | Versenden | Drucken ]
                                                          • 0
                                                            Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 16:45 #

                                                            Ich kann mir auch ein Loch ins Knie bohren

                                                            Du hast saudumm gefragt wer bitte bei CPU Features eine Cluster-Baseine setzen würde - Verdammt nochmal JEDER tut das weil für verschiedene Baselines schmeisst du Nodes in eigene Cluster

                                                            NIEMAND aber auch wirklich niemand mit Verstand mixt ohne Maskierung Maschinen verschiedener Generationen im selben Cluster, weder mit Proxmox noch mit VMware

                                                            [
                                                            | Versenden | Drucken ]
                    0
                    Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 12:28 #

                    Das ist auch bei hunderten Rechnern kein Problem, heutzutage virtualisiert man, hat Klone und Autotests und ein vernünftiges Deployment sprich die Produktivmaschinen bekommen nicht per Zufall irgendwelche Updates sondern von internen Cache-Repos nach Freigabe

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von irgendwer am Do, 24. Januar 2019 um 12:36 #

                      Seine eigenen Freezes aus einem eigenen Rolling Release abzuleiten führt die ganze Sache ziemlich ad absurdum – und man hat noch immer mehr Arbeit als direkt eine Release-Distribution zu nutzen, immerhin gibt es keine Sicherheitspatches, sondern man benötigt jedes mal einen neuen Freeze, der deutlich ausführlicher getestet werden muss als Sicherheitsaktualisierungen an sich. Insgesamt ist das noch mehr Blödsinn als direkt für jede Kiste einzeln Updates auszuführen – damit geht nur das einheitliche Management flöten und nicht noch die gesamten Vorteile eines Rolling Release.

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von Verfluchtnochmal-05995bd7b am So, 27. Januar 2019 um 20:58 #

                        Sprichst du aus der Theorie oder mit langjähriger praktischer Erfahrung?

                        Es kommt IMMER auf die Umgebung und Anforderungen an und steht und fällt im Zweifel mit dem Knowhow und dem Automatisierungsgrad der beteiligten Personen

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von irgendwer am Mo, 28. Januar 2019 um 09:21 #

                          Beides. Und _natürlich_ kommt es immer auf die Umgebung an. Tatsächlich wird das hier daher nur zum Teil genutzt. Aber es geht damit offensichtlich.

                          Als Beispiel. Ich habe in zwei verschiedenen VMs einmal:

                          $ gcc -march=native -Q --help=target | grep -- '-march=' | cut -f3
                          x86-64
                          $ cat /proc/cpuinfo | grep flags | head -n1
                          flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl eagerfpu pni cx16 popcnt hypervisor lahf_lm kaiser
                          $ cat /proc/crypto | grep aesni | head -n2
                          und einmal:
                          $ cat /proc/cpuinfo | grep flags | head -n1
                          flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt
                          $ gcc -march=native -Q --help=target | grep -- '-march=' | cut -f3
                          haswell
                          $ cat /proc/crypto | grep aesni | head -n2
                          name : __ctr-aes-aesni
                          driver : cryptd(__driver-ctr-aes-aesni)
                          Es geht damit offensichtlich. Der eine sieht nicht einmal sse3, der andere auch sse4.2, avx2 und aes. Der eine nutzt den Hardware-Kryptobeschleuniger, den anderen könnte ich dafür auch zum alten Opteron rüber migrieren.

                          (btw: man sieht auch, man hat sich bzgl. der unteren noch für was anderes entschieden bzgl. Performance, siehst du es? :-D
                          Und ja, ist nicht der neueste Cluster daher ist selbst die untere nicht ganz optimal... aber nicht jeder hat das Geld 3 Jahre alte Kisten zu ersetzen.)

                          [
                          | Versenden | Drucken ]
                          • 0
                            Von Verfluchtnochmal-05995bd7b am Mo, 28. Januar 2019 um 12:24 #

                            Der Cluster ist nicht nur nicht neu und nicht ganz optimal sondern ein Witz dafür dass du so grosse Töne spuckst weil Hardware ohne SSE3 muss 15 Jahre alt sein

                            Schlaue Menschen fahren nicht mehr als 2-3 Hosts mit ausreichender Dimensionierung weil sie Hardwarekonsolidierung verstanden haben und dann sind auch Leasingverträge über 3 oder 5 Jahre kein Thema

                            Und wenn du tatsächlich mehr Hosts BRAUCHST dann brauchst du auch Lösungen wo Live-Migration zwischen allen VMs und Hosts funktioniert um Ausfälle und Wartungsfenster zuverlässig und wietgehend automatisch u kompensieren

                            Und für automatische Verteilung der VMs auf den aktiven Nodes wäre halt eine Clusterbaseline sinnvoll

                            [
                            | Versenden | Drucken ]
                1
                Von irgendwer am Di, 22. Januar 2019 um 20:51 #

                Das Besondere an Debian ist, dass dies hier sogar sehr gut funktioniert, trotz keiner großen Geldmasse im Hintergrund. Auch weit abseits besagter "üblicher Nutzung". Debian ist _das_ Beispiel, dass es auch ohne große kommerziell agierende Distributoren geht.

                Ich wüsste kein System, das hier über die Breite mehr bietet. Selbst nicht bei den wirklich umsatzkräftigen wie Red Hat. Da fehlt einfach – gerade abseits des Mainstreams außerhalb von z.B. Gnome – zu viel. Brauchst du irgend eine Software, findest du sie bei Debian, kannst sie installieren und sie tut's. Bei Red Hat findest du sie im Standardrepo schon mal bestimmt nicht, vielleicht bei EPEL+co., aber selbst da ist es unwahrscheinlicher als schon Debian main, geschweige denn contrib oder weitere Repos. Nur weniges kommerzielles wird für Red Hat angeboten aber nicht für Debian – das wiederum verwundert nicht.

                [
                | Versenden | Drucken ]
                1
                Von klopskind am Di, 22. Januar 2019 um 22:30 #

                Sind wir doch mal ehrlich.

                Debian hat 50000 Pakete. Der Anteil hauptberuflich Beschäftigter liegt wahrscheinlich im unteren zweistelligen Bereich. Wahrscheinlicher ist er aber bei 10 - 20 Personen.

                ...

                Dafür funktioniert das Debian-Projekt aber erstaunlich gut, oder?

                "Sind wir doch mal ehrlich." Die Zahlen haben Sie sich aus dem Allerwertesten gezogen. Worauf basieren Ihre Annahmen für die "wahrscheinlichen" Werte?

                Stretch/Buster beinhalten aktuell 25.311/29.174 Quellpakete, siehe [1]. Davon sind derzeit maximal 538 Pakete als verwaist gekennzeichnet, siehe [2].
                Die derzeit registrierten Projektteilnehmer (m/w/d), siehe [3]: 126 contributors (w/o guest account), 228 Maintainer (w/o guest account), 978 (uploading) Developers. Aktuell gibt es etwa 684 aktiv Beitragende Personen und 6 Teams, siehe [4].
                Und unter [5] kann man relativ verlässlich beruflich assoziierte Mitglieder ausfindig machen, indem man nach Mailadressen sucht, bspw. @intel.com (3), @hp.com (1), @hpe.com (3), @redhat.com (2), @canonical.com (15), @ubuntu.com (51), @collabora.com (2), @google.com (3 + 1 Team). Das macht nach Adam Riese also mindestens 80 beruflich assoziierte, direkt zum Debian-Projekt Beitragende. Und da fehlen all' die kleinen Buden und Selbstständige, die beruflich Support und Consulting speziell für Debian leisten.

                Außerdem: Wenn Ihr Argument wirklich ziehen soll, so müssten andere Distributionen signifikant andere Zahlen aufweisen. Welche OSS-Projekte - insbesondere Linux-Distributionen - wären das Ihrer Meinung nach, die nicht unter dem selben Ressourcenmangel und Manpower leiden?

                Und um schon einmal die Zahlen für die Pakete etwas in Relation zu setzen, hilft ein kurzer Blick auf diese Tabelle, auch wenn die Werte darin etwas veraltet sind. Dort finden sich nämlich einige Linux-Distributionen mit der selben Größenordnung an Quellpaketen, denen es ebenso an Manpower mangelt, eventuell mit Ausnahme von Fedora oder Ubuntu; Ich kenne die Zahlen nicht. Der Argumentationslogik zufolge läge es nun in Ihrer Zuständigkeit, zu belegen, dass die zuvor erwähnten Defizite des Debian-Projektes in anderen Distributionen in signifikant verschiedener Quantität vorliegen.

                [
                | Versenden | Drucken ]
            1
            Von irgendwer am Di, 22. Januar 2019 um 20:42 #

            Sie ist nicht "hoffnungslos veraltet", sondern in einem Zustand, indem angenommen werden kann, dass sie so wie vorgesehen funktioniert und weniger Bugs enthält als neuere Versionen. Das ist üblicherweise auch der Fall. Sicherheitslücken, die später auftreten, werden natürlich gefixt. So funktioniert das durchaus sehr gut.

            Wenn alte Software in ihrer Funktion so weit eingeschränkt wird, dass ein außerplanmäßiger Wechsel auf eine neuere Version indiziert ist, dann wird genau das durchaus auch angegangen.

            Ich kenne im Falle certbot noch keine konkreten Pläne, würde mich aber nicht wundern, wenn das dennoch zeitnah passieren wird. Wenn nicht, muss es in dem Fall die Version Backports tun, die es immerhin gibt(!), die aber wirklich nur die Ausnahme darstellen sollten. (Backports erfahren weniger Pflege, das sollte jedem Bewusst sein.)

            [
            | Versenden | Drucken ]
            • 0
              Von Verfluchtnochmal-05995bd7b am Do, 24. Januar 2019 um 12:51 #

              "ich kenne im Falle certbot noch keine konkreten Pläne, würde mich aber nicht wundern, wenn das dennoch zeitnah passieren wird"

              Zeinah wäre jetzt weila m 13.02. ist es zu spät, das Zeug muss auch noch seinen Weg zu den Usern finden und dort bedarf es ggf. Anpassungen

              Mir sowieso schleierhaft wer in aller Welt TLS-SNI-01 und warum benutzt

              [
              | Versenden | Drucken ]
              • 0
                Von irgendwer am Do, 24. Januar 2019 um 13:20 #

                Wenn TLS-SNI-01 sowieso nicht genutzt wird, dann ist es am 13.02 ja nun nicht zu spät. :-P (der musste sein)

                Wer es dennoch nutzt, findet in den Backports passende Pakete – und zwar nicht erst jetzt, sondern schon lange. Backports gehören zu Debian wie EPEL zu Red Hat – nur dass man bei Red Hat _deutlich_ mehr auf EPEL angewiesen ist als bei Debian auf Backports, wenn man das Dingen nicht nur zum Schönstehen hat.

                Und ja, TLS-SNI-01 ist durchaus sinnvoll. Zum Beispiel wenn DNS-Challanges mangels API beim Provider nicht möglich ist, man Port 80 aber dicht hat und auch nicht öffnen will, kann TLS-SNI-01 eine sinnvolle Option sein. Man kann die Validierung auf dem https-Port (443) durchführen, ohne einem Henne-Ei-Problem oder sonstigen Kollisionen ausgesetzt zu sein.

                Mit dem Verlust von TLS-SNI-01 benötigt man wieder Port 80. Das heißt dort muss auch für die, die nicht per Link eh direkt auf https kommen sondern nur die URL eingeben, Weiterleitungen auf seine https-Seiten, weil Browser bei existentem http-Port noch immer erst einmal dort ihr Ziel vermuten und die Seite laden wollen.

                [
                | Versenden | Drucken ]
                • 0
                  Von Verfluchtnochmal-05995bd7b am So, 27. Januar 2019 um 21:01 #

                  Und weiter?

                  Den Redirect und HSTS hacken normale Menschen nicht jedes mal per Hand rein, dafür sucht man wenn man es selbst nicht gebacken bekommt Leute die 20 Zeilen Script hinbekommen und nicht für jeden Scheissdreck in den Configs rumgraben

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von irgendwer am Mo, 28. Januar 2019 um 09:26 #

                    Die 20 Zeilen Skript sind da irrelevant. Deine Aussage ist nur, dass dir das egal ist und du mit Port 80 zusätzlich leben kannst. Aber du bist nicht der Nabel der Welt. Mit dem Wegfall von TLS-SNI-01 fallen Optionen und Möglichkeiten weg. Das kannst du für dich vielleicht relativieren, es bleibt aber dennoch ein Fakt.

                    [
                    | Versenden | Drucken ]
      0
      Von erledigt am Di, 29. Januar 2019 um 15:58 #

      In meinem Stretch wurde das backport automatisch in stable verwandelt. Also der certbot.

      [
      | Versenden | Drucken ]
0
Von schmidicom am Di, 22. Januar 2019 um 07:55 #

Wer im eigenen Apache das Modul md für die Let's Encrypt Zertifikate benutzt sollte auch nachbessern.

MDCAChallenges http-01

[
| Versenden | Drucken ]
1
Von feneks am Di, 22. Januar 2019 um 16:02 #

Diese veraltete Certbot-Version 0.10.2-1 beherrscht nur die Validierung per TLS-SNI-01 ...

Die alte stable Version beherrscht auch die HTTP-01 Challenge.

[
| Versenden | Drucken ]
  • 1
    Von irgendwer am Di, 22. Januar 2019 um 20:34 #

    Man sollte den Artikel dem entsprechend abändern. Natürlich beherrscht auch der alte die alten Verfahren wie HTTP-01. Im standalone- und Dateimodus (webroot). Jedoch nicht als Apache-Plugin oder via nginx. Und das ist der Punkt, auf den sich hier wohl bezogen wird, ohne dies zu erwähnen.

    Wer mit certbot älter als 0.21.0 eh schon die HTTP-01-Challange nutzt, der kann das auch weiterhin. Wer bisher mit dem Apache-Plugin gearbeitet hat und auf einer älteren Version als 0.21.0 sitzt, der muss updaten. Im Falle Debian Stretch halt z.B. via Backports.

    Ich persönlich nutze auf Grund anderer Umstände eh schon die Backports, weil der neue Certbot hook-scripts generell auch schon bei der Initialisierung unterstützt und nicht nur als renew-script, wie der alte 0.10er.

    [
    | Versenden | Drucken ]
0
Von Tolimar am Mo, 28. Januar 2019 um 14:01 #

Und gerade eben kam das announcement rein, dass es aktualisierte Pakete via das stable-upgrades repository gibt:

https://lists.debian.org/debian-stable-announce/2019/01/msg00002.html

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung