Ich habe jetzt gesehen dass auf dem betroffenen System im qmail-smtpd/run ein Softlimit von nur 50000000 drin ist. Andere (neuere) pd-admin Server haben hier 125000000. Also mehr als das Doppelte.
Ich werde mal versuchen diesen Wert anzupassen und dann wieder das neue /usr/local/pd-admin2 Verzeichnis in Stellung zu bringen. Da warte ich aber noch etwas bis sich die betroffenen User wieder beruhigt haben.
Ich muss das Thema nochmal aufgreifen, langsam verzweifle ich etwas.
Ich habe auf den betroffenen Systemen nun nochmal einen Versuch gewagt mit Update auf SE 0.369 (4) und pd-admin 4.70. Danach wieder kein Mailversand möglich. Meldung im Syslog
smtpd: 1605751813.541401 install_driver(mysql) failed: Can't load '/usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux/auto/DBD/mysql/mysql.so' for module DBD::m$
Spannend ist hier, dass diese Probleme anscheinend nur beim Absetzen von Mails (mit SMTP-Auth) auf dem Port 25 auftreten. Testmails von mir auf Port 465 (mit SSL) haben jederzeit funktioniert. Ebenso hat die reguläre Mail Einlieferung auf Port 25 stets funktioniert.
Nach einem Rück-Umbenennen des pd-admin2 Verzeichnisses auf die Version vor dem Update funktionierte alles wieder. Allerdings natürlich sehr unsauber, da nun wieder die alte Serverumgebung mit dem nagelnauen pd-admin läuft. Ich befürchte hier Side-Effects im Betrieb mit dieser Kombination.
Die eingesetzte Distri ist Gentoo. Mir ist klar, dass dies eher exotisch ist, andererseits setze ich seit 18 Jahren immer wieder mal pd-admin mit Gentoo ein und hatte vorher noch nie Probleme. Auch diese beiden betroffenen Systeme liefen vorher 3-4 Jahre stabil mit pd-admin.
Ich wäre hier sehr froh eine Lösung zu finden. Mir bliebe sonst nichts anderes übrig als diese beiden Server auf eine andere Distri zu migrieren (weil auf meinen Centos Servern habe ich dieses Problem nicht), das wäre natürlich ein sehr hoher Aufwand.
Danke vorab für jeden Input.
Schön dass ich helfen konnte.
Warum die Zuordnung der MAC Adresse des Interfaces zum Namen sich verändert hat, ist in der Tat mysteriös. Eigentlich dürfte das nur passieren, wenn sich die MAC Adresse des Interfaces ändert (zum Beispiel weil eine Netzwerkkarte getauscht wird oder man das System in einer anderen Hardwarekonfiguration hochfahren lässt). Möglicherweise ist es ja passiert, als Du die Platten im Ersatzrechner hochfahren hast lassen. Erklärt aber dann nicht, warum es vorher nicht ging.
Der genaue Hergang wird sich wohl jetzt nicht mehr rekonstruieren lassen. In jedem Fall weißt Du da aber jetzt Bescheid, weil dieses Procedere wird dann wieder wichtig sein, wenn Du tatsächlich mal auf den Ersatzrechner angewiesen bist.
Darum war das ifconfig -a wichtig, weil es alle Netzwerkschnittstellen anzeigt, auch die nicht konfigurierten.
Warum auch immer, ich würde jetzt mal als Ferndiagnose sagen dass sich die Zuordnung der MAC Adresse zum Interfacenamen verändert hat. Das ist ein udev Thema.
Du hast aus meiner Sicht zwei Möglichkeiten, entweder Du konfigurierst Dein Netzwerk auf die eth2 um, oder Du schaust ob Du klären kannst warum das physische Netzwerkinterface nun eth2 hat. Für letzteren Weg bin ich jetzt leider nicht so gut in Debian, aber ich würde hier mal nach /etc/udev/rules.d schauen. Dort könnte ein File liegen das zum Beispiel "70-persistent-net.rules" heißt (Name kann varieren). Dort steht zum Beispiel drin
Das könntest du auf eth1 adaptieren und rebooten. Andere Zeilen mit eth1 entfernen. Oder Du löschst das ganze File (vielleicht eventuell irgendwohin weg sichern), dann sollte es beim nächsten Reboot wieder neu aufgebaut werden und die Netzwerkinterfaces werden wieder neu durchnummeriert.
Doch die gab es auch damals schon, nur war es da noch die Beta.
hmmm... Schwierig jetzt nachzuvollziehen ob mir das passiert ist damals.
Vielleicht war es wirklich das und ich sollte mich hier nochmal über ein Update drüber trauen.
Ich würde hier gern kurz auf mein Problem RE: SMTP Versand bei 4-354 funktioniert nicht vom April referenzieren. Ich trau mich nämlich seitdem nicht mehr, diesen einen Server wo das passiert ist, upzudaten. Jetzt wo ich all dies hier gelesen und mitbekommen habe: Wär es denkbar dass ich hier damals versehentlich die 64bit Version erwischt habe? Oder gabs die damals noch gar nicht?
Der Gedanke kam mir, weil die Fehlermeldung in meinem Log damals sehr änlich war wie die hier genannte.
ich hab mir dafür eine "neutrale-domain.com" gekauft und lasse jeden server da drunter laufen (zb. server01.neutrale-domain.com und so weiter).
Ich rate ebenfalls dringend davon ab einen Hostnamen unter einer Domain zu verwenden, die Du später auf dem Server verwalten willst mit pd-admin. Glaub mir, da kommt nichts gutes dabei raus.
Du kannst dem Reseller User ganz normal mittels passwd auf der kommandozeile ein neues Kennwort geben. Dann öffnest Du Dir die /etc/shadow und kopierst den Kennwort-Hash raus (zwischen dem ersten und dem zweiten Doppelpunkt der Zeile) und fügst ihn in die Tabelle vadmin -> resellers ins Feld passwd ein.
Wäre es denkbar dass die ABSENDER Domain mal bei diesem Provider war? Ich hatte mal einen sehr ähnlich gelagerten Fall, da stellte sich dann raus dass die Domain früher mal bei diesem Empfänger-Provider war und die dann nie von deren Mailservern gelöscht wurde. Das heißt, deren Mailserver fühlten sich immer noch für die Absenderdomain zuständig und haben daher die Absendermailbox überprüft. Die existierte dann natürlich nicht (bei denen) und daher wurde rückgewiesen.
Das oder etwas in die Richtung würde es erklären.
Mir ist aufgefallen dass es nun einen Punkt "Dienste" im Endkundenmenü gibt. Ich konnte da jetzt mittels Forumssuche nichts dazu finden und es erschließt sich mir nicht was man hier machen kann. Sorry falls blöde Frage - aber weiß hier jemand bescheid?
Das ist nur eine Warning. Ich bild mir ein, die seh ich seit Jahren beim updaten/installieren. Korrigiert mich, aber ich habe hier noch nie Auswirkungen bzw. Fehler im Alltag festgestellt.
Meine Vermutung wäre, dass Einträge
.domain.de
(neben der regulären Zeile für domain.de)
existieren in /var/qmail/control/ rcpthosts und virtualdomains. Diese sorgen glaube ich dafür dass sich qmail für alle Subdomains zuständig fühlt. pdadmin hat diese Zeilen früher standardmäßig angelegt, seit einiger Zeit nicht mehr. Ich kann das auf einem langjährigen Server recht gut sehen, ältere Domains haben diese Zeile, neuere nicht.
Es wäre einen Versuch wert, diese Zeile mit dem punkt voran in beiden Files zu entfernen und qmail Dienste neu zu starten. Ich denke, dann wird qmail nicht mehr versuchen, Mails für die Subdomains lokal zuzustellen.
Könnten bei Dir vielleicht die Inodes knapp werden auf der Partition? check mal mit df -i
Prüf vielleicht auch mal Dein /opt/pdadmin/tmp/top/ Verzeichnis, das läuft bei langjährigen Installationen gern mal über (sofern kein Löschjob existiert) und war hier schon 1,2 mal für eine knappe Inode Situation verantwortlich.
Weiters den ipv6 Support verbessern. Ich weiß nicht ob sich hier was getan hat, aber momentan tut man sich nichts gutes, wenn man für den Hauptservernamen einen AAAA Record hinterlegt. Es führt dazu dass Leute die per ipv6 daher kommen, nicht auf die pdadmin Oberfläche kommen.
Ich hätte mal mit viel Hingabe alles in der apache Konfig (respektive template) adaptiert damit das funktioniert, nur um dann festzustellen dass die ipv6 Besucher einen Lizenzfehler bekommen beim pd-admin einloggen.
Den Auslieferungszustand und/oder die Installationsroutine verbessern.
Ich muss irgendwie bei einer Installation immer noch sehr viel manuell machen. Manche Dinge mach ich vielleicht obwohl sie gar nicht mehr nötig sind? Dinge wie
- dc-install.sh durchlaufen lassen, damit ich SSL auf den Maildiensten habe
- Cronjob anlegen damit mir das Verzeichnis /opt/pdadmin/tmp/top/ nicht vollläuft (hier gab es schon Fälle wo den Leuten die inodes ausgingen)
- Cronjob anlegen damit mir /var/log nicht mit xferlog Dateien übergeht
- fail2ban installieren (ohne fail2ban auf den Mailports betreibe ich keinen Server mehr - wäre genial wenn man das in die Umgebung intergieren könnte)
- $pop3_alt_login_field = 'email'; in pdadmin.conf einfügen. Bin unsicher ob das noch nötig ist aber ich glaube es ist nötig damit die Leute sich mit der E-Mail Adresse authentifizieren können
- Squirrelmail mittels htaccess sperren (das Ding sollte wirklich nicht mehr zugänglich sein)
Naja, Du könntest dem problematischen Empfänger ein Mail schicken und dabei das maillog beobachten. Dann musst Du nicht die 7 Tage warten. Bitte wie gesagt aber daran denken dass qmail meines Wissens nach nach dem Anlegen dieser Datei neu gestartet werden muss.
Der Fehler an sich ist seit Jahrzehnten in der qmail Szene bekannt. Der 1er sorgt dafür dass qmail mit den DNS einträgen umgeht, die es fälschlicherweise für falsch hält - lange geschichte. Wenn meine Diagnose stimmt, sollte das Mail damit nun raus gehen.
Ich würde es übrigens gut finden wenn die Serverumgebung mit diesem Wert ausgeliefert wird. Mir würde nichts einfallen was da dagegen spricht.
Man sollte hier nicht unerwähnt lassen dass die Geschichte von qmail und den CNAME Fehlern eine Geschichte voller Missverständnisse ist. Beim rumgooglen kann man Tage damit verbringen. Der Fehler kommt nämlich zum Beispiel auch wenn die DNS Antwort zu lang für qmail ist.
Die Serverumgebung hat hier vor einiger Zeit dankenswerterweise den ignorewronganswer Switch integriert.
Steht bei Dir eine 1 in der Datei /var/qmail/control/ignorewronganswer ? Wenn nein, leg die Datei an und mach eine 1 rein. Starte dann die Dienste neu und probiere es erneut.
Eine Änderung der eMail-Adresse bei "Zwei-Faktor-Authentisierung (2FA)" hat keine Auswirkung; d.h. die email-Adresse kann NICHT geändert werden.
Ich steh grad am Schlauch.
An welcher Stelle haben wir eine Zwei Faktor Authentifizierung?
