I was trying to set up a number of MediaWiki 1.4 sites. I'd written a bash script that duplicates the folder hierarchy and creates hard links to the files. I then remove LocalSettings.php, and run /wiki/config.
This worked for several websites, then refused to work on one. I kept getting the message: * Script URI path: /wiki Fatal error: Cannot redeclare class namespace in /Users/xxx/Sites/yyy/wiki/includes/Namespace.php on line 52
Now the "yyy" directory, in the directory of user "xxx", was symlinked into /Library/WebServer, which is the standard place on MacOS X. I went up and down that symlinked path, looking for permission problems, and found none.
But the problem wasn't in the symliked path! The home directory of user "xxx" had somehow gotten perms of "-rwxr-x--x" -- there was no read permission for others, which included the user "www" that Apache runs under! User "xxx" and I had the same group, so I was able to go into the directory with no problem.
I thought it a rather strange error message for a permission problem several levels up!
:::: Sex is hereditary. If your parents never had it, chances are you won’t either. -- Joseph Fischer :::: Jan Steinman http://www.Bytesmiths.com/Van
On Mon, 28 Mar 2005 19:57:28 -0800, Jan Steinman Jan@bytesmiths.com wrote:
I was trying to set up a number of MediaWiki 1.4 sites. I'd written a bash script that duplicates the folder hierarchy and creates hard links to the files. I then remove LocalSettings.php, and run /wiki/config.
This worked for several websites, then refused to work on one. I kept getting the message: * Script URI path: /wiki Fatal error: Cannot redeclare class namespace in /Users/xxx/Sites/yyy/wiki/includes/Namespace.php on line 52
Now the "yyy" directory, in the directory of user "xxx", was symlinked into /Library/WebServer, which is the standard place on MacOS X. I went up and down that symlinked path, looking for permission problems, and found none.
But the problem wasn't in the symliked path! The home directory of user "xxx" had somehow gotten perms of "-rwxr-x--x" -- there was no read permission for others, which included the user "www" that Apache runs under! User "xxx" and I had the same group, so I was able to go into the directory with no problem.
I thought it a rather strange error message for a permission problem several levels up!
This may address a class of similar errors reported by several users. See bug #1107 (http://bugzilla.wikipedia.org/show_bug.cgi?id=1107).
Could you post your solution at that bug? Or, with your permission, I will copy your original message there.
-- Rich Holton
en.wikipedia:User:Rholton
On 29 Mar 2005, at 05:55, Richard Holton wrote:
This may address a class of similar errors reported by several users. See bug #1107 (http://bugzilla.wikipedia.org/show_bug.cgi?id=1107).
Could you post your solution at that bug? Or, with your permission, I will copy your original message there.
Done! Although I consider it a work-around, rather than a fix. MediaWiki *should* install anywhere that Apache will work! There are many valid reasons for restricting access above, but poking a hole in the side.
:::: The record is clear that left to their own devices, the automobile manufacturers lack the wisdom or the will or both to switch decisively to the production of inexpensive, compact, energy-saving cars appropriate to our present needs. -- Donald E. Weeden, 1975 :::: Jan Steinman http://www.Bytesimths.com/Van
$IP is the local path of the wiki. (shared or instance?). $wgStyleDirectory and $wgUploadDirectory by default use this.
$wgScriptPath is used as a base for URLs. By default, $wgStylePath, $wgLogo, and $wgUploadPath use this.
Try messing with these (and the ini_set() call at line 8 of LocalSettings). They're all found in LocalSettings.php.
On Tue, 29 Mar 2005 08:56:07 -0800, Jan Steinman Jan@bytesmiths.com wrote:
On 29 Mar 2005, at 05:55, Richard Holton wrote:
This may address a class of similar errors reported by several users. See bug #1107 (http://bugzilla.wikipedia.org/show_bug.cgi?id=1107).
Could you post your solution at that bug? Or, with your permission, I will copy your original message there.
Done! Although I consider it a work-around, rather than a fix. MediaWiki *should* install anywhere that Apache will work! There are many valid reasons for restricting access above, but poking a hole in the side.
:::: The record is clear that left to their own devices, the automobile manufacturers lack the wisdom or the will or both to switch decisively to the production of inexpensive, compact, energy-saving cars appropriate to our present needs. -- Donald E. Weeden, 1975 :::: Jan Steinman http://www.Bytesimths.com/Van
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On 29 Mar 2005, at 14:45, Jamie Bliss wrote:
$IP is the local path of the wiki. (shared or instance?).
Yup, this is the culprit. The installer makes this the hard link path to the wiki, probably by using getcwd().
I don't know how it could do it better. Certainly, bash tells me the path via how I got there, but MediaWiki installer has no such history.
It could display the path and ask the user to verify it during the installation. Or, it could simply require that you tell it the path. I surely would have changed it to the symlink path, had I the opportunity.
This may also cause problems for those running super-secure sites in a chroot(2, 8) jail.
[clip]
:::: If addiction is judged by how long a dumb animal will sit pressing a lever to get a "fix" of something, to its own detriment, then I would conclude that the Internet is far more addictive than cocaine. -- Rob Stampfli :::: Jan Steinman http://www.Bytesmiths.com/Item/98-4880-34
mediawiki-l@lists.wikimedia.org