But other sites are using gPlazma and gsidcap ... aren't they?
I think I'll move this discussion over to the dCache User Forum to see
if anyone there has any ideas. I'm due to upgrade to 1.8 next Monday and
I'd like to have it solved before then.
Yours,
Chris.
> -----Original Message-----
> From: GRIDPP2: Deployment and support of SRM and local
> storage management [mailto:[log in to unmask]] On
> Behalf Of Ross, D (Derek)
> Sent: 16 January 2008 14:52
> To: [log in to unmask]
> Subject: Re: gsidcap doesn't work anymore
>
> Hi,
>
> There have been issues before with gsidcap and gPlazma
>
> http://www.dcache.org/archive/user-forum/0884.html
>
> Derek
>
>
>
> > -----Original Message-----
> > From: GRIDPP2: Deployment and support of SRM and local storage
> > management [mailto:[log in to unmask]]On Behalf Of
> > Greig Alan
> > Cowan
> > Sent: 16 January 2008 14:48
> > To: [log in to unmask]
> > Subject: Re: gsidcap doesn't work anymore
> >
> >
> > On 16/01/08 14:31, Brew, CAJ (Chris) wrote:
> > > It works for me if I use a straight grid proxy, it only
> > fails if I use a
> > > VOMS proxy. Anyone know whete the vomsdir is configured
> into dCache.
> >
> > OK, sounds like gPlazma is playing up, or perhaps there is
> a bug when
> > gsidcap attempts to use it. You are using it as the gPlazma
> > cell, right?
> >
> > > P.s. If you still have access to the T1 UIs you should be
> > able to get
> > > behind the firewall there.
> >
> > I don't have access to those macines unfortunately.
> >
> > Greig
> >
> > >
> > >> -----Original Message-----
> > >> From: Greig Alan Cowan [mailto:[log in to unmask]]
> > >> Sent: 16 January 2008 14:29
> > >> To: Brew, CAJ (Chris)
> > >> Cc: [log in to unmask]
> > >> Subject: Re: gsidcap doesn't work anymore
> > >>
> > >> Hi Chris,
> > >>
> > >> I was trying the same command as you, but from a UI at
> > >> Edinburgh. It's
> > >> not working (probably because of a firewall) but seems to
> > be getting
> > >> further than you were. You can see that the client was trying
> > >> to connect
> > >> to the data port:
> > >>
> > >> Failed to connect to heplnx168.pp.rl.ac.uk:33115,
> waiting for door
> > >>
> > >> Can you inspect the logs for my DN? Is everything on your UI
> > >> up to date?
> > >>
> > >> Cheers,
> > >> Greig
> > >>
> > >> On 16/01/08 12:58, Brew, CAJ (Chris) wrote:
> > >>> Hi,
> > >>>
> > >>> Yes sorry, tyring to do too many thinks at once. I am using
> > >> gsidcap on
> > >>> the command line.
> > >>>
> > >>> Adding a -d 127 to turn on debuging I get:
> > >>>
> > >>> dccp -d 127
> > >>>
> > >> gsidcap://heplnx204.pp.rl.ac.uk:22128/pnfs/pp.rl.ac.uk/data/dt
> > >> eam/canned
> > >>> /1GBcannedfile000 /scratch/brew/gsidcap-test
> > >>> Dcap Version version-1-2-41 Apr 20 2007 12:40:20
> > >>> Allocated message queues 0, used 0
> > >>>
> > >>> Using environment variable as configuration
> > >>> Allocated message queues 1, used 1
> > >>>
> > >>> Creating a new control connection to
> heplnx204.pp.rl.ac.uk:22128.
> > >>> Activating IO tunnel. Provider: [libgsiTunnel.so].
> > >>> Added IO tunneling plugin libgsiTunnel.so for
> > >>> heplnx204.pp.rl.ac.uk:22128.
> > >>> Setting IO timeout to 20 seconds.
> > >>> Connected in 0.01s.
> > >>> Removing IO timeout handler.
> > >>> Sending control message: 0 0 client hello 0 0 2 41
> > >> -uid=24431 -pid=3150
> > >>> -gid=24251
> > >>> Error ( POLLIN POLLERR POLLHUP) (with data) on control line [3]
> > >>> Removing [3] form control lines list
> > >>> Failed to connect to heplnx204.pp.rl.ac.uk:22128
> > >>> Failed to create a control line
> > >>> [-1] unpluging node
> > >>> Removing unneeded queue [1]
> > >>> [-1] destroing node
> > >>> Using system native stat64 for /scratch/brew/gsidcap-test.
> > >>> [Wed Jan 16 09:36:52 2008] Going to open file
> > >>>
> > >> gsidcap://heplnx204.pp.rl.ac.uk:22128/pnfs/pp.rl.ac.uk/data/dt
> > >> eam/canned
> > >>> /1GBcannedfile000 in cache.
> > >>> Allocated message queues 2, used 1
> > >>>
> > >>> Using environment variable as configuration
> > >>> Allocated message queues 2, used 2
> > >>>
> > >>> Creating a new control connection to
> heplnx204.pp.rl.ac.uk:22128.
> > >>> Activating IO tunnel. Provider: [libgsiTunnel.so].
> > >>> Added IO tunneling plugin libgsiTunnel.so for
> > >>> heplnx204.pp.rl.ac.uk:22128.
> > >>> Setting IO timeout to 20 seconds.
> > >>> Connected in 0.00s.
> > >>> Removing IO timeout handler.
> > >>> Sending control message: 0 0 client hello 0 0 2 41
> > >> -uid=24431 -pid=3150
> > >>> -gid=24251
> > >>> Error ( POLLIN POLLERR POLLHUP) (with data) on control line [3]
> > >>> Removing [3] form control lines list
> > >>> Failed to connect to heplnx204.pp.rl.ac.uk:22128
> > >>> Failed to create a control line
> > >>> [-1] unpluging node
> > >>> Removing unneeded queue [2]
> > >>> [-1] destroing node
> > >>> Failed open file in the dCache.
> > >>> Can't open source file : Server rejected "hello"
> > >>> System error: Input/output error
> > >>>
> > >>> It's definitely something in the negoations of the SSL -
> > >> the only error
> > >>> I see in the server logs is:
> > >>>
> > >>> Failure unspecified at GSS-API level. Caused by
> > >>> COM.claymoresystems.ptls.SSLThrewAlertException:
> Handshake failure
> > >>> at
> > COM.claymoresystems.ptls.SSLConn.alert(SSLConn.java:235)
> > >>> at
> > >>>
> > >> COM.claymoresystems.ptls.SSLHandshakeServer.recvSSLv2ClientHel
> > >> lo(SSLHand
> > >>> shakeServer.java:431)
> > >>> at
> > >>>
> > >> COM.claymoresystems.ptls.SSLHandshakeServer.processTokens(SSLH
> > >> andshakeSe
> > >>> rver.java:190)
> > >>> at
> > >>>
> > >> COM.claymoresystems.ptls.SSLHandshake.processHandshake(SSLHand
> > >> shake.java
> > >>> :135)
> > >>> at
> > >>>
> > >> org.globus.gsi.gssapi.GlobusGSSContextImpl.acceptSecContext(Gl
> > >> obusGSSCon
> > >>> textImpl.java:295)
> > >>> at javatunnel.GssTunnel.verify(GssTunnel.java:189)
> > >>> at javatunnel.GsiTunnel.verify(GsiTunnel.java:91)
> > >>> at javatunnel.TunnelSocket.verify(TunnelSocket.java:170)
> > >>> at
> > >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >>> at
> > >>>
> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> > >> orImpl.jav
> > >>> a:39)
> > >>> at
> > >>>
> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> > >> odAccessor
> > >>> Impl.java:25)
> > >>> at java.lang.reflect.Method.invoke(Method.java:585)
> > >>> at
> > >>>
> > >> dmg.protocols.telnet.TelnetStreamEngine.<init>(TelnetStreamEng
> > >> ine.java:1
> > >>> 08)
> > >>> at
> > >>>
> > >> dmg.cells.services.login.LoginManager$RunEngineThread.run(Logi
> > > nManager.j
> > >>> ava:848)
> > >>> at java.lang.Thread.run(Thread.java:595)
> > >>>
> > >>> but using the same VOMS certificate I can talk to the
> > >> gridftp doors and
> > >>> the SRM so I don't think it's a certificate issue per se.
> > >>>
> > >>> I'm running out of ideas now.
> > >>>
> > >>> Yours,
> > >>> Chris.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Greig A Cowan [mailto:[log in to unmask]]
> > >>>> Sent: 16 January 2008 09:35
> > >>>> To: Brew, CAJ (Chris)
> > >>>> Cc: [log in to unmask]
> > >>>> Subject: RE: gsidcap doesn't work anymore
> > >>>>
> > >>>>
> > >>>> Hi Chris,
> > >>>>
> > >>>> Don't you mean:
> > >>>>
> > >>>> dccp
> > gsidcap://heplnx204.pp.rl.ac.uk/pnfs/pp.rl.ac.uk/path/to/file
> > >>>> /local/path/to/file
> > >>>>
> > >>>> Note the gsidcap, not gsiftp.
> > >>>>
> > >>>> What about firewalls, are they in the way? At Edinburgh, I use
> > >>>>
> > >>>> export DCACHE_CLIENT_ACTIVE=1
> > >>>>
> > >>>> to make the server act in passive mode.
> > >>>>
> > >>>> Cheers,
> > >>>> Greig
> > >>>>
> > >>>> On Wed, 16 Jan 2008, Brew, CAJ (Chris) wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> No dice I'm afraid.
> > >>>>>
> > >>>>> Just to check just doing:
> > >>>>>
> > >>>>> dccp
> > gsiftp://heplnx204.pp.rl.ac.uk/pnfs/pp.rl.ac.uk/path/to/file
> > >>>>> /local/path/to/file
> > >>>>>
> > >>>>> Should just work? I don't need to set up any environment or
> > >>>> anything?
> > >>>>> Thanks,
> > >>>>> Chris.
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: GRIDPP2: Deployment and support of SRM and local
> > >>>>>> storage management [mailto:[log in to unmask]] On
> > >>>>>> Behalf Of Greig Alan Cowan
> > >>>>>> Sent: 15 January 2008 15:46
> > >>>>>> To: [log in to unmask]
> > >>>>>> Subject: Re: gsidcap doesn't work anymore
> > >>>>>>
> > >>>>>> I think this is precisely what it is. Chris, can you try
> > >>>>>> restarting the
> > >>>>>> door?
> > >>>>>>
> > >>>>>> Also note that SRM should be restarted to reload the
> new certs.
> > >>>>>>
> > >>>>>> Greig
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 15/01/08 15:34, Ross, D (Derek) wrote:
> > >>>>>>> I have a dim recollection that while the gridftp door coped
> > >>>>>> with the CA certificates being updated under it, the gsidcap
> > >>>>>> door didn't. But I could be misremembering.
> > >>>>>>> Derek
> > >>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: GRIDPP2: Deployment and support of SRM and
> > local storage
> > >>>>>>>> management [mailto:[log in to unmask]]On Behalf
> > >>>>>> Of Kostas
> > >>>>>>>> Georgiou
> > >>>>>>>> Sent: 15 January 2008 15:31
> > >>>>>>>> To: [log in to unmask]
> > >>>>>>>> Subject: Re: gsidcap doesn't work anymore
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Tue, Jan 15, 2008 at 02:03:47PM -0000, Brew, CAJ
> > >>>> (Chris) wrote:
> > >>>>>>>>> Hi Greig,
> > >>>>>>>>>
> > >>>>>>>>> Unfortunately, dcap ordinaire works fine and as far as I
> > >>>>>>>> can tell both
> > >>>>>>>>> the lcg-CA and voms server certs are up to date (if
> > >> they weren't
> > >>>>>>>>> wouldn't GridFTP fail as well?).
> > >>>>>>>>>
> > >>>>>>>>> I can remember spending ages trying to get this to work
> > >>>>>> in the past
> > >>>>>>>>> before finally managing it.
> > >>>>>>>>>
> > >>>>>>>>> Does anyone have a recipe from a working dCache/UI
> > >>>>>>>> combination that does
> > >>>>>>>>> used gsidcap to copy a file into or out of a dCache? (to
> > >>>>>>>> test my test).
> > >>>>>>>>
> > >>>>>>>> Strangly enough running
> > >>>>>>>> /opt/d-cache/jobs/gsidcapdoor -domain=gsidcap-gfe02Domain
> > >>>>>>>> {stop,start}
> > >>>>>>>> fixed the error for us. Since the door was there but
> > >>>> malfunctioning
> > >>>>>>>> something must have pushed it to a strange state,
> I am going
> > >>>>>>>> through the
> > >>>>>>>> logs just in case I can fine something.
> > >>>>>>>>
> > >>>>>>>> Cheers,
> > >>>>>>>> Kostas
> > >>>>>>>>
> > >>>> --
> > >>>> ==============================================================
> > >>>> ==========
> > >>>> Dr Greig A Cowan
> > >>>> http://www.ph.ed.ac.uk/~gcowan1
> > >>>> School of Physics, University of Edinburgh, James Clerk
> > >>>> Maxwell Building
> > >>>>
> > >>>> TIER-2 STORAGE SUPPORT PAGES:
> > >>>> http://wiki.gridpp.ac.uk/wiki/Grid_Storage
> > >>>> ==============================================================
> > >>>> ==========
> > >>>>
> >
>
|