Plesk Greylisting Manager

xeiko78 · Jun 26, 2014

Update auf 2.4.1 White- /Blacklist fehlt

Hallo miteinander,

bin sehr zufrieden mit GLM, doch nach dem Update auf 2.4.1 werden keine Einträge mehr in der White- /Blacklist angezeigt.
Die Dateien *.db sind noch vorhanden und werden von GLM auch automatisch mit den Nutzer und Ausführungsrechten versehen.
Die Daten sind ebenso in den Dateien vorhanden und scheinen auch abgearbeitet zu werden.

Wie kann ich die Anzeige wieder herstellen?

contix · Jun 29, 2014

Hallo Haggybear,

haggybear said:
Leider hatte ich beim Update-Paket einen falschen Wrapper mit drin.
Bitte den Wrapper von Hand neu bauen, dann läuft wieder alles

Leider ist noch immer im Installationspaket der wohl falsche Wrapper enthalten. Damit dürfte die automatische Aktualisierung scheitern. Leider habe ich keinen GCC installiert und kenne mich nicht damit aus.
Könntest Du den Wrapper bitte aktualisieren?

Danke und Gruß
Contix.

cyberdoro · Jun 30, 2014

SQLITE DATABASE FOLDER AND DATABASE FILES

Hallo
habe gestern auf die Version 2.4.1 upgedatet, seit der zeit springen die

