Beiträge von kk

Mit PHP hat das nichts zu tun (LiveConfig nutzt kein PHP).
Was erhalten Sie denn, wenn Sie direkt den Link zu einer Ressource aufrufen?
z.B. http://###:8443/res/m/core/logo-left.jpg

Danke für das Feedback, hier gab es leider einen kleinen Fehler im lcsam-Dienst. Update (r2947) steht ab sofort im Test-Repo.

Ab sofort steht die erste Preview von LiveConfig v1.7.4 (r2946) zum Download bereit.

Diese Version bringt nun eine integrierte Unterstützung von SpamAssassin durch einen eigenen Milter-Service (LiveConfig SpamAssassin Milter, kurz "lcsam").
Wenn das Paket "spamassassin" installiert ist, sollte LiveConfig dieses automatisch erkennen und im Dialog Serververwaltung -> Mail die Option "Spam-Filter" anbieten. Wenn diese aktiviert ist, können pro Postfach der SpamAssassin-Check aktiviert und die verschiedenen Schwellwerte konfiguriert werden.

Es gibt zwei konfigurierbare Schwellwerte: einer zur Markierung verdächtiger Mails (Standard: 3.0) - erreicht eine Mail diese Punktzahl, dann wird vor das Subject der Text "***SPAM-Verdacht***" eingefügt. Der Schwellwert zur Ablehnung (Standard: 5.0) führt dazu, dass eine E-Mail noch während der SMTP-Verbindung abgewiesen wird (mit der Fehlermeldung "554 5.7.1 Your message was rejected because it appears to be spam").
Zudem werden die üblichen SpamAssassin-Header in analysierte Mails eingefügt, um diese ggf. auch lokal zu filtern.

Der Quellcode für den Milter-Dienst steht übrigens als Open Source bei GitHub online.

Wir haben das ganze derzeit mit Debian 6, Debian 7, CentOS 5, CentOS 6 und Ubuntu 12 durchgetestet; derzeit werden die Tests noch verfeinert und auf zusätzliche Distris erweitert.
Sollte es zu Fehlern/Problemen kommen, brauchen wir mindestens folgende Infos:
- eingesetzte Distribution & Version
- läuft der Dienst "lcsam"?
- was steht im Mail-Log (/var/log/mail.log o.ä.)?

Aktuell wird noch am GUI-"Umschalter" für die PHP-Version gearbeitet, dieser sollte dann nächste Woche soweit sein. Und natürlich werden die Spam-Einstellungen auch (falls aktiviert) über das direkte Login durch Mail-User bearbeitbar sein.

Viele Grüße

-Klaus Keppler

Nein, wird nicht durch LC zurückgesetzt. Lediglich falls neue Anwendungen dazu kommen sollten sind diese standardmäßig natürlich nicht deaktiviert.

LiveConfig führt (derzeit) keine Updates für Apps aus, daher ist das irrelevant.
Unabhängig davon ist aber in den Installationsscripts bereits eine Funkton vorbereitet, die von der jeweils installierten App die tatsächliche Version ausliest. Wenn LC künftig also auf Updates hinweist (bzw. diese starten kann), wird natürlich geprüft, welche Version tatsächlich läuft.

Die "zusätzlichen" php.ini-Verzeichnisse werden bei Aktualisierung der Vertragsdaten angelegt. Um diese also nachträglich für "ältere" Kunden anzulegen, speichern Sie entweder die betroffenen Verträge neu (also Vertrag bearbeiten -> direkt auf "speichern" klicken), oder speichern Sie die verwendeten Hostingangebote neu (daraufhin werden alle darauf basierenden Hostingverträge auch aktualisiert)

Viele Grüße

-Klaus Keppler

LiveConfig nutzt die Standard-Quota-API des Betriebssystems. Wenn Sie also das "normale" Filesystem-Quota aktivieren dann sollte das automatisch auch mit LiveConfig funktionieren.
Um das zu testen, aktivieren Sie das Filesystem-Quota auf Gruppen-Ebene; wenn der Befehl "repquota -ag" eine Liste der Gruppen und deren Usage/Quota ausgibt, passt alles.

LiveConfig fragt die Quota alle 15 Minuten ab (LC.fs.getUserQuota). Die Aktualisierung (bei Änderung des Quotas in einem Vertrag) sollte innerhalb von 10-20 Sekunden erfolgen.

Viele Grüße

-Klaus Keppler

In der LiveConfig-Datenbank gibt es eine Tabelle namens APPREPO. Wenn Sie dort in der Spalte APPREPO.AR_DISABLED eine "1" setzen, wird die betroffene Applikation nicht mehr zur Installation angezeigt. Bereits vorhandene Installationen bleiben aber verwaltbar.

Derzeit werden die automatisierten Tests bei uns angepasst (Implementierung ist also schon abgeschlossen). Heute Abend oder morgen dürfte die Preview dann bereitstehen.

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