5:27 a.m.
Hi,
I noticed this in fticks.c, line 109:
if (options->fticks_reporting == RSP_FTICKS_REPORTING_FULL) {
if (client->conf->fticks_visinst != NULL ) {
snprintf((char *) visinst, sizeof(visinst), "VISINST=%s#",
client->conf->fticks_visinst);
} else {
snprintf((char *) visinst, sizeof(visinst), "VISINST=%s#",
client->conf->name);
}
}
If a client has no fticksVISINST set, this means radsecproxy will log
the client name instead. However that may not be a valid operator-name
(1<domain>) and it probably won't convey anything meaningful: if you
don't set fticksVISINST you probably expect requests from different
operators to be proxied through that client.
If the Operator-Name attribute value won't be used in the absence of
fticksVISINST, then I guess it would be better to have an empty VISINST
(not sure if that would be valid). However it is not even possible to
force an empty value through configuration, as the tokenizer in
getconfigline() reports that "fticksVISINST needs a non-empty value".
Any ideas? Please advise.
Thanks,
Zenon Mousmoulas
12:40 p.m.
Hi Zenon,
On 28/06/16 07:27, Zenon Mousmoulas wrote:
If a client has no fticksVISINST set, this means
radsecproxy will log
the client name instead.
Yes that is intended and also stated in the
documentation.
However that may not be a valid operator-name
(1<domain>) and it
probably won't convey anything meaningful: if you don't set
fticksVISINST you probably expect requests from different operators
to be proxied through that client.
The f-ticks does not require the VISINST to
conform to the operator-name format. It's basically free-text hand has no further
meaning (see Geant deliverable DJ3.1.2,1: Roaming Developments). You can either send
f-ticks in a short format (just the VISCOUNTRY) or in a long format (including the
VISINST). Which one to use is set by the global option FTicksReporting (None, Basic or
Full).
If the Operator-Name attribute value won't be used
in the absence of
fticksVISINST, then I guess it would be better to have an empty
VISINST (not sure if that would be valid).
No, it wouldn't. The only option
would be to use the short format (see above).
Best regards,
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 30, direct +41 44 268 15 39
fabian.mauchle(a)switch.ch, www.switch.ch
9:55 p.m.
Hi Fabian
On 2016-06-28 15:40, Fabian Mauchle wrote:
On 28/06/16 07:27, Zenon Mousmoulas wrote:
You are absolutely right.
I was somehow hoping that radsecproxy would fall back to using
Operator-Name if fticksVISINST is not set, and then perhaps fall back to
client block name. I have now understood this is unfortunately not an
option.
It would also not make sense to sacrifice logging VISINST, switching
from FTicksReporting Full to Basic, just for some outlier cases, such as
the particular client.
Thanks,
Z.
If a client has no fticksVISINST set, this means
radsecproxy will log
the client name instead.
Yes that is intended and also stated in the
documentation.
However that may not be a valid operator-name
(1<domain>) and it
probably won't convey anything meaningful: if you don't set
fticksVISINST you probably expect requests from different operators
to be proxied through that client.
The f-ticks does not require the VISINST to
conform to the
operator-name format. It's basically free-text hand has no further
meaning (see Geant deliverable DJ3.1.2,1: Roaming Developments). You
can either send f-ticks in a short format (just the VISCOUNTRY) or in
a long format (including the VISINST). Which one to use is set by the
global option FTicksReporting (None, Basic or Full).
If the Operator-Name attribute value won't be
used in the absence of
fticksVISINST, then I guess it would be better to have an empty
VISINST (not sure if that would be valid).
No, it wouldn't. The only option
would be to use the short format (see
above).
2866
days inactive
2866
days old
2 comments
2 participants
participants (2)
-
Fabian Mauchle -
Zenon Mousmoulas