We are having almost the same issue as this person:
OCI8 functions not found when run by apache with php5
The difference between their issue and ours is that we only have one php.ini (/etc/php.ini). We are running PHP 5.3.5 with Apache 2.2.3 on CentOS 5.5. As you can see, their question was never really answered but I hope y'all can help up with ours. Thanks!
I have found the cause of the issue but I do not know how to permenantly solve it. Apparently, our test server is using SELinux set to "Enforce". Setting it to "Permissive" allows Apache/PHP to run the oci8 extension. My boss, however wants SELinux set back to "Enforce" for which I do not blame her. I'm going to look into creating an exception for Oracle/oci8.
Re. SELinux and OCI8 when running as an Apache module
Suggested solution from http://old.nabble.com/php-with-oci8-td16460446.html
you can customize your policy to allow this access using audit2allow
# grep http /var/log/audit/audit.log | audit2allow -M myhttp
# semodule -i myhttp.pp
This should allow you to run these oracle apps with SELinux in enforcing
mode.
There's also a thread about this on the oracle forums
Ensure that you have ORACLE_HOME, ORACLE_SID and LD_LIBRARY_PATH in the Apache envvars. Remember that Apache is running as a daemon, so it doesn't necessarily have access to the same environment variables as when you run your PHP scripts from the command line.
ORACLE_HOME=/u01/app/oracle/product/10.1
ORACLE_SID=orcl
export ORACLE_HOME ORACLE_SID
export LD_LIBRARY_PATH=${ORACLE_HOME}/lib:${LD_LIBRARY_PATH}
Depending where your database server is and how you connect to it you may also want to set TWO_TASK or TNS_ADMIN. To ensure the correct character set is used, you may also want to set NLS_LANG.
EDIT
I normally build PHP from source, so I have full control:
Assuming that the standard Oracle Client is running on the server, then my ./configure includes:
--with-pdo-oci=$ORACLE_HOME
On the couple of occasions when I've needed to build for the Oracle instant client, I've used
--with-pdo-oci=instantclient,/usr,10.2.0.3
in my ./configure line
Note that I use PDO_OCI rather than OCI8, but the ./configure should be similar
The other step that I take when deploying to a new server is to ensure that the apache user/group (as defined by the User and Group directives in httpd.conf... my apache runs as user "daemon") will have read and execute privilege to the files under ORACLE_HOME
Related
I'm buildig a simple web application in Laravel 8 using PHP 7.4 and Azure web services. The app runs perfectly on my local machine, but once I try to push my app to Azure I'm getting a PHP 500 error for all pages where some sort of querying is needed.
It turns out that I'm missing a pdo_mysql driver that hasn't been enabled when setting up our Linux server. I've been looking through all the Azure documentation and I can't seem to find how to turn this pdo extension on.
Strange thing is Azure provides us two terminals: the SSH terminal and a Bash terminal (Kudo remote execution terminal). When I run
php -m
in the SSH, the pdo_mysql module does show up in the list. I can also migrate my tables within the SSH. But once I run the same
php -m
command in the Bash terminal, the module is not showing. Migrating tables in that terminal is also not possible, because it says I'm missing the pdo_mysql driver. The Oryxbuilder that builds my application after each git deployment also notices that I'm missing the pdo_mysql driver and returns the same error.
So how can I enable this module in Azure? Can anyone please help me?
First of all i'd check to see if its enabled in the php.ini file, often located at /etc/php/{version}/cli/php.ini , cli may also be cgi or apache2.
I'm trying to run my Symfony website with XDebug, and PHP sockets at the same time.
To run the website:
bin/console server:start
To run the sockets
bin/console sockets:start
My sockets will not start unless XDebug is disabled.
However, I would like XDebug to be enabled for my website.
A solution is to disable XDebug system-wide in php.ini, but I would like to know if it is possible to do so at runtime, so I could unload XDebug before starting sockets when I run sockets:start.
Thank you!
To fix, before PHP 7 people would suggest to comment out the extension from php.ini file. However, in PHP 7 they are no longer in there.
Instead, we use the phpdismod command.
$ sudo phpdismod -s cli xdebug
The -s flag tells it to disable Xdebug for the CLI SAPI (/etc/php/7.0/cli) and not FPM.
And just like that, the warning message should be gone. No need to restart PHP
just assign two different ports for the debugger in the xdebug.ini (the CLI has it's own) -
because it sounds alike, as if it would get stuck due not being able to bind the port.
... this additional port then needs to be set up in the IDE, too.
I'm getting this PHP Warning:
Module 'pcntl' already loaded in Unknown on line 0
But it is only enabled for Apache. Enabled it on /etc/php/7.2/apache2/conf.d/20-pcntl.ini:
extension=pcntl.so
I don't have it enabled on CLI. Checked with:
I don't have a /etc/php/7.2/cli/conf.d/20-pcntl.ini file
Grep command grep -R extension=pcntl.so /etc/php/7.2 only returns the file on apache2 folder
If I disable this extension on Apache's .ini, it won't load on Apache but loads on Cli.
If I enable this extension on Apache's .ini, I get the module already loaded warning.
I'm need to enable PCNTL on Apache to use Spatie\Async library.
It's a Ubuntu 14 server.
Sometimes extensions are compiled into PHP rather than loaded as separate modules. Before fiddling with the PHP.ini files, you should probably run a quick PHP script to see what modules are loaded:
<?php
var_dump(get_loaded_extensions());
You should also beware of PHP directives like disable_functions which may be disabling the pcntl functions. On my Ubuntu workstation, the pcntl functions are disabled with this directive:
/etc/php5/apache2/php.ini:disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority
I suggest you try a broader grep search to see if pcntl gets mentioned in other places:
grep -ir pcntl.so /etc/php/7.2
I don't have a /etc/php/7.2/cli/conf.d/20-pcntl.ini file
That seems a bit weird to me. You might try searching for more php.ini files there:
sudo find /etc -name "php.ini"
You should also check to make sure that you aren't running a different PHP from the command line than you are with apache. Under certain circumstances (which regrettably happen more often that you might think) your CLI PHP is different than your Apache PHP. This article discusses that issue in more detail.
If I disable this extension on Apache's .ini, it won't load on Apache but loads on Cli.
That actually sounds reasonable to me. If I had to guess, I would say that the wise Ubuntu/Debian package manager folks decided it would be unwise to allow pcntl_x functions to run in an apache environment, especially given this stark and ancient warning. I don't recall if that warning is outdated now or not. I would refer you to this other thread where I asked some related questions and was told I should use PHP-FPM with apache in event mode.
All that said, I have had some tremendous success writing "multithreaded" applications in PHP (technically not multithreaded but rather multiprocessing) using pcntl_fork and posix_setsid and the like.
To summarize, I'm guessing that PCNTL is already loaded both on apache and cli and the wise Ubuntu devs probably disabled the pcntl functions in the php.ini.
I know this is long after the original post, but I faced a similar problem. I'm working on a AWS Linux AMI and pnctl seems to be pre-installed into php-cli (not loaded via php.ini)
The problem is Spatie async checks your PHP Runtime (PHP-FPM) to see if the pnctl and posix modules are loaded, which by default aren't even though they are available in php-cli which it actually uses when you create Spatie Async Pools.
My solution was to actually modify the php-fpm service to run with extension=pnctl.so
systemctl edit php-fpm
It will create an override file in /etc/systemd/system/
Modify the file by changing
ExecStart=/usr/sbin/php-fpm --nodaemonize to ExecStart=/usr/sbin/php-fpm -d extension=pctnl.so--nodaemonize and save that
Then restart your nginx and php-fpm services and pnctl should be active for PHP-FPM
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.
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.