On Thu, 18 Oct 2007, Kees-Jan Dijkzeul wrote:
The problem first occurred when I booted the box without the network
cable plugged in. The network interface got configured with a remembered
ip adress, but obviously, DNS is not available. Hence, the
/etc/network/if-up.d/sendmail script failed (?) to determine my
hostname, and messed up dialup.m4 by inserting a dns-error message
I can see that happening, and the other cause is slow DNS - though
there are a plethora of attempts to hopefully work around that case.
I expected the box to recover when rebooting with the network connected,
but it didn't. Manually calling /etc/network/if-up.d/sendmail as
/etc/network/if-up.d/sendmail 192.168.11.2 '' eth0
seems to solve the issue for me (dialup.m4 gets rewritten correctly, and
isn't messed up again by subsequent ifup/ifdowns
Exactly - you told it what your new address was, and that the domain
(provider) has not changed.
I did not yet investigate why /etc/network/if-up.d/sendmail feels the
need to update my hostname only when dns is absent, but not when it is
present.
Actually, updating has nothing to do with DNS availability !
provider.m4 and dialup.m4 are re-written in the following cases:
*) Network goes down
This event causes /etc/mail/m4/dialup.m4 to updated
*) Network comes up and one or more of the following has changed
+) Network domain/provider (ISP) via PPP or provider tag in
/etc/network/interfaces, or DHCP lease information
This event causes /etc/mail/m4/provider.m4 to be updated
+) The IP has changed
This event causes /etc/mail/m4/dialup.m4 to be updated
Note that both of these can happen at the same time
These changes are handled by one or more of /etc/ppp/ip-*/sendmail,
/etc/network/if-*/sendmail and /etc/dhcp3/dhclient-exit-hooks.d/sendmail
The real logic (or lack thereof) comes in two places:
*) /etc/mail/sendmail.conf
Here, you tell sendmail if you have a static or dynamic IP,
and if dynamic, which interface(s) to monitor for changes.
If you have a static IP, please tell sendmail that, and update
the dialup.m4 by hand to reflect what the values should be - then
sendmail will keep its grubby (not so) little fingers out the
pie.
*) /usr/share/sendmail/dynamic
Here it attempts to 'do the right thing' and not restart sendmail
every
time your DHCP lease is renewed, etc... It will only update
information
it has a good chance of knowing changed.
The above really should be put into README.Debian
So, in your case, after you set the IP, sendmail has no way of knowing
when/if the resolvability of your host changes - and can't change anything.
This whole mess was concocted by me and a few others back when we were
forced to live on PPP/dialup or DHCP dsl/cable - and it worked just fine
for us, but at least I always ran a split horizon/view local DNS on my
mail servers - and thus never really ran into this issue.
I found a bug in the dynamic script that can cause early termination
of the host lookup loop - and explains the ';;....' edit.
I'm going to fix that, but before I put it out, I would like your
opinions on how to handle the remaining issue:
/usr/share/sendmail/dynamic::update_host is called when the IP has
changed, and it calls find_host to do the resolution... just blindly
assuming it has done the job properly.
If find_host works, there is no problem...
If it fails, however, there are some options - none good ;(
*) Keep sendmail from starting in an unknown state, and invent
a means to do the needed DNS lookup during
/etc/init.d/sendmail start
This likely means actually keeping some state around - and
we could even retry later on DHCP RENEWs !
*) Keep sendmail the 'logically offline state' - mail will
not be sent, I will have to investigate if it will accept
mail in this state or not (doing so could be *bad*)
*) Use the prior hostname, which *may* be invalid - potentially
causing bounces, DNSBL additions, etc.
--
Rick Nelson
I stopped a long time ago to try to find anything in the bug list of dpkg.
We should run for an entry in the Guinness Book of Records.
-- Stephane Bortzmeyer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
