Handling of duplicates in clients.conf

[Garber, Neal]

> use dynamic-clients - this calls an SQL query which, if the target is
now
> in your DB will update the client list on the fly. no server 
> restarts needed. radmin lists and shows the client etc
> 

Sounds nice - I'll check it out.  Thanks for the tip Alan..

> I seem to recall the error message being one of the last things
printed
> out before the server barfed

Well, assuming by "barf" you mean not start, in 2.0.3 and 2.0.5, the
server doesn't barf and the error message only appears when debug is on
(-Xx).  Within the debug, it's closer to the beginning of my output
(line 188 of 542 messages).  Here's a very abbreviated example:

Info: ...
.
Debug: including...
.
Debug: main...
.
Debug: log...
.
Debug: security...
.
Debug: client...
.
Error: Failed to add duplicate client...
Error: /usr/local/etc/raddb/clients.conf[115]: Failed to add client...
Debug: proxy...
.
Debug: realm...
.
Debug: Module: ...  
. (lots of msgs here)
.
Debug: listen...
Debug: Listening on authentication address * port 1645
Debug: Listening on accounting address * port 1646
Debug: Listening on authentication address * port 1812
Debug: Listening on accounting address * port 1813
Debug: Listening on proxy address * port 1647
Debug: Ready to process requests.

It is also logged to radius.log, but I doubt many people check that file
every time the server is started to see if there was a configuration
error.  What I'm suggesting is to handle it the same as errors in
certain places of radiusd.conf.  For instance, an error in the listen
section causes:

Debug: radiusd: #### Opening IP addresses and Ports ####
Debug: listen {
Debug:       type = "authxxxxxx"
Error: /usr/local/etc/raddb/radiusd.conf[27]: Invalid type "authxxxxxx"
in listen section.

After which the server exits.  If the server exited after the
clients.conf error, then it would be consistent and would force the
admin to fix it (which I think we agree is the right thing to do - that
is, get the admin to fix the conflict..)

For now, I will change the clients.conf file so the client I use to
monitor the server is at the bottom.  This way, if this ever happens
again, my monitoring script will detect the failure.