Beiträge von tbc233

Ich hab grad auf einer meiner älteren 32bit Maschinen nachgesehen, da scheint disbezüglich alles in Ordnung zu sein.

Kommt irgendeine Meldung wenn Du den httpd_log Job manuell ausführst?

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 danke dir für den Tip. Ich hab jetzt mal die pagespeed.conf in der httpd-template inkludiert, dort aber "ModPagespeed off" rein gemacht.

In der .htaccess der gewollten Seite habe ich dann "ModPagespeed on" eingefügt.

Scheint soweit zu funktionieren.

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.

Ich kann leider derzeit auch nur ein Centos7 bieten dass ich dieser Tage auf 64bit angehoben habe. Hier hab ich keine PTR Probleme.

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.

Nachtrag: In der 64bit Version dürfte es hingegen gefixt sein.

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

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.

Ich habe jetzt nochmal die install-all.sh drüber laufen lassen und nun funktioniert es.

Bleibt ein bisschen mysteriös, aber tut jetzt wie es soll.

Danke für die rasche Antwort am Sonntag.

# ./pduclean.sh -a /usr/local/pd-admin2
Server Environment/Serverumgebung

   Series/Reihe  Release/Version  dotlessversion  READLINK_E
   ------------  ---------------  --------------  ----------------
   4             0.378            0378            readlink -e

activate inactive pdu files </usr/local/pd-admin2>
------------------------------------------------------------------------
/usr/local/pd-admin2/php5-5.6/lib/php.ini.pdu-0378
/usr/local/pd-admin2/lib/php.ini.pdu-0378
/usr/local/pd-admin2/etc/my.cnf.pdu-0378
/usr/local/pd-admin2/htdocs/squirrelmail/.htaccess.pdu-0378
------------------------------------------------------------------------

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?

Ich denke ich bin hier in völlige Anfängerfehler reingelaufen. Die Backups der user werden ja mit den Rechten vom user "pdbackup" und der Gruppe des Users erstellt. Das war dann natürlich so nicht möglich weil mein Backupziel nur für root beschreibbar war.

Sollte also geklärt sein und funktioniert jetzt auch.

Okay, ich bin einen Schritt weiter. Mein pd-admin Backup Ziel hatte nur Schreibrechte für root. Nachdem ich diese erweitert habe, funktioniert es nun.

Verstehen tu ich es allerdings nicht, der Backup Job wird doch schließlich als root ausgeführt...?

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

================
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

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?

Da kommt wohl was auf uns zu. Liest sich momentan als stünde ein zweites Heartbleed bevor.