Beiträge von monderka

    Hallo,

    ich muss das nochmal ausgraben, da ich keine Lösung im Forum zu den Fall finde. Habe auf diversen Maschinen in letzter Zeit immer wieder haufenweise diese Meldungen:


    Oct 22 08:04:59 server15 spamd[11017]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:05:09 server15 spamd[11017]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:05:18 server15 spamd[11017]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:16:16 server15 spamd[13953]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:16:25 server15 spamd[13953]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:43:03 server15 spamd[25650]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:43:10 server15 spamd[25651]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:43:13 server15 spamd[25650]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:43:17 server15 spamd[25651]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists

    Oct 22 08:43:28 server15 spamd[25651]: bayes: cannot open bayes databases /var/spamd/.spamassassin/bayes_* R/W: lock failed: File exists



    Und die Dateien dazu sind:

    insgesamt 642516

    69075759 4 drwx------ 2 spamd spamd 4096 Okt 22 08:53 .

    69075525 4 drwxr-xr-x 4 spamd spamd 4096 Okt 22 08:42 ..

    69075054 4 -rw------- 1 spamd spamd 3600 Okt 22 08:52 bayes_journal

    69074953 4 -rw------- 1 spamd spamd 25 Okt 22 08:52 bayes.lock

    69075208 31712 -rw------- 1 spamd spamd 41824256 Okt 22 08:52 bayes_seen

    69075205 610768 -rw------- 1 spamd spamd 683732992 Okt 22 08:52 bayes_toks


    Wie kann man den bayes-Zugriff heilen? Hatte das jemand bereits gelöst und vielleicht vergessen die Lösung zu teilen?

    Also mir ist es mir Debian10 noch nicht gelungen nach meinem letzten Posting da was hin zu bekommen.

    Gott sei dank waren meine Debian9-Images wohl schon älter und damit konnte ich zuletzt auch die Maschinen noch aufsetzen. Was mir aber auch NIE gelungen ist war ein Dist-Upgrade, das hat auch immer zu CGI Fehlern oder sonst komischen Meldungen geführt. Ich lebe auch in der Hoffnung das es für aktuelle Debian Distributionen was gibt.

    Ich habe da die Domain eingetragen des kunden:


    z.B.

    da werden alle als Spam erkannten mails an @angastro.de abgewiesen und alle sonstigen durchgelassen in die Quarantäne-Postfächer.


    angastro.de:clam=yes,spam=yes,spam_passthru=no

    :clam=yes,spam=yes,spam_passthru=yes

    PD-Admin auf Debian 9 geht auch problemlos zu installieren wenn die IPv6-Einträge auskommentiert werden, sofern man einen PD-Admin darauf neu installiert.

    Eine ältere PD-Admin-Installation auf einem Debian8 mit dist-upgrade auf Debian9 führte zu oben genanntem administrator.cgi general protection ip Fehler. Habe aber auch bisher niemanden gefunden der auch probiert hat dist-upgrades mit pd-admin zu machen und seine Erfahrungen damit geteilt hat.

    Zusätzlich muss noch simcontrol angepasst werden, sonst gehen die spam als markiert durch und werden nicht abgewiesen.

    Geht aber nur generell nicht für Spam-Domains individuell


    vi /var/qmail/simcontrol/simcontrol

    domain.com:clam=yes,spam=yes,spam_passthru=no

    :clam=yes,spam=yes,spam_passthru=yes


    Änderungen im simcontrol aktivieren:

    /var/qmail/bin/simscanmk

    /var/qmail/bin/simscanmk -g

    Ich habe jetzt mal eine Debian9-Minimal zunächst auf Debian10-Minimal direkt nach der OS-Installation geupdated und danach die PD-Admin-Installation gemacht (packete und Vorgehen poste ich mal später wenn alles funktioniert).


    Ab der Installation des dc-Scripts tritt wieder der libc Fehler (general protection ip) auf:


    root@server ~ # ./dc-ssl-install.sh

    + '[' '' == '' ']'

    ++ /opt/pdadmin/bin/hostname.pl

    + H=server.domain.de

    + test -e /opt/pdadmin/sslcerts/server.domain.de-key

    + touch /var/qmail/control/servercert.pem

    + chown qmaild:nofiles /var/qmail/control/servercert.pem

    + chmod 440 /var/qmail/control/servercert.pem

    + cat /opt/pdadmin/sslcerts/server.domain.de-key /opt/pdadmin/sslcerts/server.domain.de-cert /opt/pdadmin/sslcerts/server.domain.de-cacert

    + touch /usr/local/pd-admin2/share/imapd.pem

    + chown qmaild:nofiles /usr/local/pd-admin2/share/imapd.pem

    + chmod 440 /usr/local/pd-admin2/share/imapd.pem

    + cat /opt/pdadmin/sslcerts/server.domain.de-key /opt/pdadmin/sslcerts/server.domain.de-cert

    + ln -sf /usr/local/pd-admin2/share/imapd.pem /usr/local/pd-admin2/share/pop3d.pem

    + cat /opt/pdadmin/sslcerts/server.domain.de-cacert

    + '[' '!' -e /service/qmail-smtpSd/run ']'

    + cd /usr/src

    + wget http://download.pd-admin.de/qmail-smtpSd.tar.gz

    --2019-07-09 09:47:16-- http://download.pd-admin.de/qmail-smtpSd.tar.gz

    Auflösen des Hostnamens download.pd-admin.de (download.pd-admin.de)… 2a02:e00:ffff:fff5:225:90ff:fe05:101, 130.255.184.84

    Verbindungsaufbau zu download.pd-admin.de (download.pd-admin.de)|2a02:e00:ffff:fff5:225:90ff:fe05:101|:80 … verbunden.

    HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK

    Länge: 947 [application/octet-stream]

    Wird in »qmail-smtpSd.tar.gz« gespeichert.


    qmail-smtpSd.tar.gz 100%[===================>] 947 --.-KB/s in 0s


    2019-07-09 09:47:16 (96,7 MB/s) - »qmail-smtpSd.tar.gz« gespeichert [947/947]


    + tar xzf qmail-smtpSd.tar.gz

    + mv qmail-smtpSd /service

    + mkdir -p /etc/ssl/

    + cat /opt/pdadmin/sslcerts/server.domain.de-cacert

    + grep -q '^ssl *= *yes' /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/conf.d/10-ssl.conf

    + /usr/local/pd-admin2/CONFIGURE/dovecot-2.2.sh

    default_process_limit = <1000>

    mail_max_userip_connections = <50>

    Bestehende Konfiguration wird nach dovecot.2019-07-09-09:47:16 verschoben ...

    OK.

    Konfigurations-Template wird kopiert ...

    OK.

    Datenbankpassword wird ermittelt ...

    OK.

    Datenbankzugriff wird eingerichtet ...

    OK.

    andere Variablen werden gesetzt ...

    OK.

    Berechtigungen werden angepasst ...

    OK.

    certificate found, enable ssl/tls

    Dovecot-Konfiguration abgeschlossen.

    + svc -du /service/dovecot22/

    + grep TLSRSACertificateFile /usr/local/pd-admin2/etc/proftpd.conf

    + cat

    + killall proftpd

    + crontab -l

    + grep -q update_tmprsadh

    + cd /usr/src

    + wget download.pd-admin.de/.cron_tmprsadh.pl

    --2019-07-09 09:47:19-- http://download.pd-admin.de/.cron_tmprsadh.pl

    Auflösen des Hostnamens download.pd-admin.de (download.pd-admin.de)… 2a02:e00:ffff:fff5:225:90ff:fe05:101, 130.255.184.84

    Verbindungsaufbau zu download.pd-admin.de (download.pd-admin.de)|2a02:e00:ffff:fff5:225:90ff:fe05:101|:80 … verbunden.

    HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK

    Länge: 572 [application/x-perl]

    Wird in ».cron_tmprsadh.pl« gespeichert.


    .cron_tmprsadh.pl 100%[===================>] 572 --.-KB/s in 0s


    2019-07-09 09:47:19 (1,79 MB/s) - ».cron_tmprsadh.pl« gespeichert [572/572]


    + perl .cron_tmprsadh.pl

    + /var/qmail/bin/update_tmprsadh

    Generating RSA private key, 512 bit long modulus (2 primes)

    ..........................+++++++++++++++++++++++++++

    .+++++++++++++++++++++++++++

    e is 65537 (0x010001)


    Generating DH parameters, 512 bit long safe prime, generator 2

    This is going to take a long time

    .................+....++*++*++*++*++*


    Generating DH parameters, 1024 bit long safe prime, generator 2

    This is going to take a long time

    ...+.............+................................................................+........................+...............................+........+......................................+.......+............+.....................................................+....................+...................................................................................+........++*++*++*++*++*

    + /opt/pdadmin/bin/httpd_vhosts.pl

    Writing /usr/local/pd-admin2/conf/httpd.conf

    ./dc-ssl-install.sh: Zeile 69: 1055 Speicherzugriffsfehler /opt/pdadmin/bin/httpd_vhosts.pl



    Mit Ergebnis in der Kernel-Log:

    Jul 9 09:47:24 server kernel: [ 133.291809] traps: httpd_vhosts.pl[1055] general protection ip:f7d13680 sp:ffb441e4 error:0 in libc-2.28.so[f7c58000+1d7000]


    Also gehe ich mal davon aus das PD-Admin aktuell nicht Debian10-Kompatibel ist, zumindest was das httpd_vhost.pl betrifft.

    Das habe ich schon gemacht, das hat keinen Einfluss. Ich gehe - nach einigem Googln wirklich davon aus das die libc Updates nicht mit den PD-Admin Binaries (oder besser die Binaries mit den libc-Versionen) kompatibel sind. Denn genau das gleiche verhalten hatte ich beim Update von Debian8 auf Debian9 mit der administrator.cgi (libc auf 2.24 hoch gesetzt) und jetzt mit der httpd_vhost.pl (libc auf 2.28.10 hoch gesetzt).


    Was ich aber in der Tat seltsam finde ist das bei Neuinstallationen der Distibution alles im PD-Admin tadellos funktioniert.

    Das Update hier von Debian9 auf Debian10 habe ich auf zwei unterschiedlichen Testservern parallel gemacht - weil ich im ersten Anflug gar keinen Fehler festgestellt hatte bei der ersten Maschine - und bei beiden genau das gleiche verhalten das die httpd_vhost.pl den general protection ip Speicherfehler wirft. (Unterschiedliche Hardware unterschiedlich viel RAM, beide maschine nur blankes PD-Admin mit Debian9 Minimal auf Debian10 - ohne Kunden.

    Vielleicht kann ja mal Herr Bradler eine Idee in den Ring werfen was das sein könnte.

    Ansonsten werde ich keine Dist-Upgrades mehr machen. Wenn das Debian10-Minimalimage verfügbar ist werde ich eine komplette Neuinstallation auf Debian10 testen.

    Hallo,


    damals hatte ich das Debian9 nochmal komplett neu installiert und dann gibt es mit dem neuen Pd-Admin auch problemlos.

    Nun habe ich auf der Maschine - da es sich um eine Testmaschine handelt die als Vorbereitung auf Live-Updates dient - von Debian9 auf Debian10 geupdated. Und genau wieder das gleiche Problem:


    Jul 8 14:49:51 server10 kernel: [ 142.206138] traps: httpd_vhosts.pl[4378] general protection ip:f7d60680 sp:ffa5b794 error:0 in libc-2.28.so[f7ca5000+1d7000]

    Jul 8 15:06:18 server10 kernel: [ 1129.759808] traps: httpd_vhosts.pl[6698] general protection ip:f7cfc680 sp:ffbd49f4 error:0 in libc-2.28.so[f7c41000+1d7000]

    Jul 8 15:22:50 server10 kernel: [ 2121.042094] perf: interrupt took too long (2580 > 2500), lowering kernel.perf_event_max_sample_rate to 77500

    Jul 8 15:44:48 server10 kernel: [ 3439.504239] perf: interrupt took too long (3358 > 3225), lowering kernel.perf_event_max_sample_rate to 59500

    Jul 8 15:46:04 server10 kernel: [ 3515.763794] traps: httpd_vhosts.pl[14834] general protection ip:f7d8f680 sp:ffc07914 error:0 in libc-2.28.so[f7cd4000+1d7000]


    Ist es dann also nicht empfehlenswert per Dist-Upgrade mit PD-Admin zu agieren sondern dann immer zu migrieren?

    Das Debian selbst funktioniert nach dem Distributionsupgrade eigentlich problemlos, aber wenn die Scripte nicht zuverlässig laufen ist ein Upgrade auf einer Livemaschine ziemlich riskant.

    Hallo, folgendes ist mir jedoch auf einem SE Reihe 6 aufgefallen was unterschiedlich ist:


    Bei 4.61 fehlen die S-Bits-Rechte.


    Version 4.61:

    apache-errorlog:

    [Mon Jul 01 07:34:20.436074 2019] [core:crit] [pid 7909:tid 140182454028032] (13)Permission denied: [client 195.34.83.133:26255] AH00529: /usr/local/pd-admin2/htdocs/forbidden/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/usr/local/pd-admin2/htdocs/forbidden/' is executable

    Bei allen Zertifikaten die wir bisher hatten muss nach dem install-script die Datei überarbeitet werden und der Zeilenumbruch manuell rein.

    /var/qmail/control/servercert.pem


    Ich hatte noch keine Installation bei der das nicht der Fall war.
    Das hatte ich auch schonmal in einer Installationanleitung für Debian 9.2 angemerkt, weil ich auch ewig nach dem Fehler bei den Mails gesucht hatte...


    Debian 9 "Stretch" mit PD Admin

    Tritt bei uns auf allen Servern auf. Ich habe jetzt überall die whitelist.ign2 Datei angelegt.

    In der Hoffnung das es dann geht. Echt ärgerlich.


    [Update]

    die whitelist.ign2 Datei im Verzeichnis /usr/local/pd-admin/shared/clamav bringt gar nichts.

    Die Mails werden trotzdem abgelehnt.


    [Update 2]

    Neuer Versuch: Clamd nochmal durchstartet svc -du /service/clamd

    Weiterer Hinweis:

    https://forum.directadmin.com/archive/index.php/t-57936.html

    Bei uns heute morgen auch:


    /usr/local/pd-admin2/bin/freshclam

    ClamAV update process started at Mon May 27 07:46:54 2019

    main.cvd is up to date (version: 58, sigs: 4566249, f-level: 60, builder: sigmgr)

    daily.cld is up to date (version: 25461, sigs: 1581583, f-level: 63, builder: raynman)

    bytecode.cvd is up to date (version: 328, sigs: 94, f-level: 63, builder: neo)



    Diagnoseinformationen für Administratoren:
    Generierender Server: Server.KUNDENEXCHANGE.LOCAL
    Heinz.empfaenger@empfaenger.net
    server14.domain.de
    Remote Server returned '554 Your email was rejected because it contains the Win.Exploit.CVE_2019_0903-6966169-0 virus'

    Hallo,


    am Symlink für Perl liegt es nicht. Der ist korrekt gesetzt.

    Bei anderen Installationen die neu auf Debian9 installiert wurden geht auch alles problemlos - selbst ohne Perl-Symlink. Nur bei dem apt-get dist-upgrade System von Debian8 auf Debian9 geht der Administrator nicht.


    Wenn alles nichts hilft setze ich die Maschine nochmal neu auf, aber mit dem update wäre es natürlich weniger aufwendig. Zumal alles andere scheinbar problemlos läuft.


    viele Grüße

    Manfred

    Hallo Zusammen,

    ich habe heute eine Maschine von Debian8 auf Debian9 upgegraded und nach dem Upgrade geht der Login in den /administrator nicht mehr.

    Die Zugangsdaten-Seite geht und danach Internal Server Error mit folgenden Logfile-Einträgen.

    Komischerweise geht aber /customer problemlos


    Reihe4 0.332 aktueller Stand der SE und PD-Adminversion 4.60


    kern.log

    May 24 09:57:13 server05 kernel: [ 1713.772890] traps: administrator.c[12007] general protection ip:f7631da1 sp:ffbed85c error:0

    May 24 09:57:13 server05 kernel: [ 1713.772906] in libc-2.24.so[f752d000+1b1000]


    errorlog Apache24

    [Fri May 24 09:57:13.340384 2019] [cgid:error] [pid 11166:tid 140601667200768] [client 80.153.150.43:56309] End of script output before headers: administrator.cgi, referer: https://server05.xxxxx.de/administrator/


    habe schon versucht die administrator.cgi zu löschen und mit dem update-script vom letzten pd-admin update die zu erstetzen. Das geht auch aber der Fehler bleibt.


    any idea?


    Manfred

    Ich habe die Konfiguration im apache24 auch mal hinterlegt und das wirkt sich natürlich mit korrekten DNS vor und rück auflösungen für den Mailverkehr positiv aus und geht dann korrekt.

    Aber der PD-Admin ist dann für /customer nicht mehr erreichbar weil nach dem Login die Meldung kommt das zu viele Domains registriert sind und wohl der Lizenzschlüssel nicht richtig ausgewertet wird. (der ja auch nur auf die IPv4 gebunden ist).


    Wie macht es den providerdienste.de bei B&K, die müssen doch auch korrekt Mails raus geben UND den /customer für die Kunden offen haben. Natürlich kann man IPv6 komplett weg nehmen, aber zeitgemäß ist das natürlich auch nicht mehr.


    Gibt es da noch weitere Praxis-tipps wie ihr das macht?

    Hallo Martin,


    mit welchem Zertifikatsanbieter hast du das so automatisiert? Wenn die Zertifikate 2 Jahre gelten wäre das auch eine Überlegung wert. Wenn es da andere Anbeiter als letsencrypt geben würde die mit PD-Admin arbeiten wäre ich schon offen dafür. Ich hatte mal mit Comodo versucht aber bin da irgendwie nicht weiter gekommen.


    viele Grüße

    Manfred