On Fri 18 May 2007, Guy Fraser wrote:
On Fri, 2007-05-18 at 17:09 +0200, Jack J Allan wrote:
On 5/18/07, Brian A. Seklecki <lavalamp@spiritual-machines.org> wrote: Another solution would be to perform logging via syslog(3), which absolves radiusd from trapping and handling signals and file handlers. Syslog-ng already does this very well -- why duplicate all of that code? ~BAS
I've certainly looked at that possibility, the problem is that you cannot separate your logging components nicely. I'd like to separate my radius.log, sqltrace, detail logfiles per nas and all that. I'm afraid that syslog can't do that and you'll run out of log facilities very quickly if you decided to do it manually ( e.g. one facility per logfile).
I found a workaround (no HUP) so I'm happy.
Jack
I have not checked in quite a while, but at one point a while back, I suggested using configurable dynamic log file names, like the detail files have. I used to use such a beast on a version of Cistron Radius that I customized, but I ran into problems trying to make it work with FR because if I remember correctly, and it is quite possible I do not, there was some kind of problem I ran into where the "Xlate" function did not generate what I expected when it had insufficient data to resolve the log file "name" due to the type of error. Having the configurable logging was low on my list of priorities back then and has not become any more important as of now, but it would still be a nice feature if their was a way to use defaults using "{{variable}:-default}" type entries.
I second this.. But its a low priority.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc