New-installer issues

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

Already fixed in branch: 198, 2837, 10541, 10596, 11013, 13230, 13409, 16902, 17394, 17691, 17762, 19129, 20627, 21576

Bugs not yet fixed (but could be)

Commits to installer code in trunk

[edit] Outstanding issues

[edit] Critical

• Evaluate restart possibilities for failed install step
• Checkboxes are positioned insanely
• Long single word field labels can run under input fields. Example on page=DBConnect in Dutch 'config-db-prefix' (Databasetabelvoorvoegsel:) like this
• (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

• 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.
• Better/more JS (Roan)
  • Fix non-JS behavior, refactor stuff in <noscript><style> to use hiding by JS
  • After returning to page=DBConnect with browser back button, everything's unhidden

[edit] Features

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.

• 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)

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)

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)

[edit] Non-critical

• Get someone to fix the error box styling
• proprietary DB support, https://bugzilla.wikimedia.org/show_bug.cgi?id=15493

• This is not a blocker. Mysql, Postgresql, Sqlite are the only requirements. The rest are a bonus.

• Review initial main page text

• Text is fine, it just looks like it's in the old installer still. Could some some visual cleanup. For the environment checks, make passed tests obviously good, failed obviously bad.
  • I think it could be made more beautiful and informative. -- Tim Starling
• 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

• Logo stuff:

• Initial path is wrong, points to MediaWiki.org, not http://$localhost
• Allow uploading of a custom logo

• In the installer? Wouldn't it be better to list it in post-install tasks somewhere? --Ævar Arnfjörð Bjarmason

• Preview of logo

• 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.
• Remove span from 'config-sidebar' message

• I don't see a span. Maybe you mean config-env-good right below it?

• 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'
• Make table of access rights profile for easier overview
• CC license picker is buggy (doesn't load image, name of license, etc)
• Consider not embedding the CC license picker, but a list of CC licenses

• We have 2 of the most common ones listed, would like to keep the selector though if we can get it. Also cf bug 17429. ^demon

• Return Status objects more often
• 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)
• 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

• 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.

• 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.
• Some help could perhaps be shown by default, like the short ones and the more unclear ones, like "User rights profile"
• Lifebuoy's meaning is not culture-independent, better replace it with something like a question mark.

• Oh come on, it's a Pango icon! --Ævar Arnfjörð Bjarmason

What? Max Semenik 19:31, 30 April 2010 (UTC)

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)

• 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)

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)

• 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)

• The 'Directory for deleted files' seems a coonfiguration for power users, probably not worth having there.
• If the mysql account is root, the default shouldn't be to use the same account for web access.
• If the given mysql account can't there's a backtrace.
• By going back, the 'Use same account' as for installation checkbox isn't synchronized with the options visibility.
• 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?)
• config-insecure-secretkey contains wikitext, but doesn't parse it.
• 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)

• Can we log in the user account we've just created?

[edit] Fixed issues

• 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?
  • That's not a bug, see Special:Code/MediaWiki/r63389 -- Tim Starling 01:26, 30 June 2010 (UTC)
• 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)
• (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)

• Fix WebInstallerOutput::flush()