Hello Toomas -
All you need to do in your PreClientHook is include the same code for finding the Client as is in "radiusd->despatch_request()".
Alternatively, as mentioned before, you can also use a StartupHook to patch PreHandlerHooks into your Client clauses.
Of course, you could also use a PreProcessingHook in each of your Handlers or Realms as well.
regards
Hugh
On Friday, Jan 31, 2003, at 19:56 Australia/Melbourne, Toomas Kärner wrote:
Hi,
Actually I don't need special hooks per client. My problem is that when I do
my $identifier = $p->{Client}->{Identifier}; in PreClientHook (the client is
not selected jet) I will get nothing so I just need to execute my hook a
little later than PreClient and PreHandler would be perfect. So if there
were a keyword in ClientList SQL with what I could call for hook that would
be executed with every client. I need this Identifier (from SQL) for NAS
detection, to be abel to send back correct set of parameters needed for tis
NAS in order to set up session.
So the thing that I relly need is to add an attribute to every request with
a NAS "type" and this type should come from SQL.
Rgds.
Toomas
----- Original Message -----
From: "Hugh Irvine" <[EMAIL PROTECTED]>
To: "Claudio Lapidus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"Toomas Kärner" <[EMAIL PROTECTED]>
Sent: Friday, January 31, 2003 1:04 AM
Subject: Re: (RADIATOR) Retrieving a hook by filename from inside
ClientListSQL
Hello Toomas, Hello Claudio -
I have been thinking about this a bit more, and there are alternative
approaches that you could consider.
The first would be a StartupHook that compiles code with multiple entry
points and then patches those entry points into the Client structures
that have been built from the database (probably using the Identifier
tags).
The second would be a generic PreClientHook that checks to see for
which Client clause the current request is destined for, then does the
processing for that Client.
Both of these approaches are a bit more complicated than using
PreHandlerHooks in the Client clauses directly, but at least its
possible.
regards
Hugh
On Friday, Jan 31, 2003, at 09:38 Australia/Melbourne, Mike McCauley
wrote:
Hello Claudio and Toomas,On Fri, 31 Jan 2003 09:27 am, Hugh Irvine wrote:Mikey - Could you answer this please? ta Hugh Begin forwarded message:From: Toomas Kärner <[EMAIL PROTECTED]>
Date: Fri Jan 31, 2003 02:36:44 Australia/Melbourne
To: "Claudio Lapidus" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: (RADIATOR) Retrieving a hook by filename from inside
ClientListSQL
Hi,
Any comments? ... I have the same issue.
Rgds.
Toomas Kärner
----- Original Message -----
From: "Claudio Lapidus" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 07, 2002 12:01 AM
Subject: (RADIATOR) Retrieving a hook by filename from inside
ClientListSQL
Hello,
I need to get the PreHandlerHook for certain clients from our
standard
RADCLIENTLIST SQL table. The problem is that I'd prefer to store the
hook
code in a file and not directly inside the table, for various
reasons.
I've setup this config and it works fine:
<Client x.x.x.x>
Secret shhhh
PreHandlerHook file:"%D/preauth.pl"
</Client>
As expected, the hook gets executed for this particular client.
However,
this one doesn't work:
<ClientListSQL>
DBSource dbi:mysql:radiator
DBUsername sqluser
DBAuth donttellya
</ClientListSQL>
from the table we get:
mysql> select NASIDENTIFIER, SECRET, PREHANDLERHOOK from
RADCLIENTLIST;
+---------------+-------------+----------------------+
| NASIDENTIFIER | SECRET | PREHANDLERHOOK |
+---------------+-------------+----------------------+
| x.x.x.x | shhhh | file:"%D/preauth.pl" |
+---------------+-------------+----------------------+
1 row in set (0.00 sec)
By seeing further action it is apparent that the hook doesn't get
executed
this time. However, even at level 4 trace doesn't show anything
regarding
this step. I also tried changing double quotes to single quotes in
the
fieldcontents, to no avail. So: 1. Is it legal to store the hook's filename into the table instead of the code itself? (I hope so :-)No. The file:".."syntax is recognised by the config file parser, so it only works in the config file.2. Is there a way to increase debug verbosity for ClientListSQLoperations?Only by adding more $self->log($main::LOG_DEBUG, ...); lines. If you have a particular need for more debug, let me know where, and I will see if we can add it. Cheers.--TIA, cl. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.=== Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS etc.
-- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
-- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.