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.