 |
 |
Hello Oliver, all, On Thu, Sep 24, 2020 at 09:41:41AM +0200, Oliver Freyermuth wrote: > Hi Andy, > > Am 24.09.20 um 09:10 schrieb Andrew Hanushevsky: > > Hi Oliver, > > > > So, if the reason is that "It seems /usr/lib64/libXrdVoms-5.so links against /lib64/libvomsapi.so.1 from voms 2.0.14, which matches the statement above" then the question is why is that so? The plugin should link to whatever is available on that machine and if it happens to be an old version, well, that's what will happen. > > Andrea has confirmed by now that the current breakage is regarded as a bug in the upstream VOMS servers, since it was not planned to drop VOMS 2 client support (yet?). > > The version I use is the pre-built one from the XRootD repositories. However, I would suspect that even if VOMS 3.x is installed on the system on which XRootD is compiled, > it might not be picked up — VOMS 3 is a rewrite in Java as far as I know, so likely it needs changes in the CMake scripts and may even need adapting the code. VOMS APIs (i.e. libvoms) should not be confused with VOMS clients (i.e., voms-proxy-init, voms-proxy-info etc..) The problem yesterday was that the upgraded VOMS server issued a VOMS extension that could not be validated by existing (and supported) VOMS C/C++ libraries. The problem was observed on XRootD since XRootD links against VOMS libraries, but any C/C++ software linking against the VOMS library would be affected (e.g., the StoRM frontend server). The change was quickly rolled back and we are investigating the causes of the issue. No update on the client side *libraries* will be required by the VOMS server upgrade. Cheers, Andrea -- Andrea Ceccanti - INFN-CNAF Viale Berti Pichat 6/2 40127 Bologna, Italy +39 0512095 50 skype: andreaceccanti keybase: andreaceccanti ######################################################################## 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