Using a .user.ini file with extension=geoip.so (or mysqli.so) I'm trying unsuccessfully to load the relevant module: in the phpinfo() page of Php 7.1 (or even Php5.4) the module is never shown.
1) The .user.ini file is working correctly because I'm able to modify the variable memory_limit.
2) The phpinfo() function correctly shows the extension_dir folder containing .so extensions that I want to load (in the php.ini file this variable is not present, however).
3) The php error log contains no message.
Every suggestion is welcome.
The .user.ini files can only set certain PHP ini settings. It just so happens that the extension setting is not one of them. In fact, according to the manual, the extension setting is only valid in the core php.ini file. So put the extension=geoip.so in your main php.ini file.
As a side note: I use Ubuntu/Debian for most of what I do with PHP. The standard PHP distro that is available through the Debian package archives has extra code compiled into it that allows for a distributed configuration. The way this works is the SAPI module scans a conf.d directory and includes any ini files. Typically when you package an external PHP extension for Debian (which I might add is a pain - I've done it for my own extensions) you include a little ini file that includes the extension (e.g. extension=myext.so). The package installs it in the distributed config directory and it is included into the php.ini file when PHP spins up. Perhaps you meant to install a Debian-based config like this?
Another side note: Since you are probably using a CGI SAPI and might want different sites to load different modules (exclusively), you could perhaps look into getting the Web server to point the CGI PHP at a different php.ini file. I'm just presuming you want to achieve something like this. However loading modules for certain directories using .user.ini files is just not possible.
Try disable or configure selinux. Check selinux audit log.
Related
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.
Linux server, running suphp with Apache 2.2.22 and PHP5.5.17
When I upload an image using the image widget, it is stored in a date-based path under /file
the path directories are created with properties of -rwx------, and the file is stored with properties of -rw-------
This works fine when I am traversing the directory using shell, but Apache can't see the files, as it runs as not me.
What is a safe file into which I can add umask(002); that will be early enough in the application logic, but won't get overridden by updates? Can I create a Plugin and make it the only thing in the routes.php? Can I put this in my Theme file?
There is no such setting in ImpressPages yet. I guess you have to configure your Linux to use the right mask by default. Have you seen such a setting on other CMSs or Frameworks?
I recently modify the "include_path" var in my php.ini file. Before you ask, I restarted the apache service. The change work for every pages we access from a web browser.
The problem is the cron jobs doesn't seems to consider that change. When I do a phpinfo() inside the cron job, it uses the same php.ini file than the web server and it is the one I changed, but the value beside "include_path" is the old one.
So is there a way to "restart" crontab?
Or maybe there is another problem?
Several systems use a separate php.ini file for web and CLI. You will need to make changes in that one as well: How to find the php.ini file used by the command line?
The easiest way to find this file is to run this at the command line: php --ini which will result in output like this:
user#computer:~$ php --ini
Configuration File (php.ini) Path: /etc/php5/cli
Loaded Configuration File: /etc/php5/cli/php.ini
Scan for additional .ini files in: /etc/php5/cli/conf.d
What you see as "Loaded Configuration File:" is where you need to add your changes.
EDIT: Another option, is in your CRON script use set_include_path() to make the change at runtime.
PHP generally has two .ini files. One for in-webserver (SAPI) and one for command-line (CLI) usage. If you modified only the SAPI one, then anything running from CLI (e.g. cron jobs) will not see the change.
do a php -i at the command line to see where PHP is looking for its ini file while in that mode.
I have a couple of compressed zip file with static HTML content (e.g. a directory tree of documentation with several static html pages that link to each other, images, css, etc.) For instance, the javadoc zip file serves as an equivalent example for my purpose.
My question is, if there's an apache module that would allow apache to "mount" a zip file as a virtual directory, whose contents are those of the zip file. The operating system in which I'm hosting apache is Mac OS X Snow Leopard.
There is a zip filesystem for FUSE, which is supported on OS X via the MacFUSE project. This will let you mount a zip file via the mount command, thus allowing Apache -- or any other application -- to access its contents as a normal directory.
I don't have my Mac handy at the moment so I can't actually test it out.
I'm not aware of any existing Apache modules to do this, but you could implement it without touching Apache internals by adding a CGI script which handles access to ZIP archives:
Action zip-archive /cgi-bin/ziphandler.cgi
AddHandler zip-archive .zip
This will make ziphandler.cgi get called for all accesses to .zip files, or (more importantly!) to files in "directories" under .zip files. From there, it should be pretty straightforward.
Using proxy_http you can forward requests to Jetty which will serve any ZIP file.
Download Jetty Runner from here: http://mvnrepository.com/artifact/org.eclipse.jetty/jetty-runner
You can run it using e.g. java -jar jetty-runner-9.3.0.M2.jar --port 8082 myZIPFile.zip. Now set up Apache to forward requests to localhost:8082. You can do that for even only one subdirectory.
Is it possible to keep variables in php.ini file. Like that we do with the web.config in .net. I like to keep a flag type variable in the php.ini and use it to different projects.
It's not possible to set user-level variables within a plain php.ini file (or the .htaccess equivilents). There are some PECL modules that do allow that, such as hidef (http://pecl.php.net/package/hidef) - though these would need to be installed on every installation you use.
Including (or pre-including) a file with auto_prepend_file is quite possible - though that would be on every PHP request.
What is frequently done is setting an environment variable as part of the webserver process, which can be read from PHP. In Apache this is quite easy, with the SetEnv module.
SetEnv PRODUCTION_SERVER 1
And accessing it in PHP:
if ($_ENV['PRODUCTION_SERVER']) {...} // or getenv('PRODUCTION_SERVER')
Have you looked at get_cfg_var()?
I needed to do something similar, and this was able to do it for me.
Nope.
You could use the auto_prepend_file directive to automatically include a file that said, although as it uses the include_path, you'd need to specify the full path.
However, it's probably more transparent just to explicitly include/require the relevant file.
One technique that I have found useful for passing a limited number of global variables to a bootstrap script is to take advantage of the SetEnv directive in an .htaccess file. The advantage is that the variable you set will be made available to any script in that directory, plus any scripts in child directories under it.
You could use a SetEnv varibale with the location of a configuration file, such as:
in .htaccess:
SetEnv init_path /home/hendepher/TestApp/init/init.php
In your .php scipt:
<?php
if(!getenv('init_path')) throw new Exception('Must set init_path in .htaccess');
require_once getenv('init_path');
.
.
.
?>
If you have a test directory that requires different initialization o global variables, simply add another .htaccess file in your test directory:
SetEnv init_path /home/hendepher/TestApp/init/testing_init.php
Doing it this way, as opposed to using the 'auto_prepend_file' directive, is that your global configuration script is not run by all the php applications on your server: some may not need it.
The accepted answere also worked for me, with one change.
I didn't test this on earlier versions, but in my environment (php 5.4.22) this doesn't show up in $_ENV, but rather in $_SERVER.
In my .htacess file:
SetEnv PRODUCTION_SERVER 0.
My php code:
$production="PRODUCTION";
if (!isset($_SERVER['PRODUCTION_SERVER']) || $_SERVER['PRODUCTION_SERVER'] != 1){
$production="DEVELOPMENT";
}
I don't think that's a good place to store variables. php.ini is for storing configuration for PHP itself not your applications. You should consider putting the shared variables into a .inc file and including that instead.
Have you considered hidef?
Allow definition of user defined constants in simple ini files,
which are then processed like internal constants, without any
of the usual performance penalties.
Complementing #Ascherer answer, use get_cfg_var() to save custom variables in custom php.ini (variable created by you, not an official PHP ini directive). For example:
In php.ini: custom_variable = "abcde"
In any php script: get_cfg_var('custom_variable') returns abcde
I use this in in a small project in local dev. As I run the local server via php -S localhost:8000 -c php.ini (not running an Apache server locally), it's a good option to call some configuration constants. In production, these constants are set in .htaccess.