On Fri, 8 Jul 2005, Graeme A Stewart wrote:
>
> Anyway, regardless of this, I think that migrating to a different SE and
> forcing registration of srm:// SURLs into the catalogs will be better for us
> and the VOs in the long run.
Yes, but if when I upgrade to 2_6_0 I install DPM on a separate machine
with a new certificate, for how long does my *old* classic SE have to be
available and maintained?
This might be something to think about for Friday's phone conf. (assuming
we all go with Steve's postponemenmt idea).
Thanks
Henry
--------------
On Fri, 8 Jul 2005, Graeme A Stewart wrote:
> On Friday 08 July 2005 11:56, owen maroney wrote:
> > Graeme A Stewart wrote:
> > > However, as Henry says, unless you migrate the hostname of the old
> > > classic SE to the new DPM SE then the SURLS will change, at minimum the
> > > hostname will be different (unlike dCache you can probably keep the path
> > > unaltered).
> >
> > Surely the SURLS will have to change regardless of whether the SRM has a
> > DPM or dCache backend? A file registered in an srm must have a SURL like:
> >
> > srm://<srm.host.name>:8443/<some/srm/path>
> >
> > while a file on a classic SE will have SURLS like:
> >
> > sfn://<gsiftp.host.name>:2811/<some/gsiftp/path>
>
> Yes, but DPM and dCache both support gsiftp so I _think_ (caveat, I haven't
> tried it) that an sfn:// SURL should also be valid for an SRM which supports
> gridftp access. I imagine that GFAL, for instance, just translates a classic
> SE SURL, starting sfn://, into a TURL starting gsiftp://. (Unlike an SRM
> where the TURL can be quite different from the SURL.)
>
> Anyway, regardless of this, I think that migrating to a different SE and
> forcing registration of srm:// SURLs into the catalogs will be better for us
> and the VOs in the long run.
>
> Cheers
>
> Graeme
--
Dr. Henry Nebrensky [log in to unmask]
http://people.brunel.ac.uk/~eesrjjn
"The opossum is a very sophisticated animal.
It doesn't even get up until 5 or 6 p.m."
|