Hugh Irvine wrote:
>
> Hi Dave -
>
> Did you mean to add the source modules to this mail?
I suppose I could... The difficulty is that we have other
customizations, so it's difficult to extract just those changes that are
relevant to other people (as I am not quite a CVS expert :-) but here's
the gist of the changes.
For the USR1/2Hook, add these lines to ServerConfig.pm inside the
keyword() sub:
elsif ($keyword eq 'USR1Hook')
{
# Get a reference to the code block
$self->{USR1Hook} = eval($value);
&main::log($main::LOG_ERR,
"Compilation error in USR1Hook(): $@")
if $@;
}
elsif ($keyword eq 'USR2Hook')
{
# Get a reference to the code block
$self->{USR2Hook} = eval($value);
&main::log($main::LOG_ERR,
"Compilation error in USR2Hook(): $@")
if $@;
}
Then, change radiusd subs handle_sigusr1 and handle_sigusr2:
#####################################################################
# Handle SIGUSR1 by increasing the trace level or running a hook
sub handle_sigusr1
{
if (defined($config->{USR1Hook})) {
eval { &{$config->{USR1Hook}}() };
if ($@) {
&log($LOG_WARNING, "USR1Hook failed: $@");
}
} else {
$main::config->{Trace} = &Radius::Log::adjustTrace(1);
&log($LOG_INFO, "Trace level increased to
$main::config->{Trace}");
}
}
#####################################################################
# Handle SIGUSR2 by decreasing the trace level or running a hook
sub handle_sigusr2
{
if (defined($config->{USR2Hook})) {
eval { &{$config->{USR2Hook}}() };
if ($@) {
&log($LOG_WARNING, "USR2Hook failed: $@");
}
} else {
$main::config->{Trace} = &Radius::Log::adjustTrace(-1);
&log($LOG_INFO, "Trace level decreased to
$main::config->{Trace}");
}
}
That's it.
The AuthLog is much more involved... I don't think I could easily make a
diff between the base 2.16.3 version and the AuthLog version because of
customizations, but basically what I did is this:
I addeded a global configuration object <AuthLog xxx>. I also added the
keyword AuthLog and the configuration object <AuthLog xxx> to
Handler.pm. This is because Handler.pm is what reports most of the
authentication successes and failures. Then I made AuthLogGeneric
module that acts as a base class for the various AuthLog modules. It
specifies keywords such as LogSuccess, NoLogSuccess, LogFailure, and
NoLogFailure.
In order to allow AuthBy modules to log success or failure in
authentication independantly of Handler.pm (AuthRADIUS for one), I had
to cause Handler.pm to pass a copy of itself to all AuthBy modules that
it calls as a last parameter. However, this may be at odds with the
next version of Radiator, which seems to have a more universal method
for reporting success or failure. I'll have to look at it again. But
if you're interested, I can send you the code I have (including an
AuthLog FILE and an untested AuthLogSQL) in my CVS repository.
> At 16:55 -0600 00/11/8, Dave Lloyd wrote:
> >Here's a couple more handy little things we put into our Radiator
> >server:
> >
> >- USR1Hook and USR2Hook: I don't much use dynamic log level changes, so
> >I added these global config items to do stuff I want instead when we get
> >SIGUSR1/2. If they aren't defined, they default to the normal
> >behavour. I use this to switch the process into or out of accessing the
> >billing system, by setting or clearing a global variable that I later
> >test for in my <Handler>s.
> >
> >- I also added WINCHHook because I needed one more function. :-)
> >
> >- I added <AuthLog FILE> and <AuthLog SQL> to replace password.log.
> >They can log successes, failures, or both, and you can also include the
> >reason. I did this so our helpdesk can use our admin tool to view
> >recent connection attempts.
> >
> >The USRxHook stuff was really easy, but the AuthLog stuff was more
> >involved... it involves changing many AuthBy modules, as well as
> >Handler.pm.
> >
> >- D
>
> --
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
