Beiträge von kk

    In lclogparse.status wird nur beim Ende des lclogparse-Prozesses geschrieben, bis wohin er die Log-Datei bereits abgearbeitet hat.
    Wichtig ist vielmehr die smtp.stats - die Werte darin enthalten die Statistikdaten, die dann auch in der LiveConfig-GUI angezeigt werden sollten (d.h. die Zahlen darin sollten analog der Einträge in mail.log auch wachsen).
    Es wird immer ein paar Minuten dauern bis die ersten Zahlen in der GUI auftauchen (die Aktualisierung in der Datenbank erfolgt nur alle paar Minuten; für die Berechnung der RRDs braucht es mindestens zwei Meßwerte). Nach maximal 30 Minuten sollten also die ersten Daten da sein.


    Derzeit gilt noch die Einschränkung, dass unter E-Mail-Aliasen empfangene Mails nicht als eingehende Mails eines Accounts mitgezählt werden können; ausgehende Mails werden aber immer gezählt.

    Die Arbeiten am Milter-Service für eine nahtlose SpamAssassin-Integration sind inzwischen erfolgreich abgeschlossen. Wir haben "lcsam" (LiveConfig SpamAssassin Milter) gestern ausführlich durchgetestet. Dieser Service erlaubt eine individuelle Konfiguration von Schwellwerten für die Markierung und Ablehnung von E-Mails sowie individuelles "Tagging" verdächtiger Mails. Als "Spam" erkannte Mails werden während der SMTP-Verbindung (pre-queue) abgelehnt, so dass kein Backscattering erfolgt und der Absender ggf. durch seinen eigenen Mailserver über eine nicht erfolgte Zustellung informiert wird. Last but not least unterstützt lcsam auch eine individuelle SpamAssassin-Konfiguration pro Mailadresse; in einem nächsten Schritt können somit auch persönliche Whitelists und Blacklists realisiert werden.


    lcsam ist unter einer dualen Lizenz verfügbar (Open Source (GPL) und kommerziell im Rahmen von LiveConfig), der Code wird in den nächsten Tagen bei GitHub veröffentlicht.


    Anfang der kommenden Woche wird im LiveConfig die GUI für die Verwaltung der Spam-Einstellungen aktiviert, Ende der Woche wird es dann die Preview freigegeben.


    Viele Grüße & ein schönes Wochenende


    -Klaus Keppler

    Die Version 1.7.3 wurde eben noch mal aktualisiert (r2921) - damit werden zwei Probleme beseitigt:

    • lclogparse: hier gab es auf manchen System ein Timing-Problem bei der Erstellung der PID-Datei (nach einem fork() versuchte der Child-Prozess die PID-Datei zu sperren, während der Parent-Prozess aber noch nicht beendet war). Sollte nun klappen - während des Updates wird lclogparse ggf. automatisch (neu) gestartet.
    • Cron-Jobs: durch eine Änderung beim Erstellen der Cronjobs (so dass nun eventuelle Fehlermeldungen abgefangen und im LiveConfig-Log angezeigt werden) gab es teilweise Fehler beim Anlegen von Cronjobs. Auch das ist mit dem Update beseitigt.


    Viele Grüße & noch ein schönes Wochenende


    -Klaus Keppler

    Hallo,


    vielen Dank für den Hinweis - ein Update (r2921) steht ab sofort bereit.


    Mit freundlichen Grüßen


    -Klaus Keppler

    iOS arbeitet nur eine von Apple vorkonfigurierte Liste ab - es wird für POP/IMAP/SMTP leider keine Form von Autodiscover o.ä. unterstützt (wir haben uns längere Zeit damit beschäftigt).
    Einzige Möglichkeit das bei größeren Rollouts etwas zu vereinfachen ist die Erstellung einer .plist-Datei (mit den Mail-Preferences) - so machen das Unternehmen, Unis usw.

    Ich weiß, nachträglich zu spekulieren bringt eigentlich nichts.


    Nein, nicht eigentlich nichts, sondern überhaupt nichts.


    Ohne eine systematische Fehlersuche ist das völlige Zeitverschwendung.
    Mögliche Fehlerquellen: DNS, DNS-Cache, Apache-Konfiguration, Firewall, Virenscanner, Internetanbindung, Routing.
    Ausgeschlossen werden kann lediglich: das Wetter.


    Und zu SPA findet man über sogenannte Suchmaschinen (z.B. unter http://www.google.de) ganz viele Informationen. Kurz gesagt: aus lassen.

    Ich kann das hier leider nicht reproduzieren (weder mit SQLite noch mit MySQL). Ich habe testweise die Seite "Webspace" -> "Domains" zig mal hintereinander aufgerufen (<Strg>+<R> auch mal gedrück gehalten) - kein Problem.
    Ich würde der Sache gerne auf den Grund gehen - könnten Sie sich bitte bei Gelegenheit kurz unter support@liveconfig.com melden? Dann würde ich das weitere Vorgehen direkt besprechen (ggf. Core-Dump des "defekten" Prozesses erzeugen).


    100% CPU-Last können zumindest für eine kurze Zeit durchaus "normal" sein (event-basierter I/O eben), sobald die offenen Anfragen bearbeitet sind sollte aber wieder alles normal laufen. Sie können während so eines Test mal die Datei /var/log/liveconfig/access.log beobachten (tail -f ...) - sobald da keine Zeilen mehr dazu kommen sollten alle Requests bearbeitet sein und LiveConfig wieder "normal" reagieren.


    PS: das Video funktioniert leider nicht (defekt?).

    Das LiveConfig-Team freut sich, die Verfügbarkeit von Version 1.7.3 (r2914) bekanntgeben zu dürfen.


    Die neue Version steht ab sofort im Download-Bereich sowie in allen Repositores bereit.


    Die wichtigsten Änderungen in der neuen Version sind:

    • Statistik über gesendete & empfangene E-Mails der letzten 24 Stunden pro Vertrag
    • Auswahl der IPs für eingehende & ausgehende SMTP-Verbindungen
    • Unterstützung von DNS-Whitelists (wenn Greylisting aktiviert ist, ab Postfix v2.8)
    • automatische Aktualisierung der SSL-Zertifikate in der Webserver-Konfiguration, wenn diese in der LiveConfig-GUI bearbeitet wurden
    • SSL-Ciphers verbessert (basiert nun auf Mozillas OpSec-Empfehlungen)
    • OpenSSL von 1.0.1g auf 1.0.1h aktualisiert
    • bessere Eingabeprüfung und Fehlerverarbeitung bei Einrichtung von Cron-Jobs


    Die vollständige Liste aller Änderungen finden Sie im Änderungsverlauf.

    Ja, ich hatte am Freitag einfach nicht im Kopf, dass am Montag Feiertag ist.
    In r2907 war noch ein Fehler, der uns nicht gleich aufgefallen ist (beim Bearbeiten von Verträgen), daher gab es mit 2910 noch ein kurzfristiges Update hinterher. Um diesen (und ähnliche) Fehler künftig gleich zu erkennen bauen wir heute noch ein paar weitere Tests. Am LiveConfig selbst gibt es heute keine Änderungen mehr - wenn die Tests alle durchlaufen erfolgt heute Abend das Release.


    Viele Grüße


    -Klaus Keppler

    Das Dropdown-Feld bei "eigene DNS-Server" innerhalb des Hosting Panels von LiveConfig ist einfach blank und bietet nach Auswahl auch kein Erstellen einer erstmaligen DNS-Vorlage.


    Sind Sie als Reseller oder als "admin"-Kunde angemeldet?
    Wenn admin: in diesem Fall haben Sie vermutlich keine vollständigen DNS-Templates angelegt. Alle Details hierzu sind im Handbuch beschrieben ("4.15.1 DNS-Vorlagen").


    Reseller können derzeit die DNS-Templates nicht mit nutzen, da hier einige Berechtigungsfragen noch nicht geklärt sind. (was machen Sie etwa, wenn ein Reseller z.B. die Domain "gmx.de" auf Ihrem DNS-Server anlegen will?)

    Ja, die Änderungen sind drin. Bitte speichern Sie ggf. den betroffenen Vertrag noch mal neu (damit die Rechte aktualisiert werden).
    Und bitte ggf noch die Preview auf r2910 aktualisieren (mit r2907 gab's noch einen Fehler beim Bearbeiten von Verträgen unter "Mein Hosting").


    Viele Grüße


    -Klaus Keppler

    Die Preview wurde eben noch mal aktualisiert, ab sofort steht v1.7.3-r2907 bereit.
    Die wichtigsten Änderungen sind:

    • Auswahl der IP-Adressen für eingehende SMTP-Verbindungen möglich
    • Deaktivierung von IPv6 für ausgehende SMTP-Verbindungen möglich (wichtig z.B. bei GoogleMail)


    Viele Grüße


    -Klaus Keppler

    Ich will mich kurz fassen: wenn das Backup von MySQL-Datenbanken nur ein billiger Aufruf von mysqldump vor dem Erstellen des tgz's wäre, dann wäre das natürlich schon längst drin.
    Leider ist die Sache in der Praxis etwas komplizierter. In vielen Setups laufen Web- und DB-Server separat. Auf vielen Webservern sind keine MySQL-CLI-Tools (insbes. mysqldump) installiert. Die Backup-Thematik bei Postfächern ist sogar noch komplexer.


    Ein Backup, dass zwar auf dem Server erzeugt wurde aber von niemandem heruntergeladen wurde, nutzt kaum etwas. Auf professionellen Shared-Hosting-Systemen sollten ohnehin seitens des Betreibers inkrementelle Backups mit sinnvolleren Protokollen (z.B. rsync) laufen, statt "dumm" einfach große TGZs zu erzeugen welche dann die gesamte Storage zumüllen.


    Wir machen uns also sehr ernsthaft Gedanken zu diesem Thema. Eins nach dem anderen.