MediaWiki

New installer/issues

< New installer

This is a list of known issues in the new-installer branch. List started from Tim's list at [1].

All open installer bugs which can be fixed in the branch. Tracking bug

Some bugs we wanted to fix: 13230, 17691, 198, 2837, 10541, 10596, 11013, 13409, 16902, 17394, 17762, 19129, 20627, 21576
Two outstanding issues from /branches/new-installer: r63389, r64717
Unreviewed installer code in trunk
Fixme'd installer code in trunk

Outstanding issues

edit

Critical

edit
  • Evaluate restart possibilities for failed install step
  • Long single word field labels can run under input fields. Example on page=DBConnect in Dutch 'config-db-prefix' (Databasetabelvoorvoegsel:) like this

Non-critical

edit
  • Review initial main page text
  • I think it could be made more beautiful and informative. -- Tim Starling
  • Fieldset legends are very small, smaller than the labels for fields.
  • Selecting a different interface language on first page, should reload the page in the chosen language.
  • Fix parsing of multi line messages in the i18n files. In page=Welcome multiline messages get a <>p> for the second line causing it to be displayed on two lines instead of in one paragraph. Example: 'config-gd'
  • SQLite DoS issues: because it doesn't need a password for DB access, an attacker could create an infinite number of database files around, depleting disk space. Need to handle this, including cases where LocalSettings is not writable and installer offers the user to create it manually.
    • After my non-writable config dir feature is implemented (see above), the only directory we can be sure we're able to write to is the directory the SQLite DB is created in. I suggest writing a specially-named resource limit tracking file into that directory, and into the parent of any directory created by wfMkdirParents(). It could be a flat text file listing the paths of the SQLite files which have been created. Opening it in append mode avoids the concurrency issue you'd have if you tried to update a simple count. Then when the install step is submitted you'd scan from the requested directory back to the filesystem root looking for the tracking file closest to the root. You'd check the line count, and then update it if it's smaller than a given limit. The error message should include information on which file should be deleted to re-enable installation. -- Tim Starling 03:04, 30 June 2010 (UTC)[reply]
  • Command-line installer: I (Max) have started working on it. Now hexmode is at it.
  • Max said on IRC that he didn't get far with it. I'm interested in it, and config-driven installation. Ideally it should be generic enough for Wikimedia to use it when installing new wikis, and Debian should be able to interface with it to install wikis via apt. --Ævar Arnfjörð Bjarmason
  • If some field does not validate, it should be highlighted in addition to error messages somewhere in the page.
  • Field for sqlite data dir could be longer. The directory usually doesn't fit.
  • If the mysql account is root, the default shouldn't be to use the same account for web access.
  • Can we log in the user account we've just created?
  • config-db-web-no-create-privs is unclear and repetitive, needs some tweaks.
  • Super minor non-important UI things that crossed my (bawolff's) mind when testing it:
    • The bullets aren't using real lists but divs and images, which renders differently (not indented), which kind of looked weird to me
    • On hoovering the help links, it'd be nice if there was a tooltip that said click to expand (At first i thought the help would come up as a tooltip)
    • Help links placement is inconsistent. Sometimes below the text box it refers to, sometimes above.
    • The vertical alignment of the You are almost done! You can now skip the remaining configuration and install the wiki right now. is kind of weird, I think it'd look better if the text was aligned with the middle of that icon (or even on the same base line), not at the top of that icon. Bawolff 22:27, 6 March 2011 (UTC)[reply]

Fixed issues

edit
  • Test canCreateAccounts()
  • Fix session expiry message "$1"
  • Object cache settings
  • Make sure usernames are trim()'d
  • RELEASE-NOTES does something funky with left sidebar font sizes :-\
  • Additional e-mail settings need adding
  • Continue button on "Completed installation" leads to null page
  • Spews ugly warnings if sessions path is not writable (old installer did not)
  • Project namespace, the first alternative, the javascript needs to add space or it looks like this Same as the wiki name:Foobar
  • Object caching defaults to Memcached, while APC installed. Should check that APC cache is big enough.
  • SQLite installation fails with no error, only output is: " * Setting up database..."
  • "Advanced configuration" box on options page is empty.
  • Don't offer "MediaWiki" as custom project namespace name by default, it's invalid (what other sane value could it be?)
  • Sqlite permission values are confusing at best, useless for Windows users, and don't even work as advertised (usual oct/dec conversion issues). Probably just remove?
  • Does it make sense to add version of MediaWiki that generated LocalSettings to that file to keep track of things?
  • We currently have two sidebars with partially duplicated content.
  • Sniff languages from Accept-Language?
  • Check if config/ is writable
  • Write LocalSettings' content on the page if it failed to write the file
  • Major: Post upgrade, if you choose to regenerate LocalSettings, it runs the full install. This is bad.
  • README/RELEASE-NOTES/COPYING all need to be properly wiki formatted, else we need to include wiki-formatted version
  • Easier to just force wiki formatting in the files, waste of time to have two
  • Or you can regex-foo it like here and here
  • Check with Mike Godwin if translated license with link to original text is OK
  • Put GFDL licenses one level down, and possibly mark as not recommended. At least display CC above GFDL
  • Yeah, this is out of date:
If you want to be able to use text from Wikipedia, and you want
Wikipedia to be able to accept text copied from your wiki, you should
choose GNU Free Documentation License 1.2. However, this license has
some features which make reuse and interpretation difficult.
Should say that Wikipedia uses CC. More lawyering needed. --Ævar Arnfjörð Bjarmason
  • Creating LocalSettings.php... Done
Either use no HTML or enable it in these status messages
  • Hide "Memcached servers" input whem memcached is not selected.
  • Going directly to the release notes produces an error by using LBFactory_Fake
  • (there's a catch for a InstallerDBAccessError class which isn't anywhere)
  • WikiSysop doesn't seem to be getting +sysop and +bcrat bits
  • CACHE_MAIN defaults to NONE?
  • Deactivate the installer when LocalSettings.php is present, as in the old installer. Omitting this feature was a hack for easier testing. -- Tim Starling 01:26, 30 June 2010 (UTC)[reply]
  • (What to do when things go wrong)
  • Does not go well at all. Also: re-entry on a half-working install is bad. Should be more robust in its checks.
  • This also means NO EXPLODING IF TABLES ALREADY EXIST
  • Tweak installTables() and specifically the createTables() implementations to be more useful. (eg: tables.sql is a failure issue, interwiki.sql is a warning, etc). Do not want to call output directly from InstallDBType children...maybe pass some Statuses back up to the caller?
    Can we consider it done now that interwiki.sql isn't used?
  • UPGRADING doc (others too?) will be wrong and need updating.
  • Allow enabling instant commons if outside access is possible
  • The option Logo URL: shouldn't be hidden under 'enable uploads' (and don't ask the admin to upload a file before installing mediawiki)
  • LocalSettings.php download, non-writeable config directory
