Beiträge von tbc233

Ich habe mir eine eigene Lösung gebaut für letsencrypt, mittels dehydrated: https://github.com/lukas2511/dehydrated

Das initiale erstellen eines zertis muss ich derzeit noch händisch machen mittels "dehydrated -c -d hostname". AB DANN hab ich ein script das täglich läuft und die vadmin datenbank nach allen ssl hosts anzapft. Findet es eins, schaut es im dehydrated certs Verzeichnis nach, ob es auch wirklich ein selbst erstelltes ist (könnte ja auch irgendein anderes zerti sein, zb eines dass der Kunde selbst gekauft hat). Wenn dem so ist, wird der dehydrated Befehl angeworfen und dieser erneuert das zerti, SOFERN es in weniger als 14 Tagen abläuft. Wenn es erneuert wurde, kopiert das script die zertis mit der nötigen Benennung nach /opt/pdadmin/sslcerts und macht einen apache reload.

Damit fahr ich recht gut auf vielen Servern. Ich hatte das schon fertig, bevor pd-admin begonnen hatte letsencrypt selbst zu implementieren, daher habe ich es auch weiterhin so gelassen.

Generell alle Mails die via nicht-authentifizierter smtp Verbindung zu localhost oder via sendmail Befehl abgesetzt werden, fallen nicht ins Sendelimit. Somit im Prinzip alles was so von Scripts / Weboberflächen generiert wird.

Wurde hier schonmal diskutiert, dass das schade ist. Andererseits versteh ich es, ich wüsste selbst nicht wie man das implementieren könnte.

Bezogen auf ein mailgenerierendes Kunden-Script dass in einem bestimmten Account liegt, ginge es vielleicht noch. Man könnte den sendmail Befehl durch ein wrapper Script ersetzen, dass auf das Sendelimit Rücksicht nimmt.

Aber bei einer serverweit gemeinsam genutzten Sache wie roundcube wirds schwierig.

Sowas ist wirklich Mist, zumal roundcube ja nicht im Kontext des SMTP Accounts des Users versendet. Somit greift das ansonsten recht hilfreiche Sendelimit des Accounts nicht.

Der erste Ansatz der mir einfallen würde:

Man kann bei Roundcube im config File ein logging aufdrehen. Dann wird jede Action in ein File im roundcube Logs Verzeichnis geloggt. Da könnte man dann schauen, ob sich beim Absetzen eines Mails hier etwas tut, das man in eine fail2ban Regel pressen könnte. Wenn hier bei jedem Mailversand, hoffentlich inklusive IP, eine Zeile geloggt wird, könnte man mit fail2ban die Sendelimits (zb. maximal 20 Mails in 15 Minuten) beinahe adäquat nachbauen.

Vielen Dank, das erleichtert mich direkt etwas. Bin aber unsicher was Du meinst mit "in meinem vhost habe ich gesetzt...". Die vhost Definitionen werden ja stets automatisch generiert und rausgeschrieben.

Oder meintest Du global in der httpd.conf-template?

Mist, ich hatte mich echt gefreut dass wir hier auf der richtigen Spur waren. Schade zu hören dass es nun nichts hilft.

Zunächst mal klingt das mit den 14 Tagen *sehr verdächtig* danach dass jemand die betreffende Mailbox als Quarantäne Mailbox des Spamfilters eingestellt hat. Das kam hier schon öfter vor. Die Quarantäne Mailbox die im Spamfilter eingestellt wird, dient als Auffangbecken von Spams, Mails werden hier nach 14 Tagen gelöscht. Daher sollte das eine eigens angelegte Mailbox sein, und keine die von einem User verwendet wird.

Das solltest Du unbedingt prüfen, ob ich hier mit meiner Vermutung richtig liege, weil sonst hast Du den selben Spaß gleich morgen wieder.

Ansonsten brauchst Du nur die ganzen Mails und Verzeichnisse aus der Sicherung in das Mailverzeichnis des Users kopieren (/home/popuser/popboxen/domain/8-stelliger-username/). Das klappt recht gut, ist im Normalfall nicht mal ein Neustart des Dienstes nötig.

Okay, ich hab grad gesehen dass ich meine httpd.conf-template entsprechend erweitert habe, damit auch ipv6 zieht. Das war mir auswendig nicht mehr geläufig dass ich das händisch gemacht habe.

Damit sollte es dann gehen, weil das pd-admin document root dann auch auf die ipv6-Adresse "hört".

Ist sonst echt niemand mit diesem Problem konfrontiert bzw. kann es niemand nachvollziehen? Mir wächst das zunehmend über den Kopf.

Machs mal ein bisschen genauer - "...ist nicht zu erreichen" ist etwas wenig Info.

Kommt zumindest irgendwas im Browser wenn Du auf eine pd-admin Adresse mit ipv6 los gehst? Taucht was im access/errorlog auf während Du das tust?

Ich habe das Problem überall weg gebracht durch setzen der Datei /var/qmail/ignorewronganswer auf den Wert 1.

Für genauere Infos Forumssuche nach "ignorewronganswer" oder zb. SE 0.246 und qmail

Richtig. Wie gesagt, hatte noch nie Probleme und sehe auch regelmäßig in den Logs dass Clients per ipv6 daherkommen.

Wenn es tatsächlich nicht funktionieren sollte nach dem Setzen des Eintrages, würde ich mir mal (natürlich während dieser Zustand andauert) die error_logs ansehen.