/var/lib/plesk/mail/greylist/*.db"

immer wieder auf chmod 666 und somit läuft die Greylist nicht mehr.
Stelle ich manuell wieder chmod 777 wird beim nächsten Eintrag wieder chmod 666 draus.

Wo kann ich das umstellen ??

MfG
cyberdoro

vegeta · Jul 22, 2014

followed the install, and mails appear. But nothing else works. Pressing "pass selected" returns this error:

Code:

 PHP Notice: Undefined variable: session; File: /usr/local/psa/admin/htdocs/glm/json.php, Line: 22

file: /usr/local/psa/admin/plib/Smb/Exception/Syntax.php
line: 56
code: 0
trace: #0 /usr/local/psa/admin/htdocs/glm/json.php(22): Smb_Exception_Syntax::handleError(8, 'Undefined varia...', '/usr/local/psa/...', 22, Array)
#1 {main}

Exception: PHP Notice: Trying to get property of non-object; File: /usr/local/psa/admin/htdocs/glm/paa.class.php, Line: 139

file: /usr/local/psa/admin/plib/Smb/Exception/Syntax.php
line: 56
code: 0
trace: #0 /usr/local/psa/admin/htdocs/glm/paa.class.php(139): Smb_Exception_Syntax::handleError(8, 'Trying to get p...', '/usr/local/psa/...', 139, Array)
#1 /usr/local/psa/admin/htdocs/glm/glm.class.php(64): paa->setPleskSmtpType()
#2 /usr/local/psa/admin/htdocs/glm/json.php(22): glm->__construct(NULL, Array, Array)
#3 {main}

PHP Notice: Trying to get property of non-object; File: /usr/local/psa/admin/htdocs/glm/paa.class.php, Line: 139

file: /usr/local/psa/admin/plib/Smb/Exception/Syntax.php
line: 56
code: 0
trace: #0 /usr/local/psa/admin/htdocs/glm/paa.class.php(139): Smb_Exception_Syntax::handleError(8, 'Trying to get p...', '/usr/local/psa/...', 139, Array)
#1 /usr/local/psa/admin/htdocs/glm/glm.class.php(64): paa->setPleskSmtpType()
#2 /usr/local/psa/admin/htdocs/glm/json.php(22): glm->__construct(NULL, Array, Array)
#3 {main}

If i compile wrapper, postfix milter cant open databases at /var/lib/plesk/mail/greylist/ and rejects all mail.

Any help, since it was working perfectly in plesk 11 and is such an amazing tool?

Thanks.

vegeta · Jul 22, 2014

OK, narrowed it down to his error:

PHP:

PHP Notice: Undefined variable: session; File: /usr/local/psa/admin/htdocs/glm/json.php, Line: 22

Any help?

strenggeheim · Jul 26, 2014

cyberdoro said:
Hallo
habe gestern auf die Version 2.4.1 upgedatet, seit der zeit springen die

/var/lib/plesk/mail/greylist/*.db"

immer wieder auf chmod 666 und somit läuft die Greylist nicht mehr.
Stelle ich manuell wieder chmod 777 wird beim nächsten Eintrag wieder chmod 666 draus.

Wo kann ich das umstellen ??

MfG
cyberdoro

Ordner: sh
File glm_updater.sh
755 oder 666 -> 777
anschl. manuell noch einmal *db mit dem Verzeichnis greylist auf 777 stellen. Dann läuft es durch.

deepsleep · Jul 26, 2014

Klappt nicht

Hi Strenggeheim

Klappt bei mir nicht. Stellt auch danach die Dateien auf 666 zurück. Muss im Moment Greylisting ausschalten oder den GLM ausschalten, da sonst keine Mails ankommen.

Gruss
Deepsleep

Meinname · Aug 13, 2014

@deepsleep
das Problem mit der Rückstellung der Rechte auf 666 habe ich auch.
Es liegt daran, dass im GLM 2.4.1 in der Datei paa.class.php die *.db-Rechte in der Funktion CheckSqliteRights auf 666 gesetzt werden.

cyberdoro · Aug 23, 2014

GLM 2.4.1

@strenggeheim

Ordner: sh
File glm_updater.sh
755 oder 666 -> 777
anschl. manuell noch einmal *db mit dem Verzeichnis greylist auf 777 stellen. Dann läuft es durch.

Klappt leider auch nicht.

Ich habe in der (GLM 2.4.1) Datei paa.class.php die *.db-Rechte in der Funktion CheckSqliteRights auf 777 gesetzt, aber auch das hilft leider nichts.

Ich mußte wie @deepsleep den GLM ausschalten, da ich sonst keine Mails bekomme.

Ich habe auch schon den wrapper manuel installiert -> hilft auch nichts.

Auch die Automatikinstallation

[Version 2.4.1 verfügbar - jetzt updaten?]

klappt nicht. Sie läuft zwar durch und sagt mir auch alles I.O. aber es klappt nicht. Es steht dann wieder [Version 2.4.1 verfügbar - jetzt updaten?] da.

Hat sonst noch einer eine Idee ?

Ich habe Plesk 12.0.18 Update #13 mit CentOS 6.5 (Final).

Bierteufel · Aug 25, 2014

Hallo,

ich muss mich hier leider auch mal mit einklinken.

Nutze den GLM eigentlich recht gern, aber unter PSA 12.0.18 in Verbindung mit dem GLM 2.4.1 gibt es Probleme.

- Neues System (neu aufgesetzt)
- Rechte wurden wie beschrieben gesetzt
- 1. Einträge im GLM lassen sich nicht entfernen
- 2. Analyse der Mailkommunikation bringt ?

Code:

ERROR: uname:gname should be psaadm:sw-cp-server (now they are psaadm:psaadm)

Bierteufel · Aug 26, 2014

Was (leider) auch nicht passt, ist das der "Kunde" in seiner Greylistingansicht das volle Adminpanel des GLM sieht ?

(Siehe Anhang)

haggybear · Aug 29, 2014

Version 2.4.2

Ein wichtiges Security-Update. In der Version 2.4 und 2.4.1 ist es einem Reseller möglich in die Administration des GLM zu gelangen

Download -> http://haggybear.de/de/greylisting-manager
//EDIT: Attachment gelöscht, nur noch der letzte Post anhält die akt. Version.

Gruß
Haggy

Bierteufel · Aug 29, 2014

Kurzes Feedback zum GLM:

PSA 12#14 (Postfix) (CentOS)

- GLM 2.4.2 neu installiert
- Ansicht im Kundenbereich funktioniert wieder (nur der entsprechende Part wird angezeigt)
- WHOIS funktioniert auch wieder
- Black / Whitlisten werden nach setzen (manuell) /var/lib/plesk/mail/greylist/*.db auf 777 auch wieder gelesen / geschrieben

Was noch nicht geht:

- Analyse der Mailkommunikation: ERROR: uname:gname should be psaadm:sw-cp-server (now they are psaadm

saadm)

cyberdoro · Sep 1, 2014

GLM 2.4.1

Hallo
ich habe heute nochmal alles neu installiert auch den wrapper.
Habe die .db manuel /var/lib/plesk/mail/greylist/*.db auf 777 gesetzt und in der Datei paa.class.php auch geändert.

-rwxrwxrwx 1 root popuser 4096 Sep 1 03:56 data.db
-rwxrwxrwx 1 root popuser 102400 Sep 1 12:08 settings.db

Nun kann ich auch in den Black/Whitlisten schreiben und löschen.

Doch leider wenn ich im Plesk unter Spamfilter-Einstellungen die "Aktivieren Sie den Server-weiten Graylisting-Spamschutz" aktiviere bekomme ich keine mails mehr.

In der maillog erscheint folgender fehler

Sep 1 12:10:19 mail postfix/smtpd[16012]: C15B820746: milter-reject: DATA from mailoutxx.t-online.de[194.25.134.82]: 451 4.7.1 Service unavailable - try again later; from=<meineemail@t-online.de> to=<email@aufdemserver.com> proto=ESMTP helo=<mailoutxx.t-online.de>

Ist das nun ein fehler von GLM oder von Plesk ??

cyberdoro · Sep 1, 2014

Update GLM 2.4.1

kurzes update zu meinem Problem.

Mußte in der /etc/postfix/main.cf Datei den zweiten Eintrag wie folgt ändern:

von

smtpd_milters = , inet:127.0.0.1:12768
non_smtpd_milters =

auf

smtpd_milters = , inet:127.0.0.1:12768
non_smtpd_milters = , inet:127.0.0.1:12768

und postfix restarten (/etc/init.d/postfix restart).

GLM hat dann auch einen Eintrag gemacht und dann wieder alle emails geblockt, siehe mein vorherigen Eintrag.

Was er geändert hat sind die Rechte des Verzeichniss /var/lib/plesk/mail/greylist von 777 auf 755.

Kann ich irgendwo die Rechte automatisch vergeben lassen, wie bei den 2 /var/lib/plesk/mail/greylist/*.db Datenbanken ?

Bierteufel · Sep 1, 2014

Code:

451 4.7.1 Service unavailable - try again later

ist doch "korrekt" ?

cyberdoro · Sep 4, 2014

Das ist es ja auch. Für die erste email die er vom email Server bekommt!

Er sollte aber nach einer eingestellten Wartezeit (meistens 5min) die gleiche email annehmen und durchlassen.

Er sperrt aber alle emails.

Meine Frage war ja.....

Kann ich irgendwo die Rechte automatisch vergeben lassen, wie bei den 2 /var/lib/plesk/mail/greylist/*.db Datenbanken ?
Was er (ob GLM oder Plesk) geändert hat sind die Rechte des Verzeichniss /var/lib/plesk/mail/greylist von 777 auf 755.

frank.segelke · Dec 30, 2014

Hallo Bierteufel,

Zum Thema "Analyse der Mailkommunikation":
Erst den eigenen wrapper kompiliert. Danach wurde nichts angezeigt. Dann ändern der config.inc.php in Zeile 49:
Vorher:

PHP:

define("LOGFILE","/var/log/mail.info");

nachher:

PHP:

define("LOGFILE","/var/log/maillog");

Nun funktionierts.

Gruß
Frank

btw: Vielen Dank für das Admin-Panel, Haggy. Immer gerne gesehen

Bierteufel said:
Kurzes Feedback zum GLM:

PSA 12#14 (Postfix) (CentOS)

- GLM 2.4.2 neu installiert
- Ansicht im Kundenbereich funktioniert wieder (nur der entsprechende Part wird angezeigt)
- WHOIS funktioniert auch wieder
- Black / Whitlisten werden nach setzen (manuell) /var/lib/plesk/mail/greylist/*.db auf 777 auch wieder gelesen / geschrieben

Was noch nicht geht:

- Analyse der Mailkommunikation: ERROR: uname:gname should be psaadm:sw-cp-server (now they are psaadmsaadm)

SystemBuana · Jan 25, 2015

Statistik Probleme mit GLM2 (V 2.4.2)

<MOD>Fullquote von Bierteufel entfernt!</MOD>
Ich habe nach upgrade auf Plesk 12.0.18 #32 die gleichen Problemem wie die bisherigen Mitstreiter im Forum "erlebt". Es ging nichts mehr; also Neuinstallation mit der letzten von Haggybear hier im Foum "attachten" GLM2 Fassung vom August 2014.

Nach Anpassung vo Rechten der greylist DB und der darin enthaltenen DB's (chmod 777) scheint alles zu laufen, auch Änderungen der Black/Whitelisten scheinen möglich. Allerdigs existieren die gleichen Fehler wie von Bierteufel beschrieben:

1. löschen von EInträgen in der GLM Liste geht nicht
2. dauert die Mailzustellng eine Ewigkeit und
3. die Statistiken laufen nicht. Nach Sichtung des Errorlogs scheint in index.php ein Verzeichnisreferenzfehler zu sein (css-Dateien werden nicht in "/usr/local/psa/admin/htdocs/theme/css" gesucht sondern eine "Etage" drüber in "theme") siehe angefügten "error log"

@Haggy: hat sich mit Plesk 12 etwas gegenüber den bisherigen Plesk-Versionen verändert? Müssen die Referenzen in index.php geändert werden?
Warum kann in der GLM Liste nicht gelöscht werden?

Hoffe Du kannst heir helfen .... das Teil ist ansonsten Spitzenklassse und lief Jahre unter der alten Plesk Version 9.5.4 ohne Probleme!!!

SystemBuana · Jan 25, 2015

Statistik Probleme mit GLM2 Version 2.4.2

<MOD>Eigener Fullquote entfernt!</MOD>
So nachdem ich nun noch weitere 2 Stunden mit der Fehlereingrenzung verbracht habe, kann ich nun folgenden Zwischenstand mitteilen:

1. Nach erneuter Neuinstallation und Neucompilierung des "richtigen" Wrappers (ich hatte über das Forum wohl den falschen runtergeladen) läuft alles bis auf die Statistik wieder super "rund".
Gemäß errorlog sieht es in der Tat nach einem Verzeichnisproblem, wie bereits in meinem letzten "post" angemerkt, aus. Unverständlich für mich, da die Statistik vor dem Upgrade von Plesk 11.0.9 auf 12.0.18 #32 problemlos lief !!! (Also an dem GLM nichts verändert wurde!)
Da ich leider keinen Zugriff mehr auf einen Plesk 11.0.9 Server habe, kann ich die Veränderungen nicht nachvollziehen.

Hat jemand eine Lösung für das Statistik-Problem oder müssen die Verzeichnisse in index.php für Plesk 12 "nachjustiert" werden?

2. Rechte der DBs und des DB-Verzeichnisses müssen in der Tat auf "777" gesetzt sein.

3. Das komische Rechteproblem (rücksetzen der Rechte auf 666 des DB-Verzeichnisses und der db's selbst) hatte bei mir mit dem Plesk "mchk" Befehl zu tun. Einsatz wird nach Upgrade auf eine höhere Plesk-Version von Parallels angeraten!
Dieser biegt gesetzte Rechte bei der Rekonfiguration der Mail und SpamAssassin wieder um. Mir sind auch ehrlich gesagt "777" Rechte bei den DB's nicht ganz geheuer und ich denke, dass hier eine geschicktere Gruppenzuordnung vermutlich das Problem in der Zukunft lösen könnte.

Plesk Greylisting Manager

Registered User

New Member

New Member

New Member

New Member

New Member

New Member

New Member

New Member

Registered User

Registered User

Attachments

Registered User

Registered User

New Member

New Member

Registered User

New Member

Registered User

New Member

Attachments

New Member

We value your privacy