Re: modules instantiation

[Latha Krishnamurthi]

This is very clear.Thanks.

--- On Mon, 2/22/10, Doug Hardie bc...@lafn.org wrote:


From: Doug Hardie bc...@lafn.org
Subject: Re: modules instantiation
To: FreeRadius users mailing list freeradius-users@lists.freeradius.org
Date: Monday, February 22, 2010, 10:56 PM



I tried to correct the wiki's description but was not able to do so.  I can log 
in fine and it says I can edit the file.  However, after making the changes 
save just gives a blank screen and the changes never appear in the text.

In the modules2 file change:

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.


to:

The xxx_instantiate module is called each time a new instance is started during 
the initial configuration process.  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.  Note 
that the instantiate module is not called each time a new instantiation of the 
module is started during run time.  The data established during the instantiate 
module is available to all instantiations during run time.   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().
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html



  -
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules instantiation

[Latha Krishnamurthi]

Thankyou will try that.

--- On Fri, 2/19/10, Alan DeKok al...@deployingradius.com wrote:


From: Alan DeKok al...@deployingradius.com
Subject: Re: modules instantiation
To: FreeRadius users mailing list freeradius-users@lists.freeradius.org
Date: Friday, February 19, 2010, 6:07 PM


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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html



  -
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules instantiation

[Doug Hardie]

I tried to correct the wiki's description but was not able to do so.  I can log 
in fine and it says I can edit the file.  However, after making the changes 
save just gives a blank screen and the changes never appear in the text.

In the modules2 file change:

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.


to:

The xxx_instantiate module is called each time a new instance is started during 
the initial configuration process.  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.  Note 
that the instantiate module is not called each time a new instantiation of the 
module is started during run time.  The data established during the instantiate 
module is available to all instantiations during run time.   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().
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

modules instantiation

[Latha Krishnamurthi]

 
Hi,
 
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.
 
Thanks in advance for your inputs.
 
Thanks,
Latha.
 
 


  -
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules instantiation

[Doug Hardie]

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

Re: modules instantiation

[Latha Krishnamurthi]

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.
 
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 ?)
 
Thanks in advance
LK
 
--- On Fri, 2/19/10, Doug Hardie bc...@lafn.org wrote:


From: Doug Hardie bc...@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

Re: modules instantiation

[Alan DeKok]

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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules instantiation

[Doug Hardie]

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 bc...@lafn.org wrote:
 
 From: Doug Hardie bc...@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

modules' instantiation failing (files)

[Pedro Figueiredo]

hi all,

i need to send different lns configuration in a round-robin fashion.  
in order to do this, i added the following to modules:

 files rra {
 userfile = ${confdir}/users.rr1
 acctusersfile = ${confdir}/acct_users
 preproxy_usersfile = ${confdir}/preproxy_users
 compat = no
 }
 files rrb {
 userfile = ${confdir}/users.rr2
 acctusersfile = ${confdir}/acct_users
 preproxy_usersfile = ${confdir}/preproxy_users
 compat = no
 }

and then in authorize:

 redundant-load-balance {
 rra
 rrb
 ok = 1
 }

freeradius is picking the right module, alternating between them on  
each request. the problem is in the instantiation of the modules,  
where i'm getting the following:

Module: Instantiated files (rra)
files: usersfile = /etc/freeradius-dev/users
files: acctusersfile = /etc/freeradius-dev/acct_users
files: preproxy_usersfile = /etc/freeradius-dev/preproxy_users
files: compat = no
Module: Instantiated files (rrb)
files: usersfile = /etc/freeradius-dev/users
files: acctusersfile = /etc/freeradius-dev/acct_users
files: preproxy_usersfile = /etc/freeradius-dev/preproxy_users
files: compat = no

as you can see, it's not reading the files i told it to read.  
confirmed with strace, just to be on the safe side:

