 |
 |
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. Andy 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