[postfix-users] [OT?] Postfix ignoriert /etc/hosts
Moin,
mein Postfix (2.3.4) läuft in einem Chroot.
Für Vacation wollte ich eine "virtuelle" Domäne intern.example.com einführen, die auch nur von meinem Server erreichbar sein soll.
Also dachte ich es sollte ausreichen in der /etc/hosts und (wegen des Chroots) in /var/spool/postfix/etc/hosts den Eintrag
127.0.0.1 localhost
anzupassen in
127.0.0.1 localhost intern.example.com
Nachdem ich das gemacht habe kann aber weder Postfix den Hostnamen auflösen (auch nicht nach einem Restart!) noch funktioniert das mit dem host Befehl.
Was habe ich vergessen?
Schönen Sonntag
Thomas
* Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
mein Postfix (2.3.4) läuft in einem Chroot.
Für Vacation wollte ich eine "virtuelle" Domäne intern.example.com einführen, die auch nur von meinem Server erreichbar sein soll.
Also dachte ich es sollte ausreichen in der /etc/hosts und (wegen des Chroots) in /var/spool/postfix/etc/hosts den Eintrag
127.0.0.1 localhost
anzupassen in
127.0.0.1 localhost intern.example.com
Nachdem ich das gemacht habe kann aber weder Postfix den Hostnamen auflösen (auch nicht nach einem Restart!) noch funktioniert das mit dem host Befehl.
Was habe ich vergessen?
Wahrscheinlich intern.example.com irgendwie als gültiges Ziel zu markieren, sei es via mydestination oder sonstwie ;-)
Ansonsten: smtp_host_lookup = native,dns sollte helfen.
Ciao Stefan
Stefan Förster schrieb:
Wahrscheinlich intern.example.com irgendwie als gültiges Ziel zu markieren, sei es via mydestination oder sonstwie ;-)
Ansonsten: smtp_host_lookup = native,dns sollte helfen.
Werd ich checken, was mich aber wundert ist, dass nichtmal der host-Befehl den Namen auflösen kann. Der sollte doch auch funktionieren.
Thomas
* Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
Stefan Förster schrieb:
Wahrscheinlich intern.example.com irgendwie als gültiges Ziel zu markieren, sei es via mydestination oder sonstwie ;-)
Ansonsten: smtp_host_lookup = native,dns sollte helfen.
Werd ich checken, was mich aber wundert ist, dass nichtmal der host-Befehl den Namen auflösen kann. Der sollte doch auch funktionieren.
Wenn Du das im chroot in die Hosts einträgst....? Ansonsten kann man unter Zuhilfename von Dingen wie lwres, nscd, nsswitch.conf und host.conf jedes mir bekannte Unix so verdrahten, daß es intern.example.com auch nicht wird auflösen können, wenn man das in die /etc/hosts einträgt.
Ciao Stefan
P.S: Falls Dein Setup nicht das Einliefern einer Nachricht an einen smtpd beinhaltet, bei dem reject_unknown_recipient_domain angegeben ist, dann hat Dein Problem - welches auch immer das sein mag - wie schon erwähnt nichts mit der Namensauflösung zu tun.
Stefan Förster schrieb:
- Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
Stefan Förster schrieb:
Wahrscheinlich intern.example.com irgendwie als gültiges Ziel zu markieren, sei es via mydestination oder sonstwie ;-)
Ansonsten: smtp_host_lookup = native,dns sollte helfen.
Werd ich checken, was mich aber wundert ist, dass nichtmal der host-Befehl den Namen auflösen kann. Der sollte doch auch funktionieren.
Wenn Du das im chroot in die Hosts einträgst....?
Zitat aus meiner ersten Mail:
Also dachte ich es sollte ausreichen in der /etc/hosts und (wegen des Chroots) in /var/spool/postfix/etc/hosts den Eintrag
127.0.0.1 localhost
anzupassen in
127.0.0.1 localhost intern.example.com
Wenn dann richtig ;) Also müsste es wenn auch mit dem host-Befehl auf der Konsole klappen oder nicht - und wenn das nicht geht, dann liegt's doch wahrscheinlich schon an der Namensauflösung oder?
Ansonsten kann man unter Zuhilfename von Dingen wie lwres, nscd, nsswitch.conf und host.conf jedes mir bekannte Unix so verdrahten, daß es intern.example.com auch nicht wird auflösen können, wenn man das in die /etc/hosts einträgt.
Hm?
Hab's jetzt mal auf was komplett abstruses geändert: "example.intern".
P.S: Falls Dein Setup nicht das Einliefern einer Nachricht an einen smtpd beinhaltet, bei dem reject_unknown_recipient_domain angegeben ist, dann hat Dein Problem - welches auch immer das sein mag - wie schon erwähnt nichts mit der Namensauflösung zu tun.
??? Ich versteh Dich gerade jetzt nicht. Bei mir läuft das so ab: Ich habe ein vacation-Script was ich per master.cf und pipe als "Modul" vacation eingebunden habe. Meine Konfiguration liefert für jeden Benutzer, der Vacation aktiviert hat eine zusätzliche Weiterleitung auf die E-Mail-Adresse "vacation@example.intern". (Zusätzlich zur "Weiterleitung" in's entsprechende Postfach!)
user@example.com user@example.com, vacation@example.intern
Für diese E-Mail-Adresse existiert ein virtueller Transport zum vacation-Script.
vacation@example.intern vacation:
Warum über eine eigene Domain? Weil ich nicht will, dass man von außen das Script anschreiben kann und dafür in meiner Konfiguration auch keine Verrenkungen anstellen wollte. Laut dem Readme aus dem Postfixadmin-Paket für dessen vacation-Script, auf dem meines basiert, sollte es so, wie ich es versuche eingebunden werden.
reject_unknown_recipient_domain gibt es in meinen Restrictions.
Thomas
Thomas Schwenski schrieb:
Wenn dann richtig ;) Also müsste es wenn auch mit dem host-Befehl auf der Konsole klappen oder nicht - und wenn das nicht geht, dann liegt's doch wahrscheinlich schon an der Namensauflösung oder?
Da Host ein Programm zum Test der DNS Auflösung ist, kann es auch sein das Host explizit dns abfragt... Was macht dann z.B. ping?
Guten Abend André,
André Keller schrieb:
Da Host ein Programm zum Test der DNS Auflösung ist, kann es auch sein das Host explizit dns abfragt... Was macht dann z.B. ping?
# ping example.intern ping: unknown host example.intern
Dasselbe also!
Habe ich einen prinzipiellen Denkfehler bei meinem Vorhaben?
Thomas
Thomas Schwenski schrieb:
Guten Abend André,
André Keller schrieb:
Da Host ein Programm zum Test der DNS Auflösung ist, kann es auch sein das Host explizit dns abfragt... Was macht dann z.B. ping?
# ping example.intern ping: unknown host example.intern
Dasselbe also!
Habe ich einen prinzipiellen Denkfehler bei meinem Vorhaben?
Nein müsste eigentlich schon gehen... Wie sieht die /etc/nsswitch.conf aus?
Thomas _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Habe ich einen prinzipiellen Denkfehler bei meinem Vorhaben?
Nein müsste eigentlich schon gehen... Wie sieht die /etc/nsswitch.conf aus?
# cat /etc/nsswitch.conf
passwd: compat group: compat shadow: compat
hosts: files dns networks: files
protocols: db files services: db files ethers: db files rpc: db files
netgroup: nis
hosts: files dns
Sieht eigentlich auch iO aus.
Thomas
* Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
Stefan Förster schrieb: Also müsste es wenn auch mit dem host-Befehl auf der Konsole klappen oder nicht - und wenn das nicht geht, dann liegt's doch wahrscheinlich schon an der Namensauflösung oder?
Daß Du nicht pingen kannst, liegt an der Namensauflösung. Aber bisher hast Du noch nicht gezeigt, daß Postfix ein Problem hat, welches an der Namensauflösung hängen könnte.
"Know your Unix", Du solltest das eigentlich schon alleine hinkriegen, daß Du einen Rechner pingen kannst, den Du in /etc/hosts einträgst.
P.S: Falls Dein Setup nicht das Einliefern einer Nachricht an einen smtpd beinhaltet, bei dem reject_unknown_recipient_domain angegeben ist, dann hat Dein Problem - welches auch immer das sein mag - wie schon erwähnt nichts mit der Namensauflösung zu tun.
???
Du behauptest, Dein Problem hat mit Namensauflösung zu tun, belbst aber jeden Hinweis oder Beweis schuldig. Hör auf zu spekulieren und komm' mit harten Fakten rüber.
Ich versteh Dich gerade jetzt nicht. Bei mir läuft das so ab: Ich habe ein vacation-Script was ich per master.cf und pipe als "Modul" vacation eingebunden habe.
[Standard-Setup ausgelassen]
Ich lege in meinem Test-Setups regelmäßig Domains wie "virtual.lan", "catchall.lan" etc. an - mein Postfix interessiert sich in keinster Weise dafür, ob diese Domains existieren sondern nur dafür, ob ich ihm hinkonfiguriert habe, daß es dafür verantwortlich ist, es sei denn, die Einlieferung erfolgt via einem smtpd, bei dem
reject_unknown_recipient_domain gibt es in meinen Restrictions.
genau dieses gesetzt ist. Das scheint bei Dir jedoch nicht der Fall zu sein. Und jetzt bitte Butter bei die Fische, Felhermeldung aus den Logs zu Deinem Problem.
Ciao Stefan
Stefan Förster schrieb:
Du behauptest, Dein Problem hat mit Namensauflösung zu tun, belbst aber jeden Hinweis oder Beweis schuldig. Hör auf zu spekulieren und komm' mit harten Fakten rüber.
Ich behaupte nicht nur, sondern ich habe es auch belegt. Zugegebenermaßen ich habe keine Fehlermeldungen zitiert, aber in meiner ersten Mail stand alles relevante:
Ich habe den Hostnamen in /etc/hosts UND in /var/spool/postfix/etc/hosts eingetragen gehabt und als es Probleme gab das Ganze mit dem host-Kommando versucht habe aufzulösen.
Hier mal die Meldung die mein Mailor-Daemon gesendet hat (nur damit Du's mir glaubst):
Host or domain name not found. Name service error for name=intern.example.com type=A: Host not found
Und hier das was host meinte:
# host intern.example.com Host intern.example.com not found: 3(NXDOMAIN)
Auf den Hinweis, dass host evtl. direkt in's DNS geht, habe ich es mit ping (erfolglos) versucht.
Nach dem Ändern der Domäne auf example.intern, entsprechender Aktualisierung der hosts-Dateien und Anpassen beider resolv.conf (Eintrag von "domain example.intern") läuft es nun.
Ob es an diesen Änderungen liegt kann ich leider nicht 100%ig sagen. Ich vermute, dass mir mein lokales bind noch zusätzlich dazwischen geschlagen hat - auch wenn ich keine schlüssige Erklärung habe.
Wie ich darauf kam, dass es die Namensauflösung war? Die Fehlermeldung des Postfix und dass, obwohl dieselbe Konfiguration dafür existierte auch Kommandozeilen-Tools nicht auflösen konnten.
Ich lege in meinem Test-Setups regelmäßig Domains wie "virtual.lan", "catchall.lan" etc. an - mein Postfix interessiert sich in keinster Weise dafür, ob diese Domains existieren sondern nur dafür, ob ich ihm hinkonfiguriert habe, daß es dafür verantwortlich ist, es sei denn, die Einlieferung erfolgt via einem smtpd, bei dem
reject_unknown_recipient_domain gibt es in meinen Restrictions.
genau dieses gesetzt ist. Das scheint bei Dir jedoch nicht der Fall zu sein.
Doch, dass ist hier der Fall! (Hast mich ja auch damit zitiert!)
Ich vermute, Du hast aufgrund der Uhrzeit bissel was überlesen - kann ja vorkommen; passiert mir auch.
Thomas
Hallo Thomas,
es freut mich, daß Du für Dich eine Lösung gefunden hast. Laß mich - und wenn es nur für das Archiv ist - noch ein paar lose Enden verknoten :-)
* Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
Stefan Förster schrieb: Hier mal die Meldung die mein Mailor-Daemon gesendet hat (nur damit Du's mir glaubst):
Host or domain name not found. Name service error for name=intern.example.com type=A: Host not found
Ja - das ist aber, auch wenn es da steht, nichts, wofür Du eine funktionierende Namensauflösung für intern.example.com brauchst. Also ich mein, klar ist es das, aber man braucht keinen Eintrag in eine /etc/hosts oder so dafür. Siehe unten.
Ich lege in meinem Test-Setups regelmäßig Domains wie "virtual.lan", "catchall.lan" etc. an - mein Postfix interessiert sich in keinster Weise dafür, ob diese Domains existieren sondern nur dafür, ob ich ihm hinkonfiguriert habe, daß es dafür verantwortlich ist, es sei denn, die Einlieferung erfolgt via einem smtpd, bei dem
reject_unknown_recipient_domain gibt es in meinen Restrictions.
genau dieses gesetzt ist. Das scheint bei Dir jedoch nicht der Fall zu sein.
Doch, dass ist hier der Fall! (Hast mich ja auch damit zitiert!)
Nein, denn Deine Mail an intern.example.com (oder wie die jetzt bei Dir heißt), wird ja nicht direkt von extern an Dein Postfix mit einem "RCPT TO:foo@intern.example.com eingeliefert sondern entsteht aus einer internen Umschreibung - reject_unknown_recipient_domain ist da also herzlich egal.
Das Problem, über welches Du gestolpert bist, ist die Verbindung aus den Eigenheiten der Transport-Tabelle und der Art und Weise, wie Du "intern.example.com" bei Dir im Postfix bekannt gemacht hast:
Du hast in Deine transport(5) etwas in der Form:
foo@intern.example.com vacation:
geschrieben. Wenn Postfix das nun interpretiert, so sieht es, daß es "vacation" als Tranport benutzen soll - aber der "nexthop" ist nicht gesetzt, was dann wiederum bedeutet, daß er nicht geändert wird. Jetzt taucht - nach dem was ich von Deiner Konfiguration weiß - "intern.example.com" nirgendwo als relay domain, mydestination etc. auf - das heißt für Postfix, daß das eine entfernte Adresse ist und es für den Zieltransport "vacation" den Wert von "nexthop" selbständig herausfinden soll - und genau da fällt es dann auf die Nase ohne Eintrag in /etc/hosts, denn egal, wie es die Suche nach Adressen für "intern.example.com" auf angeht, es wird nicht fündig werden. Ergebnis ist die Fehlermeldung, die Du oben zitierst.
Wenn ich mich nicht irre - ich hatte den Fall noch nie genau so - dann Fehler tritt ja eben nur auf, weil Postfix keinen Nexthop finden kann - also hilf ihm und spezifizier den per Hand, z.B. via "[127.0.0.1]". Falls das nicht klappt, muß ich das in einer VM nachbauen, aber ich bin mir eigentlich recht sicher.
Ich vermute, Du hast aufgrund der Uhrzeit bissel was überlesen - kann ja vorkommen; passiert mir auch.
Nein, eigentlich war es ja schon Mittag ;-)
Ciao Stefan
Hallo Stefan
es freut mich, daß Du für Dich eine Lösung gefunden hast. Laß mich - und wenn es nur für das Archiv ist - noch ein paar lose Enden verknoten :-)
Gerne, in Deinen Ausführung stand ja auch Wissenswertes.
Das Problem, über welches Du gestolpert bist, ist die Verbindung aus den Eigenheiten der Transport-Tabelle und der Art und Weise, wie Du "intern.example.com" bei Dir im Postfix bekannt gemacht hast:
Wenn ich mich nicht irre - ich hatte den Fall noch nie genau so - dann Fehler tritt ja eben nur auf, weil Postfix keinen Nexthop finden kann
- also hilf ihm und spezifizier den per Hand, z.B. via "[127.0.0.1]".
Falls das nicht klappt, muß ich das in einer VM nachbauen, aber ich bin mir eigentlich recht sicher.
Du meinst:
foo@intern.example.com vacation:[127.0.0.1]
? ??
Ich vermute, Du hast aufgrund der Uhrzeit bissel was überlesen - kann ja vorkommen; passiert mir auch.
Nein, eigentlich war es ja schon Mittag ;-)
Öhm - ich hatte auf gestern gesetzt, da war der Tag ja schon etwas älter.
Thomas
* Thomas Schwenski mailing-lists@thomasschwenski.de wrote:
Das Problem, über welches Du gestolpert bist, ist die Verbindung aus den Eigenheiten der Transport-Tabelle und der Art und Weise, wie Du "intern.example.com" bei Dir im Postfix bekannt gemacht hast:
Wenn ich mich nicht irre - ich hatte den Fall noch nie genau so - dann Fehler tritt ja eben nur auf, weil Postfix keinen Nexthop finden kann
- also hilf ihm und spezifizier den per Hand, z.B. via "[127.0.0.1]".
Falls das nicht klappt, muß ich das in einer VM nachbauen, aber ich bin mir eigentlich recht sicher.
Du meinst:
foo@intern.example.com vacation:[127.0.0.1]
Ja. Es kommt jetzt noch drauf an, wie der Eintrag für "vacation" in der master.cf definiert ist, sprich, ob dort die Variable "${nexthop}" verwendet wird und wenn ja, was das Skript, welches dann von pipe(8) aufgerufen wird, daraus macht.
Wenn "${nexthop}" nicht verwendet wird, ist das natürlich wayne :-)
Ich vermute, Du hast aufgrund der Uhrzeit bissel was überlesen - kann ja vorkommen; passiert mir auch.
Nein, eigentlich war es ja schon Mittag ;-)
Öhm - ich hatte auf gestern gesetzt, da war der Tag ja schon etwas älter.
Jetzt bin ich mir selber nicht mehr sicher, wann ich das geschrieben hab'... *such* :-)
Auf der anderen Seite: Es läuft ja jetzt bei Dir. Und Du weißt doch, wie das mit den laufenden Systemen so ist.
Ciao Stefan
participants (3)
-
André Keller -
Stefan Förster -
Thomas Schwenski