Logging (was: Freeradius-Users Digest, Vol 129, Issue 3)

[Stefan Paetow]

>Yes, 'detail' is included in the accounting section.

Ok, that's not going to log then. It will only log when it gets accounting
packets. 

Look at the 'default' server. In the post-auth section you'll see a
reply_log entry that is commented out by default. If you uncomment this,
it will start logging entries as per the 'reply_log' line log that is
defined in the 'detail.log' module in mods-available. However, note that
this will *not* be a single-line entry (which is what's recommended by the
eduroam operator in the UK).

Look at 
https://github.com/FreeRADIUS/freeradius-server/blob/v2.x.x/raddb/modules/l
inelog for the current linelog for v2.x. If you're on 3.x, go to
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/mods-avai
lable/linelog - This will come in handy when doing what the Confluence
page you found says.

>Log file enclosed in ZIP format.

Don't do that. Archives are stripped. A simple freeradius -X output
capture is useful.

>I found this website which may help to enable logging, looks like logging
>functionality is different between 2.1.10 and 2.1.12.
>http://confluence.diamond.ac.uk/pages/viewpage.action?pageId=22252353

Ahhh... My history comes back to haunt me... ;-)

You may want to set up two of the three line logs defined on that page:
eduroam_log and inner_auth_log. To log to the *log* directory, do *not*
set 'filename' to 'syslog'. Instead set it to whatever you wanted the
filename to be... "${logdir}/linelog" is the default in linelog. Tweak
that appropriately for the inner_auth_log (if you want to log
authentication of your own users separately).

Then, like the page says, call 'eduroam_log' in the post-auth section, or,
better yet, in the post-proxy section of your eduroam server, since
post-proxy gets hit by an incoming reply from a home organisation before
post-auth does (and post-auth also gets hit by your own users after their
authentication reply returns from the inner-tunnel server).

Also, like the page says, call 'inner_auth_log' from the post-auth section
of your inner-tunnel. Stop your server. Start it in debug mode. Then hit
it with an authentication request (for your own user). You should with any
luck get an entry in your inner-tunnel authentication log. Then, if you
have a test subject from another institution, get them to authenticate
through eduroam and see what happens.

Like Alan and others have pointed out, the module files are liberally
commented so that it is easier to understand the operation of the server
(and what the options do). Of course, if you strip out all comments for a
bare-bones configuration, then yes, it becomes distinctly more difficult
(or you spend a lot of time on Github to understand what each file does).

:-)

Stefan Paetow
Moonshot Industry & Research Liaison Coordinator

t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp at jabber.dev.ja.net
skype: stefan.paetow.janet

jisc.ac.uk

Networkshop44, University of Manchester. Save the date: 22-24 March, 2016.
#NWS44

Jisc is a registered charity (number 1149740) and a company limited by
guarantee which is registered in England under Company No. 5747339, VAT
No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower
Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a
company limited by guarantee which is registered in England under Company
No. number 2881024, VAT No. GB 197 0632 86. The registered office is:
Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T
01235 822200.


>