On Tue, Dec 23, 2014 at 11:05:23AM -0500, Alan DeKok wrote:
That’s not really the intended use of the “linelog” module. It logs lines of text.. not multiple lines.
Of course, "intended" and "what's useful" are two different things. We're also (ab-)using linelog to write out detail log format. These are then picked up by the detail reader and fed (as accounting packets) across to a central RADIUS server for common logging. It means we can set exactly which attributes to forward. Because of the way the logging and detail reader works it is also reliable if the central server goes away for some reason. I guess the alternative would be to have an "include" option for the detail module, countering the "suppress" option. But that's only for our use case.
Not with 3.0.6. We can take a look at correcting it for the next release. We’ve made other fixes in 3.0 which made it easier to separate the “literal” strings passed in from the config files, and the “end user” strings taken from a RADIUS packet. We can have the linelog module convert \n -> CR for literal strings you enter, but not do that expansion for strings taken from RADIUS packets.
That would seem the more sensible option - expand \n, \t etc in the string first, then expand %{..}. But I get that string expansion is pretty tricky in the ordering it needs to be done to get a sane output for all cases. Cheers Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>