Ticket #172 (new task)

Opened 4 years ago

Last modified 2 years ago

Use new PHP 5.3 .user.ini for PHP configuration instead of hacked PHPRC

Reported by: ezyang Owned by:
Priority: major Milestone:
Component: web Keywords:
Cc:

Description (last modified by ezyang) (diff)

PHP 5.3 comes with Fedora 13 and has built-in support for user php.ini. This task involves:

  • Testing that .user.ini works, or twiddling the correct config option to enable it,
  • Updating our documentation (esp. the FAQ),
  • Updating our autoinstalls (Wizard especially) to use this instead of a symlink farm,
  • Modifying fix-php-ini to let users know about the alternate solution

See also http://php.net/manual/en/configuration.file.per-user.php

Change History

comment:1 Changed 4 years ago by ezyang

  • Description modified (diff)

comment:2 Changed 3 years ago by achernya

  • Milestone set to Fedora 15

comment:3 Changed 2 years ago by ezyang

  • Milestone changed from Fedora 15 to Fedora 17

Not a release blocker, re-milestoning.

comment:4 Changed 2 years ago by ezyang

  • Milestone Fedora 17 deleted

comment:5 Changed 2 years ago by ezyang

  • Priority changed from normal to major

comment:6 Changed 2 years ago by andersk

As far as I can tell, .user.ini does not currently let you load extensions, which is kind of a big problem.

comment:7 Changed 2 years ago by ezyang

One way around this is to patch

static void php_cgi_ini_activate_user_config(char *path, int path_len, const char *doc_root, int doc_root_len, int start TSRMLS_DC)
{
...
	php_ini_activate_config(entry->user_config, PHP_INI_PERDIR, PHP_INI_STAGE_HTACCESS TSRMLS_CC);

in sapi/cgi/cgi-main.c to call php_ini_register_extensions afterwards. We're even guaranteed not to attempt to double load extensions, since the extension_lists variable gets cleared! I don't know if this steps on any invariants; I don't think so, since usually you can load extensions arbitrarily late.

comment:8 Changed 2 years ago by ezyang

Sent mail to php-internals: http://news.php.net/php.internals/56143

comment:9 Changed 2 years ago by ezyang

Rasmus thinks this will work, but we will still have problems if we want FastCGI PHP, since .user.ini doesn't work for those.

comment:10 Changed 2 years ago by ezyang

I'm sorry, /extension loading/ probably won't work for user.ini FastCGI PHP. The big problem here is that user.ini files are handled per-request, whereas php.ini is handled once at FastCGI startup.

comment:11 Changed 2 years ago by ezyang

Note: it is very fiddly to get .user.ini to be picked up from command line. You appear to need to set the environment variables: REDIRECT_STATUS= GATEWAY_INTERFACE=CGI/1.1 SCRIPT_FILENAME=foobar.php DOCUMENT_ROOT=/path/to/foobar/

Trailing slash is necessary for DOCUMENT_ROOT, otherwise it will walk all directories except the topmost one. Also, you need to use the php-cgi executable.

comment:12 Changed 2 years ago by ezyang

Fixed in r2041. Not deployed yet.

comment:13 Changed 2 years ago by ezyang

Reverted, pending upstream approval.

comment:15 follow-up: ↓ 16 Changed 2 years ago by geofft

Just to be clear, "instead of hacked PHPRC" does not imply any interest on our part in reverting said hack in suexec, does it?

We should not gratuitously break people's sites that would have otherwise continued working absent some reason (like a security concern, or like it breaking other software like the exec bit hack did) to desupport the functionality. "The suexec patch is ugly" doesn't count.

comment:16 in reply to: ↑ 15 Changed 2 years ago by andersk

Replying to geofft:

Just to be clear, "instead of hacked PHPRC" does not imply any interest on our part in reverting said hack in suexec, does it?

No, but we’d use .user.ini in autoinstallers and stuff.

BTW, sane archive link: http://thread.gmane.org/gmane.comp.php.devel/69069

Note: See TracTickets for help on using tickets.