Beiträge von KB19

    @MarcelloW Interessant wäre auf jeden Fall eine Beobachtung über einen Zeitraum von mehreren Tagen mit z.B. Smokeping. Natürlich über alle Interfaces, damit man einen Vergleich hat.

    Steht ein vLAN ausschliesslich innerhalb dem Bereich einer Kundennummer zur Verfügung?

    Ja, afaik. Ob es bei Bedarf Sonderlösungen gibt, müsstest Du den Support fragen.

    Kann höchstens ein vLAN gebucht werden?

    Kostenpflichtige vLANs kannst Du so viele buchen, wie Du möchtest: https://www.netcup.de/vserver/root-server-erweiterungen.php

    Wie es beim kostenlosen 100 Mbit/s vLAN ist, musst Du den Support fragen.

    Ich lade die SHA1-Passwortsammlung von Troy doch endlich mal in eine lokale Test-DB… :/:love:

    12-13 Tage (!) später ist die Datenbank endlich gefüllt. Das Aufbauen eines Indexes dauert vergleichsweise kurz und ist nach 30-45 Minuten durch. Wenn man maximal die ersten 5 Byte in den Index aufnimmt, deckt man offenbar nahezu alle 551 Millionen Hashwerte ab:

    Code
    +----------+-------------+----------+
    | Key_name | Cardinality | Sub_part |
    +----------+-------------+----------+
    | 5b       |   528630476 |        5 |
    | 3b       |    35242031 |        3 |
    | 2b       |      917761 |        2 |
    +----------+-------------+----------+

    Weniger macht kaum Sinn, da es an der Größe vom Index nicht mehr viel ändert und zu viele ähnliche Hashwerte existieren:

    Code
    +---------+-----------------+-----------------+
    | pages   | index_name      | size            |
    +---------+-----------------+-----------------+
    |  524607 | 2b              |  8.004867553711 |
    |  563455 | 3b              |  8.597640991211 |
    |  641471 | 5b              |  9.788070678711 |
    | 1551744 | GEN_CLUST_INDEX | 23.677734375000 |
    +---------+-----------------+-----------------+

    Die Datenbank braucht nun ca. 35 GB Platz. Bei den ersten Tests reagiert sie erfreulich schnell:

    Das läuft zum Test übrigens am VPS 1000 G8 Plus mit 8 GB Ram und Optane, der nebenbei andere Dinge erledigt. Die MariaDB-Konfiguration ist unverändert und Debian Standard. Ich spiele mich mal weiter damit rum… :D

    Notiz an mich: MariaDB 10.1 auf MariaDB 10.3 Upgrade, wenn es sich um einen Slave mit SSL-Verbindung handelt und Debian Buster (OpenSSL 1.1.1) verwendet wird. Falls der Master etwas älter ist, kracht es spätestens bei diesem MariaDB-Upgrade…

    Code: Konfiguration vom Slave
    # /etc/mysql/[…].cnf
    binlog_checksum = NONE
    
    # /etc/ssl/openssl.cnf (je nach Version vom Master vorher einmal mit TLSv1.1 probieren)
    MinProtocol = TLSv1
    
    # bei älterer CA auch noch das
    CipherString = DEFAULT@SECLEVEL=1

    Fazit: Ich bin froh, wenn ich diese Altlasten endlich los bin! <X Aber bis dahin braucht es diese Übergangslösungen.

    Tipp: wget und wput/curl über einen netcup Server aufrufen, dann ist der Download und Upload nur eine Sache von Sekunden. Das kann man sogar über den betroffenen Server machen, notfalls einfach das Rescue System kurz booten.

    Afaik unterstützt der FTP-Server übrigens eine verschlüsselte Verbindung.

    Wie häufig und lange tritt das auf? Kannst Du das im Rettungssystem auch reproduzieren? Oder hast Du wenigstens Verlaufsgrafiken, die das Problem zeigen? Smokeping wäre ein gutes Tool, um das aufzuzeichnen.

    Debian Stretch

    Ich meinte übrigens Debian Buster, also Testing. Das kommt davon, wenn man im Halbschlaf Forenbeiträge verfasst… ^^

    Ganz toll, jetzt muss ich bei netcup endgültig immer an netcat denken! :D

    Reicht eh schon, dass ich statt netstat manchmal netcup eintippe…

    Code
    $ netcup -tupen
    Der Befehl »netcup« wurde nicht gefunden, meinten Sie vielleicht:
     Befehl »netcap« aus dem Paket »libcap-ng-utils« (universe)
    netcup: Befehl nicht gefunden.

    Ich habe mich schon vor einigen Tagen gewundert, warum der "commited" Anteil in den Ram-Usage-Grafiken meiner Debian Stretch VMs massiv ansteigt. Mittlerweile schlug auf einem System der OOM-Killer an, was mich selbst auf irgendwelchen Test-VMs mal zum genaueren Nachschauen verleitete.

    Ergebnis: systemd-journald frisst den ganzen Arbeitsspeicher auf…

    Lösung: Version 240-4 vermeiden und auf 240-5 warten!

    Falls es jemand nachlesen möchte: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920018

    btw: Könnte man bei gekündigen Produkten bereits in der Liste einblenden mit welchem Datum? Also statt Produkt ist gekündigt. vielleicht gleich zum 28.02.2019 gekündigt?

    Es wäre auch sehr sinnvoll, wenn die Kündigung im Tab Vertragliches irgendwo erwähnt wird. Derzeit steht dort nur der nächstmögliche Kündigungstermin, was irgendwie witzlos ist, wenn das Produkt bereits gekündigt wurde.

    fällit sowas niemanden auf?

    Womöglich schon, aber zum Erneuern von blockierten Symantec-Zertifikaten haben sie auch drei Wochen nach mehrmaligen Hinweisen gebraucht. Insofern wohl normal. Erstreaktionen auf Tickets dauern aktuell oft 1-2 Monate (!) bei A1 und gehen überhaupt nicht auf das Thema ein. Insofern wundert mich langsam echt nichts mehr.