Run 2 FreeRadius simultanously
Hello! My machine is running FreeRADIUS Version 1.1.3, for host i686-redhat-linux-gnu under Fedora Core 6 and my question is... Can my machine run 2 FreeRadius at the same time? Each FreeRadius in a diferent IP but simultanously in the same CPU and O.S.? Somebody tell me thats possible if each radius is reading from a diferent PATH... Thanks for any documentacion, link or kind of help. Jaume, trying to start eduRoam in Peru!
Jaume wrote:
Can my machine run 2 FreeRadius at the same time? Each FreeRadius in a diferent IP but simultanously in the same CPU and O.S.? Somebody tell me thats possible if each radius is reading from a diferent PATH...
As Josh said, yes. But why? The server can be configured to listen on multiple IP's and ports. The only reason to run two servers is if they're administered by completely different people. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Jaume wrote:
Can my machine run 2 FreeRadius at the same time? Each FreeRadius in a diferent IP but simultanously in the same CPU and O.S.? Somebody tell me thats possible if each radius is reading from a diferent PATH...
As Josh said, yes.
But why? The server can be configured to listen on multiple IP's and ports. The only reason to run two servers is if they're administered by completely different people.
We run multiple instances, with each service on a secondary IP and its own server process; this helps with fault isolation, as well as allowing development of an appropriate config for new services without disrupting existing ones (doubly important now that HUP doesn't work). re: Fault isolation - FreeRadius is a pretty reliable bit of software, but it's not bug-free. We have an infrequent hang-up of our wireless WPA instance (and yes, as soon as I have enough info I will report the bug). Blowing away our entire network (wired ports, vpn, dialup, eduroam) because that has hung up is not attractive, and multiple processes helps there. Running redundant servers doesn't help much in this case for 2 reasons: first, we've found that Cisco APs are very, very poor at detecting dead radius servers and moving to the backup; second, it seems to be malformed data coming from a certain client so if the APs do failover, the 2nd server hangs up in short order. Additionally there are certain configurations that are easy to do individually, but very difficult to combine; though the config unlang in 2.0 should resolve most of the cases I have in mind, and they can be resolved in 1.1 with careful use of Autz/Acct-Type and early use of a module that can add request items (hints, huntgroups, rlm_passwd).
Phil Mayers wrote:
Running redundant servers doesn't help much in this case for 2 reasons: first, we've found that Cisco APs are very, very poor at detecting dead radius servers and moving to the backup; second, it seems to be malformed data coming from a certain client so if the APs do failover, the 2nd server hangs up in short order.
That's not nice...
Additionally there are certain configurations that are easy to do individually, but very difficult to combine; though the config unlang in 2.0 should resolve most of the cases I have in mind
Another thing for 2.0.0 (maybe) is to have per-socket configuration. i.e. socket X can have authorization section X, and socket Y can have authorization section Y. It may not be too hard to add, in fact. And it would be extremely useful. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Another thing for 2.0.0 (maybe) is to have per-socket configuration. i.e. socket X can have authorization section X, and socket Y can have authorization section Y.
It may not be too hard to add, in fact.
Yup. 300 lines of code. The "listener" sections already had an undocumented "identity" entry. It's now used: listen { ipaddr = ... type = ... identity = foo } ... identity foo { authorize { ... } authenticate { ... } } if the "identity foo" section exists, then the authorize / authenticate / etc. sections in it are used, in preference to the ones not wrapped in "identity". This means that each port that the server is listening on can have completely independent authorize / etc. rules. The "listen" sections currently support per-socket clients via a hack. Those will be moved into the "identity" section, too. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan Dekok wrote:
Alan Dekok wrote:
Another thing for 2.0.0 (maybe) is to have per-socket configuration. i.e. socket X can have authorization section X, and socket Y can have authorization section Y.
It may not be too hard to add, in fact.
Yup. 300 lines of code.
The "listener" sections already had an undocumented "identity" entry. It's now used:
listen { ipaddr = ... type = ... identity = foo } ...
identity foo { authorize {
Awesome.
I have Freeradius installed on two opensuse 10.2 servers Running Freeradius 1.16 I am running radrelay on the two too keep the detail files in sync (New Setup) The combined detail work file is created on the two servers and each appear to write to it ok. But they aren't syncing with one another heres my radrelay start commands --- Primary radrelay -a /var/log/radius/radacct/ -d /etc/raddb -n Secondary-Radius detail-combined --- Secondary radrelay -a /var/log/radius/radacct/ -d /etc/raddb -n Primary-Radius detail-combined --- In the clients.conf on each server is an entry with secret pointing to the server in question.
participants (4)
-
Alan Dekok -
Jaume -
Jeff -
Phil Mayers