Bi, all!
Thanks for usufull sugegstions, I did finally found that it was missing
.alias file for AliEn CA in the CAcert directory. I am happy no code fix
required :)
Now I have a different problem with srmcp: apprently it doesn't like the
format of Alien host certificate (note that /SE):
SRMClientV1 : org.globus.common.ChainedIOException: Authentication failed
[Caused by: Operation unauthorized (Mechanism level: Authorization failed.
Expected "/CN=host/ccsvli08.in2p3.fr" target but received
"/C=ch/O=AliEn/OU=ALICE/CN=ccsvli08.in2p3.fr/SE")]
Note, that if I use another host certificate with CN=cclcgseli05.in2p3.fr
it works (when srm server runs on cclcgseli05 of course), so CN doesn't
need to be in the form CN=host/ccsvli08.in2p3.fr.
So, who is more standard here?
If I request a host certificate without /SE, will it be ok for Alien
software?
Artem.
On Thu, 19 Jan 2006, Derek Feichtinger wrote:
> Hi,
>
> If the authentication uses the globus C libraries somewhere in the back (based
> on a slightly openssl version), there is a number of environment variables,
> which can be used to get more information about the inner workings of the
> authentication process. I don't know whether the java libraries make use of
> this, but if not one can try to look whether the same behavior happens with
> normal gridftp or some other service.
>
> Note one needs to make sure that the "globus flavor" is one of the debug
> flavors, so the libraries used will have a "dbg" in their names. I used this
> a lot while integrating the authentication for the ALICE apiservice.
>
> Just set these variables to a numeric value and you should get messages on
> stdout.
>
> GLOBUS_GSI_AUTHZ_DEBUG_LEVEL
> GLOBUS_CALLOUT_DEBUG_LEVEL
> GLOBUS_FTP_CLIENT_DEBUG_LEVEL
> GLOBUS_FTP_CONTROL_DEBUG_LEVEL
> GLOBUS_GSI_CALLBACK_DEBUG_LEVEL
> GLOBUS_GSI_CERT_UTILS_DEBUG_LEVEL
> GLOBUS_GSI_CRED_DEBUG_LEVEL
> GLOBUS_GSI_PROXY_DEBUG_LEVEL
> GLOBUS_GSI_SYSCONFIG_DEBUG_LEVEL
> GLOBUS_GSI_GSS_ASSIST_DEBUG_LEVEL
> GLOBUS_GSSAPI_DEBUG_LEVEL
> GLOBUS_NEXUS_DEBUG_LEVEL
> GLOBUS_GIS_OPENSSL_ERROR_DEBUG_LEVEL
>
> Funny enough, this is not well known and when I just tried googling for it
> with the name of one of these variables I almost got no hits. The original
> description is somewhere on the globus site, but I don't remember where.
>
> Cheers,
> Derek
>
>
>
> On Wednesday 18 January 2006 18.50, Timur Perelmutov wrote:
> > This is exactly the kind of problems that are hard to debug and plaque
> > the grid software in general and are not specific to our particular
> > software. Sometimes it is useful to run a different grid tool from
> > globus to see what kind of error messages you get with them. For example
> > I am using gridftp server and globus-url-copy client from globus
> > toolkit, make them run with the same server/client credentials and CA
> > cert directories and look at the errors they report.
> >
> > Thanks,
> > Timur
> >
> > Artem Trunov wrote:
> > >Hi, Timur!
> > >
> > >This is exactly what I did... I used non-default directory on both srm
> > >server side and srmcp client side.
> > >I can assume there is some problem with Alien CA and it's host
> > >certificate, but can't get enough information to get to the cause of the
> > >problem..
> > >
> > >Artem.
> > >
> > >On Wed, 18 Jan 2006, Timur Perelmutov wrote:
> > >>The problem is caused by the absence of the Certificate Authority (CA)
> > >>certificate in the trasted certificates directory (usually
> > >>/etc/grid-security/certificates or ${HOME}/.globus/certificates). You
> > >>will need to find the CA cert, usually available from the CA web site.
> > >>Note that your CA certs directory will need to have both CA certs for
> > >>the CA that issued cert for your server and that CA certs for CAs that
> > >>issued certs for all the clients using your system. The
> > >>
> > >><x509TrastedCACerts> should point to such directory and not to individual
> > >> file.
> > >>
> > >>Thanks,
> > >>Timur
> > >>
> > >>Artem Trunov wrote:
> > >>>Hi, Timur and also Alice experts!
> > >>>
> > >>>I'v been able to run test unix SRM under a regular user (after
> > >>> "stealing" host certificate and key from root). This is older version I
> > >>> checked out in october. I can copy in/out of gridftpserver.
> > >>>
> > >>>I was also trying to use SRM with a host certificate issued by Alien CA,
> > >>>the same used for running Alice VO services. This one didn't work and I
> > >>>think I need some help debugging this problem.
> > >>>
> > >>>Alien CA certificate is not in LCG distribution (asked them to fix), but
> > >>>in Alice software distribution, so I
> > >>>had to specify custom location with srmcp
> > >>> -x509_user_trusted_certificates and <x509TrastedCACerts> in
> > >>> .srmconfig/config.xml . This worked when SRM is run with a host
> > >>> certificate issued by french authority.
> > >>>
> > >>>When I replace this certificate and key with ones issued by Alice, srmcp
> > >>>gives this error:
> > >>>
> > >>>SRMClientV1 : get: try # 0 failed with error
> > >>>SRMClientV1 : org.globus.common.ChainedIOException: Authentication
> > >>> failed [Caused by: Failure unspecified at GSS-API level [Caused by:
> > >>> Unknown CA]]
> > >>>
> > >>>SRM log file contains:
> > >>>
> > >>>Wed Jan 18 15:47:36 CET 2006 SslGsiSocketFactory :GsiSslServerSocket
> > >>>accepted socket from host =/134.158.105.66
> > >>>Wed Jan 18 15:47:56 CET 2006 SslGsiSocketFactory :GsiSslServerSocket,
> > >>>waiting for incomming connection...
> > >>>Wed Jan 18 15:48:07 CET 2006 SslGsiSocketFactory :GsiSslServerSocket
> > >>>accepted socket from host =/134.158.105.66
> > >>>Wed Jan 18 15:48:07 CET 2006 SslGsiSocketFactory :GsiSslServerSocket,
> > >>>waiting for incomming connection...
> > >>>Wed Jan 18 15:48:11 CET 2006 SslGsiSocketFactory :
> > >>>java.net.SocketTimeoutException: Read timed out
> > >>> at java.net.SocketInputStream.socketRead0(Native Method)
> > >>> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> > >>> at org.globus.gsi.gssapi.SSLUtil.read(SSLUtil.java:31)
> > >>> at
> > >>>org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readToken(GSIGssInputSt
> > >>>ream.java:58) at
> > >>>org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readHandshakeToken(GSIG
> > >>>ssInputStream.java:48) at
> > >>>org.globus.gsi.gssapi.net.impl.GSIGssSocket.readToken(GSIGssSocket.java:
> > >>>54) at
> > >>>org.globus.gsi.gssapi.net.GssSocket.authenticateServer(GssSocket.java:11
> > >>>7) at
> > >>>org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:137)
> > >>> at
> > >>>org.globus.gsi.gssapi.net.GssSocket.getInputStream(GssSocket.java:161)
> > >>> at
> > >>>org.dcache.srm.security.SslGsiSocketFactory$GsiClientSocket.getInputStre
> > >>>am(SslGsiSocketFactory.java:808) at
> > >>>org.dcache.srm.security.SslGsiSocketFactory$SocketInputStreamWrapper.ret
> > >>>rieveInputIfNeeded(SslGsiSocketFactory.java:503) at
> > >>>org.dcache.srm.security.SslGsiSocketFactory$SocketInputStreamWrapper.rea
> > >>>d(SslGsiSocketFactory.java:517) at
> > >>> java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at
> > >>> java.io.BufferedInputStream.read(BufferedInputStream.java:201) at
> > >>> electric.util.io.Streams.readLine(Unknown Source)
> > >>> at electric.net.http.HTTPRequest.readHeader(HTTPRequest.java:73)
> > >>> at
> > >>>electric.net.http.HTTPOperation.readHeader(HTTPOperation.java:87)
> > >>> at electric.net.http.WebServer.service(WebServer.java:80)
> > >>> at electric.net.socket.SocketServer.run(Unknown Source)
> > >>> at electric.net.socket.SocketRequest.run(Unknown Source)
> > >>> at electric.util.thread.ThreadPool.run(Unknown Source)
> > >>> at java.lang.Thread.run(Thread.java:534)
> > >>>Wed Jan 18 15:48:11 CET 2006 SslGsiSocketFactory :propogating the
> > >>>exception to the caller
> > >>>Wed Jan 18 15:48:13 CET 2006 SslGsiSocketFactory :
> > >>>java.net.SocketException: Connection reset
> > >>> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> > >>> at org.globus.gsi.gssapi.SSLUtil.read(SSLUtil.java:31)
> > >>> at
> > >>>org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readToken(GSIGssInputSt
> > >>>ream.java:58) at
> > >>>org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readHandshakeToken(GSIG
> > >>>ssInputStream.java:48) at
> > >>>org.globus.gsi.gssapi.net.impl.GSIGssSocket.readToken(GSIGssSocket.java:
> > >>>54) at
> > >>>org.globus.gsi.gssapi.net.GssSocket.authenticateServer(GssSocket.java:11
> > >>>7) at
> > >>>org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:137)
> > >>> at
> > >>>org.globus.gsi.gssapi.net.GssSocket.getInputStream(GssSocket.java:161)
> > >>> at
> > >>>org.dcache.srm.security.SslGsiSocketFactory$GsiClientSocket.getInputStre
> > >>>am(SslGsiSocketFactory.java:808) at
> > >>>org.dcache.srm.security.SslGsiSocketFactory$SocketInputStreamWrapper.ret
> > >>>rieveInputIfNeeded(SslGsiSocketFactory.java:503) at
> > >>>org.dcache.srm.security.SslGsiSocketFactory$SocketInputStreamWrapper.rea
> > >>>d(SslGsiSocketFactory.java:517) at
> > >>> java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at
> > >>> java.io.BufferedInputStream.read(BufferedInputStream.java:201) at
> > >>> electric.util.io.Streams.readLine(Unknown Source)
> > >>> at electric.net.http.HTTPRequest.readHeader(HTTPRequest.java:73)
> > >>> at
> > >>>electric.net.http.HTTPOperation.readHeader(HTTPOperation.java:87)
> > >>> at electric.net.http.WebServer.service(WebServer.java:80)
> > >>> at electric.net.socket.SocketServer.run(Unknown Source)
> > >>> at electric.net.socket.SocketRequest.run(Unknown Source)
> > >>> at electric.util.thread.ThreadPool.run(Unknown Source)
> > >>> at java.lang.Thread.run(Thread.java:534)
> > >>>Wed Jan 18 15:48:13 CET 2006 SslGsiSocketFactory :propogating the
> > >>>exception to the caller
> > >>>
> > >>>etc...
> > >>>
> > >>>Running with $SECURITY_DEBUG true doesn't help me - it prints bunch of
> > >>>hex digits in columns, but nothing gives a clue.
> > >>>
> > >>>I understand, that this may be a difficult problem, since if involves
> > >>>interoperability between two systems that work by themselvs. :(
> > >>>
> > >>>But I'd really appreciate any advise and hint in debugging. For example,
> > >>>what makes client give out "Unknown CA" message ?
> > >>>
> > >>>I'll be happy to provide more info on this..
> > >>>
> > >>>Artem.
> > >>>
> > >>>>>>Hi Artem,
> > >>>>>>
> > >>>>>>well, I fear that I am not able to do what I need without installing
> > >>>>>> a world of packages.
> > >>>>>>
> > >>>>>>Here is the latest output I get:
> > >>>>>>
> > >>>>>>---------
> > >>>>>>fabrizio@nbbbrrepro2 16:22:49 ~/Park/JavaSRM/srmclient>bin/srmcp
> > >>>>>>file:////bin/sh srm://nbbbrrepro2:8443//dir1/dir2/sh-copy
> > >>>>>>
> > >>>>>>org.globus.gsi.GlobusCredentialException: Proxy file
> > >>>>>>(/home/fabrizio/k5-ca-proxy.pem) not found.
> > >>>>>> at
> > >>>>>> org.globus.gsi.GlobusCredential.<init>(GlobusCredential.java:93) at
> > >>>>>>org.dcache.srm.security.SslGsiSocketFactory.createUserCredential(SslG
> > >>>>>>siSocketFactory.java:305) at
> > >>>>>>org.dcache.srm.security.SslGsiSocketFactory.createUserCredential(SslG
> > >>>>>>siSocketFactory.java:351) at
> > >>>>>> gov.fnal.srm.util.SRMClient.getGssCredential(SRMClient.java:255) at
> > >>>>>> gov.fnal.srm.util.SRMClient.connect(SRMClient.java:203) at
> > >>>>>> gov.fnal.srm.util.SRMPutClient.connect(SRMPutClient.java:152) at
> > >>>>>> gov.fnal.srm.util.SRMDispatcher.work(SRMDispatcher.java:436) at
> > >>>>>> gov.fnal.srm.util.SRMDispatcher.main(SRMDispatcher.java:200) srm
> > >>>>>> client error: org.globus.gsi.GlobusCredentialException: Proxy file
> > >>>>>> (/home/fabrizio/k5-ca-proxy.pem) not found.
> > >>>>>>---------
> > >>>>>>
> > >>>>>>
> > >>>>>>Is there any easy way to avoid all this? Since I am not interested in
> > >>>>>>testing the authentication stuff, cannot I send formatted get/put
> > >>>>>>requests to the server?
> > >>>>>>
> > >>>>>>Fabrizio
> > >>>>>>
> > >>>>>>Artem Trunov wrote:
> > >>>>>>>Hi, Fabrizio!
> > >>>>>>>
> > >>>>>>>it's srm's port for incoming requests.
> > >>>>>>>
> > >>>>>>>Artem.
> > >>>>>>>
> > >>>>>>>On Fri, 13 Jan 2006, Fabrizio Furano wrote:
> > >>>>>>>>Hi Artem,
> > >>>>>>>>
> > >>>>>>>>Artem Trunov wrote:
> > >>>>>>>>>hi, Fabrizio!
> > >>>>>>>>>
> > >>>>>>>>>>>Yuo can also do usefull stuff with default protocol. Yuo can
> > >>>>>>>>>>> test how your srm interacts with xrootd(s) and what URLs it
> > >>>>>>>>>>> gives out for get/put requests.
> > >>>>>>>>>>
> > >>>>>>>>>>Well, this is my intention but I have no ideas. How can I send a
> > >>>>>>>>>> request to the srm server? Possibly bypassing the scripts.
> > >>>>>>>>>
> > >>>>>>>>>yuo can try srmcp from srmclient package - this is the commandline
> > >>>>>>>>> srm copy tool.
> > >>>>>>>>>
> > >>>>>>>>>srmcp srm://yourserver:8843/path file:/tmp/test1
> > >>>>>>>>
> > >>>>>>>>Well, that's one of the scripts I'd like to bypass.
> > >>>>>>>>Anyway, what's that 8843 port number? Is it needed to contact the
> > >>>>>>>> srm server in the machine "yourserver" ?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>Fabrizio
> > >>>>>>>>
> > >>>>>>>>>I hope it could give some usefull result to you before bumping
> > >>>>>>>>> into luck of grid infrastructure. Although, I am doubtfull, since
> > >>>>>>>>> it needs authorization on the first place... Yuo can also try
> > >>>>>>>>> soap messages directly :( . Timur may give more usufull advise.
> > >>>>>>>>>
> > >>>>>>>>>Artem.
> > >>>>>>>>>
> > >>>>>>>>>>>Yuo don't need to do the actual transfers? I guess. I will set
> > >>>>>>>>>>>up a testbed with classical stogage element and validate the
> > >>>>>>>>>>> transfer.
> > >>>>>>>>>>
> > >>>>>>>>>>In principle I wrote teh java code also for that. I totally
> > >>>>>>>>>> ignore if it works. I don't want to give away code written but
> > >>>>>>>>>> *never* run.... so I believe you have to wait some more time...
> > >>>>>>>>>> sorry. Anyway the deployment is not that hard. But definitely
> > >>>>>>>>>> you need postgres.
> > >>>>>>>>>>
> > >>>>>>>>>>Fabrizio
> > >>>>>>>>>>
> > >>>>>>>>>>>Artem.
> > >>>>>>>>>>>
> > >>>>>>>>>>>On Fri, 13 Jan 2006, Fabrizio Furano wrote:
> > >>>>>>>>>>>>Hi Timur,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>I just managed to get my custom srm server started!
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>But now I have no idea about what to do. Is there a way to
> > >>>>>>>>>>>> inhoculate get/put requests directly to the server to debug
> > >>>>>>>>>>>> it?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>I gave a look at the scripts in the srmclient directory, but I
> > >>>>>>>>>>>> don't believe that they are the answer. Moreover, the protocol
> > >>>>>>>>>>>> matchings are done inside the scripts, so I believe I'd need
> > >>>>>>>>>>>> to modify them all to include a new protocol.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>Thank you
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>Fabrizio
>
|