I'm trying to install zend debugger in my Ubuntu 9.04 machine, I've done it in win. but not in linux, I hope you could help me, this is what I've done:
1)Copied the file ZendDebugger.so to /etc/php5/apache2 (didn't choose this folder for anything in special).
2)Added this lines to php.ini:
zend_extension="/etc/php5/apache2/ZendDebugger.so" zend_debugger.allow_hosts=127.0.0.1,127.0.1.1,localhost,*
zend_debugger.expose_remotely=always
I've also tried without quotes(zend_extension=/etc/php5/apache2/ZendDebugger.so)
3)Copied file dummy.php to /var/www
And then restarted Apache but I didn't see the information about Zend Debugger in the phpinfo(), the only related thing I found there was report_zend_debug On.
Thanks in advance
I found much more easy to install Xdebug in my Ubuntu machine.
sudo mv /etc/php5/apache2/ZendDebugger.so /usr/lib/php5/20060613/ZendDebugger.so
This is where your memcache.so, apc.so, etc. are located. Unless you modified your php extensions directory that is where new exts should go.
In php.ini:
zend_extension=/usr/lib/php5/20060613/ZendDebugger.so
cd to that directory and chmod a-x ZendDebugger.so to remove executable bits from the .so.
sudo /etc/init.d/apache2 stop
In another terminal window, tail -f /var/log/error.log and clear console so it is easy to see new log entries coming in (cmd-k on macos).
Then:
sudo /etc/init.d/apache2 start
If there are no errors in error.log, check phpinfo() and see if the debugger section shows up.
You might get errors in the configuration of other php extensions that occur further up in php.ini (e.g., xcache or eaccellerator) that will make loading stuff further down in php.ini problematic.
This is a baseline setup and should work if there are no other problems.
You can also try to install Zend Server Community Edition
You'll get Zend Debugger enabled by default, along with some other nice features. There is a link to the deb repository available through the download page.
I followed the same steps that you did with the same result. In the end the problem was that I was trying to load a 32bit binary with apache running in 64bit mode base (as described in this post) I was able to get it running immediately by doing the following.
stopping apache
executing sudo arch -i386 /usr/sbin/httpd
restarting apache.
After replacing the 32bit binary with the 64bit binary everything worked as expected with no special apache handling. There was also some facepalming involved, but it did not affect the overall outcome.
Related
So I ran into something I'm just hoping I can get some understanding on. There is a clean Centos machine with a clean install of PHP. It had the mongoDB driver installed as well. When accessing the web app through the browser, it kept complaining the mongo client didn't exist. All of the installation procedures were followed, php.ini contained extension=mongo.so, and httpd restarted. PHP info() did not contain the Mongo conf. What ended up working was adding a mongo.ini file to the /etc/php.d directory with the extension=mongo.so written to it.
I'm getting a sneaky suspicion php.ini wasn't being loaded correctly, but I don't understand why. The reason I'm thinking this is, for one, it worked after adding mongo.ini. Second, there are mismatched PHP info() outputs from the CLI and browser gui.
and from the GUI
Both of these were snapped seconds apart. No configuration changes or restarts were made. For some reason the CLI output says the loaded configuration file was /etc/php.ini which was expected. The browser GUI however shows (none). What is going on here? Is this why the extension=mongo.so was never loading from the php.ini file?
versions
Apache/2.4.6
PHP/5.4.16
CentOS Linux release 7.3.1611
[someUser#someServer etc]# find / -name php.ini
/etc/php.ini
Is SO even the proper place for this? or should I move to a different forum?
update
After reading Grigory Ilizirov's comments, and doing some research, I think the question is answered if he wants to post it. Looks like the php configs for apache wasn't being loaded. I had just assumed the /etc/php.ini file was all that was needed to be edited. Now I just need to figure out how the heck I'm going to do that.
update 2
Reverted back to a clean install and did everything again. This time around, same results from the CLI and web GUI as before, but now mongo wouldn't load at all despite being added in /etc/php.d/mongo.ini. suspect SELinux is interferring with apache. mongo.ini is no longer showing in the additional .ini file sections. Disabling SELinux and rebooting allows it to load to apache.
FINAL
This is indeed an SELinux issue. Now then, does this belong on SO for future users?
You need to make sure your PHP have installed MongoDB extension.try use PHP -m see if you have MongoDB installed.
Then Download source code from https://github.com/mongodb/mongo-php-driver-legacy.
follow these steps to install the extension:
tar zxvf mongo-x.x.x.tgz -C ../
cd mongo-x.x.x/
phpize
./configure --with-php-config=/usr/local/php/bin/php-config
make clean
make
make install
extension=mongo.so //add this line to php.ini
after install try run PHP -m again, see if extension installed success.
for more info, you should read PHP doc.http://php.net/manual/en/mongo.installation.php#mongo.installation.fedora
It was indeed SELinux interfering with Apache's access to the PHP configuration file. Adding the security context fixed it.
semanage fcontext -at httpd_sys_content_t '/etc/php.ini'
semanage fcontext -at httpd_sys_content_t '/etc/php.d/(/.*)?'
restorecon -Rv /etc/
systemctl restart httpd
I'll make this quick.
I installed Oracle 11g (with appropriate database, users, etc), Apache 2.4.6, and PHP 5.5.4 on a Fedora 19 system.
I wanted to connect PHP to Oracle. What I really wanted to do was to download MDB2_Driver_oci8, which I thought would be easy, but before I can do such a thing, PHP needs to have that plug-in enabled, so here's what I did:
Tried to install oci8 via the following: pecl install oci8
When that didn't exactly work the first few times, I figured out I, for some reason, needed "Development tools" - via yum groupinstall "Development Tools"
Then I figured out later that PHP actually doesn't do oci8 - it's PHP Devel. So, I had to install that too, via yum install php-devel.
And then, I finally got to install oci8. It asked for the Oracle Directory, and that was that. But it said the following:
Configuration option 'php_ini' is not set to php.ini location
You should add 'extensions=oci8.so' to php.ini
First, I did a locate oci8.so - found it in /usr/lib64/php/modules/
Second, I added what it told me to, to the php.ini file.
Third, I checked the usual php_info() test page - no mention of OCI8. Uh-oh.
Fourth, running both php -i and php -m listed oci8 as one of the modules. Weird.
In desperation, I went ahead and downloaded the MDB2_Driver_oci8. Maybe that will fix things. Nope.
When I loaded my PHP Webpage, it returned the following:
Error message: extension oci8 is not compiled into PHP
As well as: MDB2 error: not found
Strange. And then I decided to check the error logs:
PHP Startup - unable to load dynamic library '/usr/lib64/php/modules/oci8.so' - libclntsh.so.11.1: cannot open shared object file: No such file or directory in Unknown on line 0
And now I'm stuck. I tried going into the php.ini, and found that the extension_dir was commented out. I put it back in, which only seemed to break stuff.
Things of note:
I followed this (link) guide on how to configure PHP and install oci8.
./configure --with-oci8 doesn't work. Fedora says no such directory.
As both the webpage files and the actual server reside on the same PC, I did not install the Oracle Client files.
The extension_dir is commented out by default in the php.ini.
This is just one of my problems in a long line of problems concerning the replication of an already existing and working, but dying, setup. It seems whenever I want to solve a problem, I have to do X first. And by doing X, I uncover another problem, which I have to solve by doing Y, which has its own problems, etc, etc.
Any help would be much appreciated. Thanks.
I know this question is a bit old - but I'm writing this here incase others come looking for the solution.
PHP Extensions Directory
To get your PHP extensions directory, run this command
php-config --extension-dir
ORACLE configuration
When you run the config command for oracle, you need to provide it with your Oracle Home directory (this assumes you have installed ORACLE XE):
./configure -with-oci8=shared,$ORACLE_HOME/xe
SELinux policy
You need to adapt your SELinux policy to support what you are trying to achieve. Disabling it completely is not recommended.
On your Fedora system, try running:
which audit2allow
If you receive an error that indicates it cannot find audit2allow then you need to install this package:
yum install policycoreutils-python
Once you have this package, you can pipe your audit log files into audit2allow to have it create your policy file:
grep httpd /var/log/audit/audit.log | audit2allow -m httpd > http.te
This will create the file http.te that is human readable for you to review what the policy additions are that it will make to your SELinux configuration. If you are OK with the modifications, then run these commands (note the capital M in the following command vs. the lowercase m previously)
grep httpd /var/log/audit/audit.log | audit2allow -M httpd
semodule -i httpd.pp
This may take a few seconds to run - you can verify the policy has been installed by running:
semodule -l | grep httpd
You will need to restart httpd so that it can try to load the oci8.so plugin
service httpd restart
HTH
After reading a lot on the internet, I found this page, that indicates I should disable SELinux, and reboot.
That did the trick.
So I'm running MAMP on Mountain Lion and I've installed gmagick and imagick using pecl, both are relase candidates (mainly because gmagick doesn't have a stable release and imagick 3.0.0 doesn't install, it gives a make error). The modules appear when I run php -i in the terminal but not in phpinfo(), I have checked the php.ini it is the same for both so that is not the issue.However I have installed bitset(which is a stable release) and it appears in phpinfo() and php -i. So my question is does PHP have any configuration option that does not load extensions if they are not stable? Btw, I did restart my server after the changes to the ini file.
You will probably now have two php installations on your machine. Mountain Lion ships with a preinstalled php version. Trylocate php.ini in Terminal to find out how many php.inis are installed.
In your phpinfo() page there is also noted which php.ini is in use. You might want to open the exact php.ini which is used for your phpinfo() and make sure the extentions are loaded.
There should be two lines like
extension=/path/to/gemagicext/gmagic.so
extension=/path/to/imagick/imagick.so
I faced a similar problem with php-fpm and nginx server. The problem was due to the fact that the updated php configuration was not reflected in the current active php-fpm worker processes. I have to manually kill the fpm process and restart it again to have the updated extensions info.
Steps that worked for me:
1) Look for active php-fpm process
ps ax | grep "fpm"
mostly this will list more than one process
2) kill process manually
kill -9 [pid_got_from_previous_command]
3) restart php-fpm process
sudo service php5-fpm start
Note: Trying something like sudo service php-fpm reload or sudo service php-fpm restart didn't work since the old child processes retained the old configuration. Killing the active processes and restarting php fpm what updated the phpinfo for me.
I had the same problem CentOS 6.6 x64, php 5.5.27 and I followed the steps from
http://php.net/manual/en/imagick.installation.php
First of all download a tar image of the ImageMagick install from here:
sourceforge.net/projects/imagemagick/files/
Unpack it and then from terminal issue the following commands:
1. "cd ImageMagick-6.9.1-10" - go where you placed the folder
2. ./configure
3. make
4. make install
5. make check
6. install imagick extension from pecl.php.net/package/imagick/download 3.1.2
7. cd imagick-3.1.2
8. phpize
9. ./configure --with-imagick=/opt/local
10. make
11. make install
12. Copy imagick.so in your PHP extensions folder and add extension=imagick.so in php.ini
Restart apache: service httpd restart
I am sure this problem is related to your extension and PHP server compatibility. I encountered such problems when I created my own extensions. Your extension should compatible with your PHP server in three main attributes:
1- The Zend API number which your PHP server is configured with ( in phpinfo() you can find this number), this number should be the same with your extension header file at build time.
2- The compiler version on your PHP server and your extension must be the same.
3- Thread safety in your PHP server is important. If you use thread-safe server then your extension must be built with php thread-safe library and if you use non-thread safe server you should build your extension with PHP-nts library.
I have spent a lot of time on this with no end product.
Installed MAMP.
Found "make" (was installed in different folder)
Installed autoconf which was missing so I can run phpize
Downloaded, compiled and installed xdebug according to:
http://www.xdebug.org/find-binary.php
Made necessary changes to correct php.ini.
Restarted MAMP - but phpinfo() does not show xdebug.
No matter what I do to the php.ini file located at /Applications/MAMP/conf/php5.3/php.ini, nothing changes. The site still loads fine. Even if I nuke it completely. Yet that is what phpinfo() shows it is loading.
What am I overlooking?
php.ini
[xdebug]
zend_extension=/Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
The site where you can download precompiled binaries of xdebug had been down all morning (activestate) which is why I was trying to compile my own.
I just found out the site was back online, downloaded the xdebug.so file, and it is now loading.
Modern MACs have two kinds of binaries - 32-bit and 64-bit. Verify that you PHP matches your xdebug: do file Applications/MAMP/bin/php5.3/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so then file /path/to/mamp/Library/modules/php5.3/libphp5.so and see if they both show i386 or x86_64.
I just did it and it worked. Here is what I did:
install PECL in order to install Xdebug
download http://pear.php.net/go-pear.phar
in the download directory execute php -d detect_unicode=0 go-pear.phar
now add the ~/pear/bin folder to your path echo "export PATH=$PATH:/Users/the-user/pear/bin" >> .bash_profile
and make the change visible to your terminal . .bash_profile
install Xdebug
now that you have PECL it's as easy as sudo pecl install xdebug
now you need to add a line to php.ini
the php.ini on my mac (Lion) is /etc/php.ini.default
search for zend_extension and uncomment the line if it is correct or change it if it is not (in my case it was correct)
That's it. Unless you want to debug form IntelliJ Idea. In which case I had to copy /etc/php.ini.default to /etc/php.ini
have fun with PHP
Just to point out the obvious, but one that I keep throwing away time on; in an apache2 environment remember to restart apache2 for the changes to take effect.
sudo apachectl restart
I have OS X 10.5 set up with the precompiled versions of PHP 5 and Apache 2. I'm trying to set up the Zend Debugger, but with no luck. Here's what I did:
I downloaded ZendDebugger-5.2.14-darwin8.6-uni.tar
I created the directory /Developer/Extras/PHP and set the permissions to:
Permissions: drwxrwxr-x
Owner: root:admin
I copied ZendDebugger.so from the 5_2_x_comp directory to /Developer/Extras/PHP
I updated /etc/php.ini file, adding the following lines:
zend_extension=/Developer/Extras/PHP/ZendDebugger.so
zend_debugger.expose_remotely=always
zend_debugger.connector_port=10013
zend_debugger.allow_hosts=127.0.0.1
I restarted Apache via the System Preferences "Sharing" panel
When I run phpinfo() within a PHP file, I get no mention of the Zend Debugger. When I run php -m from the command line, it shows the Zend Debugger is loaded. Both state that they're running the same version of PHP, and loading the same INI file.
Anyone have another suggestion for me to try?
If I remember correctly, this problem is do to the fact that the Zend Debugger is compiled for 32-bit Apache while the Apache that comes with Max OS 10.5 is compiled as 64-bit application. Until Zend comes out with a 64-bit version, you have two options:
1) Restart Apache manually into 32-bit
2) Recompile Apache and PHP in 32-bit mode.
I haven't actually gotten around to doing either yet, but I think I am leaning to recompiling to avoid future problems.
Restarting in 32-bit mode did the trick. For those of you who want to be able to do this easily, here's a little bit of AppleScript:
do shell script "apachectl stop" with administrator privileges
do shell script "arch -i386 /usr/sbin/httpd" with administrator privileges
It's nice to have sitting somewhere so you can quickly pop into 32-bit mode when needed.
Zend released the 64bit version for Mac OSX, so just download the file from http://www.zend.com/en/products/studio/downloads and procede as normal.
You will have to register and answer some questions, but it worked for me.
Good Luck.
Me too, HOURS!! Thanks so much!!
Also if for some reason you need to restart apache/httpd after running this (e.g. you need to make a change in your php.ini) but when you run "sudo arch -i386 /usr/sbin/httpd" you're getting this error:
(48)Address already in use: make_sock: could not bind to address [::]:80
type this in a terminal window:
sudo killall httpd
then "sudo arch -i386 /usr/sbin/httpd" should work fine to restart apache/httpd.