Last modified: 2010-05-15 16:03:12 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 14203 - Automated command-line installation of MediaWiki
Automated command-line installation of MediaWiki
Status: RESOLVED DUPLICATE of bug 10542
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.13.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-21 02:57 UTC by Nick Jenkins
Modified: 2010-05-15 16:03 UTC (History)
5 users (show)

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


Attachments

Description Nick Jenkins 2008-05-21 02:57:46 UTC
Currently to install MediaWiki, you download and extract it, point your web browser at config/index.php , manually enter some configuration values (e.g. the wiki name / language / database name / etc) for that wiki into a web form in your browser, then click a button, and then installation stuff happens, and yay, you've got yourself a wiki.

Now, this approach works great if you want to set up _one_ wiki... But suppose you want to create hundreds or thousands of wikis. There are real-world reasons to want this:
* You want to test a huge number of combinations of something.
* You want to give everyone in a large group of people their own separate wiki to play with, experiment with, learn with, and store information that's personally relevant to them. (Why shouldn't everyone on the planet have their own wiki if they want one?)
* You have many branches or outlets of an organisation, who want to keep some information separate.

Currently, we don't see the above applications - but that's because to create 1000 wikis, you'd have to manually enter information 1000 times, which of course no sysadmin in-their-right-mind wants to do, so it just doesn't happen.

So what I am proposing is a way of installing MediaWiki from the command-line, using some sort of configuration file. This configuration file should ideally allow the same information as is entered manually in config/index.php. However it doesn't matter what the format of the configuration file is (as long as a human can read it and edit it and understand it), and it doesn't matter whether the command-line installation script lives in config/ or in maintenance/, or is part of config/index.php or is separate. As long it can be scripted from the command line, it's all good :-)
Comment 1 Daniel Friesen 2008-05-21 04:16:02 UTC
No sane sysadmin would go an install 1000 wiki each with their own full LocalSettings.php file.
And those applications are in use, they are called Wiki Farms, take Wikimedia, Wikia, a number of other wiki hosts, even I run a wiki farm.

But creation of wiki on a Wiki farm is completely out of the scope of MediaWiki core. Management of multiple wiki is something that a single installation cannot be made to handle, that kind of thing is something that must be handled as something wrapped around the MediaWiki installation. Be it use of a GlobalSettings.php file, domain checking to tweak configuration per-site, or use of a WikiFactory extension like Wikia's.

A wiki installation script may be an interesting addition, but not for the reasons you've outlined. That script to should only be used for installing a single wiki. A sysadmin would have to be pretty foolish to use that kind of thing to setup hundreds of wiki instead of doing it the proper way and creating a custom set of configuration where all they need is a minimal set of new data to configure a new wiki because all the common stuff is put in a central location.

Now, for the sane people who know that all you need to setup a second wiki installation is a little minor tweak to configuration and a new database, I already have a StarterWiki extension which works similarly to Wikia's starter wiki, where you install it on one wiki, and you can run a maintenance script to use that wiki as a base for a brand new wiki.

Unfortunately I don't have documentation up yet, but if I ever do get to it, it will be located at:
http://wiki-tools.com/wiki/StarterWiki

For now all you need is to look at my SVN repo:
http://svn.nadir-point.com/viewvc/mediawiki-extensions/branches/stable/StarterWiki/

And handily enough, I customized a ViewVC template so it'll even give you the SVN command you need to checkout the folder you are in. And tarball snapshot downloads are supported to.

Or if you just want to checkout my entire set of extensions in a location that won't collide with Wikimedia's extensions:
svn checkout svn://svn.nadir-point.com/mediawiki-extensions/branches/stable/ extensions/wiki-tools/

I also do have a bash script I use for the linking, setup, and also initial setup of extensions which have database additions, but that's a little less generic. Plus my setup uses symlinks in a way tailored to my situation, it's best for farms to use the domain checking method instead. I actually have a trick meant for the ShoutWiki project, but it's a little complex to be of use.
Comment 2 Nick Jenkins 2008-05-21 08:22:39 UTC
> own full LocalSettings.php file.

How LocalSettings.php is structured is not relevant to what is being requested. I never mentioned it. Of course duplication of configuration data should be avoided, but this is the sysadmin's problem, not the installers, so it is irrelevant here.

> And those applications are in use

That's like saying the head of IBM saying "the world only needs 5 computers". Pointing to a handful of vaguely similar things that exist and saying "see, we've got that covered" - it misses the potential for things that you have not envisaged.

> they are called Wiki Farms

A wiki farm implies multiple machines, yes? Well, I don't want that. I want one machine, with many wikis.

> But creation of wiki on a Wiki farm is completely out of the scope

I don't want a wiki farm. I want an automated command line installation of a single wiki. I want the installer to do only what it already does, but from the command line.

> Management of multiple wiki is something that a single installation cannot be made to handle

