Re: Specific User Trace and multiple radiusd instant
Hello everyone, We use below freeradius. It works well. The OS is Linux Enterprise 5.4. Thanks. freeradius2.x86_64 2.1.12-3.el5 installed freeradius2-krb5.x86_64 2.1.12-3.el5 installed freeradius2-ldap.x86_64 2.1.12-3.el5 installed freeradius2-mysql.x86_64 2.1.12-3.el5 installed freeradius2-perl.x86_64 2.1.12-3.el5 installed freeradius2-postgresql.x86_64 2.1.12-3.el5 installed freeradius2-python.x86_64 2.1.12-3.el5 installed freeradius2-unixODBC.x86_64 2.1.12-3.el5 installed freeradius2-utils.x86_64 2.1.12-3.el5 installed We got below two questions recently. 1. We know 'radiusd -X' will run the radius in debuge mode. With large amount user request, the debug information will be massive. It will be difficult to read one specific user authentication process. Can anyone advise how to debug a specific user's access process? 2. We tried to run multiple radiusd at same server while the second failed. Can anyone advise how to configure the server to run multiple radiusd simultaneously？ Thanks! Tom
On Tue, May 15, 2012 at 8:34 AM, 全球无线联盟 <2394263740@qq.com> wrote:
Hello everyone,
We use below freeradius. It works well. The OS is Linux Enterprise 5.4.
5.4? really? why not update?
Thanks. freeradius2.x86_64 2.1.12-3.el5
these packages should come post-5.4. Are you only updating select packages? why not update everything?
We got below two questions recently.
1. We know 'radiusd -X' will run the radius in debuge mode. With large amount user request, the debug information will be massive. It will be difficult to read one specific user authentication process. Can anyone advise how to debug a specific user's access process?
Try http://freeradius.org/radiusd/man/raddebug.html
2. We tried to run multiple radiusd at same server while the second failed.
duh :P
Can anyone advise how to configure the server to run multiple radiusd simultaneously？
Depends on what you need. In short, each instance needs its own resource (e.g. ports/sockets, log files, etc). There are ways to do that manually (e.g. editing radiusd.conf, customized init scripts, etc.). If you have no idea what I'm talking about, I actually suggest you just use virtualization. lxc, in particular, has very little overhead, and depending on your skills, managing multiple virtual environment might be easier than managing several customized FR instances. -- Fajar
On 15/05/2012 02:34, 全球无线联盟 wrote:
2. We tried to run multiple radiusd at same server while the second failed. Can anyone advise how to configure the server to run multiple radiusd simultaneously？
Why do you need to do this? FreeRADIUS has "virtual-server" functionality, so you can create separate logical instances running a single daemon. -James
On Tue, May 15, 2012 at 1:21 PM, James J J Hooper <jjj.hooper@bristol.ac.uk> wrote:
On 15/05/2012 02:34, 全球无线联盟 wrote:
2. We tried to run multiple radiusd at same server while the second failed. Can anyone advise how to configure the server to run multiple radiusd simultaneously？
Why do you need to do this? FreeRADIUS has "virtual-server" functionality, so you can create separate logical instances running a single daemon.
I can't speak for the Tom, but there are legitimate use cases for this. For example, currently FR does not have limit for a particular virtual server, port, or purpose (i.e. auth vs acct); everything uses the same server thread pool. There can be cases where acct packets flood the server and use up all available server threads, so that all further packets (including auth packets, which should need less resource compared to acct) is rejected. In this case it might be desirable to have separate instance for auth and acct. -- Fajar
Fajar A. Nugraha wrote:
I can't speak for the Tom, but there are legitimate use cases for this.
They're getting more rare.
For example, currently FR does not have limit for a particular virtual server, port, or purpose (i.e. auth vs acct); everything uses the same server thread pool. There can be cases where acct packets flood the server and use up all available server threads, so that all further packets (including auth packets, which should need less resource compared to acct) is rejected. In this case it might be desirable to have separate instance for auth and acct.
That usually happens when the same DB is used for accounting && authentication. A high accounting load will cause starvation on authentication. The solution is to split the DB into two pools. One for accounting (read/write), and another for authentication (read-only). You can provision 50 sockets for acct && auth, then 100 threads. After that, a blocked accounting DB will have *no* effect on authentication. On top of that, the server prioritizes authentication internally. It will preferentially process authentication packets over accounting packets. So that's one more way to avoid server meltdown. Alan DeKok.
On Wed, May 16, 2012 at 1:53 PM, Alan DeKok <aland@deployingradius.com> wrote:
The solution is to split the DB into two pools. One for accounting (read/write), and another for authentication (read-only). You can provision 50 sockets for acct && auth, then 100 threads. After that, a blocked accounting DB will have *no* effect on authentication.
Interesting idea. So use the number of db threads to somewhat limit max number of server threads used for accounting? In our implementation we ended up going with decoupled accounting instead, which pretty much serialize accounting load to db to the number of detail file and reader.
On top of that, the server prioritizes authentication internally. It will preferentially process authentication packets over accounting packets. So that's one more way to avoid server meltdown.
Is this code new? I haven't seen that effect back on our old setup (the days of FR-2.1.7). But then again there might be other factors causing it. -- Fajar
Fajar A. Nugraha wrote:
Interesting idea. So use the number of db threads to somewhat limit max number of server threads used for accounting?
Yes.
In our implementation we ended up going with decoupled accounting instead, which pretty much serialize accounting load to db to the number of detail file and reader.
That helps for systems like MySQL. It doesn't handle parallel writes very well.
On top of that, the server prioritizes authentication internally. It will preferentially process authentication packets over accounting packets. So that's one more way to avoid server meltdown.
Is this code new?
No. It's in 2.1.x.
I haven't seen that effect back on our old setup (the days of FR-2.1.7). But then again there might be other factors causing it.
It's not immediately visible when you use the server. The code just prioritizes processing auth over acct. So if it receives a lot of accounting packets, it will "starve" them, and process authentication instead. This only happens when it's overloaded, so it's unusual, and difficult to see. Alan DeKok.
Hi,
1. We know 'radiusd -X' will run the radius in debuge mode. With large amount user request, the debug information will be massive. It will be difficult to read one specific user authentication process. Can anyone advise how to debug a specific user's access process?
raddebug - with radmin interface
2. We tried to run multiple radiusd at same server while the second failed. Can anyone advise how to configure the server to run multiple radiusd simultaneously��
if you need to run multiple instances, then you need to have them all having their own configuration, listening on different sockets etc. I would advise, instead, if you require seperate configurations for different APs or clients, to use the virtual-server methods instead. edit clients.conf to point the request to a different virtual-server and create that virtual-server. (which could then have more logging enabled etc) alan
participants (5)
-
alan buxey -
Alan DeKok -
Fajar A. Nugraha -
James J J Hooper -
全球无线联盟