osx 10.9 php 5.4 pecl_http - class HttpRequest not found - pecl

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'

Related

Apache 2.4 start/stop throws "undefined symbol: ber_sockbuf_io_udp" error after configuring it with Shibboleth SP 3.2.0

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.

How to fix "undefined symbol: BrotliEncoderTakeOutput" when apache start

I have compiled mod_brotli.so, but when I restart apache, it cannot load module.
Error :
httpd: Syntax error on line 155 of /usr/local/apache2/etc/httpd.conf: Cannot load modules/mod_brotli.so into server: /usr/local/apache2/modules/mod_brotli.so: undefined symbol: BrotliEncoderTakeOutput
I am having the same problem. I don't know if it is the cause... in my case we are trying to add mod_brotli to Apache 2.4.34, from the Red Hat software collection (why they don't compile it with Brotli and include the Brotli package as a dependency, I have no idea).
I am not C developer, coming from the admin side, I can't see why it isn't working.
At first I thought it was an ldconfig issue, so I added a new file to the config dir, but it still doesn't work...
# apachectl -M
httpd: Syntax error on line 129 of /opt/rh/httpd24/root/etc/httpd/conf/httpd.conf: Cannot load /opt/rh/httpd24/root/usr/lib64/httpd/modules/mod_brotli.so into server: /opt/rh/httpd24/root/usr/lib64/httpd/modules/mod_brotli.so: undefined symbol: BrotliEncoderTakeOutput
Here you can see that ld knows about it, and that lib has the symbol...
# ldconfig -p | grep brotli
libbrotlienc.so.1 (libc6,x86-64) => /usr/local/lib64/brotli/libbrotlienc.so.1
libbrotlienc.so (libc6,x86-64) => /usr/local/lib64/brotli/libbrotlienc.so
libbrotlidec.so.1 (libc6,x86-64) => /usr/local/lib64/brotli/libbrotlidec.so.1
libbrotlidec.so (libc6,x86-64) => /usr/local/lib64/brotli/libbrotlidec.so
libbrotlicommon.so.1 (libc6,x86-64) => /usr/local/lib64/brotli/libbrotlicommon.so.1
libbrotlicommon.so (libc6,x86-64) => /usr/local/lib64/brotli/libbrotlicommon.so
# nm /usr/local/lib64/brotli/libbrotlienc.so | grep BrotliEncoderTakeOutput
0000000000090970 T BrotliEncoderTakeOutput
Meanwhile, you can see the undefined symbol in mod_brotli:
# nm /opt/rh/httpd24/root/usr/lib64/httpd/modules/mod_brotli.so | grep BrotliEncoderTakeOutput
U BrotliEncoderTakeOutput
Compiling the Apache module was done with
apxs -i -c -I /usr/local/include/brotli/ mod_brotli.c
Brotli itself was compiled from the latest tarball from github...
Apache is otherwise running fine, with the brotli line commented out.
Will post again if I find the answer...
====
Edit:
I got it working (well, having issues related to haproxy and h2c (unencrypted http2), but that's another matter)
In my case, the two issues were
A) I had compiled brotli in a bad way (based on some blog posts), compiling it per the google github readme worked
B) I was compiling the module with apxs command, but it turns out that is only for third party modules. The correct way for Apache built in modules that just didn't get compiled originally is:
./configure --prefix=/opt/rh/httpd24/root/etc/httpd --enable-brotli --with-brotli=/usr/local
and then make install (prefix is for the RH SCL version of course) (I actually did make install from the modules/filters/ dir, so it would install as little as possible as an override... not sure if it was needed, but that's what I did).
I figured out B) first, but it wasn't picking up the Brotli libs, after A) it worked fully.
I have no idea what apxs is doing differently, or why there should be different ways to compile modules, but hey.
I hope this will be at least some help.

"Please install the "intl" extension for full localization capabilities" when intl IS installed

Symfony 2.8 project in ubuntu 16.04
I got this exception:
An exception has been thrown during the rendering of a template ("The
Symfony\Component\Intl\DateFormatter\IntlDateFormatter::__construct()
method's argument $locale value 'es' behavior is not implemented. Only
the locale "en" is supported. Please install the "intl" extension for
full localization capabilities.").
Ok, but I have the intl extension already installed:
php -i | grep int
/etc/php/7.0/cli/conf.d/20-intl.ini,
intl
intl.default_locale => no value => no value
intl.error_level => 0 => 0
intl.use_exceptions => 0 => 0
Maybe is that default_locale with no value the problem? I have libicu installed too so no idea what is the problem.
It happens with php7.0, php7.1 and php7.2

httpd restart error : Apache

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)

Define Bundle Path With Capistrano

I am using the following configurations in my deploy.rb file for capistrano:
require 'bundler/capistrano'
require 'rvm/capistrano'
set :bundle_cmd, "/home/deployment/.rvm/gems/ruby-1.9.3-p194#global/bin/bundle"
set :default_environment, {
'PATH' => "/home/deployment/.rvm/gems/ruby-1.9.3-p194/bin:/home/deployment/.rvm/bin:$PATH",
'RUBY_VERSION' => 'ruby 1.9.3',
'GEM_HOME' => "/home/deployment/.rvm/gems/ruby-1.9.3-p194",
'GEM_PATH' => "/home/deployment/.rvm/gems/ruby-1.9.3-p194",
'BUNDLE_PATH' => "/home/deployment/.rvm/gems/ruby-1.9.3-p194"
}
But when I run cap deploy:update I get this:
* executing "cd /var/www/currienet/marketplace/releases/20120928140140 && /home/deployment/.rvm/gems/ruby-1.9.3-p194#global/bin/bundle install --gemfile /var/www/currienet/marketplace/releases/20120928140140/Gemfile --path /var/www/currienet/marketplace/shared/bundle --deployment --quiet --without development test"
That is, it's not setting the bundle path (the --path argument) to what I want it to be.
I've tried a number of tutorials, including the rvm capistrano tutorial but nothing seems to work. It continues to use the capistrano default.
Capistrano also creates an application with the following .bundler/config
BUNDLE_FROZEN: '1'
BUNDLE_PATH: /var/www/currienet/marketplace/shared/bundle
BUNDLE_DISABLE_SHARED_GEMS: '1'
BUNDLE_WITHOUT: development:test
Development Machine: Windows 7, bundler (1.0.22), capistrano (2.12.0), rvm-capistrano (1.2.7), rails (3.2.8), (no rvm)
Production: Debian, bundler (1.2.1) (no capistrano), (no rvm-capistrano), rails (3.2.8), rvm 1.16.5
Thanks to Joseph Holsten's blog I was able to ascertain my problem was I was not defining the bundler variables in my deploy.rb before I required 'bundler/capistrano'. I also needed to define the bundle_dir variable, to create code that looks like the following:
set :bundle_cmd, "/home/deployment/.rvm/gems/ruby-1.9.3-p194#global/bin/bundle"
set :bundle_dir, "/home/deployment/.rvm/gems/ruby-1.9.3-p194"
require 'bundler/capistrano'