Which is why we need release procedures and testing and all that.
FYI, srmcp connects to the web server with an HTTP GET request,
asking for the WSDL - and the path sounds about right, /managerv1.wsdl
(from memory). I don't know that it does anything with it except
to extract the endpoint - the web services endpoint, not the
one published via the SA that is commonly but wrongly referred to
as an endpoint. The web services endpoint is always
https://<host>/srm/managerv1 (which is the URL to which SOAP
encoded requests are HTTP PUT - although the schema might be
httpg).
From your description, it sounds like the server doesn't return
the wsdl which will make srmcp refuse to connect. Try another
client - I don't think GFAL fetches the wsdl. Or FTS.
Cheers,
--jens
-----Original Message-----
From: GRIDPP2: Deployment and support of SRM and local storage
management [mailto:[log in to unmask]]On Behalf Of Kostas
Georgiou
Sent: 06 June 2006 00:21
To: [log in to unmask]
Subject: Re: dCache CA problem
On Mon, Jun 05, 2006 at 04:32:23PM +0100, Greig A Cowan wrote:
> Hi Kostas,
>
> I've also seen the same problem that you report. I've raised it on the
> dCache support list and am waiting for a response.
Good to know that it's not just us.
What worries me is that this is the second time that an update from dcache
broke srm. It makes you wonder if they even test the software before a
release...
Cheers,
Kostas
|