a small comment on isc dhcp

[Luc T.]

Is it a good idea to give an option to ignore duplicate hostname? If set, only one (first one, second one or any one) is used and others ignored. Then the admins can choose which way to go, in case some of them think keep runing is more important than stucking there, such as me.
   
  Of course, error or warning messages can go to the log file once a certain period of time for reminding purpose.
   
  Will this bring much complexity? Thanks!
  
"David W. Hankins" <David_Hankins at isc.org> wrote:
  On Wed, Feb 28, 2007 at 09:28:36AM -0800, mark wrote:
> Also, is this desire for configuration error tolerance confined to
> dhcpd, or do you want all software to do this? sshd? apache?
> bind? A unix 'mount' that tolerates duplicate mount points
> in fstab and just picks one?

Is it better for software to fail (and thus be visible) or to
try and tolerate the situation (and thus hide an error)?

I've heard operators tell me that they hate software that only
manages to "hide" failure situations by pressing on long after
they'd encountered "bad config".

But still, of course, Luc is not alone.


For example, ISC DHCP's 'authoritative' mess. There are those
that would applaud the attempt not to spit garbage out onto
any random interface someone 'accidentally' started dhcpd
on. But if you've ever had a non-authoritative dhcpd
on one of your networks, you might be of the opinion that it
would actually be better if it did DHCPNAK other clients.

By failing to NAK, it effectively hides itself...it still
addresses some of your clients (which is bad), it just
becomes less visible.


Was that really a benefit, and if so was it worth it? I'd
have to say "no." It's trying too hard to be nice.


Beware of men with good intentions.

-- 
ISC Training! http://www.isc.org/training/ training at isc.org
Washington DC area, April 16-20 2007. DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins




             
  Luc