Beiträge von kk

    So etwas fällt unter "exotische Sonderfälle". Man kann das einrichten, allerdings nicht über die Oberfläche.


    Legen Sie im Kunden-Home-Verzeichnis eine Datei namens "conf/httpd.conf" an (also z.B. /var/www/<Vertrag>/conf/httpd.conf). Tragen Sie da folgende Zeilen ein


    Code
    <Location "/beliebiger-cgi-ordner">
      SetHandler cgi-script
      Options +ExecCGI
    </Location>


    Danach (!) speichern Sie im LiveConfig irgendeine Webspace-Einstellung dieses Vertrages neu (z.B: irgendeine Domaineinstellung mal kurz bearbeiten), damit die Apache-vHost-Konfiguration aktualisiert wird. Da wird diese httpd.conf dann mit eingebunden.

    Soll heißen das die Blackliste die der User unter der E-Mailadresse eingibt garnicht alle Einträge die dort drinn stehen abweist?
    Das wäre ja Fatal! Wenn also SpammAssassin die Adresse als gut befindet geht sie durch und wird zugestellt?


    Nein. Die Blacklist/Whitelist-Einträge werden natürlich vom SpamAssassin mit oberster Priorität verarbeitet.
    Wenn der Absender auf der Blacklist steht bekommt die Mail praktisch 999 Spam-Punkte, bei der Whitelist -999 Punkte.


    Die Blacklist- und Whitelist-Einstellungen werden im LiveConfig unterhalb des Spamfilters konfiguriert und sind nur bearbeitbar, wenn die Checkbox beim Spamfilter gesetzt ist (=Spamfilter aktiviert ist).


    Wenn Mails dennoch durch kommen hat das definitiv einen Grund, den man am einfachsten anhand der Log-Einträge in /var/log/mail.log herausfinden kann.
    Wenn Sie sich bei der Interpretation der Meldungen unsicher sind, schicken Sie bitte mal von einer "geblacklisteten" Absenderadresse aus mal eine E-Mail und senden uns *alle* Log-Meldungen, die während der Mailzustellung in der mail.log protokolliert werden, an support@liveconfig.com

    Das Blacklisting/Whitelisting betrifft SpamAssassin, d.h. die Mail wird ggf. im Rahmen der Spam-Analyse abgelehnt.
    Eine Möglichkeit wenn "nichts" passiert wäre, dass SpamAssassin nicht läuft. Prüfen Sie daher bitte mal, ob die Prozesse "lcsam" und "spamd" existieren.

    Das Feature mit den TLD-Wildcards ist in v2.10 enthalten (aktuelle Preview-Version).


    Zum o.g. Beispiel: es kann z.B. sein dass die betroffenen Spam-Mails über irgendeine andere Adresse ins System kommen (also quasi über eine lokale Weiterleitung); es wird praktisch nur der "erste" Spamfilter ausgewertet.
    Beispiel: Weiterleitung von a@example.org an b@example.org. Wenn nun eine E-Mail an a@example.org eintrifft ist egal was bei b@example.org im Spamfilter konfiguriert ist.


    In /var/log/mail.log wird eigentlich ziemlich ausführlich protokolliert, was während einer Zustellung passiert. Ggf. müsste man anhand der Message-ID (die man in den Mailheadern auslesen kann) im Maillog suchen, was genau während der Zustellung gelaufen ist.

    In der Datei /etc/dovecot/passwd sehen Sie die Zuordnung von E-Mail-Adresse (Postfach) zu Verzeichnisname (/var/mail/<Vertrag>/<Postfach-ID>/). Sie müssen also die Postfächer im LiveConfig neu anlegen, danach können Sie die Postfachinhalte aus dem Backup in die entsprechenden Verzeichnisse zurück verschieben.

    Ihnen ist schon bewusst, dass das unnötige Ressourcen kostet wenn wir Ihnen die Frage erst am Telefon beantworten und Sie danach die exakt selbe Frage noch mal im Forum stellen...?


    Zitat

    Ein API Komando hat einen Vertrag in die ewigen Jagdgründe befördert.


    Was für ein API-Kommando soll das denn überhaupt gewesen sein?


    Zitat

    Wir haben bei dieser Gelegenheit festgestellt, das dass Backup der LC Datenbank nicht so läuft wie es soll, somit ist dass keine Option.


    Wie genau sichern Sie Ihre LiveConfig-Datenbank aktuell?


    Und zur eigentlichen Frage (wie auch am Telefon schon so beantwortet): wenn Sie Daten in LiveConfig löschen, dann sind diese weg. Wenn Sie kein Backup der LiveConfig-Datenbank haben, gibt es nur die Möglichkeit, den betroffenen Vertrag wieder neu anzulegen.


    Viele Grüße


    -Klaus Keppler

    Natürlich.


    Ich halte persönlich überhaupt nichts davon, Mails automatisch in einen Spam-Ordner zu verschieben - das macht garantiert nur mehr Ärger. Die Zeit sollte man viel lieber in die Pflege & Tuning der Spamfilterung stecken, damit das Zeug überhaupt nicht erst rein kommt.

    Nein, da hat sich nichts geändert - die Thematik hat schließlich mit der Architektur von PHP-FPM zu tun.
    So lange diese sich nicht grundlegend ändert, bleibt die Problematik mit Shared Memory und Opcache bestehen.


    Socket Activation haben wir auf der Ideenliste stehen, eine Umsetzung derzeit aber noch nicht geplant.


    Viele Grüße


    -Klaus Keppler

    Die direkt verlinkten .deb-Dateien sollten nicht verwendet werden, sondern nur das Repository.


    Dabei die selben Daten wie für Debian 9 verwenden - nur "stretch" eben durch "buster" ersetzen:

    Code
    deb http://repo.liveconfig.com/debian/ buster php

    Es geht viel einfacher.
    unter "Serververwaltung" -> "Web" eine neue IP-Gruppe anlegen. Dort die gewünschte(n) IP(s) auswählen und TLS 1.0/1.1 deaktivieren - fertig. Als Beschreibung am besten so was wie "kein TLS1.0/1.1" angeben.


    Dann kann man durch's Bearbeiten der Subdomain (Hosting -> Domains) eben diese IP-Gruppe auswählen.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ab sofort steht die erste Preview von LiveConfig v2.10 zum Download bereit.
    Was die Änderungen betrifft verweise ich an dieser Stelle einfach auf das Changelog auf der Preview-Seite.
    Neben einigen Änderungen für automatisierte Deployments und größere Setups ist die wichtigste Neuheit das komplett überarbeitete Backup-System. Das Handbuch wird diesbzgl. gerade angepasst und zum 01. Mai aktualisiert. Um diesen Zeitpunkt herum ist auch das Release von v2.10 geplant.


    Wir haben diese Version vor einigen Stunden auf einigen Servern ausgerollt und gleich ein Problem beim neuen Backupservice in Multiserver-Umgebungen festgestellt, voraussichtlich wird es im Laufe des Tages also noch mal ein Update geben (ist ja schließlich auch eine Testversion...)


    Viele Grüße


    -Klaus Keppler

    Hallo,


    unsere PHP-Pakete für Debian/Ubuntu wurden auf die Versionen 7.2.30, 7.3.17 und 7.4.5 aktualisiert.


    Viele Grüße


    -Klaus Keppler


    PS: wir planen die Erkennung der verfügbaren PHP-Versionen zu überarbeiten, so dass auch alternative PHP-Pakete (deb.sury.org oder für CentOS die Remi-Pakete) komplett automatisch erkannt werden - die Registrierung via Lua soll mittelfristig also entfallen.

    LiveConfig unterstützt noch keine Wildcard-SSL-Zertifikate von Let's Encrypt.


    Die Validierung für solche Zertifikate müsste via DNS erfolgen, und das ist leider recht anfällig für Probleme (hauptsächlich das Caching).


    Es gibt zudem kaum ernste Anwendungsfälle für Wildcard-Zertifikate - in der Regel tun's ja auch "normale" Zertifikate.

    Meine ersten Ideen dazu:
    - ist der Webspace (web2) evtl. voll? (Quota prüfen) Das php-Errorlog wird mit Berechtigung des Benutzers erstellt
    - eine phpinfo()-Datei anlegen und aufrufen - dann prüfen ob die log_errors-Einstellungen etc. auch tatsächlich aktiv sind


    Und warum um alles in der Welt LiveConfig 2.7.4? Das ist über ein Jahr alt. Ein Server darf durchaus wöchentlich (!) aktualisiert werden.

    Ja, ich würde mal php-cgi installieren und versuchen ob "liveconfig --diag" dann die PHP-Erkennung korrekt ausführt.
    Wobei es eigentlich auch in dieser Kombination funktionieren sollte (also nur mit php-fpm) - das testen wir morgen bei uns mal durch.