Beiträge von tbc233

Nochmal zum Thema "relaylock", das klingt für mich irgendwie so nach 2006

Gabs den nicht tatsächlich mal früher in diesen Dateien? War das nicht das Ding das "smtp after pop" früher abgearbeitet hat?

Vielleicht bin ja einfach ich nur so schwer von Begriff, aber ich habe, außer dass diese Datei recht chaotisch aussieht, keine Ahnung worauf Du hinaus wollen könntest.

Gemessen daran dass wir alle uns recht bemüht haben Dir zu helfen, könntest Du jetzt schon noch die zwei Minuten investieren um ein wenig genauer zu erklären wie Du es gelöst hast.

Zitat von WebTeufel

für 25 fehlt Zertifikat scheinbar, wie und wo kann ich es nach gucken, nachreichen?

Port 25 ist unverschlüsselt und verwendet kein Zerti. Das macht mich ja so stutzig.

Ich persönlich denke, dass Du Verdachtsmomente hinsichtlich Zertifikate und SSL eher hinten anstellen solltest. Weiter oben hast Du ja angedeutet dass es auch völlig unverschlüsselt über Port 25 nicht funktioniert. Das würde ich zuerst versuchen zu klären. Kannst Du von aussen über Port 25 was versenden?

Zitat von Sumeragi

in Titel steht dovecot

Daran bin ich ich mitschuldig, als ich den Thread zerteilt habe ist das passiert. Habe es angepasst.

Zitat von Sumeragi

Laut der lsof Ausgabe laufen die Dienste auf Port 25 und 587

Das komische ist halt, dass auf diesen Ports ja gar keine Zertis involviert sind und es bricht bei ihm trotzdem ab.

Zitat von Sumeragi

Es wurden auch keine Log Einträge bzgl. Speicherlimits gepostet

Hier muss man fairerweise sagen dass auch in der Vergangenheit die Logausgaben nicht gerade eindeutig waren, wenn die Speicherlimits zugeschlagen haben. Ein testweises hochsetzen der Limits kann hier sicher mal nicht schaden.

Hats denn was gebracht? Damit die Einstellung zieht, musst Du btw die Dienste neu starten oder den Server rebooten.

den hier

config: Warning: service auth { client_limit=5000 } is lower than required under max. load (6000)

halte ich für unbedenklich, ist nur eine Warning, sehe ich auch sehr oft. Hat mit Deinem Fehlerbild ziemlich sicher nichts zu tun.

Dass die Verbindungen abbrechen könnte mit dem Softlimit zusammenhängen. Hier gab es öfter den Fall, dass hier die Werte nach Updates, neuere Kernelversionen etc. nicht mehr ausreichend waren.

Kontrollier mal /service/qmail-smtpd/run, /service/qmail-smtpSd/run und /service/qmail-msa/run, da sollte bei dem -m Flag auf jeden Fall zumindest 128000000 drin stehen.

Ich war mal so frei dass in ein eigenes Thema zu verschieben, den vorigen Thread hätte das nur noch mehr verwässert.

An Deiner Stelle würde ich das dc-install nochmal ausführen im ersten Schritte.

Was die zweite Fehlermeldung angeht, würde ich prüfen ob es für den hostnamen mit dem sich qmail meldet (im Normalfall ist das der, der in der /var/qmail/control/me drin steht) auch einen Reverse Eintrag von der IP des Servers gibt.

Versuch nochmal den curl Aufruf und gerne auch den Aufruf von extern und beobachte dabei die logs

/usr/local/pd-admin2/logs/access_log

/usr/local/pd-admin2/logs/error_log

Was mir noch eingefallen ist im Bezug auf das Forbidden dass da beim Curl Aufruf zurück kam:
Dieses Verhalten kriegt man glaub ich auch hin, wenn man eine falsche IP Adresse bei der Installation angegeben hat. Weil dann werden alle vhost Container mit eben dieser falschen IP ausgespielt und dann bleibt nichts anderes mehr übrig als ein "Forbidden" beim Aufruf.

Kontrollier daher mal in der /opt/pdadmin/etc/pdadmin.conf die Haupt IP Adresse ob das eh Deine korrekte öffentliche IP Deines Servers ist.

Hast schon geschaut ob http Prozesse laufen?

Zitat

Da ist der Server schon nicht erreichbar.

Wie ich vermutete.

Mein Tipp wäre eher lokale Firewall. Viele Distris haben per Default ein Set an Regeln laufen. Im Falle von Centos könntest mal ein "systemctl stop firewalld" probieren, bei anderen Distris weiß ich grad auswendig nicht.

Ich denke es wär mal wichtig zu klären, ob der Aufruf von dein-server/administrator ohne https funktioniert. Das hab zumindest ich bisher hier nicht rausgelesen. Tut er das nicht, dann probier als nächstes mit der IP deines servers (und ebenfalls nur mit http). Also http://ip-adresse-des-servers/administrator

Damit kann man mal eingrenzen ob es vielleicht einen Fehler seitens DNS oder lokalen Firewall Regeln gibt. Das würde irgendwie ins Fehlerbild passen. Wenn Dein Server nicht auf Deinen vorgesehenen Namen hört, dann schlägt auch die letsencrypt Verifizierung fehl, das heißt Du bekommst kein Zerti und das würde Deine jeztzige Situation erklären.

