 |
|
You are here: Foswiki>ITB Web>NewLFCTesting (03 Jul 2011, MarcoMambelli)Edit Attach
Testing the new LFC package from VDT
Introduction
This page presents the tests on the new LFC package from VDT providing python LFC bindings for Python 2.4, 2.5 and 2.6 in both 32 and 64bit. These are some notes, no the installation document for any of the packages (see the references).Packages
Some Pacman packages have been prepared Wlcg client form the alternative VDT test cache Python 32 bitInstallation
Requirements:- RHEL 5 based OS, 32 or 64bit
pacman -get http://www.mwt2.org/caches/:wlcg-client-1.7rc2.pacmanMake sure that packages are downloaded by these caches (answer 'y' each time instead of 'yall' once to check the caches):
Do you want to add [http://www.mwt2.org/caches/] Do you want to add [http://vdt.cs.wisc.edu/test-cache/lfc]Don't worry if you see these messages, they are OK:
All prerequisite checks are satisfied. vdt-register-service: registered cron service 'fetch-crl' vdt-register-service: desired state = disable vdt-register-service: cron time = '41 5,11,17,23 * * *' vdt-register-service: cron command = '/opt/wlcg-client-17rc2-110606/fetch-crl/share/doc/fetch-crl-2.8.5/fetch-crl.cron' INFO: The Globus-Base-Info-Client package is not supported on this platformComplete the installation with the post-install and the certificates.
[root@ui-gwms wlcg-client-17rc2-110606]# . ./setup.sh [root@ui-gwms wlcg-client-17rc2-110606]# vdt-post-install Starting... Done. Making log symlinks in /opt/wlcg-client-17rc2-110606/logs [root@ui-gwms wlcg-client-17rc2-110606]# vdtmanage setupca --location local --url osg Setting up CA Certificates for VDT installation at '/opt/wlcg-client-17rc2-110606' CA Certificates will be installed into /opt/wlcg-client-17rc2-110606/globus/share/certificates Setup completed successfully.Python 32bit, used for testing:
pacman -get http://www.mwt2.org/caches/:Python32bit26and
pacman -get http://www.mwt2.org/caches/:Python32bit25
Setup
Source the setup files and initialize a proxy:. /opt/wlcg-client/setup.sh . /opt/DQ2Client/setup.sh voms-proxy-init -voms atlasYou'll see something like:
Enter GRID pass phrase: Your identity: /DC=org/DC=doegrids/OU=People/CN=Marco Mambelli 325802 Creating temporary proxy ......................................................................................................... Done Contacting lcg-voms.cern.ch:15001 [/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch] "atlas" Done Creating proxy .................................................................................................................... Done Your proxy is valid until Tue Jun 7 04:41:36 2011
Some tests
Control the python version and testlfc import: which python python -c "import platform,sys; print sys.version; print platform.architecture()" python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"Some errors:
- if the module is not in the PYTHONPATH
ImportError: No module named lfc
dq2-ls --version $Revision: 1.14 $Here some dq2 commands:
dq2-ls -L ROAMING step09.20201123000004L.physics* dq2-ls -L MWT2_DATADISK -f -p step09.20201123000004L.physics_C.recon.AOD.closedPossible errors:
- if the right version of the module is not in the PYTHONPATH (either missing or wrong version - try the import command to see more)
LFC exception [Python bindings missing]
- Wrong binding version:
Traceback (most recent call last): File "
", line 1, in File "/opt/wlcg-client-17rc2-110606/lcg/lib64/python2.4/site-packages/lfc.py", line 5, in import _lfc ImportError: /opt/wlcg-client-17rc2-110606/lcg/lib64/python2.4/site-packages/_lfc.so: undefined symbol: Py_InitModule4 - 32/64bit mismatch:
Traceback (most recent call last): File "
", line 1, in ? File "/opt/wlcg-client-17rc2-110606/lcg/lib64/python2.6/site-packages/lfc.py", line 5, in ? import _lfc ImportError: /opt/wlcg-client-17rc2-110606/lcg/lib64/python2.6/site-packages/_lfc.so: wrong ELF class: ELFCLASS64 bash-3.2$
step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK is another one. I used DQ2 dashboard (at MWT2_DATADISK or at WISC_LOCALGROUPDISK) and selected a dataset that recently completed the transfer.
Package changes
Change the lfc binding to dynamically load the correct compiled binding. The attached script does the changes. The directories$VDT_LOCATION/lcg/lib/python2/site-packages and $VDT_LOCATION/lcg/lib64/python2/site-packages contain the exact same files and any of the 2 can be added to the PYTHONPATH (ahead of other directories containing LFC bindings). $VDT_LOCATION/lcg/lib64/python2.4/site-packages is still necessary for the other LCG utilities:
PYTHON_LIB=$VDT_LOCATION/lcg/lib/python2/site-packages export PYTHONPATH=$PYTHON_LIB:$VDT_LOCATION/lcg/lib64/python2.4/site-packages:$PYTHONPATHAppli the patch (make the file executable):
export $VDT_LOCATION=your_vdt_location cp changes.sh $VDT_LOCATION/lcg/etc/ $VDT_LOCATION/lcg/etc/changes.shTest results after applying the patch. As visible in the test I can setup different python version and the correct binding is selected.
bash-3.2$ . /opt/wlcg-client/setup.sh
bash-3.2$ . /opt/DQ2Client/setup.sh
bash-3.2$ which python
/usr/bin/python
bash-3.2$ python -c "import platform,sys; print sys.version; print platform.architecture()"
2.4.3 (#1, Jan 13 2011, 20:52:03)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
('64bit', 'ELF')
bash-3.2$ python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2.4/site-packages/_lfc.so
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2/site-packages/lfc.py
bash-3.2$ export PATH=/opt/python/bin/:$PATH
bash-3.2$ which python
/opt/python/bin/python
bash-3.2$ python -c "import platform,sys; print sys.version; print platform.architecture()"
2.6.5 (r265:79063, Feb 28 2011, 21:55:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)]
('64bit', 'ELF')
bash-3.2$ python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2.6/site-packages/_lfc.so
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2/site-packages/lfc.py
The remaining problem is that all the libraries required by the binding should be in the path.
This is not true is you try a 32bit python in a 64bit installation of the client.
Workarounds
Test after installing both 32bit LFC and 64bit wlcg-client. Install of 32bit LFC:pacman -pretend-arch i686 -get http://vdt.cs.wisc.edu/test-cache/lfc:LFC-InterfacesTest (works after restoring LD_LIBRARY_PATH)
Last login: Fri Jun 10 10:12:25 2011 from nsit-dhcp-250-247.uchicago.edu
-bash-3.2$ . /opt/lfc-32bit/setup.sh
-bash-3.2$ . /opt/wlcg-client/setup.sh
-bash-3.2$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/lfc-32bit-110610/globus/lib
-bash-3.2$ . /opt/DQ2Client/setup.sh
-bash-3.2$ which python
/usr/bin/python
-bash-3.2$ python -c "import platform,sys; print sys.version; print platform.architecture()"
2.4.3 (#1, Jan 13 2011, 20:52:03)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
('64bit', 'ELF')
-bash-3.2$ python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2.4/site-packages/_lfc.so
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2/site-packages/lfc.py
-bash-3.2$ export PATH=/opt/python/bin/:$PATH
-bash-3.2$ which python
/opt/python/bin/python
-bash-3.2$ python -c "import platform,sys; print sys.version; print platform.architecture()"
2.6.5 (r265:79063, Feb 28 2011, 21:55:45)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)]
('64bit', 'ELF')
-bash-3.2$ python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2.6/site-packages/_lfc.so
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2/site-packages/lfc.py
-bash-3.2$ . /opt/python
python/ python24-i386/ python25-i386/ python26-i386/ python27-i386/
-bash-3.2$ . /opt/python25-i386/setup.sh
-bash-3.2$ which python
/opt/python25-i386/python25i386/bin/python
-bash-3.2$ python -c "import platform,sys; print sys.version; print platform.architecture()"
2.5.6 (r256:88840, Jun 6 2011, 17:53:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)]
('32bit', 'ELF')
-bash-3.2$ python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"
/opt/wlcg-client-17rc2-110606/lcg/lib/python2.5/site-packages/_lfc.so
/opt/wlcg-client-17rc2-110606/lcg/lib64/python2/site-packages/lfc.py
PATH change only works as well:Last login: Fri Jun 10 10:41:27 2011 from nsit-dhcp-250-247.uchicago.edu -bash-3.2$ . /opt/wlcg-client/setup.sh -bash-3.2$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/lfc-32bit-110610/globus/lib -bash-3.2$ . /opt/DQ2Client/setup.sh -bash-3.2$ which python
Package 20110624
Tests
Error:$ dq2-ls -L NET2_DATADISK -f -p step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK send2nsd: NS002 - send error : Csec_get_shlib: Error opening shared library libCsec_plugin_GSI.so: libCsec_plugin_GSI.so: wrong ELF class: ELFCLASS64 LFC exception [Cannot connect to LFC [lfc://atlas007.bu.edu:/grid/atlas]] 3Error missing expat:
$ dq2-ls -L NET2_DATADISK -f -p step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK send2nsd: NS002 - send error : Csec_get_shlib: Error opening shared library libCsec_plugin_GSI.so: libexpat.so.1: wrong ELF class: ELFCLASS64 LFC exception [Cannot connect to LFC [lfc://atlas007.bu.edu:/grid/atlas]] 3Error missing glite library:
$ dq2-ls -L NET2_DATADISK -f -p step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK send2nsd: NS002 - send error : Could not load a security plugin LFC exception [Cannot connect to LFC [lfc://atlas007.bu.edu:/grid/atlas]] 3To fix these and get correct result:
Last login: Mon Jun 27 11:33:48 2011 from nsit-dhcp-250-247.uchicago.edu -bash-3.2$ . /opt/wlcg-client-17rc4-110627/setup.sh -bash-3.2$ . /opt/DQ2Client/setup.sh -bash-3.2$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/lib32addon/lcg32lib:/opt/lib32addon/glite32lib:/opt/lib32addon/expat32lib -bash-3.2$ dq2-ls -L NET2_DATADISK -f -p step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0003._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0001._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0002._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0005._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0004._0001_1286528526 total files: 5 total size: 100000000 date: 2010-10-08 09:20:52 -bash-3.2$ export PATH=$PATH:/opt/python/bin/ -bash-3.2$ dq2-ls -L NET2_DATADISK -f -p step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0003._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0001._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0002._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0005._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0004._0001_1286528526 total files: 5 total size: 100000000 date: 2010-10-08 09:20:52 -bash-3.2$ . /opt/python25-i386/setup.sh -bash-3.2$ dq2-ls -L NET2_DATADISK -f -p step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0003._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0001._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0002._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0005._0001_1286528526 srm://atlas.bu.edu/gpfs1/atlasdatadisk/step09/AOD/LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK/step09.50000030.sonar_1.sonar.AOD.LIP-LISBON_DATADISK._lb0004._0001_1286528526 total files: 5 total size: 100000000 date: 2010-10-08 09:20:52 -bash-3.2$
Solution
Include also lcg (except perl and python trees), glite and expat libraries from the 32bit installation.Finding hidden dependencies
LFC bindings seem to have dependencies not visible in ldd. Here what happens invoking it in python:$ python
Python 2.5.6 (r256:88840, Jun 6 2011, 17:53:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> _lfc = __import__('lfcthr')
>>> _lfc.init()
0
>>> _lfc.lfc_startsess('atlas007.bu.edu', '')
send2nsd: NS002 - send error : Csec_get_shlib: Error opening shared library libCsec_plugin_GSI.so: libCsec_plugin_GSI.so: wrong ELF class: ELFCLASS64
-1
But libCsec_plugin_GSI is not in ldd:$ ldd /opt/wlcg-client-17rc4-110627/lcg/lib/python2.5/site-packages/_lfcthr.so linux-gate.so.1 => (0xffffe000) libglobus_gssapi_gsi_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gssapi_gsi_gcc32dbgpthr.so.0 (0xf768f000) libglobus_gss_assist_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gss_assist_gcc32dbgpthr.so.0 (0xf7682000) libdl.so.2 => /lib/libdl.so.2 (0xf7672000) libnsl.so.1 => /lib/libnsl.so.1 (0xf7659000) libc.so.6 => /lib/libc.so.6 (0xf7500000) libglobus_gsi_proxy_core_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gsi_proxy_core_gcc32dbgpthr.so.0 (0xf74f1000) libglobus_gsi_credential_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gsi_credential_gcc32dbgpthr.so.0 (0xf74e1000) libglobus_gsi_callback_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gsi_callback_gcc32dbgpthr.so.0 (0xf74d6000) libglobus_oldgaa_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_oldgaa_gcc32dbgpthr.so.0 (0xf74cd000) libglobus_gsi_sysconfig_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gsi_sysconfig_gcc32dbgpthr.so.0 (0xf74c0000) libglobus_gsi_cert_utils_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_gsi_cert_utils_gcc32dbgpthr.so.0 (0xf74bb000) libglobus_openssl_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_openssl_gcc32dbgpthr.so.0 (0xf74b9000) libglobus_openssl_error_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_openssl_error_gcc32dbgpthr.so.0 (0xf74b4000) libglobus_proxy_ssl_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_proxy_ssl_gcc32dbgpthr.so.0 (0xf74b0000) libglobus_common_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_common_gcc32dbgpthr.so.0 (0xf7475000) libltdl_gcc32dbgpthr.so.3 => /opt/wlcg-client-17rc4-110627/globus/lib/libltdl_gcc32dbgpthr.so.3 (0xf746d000) libssl.so.6 => /lib/libssl.so.6 (0xf7425000) libcrypto.so.6 => /lib/libcrypto.so.6 (0xf72e3000) libz.so.1 => /usr/lib/libz.so.1 (0xf72d0000) libpthread.so.0 => /lib/libpthread.so.0 (0xf72b7000) libglobus_callout_gcc32dbgpthr.so.0 => /opt/wlcg-client-17rc4-110627/globus/lib/libglobus_callout_gcc32dbgpthr.so.0 (0xf72b3000) /lib/ld-linux.so.2 (0x49f9b000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7284000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf71ed000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xf71ea000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf71c3000) libresolv.so.2 => /lib/libresolv.so.2 (0xf71af000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf71a5000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xf71a2000) libselinux.so.1 => /lib/libselinux.so.1 (0xf718a000) libsepol.so.1 => /lib/libsepol.so.1 (0xf7144000)Then checking the dependencies:
- libCsec_plugin_GSI (beside system and Globus dependencies) depends on
libvomsapi_gcc32dbgpthr.so.0 - libvomsapi_gcc32dbgpthr (beside system and Globus dependencies) depends on
libexpat.so.1
Marco Mambelli writes:
> Charles, all,
> in working with the LFC-Client I found that _lfc.so (and others lcg
> shared objects) depend on shared libraries not appearing in the output of
> "ldd _lfc.so" (or "ldd filename").
>
> It seems that the dependency is not actually in the list.
> Do you know how this works?
It's 'dlopen' - see 'man dlopen' - you can use this to open any
dynamic object file at any time - this is completely independent
of ld.so, which handles the compiled-in dependencies (the ones
reported by ldd).
> Do I have any way to find statically all the libraries that can be loaded
> this way?
In general, the answer is "no", because the argument to dlopen could be computed
at run-time, or read in from some config file, and it could be any string - you
just have no idea a priori. But in practice, you can usually figure out what's
going on. Following my nose a bit here ....
running 'strings' on the library looking for 'lib':
/wn-client/lcg/lib64/python$ strings _lfc.so |grep lib
Csec_unload_shlib
Csec_get_shlib
libglobus_gssapi_gsi_gcc64dbgpthr.so.0
libglobus_gss_assist_gcc64dbgpthr.so.0
libdl.so.2
libnsl.so.1
libc.so.6
Csec_unload_shlib
Csec_get_shlib
Forcing unload of shlib
Could not find library in linked list. Will try to load it
libCsec_plugin_%s
Using shared library <%s> for mechanism <%s>
Error opening shared library %s: %s
Error opening shared library %s: %s
Using previously loaded library for %s
looking at the sources:
$ cd ~/LFC_SOURCE$
$ find . -type f | xargs grep dlopen
./LCG-DM/dicomcopy/dicomcopy_serv.c: if ((dlhandle = dlopen ("libdpm_dicom.so", RTLD_NOW)) == NULL) {
./LCG-DM/security/Csec_api_loader.c: handle = dlopen(filename_thread, RTLD_NOW);
./LCG-DM/security/Csec_api_loader.c: handle = dlopen(filename, RTLD_NOW);
I don't think 'libdpm_dicom.so' is relevant (DPM is a storage system,
'distributed pool manager', which AFAIK is not used in the US. We
need to check that though)
I think it's the dlopen's in Csec_api_loader.c that are getting us -
Here's the section where this happens:
/* Creating the library name */
snprintf(filename, CA_MAXNAMELEN, "libCsec_plugin_%s", ctx->protocols[ctx->current_protocol].id);
strcpy(filename_thread,filename);
#if defined(__APPLE__)
strcat(filename,".dylib");
strcat(filename_thread,"_thread.dylib");
#else
strcat(filename,".so");
strcat(filename_thread,"_thread.so");
#endif
handle = NULL;
if (ctx->thread_safe && ! csec_nothread ) {
Csec_trace(func, "Using shared library <%s> for mechanism <%s>\n",
filename_thread,
ctx->protocols[ctx->current_protocol].id);
handle = dlopen(filename_thread, RTLD_NOW);
}
if (handle == NULL) {
Csec_trace(func, "Using shared library <%s> for mechanism <%s>\n",
filename,
ctx->protocols[ctx->current_protocol].id);
handle = dlopen(filename, RTLD_NOW);
}
So the file is libCsec_plugin_something but I'm not sure what
'something' is. We might use 'ltrace' on a working setup to
catch the dlopen's (or use 'strace' and see the underlying 'open'
and 'mmap' system calls) and get the libs from there.
Actually, maybe best to just grab all the libs with names like this,
there aren't too many:
./lib64/libCsec_plugin_GSI.so.1.7.4
./lib64/libCsec_plugin_ID.so
./lib64/libCsec_plugin_ID.so.1.7.4
./lib64/libCsec_plugin_GSI_thread.so
./lib64/libCsec_plugin_GSI.so
./lib64/libCsec_plugin_GSI_thread.so.1.7.4
(and also the corresponding 32-bit versions as well, I got this
list from a 64-bit host)
Hope this helps,
- Charles
In the wn-client there is the problem that the ATHENA setup is removing expat from LD_LIBRARY_PATH (problem solved with ATLAS-OSG-compat for 64 bit). These jobs (ATHENA 16.2 and 16.4) failed: - http://panda.cern.ch/server/pandamon/query?job=1263577785
- error: http://voatlas141.cern.ch:25980/monitor/logs/302636bf-6026-47b5-9ea8-1913596ba48a/tarball_PandaJob_1263577785_ANALY_MWT2/prun_stdout.txt
WN client discussion test
Latest test
which python
python -c "import platform,sys; print sys.version; print platform.architecture()"
python -c "import lfc; print lfc._lfc.__file__; print lfc.__file__"
python -c "_lfc = __import__('lfcthr'); _lfc.init(); _lfc.lfc_startsess('atlas007.bu.edu', '')"
Setup wlcg-client+dq2-client
For WN environment setup wn-client, then atlaswn, then Athena, e.g. on c100:
. /share/wn-client/setup.sh . /osg/app/atlas_app/atlaswn/setup.sh export FRONTIER_ID="[1263577785]";export CMSSW_VERSION=$FRONTIER_ID;source /osg/app/atlas_app/atlas_rel//16.6.2/setup.sh;source /osg/app/atlas_app/atlas_rel/16.6.2/cmtsite/asetup.sh 16.6.2,notest --cmtconfig i686-slc5-gcc43-optATLAS-OSG-compat-0.2 has been accommodated to protect both 64 and 32bit versions of expat. Not put into production yet.
VDT file selection using PLATFORM
This code in Pacman allows dynamic file names in the download command:
def resolve_url_macro(url):
global archMap
global osMap
global loaded_mapping
# Resolve the macro, if it exists
if url.find("@@PLATFORM@@") >= 0:
# Load the arch and OS mappings
if loaded_mapping == 0 and len(archMap) == 0:
load_platform_mappings()
loaded_mapping = 1
platform_string = None
if len(archMap) == 0:
print "ERROR: No platform mapping exists"
return url
# Get mapped architecture
mapped_arch = None
arch = Platform.thisArch()
if archMap.has_key(arch):
mapped_arch = archMap[arch]
Names are like: x86_rhap_5 or x86_64_rhap_5.
Uses in ATLAS
When setting up DQ2 clients in Lxplus, it sets up also the grid environment (gLite UI 3.2.8-0) and python 2.5 32bit:[lxplus418] /afs/cern.ch/user/m/mambelli > source /afs/cern.ch/atlas/offline/external/GRID/ddm/DQ2Clients/setup.sh - Enabled current AFS CERN GRID SLC5 UI - Enabled Python 2.5 - Configured local site - Enabled DQ2 Clients -- IMPORTANT -- IMPORTANT -- IMPORTANT -- IMPORTANT -- IMPORTANT -- If you have not done so already, execute: voms-proxy-init -voms atlas -- IMPORTANT -- IMPORTANT -- IMPORTANT -- IMPORTANT -- IMPORTANT -- If you have any questions, go to: https://twiki.cern.ch/twiki/bin/view/Atlas/DQ2ClientsHowTo ReadyThis section from the setup file shows the behavior for SL5:
- if pyhton 2.6 is in the path, then add the bindings
- else add python 2.5 32bit in the path and add the bindings
- in both case run the setup for the grid client
- note that the binding are always 32bit. This will not work with 64bit python (2.6, other versions are overridden by adding the 2.5 32bit one in the path)
if [[ "${distribution}" = "Scientific Linux CERN SLC release 5"*||"${distribution}" = "Scientific Linux SL release 5"* ]]; then
source /afs/cern.ch/project/gd/LCG-share/sl5/external/etc/profile.d/grid-env.sh
echo " - Enabled current AFS CERN GRID SLC5 UI"
if [[ "${pyver}" = "2.6"* ]]; then
echo " - Enabled Python 2.6"
. /afs/cern.ch/project/gd/LCG-share/3.2.1-0/external/etc/profile.d/grid-env-funcs.sh
gridpath_prepend "PYTHONPATH" "/afs/cern.ch/sw/lcg/external/Grid/dm-util/1.7.6-2/i686-slc5-gcc43-opt/lib/python2.5/
site-packages"
gridpath_prepend "PYTHONPATH" "/afs/cern.ch/sw/lcg/external/Grid/gfal/1.11.8-3/i686-slc5-gcc43-opt/lib/python2.5/si
te-packages"
gridpath_prepend "PYTHONPATH" "/afs/cern.ch/sw/lcg/external/Grid/LFC/1.7.2-5sec/i686-slc5-gcc43-opt/lib/python2.5/s
ite-packages"
gridpath_prepend "LD_LIBRARY_PATH" "/afs/cern.ch/sw/lcg/external/Grid/lcg-dm-common/1.7.3-1sec/x86_64-slc5-gcc43-opt/lib
64"
else
export PATH=/usr/bin/:$PATH
export PATH=/afs/cern.ch/sw/lcg/external/Python/2.5.4p2/i686-slc5-gcc34-opt/bin:$PATH
export LD_LIBRARY_PATH=/afs/cern.ch/sw/lcg/external/Python/2.5.4p2/i686-slc5-gcc34-opt/lib:$LD_LIBRARY_PATH
. /afs/cern.ch/project/gd/LCG-share/3.2.1-0/external/etc/profile.d/grid-env-funcs.sh
gridpath_prepend "PYTHONPATH" "/afs/cern.ch/sw/lcg/external/Grid/dm-util/1.7.6-2/i686-slc5-gcc43-opt/lib/python2.5/site
-packages"
gridpath_prepend "PYTHONPATH" "/afs/cern.ch/sw/lcg/external/Grid/gfal/1.11.8-3/i686-slc5-gcc43-opt/lib/python2.5/site-p
ackages"
gridpath_prepend "PYTHONPATH" "/afs/cern.ch/sw/lcg/external/Grid/LFC/1.7.2-5sec/i686-slc5-gcc43-opt/lib/python2.5/site-
packages"
gridpath_prepend "LD_LIBRARY_PATH" "/afs/cern.ch/sw/lcg/external/Grid/lcg-dm-common/1.7.3-1sec/x86_64-slc5-gcc43-opt/lib
64"
echo " - Enabled Python 2.5"
fi
ATLAS Tier 3 use ATLASRootBase from ATLAS Canada. This is setting up DQ2 and dependencies (including a i686 version of Python)
The WN installation (gLite WN) is installing both the 32 and 64 bit version of some packages (including lfc bindings and globus essential from VDT)
References
- http://www.usatlas.bnl.gov/twiki/bin/view/Admins/WlcgClient
- LFC Upgrade requests (planning document): https://twiki.grid.iu.edu/bin/view/SoftwareTeam/LFCUpgradeReqs
- VDT LFC test cache: http://vdt.cs.wisc.edu/test-cache/lfc
- MWT2 Pacman cache: http://www.mwt2.org/caches/
- http://www.b-list.org/weblog/2007/dec/03/making-magic/
- http://effbot.org/zone/import-confusion.htm
- http://docs.python.org/dev/reference/simple_stmts.html#the-import-statement
- http://docs.python.org/library/site.html#module-site
- https://twiki.cern.ch/twiki/bin/view/Main/LxplusProblem
- http://www-pnp.physics.ox.ac.uk/~gallas/DQ2_notes.html
- https://twiki.cern.ch/twiki/bin/viewauth/Atlas/DQ2Clients
- https://twiki.cern.ch/twiki/bin/view/Atlas/DQ2ClientsHowTo
- http://www.triumf.info/wiki/atlas-triumf/index.php/Local_ATLAS_Computing_at_TRIUMF
- http://www.triumf.info/wiki/atlas-triumf/index.php/Setting_up_ATLAS_software
- http://www.triumf.info/wiki/atlas-triumf/index.php/How_to_setup_an_LCG_UI_on_your_desktop
- (ATLASRootBase) https://twiki.atlas-canada.ca/bin/view/AtlasCanada/InstallAtlasSoftware#Brief_description_and_usage_of_t
- WN client package list: http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-WN/glite-WN.asp
- WN install instructions: http://lists.grid.sinica.edu.tw/apwiki/%5CWN_Installation
- http://www.symantec.com/connect/articles/dynamic-linking-linux-and-windows-part-two
- http://grahamwideman.wordpress.com/2009/02/09/the-linux-loader-and-how-it-finds-libraries/
- ldd code execution: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/
- ?bug? https://www-304.ibm.com/support/docview.wss?uid=isg1IY81625
- changes.sh: file to patch the installation
| I | Attachment | Action | Size | Date | Who | Comment |
|---|---|---|---|---|---|---|
 sh |
changes.sh | manage | 2 K | 09 Jun 2011 - 21:13 | MarcoMambelli | file to patch the installation |
Edit | Attach | Print version | History: r14 < r13 < r12 < r11 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r14 - 03 Jul 2011, MarcoMambelli
CycleSeeder
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback