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