| |||||
| |||||
Search Irongeek.com:
Help Irongeek.com pay for bandwidth and research equipment: |
Back To MAN Pages From BackTrack 5 R1 Master List
That will cause your accounting packets to go the the backup server -
and some NASes don't even switch back to the primary server when it
comes back up.
The result is that accounting records are missed, and/or the
administrator must jump through hoops in order to combine the
different detail files from multiple servers. It also means that the
session database ("radutmp", used for radwho and simultaneous use
detection) gets out of sync.
radrelay solves this issue by "relaying" packets from one server to
another, so they both have the same set of accounting data.
Similarly, you may have one database that tracks "live" sessions, and
another that tracks historical accounting data. In that case,
accessing the first database is fast, as it is small. Accessing the
second database many be slower, as it may contain multiple gigabytes
of data. In addition, writing to the first database in a timely
manner is important, while data may be written to the second database
with a few minutes delay, without any harm being done.
For example:
This configuration will cause accounting packets to be logged to the
${radacctdir}/radrelay/detail file. This file should not be
rotated by standard log rotation scripts, as the radrelay
program will read and rotate it.
To have the "radrelay" portion of the server read the above detail
file, configure radrelay.conf with the following section:
The server will read the accounting packets from the detail file, and
process them just as if it had received them from the NAS. Therefore,
you should configure the "accounting" section of radrelay.conf
to write the accounting records to an "sql" module, or to proxy them
to another RADIUS server.
Then, start the server via the following command:
$ radiusd -n radrelay
The server should start up, read the detail file, and process
accounting packets from it.
15 most recent posts on Irongeek.com:
|
If you would like to republish one of the articles from this site on your
webpage or print journal please contact IronGeek.
Copyright 2020, IronGeek
Louisville / Kentuckiana Information Security Enthusiast