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.
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'm trying to install php's ssh2 extension, and having a little bit of difficulty. The file is there, it's just not loading into php.
First, I've installed ssh2 with:
aptitude install libssh2-1-dev libssh2-php
(For what it's worth, I'm running Ubuntu 12.04 on Nginx.)
I can see that ssh2 is loaded using the modules command:
php -m |grep ssh2
ssh2
However, when I run my code, I get an undefined function error.
In my phpinfo() script, I can see that my php installation scans this directory for additional ini files: /etc/php5/fpm/conf.d. Listing the contents of that directory, I can see that my ssh2.ini is there:
ls /etc/php5/fpm/conf.d
mysqli.ini mysql.ini pdo.ini pdo_mysql.ini ssh2.ini
According to phpinfo again, the other four ini files are loaded. SSH2 is not.
I've also tried placing "extension=ssh2.so" directly in my php.ini file - /etc/php5/fpm/php.ini. And yes - I've restarted my nginx server.
Am I missing something else?
Set display_startup_errors = On in you php.ini
Set error_log = '/var/log/php-error.log' in you php.ini
Create error log - touch /var/log/php-error.log
Now, you can restart php5-fpm daemon and lookup in error log any errors with ssh2 module
The answer from Aleksandr was helpful. I was attempting to install a PHP extension for a Plesk build. You need to make the modifications to the Plesk php.ini version that corresponds to the domain (which you can find in the web-based control panel under Tools and Settings). The error log will be located in /var/log/plesk-phpXX-fpm.
Do NOT uncomment the error_log (#2 / #3) as noted above otherwise you won't see the error show up in this location.
After I tried for hours to find the good path for PHP-CLI, i finally found it. But my proud was soon gone again.
Still i got the following error:
The following requirements were not met. As a result video uploads have been disabled.
Unable to locate path to PHP-CLI
I have tried much different paths
bin/php
usr/local/lib
usr/local/lib/php
usr/local/bin/php (this is the good one I thought).
Still getting the same error as above. Whats happening? My server is not running in Safe Mode and my exec() are enabled via the php.ini file.
Please help me..
Edit:
Paul
Q: Have you tried any "fully qualified paths", e.g. "/bin/php" (not
just "bin/php")?
A: I have tried both solutions, no result.
Q: Are you sure php-cli is installed on your system (it's typically a
seperate package from the Apache PHP plug-in)? EXAMPLE: apt-get
install php5-common libapache2-mod-php5 php5-cli.
A: I tried this in the SSH of my server, its a CentOS server so he didn't found the comment
#Peter:
If you installed PHP through your OS package manager, the path would
probably be /usr/bin/php, which appears to be the only one you didn't
try
I tried that one now, i didn't help, still the same error:
Edit2
#Dev-null
You have found and what? Just knowing where >is located will not fix it, have you changed some >code or environment variable PATH to make it
A: its an input field where i need to put the path in. I haven't changed any code, because PHP version 5.3.17 (CLI) installed on my CentOS server. So no need to change some code just for the path, right?
Edit
My PHP info, PHP 5.3.17 (CLI) Check the image below..
Edit
When I do rpm -q php-cli I get PHP-CLI not installed and when I want to install i get No package php-cli available. See image below.
Edit
Result of /bin/php -v below.
CentOS ships the PHP command-line interpreter in the php-cli package. So you first need to verify whether it's installed or not:
rpm -q php-cli
If installed, you can list all its files:
rpm -ql php-cli
... and filter out potential binaries:
rpm -ql php-cli | grep /bin/
You can get further details in the Using RPM chapter of the deployment guide.
If the package is not installed:
yum install php-cli
More info at Installing New Software with yum.
All this answer assumes that nobody broke the package system by installing software manually. If that happened, there's no way to tell what changes were made to the system.
Edit #1: I've just seen your last edit where php-cli is up and running. Then, if you want to know the path you just need to type this:
which php
Edit #2: You seem to have up to 4 binaries called php in your path. I still think that the proper reliable way to find the php-cli binary is running rpm -ql php-cli but given that php finds it on the path I'm pretty sure that it's located at /bin/php and you can verify it by running:
/bin/php -v
Run that exact command—don't remove any slashes or append -cli.
If your script, whatever it looks like, cannot find it, it's either doing it wrong or it's missing the appropriate permissions.
try the following to find it:
sudo find / -name php-cli
You most likely want php instead of php-cli though.
None of the solutions on this page found the installed versions of PHP that were present in my own elusive search for php-cli. The solution for me was to use the following command:
locate bin/php
This listed all php versions and I could then replace php with, for example:
/usr/bin/php71-cli
To access the command line interface version of php rather than the default cgi one. I then alias my instructions like so:
alias composer='/usr/bin/php71-cli bin/composer.phar'
I installed "drush" for my drupal website.
when I tried to run "drush":
[root#server /]# drush
/usr/share/drush/drush.launcher: line 132: /usr/bin/php-cli: No such file or directory
[root#server /]#
php-cli was not in my default directory /usr/bin
Solution was to copy my "php"-file to "php-cli" file (no rename!!, just copy)
[root#server /]# cp php php-cli
weird, but still working!
I've been tasked to create a PHP app which accesses an existing PostgreSQL database. This is my first time working with Postgre, not to mention the PHP has already been installed in the Linux box on which the app is supposed to run. I have no experience setting up this stuff, I just code.
My question is that I can't seem to get the Postgre extension working in PHP. I checked the php.ini file, there were no "extension=..." lines. So I added "extension=pgsql.so". I then checked the "extension_dir" and found that there were only 2 files in there (ldap.so, phpcups.so), I added a pgsql.so file taken from another Linux box. I restarted httpd. And it does not work. I couldn't find any "pgsql" or "postgre" in phpinfo().
Forgive my noobness. I know too little Linux. I would really appreciate it if you can point me to the right direction.
I used the suggestion given by number5:
Dude, I'm on RedHat. I used the "yum" version of the command you gave, and I got this:
[root#perseus ~]# yum install php-pgsql
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=extras error was
[Errno 4] IOError:
Error: Cannot find a valid baseurl for repo: extras
UNFORTUNATELY, the Linux server I'm using is NOT connected to the Internet. Any other way to install?
It depends on which Linux distro you are using.
If you are using Ubuntu/Debian, you need to:
sudo apt-get install php5-pgsql
Fedora/CentOS
yum install php-pgsql
usually you can find out which distro you are on by:
ls /etc/*-release
On CentOS extensions create separate *.ini file one per each php extension in /etc/php.d
So, don't alter main *.ini file, but create /etc/php.d/pgsql.ini and add there a line
extension=pgsql.so
Then you will need to restart Apache using
service httpd restart
But the best automated way is to just type
yum install php-pgsql
In your case that didn't work because of some problems in yum configuration. Go to /etc/yum-repos.d
Type
nano /etc/yum.repos.d/CentOS-Base.repo
Scroll down to [extras] section and ensure it is like this:
#additional packages that may be useful
[extras]
priority=1
name=CentOS-$releasever - Extras
=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
Correct it if needed, save file (Ctrl-X) and do the following:
yum clean all
yum upgrade
Afterwards try to repeat
yum install php-pgsql
Remove the .so file you've copied from the other machine (though it might work, there's no need to take the risk)
Use the distribution's package manager to install the php_pgsql/php5_pqsql module
Restart the apache and try again. Maybe the module has been added to an .ini file automagically
If not, run <?php echo 'ini: ', get_cfg_var('cfg_file_path'); to see which php.ini you have to edit
edit this ini file
restart the apache
My operation system Linux mint kde and there was same issue
pg_connect()
You must install if you are use php5.6
sudo apt-get install php5.6-pgsql
After you must change extention name in "php.ini" file.
;extension=php_pgsql.dll
'dll' to 'so'
For example
extension=php_pgsql.so
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.