I don't want the installation to manage multiple wikis. I want it to install without requiring manual input. 

> all you need to setup a second wiki installation is a little
> minor tweak to configuration and a new database,

Exactly. On this we completely agree! And **creating a new database is the installer's job**. That and checking the environment, and writing a basic LocalSettings.php - those are the reasons why we have an installer. Doing the installer's job using a undocumented custom extension that is out of core does not seem prudent to me. I want the installer to do the installer's job, but from the command line.

I certainly thank you for the links, and will look over those, but it does not solve the request. I did not think this would be contentious - just about every Linux package can be installed from the command line, and many Windows MSIs can too - so I fail to see why command-line installation of MediaWiki is so completely different.
Comment 3 Roan Kattouw 2008-05-21 12:09:40 UTC
(In reply to comment #2)
> > own full LocalSettings.php file.
> 
> How LocalSettings.php is structured is not relevant to what is being requested.
> I never mentioned it. Of course duplication of configuration data should be
> avoided, but this is the sysadmin's problem, not the installers, so it is
> irrelevant here.
It's not irrelevant. Adding a few lines to detect which wiki you're on in LocalSettings.php is way easier and faster than running a script 1000 times and having 1000 LocalSettings.php files lying around/

> > they are called Wiki Farms
> 
> A wiki farm implies multiple machines, yes? Well, I don't want that. I want one
> machine, with many wikis.
No, it doesn't wiki farms can also be run on one machine. In fact, I'm a sysop of a wiki that runs six other wikis on the same server using subdomains.

> > But creation of wiki on a Wiki farm is completely out of the scope
> 
> I don't want a wiki farm. I want an automated command line installation of a
> single wiki. I want the installer to do only what it already does, but from the
> command line.
You may *want* that, but what we're trying to tell you here is that there's a better way to accomplish your goal. A command-line installation would be a nice feature, but it wouldn't be the best solution to your problem (creating lots of wikis).

> I certainly thank you for the links, and will look over those, but it does not
> solve the request. I did not think this would be contentious - just about every
> Linux package can be installed from the command line, and many Windows MSIs can
> too - so I fail to see why command-line installation of MediaWiki is so
> completely different.
>
Now *that* is a good reason to have a command-line installer. It'd greatly simplify installing MediaWiki from e.g. a .deb package or a Windows MSI. In fact, it'll allow distributors to build their own frontend to our installer.

All in all, no one's saying we shouldn't have a command-line installer (we should), but simply that it's not needed for wiki farms.
Comment 4 Daniel Friesen 2008-05-21 18:14:57 UTC
(In reply to comment #2)
> > all you need to setup a second wiki installation is a little
> > minor tweak to configuration and a new database,
> 
> Exactly. On this we completely agree! And **creating a new database is the
> installer's job**. That and checking the environment, and writing a basic
> LocalSettings.php - those are the reasons why we have an installer. Doing the
> installer's job using a undocumented custom extension that is out of core does
> not seem prudent to me. I want the installer to do the installer's job, but
> from the command line.

It won't be undocumented, and it's perfectly usable without it. Setup a wiki, install the extension, run the maintenance script when you need a new database.

But it's out of core because this is not core's job. Handling cross-wiki stuff is not something within the scope of MediaWiki core, that is something meant for extensions and wrappers around MediaWiki to handle, which is what that extension is in combination with your own preferred method of sharing configuration is.

Also there is this extension to think about: http://www.mediawiki.org/wiki/Extension:Farmer
Comment 5 Christian Neubauer 2008-05-23 14:00:39 UTC
> (In reply to comment #2)
> You may *want* that, but what we're trying to tell you here is that there's a
> better way to accomplish your goal. A command-line installation would be a nice
> feature, but it wouldn't be the best solution to your problem (creating lots of
> wikis).

This requirement has merit regardless of this wiki farm issue.  Anyway, you don't know anything about his environment.  Maybe his machines/devices exist on disconnected or semi-connected networks or something and can't be managed by a wiki farm.  Maybe he has to create 1000 different wikis.  Regardless of all that, he's just asking for a simple way to create a LocalSettings file without going through a web interface.  What's so problematic about that?
Comment 6 Roan Kattouw 2008-05-23 17:27:21 UTC
(In reply to comment #5)
> This requirement has merit regardless of this wiki farm issue.  Anyway, you
> don't know anything about his environment.  Maybe his machines/devices exist on
> disconnected or semi-connected networks or something and can't be managed by a
> wiki farm.  Maybe he has to create 1000 different wikis.  Regardless of all
> that, he's just asking for a simple way to create a LocalSettings file without
> going through a web interface.  What's so problematic about that?
> 

Nothing is. Read the end of my comment #3.
Comment 7 Chad H. 2009-07-13 19:01:16 UTC

*** This bug has been marked as a duplicate of bug 10542 ***

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


Navigation
Links