Core PHP Functions?

I'm getting

Tim @ Nimbus says these are the only disabled functions in PHP and are disabled by default:
system, proc_open, parse_ini_file, show_source
I wish the above message was more specific.

Did you leave these disabled Stuart? The reason I ask is because I am also with Nimbus and will be doing an upgrade at some point.
 
There are no functions that are disabled in the default PHP configuration, though different distributions might disable certain functions.

Ubuntu Server 12.04 runs by default with PHP5.3 and Suhosin. That would probably throw up this warning.
 
i get this same error but the only thing i have disabled is disable_functions = mail, i am using something else to handle my mail and xenforo works fine with it... the mail that i have disabled is the standard php version
 
Tim @ Nimbus says these are the only disabled functions in PHP and are disabled by default:
system, proc_open, parse_ini_file, show_source
I wish the above message was more specific.
Why would you have those functions disabled? If someone would want to take over your server, it will certainly NOT be through PHP. You can easily check what functions are disabled in PHP, I have none disabled:
Code:
# php -r "var_dump(ini_get('disable_functions'));"
string(0) ""
I understand some hosts have the tendency to disable functions for shared accounts in order to avoid shady software commands, but we are not dealing with that situation in XenForo. Tim should focus on how to protect their cloud against blue/red pill attacks for example, instead of disabling PHP functions. :)

And for the love of God people, please stop editing php.ini and use /etc/php.d for that instead. We are blessed with .d directories and nobody use them... makes you think why the Linux software developers bother to make our life easy if nobody uses the tools they provide.
 
Last edited:
  • Like
Reactions: rdn
And for the love of God people, please stop editing php.ini and use /etc/php.d for that instead. We are blessed with .d directories and nobody use them... makes you think why the Linux software developers bother to make our life easy if nobody uses the tools they provide.
problem is... you are thinking centOS centric... not ALL distributions use the same format. There is no such critter as /etc/php.d in Debian (and I'm pretty sure under Ubuntu either). :p
 
@Tracy Perry, then they choose a bad approach, I'm really surprised to hear this. .d directories are essential to avoid editing important configuration files that can affect upgrades.
 
When upgrading it gives you an option to use yours, use the packagers, compare the contents and one other option. Just a difference in philosophy for the basics.
It's the difference in the packaging philosophy between them.
And you should preface that with "In my opinion" because apparently it's been working just fine since Debian has been out. ;)
Some prefer a monolithic setup and others want it broken down to multiple files to include.

As a matter of fact, there is not even such a critter as /etc/php on a Debian system... it's /etc/php5 now. You can still do an include in the php.ini. That's also the difference in compiling your own source and using the package(d) I would assume.... the packaging on Debian will not automatically stomp over your settings.
 
Found this for you @Floren.... never have played with it (as /etc/php5-fpm/conf.d is where the module configs typically are) but it would probably work for custom configs also
Code:
Configuration layout
For each major release N of PHP (where N is 4 or 5), each of the 4 SAPI's (apache/apache2/cgi/cli) have a different central configuration file /etc/phpN/$SAPI/php.ini.

Additionally, each SAPI is configured with the compile-time option


--with-config-file-scan-dir=/etc/phpN/$SAPI/conf.d
which for all SAPI's is actually a symlink pointing to a central directory /etc/phpN/conf.d. Any file found in this directory ending in .ini will be treated as a configuration file by the PHP SAPI.

The rationale with this method is that each SAPI can thus be identically configured with a minimal amount of conffile handling, but at the same time if you want to have SAPI-specific configuration, you can just remove the symlink.

Add something like local.ini in there and it should work.
 
Top Bottom