Vielleicht hilft es mal wem, ich habe das jetzt mal genau so wie oben skizziert durchgezogen. Zusätzlich habe ich auf Anraten von Herrn Bradler diese beiden Scripts ausgeführt, die die Dateien /var/qmail/users/assign und /var/qmail/control/virtualdomains aus den vorhandenen Daten neu generieren.

http://download.pd-admin.de/assign.pl
http://download.pd-admin.de/virtualdomains.pl

Es scheint soweit alles erwartungsgemäß zu funktionieren, ist nun bereits einen Tag lang so umgestellt und es sind keinerlei Nebenwirkungen aufgefallen.

Daniel Bradler

Vielleicht könnte man das in den künftigen Auslieferungsstand übernehmen.

Ich dank Dir für den Tipp, das scheint tatsächlich zu helfen.

Habe grad meinen Filezilla upgedatet (3.56.0) und konnte mich dann nicht mehr via TLS auf auch nur irgendeinen FTP Account meiner pd-admin Server verbinden. Ging vor dem Update problemlos. Klassisches, unverschlüsseltes FTP ging ebenfalls weiterhin.

Status:    Verbindung hergestellt, warte auf Willkommensnachricht...
Status:    Initialisiere TLS...
Fehler:    TLS-Warnung vom Server erhalten: Error in protocol version (70)

Habe dann unter "Bearbeiten" -> "Einstellungen" bei "TLS Options" die Minimum erlaubte TLS Version auf 1.0 runter gestellt. Hier war nach dem Update 1.2 eingestellt. Damit gehts nun wieder.

die Frage ist, wie kann man das serverseitig lösen, also den proftpd dazu bewegen dass er TLS 1.2 unterstützt?

Die Fehlermeldung

Failed to parse signal string top.

krieg ich übrigens auch, mit jedem Dienst, wenn ich systemctl so aufrufe wie Du. Lass bei Deinem Aufruf

Zitat von altomom

[root@spartacus pd-admin2]# systemctl -stop daemontools

das Minus beim stop weg.

Das /proc Verzeichnis ist kein echtes Verzeichnis mit echten Dateien, es ist vereinfacht gesagt ein Pseudofilesystem vom Kernel. Wenn Du da irgendeinen Prozess zum Speicherplatz messen rein schickst, werden immer utopische Werte rauskommen. Das ist aber keine echte Plattenbelegung.

Wenn Du den Verdacht hast dass irgendwas Deine Platte voll räumt, konzentrier dich eher auf die Ausgabe von df bzw. kreise es weiter mit zb. "du -sh / " ein.

Inzwischen lösen sich die IPs wieder reverse auf und auch Port 25 flutscht wieder. Ist mir ein Rätsel. Zur Sicherheit noch erwähnt, es waren nie klassisches Namensauflösungsprobleme auf dem Host selbst. Es war wirklich nur der Umstand, dass sich die IP der Maschine nicht reverse aufgelöst hat.

Mein Provider hat gerade Troubles mit seinen PTR Einträgen. Also die Server die ich dort habe, lösen sich reverse im Moment nicht auf. Ein "dig -x IP-Adresse-des-Servers" bringt eine leere Antwort mit SERVFAIL.

Das soll aber nicht das konkrete Thema dieses Postings sein, das wird der Provider hoffentlich bald in Griff kriegen. Eher interessant finde ich, was das für Folgen für EINGEHENDE smtp Verbindungen hat, womit ich eigentlich nicht gerechnet hätte.

Draufgekommen bin ich über Clients, die in Ihrem Mailprogramm Port 25 zum Senden benutzen. Hier kommt es nun zu einer Zeitüberschreitung. Und tatsächlich, wenn ich zb. mit Telnet eine Verbindung auf Port 25 aufbaue, dauert es geschlagene 40 Sekunden bis der SMTP Banner kommt.

Das Problem besteht NICHT bei den Ports 587 oder 465. Hier flutscht alles sofort.

Was genau wird hier bei Verbindungen auf Port 25 abgearbeitet, dass zu so einem Verhalten führen könnte und bei den anderen Ports nicht? Hat das etwas mit dem greylisting Script zu tun?

Seit einiger Zeit überprüft die Installationsroutine ob es an den üblichen verdächtigen Plätzen eine my.cnf gibt die von der Distri ausgeliefert wurde, um zu vermeiden dass der Mysql Dienst diese auswertet anstatt der eigentlich vorgesehenen innerhalb von /usr/local/pd-admin2/etc/

Du kannst es Dir in diesem Fall einfach machen aus meiner Sicht, benenne das /etc/mysql Verzeichnis einfach um.

mv /etc/mysql /etc/mysql.orig

Dann sollte es gehen.

Dieser Tipp natürlich unter der Vorraussetzung dass auf diesem System nicht bereits bewusst ein Mysql Server läuft, der irgendeinen Zweck erfüllt. Davon gehe ich aber nicht aus und wenn es so wäre, dann wärs mit der pd-admin Installation ohnehin schwierig.