Last modified: 2011-03-13 18:05:38 UTC
While attempting installation of MediaWiki 1.5.6 inside a sourceforge account, I ran into the problem that the web tree is not writable by the web server, so MediaWiki installation fails as the config folder cannot be made writable. In looking at how to fix this, I noticed that the location of the created config file is hard-coded in multiple locations. I cleaned this up a bit and defined a bunch of constants for naming and locating new and existing config files. This simplified my sourceforge install greatly, and should help others in similar situations. It would be nice to extend the config form to deal with this, but this is an improvement for now. Three constants are defined: MEDIAWIKI_CONFIG_FILENAME contains the default 'LocalSettings.php' filename; MEDIAWIKI_NEW_CONFIG_DIR (defaults to '.') which is an absolute path or a path relative to the config folder indicating where a newly created config file should be placed; MEDIAWIKI_EXISTING_CONFIG_DIR (defaults to '..') which similarly indicated the location of an existing config file. I then amended the code that locates and creates the config file (don't think I missed any) to use these constants, and I attach a patch relative to the 1.5.6 source.
Created attachment 1420 [details] Patch to config/index.php to streamline config file location
Created attachment 1421 [details] Better config location patch for config/index.php Apologies for that first patch - I had misinterpreted the purpose of $sep. This patch is better (using DIRECTORY_SEPARATOR instead), and also improves interface feedback to reflect the actual location of files written.
Why was this classed as invalid? It's pretty dumb to have multiple hardcoded paths at the best of times - MediaWiki's own code spends considerable effort working out an include path - why not apply the same approach to the config file? If it really is considered invalid, then there should (by definition) be a documentation change saying 'MediaWiki CANNOT be installed on servers that do not allow write access below the web root'. If on the other hand you don't consider that statement to be true, then this patch is not invalid, so make your mind up. If on the other hand you had an objection to the particular implementation, then you could at least have had the decency to say so.
You're always free to do a manual installation if your host is broken.
Well that's what I did by fixing the installer, thus making it easier for others to do the same, and making MediaWiki more reliable, flexible and able to be installed easily on 'broken' hosts such as SourceForge. I can't think of any real downside to this patch - duplicated, hard-coded paths are considered by many to be a bug in their own right. I'm sorry if I got the impression that this was a collaborative, open-source project supported by contributors.
(Note that MediaWiki is primarily in-house software for Wikipedia, so the installer doesn't get much lovin'.) I don't really like this implementation; since it requires hacking up the source it's still not providing for a clean install out of the box. Would it be better to allow, say, automatic selection of a temp directory or just dumping the config file to output for copy-and-paste?
I mentioned something to that effect in my original post - yes it would be nice to be able to set this from an installer form - perhaps one that appears if it finds that the default file location is not writable? I also agree that while hacking the source to fix the install is not great, it's much better to only have to hack it in one place instead of six or so (and with a far greater chance of failure). Having changed the code so that it does have a single definition for the file location also means that writing an interface for it will be easier. I wasn't really planning to, but I could give it a go if you like. I appreciate that MW is mainly in-house - that's why you need contributors to be annoyed by the bits you don't use ;^)
Hello, I just ran into this bug posting after pulling my hair out why MediaWiki would not install in our project team's sf.net webpage. [1] I know of at least one other person that gave up on trying ot get their sf.net webspace up and running with mediawiki, and so loaded it on his own domain. Action Item (just suggestions, but could help, I don't know if this this a thread hijack but this topic is directly related to sf.net setup and user workarounds): - WikiMedia is great software and lots of project teams benefit from a wiki being used to maintain doc. Please post some kind of information article directed towards users of sf.net on the sf.net project webspace about the problems sf.net users encounter and how it is recommended we should resolve them. =( - Perhaps have a bug listing in Mantis with the words sf.net sourceforge.net in the title of the submission (I wasn't able to locate one, so as a result I dug inside the bug threads and found this! =) ) - Idea (may not be practical or appropraite): If you detect sourceforge.net as the hostname in the wikipedia autoconfigure process, present a link in the autoconfigure to tell someone to visit a particular link. -- Better yet, maybe if you can detect somehow the the config folder cannot be writable (how?- maybe if the user reruns the web based autoconfigure process multiple times and keeps getting the same message...), present some information to the user about the specific problem he/she could be experiancing and how to resolve it (or where to read more on it) Thank you so much for this thread. I hope we can at least save some time and effort of future installers of mediawiki on sf.net. =) [1] I've tried installing wikimedia months ago then recently retried to get the same error message regarding my config directory not being writable, and thus began looking into it deeper. I was able to get it working without a problem many times in the past on my own domains, so didn't understand where the problem could have originated.
I'm claim to be no expert on this issue, but from what I've digested and understood, I've posted a support request to sf.net on this issue. Please review it, correct it, and lobby, as necessary, to see advancements in this area: SourceForge.net: Modify: 1523144 - Web tree under web root is not writable by the web sever https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1523144&group_id=1 This is also left here as a footprint for those trying to resolve this issue as well, from a policy standpoint.
Getting SF.com to make their web space globally writable is not a good idea - because all project sites are run under the same user, it would mean that any site could write into any other. A better solution would be for mediawiki to support an alternative to writing a local config file, such as displaying the config file contents in the installation page so that it can manually be saved in a local file via non-web means.
I'm WONTFIXing this for several reasons. 1) We're not going to change the name of LocalSettings.php or make it customizable. 2) The name of the installation path "/config/index.php" is static and also does not need customization. Whether or not this is a good name (/config seems to conflict) is under discussion at bug 1379. 3) Writing to /config is unsafe. Plans for the new-installer are to ditch writing of LocalSettings.php to the /config directory, and instead offer it as a download to the site administrator to then put in place.
Goodness, I'd forgotten I'd written all this. I find your conclusion nonsensical - My changes for 1 above does not amount to customization, merely that making the definition only in one place (aka DRY), which is just good coding practice IMHO. WHEN you decide to change it, chances are you'll write code that does pretty much the same thing. Either that or invite disaster by making changes in multiple locations. 3 directly conflicts with 2: you say that writing to config is dangerous (which is why SF doesn't allow it), but then refuse to provide a workaround. Also, again my changes really only amount to making this so it's set only in once place, it doesn't represent any change in policy. Allowing someone to hack the path simply (for example so it writes somewhere that's writable but not under the web root) seems like a handy side effect. To summarise: my patch would: a) simplify changing paths used by mediawiki and make doing so safer and more reliable, pre-emptively fixing future bugs in that area b) have a side effect of making changing them again easier, even though that may not be the primary aim c) make mediawiki installations on sourceforge easier I'm mystified why you'd not want this fix; the alternative means you're deliberately choosing to live with bad code for no good reason.
(In reply to comment #12) > Goodness, I'd forgotten I'd written all this. > Lots of installer bugs are old. None of the patches on them apply to the new installer. > I find your conclusion nonsensical - My changes for 1 above does not amount to > customization, merely that making the definition only in one place (aka DRY), > which is just good coding practice IMHO. WHEN you decide to change it, chances > are you'll write code that does pretty much the same thing. Either that or > invite disaster by making changes in multiple locations. > /config isn't hardcoded in a bazillion places these days. It wouldn't be hard to find and fix the few manual usages. Like I said above, if we decide to change where the entry point is, that's being discussed at bug 1379 > 3 directly conflicts with 2: you say that writing to config is dangerous (which > is why SF doesn't allow it), but then refuse to provide a workaround. Writing to /config isn't safe. Neither is writing to /foobar or /mysecretinstaller. Changing the directory does nothing to mitigate the issue. We don't want the web server being the owner of the config file at all. See http://www.mediawiki.org/wiki/New-installer_issues?diff=334526&oldid=333913 for more information. >Also, > again my changes really only amount to making this so it's set only in once > place, it doesn't represent any change in policy. Allowing someone to hack the > path simply (for example so it writes somewhere that's writable but not under > the web root) seems like a handy side effect. > > To summarise: my patch would: > > a) simplify changing paths used by mediawiki and make doing so safer and more > reliable, pre-emptively fixing future bugs in that area > b) have a side effect of making changing them again easier, even though that > may not be the primary aim > c) make mediawiki installations on sourceforge easier > To summarize, we're changing the installer so that you no longer have the web server writing the config file. So customizing it is no longer an issue :) > I'm mystified why you'd not want this fix; the alternative means you're > deliberately choosing to live with bad code for no good reason. You haven't seen the new installer, have you? The code is far better than when you submitted that patch ;-) http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/installer/
