... nur ein Schönheitsfehler aber unter LiveConfig->Status wird als neuste Version wird 2.9.3 release ausgegeben obwohl da ja nun 2.10.1 stehen müsste. Die LiveConfig-Version wird hingegen korrekt ausgegeben.
Beiträge von bravesurfer
-
-
Wurde die angekündigte neue Version wieder verworfen?
Etwas Infos wären nett!
-
Ja, die werden beide derzeit inhaltlich überarbeitet und in Kürze auch wieder online stehen.
Prima, danke!
Der Fehler ist nun auch behoben (Inkompatibilität nach einem PHP-Upgrade...
)Danke, funktioniert nun auch im Backend des Wiederverkäufers nun wieder und ich konnte bereits eine neue Lizenz in Echtzeit ordern. Wurde mir von dort auch bereits bestätigt.
-
Leider erhalte ich eine Fehlermeldung, wenn ich als Partner eine Lizenz ordere: "Error while ordering: Not Allowed (partner.php:170)"
Ich wollte gestern über meine Bezugsquelle und deren Backend eine weitere Lizenz ordern und erhielt eine ähnliche Fehlermeldung (Error while calling Web Service: Not Allowed).
-
WIrd es auch noch die bisherigen Wiki Beiträge zum Beispiel zu Multi-PHP und Autodiscover wieder geben?
Da fehlen im Moment ja einige nützliche Beiträge oder habe ich die nur nicht gefunden? -
steht doch oben, um den 1. Mai herum (Spaß)
P.S: Finde es nicht schlimm wenn solche Ankündigungen aus welchen Gründen auch immer, nicht eingehalten werden können, man sollte die Kunden dann aber nach Möglichkeit kurz informieren dass und warum es zu Verzögerungen kommt oder solche Ankündigungen bleiben lassen
-
Da hat uns die Bundesregierung mal wieder einen wirklich tollen Dienst erwiesen.
Ohne Worte!
Hier noch einige Hinweise/Praxistipps wie das seinerzeit von 16 auf 19 % geregelt wurde
-
Das Handbuch wird diesbzgl. gerade angepasst und zum 01. Mai aktualisiert. Um diesen Zeitpunkt herum ist auch das Release von v2.10 geplant.
Schon absehbar wann nun mit dem Release zu rechnen ist?
-
ich muss dem SA mal etwas auf die Sprünge helfen, bin mir aber nicht sicher welchen DB-Path ich dem sa-learn geben muss, damit das gelernte für alle Benutzer auf dem System genutzt wird.Klaus Rörig
Mich würde ebenfalls interessieren welchen -dbpath ich da setzen muss bzw. wie Liveconfig die bayes_seen und bayes_toks , die sich ja für jeden Nutzer unter /var/lib/spamassassin/POSTFACHBEZEICHNUNG befinden, anlegt.
-
Ich würde diese Funktion ebenfalls begrüßen
-
Sorry gerade gesehen dass diese schon zur Verfügung stehen, lediglich im LiveConfig-Wiki nicht aufgeführt sind.
-
Hallo,
wann werden den den PHP-Pakete für Debian 10 (Buster) zur Verfügung gestellt?
-
Danke für die Korrekturen!
-
Das passt nun auch soweit mit der Ausnahme dass hier die Benutzerverzeichnisse mit root:spamd mode=0750 angelegt werden, wen ich ein neues Postfach anlege.
-
Wie genau äußert sich "funktioniert [...] hier leider nicht mehr" denn? Welcher Fehler tritt auf, bzw. was wird in /var/log/mail.log während des Empfangs einer E-Mail protokolliert?
Keine Berechtigung user_prefs zu lesen. Konnte aber auch dieses Problem nun lokalisieren. Neue Nutzerverzeichnisse werden in /var/lib/spamassassin mit den Rechten root:spamd angelegt (bislang debian-spamd:debian-spamd), daher gab es in den bereits vor der Umstellung angelegten Verzeichnissen Probleme.
-
Es muss NICHTS angepasst werden! Lassen Sie die Dateibereichtigungen in /var/lib/spamassassin bitte unverändert auf "debian-spamd".
Dann funktionieren die Spamfilter hier leider nicht mehr!
-
Hallo,
nach purge und Neuinstallation von Spamassasin wird dieser unter spamd ausgeführt. Insofern wurde die /etc/default/spamassassin lediglich -u debian-spamd durch -u spamd ersetzt.
Außerdem habe ich den Besitzer der VZ und Dateien die debian-spamd gehörten im VZ /var/lib/spamassassin auf spamd angepasst. Hier funktioniert seitdem auf einen Testsystem alles zuverlässig und stabil.
Auf einem Produktivsystem habe ich allerdings bislang noch nicht getestet.
-
Denke ich konnte das Problem nun lösen.
nach Löschung (purge) und Neuinstallation, sowie Anpassung der /etc/default/spamassassin scheint es nun zu passen
Codenobody 1043 0.0 0.0 245808 176 ? Sl 18:21 0:00 /usr/lib/liveconfig/lcsam -g spamd -U postfix root 11821 0.0 0.2 193216 92992 ? Ss 19:01 0:01 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u -u spamd spamd 11822 0.0 0.2 194716 92596 ? S 19:01 0:00 spamd child spamd 11823 0.0 0.2 193216 88024 ? S 19:01 0:00 spamd childHerzlichen Dank für die Hilfe!
-
Was liefert der Befehl "ps aux | grep spamd"?
Das sieht derzeit so aus:
Coderoot 1641 0.0 0.1 220140 120200 ? Ss Aug18 0:36 /usr/bin/perl -T -w /usr/sbin/spamd -d --pidfile=/var/run/spamd.pid -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u -u debian-spamd debian-+ 2762 0.4 0.2 250896 148516 ? S 13:42 1:10 spamd child debian-+ 12772 0.1 0.2 237856 137476 ? S 16:06 0:10 spamd child nobody 20843 0.0 0.0 467004 2072 ? Sl 16:34 0:01 /usr/lib/liveconfig/lcsam -g spamd -U postfix -
Wie bereits im Preview Thread angesprochen läuft unter Debian 9.9 Spamassassin mit den Rechten des Nutzers debian-spamd.
Wenn ich nun eine Blacklist in LiveConfig konfiguriere sieht das bei mir so aus:
Zitat/var/lib/spamassassin debian-spamd:debian-spamd 0755
/var/lib/spamassassin/web1_1 debian-spamd:debian-spamd 0700
bzw. root:spamd 0750 (bei neu angelegten Postfächern)
/var/lib/spamassassin/web1_1/user_prefs root:spamd 0640Spamassassin kann daher die user_prefs nicht lesen und berücksichtigt deren Inhalt folglich nicht.
Wie lässt sich die am elegantesten korrigieren.
