 |
 |
Hi Andy, Is there a way to inform the intended hostname to the xrootd and cmsd server though the configuration? On cmsio3, /bin/hostname -f is not cmsio3.rc.ufl.edu (the public hostname), but is cmsio3.ufhpc per the local cluster management policy. It would solve the issue if there is a way to specify the intended hostname in the configuration. At the moment, there is a very inconvenient work-around, though. If there is no such option, should I create an issue with the xrootd github? Thanks, Bockjoo On 5/19/22 20:47, Bockjoo Kim wrote: > Hi Andy, > > cmsio3.rc.ufl.edu is a server. > > Here's the output of the command with XRD_LOGLEVEL=Debug: > > https://docs.google.com/document/d/1ce4aiy8lOz5uOcsVcyvBlJvYvW-73VWSrlYlhGFyLm0 > > Thanks, > > Bockjoo > > On 5/19/22 20:36, Andrew Hanushevsky wrote: >> Hi Bockfoo, >> >> For the first case it appears to be a conflict between private and public IP addresses, 172.16.200.175 is private did you issue the command from a public address or a private address? Is cmsio3.rc.ufl.edu actually a redirector? >> >> Another thing that would be helpful is to set the envar XRD_LOGLEVEL to "Debug" and try the command again and send us the output. >> >> Andy >> >> >> On Thu, 19 May 2022, Bockjoo Kim wrote: >> >>> Hi Andy, >>> >>> I want to bring up this issue again. >>> >>> I don't understand why it's expected. >>> >>> For example, >>> >>> (base) [bockjoo@cms ~]$ xrdfs cmsio3.rc.ufl.edu ls /store/user/bockjoo >>> [FATAL] TLS error: Unable to validate 172.16.200.175; hostname not in SAN extension. >>> >>> I provided a fully qualified public hostname, but why is xrdfs coming >> up with a private ip 172.16.200.175 >>> On the other hand, if I check a specific file, xrdfs does not show this >> issue and shows the correct output: >>> (base) [bockjoo@cms ~]$ xrdfs cmsio3.rc.ufl.edu ls /store/user/bockjoo/xrdmapc.txt >>> /store/user/bockjoo/xrdmapc.txt >>> >>> I think this is a bug. >>> >>> Thanks, >>> >>> Bockjoo >>> >>> On 4/15/22 01:04, 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