Bug #24527
Condor tarball building broken
0%
Description
It seems ther is a bug with the building of the condor tarballs in 3.7.
The upgrade and reconfig commands exit with the following error:
Using default factory config file: /etc/gwms-factory/glideinWMS.xml Error creating condor tgz: Error copying /usr/lib64/libSciTokens.so.0.0.2 in lib/libSciTokens.so.0.0.2: [Errno 2] No such file or directory: 'lib/libSciTokens.so.0.0.2' Upgrading the factory [FAILED]
And the code seem to refer a file in /usr/lib, it should only pick files from the expanded tar ball. In creation/lib/cgWCreate.py:
# needed libraries for token auth, copy them in for needed in ['libSciTokens', 'libmunge']: pat = '/usr/lib64/%s*' % needed for src in glob.glob(pat): dst = os.path.join('lib', os.path.basename(src)) copy_file(src, dst)
Related issues
History
#1 Updated by Marco Mambelli 10 months ago
- Status changed from New to Feedback
- File cgWCreate.py cgWCreate.py added
Removed the extra import.
If libSciTokens is in the condor tarball, it is added to the stripped tarball for the glidein. I verified that:
-rwxr-xr-x root/root 721848 2020-05-19 15:24 lib/condor/libSciTokens.so.0.0.2 lrwxrwxrwx root/root 0 2020-05-19 15:25 lib/condor/libSciTokens.so.0 -> libSciTokens.so.0.0.2 lrwxrwxrwx root/root 0 2020-05-19 15:25 lib/condor/libSciTokens.so -> libSciTokens.so.0libmunge is not.
libmunge is not in the condor tarball and it is not detected as a dependency.
What is requiring libmunge?
It seems to be used for user authentication across an authentication domain (hosts sharing a key) using the munge service (server and library)
Attached is the changed python file to allow patching: /usr/lib/python2.7/site-packages/glideinwms/creation/lib/cgWCreate.py
#2 Updated by Marco Mambelli 10 months ago
# mv $GWMS_THIS_SCRIPT_DIR/$LIB ${CONDOR_DIR}/lib #done cd ${CONDOR_DIR}/lib ln -s libSciTokens.so.0.0.2 libSciTokens.so.0 ln -s libSciTokens.so.0.0.2 libSciTokens.so ln -s libmunge.so.2.0.0 libmunge.so.2 cd $LOCAL_DIR
this is in creation/web_base/frontend/token_setup.sh
which is supposedly a frontend ony file but is used only in factory/tools/factory_tokenize.sh
- a version of condor should not be modified (either it supports tokens or not - modifications could cause errors if the OSes are different or the condor versions incompatible)
- Frontend, Glidein tarball, and Factory if needed, should have the correct condor version or tokens are not supported. It should be a requirement if needed.
#3 Updated by Marco Mambelli 10 months ago
- Related to Bug #24285: initial reconfig of v3_7 factory fails after rpm installation added
#4 Updated by Marco Mambelli 10 months ago
- Status changed from Feedback to Resolved
Handling of token scripts has been moved to a new ticket: [#24544]
#5 Updated by Marco Mambelli 10 months ago
- Assignee changed from Dennis Box to Marco Mambelli