Recently I installed lamp and php-xdebug on an ubuntu 16.04 box. I noticed that now I have the following files
/etc/php/7.0/apache2/conf.d/20-xdebug.ini
/etc/php/7.0/cli/conf.d/20-xdebug.ini
/etc/php/7.0/mods-available/xdebug.ini
I was wandering what is the difference is between these files and settings in /etc/php/7.0/apache2/php.ini are affected by these.
Also in terms of best practice which of these files should be used?
If configurations are repeated in these files with different values which would take precedence?
For example if xdebug.remote_port = 9000 is set in /etc/php/7.0/apache2/php.ini and in /etc/php/7.0/mods-available/xdebug.ini it was set as xdebug.remote_port = 9001 which value would be selected?
Ubuntu is based on Debian. Debian and it's derivatives use a somewhat unique way of managing extensions for php and apache.
Of the files you have listed:
/etc/php/7.0/apache2/conf.d/20-xdebug.ini is a symlink to /etc/php/7.0/mods-available/xdebug.ini
/etc/php/7.0/cli/conf.d/20-xdebug.ini is also a symlink to /etc/php/7.0/mods-available/xdebug.ini
You can edit /etc/php/7.0/mods-available/xdebug.ini directly and changes you make will affect everywhere it is enabled.
Commands phpenmod and phpdismod are available to enable or disable PHP modules. These are like a2enmod for apache, which you can read about here. For example, turn XDebug off with sudo phpdismod xdebug. Turn it back on with sudo phpenmod xdebug. Your configuration will be preserved when you flip it on and off because your changes are always preserved in mods-available, although PHP does not look in that directory for configuration. In fact, when you "disable" the module with phpdismod, it's simply removing the symlink from the appropriate folder so that the module is not enabled in the php config.
Finally, /etc/php/7.0/apache2/php.ini is the location for system-wide config that is not a module that can be enabled or disabled.
Thus, your config changes like xdebug.remote_port = 9000 should go in /etc/php/7.0/mods-available/xdebug.ini since it's related to XDebug. Putting it in both places is a bad idea (because of the confusion it creates), but the last one to load takes precedence. This is why many of the files in the mods-available directory have numbers in the filename - so they'll load in the correct order.
Use the phpinfo() function to get more info about which config values were loaded and what ini files they were loaded from. For example:
$ php -r "phpinfo();"
or
$ php -r "phpinfo();" | grep xdebug
This depends on how PHP was compiled. Take a look at how PHP was compiled by reviewing the list of .ini files it is loading and from where they are being loaded.
From the command line, type the following and review:
$ php -i | grep .ini
Or, you can learn of this by creating a temporary PHP file and visiting it in a browser. Just be sure to name it something difficult to find, and delete it right after you're done; e.g., /info-949w30.php. Why? Because this report may leak full filesystem paths, version numbers, and other details.
<?php phpinfo();
PHP has two directives that are established when it's compiled.
--with-config-file-path=path/to/main.ini
--with-config-file-scan-dir=/scan/this/dir/for/other.ini files.
The main .ini file is loaded first, and then files in the scan-dir are loaded alphabetically after that. Which is why you see a lot of .ini files using a numeric prefix. That's an easy way to take control over the load order. Changing the name of the file in relation to others in the directory.
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 have found that:
When I type the following on terminal:
php -i | grep php.ini
I get the output:
The Loaded Configuration file is # /etc/php5/cli/php.ini
However, from phpinfo(), I get to see:
The loaded ini file is # /etc/php5/apache2/php.ini
Which one of these is working right now? How is it possible to have two php.ini files ?
Depends on where you are running PHP from. If you run it from command line, it uses the cli/php.ini and apache2/php.ini when run through apache.
You are executing phpinfo() through the browser, hence you get /etc/php5/apache2/php.ini as the answer. Running php -r "phpinfo();" | grep "Loaded Configuration" from the terminal should output the CLI ini. Same function, context changes.
The advantage of this system is obviously to allow different configurations depending on the context. For a simplified example, you might want to have safe_mode on in apache but it's unnecessary in CLI mode.
Your .ini paths are actually quite unusual. Normally, the default .ini is just php.ini and CLI .ini is called php-cli.ini and they reside in the same folder.
I'm no expert on the subject but this should be the basic idea. If anyone has any corrections, I'd be happy to hear them.
I am attempting to install ionCube on my VPS from DigitalOcean and I have ran the install and selected the appropriate options but then it simply returns a screen with the header of ionCube but then it has a banner saying "IMPORTANT: Ensure that This Script Is Removed When No Longer Required" followed by a single line of writing that says "ionCube Loader Wizard" and does nothing. In addition the application that it using ionCube says it is still not installed.
The empty Wizard page might indicate that a few PHP functions are disabled, though without the output of your phpinfo(); I can only guess.
DigitalOcean themselves have instructions on how to install the Loader, which can be found here. These are applicable to most VPS with slight alterations. A rough summary in case the link isn't available:
Get and unpack the newest Loader on your server: (if you are not on DigitalOcean please choose your own Loaders here)
32bit:
wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz
tar xvfz ioncube_loaders_lin_x86.tar.gz
64bit:
wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz
tar xvfz ioncube_loaders_lin_x86-64.tar.gz
Find out your extensions directory:
php -i | grep extension_dir
Which will yield something like
extension_dir => /usr/lib/php5/20090626+lfs => /usr/lib/php5/20090626+lfs
Copy the Loader to the extensions directory:
PHP_VERSION=$(php -r "echo PHP_MAJOR_VERSION.'.'.PHP_MINOR_VERSION;")
sudo cp "ioncube/ioncube_loader_lin_${PHP_VERSION}.so" /your/extensions/dir
For example with the previous output:
PHP_VERSION=$(php -r "echo PHP_MAJOR_VERSION.'.'.PHP_MINOR_VERSION;")
sudo cp "ioncube/ioncube_loader_lin_${PHP_VERSION}.so" /usr/lib/php5/20090626+lfs/
Add the zend_extension entry to your php.ini. This step is not described in the DigitalOcean tutorial, it seems that their PHP is set up to load any extension in the extensions directory I assume, so this might not be necessary for you.
Find out where your php.ini file is (or better yet, plugin directory):
php -i | grep "Loaded Config"
php -i | grep "Scan this dir"
You will get something like this:
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
You can either add this entry to the top of your php.ini (in this case in /etc/php.ini), or add a new file 00-ioncube in your ini directory (in this case /etc/php.d/00-ioncube with this content:
zend_extension = "<path to your ioncube loader>"
As an example with PHP 5.5 and the previous path:
zend_extension = "/usr/lib/php5/20090626+lfs/ioncube_loader_lin_5.4.so"
Restart your webservers:
service apache2 restart
service php5-fpm restart
Do remember to delete the ionCube Loader Script you installed from your server, since this might pose a security risk if left on the server.
In case something goes wrong, check the output your phpinfo();, verify that you have the correct Loaders installed (pay attention to thread safety, architecture and PHP version) and get the Loaders manually from here, and again make sure to choose the right one.
If it still does not work, check your error.log (typically in /var/log/apache2/error.log or /var/log/httpd/error_log) to see if the Loader is being picked up. The ionCube Support is also available should there be any problems.
I have setup Eclipse 3.6.2 on Ubuntu 11.4 for AMD64 and Xdebug.
Eclipse was installed with zip download from eclipse.org.
PHP and Xdebug were setup with apt-get.
When I run the PHP script in the shell they will use the /etc/php5/php.ini file and parse additional ini files in /etc/php5/conf.d/.
When I run in Eclipse (run mode or debug mode) it will only parse php.ini and no additional ini files.
Basically, all extensions, are not loaded.
It is an intentional bug.
PDT executes php with "-n" option always. It makes additional ini files unavailable.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=339547
also https://bugs.eclipse.org/bugs/show_bug.cgi?id=347618
BTW, you'll be able to add a shell script which trims "-n" option as PHP Executable.(Preferences>PHP>PHP Executables)
For example,
#!/bin/sh
if [ $1 = "-n" ]; then
shift;
fi
/usr/bin/php $*
The answer #atlanto gives as a work around did and does still work, but recent version of Eclipse (I'm on Neon) has a fix that may work for you if you don't mind using the php.ini and conf.d set by default for the php executable.
The failing to load additional files only happens now if you put in an explicit php.ini file when defining a PHP executable. Leave this blank and check the box Use system default php.ini configurate.
Now if you use the location/php.ini that was specified as default when the executable was built, it will respect scanning of conf.d directories.
Here's how to check if your php has scanning conf.d enable and where the approriate default location is:
php -i "(command-line 'phpinfo()')" | grep "Configure Command"
You should see something like:
Configure Command => './configure' '--prefix=/usr/local/Cellar/php5/5.6.29_5'
'--localstatedir=/usr/local/var' '--sysconfdir=/usr/local/etc/php/5.6'
'--with-config-file-path=/usr/local/etc/php/5.6'
'--with-config-file-scan-dir=/usr/local/etc/php/5.6/conf.d'
'--mandir=/usr/local/Cellar/php56/5.6.29_5/share/man'
... and so on...
The items that matter are:
with-config-file-path: this where it will look for your php.ini file
with-config-file-scan-dir: this is the conf.d that will be scanned
If you still wish to choose a different in location than the default for the executable your options are:
Inline the module directives from and file in conf.d into your alternate php.ini
Rebuild php and set the above options to your new location as default
Use the wrapper script #atlanto indicates
I have found that:
When I type the following on terminal:
php -i | grep php.ini
I get the output:
The Loaded Configuration file is # /etc/php5/cli/php.ini
However, from phpinfo(), I get to see:
The loaded ini file is # /etc/php5/apache2/php.ini
Which one of these is working right now? How is it possible to have two php.ini files ?
Depends on where you are running PHP from. If you run it from command line, it uses the cli/php.ini and apache2/php.ini when run through apache.
You are executing phpinfo() through the browser, hence you get /etc/php5/apache2/php.ini as the answer. Running php -r "phpinfo();" | grep "Loaded Configuration" from the terminal should output the CLI ini. Same function, context changes.
The advantage of this system is obviously to allow different configurations depending on the context. For a simplified example, you might want to have safe_mode on in apache but it's unnecessary in CLI mode.
Your .ini paths are actually quite unusual. Normally, the default .ini is just php.ini and CLI .ini is called php-cli.ini and they reside in the same folder.
I'm no expert on the subject but this should be the basic idea. If anyone has any corrections, I'd be happy to hear them.