> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
