Beiträge von kk

    Insgesamt könnte der gesamte SSL-Einrichtungsprozess wesentlich einfacher sein. Es gibt Provider, bei denen setzt man nur einen(!) Haken und die Sache ist erledigt.


    An dem Thema wird bereits gearbeitet. In den nächsten Monaten wird der SSL-Prozess komplett überarbeitet, so dass SSL tatsächlich nur noch mit einem Mausklick aktiviert wird. Das heißt, es muss dann u.a. kein Domainname mehr für das Zertifikat eingegeben werden, kein Let's Encrypt-Zugang angelegt werden, kein SSL in der IP-Gruppe aktiviert werden, und so weiter.
    Gleichzeitig soll auch die Einbindung anderer SSL-Anbieter (teil-)automatisiert werden, um LiveConfig auch unabhängig von der CA zu machen.


    Viele Grüße


    -Klaus Keppler

    Was definitiv noch nicht funktioniert ist die korrekte Serverkonfiguration von z.B. Bind9. Somit ist die Funktion bisher nur sehr eingeschränkt nutzbar ;)


    Was genau funktioniert denn bei Ihnen nicht?
    In unseren Testszenarien klappt nämlich alles, und ein paar Kunden nutzen dieses Feature erfolgreich im Produktivbetrieb.


    Es ist lediglich deshalb noch nicht offiziell dokumentiert, weil wir das Bearbeiten der IPs noch über die GUI ermöglichen möchten (damit niemand in die DB eingreifen muss).


    Viele Grüße


    -Klaus Keppler

    Gibt es hier schon eine Info? Konnte es bisher immer reproduzieren!
    Wurde es evtl. ver(gelöscht)bessert? :)
    Die binary liegt noch dort (/usr/lib/liveconfig/lclogparse) wurde aber nicht mehr gestartet.


    Das Komplizierte ist: wir können es hier nirgendwo reproduzieren. :(
    Das "alte" init-Script /etc/init.d/lclogparse wird bewusst während dem Upgrade entfernt. Beim Start prüft LiveConfig, welche "Konfigurationsversion" aktiv ist (/etc/liveconfig/sysconfig, Variable "LC_CFGVERSION"). Ist diese <32, dann wird u.a. das lclogparse-Init-Script aus /usr/lib/liveconfig/lclogparse.init nach /etc/init.d/lclogparse kopiert und aktiviert.
    Das sieht auf den ersten Blick etwas umständlich aus, aber nur so kann LiveConfig in einer systemd-Welt die Services "sauber" aktivieren und deaktivieren.


    Sie können testweise mal in /etc/liveconfig/sysconfig die LC_CFGVERSION auf "31" setzen und LiveConfig (oder den lcclient) neu starten. Dieser sollte dann das init-Script für lclogparse anlegen.


    Der einzige sonstige Grund, warum das ggf. nicht passieren würde, wäre dass die Datei /etc/liveconfig/lclogparse.conf nicht existiert...


    Viele Grüße


    -Klaus Keppler

    Die vorherige Version müsste 2.2.3-r4343 gewesen sein.
    [...]
    Die Tabellen wurden nicht zurückgesetzt


    Code-seitig ist so ein Fehler absolut unmöglich, da die Schemaänderung von r4440 auf r4441 eindeutig ist. Es wird in der Tabelle HOSTINGCONTRACTS die Spalte HC_LOCKED erstellt - wenn diese schon vorhanden ist (wie in der Fehlermeldung beschrieben) dann nur weil das Schema durcheinander gebracht wurde.


    Sie können die Spalte HC_LOCKED einfach noch mal löschen (ALTER TABLE HOSTINGCONTRACTS DROP HC_LOCKED) und anschließend LiveConfig starten.
    Je nachdem was da mit der Datenbank los ist kann es aber unter Umständen an anderen Stellen krachen. :(

    Hallo Herr Strausmann,


    welche LiveConfig-Version genau hatten Sie denn vor dem Upgrade am Laufen?
    Dieser Fehler kann eigentlich nur auftreten, wenn einzelne Tabellen der LiveConfig-Datenbank zurückgesetzt wurden (z.B. Restore aus einem Backup).


    Was liefert der folgende SQL-Befehl:

    SQL
    SELECT LC_VALUE FROM LIVECONFIG WHERE LC_KEY='dbschema';

    Dann habe ich mir nach vielfachem Googlen die Postfix "master.cf" ma angeguckt und dort auch keine Spur von SpamAssassin.


    Für SpamAssassin hat LC einen eigenen Milterservice ("lcsam": LiveConfig SpamAssassin Milter).
    Die von Ihnen vorgenommenen Einstellungen sind unnötig und berücksichtigen auch nicht die im LiveConfig vorgenommenen Einstellungen (Aktivierung/Deaktivierung des Filters pro Postfach, individuelle Schwellwerte zur Markierung/Ablehnung von Spam, etc.).

    More information about this error may be available in the server error log.


    Und, was sagt das error log genau?
    (/var/log/apache2/error.log)


    Irgendwas wird da nämlich definitiv drin auftauchen, wenn der Server einen "Error 500" ausgibt.

    Der Fehler trat dann auf, wenn man unter "Serververwaltung" -> "Mail" -> "Postfix" im Feld "Servername" einen manuellen Namen eingestellt hatte und diesen mit LiveConfig r4552-r4555 auf den Standard-Namen zurückgesetzt hatte. Durch einen semantischen (aber nicht syntaktischen) Fehler in SQL kam dann dazu, dass zwar bestehende MX-Einträge gelöscht, der neue Name aber nicht mehr gesetzt wurde. :(


    Wir hatten an dieser Stelle nur getestet, ob die neue Funktionalität (NAT-IPs) korrekt arbeitet, aber diese "Nebenwirkung" nicht bemerkt. Ich bitte um Entschuldigung für die Unannehmlichkeiten - die aktualisierte Version steht bereits im Repository.


    Danke auch für die schnellen Rückmeldungen und die Unterstützung bei der Fehlersuche.


    Viele Grüße


    -Klaus Keppler

    Lässt sich schon sagen wann - auch zeitlich - der Bug auftritt und ob er OS-abhängig ist?


    Wir haben vor einigen Wochen alle unserer Systeme auf v2.3.0 umgestellt und dieses Verhalten bislang auf keinem Server beobachten können. Wir arbeiten mit Hochdruck an der Ursachenforschung.

    Wenn man unter "Serververwaltung" -> "E-Mail" -> "Postfix" den Servernamen ändert, werden alle MX-Einträge zwangsweise aktualisiert.
    Um das nur 1x auszuführen, wie folgt vorgehen:
    1.) in der LiveConfig-Datenbank in der Tabelle MAILSERVERS die Spalte "MS_HOSTNAME" modifizieren (z.B. von "mx.example.org" in "mx.example.org.TEST" umbenennen"). Dabei passiert erstmal nichts.
    2.) anschließend wie oben beschrieben den Hostnamen wieder auf den "richtigen" Wert (mx.example.org) zurück setzen. LiveConfig erkennt das als Änderung und löst ein Update aller verwalteten MX-Einträge aus.

    Ich würde gerne die Ursache hierfür herausfinden...
    Können Sie uns bitte die Log-Meldungen seit dem Start von LiveConfig r4555 schicken?


    Am besten schicken Sie uns außerdem mal den Namen einer betroffenen (also aktuell noch MX-losen) Domain an support@liveconfig.com - dann können wir gemeinsam mal prüfen ob irgendetwas mit der Datenbank nicht stimmt.

    Wie kann ich von LiveConfig alle Domains in einem Rutsch neu schreiben lassen, ohne das nun für jede Domain händisch einzeln machen zu müssen.


    Gehen Sie als Admin auf "Server" -> "DNS-Verwaltung" und ändern in den SOA-Einstellungen mal den Wert für "Standard-TTL". Das sollte dazu führen, dass alle DNS-Einträge mit dem gewählten Template neu geschrieben werden.


    Zitat

    Die betroffenen Domains sind auch alle direkt nach dem Update geändert worden, die Files in /var/lib/bind/<domain>.de haben alle das Datum direkt nach der LiveConfig-Aktualisierung


    Sehr merkwürdig... Könnten Sie uns bitte mal den Ausschnitt aus /var/log/liveconfig/liveconfig.log zusenden, der unmittelbar nach dem Start der aktualisierten Version erzeugt wurde?
    (einfach per copy&paste an support@liveconfig.com).

    bei mir sind nach Aktualisierung sämtliche MX-Records für alle über LiveConfig verwaltete Domains verschwunden.


    Das Update an sich führt keinerlei Änderungen an Domains bzw. DNS-Einträgen aus, ich vermute also einen anderen Grund dafür.
    Was liefert "dig @<IP_des_Primary_DNS> <Domain> MX"?
    Mit dem Befehl "rndc freeze <Domain>" und anschließend "rndc thaw <Domain>" können Sie die Zonendatei aktualisieren lassen und prüfen ob dort auch der MX fehlt.


    Gehen Sie zudem in einem betroffenen Vertrag mal auf "Hosting" -> "Domains", klicken eine betroffene Domain an und prüfen ob im Tab "E-Mail" die Checkbox aktiviert ist.

    Hallo,


    das LiveConfig-Team freut sich, die Freigabe der Version 2.3.0 (r4555) ankündigen zu dürfen.
    Die wichtigsten Neuerungen sind:

    • über die neue SOAP-Funktion "SessionCreate()" kann nun ein Single-Sign-On in LiveConfig (z.B. von einer eigenen Kundenverwaltung aus) realisiert werden
    • es können nun einzelne Verträge gesperrt oder deaktiviert werden (auch über die SOAP-API)
    • wird ein Server hinter NAT betrieben, können nun in der LiveConfig-Datenbank die "echten" IPs hinterlegt werden, welche LiveConfig im DNS eintragen soll
    • es gibt einen neuen Policy-Dienst namens "lcpolicyd", welcher künftig die Begrenzung ausgehender E-Mails per SMTP oder sendmail-Aufruf ermöglicht. Die Konfiguration ist aktuell nur per CLI möglich, die GUI-Integration in die LiveConfig-Weboberfläche kommt mit dem nächsten Update
    • der LiveConfig SpamAssassin-Milter ("lcsam") erzeugt nun einen ausführlichen "X-Spam-Report:" im Mail-Header (mehrzeilig statt nur einzeilig). Somit sieht man welche Regel zu welchen Punkten bei der Bewertung geführt hat.
    • ausgehende Mails werden nicht mehr von lcsam analysiert (entlastet den Server und machte ohnehin wenig Sinn, da keine Filterung stattfindet)
    • sowie viele kleinere Verbesserungen und Fehlerbehebungen


    Die vollständige Liste aller Änderungen findet sich wie immer im Änderungsverlauf.


    Wie bereits angekündigt sind wir außerdem dabei, die Build-Prozesse umzustellen um künftig einzelne Änderungen schneller in das "stable"-Release freigeben zu können. Wir bereiten das derzeit parallel zum kommenden Update (v2.3.1) vor, weitere Details folgen dann wenn die Umstellung abgeschlossen ist.


    An dieser Stelle auch wieder vielen Dank für das Feedback, die Fehlerberichte und die Verbesserungsvorschläge.


    Viele Grüße & ein schönes Wochenende


    -Klaus Keppler