It's a server-side issue. Jan is looking into this.
Cheers,
Lukasz
On 10/24/2014 05:10 PM, Dirk Hufnagel wrote:
> Hi,
>
> Just to clarify the timeline
>
> 1) using 3.3.6 on one of the machines for months
> with cert/proxy based authentication, no problems
>
> 2) got 3 identical machines, same software, same local
> user, same cert (copied the cert files)
>
> 3) Ivan installed xrootd 4.0.4 from scratch on the
> new machines and upgraded the existing machine
>
> 4) xrdcp as mentioned worked on the 3 new machines,
> not the old one
>
> 5) now they all don't work
>
> Cheers
>
> Dirk
>
> On 10/24/2014 5:06 PM, Dirk Hufnagel wrote:
>>
>> Hi Marian,
>>
>> No, the same command worked on 3 machines but not on another.
>> Same xrootd version, same local user, same certificate to
>> authenticate.
>>
>> This was only a temporary state of affair though, as now it
>> fails on all 4 machines with 4.0.4.
>>
>> [2014-10-24 17:02:44.604930 +0200][Debug ][XRootDTransport ]
>> [eoscms.cern.ch:1094 #0.0] Trying to authenticate using gsi
>> 141024 17:02:44 750 crypto_X509CreateProxy: Your identity:
>> /DC=ch/DC=cern/OU=computers/CN=tier0/vocms15.cern.ch
>> [2014-10-24 17:02:44.625317 +0200][Dump ][AsyncSock ]
>> [eoscms.cern.ch:1094 #0.0] Wrote a message: (0x18042d60), 136 bytes
>> [2014-10-24 17:02:44.652569 +0200][Dump ][XRootDTransport ] [msg:
>> 0x18042d60] Expecting 3407 bytes of message body
>> [2014-10-24 17:02:44.652591 +0200][Dump ][AsyncSock ]
>> [eoscms.cern.ch:1094 #0.0] Received message header, size: 8
>> [2014-10-24 17:02:44.652606 +0200][Dump ][AsyncSock ]
>> [eoscms.cern.ch:1094 #0.0] Received a message of 3415 bytes
>> [2014-10-24 17:02:44.652616 +0200][Debug ][XRootDTransport ]
>> [eoscms.cern.ch:1094 #0.0] Sending more authentication data for gsi
>> [2014-10-24 17:02:44.653645 +0200][Debug ][XRootDTransport ]
>> [eoscms.cern.ch:1094 #0.0] Auth protocol handler for gsi refuses to give
>> us more credentials Secgsi: ErrParseBuffer: certificate chain
>> verification failed: :chain is inconsistent: kXGS_cert
>> [2014-10-24 17:02:44.653702 +0200][Error ][AsyncSock ]
>> [eoscms.cern.ch:1094 #0.0] Socket error while handshaking: [FATAL] Auth
>> failed
>> [2014-10-24 17:02:44.653716 +0200][Debug ][AsyncSock ]
>> [eoscms.cern.ch:1094 #0.0] Closing the socket
>> [2014-10-24 17:02:44.653727 +0200][Debug ][Poller ]
>> <[::ffff:128.142.152.60]:37595><--><[::ffff:128.142.38.82]:1094>
>> Removing socket from the poller
>> [2014-10-24 17:02:44.653783 +0200][Error ][PostMaster ]
>> [eoscms.cern.ch:1094 #0] Unable to recover: [FATAL] Auth failed.
>>
>> I've used 3.3.6 on one of the machines for a long time
>> before this, never had a problem.
>>
>> Cheers
>>
>> Dirk
>>
>> On 10/24/2014 4:47 PM, Marian Zvada wrote:
>>> Hi,
>>>
>>> I believe this particular thing from developers thread went into 4.0.4.
>>>
>>> @Lukasz: is this fix present in XrdClCopy.cc in the recent release
>>> please? Or can we get patch in case not? Seems like annoying artifact...
>>>
>>> Btw, is this really your problem Dirk? I think this part is more of
>>> interest:
>>> >>> Run: [ERROR] Server responded with an error: [3010] Unable to open
>>> >>> file /eos/cms/store/unmerged/tier0_harvest/zzz; Operation not
>>> >>> permitted
>>>
>>> You're saying same command line works just fine in 4.0.4 but not in
>>> version of client below that? Can you post here exact command line with
>>> '-d 2' perhaps? When I tried copy/paste from the thread into terminal
>>> where I run v4.0.3. it's weird but obvious:
>>>
>>> # xrdcp -d 1 zzz
>>> root://eoscms.cern.ch//eos/cms/store/unmerged/tier0_harvest/zzz
>>> xrdcp: No such file or directory processing zzz
>>>
>>> Is your xrdcp some alias or wrapper? How come you could execute it on
>>> vocms001 getting such output?
>>>
>>> Thanks,
>>> Marian
>>>
>>> On 10/24/14, 4:50 AM, Dirk Hufnagel wrote:
>>>>
>>>> The reporter of the bug, Marian ?
>>>>
>>>> Marian, is there a fixed release yet ?
>>>>
>>>> Cheers
>>>>
>>>> Dirk
>>>>
>>>> On 10/24/2014 11:25 AM, Ivan Glushkov wrote:
>>>>> Hi Dirk,
>>>>>
>>>>> It actually works - at least when I tried exactly the same command
>>>>> like yours and then I checked on eos, the file was copied there. The
>>>>> xrootd is throwing an error due to this bug found by Marian [1]. The
>>>>> only thing I don’t understand is why it shows only on vocms001.. I am
>>>>> actually not sure whom should we ask about that.. CERN IT has nothing
>>>>> to do with that.. Some xrootd experts? Do you have an idea?
>>>>>
>>>>> Kind regards,
>>>>> Ivan Glushkov
>>>>>
>>>>> [1]
>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?A2=ind1408&L=XROOTD-DEV&D=0&P=36536
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 23.10.2014, at 22:35, Dirk Hufnagel <[log in to unmask]> wrote:
>>>>>
>>>>>>
>>>>>> Ok, it works on vocms015 and vocms062 and presumably also on
>>>>>> vocms047.
>>>>>>
>>>>>> It does not work on vocms001
>>>>>>
>>>>>> cmst1@vocms001:/data/tier0 $ xrdcp -d 1 zzz
>>>>>> root://eoscms.cern.ch//eos/cms/store/unmerged/tier0_harvest/zzz
>>>>>> [2014-10-23 22:22:22.253218 +0200][Error ][XRootD ]
>>>>>> [eoscms.cern.ch:1094] Handling error while processing kXR_stat (path:
>>>>>> /eos/cms/store/unmerged/tier0_harvest/zzz, flags: none): [ERROR]
>>>>>> Error response.
>>>>>> [2014-10-23 22:22:22.255062 +0200][Error ][XRootD ]
>>>>>> [eoscms.cern.ch:1094] Handling error while processing kXR_open (file:
>>>>>> /eos/cms/store/unmerged/tier0_harvest/zzz?oss.asize=8, mode: 0644,
>>>>>> flags: kXR_new kXR_open_updt kXR_async kXR_retstat ): [ERROR] Error
>>>>>> response.
>>>>>> [0B/0B][100%][==================================================][0B/s]
>>>>>>
>>>>>>
>>>>>> Run: [ERROR] Server responded with an error: [3010] Unable to open
>>>>>> file /eos/cms/store/unmerged/tier0_harvest/zzz; Operation not
>>>>>> permitted
>>>>>>
>>>>>> Any idea ? I don't see any difference in the rpm packages
>>>>>> installed on the box.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Dirk
>>>>>>
>>>>>> On 10/23/2014 10:12 PM, Dirk Hufnagel wrote:
>>>>>>>
>>>>>>> Actually, wait a second, have to check with Luis
>>>>>>> why it works for him...
>>>>>>>
>>>>>>> Dirk
>>>>>>>
>>>>>>> On 10/23/2014 10:08 PM, Dirk Hufnagel wrote:
>>>>>>>>
>>>>>>>> Hi Ivan,
>>>>>>>>
>>>>>>>> The new xrootd client doesn't work with proxy authentication.
>>>>>>>>
>>>>>>>> Just tried it, same proxy, copying to the same place. 4.0.4
>>>>>>>> throws and 'operation not permitted', 3.3.6 works.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> Dirk
>>>>>
>
> ########################################################################
> 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
