Beiträge von tbc233

    Mir ist übers Wochenende auf einem Server irgendein qmail Prozess hängen geblieben. Die Folge war, dass nichts zugestellt wurde, weder lokal noch remote. /var/qmail/bin/qmail-qstat zeigte eine relativ hohe Menge unter "messages in queue but not yet preprocessed" an.


    Ich habe in dem Fall nicht lange gesucht, sondern die Serverumgebung neu gestartet. Danach wurde das alles zugestellt.


    Ich will mich deswegen jetzt nicht verrückt machen, aber ein bisschen paranoid macht einen das schon, zumal sich dieser Zustand mit keinem Monitoring erkennen lässt.


    Kennt das jemand bzw. weiß jemand wie es dazu kommen kann? Einzelfall?

    Du musst in der Tabelle "domains" der Datenbank "vadmin" für jede Domain die IP Adresse umstellen (Feld "ip"). Ich mach das immer direkt über phpmyadmin.


    Ansonsten sollte ein Speichern des neuen Hostnamens dann genügen (mach aber noch einen Kontrollblick auf die Datei /var/qmail/control/me - die legt fest mit welchem Hostnamen sich der Server im SMTP Dialog meldet. Ich bilde mir ein dass ich die zuletzt immer händisch anpassen musste).


    Wenn Du das Gefühl hast, dass dir die Invervalle zum Neuschreiben der httpd.conf zu wenig Zeit lassen, stoppe Deinen Cron Dienst vorübergehend.

    Ich hab gemäß Pagespeed aktivieren ein wenig mit mod_pagespeed experimentiert. Es gefällt mir eigentlich nicht schlecht, es hat sich aber auch recht rasch gezeigt dass das Ding sich nicht für jede Website eignet. Bei Tests von 4 Websites waren die Ergebnise bei dreien recht zufriedenstellend, bei einer kam es zu Fehlern.


    Nun frag ich mich, wie man das für eine einzelne Seite bzw. einen einzelnen Kundenaccount aktivieren könnte? Hat da jemand eine Idee?


    Dankeschön.

    Hier können durchaus Distributions- bzw. Kernelversions abhängige Unterschiede sein. Als ich zuletzt hier Probleme hatte (wenn auch mit anders gelagerter Fehlermeldung, aber es war ebenfalls PERL Zeugs), musste ich auf meinen Gentoo Servern auf 125000000 erhöhen, auf meinen Centos Servern war das nicht nötig. Probiers mal.

    Wie oben editiert, sorry - ich hatte anfänglich behauptet die Rückweisungen wären legitim und hatte dass sogar mit einem dig Schnipsel belegt, der zeigt dass es durchaus NICHT legitim war ;-)
    War leider abgelenkt.


    Wie auch immer, nachvollziehen kann das Problem nicht auf meinen Servern und ich denke auch andere hier wären schon von Ihren Anwendern gelyncht worden wenn es so wäre. Daher glaubte ich hier eher an ein lokales DNS Problem und würde mal entsprechend testen. Zum Beispiel mal irgendeinen anderen Nameserver in die resolv.con rein machen.

    Ich kann das nicht bestätigen, eben sicherheitshalber nochmal getestet.

    Für die weitere Fehlersuche: Ich würde mal andere Nameserver in Deiner resolv.conf antesten.


    (Info: Habe Beitrag nachträglich editiert, hatte zunächst behauptet die Zurückweisungen wären legitim da tatsächlich kein PTR Record vorhanden wäre, das war absoluter Quatsch. Sorry, man sollte halt keine Fehlersuche betreiben während man nebenbei telefoniert)

    Danke Twilo, aber ich hab jetzt in der Zwischenzeit leider auch kein System mehr mit 32bit pd-admin, da ich bei den paar Servern wo ich das Problem hatte die 64bit drüber genagelt habe (wo das Problem nicht besteht).


    Ich werd das jetzt zum Anlass nehmen und die nächsten Tage überall die 64bit installieren. Bisher war ich da etwas schüchtern und habe weiterhin die 32bit verwendet, aber es scheint soweit alles gut zu laufen damit.

    Ich hab eben das Update pd-admin v4.81 das diesen Fehler fixen soll installiert (32bit Version). Leider kommt der Fehler immer noch.


    Code
    Can't locate ConsolidatedAdminAndCustomerCode.pm in @INC (@INC contains: /opt/pdadmin/lib /usr/local/pd-admin2/lib/perl5/5.10.1/x86_64-linux /usr/local/pd-admin2/lib/perl5/5.10.1 /usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux /usr/local/pd-admin2/lib/perl5/site_perl/5.10.1 /usr/local/pd-admin2/lib/perl5/site_perl .) at /opt/pdadmin/bin/httpd_log.pl line 13.
    BEGIN failed--compilation aborted at /opt/pdadmin/bin/httpd_log.pl line 13.

    Wenn Du mit greylisting keine Freude hast, kannst Du es im /administrator Bereich unter "Serverkonfiguration" deaktivieren. Wer dir dieses UNCHECKED eingefügt hat, kann ich nicht sagen - pdadmin war es ziemlich sicher nicht.

    Danke für die rasche Antwort am Sonntag.


    Habe auf einem Server für eine Domain das DKIM aktiviert. Dennoch wird an die Mails keine DKIM Signatur angebracht.

    Auch keine Fehlermeldung in den Logs.


    Die entsprechenden Dateien unter /var/qmail/control/domainkeys/ sind alle da.


    Mein Verdacht ist, dass es irgendwie damit zusammenhängt dass es sich um einen Server handelt, den ich punkto SEU und pdadmin Updates seeehr vernachlässigt habe (da er länger nicht am Netz war). Vielleicht fehlt nun in irgendeiner Config Datei ein entsprechender Eintrag, nun da ich zwei Jahre an Updates übersprungen habe.


    Hat jemand eine Idee wie ich das weiter debuggen könnte?

    Mir ist heute auf einem relativ neuen Server mit Centos 8 das backup.pl keine Backups erzeugt hat die letzten Nächte.


    Führe ich es händisch aus, hagelt es "permission denied" Fehler. Beispiel


    Code
    ================
    tar: Removing leading `/' from member names
    tar (child): /backup/user/USERNAME/0/backup.tar.gz: Cannot open: Permission denied
    tar (child): Error is not recoverable: exiting now
    tar: /backup/user/USERNAME/0/backup.tar.gz: Cannot write: Broken pipe
    tar: Child returned status 2
    tar: Error is not recoverable: exiting now
    mysqldump: [Warning] Using a password on the command line interface can be insecure.
    Backup: USERNAME
    ================


    Im System Log / dmesg findet sich


    Code
    process 'opt/pdadmin/bin/httpd_vhosts.pl' started with executable stack


    Als Hinweis dazu habe ich "execstack" gefunden - https://linux.die.net/man/8/execstack - Ist das was Neues? ;)


    Hat jemand eine Idee wie ich das Backup zum Laufen bekomme?