Das kann ich nicht bestätigen. Da hatte ich bisher noch nie Probleme.

Eigentlich ist es wie bei ipv4.

qmail meldet sich beim gegnerischen Mailserver beim HELO mit dem Hostnamen der in /var/qmail/control/me drin steht. Das ist der Hostname auf den sich die IP des Servers rückwärts auflösen muss.

Idealerweise, damit es übersichtlich bleibt, ist der systemweite Hostname, der Hostname in /var/qmail/control/me sowie der Name auf den die ipv4 und die ipv6 Adressen rückwärts (und vorwärts) zeigen, stets überall der gleiche. Dann sollte das Problem bald vom Tisch sein.

Ausgangslage Centos7 mit Umgebung 0.331 und aktiviertem Apache 2.4. Habe Fehler heute nachvollzogen auf 3 verschiedenen pd-admin Installationen bei 2 verschiedenen Providern / Rechenzentren.

Es muss ein http Upload provoziert werden, der zwar seitens aller relevanten Limits (cgi Limits, PHP max_upload_sitze, PHP post_max_size, apache Timeout in der httpd.conf) funktionieren müsste, aber dennoch länger als 45 Sekunden (sagen wir sicherheitshalber 60 Sekunden) dauert. Wenn die Internetverbindung des Clients zum Server sehr sehr gut ist, wird man den Fehler vielleicht nie bemerken.

Konkreter Aufbau (zum Teil im Zuge des Testens absurd hohe Werte nachfolgend, ändert aber nichts am stets reproduzierbarem Verhalten):

1) apache Timeout 4500 Sekunden (ggf anpassen in /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template , dann /opt/pdadmin/bin/httpd_vhosts.pl ausführen)

2) cgi CPU Zeit des zugrundeliegenden Angebots auf 600 Sekunden

3) zuständige php.ini: PHP max_upload_sitze auf 1024M, post_max_size ebenso

4) Einen http Upload durchführen, der wie gesagt länger als 60 Sekunden dauert. In meinem Fall hier hat meine Internetanbindung um die 30Mbit Upload, da reicht ein 120MB File um den Fehler zu reproduzieren. Kleinere Files gehen problemlos und produzieren den Fehler nicht.

5) Den Upload zum Beispiel mit wordpress "Mediathek" durchführen falls grad bei der Hand. Falls nicht, kann auch mein PHP Testskript anbei verwendet werden, mit dem kann ich den Fehler genauso jederzeit reproduzieren.

6) Der Upload bricht ab, im Browser erscheint ein Verbindungsfehler. Im error_log erscheint "The timeout specified has expired..... Error reading request entity data".

Umschalten auf Apache 2.2: Alles funktioniert.

Hier ist definitiv was im Busch.

Eben musste ich einen anderen Server, der mit all dem bisherigen nichts zu tun hat, auch auf 2.2. rückstufen. Ein Kunde mit einer eher langsamen Internetverbindung konnte in seinen Wordpress Blog keine 12MB Datei hochladen. War bei ihm mit Teamviewer drauf - wieder in etwa die 45 Sekunden, dann Abbruch mit selber Meldung im error_log.

Auf Apache 2.2 umgestellt und alles funktioniert.

ProxyTimeout wird nicht verwendet. Ich hab das Problem (und dessen Beseitigung durch Rückschritt auf 2.2) auf zwei unterschiedlichen Servern reproduziert. Auch die Zeit nach der abgebrochen wurde, war stets in etwa die selbe, nämlich 45 Sekunden (witzigerweise exakt der in meinem Fall auskommentierte Defaultwert "Timeout 45").

Neue Erkenntnis:
Das Problem besteht nach einem testweisen Umschalten auf Apache 2.2 nicht.

Ich stelle daher mal vorsichtig die Behauptung auf, dass die aktuell enthaltene Apache 2.4 Version die Timeout Anweisung in der httpd.conf ignoriert. Es ist kein generelles 2.4 Problem, da das System auch schon vorher auf dem 2.4er Zweig lief ohne diese Probleme. Es muss mit der aktuellen 2.4 Version 2.4.39 zu tun haben.

Mal testweise auf PHP-FPM umgestellt statt cgiwrap, Fehlermeldung äußerst ähnlich, was mich vermuten lässt das das Timeout an dem es scheitert Apache 2.4 seitig ist.

Mir ist bei einer PHP Applikation, wo relativ große Dateien hochgeladen werden, mit 0.331 aufgefallen dass es hier zu Timeouts kommt, die es vorher definitiv nicht gab. Die relevanten Limits in der php.ini sind in Ordnung und habe ich mittels phpinfo() geprüft.

In der httpd.conf (sowie natürlich httpd24.conf-template) habe ich

Timeout 9500

(also ein defintiiv ausreichender Wert)

Das CPU Limit des zugrundeliegenden Angebots war auch stets sehr hoch, habe ich jetzt mittlerweile sogar testweise auf 5.000 erhöht.

Im Einsatz ist derzeit cgiwrap.

Dennoch, wenn ich einen http Upload mit 100MB mache (was vorher jahrelang kein Problem war), bricht dieser ab. Im error_log erscheint

Welches Limit könnte hier noch zuschlagen?

Ergänzend hat Herr Bradler gerade angemerkt:

Zitat

Der Thread ist leider geschlossen und ich kann nicht antworten. Dovecot wurde bereits in Version 0.330 der Serverumgebung aktualisiert.

Daher alles okay, Sorry für den falschen Alarm meinerseits.