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... )



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to