Re: FQDN via DHCP, then used in exim4
On 5/16/2013 2:17 PM, Klaus Doering wrote:
> Stan, Thank you for the teaching. Indeed, there are many books I should
> have read already, alas, there are a great many subjects about which
> important books are written. So, I go along and learn when things don't
> work as expected. Like now.
>
> The story about using DHCP to assign fixed addresses doesn't seem to be
> as clear cut as might appear from your tone, either:
>
> http://serverfault.com/questions/199104/dhcp-addressing-vs-static-addressing-for-servers
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.
--
Stan
Reply to: