rlm_detail header not expanding \t
In v2 I do: detail { ... header = "%t\t%{Client-IP-Address}" ... } which gives e.g. Wed Sep 9 16:55:16 2015 127.0.0.1 ... in the detail file. Building a config for v3, the same gives: Wed Sep 9 16:55:16 2015127.0.0.1 i.e. the \t is silently discarded and expands to nothing. I can get around it by putting a physical tab char in the config, but is this intended? Have stared at the radius_xlat code for too many minutes and figured it'd be quicker to ask... :) 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>
On Sep 9, 2015, at 12:07 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:\
i.e. the \t is silently discarded and expands to nothing.
You probably need: header = '%t\t%{Client-IP-Address}'
I can get around it by putting a physical tab char in the config, but is this intended?
It's probably a side effect of us re-doing all of the escaping rules. i.e. fixing them so they're consistent, documented, and tested.
Have stared at the radius_xlat code for too many minutes and figured it'd be quicker to ask... :)
That code is magic. Magically confusing. :( Alan DeKok.
On Wed, Sep 09, 2015 at 12:21:34PM -0400, Alan DeKok wrote:
On Sep 9, 2015, at 12:07 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:\
i.e. the \t is silently discarded and expands to nothing.
You probably need:
header = '%t\t%{Client-IP-Address}'
That doesn't work either, unfortunately.
I can get around it by putting a physical tab char in the config, but is this intended?
It's probably a side effect of us re-doing all of the escaping rules.
I figured. I just found that with correct_escapes set to false, it *does* work.
Have stared at the radius_xlat code for too many minutes and figured it'd be quicker to ask... :)
That code is magic. Magically confusing. :(
"Magic" wasn't quite the word I was thinking. But is still cleaner than a lot of the code on the Internet... 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>
On 9 Sep 2015, at 17:30, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Wed, Sep 09, 2015 at 12:21:34PM -0400, Alan DeKok wrote:
On Sep 9, 2015, at 12:07 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:\
i.e. the \t is silently discarded and expands to nothing.
You probably need:
header = '%t\t%{Client-IP-Address}'
That doesn't work either, unfortunately.
Weird that it gets nommed. Don't suppose you want to try with v3.1.x? :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Wed, Sep 09, 2015 at 05:34:18PM +0100, Arran Cudbard-Bell wrote:
header = '%t\t%{Client-IP-Address}'
That doesn't work either, unfortunately.
Weird that it gets nommed.
Don't suppose you want to try with v3.1.x? :)
Yeah, I'll try. Getting distracted enough from what I'm supposed to be doing at the moment... every time I touch FreeRADIUS I do more work on FR itself than my intended task. :) 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>
On 9 Sep 2015, at 17:40, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Wed, Sep 09, 2015 at 05:34:18PM +0100, Arran Cudbard-Bell wrote:
header = '%t\t%{Client-IP-Address}'
That doesn't work either, unfortunately.
Weird that it gets nommed.
Don't suppose you want to try with v3.1.x? :)
Yeah, I'll try. Getting distracted enough from what I'm supposed to be doing at the moment... every time I touch FreeRADIUS I do more work on FR itself than my intended task. :)
Well you are an honorary core team member ;) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sep 9, 2015, at 12:30 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I just found that with correct_escapes set to false, it *does* work.
Ugh.
"Magic" wasn't quite the word I was thinking. But is still cleaner than a lot of the code on the Internet...
Yes. And with test cases! Now with a fix, and more test cases to catch this issue. :) Try the v3.0.x branch. Alan DeKok.
On Wed, Sep 09, 2015 at 01:41:51PM -0400, Alan DeKok wrote:
On Sep 9, 2015, at 12:30 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I just found that with correct_escapes set to false, it *does* work.
Ugh. ... Now with a fix, and more test cases to catch this issue. :) Try the v3.0.x branch.
Thanks - better than before, but not what I was expecting. Now "\" is always literal: "%t\t...", '%t\t...' with correct_escapes set to either true or false always outputs: Wed Sep 9 22:17:14 2015\t127.0.0.1 But at least it's consistent :) Matthew (now hacking on a debian packaging / certs/Makefile issue...) -- 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>
On Wed, Sep 09, 2015 at 10:22:04PM +0100, Matthew Newton wrote:
(now hacking on a debian packaging / certs/Makefile issue...)
Which seems to be a non-issue after all, thankfully. Somehow (and I don't know how) server.csr, server.p12 and server.crt got truncated after an apt-get install / purge remove / install. make server.vrfy fails rather spectacularly in that condition... Removing /etc/freeradius/certs then several install/purge remove/installs later and I can't reproduce it, so probably nothing after all. 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>
On 9 Sep 2015, at 22:22, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Wed, Sep 09, 2015 at 01:41:51PM -0400, Alan DeKok wrote:
On Sep 9, 2015, at 12:30 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
I just found that with correct_escapes set to false, it *does* work.
Ugh. ... Now with a fix, and more test cases to catch this issue. :) Try the v3.0.x branch.
Thanks - better than before, but not what I was expecting. Now "\" is always literal: "%t\t...", '%t\t...' with correct_escapes set to either true or false always outputs:
Wed Sep 9 22:17:14 2015\t127.0.0.1
FWIW that's what I was expecting to happen - It's up to the consumer of the string to translate those escape codes into something useful. At the moment the xlat code uses the slashes to skip over parts of the string and temporarily suspends their specialness, but does not consume the escape sequence. This is why with the correct_escapes set you no longer have to do \\\\\\\\\\\\ to get \. As a side effect: %{redis:{my special key}foobarbaz} Actually needs: %{redis:{my special key%}foobarbaz} To prevent that literal brace on the right, from being treated as the end of the expansion, and to unescape it. If you do: %{redis:{my special key\}foobarbaz} This would get passed to the redis func: {my special key\}foobarbaz It fixes a whole bunch layered backslash problems, and puts the responsibility on the consumer of the expanded string, to translate it into the appropriate format. So what's needed here is for linelog to interpret those backslash codes correctly. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sep 9, 2015, at 5:22 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Thanks - better than before, but not what I was expecting. Now "\" is always literal: "%t\t...", '%t\t...' with correct_escapes set to either true or false always outputs:
Wed Sep 9 22:17:14 2015\t127.0.0.1
But at least it's consistent :)
The solution is probably to smash \t, \n, etc. to their respective characters. The location to do so would be in the same place I put that last patch. The best method is probably to look at the XLAT_LITERAL after it's been parsed. Then, call gettoken() to do the escaping.
(now hacking on a debian packaging / certs/Makefile issue...)
As always, patches are welcome. :) Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton