Hi Frederic,
At CGG-LCG2 we are in the same situation. I mean your information server
is publishing that your LFC server suports EGEODE VO and this is making
lcg-cr command to fail, it gives
$> lcg-cr --vo egeode -d se1.egee.fr.cgg.com
file:///tmp/ldap/.ces_ses.25173 -l lfn:/grid/egeode/ahmed_test_lfc_double
LRC endpoint not found
RMC endpoint not found
lcg_cr: Invalid argument
I don't know if the reason of this is the duplicated publication of LFC
service because you publish it as a local lfc.
As you can see below, the GRIF site does the same publication of lfc
service.
Any way, LFC server for EGEODE must only be published by CGG bdii (GIIS)
server even if the lcg-cr error we are having is not a consequence of
this. So could you delete this from your information system to let us
investigate esasily this problem ?
Could LAL administrators do the same thing please ?
We had the same problem months ago and to resolve it I edited the file
/opt/lcg/var/gip/lcg-info-generic.conf and
/opt/lcg/var/gip/lcg-info-static.ldif on the SE host. I deleted
manually unuseful information.
Thank you Frederic,
Cheers,
Ahmed
$> ldapsearch -xLLL -H ldap://rb1.egee.fr.cgg.com:2170 -b o=grid
"(&(GlueServiceType=lcg-*file-catalog)
(GlueServiceAccessControlRule=egeode))"
dn:
GlueServiceUniqueID=grid07.lal.in2p3.fr,mds-vo-name=GRIF,mds-vo-name=local
,o=grid
objectClass: GlueTop
objectClass: GlueService
objectClass: GlueKey
objectClass: GlueSchemaVersion
GlueServiceUniqueID: grid07.lal.in2p3.fr
GlueServiceName: GRIF-lfc
GlueServiceType: lcg-local-file-catalog
GlueServiceVersion: 1
GlueServiceEndpoint: grid07.lal.in2p3.fr
GlueServiceURI: grid07.lal.in2p3.fr
GlueServiceAccessPointURL: grid07.lal.in2p3.fr
GlueServiceStatus: running
GlueServiceOwner: alice
GlueServiceOwner: atlas
GlueServiceOwner: biomed
GlueServiceOwner: cms
GlueServiceOwner: dteam
GlueServiceOwner: esr
GlueServiceOwner: egeode
GlueServiceOwner: lhcb
GlueServiceOwner: planck
GlueServiceOwner: ilc
GlueServiceOwner: lal
GlueServiceOwner: grif
GlueServiceOwner: hone
GlueServiceAccessControlRule: alice
GlueServiceAccessControlRule: atlas
GlueServiceAccessControlRule: biomed
GlueServiceAccessControlRule: cms
GlueServiceAccessControlRule: dteam
GlueServiceAccessControlRule: esr
GlueServiceAccessControlRule: egeode
GlueServiceAccessControlRule: lhcb
GlueServiceAccessControlRule: planck
GlueServiceAccessControlRule: ilc
GlueServiceAccessControlRule: vo.lal.in2p3.fr
GlueServiceAccessControlRule: vo.grif.fr
GlueServiceAccessControlRule: hone
GlueForeignKey: GlueSiteUniqueID=GRIF
GlueSchemaVersionMajor: 1
GlueSchemaVersionMinor: 2
dn:
GlueServiceUniqueID=se1.egee.fr.cgg.com,mds-vo-name=CGG-LCG2,mds-vo-name=l
ocal,o=grid
objectClass: GlueTop
objectClass: GlueService
objectClass: GlueKey
objectClass: GlueSchemaVersion
GlueServiceUniqueID: se1.egee.fr.cgg.com
GlueServiceName: CGG-LCG2-lfc
GlueServiceType: lcg-file-catalog
GlueServiceVersion: 1
GlueServiceEndpoint: se1.egee.fr.cgg.com
GlueServiceURI: se1.egee.fr.cgg.com
GlueServiceAccessPointURL: se1.egee.fr.cgg.com
GlueServiceStatus: running
GlueServiceOwner: egeode
GlueServiceAccessControlRule: egeode
GlueForeignKey: GlueSiteUniqueID=CGG-LCG2
GlueSchemaVersionMajor: 1
GlueSchemaVersionMinor: 2
dn:
GlueServiceUniqueID=cclcglfcli02.in2p3.fr,o=local,mds-vo-name=IN2P3-CC,mds
-vo-name=local,o=grid
objectClass: GlueTop
objectClass: GlueService
objectClass: GlueKey
objectClass: GlueSchemaVersion
GlueServiceUniqueID: cclcglfcli02.in2p3.fr
GlueServiceName: IN2P3-CC-lfc
GlueServiceType: lcg-local-file-catalog
GlueServiceVersion: 1.0.0
GlueServiceEndpoint: cclcglfcli02.in2p3.fr
GlueServiceURI: cclcglfcli02.in2p3.fr
GlueServiceAccessPointURL: cclcglfcli02.in2p3.fr
GlueServiceStatus: OK
GlueServiceStatusInfo: No Problems
GlueServiceWSDL: unset
GlueServiceSemantics: unset
GlueServiceStartTime: 1970-01-01T00:00:00Z
GlueServiceOwner: atlas
GlueServiceOwner: alice
GlueServiceOwner: lhcb
GlueServiceOwner: cms
GlueServiceOwner: dteam
GlueServiceOwner: esr
GlueServiceOwner: egeode
GlueServiceOwner: virgo
GlueServiceOwner: dzero
GlueServiceOwner: cdf
GlueServiceAccessControlRule: atlas
GlueServiceAccessControlRule: alice
GlueServiceAccessControlRule: lhcb
GlueServiceAccessControlRule: cms
GlueServiceAccessControlRule: dteam
GlueServiceAccessControlRule: esr
GlueServiceAccessControlRule: egeode
GlueServiceAccessControlRule: virgo
GlueServiceAccessControlRule: dzero
GlueServiceAccessControlRule: cdf
GlueForeignKey: GlueSiteUniqueID=IN2P3-CC
GlueSchemaVersionMajor: 1
GlueSchemaVersionMinor: 2
Frederic Schaer wrote:
> Hmmm... I did not see the IN2P3-CC "GlueServiceType:
> lcg-_local_-file-catalog" - so this is not the cause of your problem...
>
> Frederic Schaer wrote:
>
>> Hi,
>>
>> When running manually, are you using LFC ? Which LFC_HOST ?
>>
>> Don't know why, but it seems there are duplicate LFC servers - even
>> if gstat does not show that.
>> Looking at an ldapsearch on a bdii, I see the CERN lfc for dteam...
>> and the IN2P3-CC one (which should be local, I doubt it should be
>> published like that - I see no other dteam lfc in the bdiis...).
>>
>> Same for other VOs.
>>
>> Errrhhh... sorry about this, going to disable this ASAP.
>>
>> Cheers,
>> Fred
>>
>> Yongzheng wrote:
>>
>>> Dear all,
>>>
>>> Our site (BEIJING-CNIC-LCG2-IA64) has been failing to pass the
>>> "sft-lcg-rm-cr" and other SFT tests since March 3rd. However, when I
>>> run all
>>> of those commands (sft-lcg-rm-cr, sft-lcg-rm-cp, sft-lcg-rm-rep,
>>> sft-lcg-rm-del) in our UI, everything is ok. Why? What should I do?
>>>
>>> Thank you in advance!
>>>
>>> Best wishes.
>>>
>>> Yongzheng
>>>
>>>
>>>
>>
|