原信息
主题： Freeradius-Users Digest, Vol 58, Issue 74
发件人： [email protected]
日期： 2010/02/20 19:20
Send Freeradius-Users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
Subject: Re: modules instantiation
To: FreeRadius users mailing list
<[email protected]>
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: modules instantiation
To: FreeRadius users mailing list
<[email protected]>
Message-ID: <[email protected]>
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 <[email protected]> wrote:
>
> From: Doug Hardie <[email protected]>
> Subject: Re: modules instantiation
> To: "FreeRadius users mailing list" <[email protected]>
> 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
************************************************
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
