Re: FQDN via DHCP, then used in exim4
On 5/19/2013 3:45 AM, Klaus Doering wrote:
> Stan,
>
> Thank you for taking the time to explain your perspective. Maybe it is
> the tone of your teachings that tickle me, maybe it's just that I'm no
> big fan of sweeping statements a la "Don't do it, ever". As I described
Many folks with long experience make forceful sweeping statements to
prevent others from wasting time and to avoid frustration.
> in my initial post, this thread concerns a small domestic setting.
Yes, I got that.
...
> I agree that in a different setting, where there are many users,
> hundreds of emails per minute and other mission-critical stuff is going
> on, one needs to design the infrastructure a lot more carefully.
And this is the crux of it. As I said, people who write MTAs and other
server applications, as well as OS maintainers, assume that static
addresses are assigned in the traditional UNIX way. They simply don't
consider that anyone would ever use DHCP to assign an address or
hostname, or an MX record, to an internet facing server.
> So, the initial question remains unanswered: what happens to the
> information provided by the dhcp server as reported in the lease file in
> /var/lib/dhcp, how is it accessed, and is there a way to make exim4 use
> it?
If there is a way I have no clue how to accomplish it. If you figure it
out you may want to write a detailed paper and publish it for others who
may want to follow in your footsteps.
Best of luck.
--
Stan
> Klaus
>
> On 17/05/13 19:06, Stan Hoeppner wrote:
>> It's actually very clear. Has been forever. The problem is that the
>> experts who know why -not- to use DHCP here aren't writing about it.
>> It's common sense, rule of thumb, etc. Everyone knows it. Everyone
>> except the few folks such as yourself who ask "why not", then writing
>> something up showing how it 'might' work. Simply put, you're reading
>> things written by folks who don't know what they're doing, who don't
>> have long experience. Some food for thought:
>>
>> 1. When your DHCP server goes down or is unreachable this can wreak
>> havoc. When IPs and hostnames are configured in local UNIX files this
>> is never a problem. So you must create a failover DHCP server. Getting
>> this to work seamlessly is notoriously difficult. It's one thing in an
>> ISP setting when DHCP failover has a lengthy delay. It's quite another
>> when you can't receive email for you 10,000 person organization for many
>> minutes while the DHCP servers sink up and the MX MTA can't get its IP
>> and hostname again.
>>
>> 2. When you swap a defective server NIC udev rules can keep a local
>> static IP consistent on eth0, or require little reconfiguration after
>> the NIC swap. Using your DHCP scenario you must write down the MAC
>> address from the sticker on the card before inserting it, update the
>> record in the DHCP server with the new MAC, then power up the box. The
>> ethernet industry has been working for many years to -eliminate- the
>> need for direct anipulation of MAC addresses. In your scenario you're
>> relying on it. Etc, etc, etc.
>>
>> While it may be possible, in most environments it is simply impractical,
>> and creates far more problems than it solves. If this was a great idea,
>> Rackspace et al would be doing it. And none of them are.
>>
>
>
>
Reply to: