Posts by biologist

In Postfix können Recipients-Restrictions konfiguriert werden. Das sind Checks, die der Reihe nach durchgeführt werden. Da ist jetzt die Frage, an welcher Stelle deine o.g. Checks stehen, die zum Ablehnen der Mail führen. Ich hab das auf meinem System so eingerichtet (vielleicht ist das auch Default bei imscp, weiß ich nicht, nutze meine eigenen Configs), dass DNSBL-Checks nur dann durchgeführt werden, wenn sich User nicht authentifiziert haben. An deiner Stelle würde ich mit dem lokalen Exchange-Server direkt (ohne Relay) Mails auf dem IMSCP-Server einliefern und dabei smtp-auth verwenden - dann kommt es zu DNSBL-Checks, wenn es entsprechend konfiguriert ist, erst gar nicht.

Mails von einer dyndns-Domain über einen komplett fremden Host zu relayen (wer kam eigentlich auf die Idee das Ding Smarthost zu nennen!?), der mit der Domain gar nichts zu tun hat, halte ich persönlich für Geraffel Technisch ist das ok, aber durch die ganzen Spam-Checks, die es inzwischen so gibt, ist das eine heikle Angelegenheit. Wenn, dann würde ich die Domain auf dem IMSCP-Server verwalten und dynamisch Subdomains (also eigenes dyndns) anlegen. Da muss man nur drauf achten, dass die TTL der entsprechenden Zone auch kurz genug ist, weils sonst durch das Zone-Caching nicht wirklich dynamisch ist

Quote from pinky

Nameserver:
Ich gehe davon aus, dass imscp als Nameserver eingesetzt ist. In der Installationsroutine habe ich die entsprechende Einstellung auf dem Standard belassen, sodass der server entsprechend konfiguriert sein "müsste". Gibt es eine möglichkeit dies zu überprüfen? Immerhin habe ich die Datenbank nach der Installation komplett mit der des alten Servers überschrieben.

Natürlich kann man das überprüfen. Prinzipiell durch Reinschauen in die Zonefiles und dann musst du halt schauen, welche Nameserver für die entsprechenden Domains konfiguriert sind. Mit dig kann man dann den eigenen Server testen und auch den Backup-Server - dann sieht man ja, was ausgeliefert wird. Dabei muss man natürlich auch noch DNS-Caching im Hinterkopf haben: nur weil was konfiguriert ist, muss das noch lange nicht überall aktiv sein. Denn ist der Gültigkeitszeitraum hoch eingestellt, was prinzipiell erstmal für erhöhte Sicherheit sorgt, kann es auch mal Tage dauern, bis das weltweit übernommen wurde.

Ganz ehrlich: letztlich ist es deine Sache, aber einen Authoritative Nameserver zu betreiben, wenn man sich mit dem Serverdienst nicht auskennt, ist ein ziemlich heißes Eisen...

Nachtrag:
Kurz nach meiner Mail, habe ich Hetzner mal angeschrieben und nochmal auf das schlechte Routing hingewiesen. Man schrieb mir zurück, dass man an einer Lösung des Problems arbeite (Reaktionszeit auf die Mail: 20 Minuten!). Tatsächlich fiel mir gestern auf, dass der Traffic nicht mehr über Level3 sondern ntt ging - sowohl bei ipv4 als auch ipv6. Damit waren meine Pingzeiten gestern Abend um 10 auch wieder bei 25ms und ich hatte vollen Durchsatz.

Mal hoffen, dass es so bleibt...

Irgendwie kommen hier täglich Posts wegen dem besagten dnsbl. Ich muss das jetzt einfach mal fragen:

- Haut ihr sowas grundsätzlich gleich in Foren rein oder konsultiert ihr mit sowas auch mal die Suchmaschine eures Vertrauens?
- Lest ihr eigentlich keine IT-Nachrichten, wo man sowas automatisch mitbekommt?

Gibt man "rhsbl.ahbl.org" bei Google ein, ist direkt der vierte Hit der hier:
http://www.heise.de/ix/meldung…-Betrieb-ein-2513094.html

*Kopfschüttel*

Naja, das ist ja überschaubar. Migrier es von Hand und gut Dann hast du auch Ruhe und schleppst kein altes Zeug rum.

