Beiträge von kk

Which distribution do you use?

APC macht mit suPHP keinen Sinn, da bei suPHP zwangsweise bei jedem Aufruf eine neue ("frische") PHP-Instanz ausgeführt wird - Caching ist da nicht möglich.

Zur .user.ini bitte das Handbuch lesen: http://php.net/manual/de/configuration.file.per-user.php
Eine gültige Einstellung wäre also z.B. ".user.ini", und nicht ein vollständiger Name zu einer php.ini-Datei.

In der phpinfo-Ausgabe bekommen Sie im ersten Abschnitt ja angezeigt, welche php.ini-Datei konkret verwendet wurde ("Loaded configuration file"). Prüfen Sie dann einfach mal, was dort drin steht.

Spontan kann ich mir vorstellen, dass Sie noch eine "manuell" gepflegte php.ini-Datei haben (~/.php5/php.ini). Falls das so ist, löschen Sie diese Datei einfach und speichern die Webspace-Einstellungen bzw. den Vertrag im LiveConfig einfach noch mal neu ab.

Um das kurz klar zu stellen: LiveConfig löscht eine vHost-Konfiguration nur dann, wenn keine einzige Domain mehr damit effektiv konfiguriert ist. Das kann meines Wissens nur dann vorkommen, wenn Sie in der default-IP-Gruppe alle IPs deaktivieren.
"Von alleine" fasst LiveConfig diese Dateien jedenfalls nicht an.

Um diese neu schreiben zu lassen, nehmen Sie einfach irgendeine Änderung an den IP-Gruppen vor - danach werden alle betroffenen vHosts neu geschrieben.

Viele Grüße

-Klaus Keppler

Zitat von PatrickGreger

Nur seit heute nach einem System Update will der "Lcsam" nicht mehr und begründet das mit der folgenden Fehlermeldung:

warning: connect to Milter service unix:/var/run/lcsam.sock: No such file or directory

Das klingt danach dass lcsam nicht läuft. Können Sie das bitte mal in der Prozessliste prüfen? Mit "/etc/init.d/lcsam restart" sollten Sie diesen ggf. (neu) starten können. Falls der Prozess nicht hoch kommt, müsste es Log-Meldungen in /var/log/mail.log o.ä. geben.

Hallo Herr Groh,

ich habe das inzwischen mal auf einem System mit Debian 6 nachgespielt, hier klappt alles.
Wenn Sie als "Endkunde" im LiveConfig angemeldet sind und unter "Hosting" -> "Domains" eine Domain bearbeiten - ist dort auch die exklusiv zugewiesene IP-Gruppe ausgewählt und SSL für den Webspace aktiviert?
forum.liveconfig.com/cms/attachment/12/

Zitat von WebOscar

Bei dem Versuch die Seite via https aufzurufen kommt der Fehler "Fehlercode: ssl_error_rx_record_too_long".

Dieser Fehler tritt dann auf, wenn man per HTTPS versucht auf einen Port zuzugreifen, auf dem nur HTTP läuft.
In diesem Fall also klingt es so, als ob Apache auf dem Port 443 zwar erreichbar ist, dort aber kein SSL aktiviert/konfiguriert ist.

Auch die nachfolgende Beschreibung, dass keinerlei Zertifikate in /etc/ssl abgelegt sind usw. deutet auf fehlende SSL-Anweisungen hin.
Ich prüfe das eben mal in der beschriebenen Reseller-Konstellation und gebe gleich eine Rückmeldung.

Sie meinen das "***Spam-Verdacht***"? Prinzipiell ja (steht derzeit in der Datenbank), aktuell fehlt noch die GUI dafür. Folgt in einem der nächsten Updates.

In dem ab sofort bereitstehenden Update (v1.7.4-r2960) kann nun auch die PHP-Version bequem über die GUI umgeschaltet werden.
Eine Anleitung zur Installation bzw. Registrierung zusätzlicher PHP-Versionen in LiveConfig steht in der Wissensdatenbank bereit (KB#22).

Viele Grüße

-Klaus Keppler

Ab sofort steht ein Preview-Update (r2960) bereit; mit diesem läuft der lcsam-Prozess statt unter spamd:nogroup als nobody:spamd, außerdem werden die Rechte für den SpamAssassin-Socket entsprechend angepasst. Das Update korrigiert die vorherigen LiveConfig-Einstellungen automatisch.

Viele Grüße

-Klaus Keppler

Durch Setzen des Reject-Wertes auf z.B. "999" werden keine Mails abgelehnt. Über globale Sieve-Regeln kann man die Mails dann ggf. in eigene Ordner verschieben lassen.

Ich persönlich halte in einem Spam-Ordner unerkannt herumschlummernde Mails für viel problematischer als ordentlich (und berechtigt) abgewiesene Spam-Mails. Man sollte die Schwellwerte halt mit viel Feingefühl setzen.

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.