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