 |
 |
Hi Andy, The local redirectors in CMS need the X509 authentication, too: (base) [bockjoo@cms ~]$ (unset X509_USER_PROXY ; xrdfs cmsio7.rc.ufl.edu:1094 locate '*' ; ) [FATAL] Auth failed: No protocols left to try The reason for the server-redirector difference is as follows, I think. The servers are reporting the local redirector by its public FQHN. Therefore, the redirector is listing servers by its public FQHN. Namely, when the xrootd server is xrdfs'd, it looks like: (base) [bockjoo@cms ~]$ xrdfs cmsio3.rc.ufl.edu:1094 locate '*' [::172.16.200.175]:1094 Server ReadWrite 172.16.200.175 is the other non-public interface of cmsio3.rc.ufl.edu. On the other hand, wen the xrootd redirector is xrdfs, it looks like this: (base) [bockjoo@cms ~]$ xrdfs cmsio7.rc.ufl.edu:1094 locate '*' [::128.227.221.219]:1094 Server Read [::128.227.221.225]:1094 Server Read [::128.227.221.227]:1094 Server Read [::128.227.221.221]:1094 Server Read [::128.227.221.223]:1094 Server Read [::128.227.221.226]:1094 Server Read [::128.227.221.222]:1094 Server Read [::128.227.221.220]:1094 Server Read 128.227.221.220 is cmsio3.rc.ufl.edu and the public ip unlike the server-xrdfs. Anyway, today, I was told incommon igtf CA does not allow non-public hostnames to be used for the SAN. So, I can not request a new host certificate with additional SAN's. Fortunately, xrdfs can be executed through the redirector with the current host certificates. My only remaining question is why xrdfs should behave differently from xrdcp in terms of accessing the servers directly. Thanks, Bockjoo On 4/15/22 3:17 PM, Andrew Hanushevsky wrote: > Hi Bockjoo, > > I think the way CMS sets things up the redirector has neither > authentication nor does it use TLS. So, the host cert is irrelevant. > Data servers, on the other hand employ both and need a fully filled > out cert. > > Andy > > > On Fri, 15 Apr 2022, Bockjoo Kim wrote: > >> Hi Andy, >> >> I will request the host certificates with all the SANs then. >> >> By the way, with the redirector, there is no error with the SAN and >> the xrdfs command mentioned runs just fine. >> >> So, in the typical use cases, the SAN is not needed because we almost >> always use the redirector to access the site xrootd cluster. >> >> Also, this issue is only seen with the xrdfs command but not with the >> xrdcp. I guess they are going through different codes. >> >> Thanks, >> >> Bockjoo >> >> On 4/15/22 1:04 AM, Andrew Hanushevsky wrote: >>> Hi Bockjoo, >>> >>> This is expected and normal behaviour. If the machine van be known >>> by more than one name then it's host cert must have all of these >>> listed in SAN extension. I suggest you either not give it two name >>> (i.e. use the name in tghe cert) or get a new cert with the all the >>> names in the SAN extension. Some people also put the host's IP >>> address(s) in the SAN extension as a client might use an IP address >>> to reach the host. >>> >>> Andy >>> >>> >>> On Thu, 14 Apr 2022, Bockjoo Kim wrote: >>> >>>> Hi, >>>> >>>> With the xrootd servers, I am seeing this error: >>>> >>>> (base) [bockjoo@cms ~]$ time xrdfs cmsio2.rc.ufl.edu ls /store/mc >>>> [FATAL] TLS error: Unable to validate 172.16.199.254; hostname not >>>> in SAN extension. >>>> >>>> The machine's FQHN is set at cmsio2.ufhpc ( 172.16.199.254 ) by the >>>> local cluster management team but cmsio2.rc.ufl.edu is the publicly >>>> accessible FQHN. >>>> >>>> So, I guess xrdfs is looking for the DN matching to the >>>> cmsio2.ufhpc instead of cmsio2.rc.ufl.edu. >>>> >>>> Is this expected? >>>> >>>> When we were using the non-xrootd security system, I did not see >>>> this issue. >>>> >>>> Is there any workaround in terms of xrootd directive or something? >>>> >>>> Thanks, >>>> >>>> Bockjoo >>>> >>>> ######################################################################## >>>> >>>> Use REPLY-ALL to reply to list >>>> >>>> To unsubscribe from the XROOTD-L list, click the following link: >>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >>>> >> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1