PREVIEW: LiveConfig v1.8.2

  • Ab sofort steht Version 1.8.2 in einer ersten Preview bereit. Diese enthält u.a. folgende Änderungen:

    • automatische Meldung von Backtraces:
      Wenn LiveConfig mit einem Segmentation Fault abstürzt, wird künftig automatisch der Backtrace (also die Programmadressen, die zum Absturz geführt haben) automatisch per HTTPS an update.liveconfig.com gesendet. Außerdem wird natürlich noch die genaue Versionsnummer und Kernelversion übermittelt (damit wir wissen, auf welcher Plattform das passiert ist). Eine vollständige Meldung sieht dann z.B. so aus:


      Mehr Daten werden nicht übermittelt! Diese Informationen sind nicht sicherheitsrelevant und erleichtern uns die Arbeit erheblich. Unserer Erfahrung nach merken viele Kunden es gar nicht, wenn mal ein Fehler auftritt, da sich die betroffenen LiveConfig-Prozesse automatisch neu starten.
      Dieser Crash Report lässt sich aber auch abschalten (dafür werden wir noch eine Konfigurationsoption schaffen). Wir wissen also nicht, bei welchem Kunden, welchem Server, welcher Lizenz oder welcher Domain usw. der Fehler aufgetreten ist - uns interessiert lediglich der Ort innerhalb des Programms.

    • Fehler beim Löschen einer Subdomain bei von LiveConfig verwaltetem DNS behoben


    Eine Hand voll kleinerer Änderungen wird derzeit noch integriert, ein Release ist noch für diese Woche geplant.


    Viele Grüße


    -Klaus Keppler

  • Das automatische "Raustelefonieren" mit optionalem Opt-Out finde ich bedenklich. Die Brisanz der o.g. Daten inkl. der Metadaten (IP-Adresse u.a.) mag vielleicht gering sein, doch möchte ich festlegen wann welche Daten zu irgendeinem Unternehmen gesendet werden. Schon allein wg. der aktuellen SSL/TLS-Konfiguration (!!!): https://www.ssllabs.com/ssltes…config.com&hideResults=on (cert self signed = kein Problem)


    Ich möchte euch liebend gerne die Traces inkl. der o.g. Daten zur Produktverbesserung schicken, aber kontrolliert. Akzeptabel wäre es wenn LiveConfig die Dumps im lokalen Dateisystem ablegt. Dann kann ich das Verzeichnis über neue Dumps überwachen lassen und sie dann nach manuellem Review automatisiert via HTTPS einsenden.


    Es haben ohnehin nicht alle Server direkten unbeschränkten Zugriff ins Internet. Wenn LiveConfig dann die Timeouts (wg. IP DROP) nicht richtig abfängt steht ein neues Problem vor der Tür.


    Also:


    Opt-In für A) automatischen Upload B) oder Opt-In für automatische Ablage im Dateisystem (Benachrichtigung des Admins mit Bordmitteln ist ganz einfach umsetzbar)


    Zitat

    Wir wissen also nicht, bei welchem Kunden, welchem Server, welcher Lizenz oder welcher Domain usw. der Fehler aufgetreten ist - uns interessiert lediglich der Ort innerhalb des Programms.


    Ein Profil über Kunde und Server lässt sich bspw. mit der (statischen) Server IP-Adresse erstellen.



    Die vorgesehene optionale Opt-Out Variante ist für mich ein Hinderungsgrund LiveConfig auf eine neuere Version zu aktualisieren.

  • Danke für das Feedback!
    Das SSL für update.liveconfig.com ist bekannt (wird bislang nur intern für die Repository-Anfragen für den AppInstaller verwendet). Und ja, auch ich mag es überhaupt nicht, wenn Software "nach Hause telefoniert". :) Daher ist es mir wichtig, das offen und transparent zu kommunizieren.


    Ein Spooling der angefallenen Daten und selektives Senden ist natürlich möglich. Auch hier haben wir aber die Herausforderung, dass der Admin es eventuell gar nicht mitbekommt, dass da was angefallen ist.


    Ich denke daher, dass wir Backtraces daher zwischenspeichern und auf der "Dashboard-Seite" (Übersichts-Seite bei der Anmeldung) einen sichtbaren Hinweis einbauen á la "Es ist ein Fehler aufgetreten - dürfen wir folgende Daten senden? [...(Daten)...]". Mit einem Klick auf "ok" geht das dann raus - eventuell mit einer Checkbox "[ ] künftig automatisch senden".


    Viele Grüße


    -Klaus Keppler

  • Hallo


    finde die Idee mit der Zusendung bei einem Fehler sehr gut, Option automatisch senden oder Manuell durch den Admin finde ich eine Gute Idee, da es auch der Entwicklung und behebung von Fehler sehr gut bei trägt.


    Die Verbindung muss dann natürlich ordentlich aufgebaut und abgesichert sein.


    Ein weiterer Pluspunkt finde ich die Veröffentlichung der Funktion, andere Software Riesen machen sowas gerne versteckt im Hintergrund.


    Mit freundlichen Grüßen


    Martin Krüger


  • Ich denke daher, dass wir Backtraces daher zwischenspeichern und auf der "Dashboard-Seite" (Übersichts-Seite bei der Anmeldung) einen sichtbaren Hinweis einbauen á la "Es ist ein Fehler aufgetreten - dürfen wir folgende Daten senden? [...(Daten)...]". Mit einem Klick auf "ok" geht das dann raus - eventuell mit einer Checkbox "[ ] künftig automatisch senden".


    Das klingt nach einer guten Lösung, gerne auch mit der (standardmäßig inaktiven) Checkbox für zukünftiges automatisch-Senden (nicht die Deaktivieren-Option vergessen)


    Ich verstehe ihr Interesse, möglichst viele Fehler-Daten zu bekommen - man wird deutlich weniger erhalten, wenn man es nicht standardmäßig aktiviert - aber der andere Aspekt sollte überwiegen.


    Bei Servern, die Probleme zeigen, aktivieren wir dann auch gerne die Automatik.



    Ein weiterer Verbesserungsvorschlag hierzu:
    Es sollte lokal im Dateisystem geloggt werden, wann und v.a. welche Daten übermittelt wurden



    P.S.:
    und auch wenn wir es nicht prüfen können: bitte auf dem vHost, der diese Requests erhält, das Logging der IP-Adressen abschalten oder auf große Subnetze hin anonymisieren



    P.P.S.:
    zumindest ab und an wird LC ja schon jetzt "nach Hause telefonieren" um die Lizenz zu prüfen?

  • Ich denke daher, dass wir Backtraces daher zwischenspeichern und auf der "Dashboard-Seite" (Übersichts-Seite bei der Anmeldung) einen sichtbaren Hinweis einbauen á la "Es ist ein Fehler aufgetreten - dürfen wir folgende Daten senden? [...(Daten)...]". Mit einem Klick auf "ok" geht das dann raus - eventuell mit einer Checkbox "[ ] künftig automatisch senden".


    Provider die ihren Kunden LiveConfig-Admin-Zugang zu Managed-Server u.ä. geben werden dann komische Fragen stellen. Ich als Admin würde das Dashboard dann auch nicht als Applikationsmonitoring nutzen/ missbrauchen. Daher würde ich nach vor die von mir vorgeschlagene Variante bevorzugen.


    Ich werde ohnehin demnächst versuchen die HTTP(S) Requests die zu license.liveconfig.com und update.liveconfig.com gehen über einen Proxy zu tunneln, damit ich die Internetverbindung bei den MySQL-Servern endlich kappen kann. Mal sehen wie weit ich komme.

  • Provider die ihren Kunden LiveConfig-Admin-Zugang zu Managed-Server u.ä. geben werden dann komische Fragen stellen. Ich als Admin würde das Dashboard dann auch nicht als Applikationsmonitoring nutzen/ missbrauchen.


    Die Backtrace-Meldungen würden bei den Benutzern erscheinen, welche die Berechtigung "LiveConfig-Verwaltung" haben. Bei Managed Servern sollte die der Kunde selbst dann eigentlich nicht besitzen.
    Eine reine (stille) Ablage im Filesystem nutzt uns nichts - bislang werden die Meldungen ja auch schon ins liveconfig.log geschrieben und dort (leider) meist ignoriert.


    Zitat

    Ich werde ohnehin demnächst versuchen die HTTP(S) Requests die zu license.liveconfig.com und update.liveconfig.com gehen über einen Proxy zu tunneln, damit ich die Internetverbindung bei den MySQL-Servern endlich kappen kann. Mal sehen wie weit ich komme.


    Nicht weit, befürchte ich... Zumindest für license.liveconfig.com nutzen wir SSL-Pinning. Eine Proxy-Unterstützung wurde aber schon begonnen, setzt dann aber CONNECT voraus (ein transparenter SSL-Proxy mit eigenem CA-Zertifikat wird nicht unterstützt). Ich denke in 2-3 Wochen ließe sich das durchaus mal testen.


    Viele Grüße


    -Klaus Keppler

  • Hallo Herr Keppler,
    ist das Admin Problem den inzwischen gelöst? Bzgl Meine Verträge...


    Wir würden gerne folgendes Umsetzen:


    - 2. Admin User anlegen ohne die von Ihnen genannte berechtigung LiveConfig-Verwaltung
    - Wenn der 2. Admin Verträge anlegt sollte er dann auch Zugriff drauf haben!


    Danke & Gruß
    O. Kolten

  • Prinzipiell stehe ich dem positiv gegenüber, allerdings möchte ich entscheiden, welche generierten Daten wann und wie das Netzwerk verlassen.


    Und nach einem kurzem Check beim SSL Zertifikat ist SSL3 auch noch aktiviert ;(.


    Ich muss allerdings dennoch bei einem Punkt widersprechen:



    (...)
    Wir wissen also nicht, bei welchem Kunden, welchem Server, welcher Lizenz oder welcher Domain usw. der Fehler aufgetreten ist - uns interessiert lediglich der Ort innerhalb des Programms.


    (...)


    Naja, (in)direkt schon. In meiner Lizenzübersicht steht zu jeder verwendeten Lizenz die IP-Adresse des Servers. Somit ist über diese Zuordnung klar, welcher Lizenznehmer mit welcher Lizenz und ggf. mit welcher Domain der Fehler aufgetreten ist.


    Prinzipiell ist dies für mich nicht tragisch, aber sollte doch etwas anders kommuniziert werden.

  • Und nach einem kurzem Check beim SSL Zertifikat ist SSL3 auch noch aktiviert ;(.


    In frühen LiveConfig-Versionen hatten wir in der OpenSSL-API statt "SSLv23_method()" die Funktion "SSLv3_method()" verwendet. War "damals" (vor POODLE) kein Thema, inzwischen aber ein Problem, da mit "SSLv3_method()" keine TLS-Verbindungen möglich sind (ja, die OpenSSL-API ist an dieser Stelle etwas !$#%&...)
    Kurzum: wenn wir SSLv3 abschalten, werden ältere LiveConfig-Versionen keine Lizenz mehr verlängern können. Aktuelle Versionen verbinden sich aber ohnehin via TLS1.2 mit dem Lizenz- und Updateserver.


    Last but not least: um POODLE auszunutzen müsste man in der Lage sein, die Kommunikation zwischen Client und Server zu beeinflussen (z.B. via Javascript in einer Website). LiveConfig führt ausschließlich einen einzigen GET-Request aus. Ich bin kein Experte auf diesem Gebiet, soweit ich das verstanden habe ist die Verbindung so aber nicht anfällig.


    Zitat

    Naja, (in)direkt schon. In meiner Lizenzübersicht steht zu jeder verwendeten Lizenz die IP-Adresse des Servers. Somit ist über diese Zuordnung klar, welcher Lizenznehmer mit welcher Lizenz und ggf. mit welcher Domain der Fehler aufgetreten ist.


    Das betrifft bestenfalls die Lizenzen, welche direkt über unseren Shop bestellt wurden. Bei allen über LiveConfig-Partner bestellten Lizenzen (und das ist der Großteil) wissen wir nicht, wer der Kunde ist. Und Domains kennen wir in keinem Fall (es wird nirgendwo ein Domainname übermittelt).


    Für uns hat eine offene Kommunikation der an uns übermittelten Daten seit Anfang an größte Priorität. Bei "anderen" Control-Panels muss man ja bereits während der Erst-Installation seine vollständigen Kontaktdaten angeben (fragt mich bitte nicht, wozu...).
    Ein Highlight ist es dann, wenn Betroffene gleich mittels iPhone bei Facebook posten, wie unverschämt es ist, dass irgendwelche Daten im Hintergrund übertragen werden... ;)

  • Die Preview für Version 1.8.2 wurde soeben aktualisiert (v1.8.2-r3427).


    Die Änderungen sind:

    • Anzeige der DNS-Vorlage in Domain-Tabelle
    • zeigt Hinweis wenn eine neue LiveConfig-Version verfügbar ist
      (hierfür wird lediglich ab sofort mit dem AppInstaller-Update auch die aktuellste LiveConfig-Versionsnummer übermittelt - es findet also keine zusätzliche Anfrage statt, weiterhin werden dabei keine Daten an uns übermittelt)
    • Prüfung des Zertifizierungspfads bei CA-Zwischenzertifikaten
      (damit werden künftig "falsche" CA-Zwischenzertifikate abgelehnt um Fehlkonfigurationen zu vermeiden)
    • Caching und automatische Konfiguration von CA-Zwischenzertifikaten
      (damit muss man künftig nicht für jedes einzelne Zertifikat die Zwischenzertifikate importieren - es genügt das einmal pro Zwischenzertifikat gemacht zu haben)
    • Prüfung der DNSSEC-Vorausetzungen verbessert
    • Markierung abgelaufener SSL-Zertifikate in Zertifikats-Liste
    • SNI/SSL-Konfiguration für NGINX korrigiert
    • Eingabelängen für Kontaktdaten-Felder vergrößert (für Multibyte-UTF8)
    • maximale Länge für Vertragsnamen von 10 auf 63 Zeichen vergrößert
    • Verzeichnis-Passwortschutz mit NGINX verbessert
      (Begrenzung der erlaubten Benutzer, bessere Unterstützung von Subdomains in Unterverzeichnissen mit Passwortschutz)


    Mit v1.8.2 befinden wir uns nun im "Feature Freeze" - die neuen Funktionen werden nun noch ausführlichst durchgetestet und dann in Kürze produktiv freigegeben. Die Arbeiten an der nächsten Version (v1.8.3) umfassen u.a. das CLI, das Backup und eine bequemere DNS-Verwaltung.


    Die Funktion zur automatischen Übermittlung von Stacktraces bei Programmfehlern wird vor der produktiven Freigabe vorerst wieder deaktiviert (in dieser Preview ist das noch aktiv).


    Viele Grüße


    -Klaus Keppler

  • Hallo


    bitte mal prüfen, bei uns ist aktuell nach Installation ein SSL Zertifikat durch das bearbeiten einer Domain gelöscht wurde.


    Leider konnte wir das Problem nicht nochmal nachstellen.


    Mit freundlichen Grüßen


    Martin Krüger

  • Die Preview für v1.8.2 wurde eben aktualisiert (v1.8.2-r3443). Die produktive Freigabe erfolgt voraussichtlich heute Nachmittag.


    Die Änderungen sind:

    • Fehler bei der Neuzuordnung einer IP-Gruppe an einen anderen Wiederverkäufer behoben
    • Fehler bei Auswahl des Webspace-Startverzeichnisses bei bislang deaktivierten Subdomains behoben
    • Fehler bei Anzeige der 24h/7d-Graphen beseitigt (Anzeige des "großen" Graphen)
    • Anzeige des im Hosting-Vertrag enthaltenen Datenverbrauchs (Traffic)
    • Unterstützung von TSIG-Schlüsseln bis 512 Bit (statt bislang 128 Bit)
    • Erlaube Zuweisung von DNS-Templates an Wiederverkäufer-Verträge (geht aus Sicherheitsgründen aber nur mit "Resellern 1. Grades", also nicht bei Resellern von Resellern...)
    • Parameter "dnstemplate" zur SOAP-Funktion HostingDomainAdd() hinzugefügt


    Die automatische Übertragung von Backtraces bei Programmfehlern wurde (wie angekündigt) wieder entfernt.


    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!