Jein. Ich hatte vor vielen Jahren mal Confixx, bis ich dann auf ispcp (Vorgänger von imscp) umgestellt habe. Damals war meine Userbase noch überschaubar (vielleicht 20 Domains). Bin mir jetzt gar nicht mehr sicher, ob die Passwörter verschlüsselt waren - weil das ist ja zur Migration ja "unpraktisch" :-). Wie auch immer: es waren nicht so viele User und ich hab denen dann halt geschrieben, was du tun ist. Kurzum: das war keine automatisierte Migration, sondern eine händische Datenübernahme.
Jahre später kam ein Reseller dazu, der auch Confixx eingesetzt hatte. Der hat einige User "mitgebracht", die halt nicht so Technik-affin waren. Dementsprechend musste er das vor Ort bei denen immer einrichten. Damals lief der Auth von Dovecot zur Datenbank jedoch nicht direkt, sondern über ein Perl-Helper-Script. Das habe ich dann etwas erweitert, so dass bei Anfragen mit webXpY ein zusätzlicher Datenbank-Lookup gemacht wurde: ich hatte da eine extra Mapping-Tabelle, bei der Confixx-User auf das neue Username-Format (Mailadresse) gemappt wurden; transparent für den Benutzer. Nach und nach wurden die User dann vor Ort nativ umgestellt, so dass das Mapping irgendwann überflüssig war.

Kurzum: ein direkter Migrationspfad ist mir nicht bekannt - die Umstellung erfordert Handarbeit. Ist halt die Frage, wieviele User du so hast.

Wie sieht das denn bei Confixx mit den Usernamen der Mailkonten aus? Früher war das sowas wie webXpY - ist das immer noch so? Weil wenn das der Fall ist, dann musst du allen Usern eben auch begreiflich machen, dass ihre Usernamen jetzt halt Mailadressen sind. Ich hab das damals für eine gewisse Übergangszeit mit nem Script gemacht, das von Dovecot aufgerufen wurde. Das hat dann quasi extra Lookups gemacht, wobei das aber vermutlich elaganter mit ner Stored Procedure im MySQL gegangen wäre.

Da irrst du dich. Er sagte, dass sich Leute mit Rechtschreibschwächen bemühen sollen. Für sowas gibt es übrigens auch Plugins im Browser.

BTW: Der Typ heißt Häuptling, sonst macht das Wort ja gar keinen Sinn.

Dann vergleiche die Files doch am besten mal.
Du solltest dein System übrigens mal mit fail2ban absichern - dein Server steht unter Dauerbeschuss aus China, wie man in deiner auth.log sehen kann. SSH-Dienst auf nen anderen Port zu legen ist auch keine schlechte Idee - Anpassen der Firewall dabei nicht vergessen...

Quote from LeoM

b: habe ich etwas anderes behauptet?
c; da habe ich wohl den Satz falsch aufgebaut. Gemeint war: "Das ist mir klar. (was goover meinte) Dass nach einem reboot nichts mehr läuft (seit dem Update) ist nicht etwas, was auf ein einwandfreies System deutet"
d: Ist das relevant bei der Problemlösung?

Tut mir leid, dass Du es hierbei nicht mit einem Linux-Guru zu tun hast. Taktgefühl ist eine schöne Sache.

gOOvER: All diese Probleme fingen nach dem Update an. Also muss es wohl zwangsweise irgendwas damit zu tun haben. Davor hatte ich weder das Problem nach dem reboot, noch die Meldung beim apache restart

b: Ja, du hast gesagt, du hast es in Putty reingehauen. Egal, das ist sicherlich der unwichtigste Punkt
c: Schon besser
d: Ja, denn ich frage mich, was für ein Linux-FS du verwendest, das sich fragmentiert. btrfs? Oder gehts um den VM-Host?

Was ich nicht verstehe: hier schlagen immer wieder User auf, die setzen imscp ein und sind scheinbar komplett aufgeschmissen, wenn das Ding nicht 100% saubere Configs produziert. Wie kann man denn ruhigen Gewissens einen Server (respektive vServer) im öffentlichen IP-Adressbereich laufen lassen, wenn man Probleme nicht selbst beheben kann? Es mag ja sein, dass es hier einen Bug in imscp gibt - aber du musst doch selbst in der Lage sein zu sehen, wo genau der Fehler liegt!? Und vor so einem Update macht man generell auch mindestens mal von /etc ein Backup.
Aber immerhin hast du noch Logs gepostet (übrigens kann man da sehen, was du alles so hostest) - hier gibts ja auch User, die wissen nicht mal, wo die Serverlogs liegen...