My original plan was to offer LocalSettings.php as a download (with Content-Disposition header), so that the user can upload it. Making the config directory writeable is insecure, and having a LocalSettings.php owned by the webserver is also insecure. In theory the administrator should copy from config to the wiki root instead of moving, but in practice most probably don't. Ensuring that all script files are non-writeable by the webserver avoids escalation from arbitrary file write (most likely in another app on the same server) to arbitrary script execution. Currently, LocalSettings.php is the only hole in this policy for a default installation.
Presenting the LocalSettings.php file to the admin as a download and forcing them to upload it ensures that it will have the same ownership and file mode settings as the other files. Also, if there is any unsafe escaping involved in the generation of LocalSettings.php, presenting the file as a download avoids any arbitrary script execution vulnerability, whereas saving it to a web-accessible directory potentially allows immediate exploitation. -- Tim Starling 23:59, 29 June 2010 (UTC)[reply]
  • require_once( './maintenance/updaters.inc' ); // sigh...
  • See r65155. Why is this in the main file? Isn't it only for SQLite? Maybe turn the update functionality into a library. --Ævar Arnfjörð Bjarmason
updaters.inc doesn't work if included from an autoloaded file. The same solution will apply for all other updaters, I just haven't got to it - only SQLite has a functional updater currently. And I intentionally haven't touched the updaters, to avoid extra problems when merging - we could refactor it later. Max Semenik 19:31, 30 April 2010 (UTC)[reply]
Sweet. --20:11, 30 April 2010 (UTC)
I still think we need to do some refactoring now. Grabbing the output from updaters.inc and shoving it to the installer isn't elegant. ^demon 13:59, 4 May 2010 (UTC)[reply]
We're still grabbing input and flushing it to the browser. Sucks marginally less, now :) ^demon 15:41, 8 September 2010 (UTC)[reply]
  • Get someone to fix the error box styling
  • Add FTS3 detection to env checks.
  • (to be clarified by Chad) Reorganize the way made settings are handled. Something about them all being evaluated each page load, making things slow.
  • Makes more sense to me now. We talked about being able to move between steps (not just forward/back, but skipping around). I said the issue with this is that we have to validate settings after each page and this makes that more difficult. Tim said more about it when I tried it before. ^demon
  • Not doing this. Tim has a solid point on validation of stuff and needing to post to-from each page.
  • disable_functions = exec,shell_exec causes warnings, and per this, probably can bring the installer down, need to investigate this.
  • Should be resolved with r74918
  • Return Status objects more often
  • After returning to page=DBConnect with browser back button, everything's unhidden
  • Checkboxes are positioned insanely
  • r75832 broke formatting in help messages
  • Was reverted
  • Lifebuoy's meaning is not culture-independent, better replace it with something like a question mark.
