Richard A Nelson wrote:
[...]
>> /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.
This is not entirely accurate. During this entire exercise, my ip address
never changed. I get it from my broadband router that is configured to
always serve this ip-address to the mac-address of my box. The only thing
that ever changes is the ability to do reverse-DNS lookups of my IP
address.
>> 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 !
Hmm...
You are contradicting my observations... This is where things get
interesting.
If I recall correctly (didn't re-test yet), the following happened:
1. Start with a perfectly working configuration.
2. Shut down
- I didn't verify that dialup.m4 gets updated
3. Disconnect ethernet
4. Start up again
- DHCP fails (obviously), so I'm given a remembered address,
which is the same as the one I've always had (192.168.11.2)
- dialup.m4 gets updated, even though my IP is still the same (?).
Because DNS-resolvability has changed, dialup.m4 gets messed up.
5. Shut down again
- I didn't verify that dialup.m4 gets updated
6. Reconnect ethernet
7. Start up yet again
- DHCP succeeds again. I'm still getting the same ip as before.
- For some reason dialup.m4 doesn't get updated.
8. End up with a broken configuration
So, in my opinion, the problem is that dialup.m4 should get updated either
both at step 4 and step 7, or not at all. Current observation is that it
only gets updated at step 4, and not at step 7.
> 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.
As expained above, I don't think this is the cause of my problem, as I am
doing reboots in between.
Still, if you depend on resolvability and don't get notifications when
resolvability changes, you have a design flaw.
> 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:
I'm not really the right person to ask, since I don't think I fully
appreciate what you are trying to do in the first place.
I'm guessing you are trying to make the sendmail configuration robust
against hostname changes, basically allowing sendmail to accept mail for
whatever hostname it happens to find itself at.
I currently don't see the point of implementing such a feature, since I
would never actually be able to hand out such an e-mail address, because
it is liable to change at unexpected times. In any (AFAIK) useful
configuration, the domain name(s) sendmail receives mail at is fixed (such
that you can hand out your e-mail address), and the real challenge is to
make mail addressed to that (fixed) domain reach you.
Back in the PPP/dialup days, I was using UUCP (which also allowed me to go
offline every now and then). Today, I have cable and a dyndns account,
making sure that my hostname points to the correct ip address.
Anyway... Returning on topic. I think we are discussing two different
issues. As far as I can tell, this bug is about the case where
resolvability changes (but ip-address doesn't) at ifup/ifdown time. This
is currently not (always) handled correctly, and I don't think we know the
cause yet.
You are asking me what to do in a case where dynamic domain names are
required and you don't have resolvability. As you observe, there is no
'correct' way to handle this case. I'm not sure, though, that the
requirement still exists (or should have ever existed ;-)
Groetjes,
Kees-Jan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
