Beiträge von kk

Der neue reguläre Ausdruck zum Prüfen der Intervall-Eingaben hatte dies nicht korrekt berücksichtigt.
Mit dem nun bereitstehenden Update (v1.7.3-r2934, ab sofort im Lab-Bereich, ab morgen als Stable) ist das korrigiert.

Zitat von jacboy

HTTP geht einwandfrei, E-Mail auch, SSH kommt ein Timeout.....

EDIT: Die Anmeldeseite war gerade kurz und einwandfrei zu erreichen, nach ein
paar Sekunden war sie aber auch wieder weg.

Wenn auch bei SSH ein Timeout kommt, dann hat das definitiv nichts mit LiveConfig zu tun. Das deutet eher darauf hin, dass der Server insgesamt extreme Wartezeiten beim Plattenzugriff hat (außer es läuft gerade ein groß angelegter BruteForce-Angriff...).

Am besten beobachten Sie mal die Systemlast des Servers insgesamt (z.B. mit dem oben erwähnten "vmstat"-Befehl).
Gerade bei besonders günstigen vServern kann es aufgrund der hohen Dichte an VMs pro Hardware schnell zu einem Flaschenhals im I/O kommen.

Ab sofort steht ein Update (v1.7.3-r2934) im Lab-Bereich bereit, mit dem u.a. die fehlenden Berechtigungen für den AppInstaller korrigiert werden. Ab morgen kommt das Update auch ins Stable-Repository.

Der Fehler war etwas verzwickter (es hing davon ab wo genau die Berechtigungen für den AppInstaller gegeben wurden, und dann wiederum ob das in Resellerverträgen eventuell "abweichen" vom Angebot definiert war).
Sollten vereinzelt noch die Berechtigungen fehlen, reicht es, das am höchsten übergeordnete Angebot (oder Vertrag) erneut zu speichern; LiveConfig aktualisiert rekursiv alle darunter angelegten Verträge.

Viele Grüße

-Klaus Keppler

Was heißt "der Server lässt gar keine Verbindungen mehr zu" - nicht nur zu LiveConfig, sondern auch zu anderen Diensten? (SSH, HTTP, ...)

Ist bereits in Arbeit, voraussichtlich heute Nachmittag gibt es weitere Details bzw. ein Update.

Standardmäßig nutzt LiveConfig eine SQLite-Datenbank für alle "internen" Daten. Wenn Sie sehr viele Objekte (z.B. Webspace-Verträge, Datenbanken, Postfächer) haben, dann führt das alle paar Minuten zu einer erhöhten I/O-Last während LiveConfig die Statistikdaten aktualisiert. Am einfachsten können Sie das prüfen, indem Sie während so einer Nicht-Erreichbarkeit auf der Konsole mal den Befehl "vmstat 1" eingeben. In der letzten Spalte ("wa"="Waiting") sehen Sie, wie viel Prozent ihrer Zeit die CPU mit dem Warten auf I/O verbringt. Falls da irgendwas ca >10 steht, ist das Problem schon gefunden.
In diesem Fall stellen Sie LiveConfig einfach auf MySQL um, das hat mehr Performance. (Anleitung: KB#15)

Viele Grüße

-Klaus Keppler

Zitat von kenny_g

Wenn ich jetzt so eine Subdomain anlege, funktioniert diese wie gesagt nicht.

Nun, wenn die Fehlerbeschreibung nur aus "funktioniert nicht" besteht, dann ist die einzige Antwort: dann stimmt wohl was nicht.

Oder anders formuliert: ohne aussagekräftige Fehlerbeschreibung kann Ihnen leider auch niemand weiterhelfen.

Der Source für lcsam ist ab sofort bei GitHub online: https://github.com/LiveConfig/lcsam

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.

Zitat von kenny_g

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.

Die .css-Dateien werden nicht dynamisch erzeugt (wäre auch Quatsch), sondern sind in den Ressourcen-Dateien unter /usr/share/liveconfig/ enthalten.
Was kommt denn, wenn man direkt die .css im Browser aufrufen möchte? https://###:8443/res/t/default/style.js?r2910

Ggf. LiveConfig (noch) mal neu starten (sollte beim Update ohnehin automatisch geschehen)

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?).

Auf welcher LiveConfig-Seite machen Sie den Refresh? Nutzen Sie bereits MySQL als Datenbank-Backend für LiveConfig?

LiveConfig ist an sich so ausgelegt, dass es quasi beliebige Lasten problemlos verarbeiten kann (event-basiertes I/O). Flaschenhals kann dann SQLite sein, da diese DB nicht für parallele Abfragen optimiert ist.

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.

Ist ab v1.7.3 behoben (in der aktuellen Lab-Version bereits enthalten).

Viele Grüße

-Klaus Keppler

Das geht schon lange
Geben Sie den Vertragsnamen einfach in die Schnellsuche ein (links, unterhalb des letzten Punkts im Navigationsmenü).