What? Max Semenik 19:31, 30 April 2010 (UTC)[reply]
Isn't it used widely by GNOME for this? Anyway a nice question mark would be nice too. --Ævar Arnfjörð Bjarmason 20:11, 30 April 2010 (UTC)[reply]
  • In case of DB errors, only (SQL query hidden) is displayed.
  • Because $wgShowSQLErrors is false by default. Set to true for install?
  • Did that in rev:64091, probably it's too much and may disclose system information.
  • I don't think it really discloses anything, it's only for the site admin. Removed comment about possible removal of debugging in r78492
  • Better/more JS (Roan)
  • Remove span from 'config-sidebar' message
  • I don't see a span. Maybe you mean config-env-good right below it?
  • config-insecure-secretkey contains wikitext, but doesn't parse it.
  • Fixed at some point.
  • This is not a blocker. Mysql, Postgresql, Sqlite are the only requirements. The rest are a bonus.
  • Oracle works at least :)
All our main DBs have complete support. Individual bugs can be ironed out in CR and bugzilla.
  • Do not place the actions:
    • Restart installation
    • Read me
    • Release notes
    • Copying
    • Upgrading

below the install steps. What about moving them to the left sidebar? Platonides 15:14, 9 June 2010 (UTC)[reply]

Done in r82682. ^demon 17:22, 23 February 2011 (UTC)[reply]

$wgSitename forgotten?

edit
  • Input fields forgotten on re-submit
When you re-submit http://aoeu/config/new-index.php?page=Name (due to
e.g. "The two passwords you entered do not match" error) it'll recall
"Your name" from the previous form, but not "Name of wiki".
--Ævar Arnfjörð Bjarmason
That seems to be on purpose? See WebInstaller_Name::execute():
		if ( $this->getVar( 'wgSitename' ) == $GLOBALS['wgSitename'] ) {
			$this->setVar( 'wgSitename', '' );
		}
I believe it's an earlier attempt for the workaround I did with $wgMetaNamespace in r64448. Need to ask Tim though. In general, having $wgSiteName default to 'Mediawiki' is kind of silly. Almost no one will use it, and something like MyWiki removes the need for workarounds. ^demon 14:59, 6 June 2010 (UTC)[reply]
Is there any reason not to prevent the user from chosing 'Mediawiki' as the old installer does? That way you could change $GLOBALS['wgSitename'] to 'MediaWiki' and $wgSitename would not be "forgotten" when you end up on the form. 70.15.115.142 22:00, 30 January 2011 (UTC)[reply]
Because it will conflict with MediaWiki: namespace. Max Semenik 22:10, 30 January 2011 (UTC)[reply]
Ignorant question: how does preventing the selection of "MediaWiki" as the wgMetaNamespace or wgSiteName conflict with the MediaWiki: namespace? MarkAHershberger 01:07, 31 January 2011 (UTC)[reply]
By default the Project-namespace name is the same as the Wiki's name. eg. like "Wikipedia:" on Wikipedia. So given that the name of the wiki will be used as a namespace name, the name can't be "MediaWiki" since there already is a MediaWiki namespace. I would vote to change the default to "MyWiki" for SiteName, makes perfect sense to me. Krinkle 11:44, 26 February 2011 (UTC)[reply]
MediaWiki is a valid sitename, just not a namespace name. ^demon 13:05, 28 February 2011 (UTC)[reply]

Done in r83398 ^demon 19:54, 6 March 2011 (UTC)[reply]

  • Some help could perhaps be shown by default, like the short ones and the more unclear ones, like "User rights profile"
This was made an info box, always shown.
  • The 'Directory for deleted files' seems a coonfiguration for power users, probably not worth having there.
Removed from installer config
  • CC license picker is buggy (doesn't load image, name of license, etc)
Fixed
  • Consider not embedding the CC license picker, but a list of CC licenses - didn't do this
  • Fail gracefully if the given web account is not able to access the database instead of showing a backtrace when calling User->idForName at line 896 (add a check-privileges step?)
Fixed.
  • By going back, the 'Use same account' as for installation checkbox isn't synchronized with the options visibility.
Fixed.

Postponed items (sometime after 1.17)

edit

Post-install stuff

edit

I (Ævar Arnfjörð Bjarmason) am doing some work on making it pluggable and extensible (to e.g. corporate installs).

  • Make it pluggable

Experimenting with whether it's best to do this with $wgHook or by subclassing the installer for custom tasks. More support in the core for abstraction is needed. Mostly I want to do this by making the code more generic and modular. E.g. turning the $envChecks into classes. And making them return Status objects instead of spewing messages directly.

  • Support post-installation

It would be very cool if we had support for post-installation tasks. E.g. installing extensions & configuring them, installing content packages on the wiki (importing XML dumps) etc. This would need some smart auth support, currently we just recommend deleting config/index.php and refuse to do anything if LocalSettings.php exists.

  • I'm going to add support for importing a dump at the end of the installation process (or post-install). I'd planned on just constructing XML from the current main page i18n messages + Feeding it to the import process. It would allow for installing more stuff, like a basic wiki with Template:* libraries. --Ævar Arnfjörð Bjarmason
  • Short URL GUI

It would be very nice if someone could add in a page to sort out Short URLs for people.. its an annoying thing to do for apache newbies..

Uh? We certainly shouldn't be touching the main httpd.conf, and attempting to create .htaccess could lead to wiki being inaccessible if we use some option not allowed on this particular server. Max Semenik 09:52, 17 July 2010 (UTC)[reply]
Well maybe design something to run a check past the server? MediaWiki can check for the image stuff, but not check for the rewrite module? Wut? --Lcawte 13:34, 18 July 2010 (UTC)[reply]
We can do it in a non-scary way. We can detect the presence of mod_rewrite, and if it's there give a field to configure $wgArticlePath. Along with LocalSettings.php, we could offer them an .htaccess to download if they want (with the caveat of course that servers can differ in configuration, and we're only providing the most common solution) ^demon 15:25, 18 July 2010 (UTC)[reply]
edit
  • Allow uploading of a custom logo
  • Initial path is wrong, points to MediaWiki.org, not http://$localhost
  • Preview of logo

Other

edit
  • Make table of access rights profile for easier overview
  • Do not create the main page, but just display the message in user language on it if it does not yet exist using a hook.
  • Maybe, still needs discussion
  • Fix WebInstallerOutput::flush() (once and for all, see r69360)
Retrieved from "https://www.mediawiki.org/w/index.php?title=New_installer/issues&oldid=6421111"