Beiträge von antondollmaier

    Eigener DNSBL WhitelistServer wäre ja schwachsin dafür, das wäre so die einzige Idee von uns, wie man das umgehen könnte, da Whitelist DNSBL ja den normalen DNSBL deaktiviert, was eigentlich eine Whitelist auch tun sollte. => rbldnsd <=


    rbldnsd ist die sinnvollste Lösung, falls die dnswl.org nicht nutzbar wäre.


    Nutzer-spezifische Domain-Whitelists können, wie schon mehrfach geschrieben wurde, zum Zeitpunkt der Blacklist(!)-Prüfung nicht realisiert werden.

    Version 2.7.4 (r5214)


    Ah ok, dann muss ich wohl warten, dachte es wäre drin, weil im return vom wsdl folgendes steht


    Stimmt, mein Fehler.


    Die Funktion ist bereits da, nur noch nicht im Handbuch.


    Aber die Möglichkeit, Weiterleitung o.ä. zu setzen, wie bei HostingSubdomainAdd, gibt es trotzdem nicht - damit bleibt mein Hinweis trotzdem bestehen: "aktuell nicht möglich".


    Kann mir da einer helfen?


    Zur not auch, mit Subdomain löschen und neu anlegen.


    "HostingSubdomainEdit" gibt es in Version 2.7 nicht, genausowenig wie "HostingSubdomainDelete". Somit ist das geplante Vorhaben aktuell gar nicht realisierbar.


    Mit Version 2.8 soll es wohl möglich werden:


    Zitat von https://www.liveconfig.com/de/lab

    Bearbeiten des SSL-Zertifikats einer Subdomain nun mittels SOAP-Funktion HostingSubdomainEdit() möglich

    kk Wie Sie sehen wollen wir alle eine Backup Lösung haben, wie schauts aus? Ist da schon was in Planung


    Schaut mal

    Zitat von https://www.liveconfig.com/de/forum/threads/2994-Preview-v2-8-0?p=17146&viewfull=1#post17146

    der neue Backup-Service (lcbackup) ist noch nicht in die GUI integriert


    Es gibt den Backup-Service also schon.

    Ich würde ihn nun gerne sukzessive bis zur aktuellen Ubuntu Version upgraden.


    Weiss jemand, wo hier evtl. Stolperfallen lauern. Gibt es ein HOWTO oder 'best practices' für das Upgrade?


    Für LiveConfig sind hier keine Besonderheiten nötig. "Einfach" an die regulären Update-Anweisungen (14.04 LTS -> 16.04 LTS -> 18.04 LTS) halten.

    Jetzt kommt auf allen Liveconfig-Servern folgende Fehlermeldung.


    Es ist ein Fehler aufgetreten
    0 SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://meinedomain:8443/liveconfig/soap?wsdl&l=admin&p=meinpasswort' : failed to load external entity "https://meinedomain:8443/liveconfig/soap?wsdl&l=admin&p=meinpasswort"


    Wurde PHP-Fehler-Log geprüft?


    Was passiert beim Aufruf der URL via CURL als POST? (curl -XPOST https://....?wsdl)

    Das bedeutet: es kann nicht ohne weiteres virtuelle SFTP-Benutzer geben (zumindest nicht so lange das über Port 22 = SSH läuft). mod_sftp setzt die Konfiguration eines eigenen Ports dafür vorraus (was man den Anwendern dann auch erst einmal erklären muss).


    Naja. System-Benutzer mit doppelter User-ID wären eine mögliche Lösung (so hat's Confixx mit den FTP-Accounts gemacht), was aber widerrum das chroot-Problem nicht löst.


    Die mod_sftp-Lösung ist relativ sexy, mit dem Nachteil des dedizierten Ports.


    Wer eher SFTP bevorzugen möchte, kann natürlich auch den SSHd auf z.B. 2201 legen und mod_sftp auf 22.


    Hier[tm] wird hauptsächlich SSH angefragt, so dass SFTP per se eigentlich irrelevant ist - und der Port-Wechsel eher hinderlich.


    Zitat

    Unsere Empfehlung daher: FTPS (FTP+SSL/TLS) verwenden - das unterstützen alle aktuellen FTP-Programme, und da sind keine Bastelarbeiten notwendig.


    Die Clients - schon.


    Die Firewalls - nicht.


    Wir hatten gerade in der Anfangszeit häufig Probleme mit Kunden, die den PASV-Mode über DPI freigeschalten haben. Nachdem die Firewall aber den PASV-Port nicht aus dem verschlüsselten Control-Traffic parsen konnte, wurde der PASV-Traffic gar nicht erst erlaubt.

    Aber: wir haben inzwischen schon mehrfach die Rückmeldung erhalten, dass mod_http2 zumindest bei Apache unter Debian 9 und Event-MPM beim Download von großen Dateien (>300MB) Probleme macht (einige Hoster haben das derzeit bewusst deaktiviert).


    Es gibt einen Bug in Event-MPM, der komplett den Apache lahm legen kann.


    Außerdem gibt es auch in Stretch einen Bug in HTTP/2, der Safari-Clients betrifft.


    Wir haben aktuell HTTP/2 aktiv (es sei denn, Kunden benötigen zwingend Safari...), aber von mpm_event auf mpm_worker umgestellt.
    Mit mpm_prefork ist HTTP/2 gar nicht möglich, wie kk schon schrieb.

    der Empfänger sie aber erhalten muss, dann haben wir ein (ggf. auch rechtliches) Problem.


    Nö.
    Entweder, die Mail wird von lcsam als "suspected Spam" markiert - und kommt dann durch.
    Oder sie wird rejected - kam also rein rechtlich niemals an.


    LiveConfig wurde ohne "Junk"-Ordner konzipiert. Das ist die rechtlich vollständig korrekte Lösung.

    SA läuft, Erkennung alles mit 0,0
    (...)
    allerdings ist dass das Verhalten seit Deb8-Deb9


    Debugging hoch, manuell via spamc eine Erkennung ausführen.


    Ich tippe auf ein Rechte-Problem. /var/lib/spamassassin enthält fast alle Regeln. Gehört der Ordner dem falschen Nutzer, kann SpamAssasssin die Regeln nicht lesen und somit auch keine Punkte vergeben.