I wanted to mess around with OSSubprocess (written by Mariano Martinez Peck) from my Pharo 6.1 on my CentOS 7.4.
I searched within the Pharo Project Catalog and tried to install it.
I got an error:
ioLoadModule(/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836/libgit2.so):
libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
tryLoading(/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836/libgit2.so/.libs/,libgit2.so): stat(/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836/libgit2.so/.libs/) Not a directory
ioLoadModule(/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836/libgit2.so):
libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
tryLoading(/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836/libgit2.so/.libs/,libgit2.so): stat(/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836/libgit2.so/.libs/) Not a directory
Apparently, some libraries as libcurl-gnutls are needed by the libgit2.so.
ls -la | grep git
-rw-r--r--. 1 smalltalk smalltalk 3019447 May 9 08:55 libgit2.so
-rw-r--r--. 1 smalltalk smalltalk 3019447 May 9 08:55 libgit2.so.0.25.1
-rw-r--r--. 1 smalltalk smalltalk 3019447 May 9 08:55 libgit2.so.25
[smalltalk#smalltalk 5.0-201805090836]$ pwd
/home/smalltalk/App/pharo6.1-64/pharo-vm/lib/pharo/5.0-201805090836
When I check the dependencies with ldd libgit2.so:
ldd: warning: you do not have execution permission for `./libgit2.so'
linux-vdso.so.1 => (0x00007ffcd7aea000)
libcurl-gnutls.so.4 => not found
libz.so.1 => /lib64/libz.so.1 (0x00007f09ff332000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libssh2.so.1 => /lib64/libssh2.so.1 (0x00007f09ff107000)
librt.so.1 => /lib64/librt.so.1 (0x00007f09feeff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f09fece3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f09fe91f000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f09fe6ad000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f09fe24c000)
/lib64/ld-linux-x86-64.so.2 (0x000056133cf8c000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f09fdffe000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f09fdd16000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f09fdb12000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f09fd8de000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f09fd6da000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f09fd4cc000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f09fd2c7000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f09fd0ad000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f09fce85000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f09fcc23000)
The issue is apparently with:
libcurl-gnutls.so.4 => not found
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libcurl-gnutls.so.4 library is not apparently shipped with CentOS 7 at all:
We just don't supply anything called libcurl-gnutls* at all. Our curl doesn't use gnutls.
libssl.so.1.0.0 is ancient (same goes for libcrypto.so.1.0.0). If I check my libssl:
sudo ls -l /usr/lib64/libssl*
-rwxr-xr-x. 1 root root 341024 May 16 17:20 /usr/lib64/libssl3.so
lrwxrwxrwx. 1 root root 16 Jan 31 13:40 /usr/lib64/libssl.so -> libssl.so.1.0.2k
lrwxrwxrwx. 1 root root 16 Jan 31 13:34 /usr/lib64/libssl.so.10 -> libssl.so.1.0.2k
-rwxr-xr-x. 1 root root 470336 Aug 4 2017 /usr/lib64/libssl.so.1.0.2k
sudo ls -l /usr/lib64/libcrypto*
lrwxrwxrwx. 1 root root 19 Jan 31 13:40 /usr/lib64/libcrypto.so -> libcrypto.so.1.0.2k
lrwxrwxrwx. 1 root root 19 Jan 31 13:34 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.2k
-rwxr-xr-x. 1 root root 2512448 Aug 4 2017 /usr/lib64/libcrypto.so.1.0.2k
The CentOS 7 details are:
Static hostname: smalltalk
Icon name: computer-vm
Chassis: vm
Machine ID: beb4030b979d4cdcbf51ec99034121fc
Boot ID: 02ef7d00b2e74489bdb78dead7e2fcf8
Virtualization: kvm Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-693.17.1.el7.x86_64
Architecture: x86-64
Now the million dollar question:
How do you deal with such a situation? Is there a reasonable way to recompile the whole Pharo VM or just the libgit2 library against the newer libraries' versions?
This seems related to a question asked here: http://forum.world.st/Pharo-download-with-wget-td5099253.html
The suggested solution in the thread and the one that also works for me is to created a symbolic link:
ln -s /usr/lib64/libcurl.so.4 /usr/lib64/libcurl-gnutls.so.4
Related
Operating System: Red Hat Enterprise Linux Server 7.9 (Maipo)
Apache version: Apache/2.4.46 (Unix)
Shibboleth version: 3.2.0
Error when trying to stop Apache (apachectl stop):
httpd: Syntax error on line 528 of <Apache>/conf/httpd.conf: Syntax error on line 13 of <Apache>/conf/myshib.conf: Cannot load /usr/lib64/shibboleth/mod_shib_24.so into server: /usr/lib64/libldap_r-2.4.so.2: undefined symbol: ber_sockbuf_io_udp
Line 528 of <Apache>/conf/httpd.conf:
Include conf/myshib.conf
Line 13 of <Apache>/conf/myshib.conf:
LoadModule mod_shib /usr/lib64/shibboleth/mod_shib_24.so
Attempted - https://superuser.com/questions/1283252/slappasswd-symbol-lookup-error-undefined-symbol-ber-sockbuf-io-udp
But running "export LD_LIBRARY_PATH=/lib64:$LD_LIBRARY_PATH" did not resolve the issue.
Output of "ldd /usr/lib64/libldap_r-2.4.so.2" command:
linux-vdso.so.1 => (0x00007ffd1c76e000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f5b3e87d000)
libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007f5b3e663000)
libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007f5b3e446000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f5b3e1d4000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f5b3dd71000)
libssl3.so => /usr/lib64/libssl3.so (0x00007f5b3db14000)
libsmime3.so => /usr/lib64/libsmime3.so (0x00007f5b3d8ec000)
libnss3.so => /usr/lib64/libnss3.so (0x00007f5b3d5b8000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f5b3d388000)
libplds4.so => /usr/lib64/libplds4.so (0x00007f5b3d184000)
libplc4.so => /usr/lib64/libplc4.so (0x00007f5b3cf7f000)
libnspr4.so => /usr/lib64/libnspr4.so (0x00007f5b3cd41000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f5b3cb25000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f5b3c921000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f5b3c553000)
libcrypt.so.1 => /usr/lib64/libcrypt.so.1 (0x00007f5b3c31c000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f5b3c0cf000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f5b3bde6000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f5b3bbb3000)
libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007f5b3b9af000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f5b3b79f000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007f5b3b589000)
librt.so.1 => /usr/lib64/librt.so.1 (0x00007f5b3b381000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5b3eceb000)
libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007f5b3b17e000)
libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007f5b3af7a000)
libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007f5b3ad53000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f5b3aaf1000)
Then attempted - https://unix.stackexchange.com/questions/193320/yum-corrupted-on-rhel-6
Output of "for lib in /lib64/.so.; do if nm -D $lib|grep ber_sockbuf_io_udp; then echo $lib; fi; done" command:
000000000020e020 D ber_sockbuf_io_udp
/lib64/liblber-2.4.so.2
000000000020e020 D ber_sockbuf_io_udp
/lib64/liblber-2.4.so.2.10.7
U ber_sockbuf_io_udp
/lib64/libldap-2.4.so.2
U ber_sockbuf_io_udp
/lib64/libldap-2.4.so.2.10.7
U ber_sockbuf_io_udp
/lib64/libldap_r-2.4.so.2
U ber_sockbuf_io_udp
/lib64/libldap_r-2.4.so.2.10.7
Output of "rpm -qf /lib64/liblber-2.4.so.2" command:
openldap-2.4.44-22.el7.x86_64
Tried to install 'openldap' but it already existed
yum install openldap-2.4.44-22.el7.x86_64
Loaded plugins: langpacks, product-id, search-disabled-repos
Package openldap-2.4.44-22.el7.x86_64 already installed and latest version
Nothing to do
Restarted entire server and re-installed 'openldap' using "yum reinstall openldap.x86_64" command but no luck.
Apache starts and returns a response when accessing https://hostname.domain.com but downloading the Shib Metadata XML file via Apache using URL https://hostname.domain.com/Shibboleth.sso/Metadata fails.
Apologies if I missed adding anything obvious.
Update:
Works when using older Shibboleth version 3.1.0
similar thread here: https://unix.stackexchange.com/questions/193320/yum-corrupted-on-rhel-6
In my case (RHEL7.8 + Apache 2.4 + Shibboleth 3.2) I was able to resolve the issue by replacing the /usr/lib64/libldap_r-2.4.so.2 library with the one from the Apache directory: <APACHE_ROOT>/HTTPServer/openldap/lib/libldap_r-2.4.so.2
Run:
locate libldap_r-2.4.so.2
to find the location of the library.
In my case I got:
/app/ptc/Windchill_12.0/HTTPServer/openldap/lib/libldap_r-2.4.so.2
/app/ptc/Windchill_12.0/HTTPServer/openldap/lib/libldap_r-2.4.so.2.10.12
/usr/lib/libldap_r-2.4.so.2
/usr/lib/libldap_r-2.4.so.2.10.7
/usr/lib64/libldap_r-2.4.so.2
/usr/lib64/libldap_r-2.4.so.2.10.7
I noticed that the lib used in the error was in /usr/lib64 dir.
I replaced it and now ./apachectl -t reports
"Syntax OK"
I don't know enough about Linux to explain what is going on here or what the correct fix is.
This was my observation and resolved the issue, I believe my steps are a hack though.
Anyone with a more elegant, upgrade proof solution?
Reference: https://groups.google.com/g/repmgr/c/TS7QfYEoNoY
cd /usr/lib64/
ll | grep libldap
lrwxrwxrwx. 1 root root 21 Feb 11 16:42 libldap-2.4.so.2 -> libldap-2.4.so.2.10.7
-rwxr-xr-x. 1 root root 352512 Jun 6 2020 libldap-2.4.so.2.10.7
lrwxrwxrwx. 1 root root 23 Feb 11 16:42 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.7
-rwxr-xr-x. 1 root root 381328 Jun 6 2020 libldap_r-2.4.so.2.10.7
It does seem like /usr/lib64/libldap_r2.4.so.2 is just a symlink to libldap_r-2.4.so.2.10.7.
I wonder if there are missing or deprecated symbols in 2.10.7...
Is there any way to tell the diff in the 2 versions?
UPDATE
I noticed that you can make use of the LoadFile command in the Apache conf.
Adding LoadFile <APACHE_ROOT>/HTTPServer/openldap/lib/libldap_r-2.4.so.2 in my 00-shib.conf file before the LoadModule mod_shib /usr/lib64/shibboleth/mod_shib_24.so entry resolved the issue.
This still seems like a workaround / hack to me and there may be an underlying issue with the libraries / different versions.
I work on an AWS lightsail server with a LAMP self-contained installation stack and I want to host a second web-app in django.
Tried to install mod_wsgi to a pyenv virtual environment (3.8.3 or 3.8-dev, both with shared libraries installed) using
export APXS=/opt/USER/apache2/bin/apxs
pip install mod_wsgi (tried with and w/o wheel)
but the module mod_wsgi-py38.cpython-38-x86_64-linux-gnu.so that created is over 1MB in size.
-rwxrwxr-x 1 USER USER 1157792 Jun 21 20:15 mod_wsgi-py38.cpython-38-x86_64-linux-gnu.so
ldd gives:
ldd mod_wsgi-py38.cpython-38-x86_64-linux-gnu.so
linux-vdso.so.1 => (0x00007ffc3e198000)
libpython3.8.so.1.0 => /home/USER/.pyenv/versions/3.8-dev/lib/libpython3.8.so.1.0 (0x00007fce67120000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fce66f03000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fce66b39000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fce66935000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fce66732000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fce66429000)
/lib64/ld-linux-x86-64.so.2 (0x00007fce678f0000)
According to the manual https://modwsgi.readthedocs.io/en/develop/user-guides/installation-issues.html#lack-of-python-shared-library, that should be a problem for my server's memory performance.
Is there something else that I could do in order to get a ~250KB in size module as the docs describe it?
mod_wsgi.so size of 1.1MB is fine nowadays.
Newbie questions regarding installation and python shared library
I am new to Lua.
Several days ago, I complished using python in ExecuteScript of NIFI. I set Python Module path to /usr/local/lib/python2.7/dist-packages. Everything goes well.
But doing the same thing with Lua is so difficult for me. Always Error of cannot find the Module!!!
I use Luarock to install modules.
Could you please tell me how to set the lua module path or some useful infomation about it?
Here comes some info of my Luarocks setting:
lbh#es-2:~/install/nifi-1.1.1/lua_modules$ luarocks list
Installed rocks:
----------------
lua-cjson
2.1.0-1 (installed) - /usr/local/lib/luarocks/rocks
luasocket
3.0rc1-2 (installed) - /usr/local/lib/luarocks/rocks
redis-lua
2.0.4-1 (installed) - /usr/local/lib/luarocks/rocks
An example of lua-cjson.
lbh#es-2:~/install/nifi-1.1.1/lua_modules$ luarocks show lua-cjson
lua-cjson 2.1.0-1 - A fast JSON encoding/parsing module
The Lua CJSON module provides JSON support for Lua. It features: - Fast,
standards compliant encoding/parsing routines - Full support for JSON with
UTF-8, including decoding surrogate pairs - Optional run-time support for
common exceptions to the JSON specification (infinity, NaN,..) - No
dependencies on other libraries
License: MIT
Homepage: http://www.kyne.com.au/~mark/software/lua-cjson.php
Installed in: /usr/local
Modules:
cjson
lua2json
json2lua
cjson.util
Directory info of /usr/local/lib/luarocks/rocks
lbh#es-2:~/install/nifi-1.1.1/lua_modules$ ls -l /usr/local/lib/luarocks/rocks
total 16
drwxr-xr-x 3 root root 4096 Mar 17 11:13 lua-cjson
drwxr-xr-x 3 root root 4096 Mar 17 11:18 luasocket
-rw-r--r-- 1 root root 3653 Mar 17 11:18 manifest
drwxr-xr-x 3 root root 4096 Mar 17 11:18 redis-lua
So I just installed Arch and most things are working fine, but when I try to use pacman or curl, I get the error:
pacman: error while loading shared libraries: /usr/lib/libcurl.so.4: invalid ELF header
Also, I can't seem to run anything pacman-related for now... not even a pacman --help
Not sure if useful, but ls -l /usr/lib | grep libcurl gives:
-rw-r--r-- 1 root root 594016 Jun 22 12:21 libcurl.a
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so.4 -> libcurl.so.4.3.0
-rwxr-xr-x 1 root root 408324 Jun 22 12:21 libcurl.s0.4.3.0
Thanks in advance!
Update: running ./curl-config gives the error, "cannot execute binary file". This makes me wonder if maybe I have a 64 bit version, whilst I'm running Arch i686. What is the best way to handle this?
maybe I have a 64 bit version, whilst I'm running Arch i686
That would do it. Run file ./curl-config. If it says ELF 64-bit LSB executable,... reinstall curl from correct packages.
I am running Centos 5.8 on a production server. I have an application that needs to use the keyctl command, but everytime the app calls (or I call) the command, I have some errors.
The first error was this:
root#server [~] keyctl show
segmentation fault
Then, I re-installed the keyutils binaries using yum. These are the keyutils packages I have on the server:
root#server [~]# rpm -qa | grep keyutils
keyutils-libs-1.2-1.el5
keyutils-libs-1.2-1.el5
keyutils-1.2-1.el5
keyutils-libs-devel-1.2-1.el5
And now, I have another different error:
root#server [~]# keyctl show
keyctl: symbol lookup error: /lib64/libkeyutils.so.1: undefined symbol: dlopen
I checked the libraries of keyctl, and libdl is not there.
root#server [~]# ldd /bin/keyctl
linux-vdso.so.1 => (0x00007fffcc5fd000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000033df000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d7ae00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d7aa00000)
All libraries that uses are fine.
root#server [~]# ls -al /lib64/libkeyutils*
-rwxr-xr-x 1 root root 9472 Jan 6 2007 /lib64/libkeyutils-1.2.so*
lrwxrwxrwx 1 root root 18 Nov 21 07:56 /lib64/libkeyutils.so.1 -> libkeyutils.so.1.9*
-rwxr-xr-x 1 root root 34584 Jan 6 2007 /lib64/libkeyutils.so.1.9*
root#server [~]# ls -al /lib64/libdl*
-rwxr-xr-x 1 root root 23360 Aug 27 08:59 /lib64/libdl-2.5.so*
lrwxrwxrwx 1 root root 12 Nov 16 02:01 /lib64/libdl.so.2 -> libdl-2.5.so*
root#server [~]#
Have you ever seen this problem before? I tried run the same version on others distros and it works.
I would like to re-install this server, but I can't because it is a production server.
Is there a way I can add or link a shared library to a binary already linked to others .so libraries?
Look at: http://blog.solidshellsecurity.com/2013/02/08/sshd-spam-rootkit-lib64libkeyutils-so-1-9/
It appears that there is no such legitimate file as libkeyutils.so.1.9
It is a rootkit, the latest legitimate version of this library is libkeyutils.so.1.3 on CentOS 6.3 (final).
rm -f /lib64/libkeyutils.so.1.9
ldconfig
/etc/init.d/sshd restart
There's also a suspected (as of now) unpatched user escalation priviledge flaw in all CentOS and RedHat kernels: https://access.redhat.com/security/cve/CVE-2013-0871 and http://blog.configserver.com/index.php?itemid=716
You may also need to reinstall SSH:
https://serverfault.com/questions/476954/remove-shared-library-from-sshd
https://forums.cpanel.net/f185/sshd-rootkit-323962.html
LD_PRELOAD=/lib64/libdl-2.5.so keyctl show