Yes, they are different. I don't know if globus has anything else in it.
cheers
alessandra
On Mon, 11 Jul 2005, Jensen, J (Jens) wrote:
> I bet they are different versions.
>
> /usr/bin/openssl version
> => 0.9.7
> /opt/globus/bin/openssl version
> => 0.9.6
>
> -j
>
>> -----Original Message-----
>> From: GRIDPP2: Deployment and support of SRM and local storage
>> management [mailto:[log in to unmask]]On Behalf Of
>> Alessandra
>> Forti
>> Sent: 11 July 2005 15:53
>> To: [log in to unmask]
>> Subject: It's a globus thing
>>
>>
>> Hi,
>>
>> I discovered the mistery. There are 2 openssl installed: a standard
>> /usr/bin/openssl and a globus /opt/globus/bin/openssl. I
>> don't know if the
>> globus version is modified, recompiled or just older but they give a
>> different output.
>>
>> When /opt/d-cache/bin/grid-mapfile2dcache-kpwd is run by hand
>> it calls the
>> globus one and there is Email= and E= in /opt/d-cache/etc/dcache.kpwd
>>
>> But when it is run by the cron job the standard openssl is
>> called because
>> the path doesn't contain /opt/globus/bin and we get the standard
>> emailAddress= in /opt/d-cache/etc/dcache.kpwd which
>> mismatches other parts
>> of the code (I haven't looked into this yet and don't know if
>> I want to).
>>
>> The simplest way to correct this is to add /opt/globus/bin at the
>> beginning of the path in /etc/cron.d/edg-mkgridmap.
>>
>> /opt/lcg/libexec/lcg-info-wrapper does work now but there is
>> still the problem of the ldif cache file being zero and
>> therefore ldap
>> doesn't pick it up.
>>
>> cheers
>> alessandra
>>
>> On Fri, 8 Jul 2005, owen maroney wrote:
>>
>>> And for IC we have:
>>>
>>> mapping
>>>
>> "/C=UK/O=eScience/OU=Imperial/L=Physics/CN=gfe02.hep.ph.ic.ac.
>> [log in to unmask]"
>>> edginfo
>>>
>>> login edginfo read-write 19491 19491 / / /
>>>
>>>
>> /C=UK/O=eScience/OU=Imperial/L=Physics/CN=gfe02.hep.ph.ic.ac.u
>> [log in to unmask]
>>>
>>> So, I try replacing this with:
>>>> mapping
>>>>
>> "/C=UK/O=eScience/OU=Imperial/L=Physics/CN=gfe02.hep.ph.ic.ac.
>> [log in to unmask]"
>>>> edginfo
>>>>
>>>> login edginfo read-write 19491 19491 / / /
>>>>
>> /C=UK/O=eScience/OU=Imperial/L=Physics/CN=gfe02.hep.ph.ic.ac.u
>> [log in to unmask]
>>>
>>> then
>>>
>>> su - edginfo
>>>> [edginfo@gfe02 edginfo]$
>> /opt/d-cache/srm/bin/srm-storage-element-info
>>>> https://gfe02.hep.ph.ic.ac.uk:8443/srm/infoProvider1_0.wsdl
>>>
>>> produces stuff ending with:
>>>
>>>> StorageElementInfo :
>>>> totalSpace =2541546897408 (2481979392 KB)
>>>> usedSpace =30397658395 (29685213 KB)
>>>> availableSpace =2502704826621 (2444047682 KB)
>>>
>>> Hurrah! (although this will get overwritten at the next
>> edg-mkgridmap
>>> update...)
>>>
>>> However, although now when I run, as edginfo:
>>>> [edginfo@gfe02 edginfo]$ /opt/lcg/libexec/lcg-info-dynamic-se
>>>
>>> I get a 3 second pause and output like:
>>>> dn:
>>>>
>> GlueSARoot=lhcb:/pnfs/hep.ph.ic.ac.uk/data/lhcb,GlueSEUniqueID
>> =gfe02.hep.ph.ic.ac.uk,Mds-Vo-name=local,o=grid
>>>> GlueSAStateAvailableSpace: 2444047682
>>>> GlueSAStateUsedSpace: 37931710
>>>
>>> when I run, as edginfo, /opt/lcg/libexec/lcg-info-wrapper,
>> it takes less than
>>> a second and produces output including:
>>>> GlueSAStateAvailableSpace: 00
>>>> GlueSAStateUsedSpace: 00
>>> in the output. I checked /opt/lcg/var/gip/tmp and the file
>>> lcg-info-dynamic-dcache.ldif.7010 is being updated but is
>> only zero sized.
>>>
>>> So the output of the dynamic-se script does not seem to be getting
>>> incorporated into the output of the wrapper script.
>>>
>>> cheers,
>>> Owen.
>>>
>>> Alessandra Forti wrote:
>>>> no I have
>>>>
>>>> mapping
>>>>
>> "/C=UK/O=eScience/OU=Manchester/L=HEP/CN=bohr0013.tier2.hep.ma
>> [log in to unmask]"
>>>> edginfo
>>>>
>>>> login edginfo read-write 18948 18948 / / /
>>>>
>>>>
>> /C=UK/O=eScience/OU=Manchester/L=HEP/CN=bohr0013.tier2.hep.man
>> [log in to unmask]
>>>>
>>>> cheers
>>>> alessandra
>>>>
>>>> On Fri, 8 Jul 2005, Steve Traylen wrote:
>>>>
>>>>> On Thu, Jul 07, 2005 at 04:54:33PM +0100 or thereabouts,
>> Philip Clark
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>
>>>>>>> I don't think we have a workaround, it just works?
>>>>>>>
>>>>>>> I expect you have mentioned it before but what is the problem?
>>>>>>
>>>>>>
>>>>>> http://savannah.cern.ch/bugs/?func=detailitem&item_id=8777
>>>>>>
>>>>>> We need to understand why you are not seeing this bug.
>> IC, Manchester
>>>>>> and Edinburgh all seem to have it. If we try to monitor
>> your storage
>>>>>> through the lcg information system then I expect it will
>> show up too.
>>>>>
>>>>>
>>>>> Does your dcache.kpwd contain
>>>>>
>>>>>
>> /C=UK/O=eScience/OU=Manchester/L=HEP/CN=bohr0013.tier2.hep.man
>> [log in to unmask]
>>>>>
>>>>> i.e are you seeing this one.
>>>>>
>>>>> https://savannah.cern.ch/bugs/?func=detailitem&item_id=5295
>>>>>
>>>>> but I'm sure I have already asked this question twice so
>> feel free to
>>>>> scream if we are going through the same loop?
>>>>>
>>>>> Steve
>>>>>
>>>>>>
>>>>>> -Phil
>>>>>
>>>>>
>>>>> --
>>>>> Steve Traylen
>>>>> [log in to unmask]
>>>>> http://www.gridpp.ac.uk/
>>>>>
>>>>
>>>
>>> -- =======================================================
>>> Dr O J E Maroney # London Tier 2 Technical Co-ordinator
>>>
>>> Tel. (+44)20 759 47802
>>>
>>> Imperial College London
>>> High Energy Physics Department
>>> The Blackett Laboratory
>>> Prince Consort Road, London, SW7 2BW
>>> ====================================
>>>
>>
>> --
>> ********************************************
>> * Dr Alessandra Forti *
>> * Technical Coordinator - NorthGrid Tier2 *
>> * http://www.hep.man.ac.uk/u/aforti *
>> ********************************************
>>
>
--
********************************************
* Dr Alessandra Forti *
* Technical Coordinator - NorthGrid Tier2 *
* http://www.hep.man.ac.uk/u/aforti *
********************************************
|