原信息 主题： Freeradius-Users Digest, Vol 58, Issue 74 发件人： freeradius-users-request@lists.freeradius.org 日期： 2010/02/20 19:20 Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..." Today's Topics: 1. Re: modules instantiation (Alan DeKok) 2. Re: modules instantiation (Doug Hardie) ---------------------------------------------------------------------- Message: 1 Date: Sat, 20 Feb 2010 03:07:15 +0100 From: Alan DeKok <aland@deployingradius.com> Subject: Re: modules instantiation To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <4B7F43D3.20302@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Latha Krishnamurthi wrote:
I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation).
No. The module is NOT having "a new instance created". A module "instance" is defined by a module configuration. One configuration: one instance. The "instance" data is *constant*. The module gets called multiple times simultaneously from multiple threads when multiple requests are received.
This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc.
Why? Is that connection changing the way the module behaves?
But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ??
Am I missing something/configuration, your help is grately appreciated.
If you need to store data that is associated with a particulare *request*, and is valid only for the lifetime of a request, see request_data_add(), and request_data_get(). Alan DeKok. ------------------------------ Message: 2 Date: Fri, 19 Feb 2010 18:36:14 -0800 From: Doug Hardie <bc979@lafn.org> Subject: Re: modules instantiation To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <D8F32319-334A-46E4-B298-4025E188FE45@lafn.org> Content-Type: text/plain; charset=us-ascii On 19 February 2010, at 17:35, Latha Krishnamurthi wrote:
Thankyou very much for your prompt reply. I was referring to this documentation.
http://wiki.freeradius.org/Modules2
The xxx_instantiate module is called each time a new instance is started. Generally this >>module is used to establish the data for the instance that needs to be retained during the >>life of the instance. For example, reading the configuration variables. cf_section_parse>>(conf, data, module_config) is used to do this function.
Setup struct rlm_xxx_t to hold data that needs to be accessed by all instances of the >>rlm. This data is not necessarily the same for each instance. There is a separate copy >>for each instance. For example, this is the place to store configuration variables that will >>be provided in FreeRADIUS.conf.
Well, it sure seemed clear when I wrote it, but now I tend to agree that its a bit misleading. Those words were lifted from the original version 1 document and perhaps something changed with version 2, but I don't recall any such changes. In any case, it does need a revision.
It is described like I can have the module specific data in the instance and use it in the life time of the instance.
So if I need to use a unique socket connection for each thread, I have no place to store the instance specific data ? I need to have a global pool and lock it with mutex ?? (looks like rlm_ldap does something similar ?)
Alan responded with something I was not aware of. I suspect thats the way you need to go.
Thanks in advance LK
--- On Fri, 2/19/10, Doug Hardie <bc979@lafn.org> wrote:
From: Doug Hardie <bc979@lafn.org> Subject: Re: modules instantiation To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Date: Friday, February 19, 2010, 3:49 PM
On 19 February 2010, at 15:24, Latha Krishnamurthi wrote:
I am using the free radius 2.1.3. I have a module rlm_xxx and have initialized it as thread safe. I have configured the start_servers as 3. The issue I am having is as follows.
I see that a new instance is getting created when the first one is busy handling a request. (I do this this by adding a sleep in the module and printing the threadid) I am expecting the xxx_instantiate function to get called each time a new instance is created (reading in the documentation). This does not happen. I am actually connecting to a server in the instantiate function and storing the socket id in the *instance, so that I can use it later in the authenticate etc.
But it seems that the socket id is the same for all the instances. *instance seems to be shared by all the instances ??
Am I missing something/configuration, your help is grately appreciated.
I believe this is an issue of terminology. Instantiation in this case refers to the configuration process prior to the start of the server accepting Radius requests. It does not refer to instantiation of new threads. I am not aware of any hook you can use for instatiation of new threads. In one of the older version rlm_example files is the following comment:
* If the module needs to temporarily modify it's instantiation * data, the type should be changed to RLM_TYPE_THREAD_UNSAFE. * The server will then take care of ensuring that the module * is single-threaded.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html End of Freeradius-Users Digest, Vol 58, Issue 74 ************************************************