detail logging not logging?
Brad Clemmons Jr
brad.clemmons at gmail.com
Fri Jan 16 20:00:50 CET 2009
Hacking to oblivion...that's an interesting way of putting it.
The only things I changed:
Changed the directory locations such as prefix and instance_prefix to my
locations,
Changed user and pass,
Changed Listening port,
Changed type from authentication to accounting only
*Added the detail section at the bottom and configure the directory
locations etc...
Oh and I turned off proxying, virtualhosting, and added the detail {}
section AFTER I had already realized the detail logging didn't seem to be
logging anywhere although I could confirm that it was taking the accounting
packets since I could see the errors in the radius.log if I set the secret
incorrectly. But those 1 or 2 errors were the only logging I could get.
The only hacking out of anything I did was to remove the commented sections
when I copy/pasted into this email just to keep the email from growing
insanely long.
Also this is version 2.1.3(since I managed to forget to add that info
originally. But I will do as you suggested anyway.
Here's a diff of my edited radiusd.conf and the original
radiusd.conf(COMPLETELY UNMODIFIED -
/opt/freeradius/etc/raddb/radiusd.conf):
bash-3.00# diff radiusd.conf /opt/freeradius/etc/raddb/radiusd.conf
54c54
< prefix = /opt/freeradius
---
> prefix = /opt/freeradius-2.1.3
56,58c56,57
< instance_prefix = /opt/voip/freeradius
< sysconfdir = ${instance_prefix}/etc
< localstatedir = ${instance_prefix}/var
---
> sysconfdir = ${prefix}/etc
> localstatedir = ${prefix}/var
60,62c59,61
< logdir = ${instance_prefix}/logs
< raddbdir = ${instance_prefix}/etc
< radacctdir = ${instance_prefix}/var/radacct
---
> logdir = ${localstatedir}/log/radius
> raddbdir = ${sysconfdir}/raddb
> radacctdir = ${logdir}/radacct
70c69
< run_dir = ${localstatedir}/run
---
> run_dir = ${localstatedir}/run/radiusd
168,169c167,168
< user = *******
< group = *******
---
> #user = radius
> #group = radius
252c251
< type = acct
---
> type = auth
277c276
< port = 1813
---
> port = 0
309,310c308,309
< #listen {
< # ipaddr = *
---
> listen {
> ipaddr = *
312,313c311,312
< # port = 0
< # type = acct
---
> port = 0
> type = acct
316c315
< #}
---
> }
526,527c525,526
< proxy_requests = no
< #$INCLUDE proxy.conf
---
> proxy_requests = yes
> $INCLUDE proxy.conf
780,816c779
< #$INCLUDE sites-enabled/
<
< detail {
< # Note that we do NOT use NAS-IP-Address here, as
< # that attribute MAY BE from the originating NAS, and
< # NOT from the proxy which actually sent us the
< # request. The Client-IP-Address attribute is ALWAYS
< # the address of the client which sent us the
< # request.
< #
< # The following line creates a new detail file for
< # every radius client (by IP address or hostname).
< # In addition, a new detail file is created every
< # day, so that the detail file doesn't have to go
< # through a 'log rotation'
< #
< # If your detail files are large, you may also want
< # to add a ':%H' (see doc/variables.txt) to the end
< # of it, to create a new detail file every hour, e.g.:
< #
< # ..../detail-%Y%m%d:%H
< #
< # This will create a new detail file for every hour.
< #
< detailfile =
${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d
< #detailfile =
${radacctdir}/%{NAS-IP-Address}/detail-%Y%m%d
< #detailfile = ${radacctdir}/detail.log
<
< #
< # The Unix-style permissions on the 'detail' file.
< #
< # The detail file often contains secret or private
< # information about users. So by keeping the file
< # permissions restrictive, we can prevent unwanted
< # people from seeing that information.
< detailperm = 0600
< }
---
> $INCLUDE sites-enabled/
On Fri, Jan 16, 2009 at 12:39 PM, Alan DeKok <aland at deployingradius.com>wrote:
> Brad Clemmons Jr wrote:
> > The issue I'm having now though is that I can't seem to get the detail
> > logging to work so the only time I get any logs is if I purposefully
> > foul something up to cause it to error. Right now I have the detail
> > statement at the bottom of the file.
>
> Right there... there's a problem.
>
> The default configuration logs to the detail file. There is literally
> *nothing* you need to do to configure it to log to the detail file.
>
> > I've tried moving it into the
> > modules section but that didn't make any different. I also tried
> > manually specifying the fully qualified path for the log file as well to
> > no avail.
>
> Making random changes without understanding how the server works won't
> help.
>
> > I verified user and group permissions in the necessary directories, but
> > I must still be missing something. Anyone able to point out what's
> > wrong but right under my nose?
> >
> > Also it's worth noting this is running on Solaris10x86 under a zone.
>
> You're either running an old version of the server, OR you've hacked
> the default configuration files into oblivion.
>
>
> > #$INCLUDE sites-enabled/
> >
> > detail {
> > detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d
> > #detailfile = ${radacctdir}/%{NAS-IP-Address}/detail-%Y%m%d
> > #detailfile = ${radacctdir}/detail.log
> > detailperm = 0600
> > }
>
> And... yes. You've completely butchered the default configuration files.
>
> Don't do that.
>
> Throw away everything you've done. Replace it with the default
> configuration files. Add a client definition. Run it in debugging
> mode. Send it accounting packets. Verify that it writes to the detail
> file.
>
> 15 minutes. Tops.
>
> What you've done is clearly to make drastic changes to the
> configuration files without understanding how it works. There *is*
> documentation on the configuration files. Please *read* it before
> editing them. There *are* lots of examples. Please read them.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20090116/e87e1702/attachment.html>
More information about the Freeradius-Devel
mailing list