Last modified: 2011-04-04 21:28:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1107 - Fatal error: Cannot redeclare class namespace in...
Fatal error: Cannot redeclare class namespace in...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.4.x
Other other
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://rci.rutgers.edu/~rack/info.php
:
: 1407 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-15 18:52 UTC by Rob
Modified: 2011-04-04 21:28 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rob 2004-12-15 18:52:17 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
Comment 1 Zigger 2005-01-26 00:53:11 UTC
*** Bug 1407 has been marked as a duplicate of this bug. ***
Comment 2 Jan Steinman 2005-03-29 16:55:00 UTC
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.
Comment 3 Jan Steinman 2005-03-30 02:13:17 UTC
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.
Comment 4 Brion Vibber 2005-04-17 23:27:28 UTC
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.
Comment 5 Brion Vibber 2005-11-10 08:23:16 UTC
[adjusting bug to fix db consistency warning; operating system was set to a no longer 
existing value]

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links