FreeRADIUS 2.0.0-pre2 has been released
Jakob Hirsch
jh at plonk.de
Fri Sep 14 17:53:52 CEST 2007
Quoting Alan DeKok:
>> As I understand the virtual servers, it is possible to have all vservers
>> listen to the same ip/port socket, but have different client
>> configurations. Is that right?
> 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"? :)
>> And would that be a sensible thing to do in a high traffic environment
>> (many million requests per day)? I'd think that every request would have
>> to be processed by all the vserser instances only to decide that the
>> request has to be discarded by most of them.
> No. The idea would be do tie a client to a virtual server. Then, all
> requests from that client would be sent to one, and only one virtual server.
That's what I want.
Allow me to elaborate on that:
a global listen section:
listen {
ipaddr = 10.0.0.1
type = auth
}
two virtual servers:
server foo {
client 10.1.0.1 {
secret = secret1
}
autz...
auth...
}
server bar {
client 10.2.0.1 {
secret = secret2
}
autz...
auth...
}
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?
> And no matter what, a request is handled by *one* virtual server. You
> seem to be saying that a request will be handled by many in parallel.
> That will never happen, for the reasons you point out.
Ok, that's what I wanted to read :)
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?
(Hm, it's really time to set up a test installation... )
More information about the Freeradius-Users
mailing list