回复: Freeradius-Users Digest, Vol 58, Issue 74
miaowang at foxmail.com
miaowang at foxmail.com
Fri Apr 30 09:44:57 CEST 2010
原信息
主题: Freeradius-Users Digest, Vol 58, Issue 74
发件人: freeradius-users-request at lists.freeradius.org
日期: 2010/02/20 19:20
Send Freeradius-Users mailing list submissions to
freeradius-users at 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 at lists.freeradius.org
You can reach the person managing the list at
freeradius-users-owner at 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 at deployingradius.com>
Subject: Re: modules instantiation
To: FreeRadius users mailing list
<freeradius-users at lists.freeradius.org>
Message-ID: <4B7F43D3.20302 at 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 at lafn.org>
Subject: Re: modules instantiation
To: FreeRadius users mailing list
<freeradius-users at lists.freeradius.org>
Message-ID: <D8F32319-334A-46E4-B298-4025E188FE45 at 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 at lafn.org> wrote:
>
> From: Doug Hardie <bc979 at lafn.org>
> Subject: Re: modules instantiation
> To: "FreeRadius users mailing list" <freeradius-users at 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
************************************************
More information about the Freeradius-Users
mailing list