On Mon, 17 Jan 2005, Maarten Litmaath, CERN wrote:
> On Mon, 17 Jan 2005, Andreas Unterkircher wrote:
>
> > [...]
> > > -----------------------------------------------------------------------------
> > > $ edg-rm pi
> > > WARNING: GetProtocols: Nothing found in MDS for the seID = oplapro16.cern.ch
> > > This means that either MDS just crashed between two queries or that the
> > > content of the GlueSE and GlueSEAccessProtocol is inconsistent: There is a
> > > GlueSE ID oplapro16.cern.ch but no corresponding entry in the
> > > GlueSEAccessProtocol was found.
> > >
> > > [...]
> > > SE at LCGCERTTB1
> > >
> > > name : LCGCERTTB1
> > > host : lxb1767.cern.ch
> > > type : disk
> > > accesspoint : /flatfiles/LCG-CERT-SE01
> > > VOs : cms, lhcb, sixt, alice, atlas, dteam
> > > VO dir for cms : /cms
> > > VO dir for lhcb : /lhcb
> > > VO dir for sixt : /sixt
> > > VO dir for alice : /alice
> > > VO dir for atlas : /atlas
> > > VO dir for dteam : /dteam
> > > protocols : gsiftp, rfio
> > >
> > > [...]
> > > SE at cern-openlab
> > >
> > > name : cern-openlab
> > > host : oplapro16.cern.ch
> > > type : disk
> > > accesspoint : /storage
> > > VOs : ERROR: Query MDS Query for GlueSA: No entry found or
> > > invalid SE ID for oplapro16.cern.ch
> > > VO dir for ERROR: Query MDS Query for GlueSA: No entry found or invalid SE ID
> > > for oplapro16.cern.ch : /<ERROR>
> > > -----------------------------------------------------------------------------
> > >
> > > The SE needs to be bound to a close CE (oplapro17), which defines the VOs
> > > and their dirs.
> >
> > I'm not sure what you mean by this... could you elaborate ? Is there
> > something missing on the CE or the SE or on both ? E.g. When I do an
> > ldapsearch on oplapro17 I see entries like
> >
> > GlueCESEBindSEUniqueID: oplapro16.cern.ch
> > GlueCESEBindCEUniqueID: oplapro17.cern.ch:2119/jobmanager-lcgpbs-infinite
> > GlueCESEBindCEAccesspoint: /storage
> >
> > This seems to be o.k. ?
>
> Yes, but it is not enough. You also need something on the close CE.
> Compare with SE lxb1767:
>
> $ ldapsearch -x -h lxb1912:2170 -b o=grid | grep '^dn: GlueSARoot=.*lxb1767'
> dn: GlueSARoot=cms:cms,GlueSEUniqueID=lxb1767.cern.ch,mds-vo-name=lcgcerttb1,m
> dn: GlueSARoot=lhcb:lhcb,GlueSEUniqueID=lxb1767.cern.ch,mds-vo-name=lcgcerttb1
> dn: GlueSARoot=sixt:sixt,GlueSEUniqueID=lxb1767.cern.ch,mds-vo-name=lcgcerttb1
> dn: GlueSARoot=alice:alice,GlueSEUniqueID=lxb1767.cern.ch,mds-vo-name=lcgcertt
> dn: GlueSARoot=atlas:atlas,GlueSEUniqueID=lxb1767.cern.ch,mds-vo-name=lcgcertt
> dn: GlueSARoot=dteam:dteam,GlueSEUniqueID=lxb1767.cern.ch,mds-vo-name=lcgcertt
>
> For oplapro16.cern.ch there are no such entries. I will send you a recipe.
Sorry, the CE entries seem to be OK; the GlueSARoot entries come from the SE:
I see you have them defined, but the BDII does not like them, so probably
there is an extra space somewhere; I will look further...
|