Last modified: 2011-04-04 21:28:26 UTC
Installation message: ---- Warning: set_time_limit(): Cannot set time limit in safe mode in ../install-utils.inc on line 27 # PHP 4.3.4: ok # Warning: PHP's register_globals option is enabled. MediaWiki will work correctly, but this setting increases your exposure to potential security vulnerabilities in PHP-based software running on your server. You should disable it if you are able. # Warning: PHP's safe mode is active! You will likely have problems caused by this. You may need to make the 'images' subdirectory writable or specify a TMP environment variable pointing to a writable temporary directory owned by you, since safe mode breaks the system temporary directory. # PHP server API is apache; ok, using pretty URLs (index.php/Page_Title) # Have XML / Latin1-UTF-8 conversion support. # PHP is configured with no memory_limit. # Have zlib support; enabling output compression. # Turck MMCache not installed, can't use object caching functions # Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads. # Installation directory: /pandemonium/vol1/home2/u4/rack/public_html/wiki # Script URI path: /~rack/wiki # Warning: $wgProxyKey is insecure Fatal error: Cannot redeclare class namespace in /pandemonium/vol1/home2/u4/rack/public_html/wiki/includes/Namespace.php on line 52 ---- This is on a university server that is fairly locked down. Here is the php info: http://rci.rutgers.edu/~rack/info.php
*** Bug 1407 has been marked as a duplicate of this bug. ***
This may be a permissions problem. Check them carefully, all the way to root, through the hard directory structure. I got the same error, and carefully checked permissions all the way to root and they were all good. But this was a symlinked path! The symlink permissions that allowed read access to user www (the user running httpd) ran up to the web server root directory, and were okay, but the *hard link* path was in a user directory, which had perms of "drwxrwx--x", which did not allow user "www" read access. Changing this to "drwxr-xr-x" solved the install problem. This was a couple levels above the actual website directory. This is doubly odd, since the website in the user directory had been working fine. Obviously, Apache could get in through the symlink, but MediaWiki must be resolving and attempting to use the hard link path. So I consider this a work-around, rather than a bugfix -- MediaWiki *should* install in any directory that Apache has no problem with. This makes me think there may be problems installing in a chroot jail. This was on MacOS X. Here are the actual paths (name changed to protect the guilty :-) Hardlink path: /Users/xxx/Sites/yyy/ -- directory "xxx" (user name) had perms "drwxrwx--x" Symlink path: /Library/WebServer/yyy/ -- directory "yyy" is a symbolic link to directory "yyy" above Hope this is helpful. Contact me if you need more info.
Jamie Bliss has isolated this to the variable $IP in LocalSettings.php. The install script /wiki/config/index.php is apparently using getcwd() to write this setting out, which will be a hard linked path to root. Suggested fix: put the discovered path in the install form and allow the user to change it to a symlinked path if they have need to restrict permissions on the hard linked path. This behavior may affect other situations, like remote mounted filesystems or chroot(8) jails.
This should be fixed now in 1.4.1. The problem is that when a parent directory is not readable, realpath() cannot resolve the relative path to a canonical path. PHP then puts the relative form into its list of already-included files, and a different form will not be recognized as the same file (../includes/Namespace.php vs includes/Namespace.php). I've now got it setting up the include path first and using more consistent relative paths, which gets it through the installer on my Mac when I set my home directory to o-r.
[adjusting bug to fix db consistency warning; operating system was set to a no longer existing value]
