 |
 |
Hi Andy, On 01/27/12 01:25, Andrew Hanushevsky wrote: > Hi Matevz, > > Right. Now you should ask yourself why the redirector requires authentication. > You get nothing but overhead doing that since you will need to authenticate on > the server anyway. It's usually just not needed. I think it's there mostly to prevent our ATLAS colleagues from browsing the CMS file-namespace ;) More seriously, I think admins just don't like if their servers talk to strangers too much. And with caching of authentication decision in XrdSecGsi the overhead is brought down to practically nothing. I agree that not using authentication on redirector for connections from local domain seems ok. Matevz > On Thu, 26 Jan 2012, Matevz Tadel wrote: > >> Hi Andy, >> >> Thanks for your help :) If I run proxy as user matevz with a valid certificate >> it happily connects to the redirector and does it job. So, I was missing that >> proxies needs to authenticate to the redirector/origin. >> >> I'll use sec.protbind (probably with sss) to make this connection independent of >> GSI. >> >> Best, >> Matevz >> >> On 01/26/12 13:25, Andrew Hanushevsky wrote: >>> Hi Matevz, >>> >>> On Thu, 26 Jan 2012, Matevz Tadel wrote: >>> >>>>> The origin is typically a redirector and we recommend against enabling >>>>> authentication for that unless you are forwarding requests. >>>> >>>> Authentication for what? For proxy->origin, for client->proxy, or for >>>> client->origin? >>> For anything. That is, why have authentication at all for connections to the >>> redirector? >>> >>>>> Based on the log, it seems that the security shared libraries that the proxy >>>>> needed to use were not in the ld path for the proxy (common problem). >>>> >>>> But why would it need the libs if it doesn't do any authentication? >>> That statement makes no sense, you just told me that the redirector requires GSI >>> authentication. >>> >>>> The final result of my fiddling with configuration: >>>> http://uaf-2.t2.ucsd.edu/~matevz/tmp/proxy.cfg >>>> where I limit access to my desktop only, results in this on startup (even >>>> without anybody connecting to the proxy): >>>> http://uaf-2.t2.ucsd.edu/~matevz/tmp/proxy.log >>>> and the redirector simply says: >>>> 120126 12:53:22 4028 XrootdXeq: xrootd.2781:[log in to unmask] disc >>>> 0:00:01 >>>> >>>> So, it seems, proxy wants to authenticate itself to the redirector ... and as >>>> redirector only allows GSI authentication, it fails. Is this correct? >>> a) The only reason that the redirector wants GSI authentication is because it is >>> configured to require it. >>> b) The only reason that the proxy fails to do si is because either it doesn't >>> have a proper certificate or the libraries are not accessible. >>> >>>> My naive expectation from the first mail was that proxy will never >>>> authenticate itself to the redirector ... but always just pass auth >>>> requests/responses between its client ant the redirector. >>> If the redirector requires authentication then everyone must authenticate. That >>> said, you can make exceptions on a host by host basis and the documentation >>> tells you how to do that via the sec.bind directive. But you have to do that >>> explicitly. >>> >>>> So ... should I be running the proxy with a valid certificate? (Or some other >>>> authentication, like sss and have it enabled on the redirector for proxy hosts >>>> only.) >>> See the sec.protbind directive. >>> http://www.xrootd.org/doc/prod/sec_config.htm#_Toc304922498 >>> >>>> [ Strangely enough, when I connect to the proxy with a client I also get a >>>> line: >>>> 120126 13:06:17 3126 secgsi_InitProxy: cannot access private key file: >>>> /home/xrootd/.globus/userkey.pem >>>> in the log ... which wasn't there before. I didn't change LD_LIB_PATH, have >>>> /usr/local/lib64 in /etc/ld.so.conf.] >>> Is that the proxy saying this ir the client. It's not clear which here. >>> In any case, either that file is missing or the permission disallow access, >>> that's what the message means. >>> >>> Andy >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-DEV list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1