Beiträge von tbc233

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.

Ja, das ist eine Unart.

Das ganze wird ohnehin immer schlimmer. Mit jedem neuen Server (bzw. jeder neuen IP) muss man eigentlich mittlerweile fast standardmäßig bei microsoft (hotmail, live etc), T-Online und (wenn man Pech hat) diversen Delisting Seiten vorstellig werden.

Und Du hast recht, Verbindung ohne Kommentar einfach abweisen, geht gar nicht. Hatten wir neulich auch, mit Empfängern die eine Sonicwall Firewall hatten mit Deep Packet Inspection für smtp. Wenn dieser Firewall etwas an dem einliefernden Server nicht gefällt, sagt sie einfach beinhart beim smtp Dialogaufbau "No smtp Service here". Furchtbares Verhalten sowas.

Exakt so hatte ich es nicht, glaube ich. Aber vor drei Tagen fiel anhand eines von hosteurope nicht angenommenen Mails definitiv auf, dass hosteurope seit einiger Zeit nun anscheinend zwingend einen SPF Eintrag beim Absender braucht (noch besser SPF + DKIM).

Die Domain (nicht von uns verwaltet) hatte gar keinen SPF Eintrag. Als wir uns dann darum gekümmert haben dass einer im DNS ist, konnte man problemlos hin mailen.

Wäre mal ein Ansatz zu prüfen.

Möchtest Du nicht kurz erklären was der Fehler war? Vielleicht hilfts mal jemand anderem.

Du hast natürlich recht. Ich für mich kann da damit leben, da die Lizenzpreise von pd-admin relativ günstig sind und ich bisher noch nie Probleme mit großen configs bemerkt hätte.

Wahrscheinlich kommts auch ein bisschen auf die Kunden an die man so hat. Wenn man auf einem Server recht viele Kunden vom Typus "Ich hatte da mal eine Geschäftsidee Sonntag Nachmittag und jetzt registrier ich gleich mal 200 Domains dazu", dann wäre vermutlich in der Tat CoDomain das bessere Werkzeug

Ich habe mir einfach, schon vor 2-3 Jahren als SSL begann zu boomen, konsequent abgewöhnt Co-Comains zu verwenden. Ich lege jede Domain im Account des kunden ganz normal ein und erstelle dann im Endkundenmenü unter "Subdomains" entsprechend Weiterleitungen auf die Hauptdomain. Ist zwar etwas mehr Klickerei beim Anlegen, dafür hatte ich das Thema dann vom Tisch.

Zitat von Sumeragi

Wäre es nicht einfacher ein Mail Relay auf dem vserver aufzusetzen und dann mittels /var/qmail/control/smtproutes Mails darüber auszuleiten?

Das hatte ich auch überlegt, aber aus irgendeinem Grund verworfen.

Letztendlich wär das natürlich auch eine Möglichkeit. Auf der anderen Seite ist halt die Frage ob es nicht generell "sauberer" ist wenn er über die selbe IP raus geht wie rein.

Zitat

Allerdings werden die E-Mails mit der NAT-IP-Adresse des DS-Lite-Anschluss versehen, die von einigen Mailserver blockiert werden.

Ich kann mich irren, aber so wie es klingt gehen die E-Mails schlichtweg über Deinen DS-Lite Anschluss raus. Das wird natürlich vielen gegnerischen Mailservern nicht gefallen.

Das Problem dürfte sein, dass Du zwar eingehend alles gut im Griff hast durch Deine Portweiterleitungen vom vserver, aber AUSGEHEND geht Dein Server nach wie vor über Deinen DS-Lite Anschluss raus, weil ihm vermutlich anhand seiner Default Route nichts anderes übrig bleibt.

Aus meiner Sicht lässt sich das mit der tollsten qmail Konfiguration nicht lösen, du müsstest dafür sorgen dass der vserver zum Default Router Deines pd-admin Servers wird und dieser nur mehr eben über den vserver ins Internet geht.

Mit openvpn hab ich das schon öfter gemacht, da fand ich es relativ einfach. Man pusht den openvpn Server als Gateway an die Clients und braucht halt dann am Server entsprechende Masquerade Rules für AUSGEHENDES Nat. Das wird bei wireguard vermutlich nicht unähnlich sein. Dieses Anleitung erscheint mir vielleicht als ganz inspirierend https://www.cyberciti.biz/faq/…er_the_client%27s_gateway
Hier werden anscheinend zuerst die Regeln für das ausgehende Nat gemacht, dann die wireguard config, "to allow WireGuard clients to access the Internet".

Das ist insofern interessant, als dass ich ja seit 5 Jahren meine Zertis mit dehydrated generiere, und meine key Files haben nur eine Sektion mit "Beginn" und "End".

Ich setze derzeit dehydrated in der Version 0.6.5 ein.

https://www.heise.de/news/Jetz…-Root-Rechte-5037687.html

Nur so als Tipp, das Thema braucht aus meiner Sicht dringende Zuwendung und updates der sudo Pakete. Momentan kann auf den meisten Systemen quasi jeder Hostingaccount zu root werden.

Find ich super. Wie gesagt, ich fahr voll auf dehydrated ab und benutze es schon sehr lange. Ich würde es auch als "gut gepflegt" bezeichnen.

pd-admin ist spitze für mich. Bei anderen Hostingpanels wird mir schon schlecht wenn ich nur die Installationsanleitung lese, mir sind die viel zu aufgeblasen. Zudem ist der Preis sowas von fair, ich bin da sehr dankbar dafür. Außerdem gefällt mir, dass wir mit so einem weniger populären Produkt (wenn ich das mal so sagen darf) eher unterm Radar fliegen, ich möchte nicht wissen wie oft weiter verbreitete Systeme wie Plesk täglich angegriffen werden und wie es bei denen rund geht wenn mal ein Zeroday raus kommt.

Natürlich gibt es manche Kinderkrankheiten, die wir schon sehr lange mitschleppen, aber bei welchem Produkt gibts die nicht.

Zudem sollte man bei konkreten Vorwürfen in Richtung des Herstellers hier in diesem Forum auch immer bedenken dass dies kein offizielles Supportforum ist. Also Herr Bradler ist nicht verpflichtet uns hier Frage und Antwort zu stehen.

Zitat von Revolution

Warum gibt es nach etlichen Jahren noch keine brauchbare Behebung des Fehlers?

Ich habe mir schon länger angewöhnt, vor einem Update der Standardumgebung und/oder pd-admin, den Cron Dienst zu beenden und nachher wieder zu starten. Dadurch wird vermieden, dass irgendeins der Scripte oder Executeables, die gerade im Begriff sind ausgetauscht zu werden, gerade gestartet wird.