Re: FQDN via DHCP, then used in exim4
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
in my initial post, this thread concerns a small domestic setting. There
is very little redundancy in such a setup, and the
router+firewall+switch+ap is one of the single point of failures that
potentially bring down most of the installation. And that's quite
independent of whether or not it also acts a a dhcp server to hand out
ip info to -- say -- an email server. My way of dealing with this
inherent weakness is that I have an old router that can be swapped in
and configured to do most of the jobs, until the original one is
repaired or replaced. Good enough for me; your guess is as good as mine
about how many typical domestic installations even have a backup
router...
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.
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?
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: