FreeRADIUS 2.0.0-pre2 has been released

[Alan DeKok]

Jakob Hirsch wrote:
> Quoting Alan DeKok:
>>   Hmm... hadn't thought of doing it that way.  It could be possible.
> 
> Meaning "try it and get back to list when you have the results"? :)

  No, as in it's not currently enabled.

> Allow me to elaborate on that:
> 
> a global listen section:
...
> two virtual servers:
> 
> server foo {
>   client 10.1.0.1 {
>     secret = secret1

  The way it's set up right now, the easiest way to do that is to list
the clients globally, not inside of a server.

> So 10.1.0.1 and 10.2.0.1 will both send their requests to the server's
> address 10.0.0.1, and freeradius will determine by itself (with little
> performance penalty) the proper virtual server for the requests?

  That can be done with little amounts of work.  It's probably a good
idea, too.

  See updates in CVS in a few days.  raddb/sites-available/README.

> But what happens with requests that could be processed by more than one
> virtual server? Like, in the example above, if they had both the same
> client definition (same ip-address, same secret). Random, sequentially
> selected (e.g. first match wins), config error, doomsday?

  Right now, you configuration won't work.  The "listen" section is
global, and therefore looks for global clients.  The clients are buried
inside of a "server" section, so there are *no* known clients.

  The solution is to put the clients globally, and add a "server=foo"
entry in each of them.  That way the "listen" section can find the
clients, and the clients point to the virtual server.

  Alan DeKok.