Handling of duplicates in clients.conf

[Garber, Neal]

> ouch - random working process that is happy if the wind blows in the
right
> direction.  no, the code is simply allowing only exact duplicates
> to be ignored as errors...which is quirky but stop s afew issues.
> anyway, another reason to use SQL as the client storage engine - you
> can put column restraints in which make each field enforced as unique
> -IP address, name, shortname etc. thus you'll never get the chance
> of having a duplicate in the first place.... apart from when you first
> start trying SQL clients and still have real entries in clients.conf
;-)

Thanks for taking the time to share your thoughts Alan.  I recently
started investigating SQL for client and huntgroup definitions and I
appreciate your insight.  Does using the SQL approach still require a
server restart to refresh any changes?  Do you know if there are any
plans to refresh the clients via radmin?  (I realize this isn't a
trivial matter..)

I'm not sure I follow why what I suggested would cause the server to act
in a non-deterministic fashion.  Wouldn't it always use the first
definition of a client with a specific IP address and ignore any
subsequent definitions that cause a conflict (because the conflicting
entries wouldn't be loaded in the client tree)?  Regardless, I wasn't
trying to suggest that the error should be ignored by the admin and that
the conflict is not an issue.  Rather, if this isn't treated as a fatal
error that prevents the server from starting (which is how it is
currently treated), then I don't see the value in breaking lots of other
clients that have no conflicts.  Am I missing something here?  I don't
think getting the admin's attention via trouble calls and client outages
is the best way to inform them there's a problem.  My suggestion was to
leave the clients with conflicts potentially broken while not breaking
the rest of the clients. 

What are your thoughts about treating the conflict as a more severe
error and not allowing the server to start?  Does this seem better than
the current approach for people that aren't using SQL?  It just seems
like there must be a better means of notifying the admin of the
configuration issue than breaking the valid clients found after the
conflicting entry.  It's very easy to miss the current error message
among all of the other startup messages.  If the server failed to start
and this error was prominently displayed, I think the configuration
problem would be noticed more quickly.  

Perhaps another option would be to display a warning that configuration
errors were detected after the "Ready to process requests" message.
This would alert the admin that they should scroll back and look for
errors.