(RADIATOR) multiple <Log FILE>

Hugh Irvine hugh at open.com.au
Thu Jun 24 17:38:52 CDT 2004


Hi Chris -

Nice to hear from you.

Yes you can run as many logs as you wish - you simply need to set up  
<Log FILE> clauses as required.

See section 6.10 in the Radiator 3.9 reference manual.

regards

Hugh


On 25 Jun 2004, at 00:45, Chris Rosan wrote:

> Hello all,
>
> I have just been reading through this.....
>
> Is there anyway to run the log's to 2 files at the same time, 1 with
> the lowest trace, and one with the highest trace?
>
> Cheers.
>
> Chris Rosan
>
>
>>>> Bret Jordan <bret.jordan at utah.edu> 23/06/2004 3:07:31 am >>>
> And you set the trace to 5?
>
> This is what I do:  (at global config)  This way I just uncomment one
> and comment out the other to switch back and forth between trace 3 and
> 4.
>
> Bret
>
> # ----------------------------------------
> # Global Logging
> # ----------------------------------------
> #LogStdout
> LogDir                  /var/log/radiator
> LogFile                 %L/radiator.log
> Trace                   3
>
> <Handler Client-Identifier=Global_Logging>
>     <Log FILE>
>         Identifier      Logger_System
>         Trace           3
>         Filename        %L/radiator.log
>     </Log>
>
>     <Log FILE>
>         Identifier      Logger_System_Debug
>         Trace           4
>         Filename        %L/radiator-debug.log
>     </Log>
> </Handler>
>
> <AuthLog FILE>
>     Identifier          Logger_Authentication
>     Filename            %L/authentication.log
>     LogSuccess          1
>     LogFailure          1
>     SuccessFormat       %l,%W,%U,%N,%h,OK
>     FailureFormat       %l,%W,%U,%N,%h,FAIL
> </AuthLog>
>
>
> <Handler Realm=something.com,Client-Identifier=BLABLABLA>
>     RejectHasReason
>     AcctLogFileName             %L/something.com_accounting.log
>     AcctLogFileFormat           %l, %{User-Name}, %{Acct-Authentic},
> %{Acct-Status-Type}, \
>                                 %{NAS-IP-Address},
> %{foundry-command-string}
>
>     Log                         Logger_System
>     #Log                        Logger_System_Debug
>     AuthLog                     Logger_Authentication
>
>     RewriteUsername s/^([^@]+).*/$1/
>     <AuthBy FILE>
>         ....
>     </AuthBy>
> </Handler>
>
>
>
> Lengacher Stefan wrote:
>
>> Hello Hugh
>>
>> I don't get it working. There seems to be no way to see the whole
> packet
>> dump in my realm-logs and not in the global one. I'm now trying with
>> Handlers instead of Realms but with no success even.
>> I'll study now radar. But for me, this is a bit too much features
> since
>> i only want a clear flat-file log.
>>
>> Regards
>>
>> Stefan
>>
>> -----Original Message-----
>> From: Hugh Irvine [mailto:hugh at open.com.au]
>> Sent: Dienstag, 22. Juni 2004 08:21
>> To: Lengacher Stefan
>> Cc: radiator at open.com.au; Bret Jordan
>> Subject: Re: (RADIATOR) multiple <Log FILE>
>>
>>
>>
>> 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?
>>
>>
>>
>
> --  
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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.
>
> ####################################################################### 
> ##############
> This email was scanned for your safety and protection from
> virus's and offensive content. postmaster at deltaeuropcar.com.au
> ####################################################################### 
> ##############
>
> This e-mail and any files attached to it are confidential and
> intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this e-mail
> inadvertently or you are not the intended recipient, you may
> not distribute, copy or in any way rely on it. Further, you
> should notify the sender immediately and delete the e-mail
> from your computer. The contents and opinions contained in
> this e-mail are those of the individual sender unless they
> are expressly stated to be those of Europcar. Whilst we have
> taken precautions to alert us to the presence of computer
> viruses, we cannot and do not guarantee that this email and
> any files transmitted with it are free from such viruses.
>
> This email was scanned for your safety and protection from
> virus's and offensive content.
> postmaster at deltaeuropcar.com.au
>
>

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