 |
 |
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...