Handling of duplicates in clients.conf

[Garber, Neal]

>   If your server is misconfigured, it's better to know and fix it,
than
> have it silently "work" for some definition of "work".
> 

I agree with you Alan that the server shouldn't just silently "work"
with configuration errors.  In the past, I've seen configuration errors
preclude the server from starting.  Is that still the case?  If so, then
given the seriousness of the error, as described in your response below,
perhaps the server should fail to start in this case as well.  That
would make it more obvious there is a configuration error and allow
immediate correction.  The current approach causes the server to start
in a semi-functional state (because requests from clients before the
error are processed and requests from clients after the error are
ignored).

>   No.  Clients that are exact duplicates can be safely ignored.
Clients
> that are "similar" but not the same are conflicts.  You may have
> policies, logging, etc. that depend on the fields that are different.
> Which one is chosen?  One at random?
> 
>   Do you really want the server to work *accidentally*?  And one day,
> when something else changes, the server suddenly picks the *other*
> client definition, and all of your policies, logs, etc. are different?

I agree with you that conflicts are bad.  I wasn't trying to suggest
otherwise.  However, the current approach (even in 2.1.4) displays 2
error messages buried in the middle of hundreds of other startup
messages.  They can easily be missed if you don't examine all of the
startup messages carefully. Even if you see the messages, it isn't clear
that the result of the error is to ignore the remainder of the
clients.conf file.  I didn't notice there was a problem until hours
after a change/restart when some clients reported they weren't able to
connect.  When I heard of the problem, I noticed messages saying
requests were being ignored from unknown clients.