write(1, Module: Instantiated files (rra)..., 34Module:  
Instantiated files (rra)) = 34
write(1,  files: usersfile = \/etc/freera..., 48 files: usersfile  
= /etc/freeradius-dev/users) = 48
write(1,  files: acctusersfile = \/etc/fr..., 57 files:  
acctusersfile = /etc/freeradius-dev/acct_users) = 57
write(1,  files: preproxy_usersfile = \/e..., 66 files:  
preproxy_usersfile = /etc/freeradius-dev/preproxy_users) = 66
write(1,  files: compat = \no\\n, 22 files: compat = no) = 22
open(/etc/freeradius-dev/users, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0640, st_size=1880, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,  
0) = 0x2a973c3000
read(6, # Simplify the Tunneling rules t..., 4096) = 1880
read(6, , 4096)   = 0
read(6, , 4096)   = 0
close(6)= 0
munmap(0x2a973c3000, 4096)  = 0
open(/etc/freeradius-dev/acct_users, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0640, st_size=532, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,  
0) = 0x2a973c3000
read(6, #\n#\t$Id: acct_users,v 1.4 2003/0..., 4096) = 532
read(6, , 4096)   = 0
read(6, , 4096)   = 0
close(6)= 0
munmap(0x2a973c3000, 4096)  = 0
open(/etc/freeradius-dev/preproxy_users, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0640, st_size=1039, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,  
0) = 0x2a973c3000
read(6, #\n#  Configuration file for the ..., 4096) = 1039
read(6, , 4096)   = 0
close(6)= 0
munmap(0x2a973c3000, 4096)  = 0
write(1, Module: Instantiated files (rrb)..., 34Module:  
Instantiated files (rrb)) = 34
write(1,  files: usersfile = \/etc/freera..., 48 files: usersfile  
= /etc/freeradius-dev/users) = 48
write(1,  files: acctusersfile = \/etc/fr..., 57 files:  
acctusersfile = /etc/freeradius-dev/acct_users) = 57
write(1,  files: preproxy_usersfile = \/e..., 66 files:  
preproxy_usersfile = /etc/freeradius-dev/preproxy_users) = 66
write(1,  files: compat = \no\\n, 22 files: compat = no) = 22
open(/etc/freeradius-dev/users, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0640, st_size=1880, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,  
0) = 0x2a973c3000
read(6, # Simplify the Tunneling rules t..., 4096) = 1880
read(6, , 4096)   = 0
read(6, , 4096)   = 0
close(6)= 0
munmap(0x2a973c3000, 4096)  = 0
open(/etc/freeradius-dev/acct_users, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0640, st_size=532, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,  
0) = 0x2a973c3000
read(6, #\n#\t$Id: acct_users,v 1.4 2003/0..., 4096) = 532
read(6, , 4096)   = 0
read(6, , 4096)   = 0
close(6)= 0
munmap(0x2a973c3000, 4096)  = 0
open(/etc/freeradius-dev/preproxy_users, O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0640, st_size=1039, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,  
0) = 0x2a973c3000
read(6, #\n#  Configuration file for the ..., 4096) = 1039
read(6, , 4096)   = 0
close(6)= 0
munmap(0x2a973c3000, 4096)  = 0

i couldn't find any 

Re: modules' instantiation failing (files)

[Alan DeKok]

Pedro Figueiredo wrote:
 i need to send different lns configuration in a round-robin fashion.  
 in order to do this, i added the following to modules:
 
  files rra {
  userfile = ${confdir}/users.rr1

  It's usersfile, with an s.  users + file.

  Alan DeKok.
--
  http://deployingradius.com   - The web site of the book
  http://deployingradius.com/blog/ - The blog
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules' instantiation failing (files)

[Pedro Figueiredo]

On 2 Apr 2007, at 13:38, Alan DeKok wrote:
 Pedro Figueiredo wrote:
 i need to send different lns configuration in a round-robin fashion.
 in order to do this, i added the following to modules:

  files rra {
  userfile = ${confdir}/users.rr1

   It's usersfile, with an s.  users + file.

   Alan DeKok.


oh. now i'm as red as a big red nose (although, in my defense, 1  
other people looked into this as well and also couldn't spot it).

one suggestion for the future, though: can freeradius complain when  
it finds an unknown keyword?

thank you very much for your help.

pedro
--
This email and any attachments may be confidential and/or legally privileged. 
If you have received this e-mail and you are not a named addressee, please 
inform the sender of this email by sending a return email to the address above 
and then delete the e-mail and your response from your system. If you are not a 
named addressee you must not use, disclose, distribute, copy, print or rely on 
this e-mail. Any views or opinions presented are solely those of the author. 
Any statements made, or intentions expressed in this communication may not 
necessarily reflect the view of Easynet. No content herein will bind Easynet or 
any associated company unless confirmed by the execution of a formal contract 
by Easynet. Any figures or amounts given in this email are quotations only and 
are subject to change. Although Easynet routinely screens for viruses, 
addressees should scan this e-mail and any attachments for viruses. Easynet 
makes no representation or warranty as to the absence of virus!
 es in this e-mail or any attachments. Please note that to ensure regulatory 
compliance and for the protection of our customers and business, we may monitor 
and read e-mails sent to and from our server(s). 

Easynet Limited a company incorporated and existing under the laws of England 
and Wales, with company number 2954343 and having its registered office at 
44-46 Whitfield Street London, W1T 2RJ.


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules' instantiation failing (files)

[Alan DeKok]

Pedro Figueiredo wrote:
 one suggestion for the future, though: can freeradius complain when  
 it finds an unknown keyword?

  As always, patches are welcome.

  But part of the issue is philosophy: The configuration file format is
very forgiving, which avoids a lot of problems.  Occasionally it can be
too forgiving, but the problem is usually a caused by re-typing things,
rather than doing a cut  paste of configuration.

  Alan DeKok.
--
  http://deployingradius.com   - The web site of the book
  http://deployingradius.com/blog/ - The blog
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules' instantiation failing (files)

[Pedro Figueiredo]

On 2 Apr 2007, at 14:51, Pedro Figueiredo wrote:

 On 2 Apr 2007, at 13:38, Alan DeKok wrote:
 Pedro Figueiredo wrote:
 i need to send different lns configuration in a round-robin fashion.
 in order to do this, i added the following to modules:

  files rra {
  userfile = ${confdir}/users.rr1

   It's usersfile, with an s.  users + file.

   Alan DeKok.


 oh. now i'm as red as a big red nose (although, in my defense, 1
 other people looked into this as well and also couldn't spot it).

ok, there's something really weird going on now. this is my config:

 files {
 usersfile = ${confdir}/users
 acctusersfile = ${confdir}/acct_users
 preproxy_usersfile = ${confdir}/preproxy_users

 #  If you want to use the old Cistron 'users' file
 #  with FreeRADIUS, you should change the next line
 #  to 'compat = cistron'.  You can the copy your  
'users'
 #  file from Cistron.
 compat = no
 }


 files wcpefiles {
 usersfile = ${confdir}/wcpeusers
 acctusersfile = ${confdir}/acct_users
 compat = no
 }

 files rra {
 usersfile = ${confdir}/users.rr1
 acctusersfile = ${confdir}/acct_users
 preproxy_usersfile = ${confdir}/preproxy_users
 compat = no
 }

 files rrb {
 usersfile = ${confdir}/users.rr2
 acctusersfile = ${confdir}/acct_users
 preproxy_usersfile = ${confdir}/preproxy_users
 compat = no
 }

and here's what's happening:

Module: Loaded files
files: usersfile = /etc/freeradius-dev/users
files: acctusersfile = /etc/freeradius-dev/acct_users
files: preproxy_usersfile = /etc/freeradius-dev/preproxy_users
files: compat = no
Module: Instantiated files (files)
files: usersfile = /etc/freeradius-dev/users.rr1
files: acctusersfile = /etc/freeradius-dev/acct_users
files: preproxy_usersfile = /etc/freeradius-dev/preproxy_users
files: compat = no
Module: Instantiated files (rra)
files: usersfile = /etc/freeradius-dev/users.rr2
files: acctusersfile = /etc/freeradius-dev/acct_users
files: preproxy_usersfile = /etc/freeradius-dev/preproxy_users
files: compat = no
Module: Instantiated files (rrb)
files: usersfile = /etc/freeradius-dev/wcpeusers
files: acctusersfile = /etc/freeradius-dev/acct_users
files: preproxy_usersfile = /etc/freeradius-dev/preproxy_users
files: compat = no
Module: Instantiated files (wcpefiles)

as you can see, it's off by one. any suggestions or ideas on why it's  
doing this?

cheers,

pedro
This email and any attachments may be confidential and/or legally privileged. 
If you have received this e-mail and you are not a named addressee, please 
inform the sender of this email by sending a return email to the address above 
and then delete the e-mail and your response from your system. If you are not a 
named addressee you must not use, disclose, distribute, copy, print or rely on 
this e-mail. Any views or opinions presented are solely those of the author. 
Any statements made, or intentions expressed in this communication may not 
necessarily reflect the view of Easynet. No content herein will bind Easynet or 
any associated company unless confirmed by the execution of a formal contract 
by Easynet. Any figures or amounts given in this email are quotations only and 
are subject to change. Although Easynet routinely screens for viruses, 
addressees should scan this e-mail and any attachments for viruses. Easynet 
makes no representation or warranty as to the absence of virus!
 es in this e-mail or any attachments. Please note that to ensure regulatory 
compliance and for the protection of our customers and business, we may monitor 
and read e-mails sent to and from our server(s). 

Easynet Limited a company incorporated and existing under the laws of England 
and Wales, with company number 2954343 and having its registered office at 
44-46 Whitfield Street London, W1T 2RJ.


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: modules' instantiation failing (files)

[Alan DeKok]

Pedro Figueiredo wrote:
 as you can see, it's off by one. any suggestions or ideas on why it's  
 doing this?

  It's not off by one.  Read it again.

  It prints out the configuration items BEFORE it prints out that it
successfully instantiated the module.

  Alan DeKok.
--
  http://deployingradius.com   - The web site of the book
  http://deployingradius.com/blog/ - The blog
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html