(RADIATOR) multiple <Log FILE>
Hugh Irvine
hugh at open.com.au
Tue Jun 22 01:21:21 CDT 2004
Hello Stefan -
Once you have the Log clauses working you simply put the PacketTrace
parameter into each of the clauses you want to get a trace 4 debug
from. Also note that you can do this interactively using our Radar
product through the Monitor port (or you can write your own scripts to
access the Monitor port. See sections 6.62 and 23 in the Radiator 3.9
reference manual.
regards
Hugh
On 22 Jun 2004, at 00:46, Lengacher Stefan wrote:
> Bret, Hugh
>
> Ok, i now see, that the two realm-logs have DEBUG-Messages, therefore
> it
> must be Trace 4. I was wrong. Sorry. What i want is therefore a
> PacketTrace in these Logs. I tried now different places to put this
> parameter without any success. Where (in my cfg-file) do i have to put
> this parameter to make it work correctly?
>
> Stefan
>
> -----Original Message-----
> From: Lengacher Stefan
> Sent: Montag, 21. Juni 2004 13:53
> To: Bret Jordan; Hugh Irvine
> Cc: radiator at open.com.au
> Subject: RE: (RADIATOR) multiple <Log FILE>
>
>
> Bret, Hugh
>
> Thanks for the bogus-hint. It now works well (of course it would be
> better to have a globally part to define different <Log FILE>
> Handlers).
> The global Log file logs everything and the others only the appropriate
> one.
>
> But this now leads me to the _trace_ Problem. I would like to have in
> this example:
>
> - 1 global log file (logfile_proxy_auth) where we log at trace level 2
> or 3
> - 1 log file for each defined realm (wetest.ch and lemy.ch) where we
> would like to be
> able to log at level 4 if necessary.
>
> I've setted everything to trace 4 but this appears only to be valid for
> the global log file. In the others i have alway logs at level 2 or 3.
> Is
> this normal behaviour? I read in the documentation that logging at
> trace
> level 4 in a <Log FILE> clause is only possible when globally trace is
> set to 4. But this doesn't work in my example, since i've set every
> trace to 4. So this should work in this example.
>
> But when we go productive, i don't want a trace 4 globally! I just want
> a trace 4 on a specific realm if there are any problems. Isn't that the
> normal way of logging?
>
> Do you have any work around for me?
>
> Regards,
>
> -Stefan
>
> Example configuration:
> ########################################################
> LogDir /var/log/radius
> LogFile %L/logfile_proxy_auth
> Trace 4
>
> <Realm foo>
> <Log FILE>
> Identifier lemylogger
> Filename %L/lemy_logfile_proxy_auth
> Trace 4
> </Log>
> <Log FILE>
> Identifier wetestlogger
> Filename %L/wetest_logfile_proxy_auth
> Trace 4
> </Log>
> </Realm>
>
> <Realm lemy.ch>
> <AuthBy RADIUS>
> Host <snipped>
> Secret <snipped>
> AuthPort <snipped>
> AcctPort <snipped>
> </AuthBy>
> Log lemylogger
> </Realm>
>
> <Realm wetest.ch>
> <AuthBy RADIUS>
> Host <snipped>
> Secret <snipped>
> AuthPort <snipped>
> AcctPort <snipped>
> </AuthBy>
> Log wetestlogger
> </Realm> ########################################################
>
> -----Original Message-----
> From: Bret Jordan [mailto:bret.jordan at utah.edu]
> Sent: Freitag, 18. Juni 2004 23:18
> To: Hugh Irvine
> Cc: Lengacher Stefan; radiator at open.com.au
> Subject: Re: (RADIATOR) multiple <Log FILE>
>
>
> You have to make a bogus realm/handler and put all your <Log FILE>
> stuff
>
> in it, not globally then it will work. Let me know if you have
> questions on what it should look like.. Then you can do exactly what
> you want. I have made a feature request to get a global logging
> section
>
> that will allow you to define multiple Log handlers., btw.
>
> Bret
>
> Hugh Irvine wrote:
>
>>
>> Hello Stefan -
>>
>> What you have discovered is correct - the logging is done for the
>> server as a whole and if you have defined multiple Log FILE's you will
>
>> get multiple copies of the same logging information.
>>
>> regards
>>
>> Hugh
>>
>>
>> On 18 Jun 2004, at 20:09, Lengacher Stefan wrote:
>>
>>> Hello
>>>
>>> I'm an absolute newbie on Radiator. I just began working at weroam in
>
>>> switzerland a couple of weeks ago and am already playing around with
>>> your really good looking tool. Therefore i apologize if i ask stupid
>>> questions ;-)
>>>
>>> Here we go:
>>>
>>> What we're exactly trying to do:
>>> We want different Logfiles for different Realms.
>>>
>>> What i've found out:
>>> We can use <Log FILE> for this.
>>>
>>> The Problem i reflect now is:
>>> I've defined two <Log FILE> parts with different Identifiers and a
>>> LogFile for logging everything and logging the realms that do not
>>> define a Log param. In the Realm parts, i then set Log to the
>>> according one. Unfortunately it does not Log correctly.
>>>
>>> The config: ##################################################
>>> LogDir /var/log/radius
>>> DbDir /etc/raddb
>>> LogFile %L/logfile_proxy_auth
>>>
>>> Trace 4
>>>
>>> <Log FILE>
>>> Identifier lemylogger
>>> Filename %L/lemy_logfile_proxy_auth
>>> Trace 4
>>> </Log>
>>>
>>> <Log FILE>
>>> Identifier wetestlogger
>>> Filename %L/wetest_logfile_proxy_auth
>>> Trace 4
>>> </Log>
>>>
>>> <Realm lemy.ch>
>>> <AuthBy RADIUS>
>>> Host <snipped out>
>>> Secret <snipped out>
>>> AuthPort <snipped out>
>>> AcctPort <snipped out>
>>> </AuthBy>
>>> Log lemylogger
>>> </Realm>
>>>
>>> <Realm wetest.ch>
>>> <AuthBy RADIUS>
>>> Host <snipped out>
>>> Secret <snipped out>
>>> AuthPort <snipped out>
>>> AcctPort <snipped out>
>>> </AuthBy>
>>> Log wetestlogger
>>> </Realm> #####################################################
>>>
>>> When i now do a radpwtst once with realm wetest.ch and once with real
>
>>> lemy.ch then in both cases i see the log-trace in logfile_proxy_auth
>>> and lemy_logfile_proxy_auth. But nothing in wetest_logfile_proxy_auth
>>>
>>> Is that because i defined both <Log FILE> globally and they get
>>> therefore overwritten? This would be a bit exhausting when i have to
>>> define each <Log FILE> inside every Realm definition. Are there any
>>> other possiblities to do this (even easyier)?
>>>
>>>
>>> Regards,
>>>
>>> Stefan Lengacher
>>> Project & Testing Manager
>>>
>>> ____________________________________________
>>> WeRoam(r)
>>>
>>> TOGEWAnet AG / P.O. Box / Nussbaumstrasse 25
>>> CH-3000 Bern 22 / Switzerland
>>> tel. +41 31 341 10 20
>>> direct: +41 31 341 1126
>>> fax: +41 31 341 10 21
>>> mobile: +41 79 483 8422
>>> Stefan.Lengacher at weroam.com
>>> www.weroam.com
>>> ____________________________________________
>>> This email may contain confidential and/or privileged information
>>> which should not be used, copied or disclosed without permission. If
>
>>> you are not an intended recipient, please contact the sender
>>> immediately.
>>>
>>> --
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with 'unsubscribe
>>> radiator' in the body of the message.
>>>
>>>
>>
>> NB: have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Bret Jordan Dean's Office
> Director of Networking College of Engineering
> 801.585.3765 University of Utah
> jordan at coe.utah.edu
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list