Hi Guys I am wondering why our logs for proxied packets look like the following: Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (Home Server says so): [peter/peter] (from client NAS1 port 60000 cli XXXXXXXX) Wouldn't it be better for us to be a bit more concise about things? for example: Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (realm: myrealm proxy: myproxy): [peter/peter] (from client NAS1 port 60000 cli XXXXXXXX) I am doing crazy thing like: DEFAULT Called-Station-Id == "YYYYYY", Proxy-To-Realm := realm1 DEFAULT Called-Station-Id == "ZZZZZZZ", Proxy-To-Realm := realm2 Therefore, I am sure that you can see why this extra logging information would be usefull. (You can't tell the realm simply by looking at the username) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
Wouldn't it be better for us to be a bit more concise about things? for example:
Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (realm: myrealm proxy: myproxy): [peter/peter] (from client NAS1 port 60000 cli XXXXXXXX)
I am doing crazy thing like: DEFAULT Called-Station-Id == "YYYYYY", Proxy-To-Realm := realm1 DEFAULT Called-Station-Id == "ZZZZZZZ", Proxy-To-Realm := realm2
Therefore, I am sure that you can see why this extra logging information would be usefull. (You can't tell the realm simply by looking at the username)
Use the Source, Luke;) And I'm logging vendor attributes. (in order to identify misconfigured NASes; comes handy when you have 400+ NASes and 150k users) Makes me think about configurable logging. Like, configure log in such a way that it always logs defined attributes values, if exist. Guess people need logging in various places; i.e. important message for me is user not found in radgroupcheck. So with such a log both Peter and me would get our logging requirements satisfied:) ? Regards...
On Wed 09 Aug 2006 14:25, Josip Almasi wrote:
Peter Nixon wrote:
Wouldn't it be better for us to be a bit more concise about things? for example:
Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (realm: myrealm proxy: myproxy): [peter/peter] (from client NAS1 port 60000 cli XXXXXXXX)
I am doing crazy thing like: DEFAULT Called-Station-Id == "YYYYYY", Proxy-To-Realm := realm1 DEFAULT Called-Station-Id == "ZZZZZZZ", Proxy-To-Realm := realm2
Therefore, I am sure that you can see why this extra logging information would be usefull. (You can't tell the realm simply by looking at the username)
Use the Source, Luke;)
And I'm logging vendor attributes. (in order to identify misconfigured NASes; comes handy when you have 400+ NASes and 150k users) Makes me think about configurable logging. Like, configure log in such a way that it always logs defined attributes values, if exist. Guess people need logging in various places; i.e. important message for me is user not found in radgroupcheck. So with such a log both Peter and me would get our logging requirements satisfied:)
Hi Josip I am of course capable of "using the source" however before I start committing code changes to a part of the server that I don't normally play with I thought I would discuss it on the list. I was also thinking about configurable logging. We are currently patching FR to add the CalledStationID to the Auth logs also as that is important info to us. One of our deployments is at a GSM operator where the CalledStationID is the APN name of the GPRS network, and therefore peter connecting to APN "internet" is a different user than "peter" connecting to APN "wap" or APN "corporatecustomerX" This is actually a change that I think everyone else could benefit from, as well as the proxy logging change. (Clearer logs are always better) however having a way to turn attributes on and off in the logs is a nice idea. I have not committed either patch yet because log formats are a sensitive thing to change (You break people's monitoring systems..) Do you have a patch for configurable logging? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
Wouldn't it be better for us to be a bit more concise about things? for example:
Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (realm: myrealm proxy: myproxy): [peter/peter] (from client NAS1 port 60000 cli XXXXXXXX)
Yeah, we do similar things, but worse! I hate legacy systems! I've modified our source so that it puts the Reply-Message (if it exists) in the Login incorrect message. eg: Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (Home server says so: Account Disabled) [peter] (from client NAS1 port 60000 cli XXXXXXXX) As we migrate away from legacy systems it gives us a single point of reference for authentication success/failures and the reasons. I think it could be very handy to have this log message more configurable, but I'm not sure what overhead that would add, its at least another call to xlat, and on a busy system this log is written out a lot! cheers, Mike
On Thu 10 Aug 2006 13:52, Mike Mitchell wrote:
Peter Nixon wrote:
Wouldn't it be better for us to be a bit more concise
about things? for
example:
Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (realm:
myrealm proxy:
myproxy): [peter/peter] (from client NAS1 port 60000 cli XXXXXXXX)
Yeah, we do similar things, but worse! I hate legacy systems!
I've modified our source so that it puts the Reply-Message (if it exists) in the Login incorrect message. eg:
Mon Aug 7 20:18:40 2006 : Auth: Login incorrect (Home server says so: Account Disabled) [peter] (from client NAS1 port 60000 cli XXXXXXXX)
As we migrate away from legacy systems it gives us a single point of reference for authentication success/failures and the reasons.
I think it could be very handy to have this log message more configurable, but I'm not sure what overhead that would add, its at least another call to xlat, and on a busy system this log is written out a lot!
Heh. Yeah. Well, in my case they are customers not legacy systems. We are basically acting as a AAA clearing house (or something). I think such a patch certainly bears testing. The more relevant info you can give to an admin, the better he can do his job, and faster machines are cheaper than more admins! In any case I have not so far ever managed to stress FreeRADIUS... It's always been the backend that is working hard, not radiusd which rarely takes more than 1% of CPU. In a pure proxy environment that of course doesn't apply, but given that the SunFire (Opteron) boxes I use only run about $1000, adding an extra 2 (or 10) doesn't really cost allot. (Adding new database servers on the other hand is a different matter) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
This is actually a change that I think everyone else could benefit from, as well as the proxy logging change. (Clearer logs are always better) however having a way to turn attributes on and off in the logs is a nice idea.
I have not committed either patch yet because log formats are a sensitive thing to change (You break people's monitoring systems..)
Do you have a patch for configurable logging?
No but I'll write one. I introduced a number of changes to freeradius to satisfy my requirements. But all were done on 1.0.1 source. As it was one of requirements:) Now I'm thinking of ways to introduce these to future freeradius releases. Regards...
participants (3)
-
Josip Almasi -
Mike Mitchell -
Peter Nixon