 |
 |
I forgot to add another comment. There is the xrd.port directive, but there is no xrd.hostname directive, which could have made the servers behave same as the redirectors. Thanks, Bockjoo On 4/15/22 3:53 PM, Bockjoo Kim wrote: > 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