Re: radius.log on DB
On 25.03.2013 09:26, AemNet wrote: Hi everybody is there any way log the requests for the radius in a DB like MySQL? In other words is possible to put radius.log entry in a DB without use the local system syslog daemon? This is not possible directly from freeradius. What you can do, is tell FreeRadius to log to your syslog deamon (like syslog-ng) and then tell syslog-ng to write the log within an INSERT statement for your database. Then you can send this to your database. Those two links might help you : http://wiki.freeradius.org/guide/Syslog-HOWTO http://vermeer.org/docs/1 But this is beyond the scope of the freeradius list Olivier - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log on DB
On 25/03/2013 11:05, Olivier Beytrison wrote: This is not possible directly from freeradius. What you can do, is tell FreeRadius to log to your syslog deamon (like syslog-ng) and then tell syslog-ng to write the log within an INSERT statement for your database. Then you can send this to your database. Those two links might help you : http://wiki.freeradius.org/guide/Syslog-HOWTO http://vermeer.org/docs/1 But this is beyond the scope of the freeradius list Olivier - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thank you for the answer and for the links Olivier, but I prefer don't use the syslog system if it's possilbe. Do you think it's possible instead to use a script (perl/bash anything else) after the request arrive and put it in a DB? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log on DB
I the past I've tail'd a log file ( this was for squid and not freeradius) and piped that into a perl script that would then write things into a database but it's a lot easier using syslog talking to an rsyslog back end database that writes things into a database for you. Rgds alex On 25 Mar 2013, at 10:45, AemNet sysadmin-aem...@aemnet.it wrote: On 25/03/2013 11:05, Olivier Beytrison wrote: This is not possible directly from freeradius. What you can do, is tell FreeRadius to log to your syslog deamon (like syslog-ng) and then tell syslog-ng to write the log within an INSERT statement for your database. Then you can send this to your database. Those two links might help you : http://wiki.freeradius.org/guide/Syslog-HOWTO http://vermeer.org/docs/1 But this is beyond the scope of the freeradius list Olivier - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thank you for the answer and for the links Olivier, but I prefer don't use the syslog system if it's possilbe. Do you think it's possible instead to use a script (perl/bash anything else) after the request arrive and put it in a DB? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log on DB
Hi, Thank you for the answer and for the links Olivier, but I prefer don't use the syslog system if it's possilbe. Do you think it's possible instead to use a script (perl/bash anything else) after the request arrive and put it in a DB? the SQL module has the psotauth table... you could always create your own table, then use unlang to populate it with whatever you want in the post-auth section of the server - for accept or reject packets. that wont log ALL that might appear in radiusd logfile (eg server messages) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log on DB
Perl File::Tail works very well for things like this... On Mon, Mar 25, 2013 at 12:45 PM, AemNet sysadmin-aem...@aemnet.it wrote: On 25/03/2013 11:05, Olivier Beytrison wrote: This is not possible directly from freeradius. What you can do, is tell FreeRadius to log to your syslog deamon (like syslog-ng) and then tell syslog-ng to write the log within an INSERT statement for your database. Then you can send this to your database. Those two links might help you : http://wiki.freeradius.org/**guide/Syslog-HOWTOhttp://wiki.freeradius.org/guide/Syslog-HOWTO http://vermeer.org/docs/1 But this is beyond the scope of the freeradius list Olivier - List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html http://www.freeradius.org/list/users.html Thank you for the answer and for the links Olivier, but I prefer don't use the syslog system if it's possilbe. Do you think it's possible instead to use a script (perl/bash anything else) after the request arrive and put it in a DB? - List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html http://www.freeradius.org/list/users.html -- Regards, Chris Knipe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log on DB
On 25.03.2013 11:45, AemNet wrote: Thank you for the answer and for the links Olivier, but I prefer don't use the syslog system if it's possilbe. Do you think it's possible instead to use a script (perl/bash anything else) after the request arrive and put it in a DB? You could make a perl script which pipe the freeradius log file and then insert the text into a DB. But again that's beyond the scope of this list. Freeradius doesn't offer the ability to put the log file into a DB. Olivier B. -- Olivier Beytrison Network Security Engineer, HES-SO Fribourg Mail: oliv...@heliosnet.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log rotation
On Thu, Mar 15, 2012 at 11:21 AM, Shreya Shah shreya.ns...@gmail.com wrote: Hi, How can we rotate radius.log file ? Depends on how you installed it. Distro-bundled ones should already have a log rotate config setup on /etc/logrotate.d. If you install it from source, see the included examples on source tarball. For example, redhat/freeradius-logrotate -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log test?
hi, All seems well besides this. It started happening a day ago every 30 seconds. Anyone understand what this is? check your changelog or revision control notes to see waht was done a day ago? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radius.log test?
Thanks for that, rather odd, I ran radius -X and found the location the request was coming from, it was one of our pc's which must have been running a test in the background, a reboot turned it off. cheers Regards Carl - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log records individual client IP. Possible??
Difan Zhao wrote: I’m wondering if it’s possible for the radius.log file to show the NAS IP instead of the “client” name (which is IP range in my case). Read radiusd.conf, look for msg_goodpass Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log with timestamp in filename
RadiusGuy wrote:
In good faith I have tried the same thing with the radius.log...
file = ${logdir}/radius.log-%Y%m%d
but it didn't work. Freeradius then creates a logfile with the explicit name
radius.log-%Y%m%d, but not with the timestamp of the actual day. Can anyone
help?
Write a cron job to rename the file.
Dynamically expanding the filename for *every* log message is an
enormous waste of time. The filename changes only once a day, so it
should be renamed only once a day.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
John Dennis wrote: FWIW, in our RPM's we force the creation of the radius.log file with ownership radiusd:radiusd at installation time before the server even runs. This should also be in the /etc/init.d/radiusd script. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
Philip Molter wrote: Attached is a patch that fixes the issue. Given the way that freeradius checks for the ability to write to the logfile, it should perform like the latter (in my testing, it does exactly that). The patch does a couple of things: 1) properly handles setuid changes in early configuration times OK. 2) enables fr_suid_down/up/down_permanently noop calls so that compile works when HAVE_SETUID is not defined That's needed, yes. I've committed a fix based on this that: a) does suid down earlier b) lets it build when HAVE_SETUID is not defined c) calls chown() on the log file to ensure it has the correct owner Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
Alan DeKok wrote: Philip Molter wrote: Attached is a patch that fixes the issue. Given the way that freeradius checks for the ability to write to the logfile, it should perform like the latter (in my testing, it does exactly that). The patch does a couple of things: 1) properly handles setuid changes in early configuration times OK. 2) enables fr_suid_down/up/down_permanently noop calls so that compile works when HAVE_SETUID is not defined That's needed, yes. I've committed a fix based on this that: a) does suid down earlier b) lets it build when HAVE_SETUID is not defined c) calls chown() on the log file to ensure it has the correct owner Thanks Alan. I'll point out the HAVE_SETUID ifdef used within the switch_users() function is redundant. The entire function is wrapped in HAVE_SETUID. Philip - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
Hi, Is this a known bug? Is there a workaround other than creating the file by hand and setting its ownership before starting freeradius? ?? how are you starting this server - the file/directory should be radiusd:radiusd and when run it will do the 'correct thing' alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
On Jul 16, 2009, at 4:03 AM, a.l.m.bu...@lboro.ac.uk wrote: Hi, Is this a known bug? Is there a workaround other than creating the file by hand and setting its ownership before starting freeradius? ?? how are you starting this server - the file/directory should be radiusd:radiusd and when run it will do the 'correct thing' /usr/sbin/radiusd -d /etc/raddb as user root. As posted before, the config file has directives to switch to user radiusd and group radiusd The directory has the proper permissions, but the radius.log file doesn't exist. When the radiusd program starts up, it creates the radius.log file in the proper directory, but the file has 0640 permissions owned by user root, group radiusd. I know that it SHOULD BE radiusd:radiusd. It is not doing the correct thing. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
On 07/16/2009 08:12 AM, Philip Molter wrote: On Jul 16, 2009, at 4:03 AM, a.l.m.bu...@lboro.ac.uk wrote: Hi, Is this a known bug? Is there a workaround other than creating the file by hand and setting its ownership before starting freeradius? ?? how are you starting this server - the file/directory should be radiusd:radiusd and when run it will do the 'correct thing' /usr/sbin/radiusd -d /etc/raddb as user root. As posted before, the config file has directives to switch to user radiusd and group radiusd The directory has the proper permissions, but the radius.log file doesn't exist. When the radiusd program starts up, it creates the radius.log file in the proper directory, but the file has 0640 permissions owned by user root, group radiusd. FWIW, in our RPM's we force the creation of the radius.log file with ownership radiusd:radiusd at installation time before the server even runs. If you don't force the creation of the file with the right ownership then I think the issue revolves around when a log message is first emitted. The log file gets created the first time a log message is emitted. The server starts as root. During it's initialization phase it raises and lowers it's operating permissions between the root and radiusd user identity via the fr_suid_up() and fr_suid_down() calls. When it gets ready to process events it settles down to radiusd via fr_suid_down_permanent(). If the first log message occurs when the server is in a fr_suid_up() mode (e.g. running as root instead of as radiusd) then you'll get the behavior you've seen. The code paths are way to complicated for static analysis to see if and when a log message might be emitted the server is in a high privilege mode. It does seem like it might happen if you start the server in debug mode because the server is much more verbose. There are various strategies to assure the newly created log file has the right ownership: * drop privileges prior to calling fopen() * call chown() after fclose() at the exit of the logging call. * pre-create the file if necessary very early during start up. I think the latter is preferable as it avoid the expense of setting or checking for the right ownership for every log message emitted (ouch). -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
John Dennis wrote: FWIW, in our RPM's we force the creation of the radius.log file with ownership radiusd:radiusd at installation time before the server even runs. If you don't force the creation of the file with the right ownership then I think the issue revolves around when a log message is first emitted. The log file gets created the first time a log message is emitted. The server starts as root. During it's initialization phase it raises and lowers it's operating permissions between the root and radiusd user identity via the fr_suid_up() and fr_suid_down() calls. When it gets ready to process events it settles down to radiusd via fr_suid_down_permanent(). The problem is commit 047fe5ca74e3de2c7f32f98154d6655c0cfd7181. Before this commit, in switch_users(), permissions were unconditionally dropped if a user setting was specified, and the 'did_setuid' boolean was set no matter what if setuid capability was even possible (ie. even if a user name wasn't specified, did_setuid was set to true). After this commit, the permission drop was abstracted into fr_suid_down(), which checks did_setuid before it does anything. Since did_setuid isn't set, fr_suid_down() doesn't do anything. After that call, did_setuid is set to TRUE, so future calls to fr_suid_down() work as expected, but all of the time spent between the code there and the code in listen.c is run as root, including a check to see if the directory is writable that immediately follows setuid in switch_users(). Previous to that commit, that wasn't the behavior. Basically, that code is the problem. I'll try to submit a patch later today that fixes the problem. Yes, if an error occurs, there are log messages that get generated before suid operations, but as far as I can tell, they're related to fatal errors or debug messages. There are various strategies to assure the newly created log file has the right ownership: * drop privileges prior to calling fopen() * call chown() after fclose() at the exit of the logging call. * pre-create the file if necessary very early during start up. I think the latter is preferable as it avoid the expense of setting or checking for the right ownership for every log message emitted (ouch). The latter is basically what happens, because in switch_users(), the daemon tries to make sure it can write to the file as the user it is. If the file exists, it's a simple append. If the file doesn't exist, it creates it. If it can't write, it bails. Like I said, it just isn't the user it thinks it is when this is called (mainconfig.c:629, version 2.1.6). Philip - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log permissions issue
John Dennis wrote:
There are various strategies to assure the newly created log file has
the right ownership:
* drop privileges prior to calling fopen()
* call chown() after fclose() at the exit of the logging call.
* pre-create the file if necessary very early during start up.
I think the latter is preferable as it avoid the expense of setting or
checking for the right ownership for every log message emitted (ouch).
Attached is a patch that fixes the issue. Given the way that freeradius
checks for the ability to write to the logfile, it should perform like
the latter (in my testing, it does exactly that).
The patch does a couple of things:
1) properly handles setuid changes in early configuration times
2) enables fr_suid_down/up/down_permanently noop calls so that compile
works when HAVE_SETUID is not defined
Philip
diff -urNp a/src/main/mainconfig.c b/src/main/mainconfig.c
--- a/src/main/mainconfig.c 2009-05-18 06:13:55.0 -0500
+++ b/src/main/mainconfig.c 2009-07-16 10:39:34.0 -0500
@@ -78,7 +78,7 @@ static cached_config_t*cs_cache = NULL;
/*
* Systems that have set/getresuid also have setuid.
*/
-uid_t server_uid;
+static uid_t server_uid;
static gid_t server_gid;
static const char *uid_name = NULL;
static const char *gid_name = NULL;
@@ -413,9 +413,9 @@ static int r_mkdir(const char *part)
#ifdef HAVE_SETUID
-int did_setuid = FALSE;
+static int has_setuid = FALSE;
-#if defined(HAVE_SETRESUID) defined (HAVE_GETRESUID)
+#if defined(HAVE_SETRESUID) defined(HAVE_GETRESUID)
void fr_suid_up(void)
{
uid_t ruid, euid, suid;
@@ -438,7 +438,7 @@ void fr_suid_up(void)
void fr_suid_down(void)
{
- if (!did_setuid) return;
+ if (!has_setuid) return;
if (setresuid(-1, server_uid, geteuid()) 0) {
fprintf(stderr, %s: Failed switching to uid %s: %s\n,
@@ -457,12 +457,7 @@ void fr_suid_down_permanent(void)
{
uid_t ruid, euid, suid;
- if (!did_setuid) return;
-
- if (getresuid(ruid, euid, suid) 0) {
- radlog(L_ERR, Failed getting saved uid's);
- _exit(1);
- }
+ if (!has_setuid) return;
if (setresuid(server_uid, server_uid, server_uid) 0) {
radlog(L_ERR, Failed in permanent switch to uid %s: %s,
@@ -474,13 +469,6 @@ void fr_suid_down_permanent(void)
radlog(L_ERR, Switched to unknown uid);
_exit(1);
}
-
-
- if (getresuid(ruid, euid, suid) 0) {
- radlog(L_ERR, Failed getting saved uid's: %s,
- strerror(errno));
- _exit(1);
- }
}
#else
/*
@@ -491,7 +479,7 @@ void fr_suid_up(void)
}
void fr_suid_down(void)
{
- if (!uid_name) return;
+ if (!has_setuid) return;
if (setuid(server_uid) 0) {
fprintf(stderr, %s: Failed switching to uid %s: %s\n,
@@ -502,8 +490,20 @@ void fr_suid_down(void)
void fr_suid_down_permanent(void)
{
}
-#endif
+#endif /* HAVE_SETRESUID HAVE_GETRESUID */
+#else
+void fr_suid_up(void)
+{
+}
+void fr_suid_down(void)
+{
+}
+void fr_suid_down_permanent(void)
+{
+}
+#endif /* HAVE_SETUID */
+#ifdef HAVE_SETUID
/*
* Do chroot, if requested.
*
@@ -609,13 +609,8 @@ static int switch_users(CONF_SECTION *cs
#ifdef HAVE_PWD_H
if (uid_name) {
+ has_setuid = TRUE;
fr_suid_down();
-
- /*
-* Now core dumps are disabled on most secure systems.
-*/
-
- did_setuid = TRUE;
}
#endif
@@ -657,7 +652,7 @@ static int switch_users(CONF_SECTION *cs
* Otherwise, disable core dumps for security.
*
*/
- if (!(debug_flag || allow_core_dumps || did_setuid)) {
+ if (!(debug_flag || allow_core_dumps || has_setuid)) {
#ifdef HAVE_SYS_RESOURCE_H
struct rlimit no_core;
@@ -676,7 +671,7 @@ static int switch_users(CONF_SECTION *cs
* running as a daemon, AND core dumps are
* allowed, AND we changed UID's.
*/
- } else if ((debug_flag == 0) allow_core_dumps did_setuid) {
+ } else if ((debug_flag == 0) allow_core_dumps has_setuid) {
/*
* Set the dumpable flag.
*/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log not working
Hi, please do not mail in HTML - look at this junk and the size of the email! html xmlns:v=urn:schemas-microsoft-com:vml xmlns:o=urn:schemas-microsoft-com:office:office xmlns:w=urn:schemas-microsoft-com:office:word xmlns:m=http://schemas.microsoft.com/office/2004/12/omml; xmlns=http://www.w3.org/TR/REC-html40; snip! Free radius is accepting requests and everything is working as it should except that the radius.log is not propagating.nbsp; I changed the IP address of the server and moved it to a new location.nbsp; The portmasters are authenticating to it and I see the requests coming in under radius #8211;X however radius.log has not changed since the move.nbsp; I am not sure where else to look I have googled this tonbsp; no avail. Any help would be greato:p/o:p/p there. thats all the text that needs to be in the email. have you checked file permissions and the real radiusd.conf - what does radiusd -x (small x!) giv you when it runs? FR wont put anything into radiusd.log whilst in -X mode (all the output goes to the debug output!) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radius.log not working
Sorry about the HTML and that did it I did not realize that when in -x it did not write to the log as well. Thank you Thank you for choosing -- Michael J Humphries Penstar Office Center, Suite 101 1431 N. 26th Street Escanaba, MI 49829 Phone: 906.786.3583 ext. 139 Fax: 906.786.4300 E-Mail: mhumphr...@dstech.us www.dstech.us -Original Message- From: freeradius-users-bounces+mhumphries=dstech...@lists.freeradius.org [mailto:freeradius-users-bounces+mhumphries=dstech...@lists.freeradius.org] On Behalf Of a.l.m.bu...@lboro.ac.uk Sent: Tuesday, July 07, 2009 1:10 PM To: FreeRadius users mailing list Subject: Re: radius.log not working Hi, please do not mail in HTML - look at this junk and the size of the email! html xmlns:v=urn:schemas-microsoft-com:vml xmlns:o=urn:schemas-microsoft-com:office:office xmlns:w=urn:schemas-microsoft-com:office:word xmlns:m=http://schemas.microsoft.com/office/2004/12/omml; xmlns=http://www.w3.org/TR/REC-html40; snip! Free radius is accepting requests and everything is working as it should except that the radius.log is not propagating.nbsp; I changed the IP address of the server and moved it to a new location.nbsp; The portmasters are authenticating to it and I see the requests coming in under radius #8211;X however radius.log has not changed since the move.nbsp; I am not sure where else to look I have googled this tonbsp; no avail. Any help would be greato:p/o:p/p there. thats all the text that needs to be in the email. have you checked file permissions and the real radiusd.conf - what does radiusd -x (small x!) giv you when it runs? FR wont put anything into radiusd.log whilst in -X mode (all the output goes to the debug output!) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radius.log question
Most likely, the user did not enter a password to be sent. Thus no User-Password attribute. -Original Message- From: [EMAIL PROTECTED] [mailto:freeradius- [EMAIL PROTECTED] On Behalf Of Edgars Sent: Wednesday, October 13, 2004 8:08 AM To: [EMAIL PROTECTED] Subject: radius.log question Hello! i can't find out why the following sentance is appearing in the line below - ...no User-Password attribute: Auth: Login OK: [a/no User-Password attribute] (from client uz galda port 12534 cli 1.1.1.2) Edgars - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log question
but the user is using a password for authentication.. Edgars Anson Rinesmith wrote: Most likely, the user did not enter a password to be sent. Thus no User-Password attribute. -Original Message- From: [EMAIL PROTECTED] [mailto:freeradius- [EMAIL PROTECTED] On Behalf Of Edgars Sent: Wednesday, October 13, 2004 8:08 AM To: [EMAIL PROTECTED] Subject: radius.log question Hello! i can't find out why the following sentance is appearing in the line below - ...no User-Password attribute: Auth: Login OK: [a/no User-Password attribute] (from client uz galda port 12534 cli 1.1.1.2) Edgars - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log question
Edgars [EMAIL PROTECTED] wrote: but the user is using a password for authentication.. Yes, but they are not sending that password to the RADIUS server, as there is no User-Password attribute in the RADIUS packet. The user is typing a password into a window on their computer. Their computer is using that password to do all sorts of work, but it does NOT send the password to anyone. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log file showing proxy not server
In the /var/log/radius.log [EMAIL PROTECTED] squid]# tail -n34 /var/log/radius.log Tue Jul 6 08:07:42 2004 : Auth: Login OK: [tango] (from client 196.26.5.5 port 148 cli 033xxx) Tue Jul 6 08:07:55 2004 : Auth: Login OK: [dbarker] (from client 196.26.5.5 port 214 cli 039xxx) Tue Jul 6 08:08:54 2004 : Auth: Login OK: [gringo] (from client 196.26.5.5 port 20217 cli 039xxx) Tue Jul 6 08:09:44 2004 : Auth: Login OK: [gringo] (from client 196.26.5.5 port 20329 cli 039xxx) Tue Jul 6 08:10:53 2004 : Auth: Login OK: [jaco] (from client 196.26.208.10 port 1847) Tue Jul 6 08:11:39 2004 : Auth: Login OK: [mbarrow] (from client 196.26.208.10 port 186 cli 039xxx) 196.25.5.5 and 196.26.208.10 are the proxying servers, I need it to reflect the actual dial-in box the client connected to. Alan DeKok wrote: Peter Kolbe [EMAIL PROTECTED] wrote: I am running freeradius freeradius-1.0.0-pre3 I want the /var/log/radius log to reflect NAS-IP-Address (or ideally nas FQDN name) not the Client-IP-Address. In what messages? There are a lot of messages printed out by the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log file showing proxy not server
Peter Kolbe [EMAIL PROTECTED] wrote: Tue Jul 6 08:11:39 2004 : Auth: Login OK: [mbarrow] (from client 196.26.208.10 port 186 cli 039xxx) 196.25.5.5 and 196.26.208.10 are the proxying servers, I need it to reflect the actual dial-in box the client connected to. Those log messages are not currently configurable. You can change them via source code modifications. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log file showing proxy not server
Peter Kolbe [EMAIL PROTECTED] wrote: I am running freeradius freeradius-1.0.0-pre3 I want the /var/log/radius log to reflect NAS-IP-Address (or ideally nas FQDN name) not the Client-IP-Address. In what messages? There are a lot of messages printed out by the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log rotate?
Guy,
That would be a really neat feature for us, too.
If you're considering implementing it, I have a feature request: it
would be great if there was also the option to have a complete
logfile containing all realms, in addition to the broken-out files.
This would allow for easier debugging (i.e. if you suspect a user is
mistyping their realm and don't want to have to tail 5 files to
check).
Thanks,
Alex
At 5:47 PM -0700 13/02/2004, Guy Fraser wrote:
The reason I am considering this feature, is that some people have
asked for it
and I work for an ISP that administrates other smaller ISP's. I have
been asked
in the past to give access to people in affialiated ISP's, but they
only want to
see traffic for their realm. A log file named like :
%L/%{Realm}/%Y%m%d.log
That translates to:
/path/to/logdir/SomeISP.com/20040213.log
Would make it possible to do, and files would be renamed on the fly.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log rotate?
Anson Rinesmith wrote: Does the radius.log file rotate when it gets large? If not, has anyone written a script to do this? Thanks, Anson I have been meaning to look into having the log file dynamically named. I made a patch for Cistron Radius that dynamically named. Example: /var/log/radius/%Y%b%d.log Today's file is : /var/log/radius/2004Feb13.log I will look at this issue, and try to get the patch into CVS. Hopfully the patch will make it into CVS before v1.0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radius.log rotate?
I found that for now the easiest way for me is to edit newsyslog.conf (FreeBSD 4.6) and add that file in there. Works pretty well so far. -Original Message- From: [EMAIL PROTECTED] [mailto:freeradius- [EMAIL PROTECTED] On Behalf Of Guy Fraser Sent: Friday, February 13, 2004 11:33 AM To: [EMAIL PROTECTED] Subject: Re: radius.log rotate? Anson Rinesmith wrote: Does the radius.log file rotate when it gets large? If not, has anyone written a script to do this? Thanks, Anson I have been meaning to look into having the log file dynamically named. I made a patch for Cistron Radius that dynamically named. Example: /var/log/radius/%Y%b%d.log Today's file is : /var/log/radius/2004Feb13.log I will look at this issue, and try to get the patch into CVS. Hopfully the patch will make it into CVS before v1.0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log rotate?
Anson Rinesmith wrote:
I found that for now the easiest way for me is to edit newsyslog.conf
(FreeBSD 4.6) and add that file in there. Works pretty well so far.
Absolutely.
After spending a while reading the code in CVS, I have determined it
will take
a bit of work to have dynamically named log files. In order to make it work
consistantly with the rest of FreeRadius I am considering a rlm_log feature.
This rlm_log feature would be similar to rlm_detail in naming
convention, but
one significant difference. Some information will not have a radius request
associated with it, so it will have to have a system log, where that
type of
data will be located.
The reason I am considering this feature, is that some people have asked
for it
and I work for an ISP that administrates other smaller ISP's. I have
been asked
in the past to give access to people in affialiated ISP's, but they only
want to
see traffic for their realm. A log file named like :
%L/%{Realm}/%Y%m%d.log
That translates to:
/path/to/logdir/SomeISP.com/20040213.log
Would make it possible to do, and files would be renamed on the fly.
Well, it's Friday night and I'm an hour past going home time, so I'll
get back
to this on Tuesday {Monday is a holiday :-)}.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radius.log
Alan, Would you be willing to work with me some off the mailing list? -Original Message- From: [EMAIL PROTECTED] [mailto:freeradius- [EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: Monday, January 26, 2004 1:17 PM To: [EMAIL PROTECTED] Subject: Re: radius.log Anson Rinesmith [EMAIL PROTECTED] wrote: Can you think of a way to pull certain information from the radius.log file? grep? I proxy to my realms based on Called-Station-ID. Each ISP that would dial into the NAS would like to see their own error log? Anyone tinkered with this successfully, even mildly? Not so far. I would be willing to poke at the code and recompile if necessary, but that is certainly not my forte. It shouldn't be too hard to do. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log
Anson Rinesmith [EMAIL PROTECTED] wrote: Would you be willing to work with me some off the mailing list? Yup. Mail me at privately. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius.log
This may be possible with webmin as well.
You could make a cutom command for each 'ISP' that would grep the log
file for their realm and return matched sets of data.
I use something like this for my non technical staff to find customer
info in the log file.
One of these days I will stat looking into fixing the way the log file
is created so that the logfile can be dated, at that time I may see if
it would be feasible to extend the functionality to allow seperate logs
per realm and/or DSN{Dialed Station Number.}
I have been patiently waiting for my dialup admin/bin patches to be
applied to CVS. I don't like to have to layer my patches onto the
current CVS, while doing additional development. Since my Customized
Cistron still works flawlessly, I am not under a lot of preasure to
switch to FreeRadius, so as time permits I have been helping with the
PostgreSQL features. The custom log file naming is one of the feature I
will need before I can implement FreeRadius, so eventualy I will be
looking at it, if someone else doesn't beat me to it.
I have been busy with other DB + PHP projects lately. One of the PHP
functions I have written recently may be able to be enhaced to provide
an html table of results parsed from the log file. I am interested to
try it, when I get a chance.
Good Luck
Anson Rinesmith wrote:
Alan,
Would you be willing to work with me some off the mailing list?
-Original Message-
From: [EMAIL PROTECTED] [mailto:freeradius-
[EMAIL PROTECTED] On Behalf Of Alan DeKok
Sent: Monday, January 26, 2004 1:17 PM
To: [EMAIL PROTECTED]
Subject: Re: radius.log
Anson Rinesmith [EMAIL PROTECTED] wrote:
Can you think of a way to pull certain information from the radius.log
file?
grep?
I proxy to my realms based on Called-Station-ID. Each ISP that would
dial
into the NAS would like to see their own error log? Anyone tinkered with
this successfully, even mildly?
Not so far.
I would be willing to poke at the code and recompile if necessary, but
that is certainly not my forte.
It shouldn't be too hard to do.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Guy Fraser
Network Administrator
The Internet Centre
780-450-6787 , 1-888-450-6787
There is a fine line between genius and lunacy, fear not, walk the
line with pride. Not all things will end up as you wanted, but you
will certainly discover things the meek and timid will miss out on.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radius.log
Anson Rinesmith [EMAIL PROTECTED] wrote: Can anyone tell me where the radius.log file is configured? $ grep radius.log /etc/raddb/* I know where the file is I would like to have a file for each realm. That is not currently supported. Can you think of a way to pull certain information from the radius.log file? I proxy to my realms based on Called-Station-ID. Each ISP that would dial into the NAS would like to see their own error log? Anyone tinkered with this successfully, even mildly? I would be willing to poke at the code and recompile if necessary, but that is certainly not my forte. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
