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.
Related
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 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
When I tried to restart httpd, I am getting below error.
[admin#stg-001 ~]$ /apps/apache/bin/httpd -k restart
httpd: Syntax error on line 114 of /apps/apache/conf/httpd.conf: Cannot load /apps/apache/modules/mod_ssl.so into server: libssl.so.1.0.0: cannot open shared object file:
No such file or directory
Server version: Apache/2.2.21 (Unix)
Please help me to resolve the error.
Try the following command, which shows required modules which are missing.
ldd (apache_home_dir)/modules/mod_ssl.so
Will produce something like:
linux-vdso.so.1 => (0x00007ffc61f7a000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
librt.so.1 => /lib64/librt.so.1 (0x00007f71c9666000)
Below Fix Worked for me:
export LD_LIBRARY_PATH=/path_to_openssl/lib/
or try
export LD_LIBRARY_PATH=/path_to_openssl/
Ref: http://www.linuxquestions.org/questions/showthread.php?s=2bcf368edb2a95bce9e538e8db2aed76&p=5605966#post5605966
Why not read the error message?
Check that the line 114 of /apps/apache/conf/httpd.conf is syntatically correct
Check that the file /apps/apache/modules/mod_ssl.so exists
You might want to check that libssl is indeed installed on your server with the proper version.
You can check in /var/lib (depends on you OS)
I am running php 5.4.17 on OS X 10.9.1.
I have installed pear using this command:
wget http://pear.php.net/go-pear.phar
php -d detect_unicode=0 go-pear.phar
Then I have installed pecl_http with:
pecl install pecl_http
I have added extension lines to my php.ini and add 'x' permission to library binaries. If I run php -i I get:
http
HTTP Support => enabled
Extension Version => 2.0.4
Used Library => Compiled => Linked
libz => 1.2.5 => 1.2.5
libcurl => 7.30.0 => 7.30.0
libevent => disabled => disabled
Directive => Local Value => Master Value
http.etag.mode => crc32b => crc32b
But if I try to run php script with HttpRequest inside I still get:
Fatal error: Class 'HttpRequest' not found
Can somebody give me a clue what am I doing wrong?
You are using pecl_http 2.0.4 and probably refer to documentation from http://www.php.net/manual/en/class.httprequest.php which is for older version. There is a post that's already explained your problem:
PECL_HTTP not recognised php ubuntu
In fact, you should refer to the documentation defined here:
http://devel-m6w6.rhcloud.com/mdref/http
To verify: if (class_exists('http\Client\Request')) printf 'pecl_http v2 is installed'
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