 |
 |
On 06/07/11 10:14, Andrew Hanushevsky wrote: > > > On Tue, 7 Jun 2011, Brian Bockelman wrote: > >> Alright, now I'm confused. My understanding is that Matevz was complaining >> that the name recorded in the new monitoring record was truncated at 8 >> characters. > I think he is but it's comming from the fact that the gsi plug-in is not > returning the translated name so he might have to rely on the traceid; which of > course, you can't except in limited circumstances. > >> I'm fine with the trace-id being "truncated", as we can back-track it to their >> login, which looks like this: >> >> 110607 02:47:20 5315 XrootdXeq: glxcuser.2050:[log in to unmask] >> login as uscmsPool1836 >> >> I assume the trace-id is the "glxcuser.2050:[log in to unmask]", >> which I'm assuming is simply an opaque unique identifier (and hence not meant >> to derive meaning, such as a user name, from). > Bingo! Yes, you are correct. He should be using the authenticated name and that > is being recorded in the monitoring records (as well as the "meaningless" > traceid). That's the 'uscmsPool1836' full name in the above line. > > This, of course, brings up the question of how you got the full name displayed > in your log record? He only gets the x500 hash from the gsi plugin he is using. > I assume you are using the same plugin but your mapping function works (his does > not). I guess this is the log ... I only get UDP monitoring streams where this info is missing. Even when we get the GSI plugin plugin -- this information will still be missing, as I'll get full DN, but not the full user name. What is glxcuser in the above case? Cheers, \m