LiveConfig v1.8.2 freigegeben

  • Das LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig v1.8.2 (r3444) bekanntgeben zu dürfen.


    Zu den wichtigsten Verbesserungen und neuen Funktionen gehören:

    • Prüfung des Zertifizierungspfads von CA-Zwischenzertifikaten
      somit sorgen ungültige oder überflüssige Zwischenzertifikate nicht mehr zu Konfigurationsfehlern oder unnötigem Ballast beim SSL-Handshake
    • Caching und automatische Konfiguration von CA-Zwischenzertifikaten
      LiveConfig speichert CA-Zwischenzertifikate und richtet diese bei weiteren SSL-Zertifikaten automatisch ein. Bei identischen SSL-Produkten muss somit nicht mehr jedes Mal separat das "ca-bundle" entpackt und eingerichtet werden.
    • abgelaufene SSL-Zertifikate werden in der Übersicht (Zertifikatsverwaltung) markiert
    • Vertragsnamen dürfen nun bis zu 63 Zeichen lang sein (statt bisher 10 Zeichen)
    • TSIG-Schlüssel für signierte Zonentransfers dürfen nun bis zu 512 Bit lang sein (statt bisher 128 Bit)
    • Voraussetzungen für DNSSEC werden besser geprüft (DNSSEC kann nur aktiviert werden, wenn auch mindestens ein KSK-Schlüssel vorhanden ist)
    • DNS-Vorlagen können nun an Reseller zugewiesen werden (damit können auch Wiederverkäufer Domains in einem von LiveConfig verwalteten DNS anlegen)
    • SNI/SSL-Konfiguration von NGINX verbessert (damit sollte SSL und insbes. SNI mit NGINX nun ohne manuelle Eingriffe funktionieren)


    Zudem gab es einige Verbesserungen und Fehlerbeseitigungen - die vollständige Liste finden Sie im Änderungsverlauf.


    Das Update lässt sich wie immer reibungslos über die Repositories einspielen.


    Im Namen des LiveConfig-Teams


    -Klaus Keppler

  • abgelaufene SSL-Zertifikate werden in der Übersicht (Zertifikatsverwaltung) markiert


    Bei mir in LiveConfig Basic werden alle Zertifikate, die im Jahr 2016 und später ablaufen, bereits mit einem Warndreieck als abgelaufen markiert. Bei 2015ern scheint der Datumsvergleich zu funktionieren.

  • Bei mir in LiveConfig Basic werden alle Zertifikate, die im Jahr 2016 und später ablaufen, bereits mit einem Warndreieck als abgelaufen markiert. Bei 2015ern scheint der Datumsvergleich zu funktionieren.


    Sehr schräg... kann ich hier nicht reproduzieren (wir haben hier Zertifikate mit Ablaufdatum 2017, die ganz normal angezeigt werden). Stimmt Ihr Serverdatum? (bei "Einstellungen" -> "Zeitzone" wird Ihre aktuelle Zeit angezeigt).

  • Ja, das korrekte Datum und die korrekte Zeit wird angezeigt.


    Edit: Bei mir lässt es sich recht einfach reproduzieren. Die Warnung wird selbst bei frisch über die LC Oberfläche erstellten self-signed Zertifikaten angezeigt. Bei über LC erstellten self-signed Zertifikaten aus dem letzten Jahr (die also 2015 auslaufen) erscheint die Warnung nicht.

  • Ich habe auch das Problem mit den SSL Zertifikaten.
    Manche Zertifikate die im März 2015 ablaufen werden nicht als abgelaufen markiert. Andere wiederum die erst im Oktober 2015 ablaufen werden als "abgelaufen" mit dem Dreieck markiert.
    :(


    Edit: Zeit ist richtig eingestellt.

  • Danke für die Rückmeldungen - Fehler gefunden. Eine Variable wird dort falsch initialisiert (bzw. der Vergleich wird mit der falschen Variable durchgeführt). Wir haben hier einen Server mit 20 SSL-Zertifikaten, bei denen alle korrekt angezeigt werden, daher fiel das leider nicht vorher schon auf. :( Update kommt gleich...
    (zumindest ist das nur eine Anzeigefehler, hat also keine Aufwirkung auf die Konfiguration o.ä.)

  • Die Graphen für CPU/Netzwerk werden nach Klick garnicht angezeigt - also keine vergrößerte Ausgabe.


    Werden hier auch nicht angezeigt. Cache des Browsers schon komplett gelöscht und neu gestartet. Egal ob Firefox 35.0.1 oder IE 10


    Folgende Fehler tauchen im Log auf, sobald man klickt:

    Code
    [2015/02/11 15:39:28.024479] [1759|1762] ERROR: Releasing db connection, but still have open statements
    [2015/02/11 15:39:28.024505] [1759|1762]        aborting SQL: 'SELECT RRA_ID, RRA_STEP FROM RRA_CPU WHERE ( ( RRA_SERVERID = ? ) AND ( ( ( RRA_STEP * RRA_SIZE ) > ? ) OR ( RRA_SIZE = -1 ) ) ) ORDER BY RRA_STEP ASC LIMIT 2'
    [2015/02/11 15:39:28.024578] [1759|1762] Database Exception: Database Error: mysql_stmt_execute: (1690) BIGINT UNSIGNED value is out of range in '(`LIVECONFIG`.`RRA_CPU`.`RRA_STEP` * `LIVECONFIG`.`RRA_CPU`.`RRA_SIZE`)' (SQL: SELECT RRA_ID, RRA_STEP FROM RRA_CPU WHERE ( ( RRA_SERVERID = ? ) AND ( ( ( RRA_STEP * RRA_SIZE ) > ? ) OR ( RRA_SIZE = -1 ) ) ) ORDER BY RRA_STEP ASC LIMIT 2)
  • Machen Sie bitte mal einen "sicheren" Reload (<Strg>+<R>). Falls danach noch immer keine Graphen erscheinen: welchen Browser verwenden Sie?


    Sowohl CPU als auch Traffic, keine großen Graphen sichtbar, popup bleibt leer.


    getestet mit


    FF 35.0.1
    CH 40.0.2214.111


    E: Fehlermeldung/Logauszug identisch zum Vorredner. Das ist kein Browserproblem ;)

  • Code
    mysql_stmt_execute: (1690) BIGINT UNSIGNED value is out of range in '(`LIVECONFIG`.`RRA_CPU`.`RRA_STEP` * `LIVECONFIG`.`RRA_CPU`.`RRA_SIZE`)'


    Ah, danke... da liegt der Hund begraben. Der Wert in RRA_SIZE kann -1 sein, was natürlich Probleme mit BIGINT UNSIGNED macht. Ich verstehe nur MySQL an dieser Stelle noch nicht so recht - auf unseren Entwicklungssystemen läuft das nämlich komischerweise problemlos. Scheint mit der Version des MySQL-Servers zusammen zu hängen.
    Wir prüfen das gerade genauer...

  • Machen Sie bitte mal einen "sicheren" Reload (<Strg>+<R>). Falls danach noch immer keine Graphen erscheinen: welchen Browser verwenden Sie?


    Nur für die Akten(weil andere das schon gemacht haben):
    FF 35 Reload ohne Änderung
    IE 11 ohne Änderung(der hatte vorher noch nie was mit LC zu tun)

  • OK, gefunden... Bei arithmetischen Operationen mit mindestens einem UNSIGNED-Wert ist das Ergebnis in MySQL immer UNSIGNED (siehe Handbuch). Seit Version 5.5.5 läuft MySQL standardmäßig im "strict mode". Dort führt ein mögliches negatives Ergebnis (wie hier: x * -1) bei gleichzeitigem UNSIGNED-Attribut zu einem Fehler.
    Bei uns ist das nicht aufgetaucht, weil unsere Entwicklungsumgebung im Büro noch mit MySQL 5.0.x läuft (Debian 6.0.10 LTS). Auf den virtuellen Servern testen wir mittels Jenkins/Selenium das MySQL-Backend bislang auch nur auf einer Debian 6 VM, alle anderen VMs (Debian 7, CentOS 5/6/7, Ubuntu 12/14, OpenSUSE 13) laufen mit dem SQLite-Backend. Wir werden das nun erweitern, um das MySQL-Backend auch mit "aktuellen" Versionen zu testen.


    Ich bitte um Entschuldigung für die Unannehmlichkeiten; ein Update läuft eben durch's Build-System und steht in ca. 30-45 Minuten online.


    Viele Grüße


    -Klaus Keppler

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!