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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519671ad.1070...@hardwarefreak.com
