Last modified: 2011-10-12 01:16:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2921, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 921 - Install script always attempts to connect to database as root
Install script always attempts to connect to database as root
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
All All
: High major with 1 vote (vote)
: ---
Assigned To: Rob Church
: 1195 3914 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-11-20 17:56 UTC by Florian Effenberger
Modified: 2011-10-12 01:16 UTC (History)
5 users (show)

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


Description Florian Effenberger 2004-11-20 17:56:19 UTC
When trying to install MediaWiki 1.3.8 (sorry, only version 1.3.7 was available
as BugZilla field), it always tries to connect as root to my MySQL database:

    * PHP 4.3.9: ok
    * PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
    * Have XML / Latin1-UTF-8 conversion support.
    * PHP's memory_limit is 8M. If this is too low, installation may fail!
Attempting to raise limit to 20M... ok.
    * Have zlib support; enabling output compression.
    * Found GD graphics library built-in, image thumbnailing will be enabled if
you enable uploads.
    * Installation directory: /usr/local/apache2/htdocs/wiki
    * Script URI path: /wiki
    * MySQL error 1045: Keine Zugriffsberechtigung f�r Benutzer:
'root@localhost'. (Verwendetes Passwort: Nein)
    * Trying regular user... need password.

Something's not quite right yet; make sure everything below is filled out correctly.

When entering the correct root password (although the database already exists),
I receive "MySQL error 0". I can connect with both the wiki and the root user to
MySQL using the normal MySQL client without any problems.
Comment 1 Brion Vibber 2004-12-25 01:34:33 UTC
*** Bug 1195 has been marked as a duplicate of this bug. ***
Comment 2 Xavier Perseguers 2005-01-19 08:43:42 UTC
I had same bug yesterday with a friend not having root access to mysql. However
he had a well configured database with his username+password.

I was able to install latest version (beta something) after having

- modified config script to login as his db-username
- entered his password as "root" password in the login form
- AND... having modified the management/users something script to remove all
GRANT queries (I replaced them with a dumb select query to get no error code,
however this might be useless)
Comment 3 Florian Effenberger 2005-01-19 20:49:59 UTC
That sounds interesting! Could you please e-mail me your modified scripts and
tell me the version of MediaWiki you used, so I can test it?
Comment 4 Asheesh Laroia 2005-05-31 17:56:20 UTC
I ran into the same problem.

I wrote on IRC before seeing this bug report: "I seem to exhibit a MediaWiki
database logic bug on my setup.  Our db server is einstein; our web server is
centaur.  There is MySQL account called 'root' with no password that MediaWiki
authenticates as.  But "root" with no password has nearly no privileges; so MW
complains, "Can't create database" because it's trying to do things as the lame
root user."

 * The file causing the problems is config/index.php; this bug is in both MW
1.4.4 and 1.5rc1.
 * The user and database existed before I hit 'submit'.

 * I worked around it by doing this to config/index.php in MW 1.4.4:

<               $wgDatabase = Database::newFromParams( $wgDBserver, "root",
$conf->RootPW, "", 1 );
>               $wgDatabase = Database::newFromParams( $wgDBserver, $wgDBuser,
$wgDBpassword, "", 1 );
Comment 5 Y Chang 2005-08-07 12:06:58 UTC
Couldn't create database wikidb; try with root access or check your 
Something's not quite right yet; make sure everything below is filled out 

* I have created a new database (manually) called wikidb. I have also created 
a new mysql user/pass, which MW has verified to work to reach the step above. 
* I do not have root access, thus I have tried Asheesh Laroia's fix of 
changing "root" to $wgDBuser (etc) 
* The same error msg still occurs. 
Comment 6 Jouko 2005-09-05 05:16:38 UTC
Same here, I also try replace all root username and passwords but only managed
to do partial installation, some data like usernames and user rights still
missing. I wonder if there is an sql file that I could put trough mysql admin to
generate tables and data.
Comment 7 Rob Church 2005-10-09 16:46:15 UTC
The reason for this is that at the bottom of the install form, the option for
users to enter their root password is provided; this is so you can get the
installer to set up your database and database user for you. Not providing the
password will cause the root connection attempt to fail, at which point, the
installer will usually find it can use your specified user.

Just to point out; root is attempted first, because if the user does want the
installer to set up the user for it, then that user is presumed not to exist.
I'm thinking perhaps we could offer the user the option to have all this created
for them; the install form is not 100% clear on this.

Marking this as INVALID, as it's expected behaviour.
Comment 8 Rob Church 2005-10-09 16:47:43 UTC
And just to confirm the obvious; yes, if you tell the installer to set up your
user and database for you, then MediaWiki is configured to use that new user,
not root.
Comment 9 PS 2005-10-09 19:47:23 UTC
The issue here is, if it is an existing MySQL implementation (which 
is quite common) a good administrator may have deleted the root 
account, giving root permission and control to some other account 
name with a less obvious means of guesswork or attack.

The problem is that Mediawiki at the time of this report, looks for 
an account named "root" on MySQL which it will use during 
installation to create and populate the various data tables, but it 
assumes "root" exists and is the superuser name on MySQL to do this, 
asking only the PW for "root". It may not be..... even on amateur 
MySQL setups the administrator may have changed and deleted the 
"root" name for superuser access long ago.
Comment 10 Rob Church 2005-10-09 19:52:43 UTC
A good point, but in that case, you would end up using the user created for that
purpose anyway.
Comment 11 PS 2005-10-09 20:07:58 UTC
But you wouldn't. Say you install MySQL and make the superuser 
"abc123XnYZ" for security, deleting or disabling the account named 
"root" afterwards. You still would not run mediawiki under that user 
"abc123XnYZ", because that user has superuser access. You would want 
mediawiki to log in as that user on installation only, as usual... 
to create its tables, and to create a "safe" user as normal. 

ie, the fact you have changed the superuser name does NOT mean you 
want to run public facing software as that user....
Comment 12 Rob Church 2005-10-09 20:08:50 UTC
Sorry, I meant the user created for the purpose of running the software. Didn't
make that clear.
Comment 13 PS 2005-10-09 20:18:07 UTC
(np, it was clear from the context but thanks anyhow. Above reply 
Comment 14 PS 2005-10-09 20:22:25 UTC
The core problem is, Mediawiki needs one time access to the 
superuser account. And it assumes that superuser is always, and 
would always, be called "root" (no matter the name of the user you 
are creating to ultimately run mediawiki). And that superuser will 
not always be called "root". 

Especially on a long standing system or a well configured one, or 
one with a good sysadmin managing it, that assumption should not be 
made as it will more than likely be wrong on a significant number of 
systems, which will result in mediawiki auto-insisting on trying to 
install itself by means of an account that either does not exist, or 
does not have authority in MySQL.

Now is it more clear, why mediawiki needs to ask not just the root 
password, but the appropriate root account name?
Comment 15 Rob Church 2005-10-09 20:25:37 UTC
MediaWiki does *not* need access to the root account if you have the other
account already created. On a well configured system, that is how you'd do it,
is it not?

I agree, however, that if it is going to use the root account, then it might be
an idea to allow the name to be changed.
Comment 16 PS 2005-10-09 20:44:39 UTC
Agreed, one of those two. 

Either way the install must visibly be able to handle (and make 
clear what to do) the consequences if the MySQL privileged account 
that has authority to set up the necessary data is not called 

If the answer is that it doesn't need root access at all, then it 
shouldn't say it needs the root password, and should make clear what 
it does need. 

If it does need some kind of privileged account to create users and 
such, it must ask its name during setup. 

If it can avoid the use of a privileged account but this would 
complicate installation for newcomers, then it should make life 
easier for them and ask for a privileged account name anyhow, for 
simplicity (as this is a minimal change to the code and would solve 
it 100%).

The answer (#15) that if your superuser account isn't called root 
you can skip it if the other account is set up already, falters for 
me, because it requires users to manually and correctly do stuff in 
MySQL in order to install Mediawiki. That's going to put off a lot 
more people than asking for the account name as well as its 
password. Its also unnecessary as the entire code to do this is 
already there, just needing a single text string "root" to be 
replaced by a variable.

Personally I feel that the simplst, most elegant way is simply:

"To install mediawiki the software needs one-time access to a 
privileged MySQL account to define users tables and privileges, such 
as 'root'. Please give the name [default = root] and password for a 
suitable account that can be used for this purpose."

Then ask for a user and password, not just a password. 

And test the account first to ensure it does have the privileges 
needed to run the install, so you don't get a cascade of less 
obvious secondary error messages if not.
Comment 17 Rob Church 2005-10-10 00:19:57 UTC
My feeling would be that we shouldn't be asking for the root password. If users
can't create accounts in mySQL, I'm not comfortable with them installing MediaWiki.

We should make it so that the user has to have already set up an account with
only the required permissions, and knows which permissions can be taken away
after - such as CREATE (we don't need to re-create the tables once defined, do we?)
Comment 18 PS 2005-10-10 00:42:47 UTC
I understand but I would none the less be inclined to still  
disagree, on two counts.

First, that installing mediawiki is a local once-off process. My 
understanding is that the root password is not being saved or reused 
beyond this one time. If instead it was constantly saving or using 
it, I would have far more grave concerns as you say.

Second, that Mediawiki is presently very accessible. Changing root 
ID on MySQL is easy. So novices at MySQL can do it. Now, if you are 
going to take away how Mediawiki automatically sets itself up, and 
demand the user has already created an account with the right 
privileges, all you are doing is essentially asking them to do 
manually a process that can be (and presently is) automated.  I 
don't see the gain to the user in terms of security or ease of doing 
so, or the gain to mediawiki in terms of accessibility, in fact much 
the reverse. 

It now would demand every user instead of entering an account and 
password and having the software take the few steps needed 
automatically and correctly, they must do precisely the same, create 
an account if it doesnt exist, and enter it and its password, and 
cut/paste some SQL code into the SQL command line, for precisely the 
same effect. I do find it quite hard to see how enforcing that 
change of process has helped the wiki manager in any everyday sense.
Comment 19 Rob Church 2005-10-10 08:13:40 UTC
Well in that case, we need to have it so that the installer asks for the root
username and password as a clear alternative to a specific account.  Perhaps,
under the specific account details, we could have a checkbox - "Create this
account" - which enables the form fields for the root username and root password.
Comment 20 PS 2005-10-10 11:01:26 UTC
So in essence, if the running acount does not exist, the Mediawiki 
software needs to temporary use a privileged account for 
installation (ie, get a suitable name and password for a privileged 
account for installation purposes), and ask for a suitable user 
account for general running use.

Or put asnother way, the software cannot create an account, from 
nothing, with the privileges needed. *Either* the user installing 
Mediawiki will have to give it a privileged account name + password 
to use to create a suitable user account, *or* the user must give it 
a pre-created user account to run under that has already been 
manually defined correctly (in which case the creation of such an 
account can obviously be skipped). 

I don't see the latter being a common scenario to handle given we 
are talking about an initial install process.

Isn't that basically where we're at anyway, except that it has to 
ask for the privileged account's name as well rather than assume the 
name is "root" and asking only its password?
Comment 21 Rob Church 2005-10-10 13:59:29 UTC
Yes, I was just musing over how to explain it to the end user.
Comment 22 PS 2005-10-10 17:03:03 UTC
"To install mediawiki, the install process must configure itself in 
MySQL. This is an automatic process, requiring brief access to a 
privileged MySQL adminstrator's account this one time. As part of 
the install Mediawiki creates a normal (non privileged) MySQL 
account which it will use when running the actual wiki.

Please enter the name (usually 'root') and password for a privileged 
account that can be used briefly to install Mediawiki (this will not 
be saved, it is needed this one time only and then forgotten), and 
the name and desired password that the Mediawiki software should  
create for everyday use once it is correctly installed and working. 
[click here for how Mediawiki uses the root account during install]"
Comment 23 PS 2005-10-10 17:06:25 UTC
If you include a radio button:

"yes, please use the following privileged account to create a 
mediawiki user"
"the Mediawiki user account below already exists so privileged 
access is not needed"

Warnings given if 1) privileged account selected but lacks necessary 
MySQL root authorities, or 2) user account said to already exist but 
does not, or lacks necessary MySQL user authorities
Comment 24 Rob Church 2005-10-10 17:50:41 UTC
Simpler option:

Please enter the mySQL account to be used by MediaWiki:

Username: __________
Password: __________

[X] MediaWiki should create this account

If the box is checked, a section of the installer (preferably below the prompt
I've outlined above) is enabled and required:

Please enter the credentials to a local superuser account to be used for this

Username: root_________ (defaults to root, anyway)
Password: _____________

>>Click here for more information on how MediaWiki uses this account<<

Something like that, perhaps?
Comment 25 PS 2005-10-11 02:53:35 UTC
That works. Same basic idea, less verbage.
Comment 26 PS 2005-10-11 02:55:36 UTC
Don't forget,  either the account (if it exists) or the superuser 
account (if given) will have to be checked briefly during the first 
stage of install, to ensure they exist and have whatever authorities 
they respectively need, whichever way it goes.
Comment 27 PS 2005-10-11 02:58:42 UTC
One edit briefly (sorry!)
I'd make extremely clear what each is used for:

Please enter the mySQL user account name to be used when running 

Username: __________
Password: __________

[X] MediaWiki should create this account during installation
Comment 28 PS 2005-10-11 03:01:05 UTC
Last potential hiccup - ensure that *blank* passwords are accepted

(some other MySQL installations might be configured so that root can 
only log in from one, or a few, specified machines, and therefore a 
password is not used to do so)
Comment 29 Rob Church 2005-12-15 17:58:20 UTC
*** Bug 3914 has been marked as a duplicate of this bug. ***
Comment 30 Jason Harrison 2005-12-15 18:02:57 UTC
I reported the above bug 3914 and still not getting it to install.  My launch
was supposed to be 15 days ago with this project, i'd like to get it going if
there is a viable workaround.  Its starting to stress me out as my users are
constantly asking me when it is going to be installed and I can't find the time
to tinker under the hood right now.  Please view the 3914 if you have any
solutions, as i might of tried them.  thank you.

Comment 31 jacki buros 2006-01-04 05:00:44 UTC
It's worth noting that on some hosted MySQL servers (XO, UNIX w/apache, MySQL4.0, 
MW1.5.4) the mere attempt to access the db as 'root' gives an error message:

  Trying to connect to MySQL on ###.###.###.### as root... 
  MySQL error 1105: No '@' was found in user string (root) Disconnecting

modifying the code in config/index.php to replace 'root' with the name of a 
DBuser having grant/create/etc privilege caused a different error (to paraphrase, 
it stated that 'root' didn't have access to 'wikidb'), but when i reloaded the 
page i got a 'MediaWiki already exists checking if updates needed' output that 
completed the installation successfully. Hope this helps.
Comment 32 Jason Harrison 2006-01-04 05:27:49 UTC
I got the email notification up above and eagerly tried to install the latest
flavor again, but I got the same freakin' error again.  I would pay someone at
this point to help me getting this up and running.  It's been over a month and a
half and my users have lost faith in me.  I'm still sold on Mediawiki, however
it's looking slim so I might have to find something else that I can work with. 

# Trying to connect to MySQL on localhost as root...

    * Connected as root (automatic)

# Connected to 4.0.16-xxxxxxxxxxx; enabling MySQL 4 enhancements

    * Error selecting database xxxxxxxxxxxxx: 1044 Access denied for user: '@%'
to database 'xxxxxxxxxxxxx'
Comment 33 Sean Gabriel Heacock 2006-01-05 04:55:51 UTC
I've encountered something that seems to be related to the issues described in
the comments for this bug.

I installed the latest version (1.5.4) for one of my users.  I created his
database beforehand, and provided the configuration page with the proper
hostname, user, database, and password.  I left the root password entry blank,
since I already set that stuff up.

It gave me a mysql connection error, saying it couldn't connect as root - even
though it shouldn't have had to.  Fine, being as how MediaWiki is such a
well-known package, I felt reasonable comfortable giving it the root mysql
password.  I assumed it would discover that the database was already set up, and
move on to creating the tables - which it did; however, it also added two new
entries to the mysql.user table, for user "root" with hostnames "%" and
"localhost.localdomain", and no privileges.

This is a MAJOR, HUGE, GINORMOUS problem.  Why did it do this?  I'm beyond
pissed about this.  Fortunately I was still able to connect through localhost
and fix what MediaWiki screwed up.  Why is MediaWiki taking it upon itself to do
ANYTHING to the root mysql user?  Why does it error out when the root password
is not supplied, when the configured database and mysql user ALREADY EXIST?
Comment 34 Rob Church 2006-01-05 07:21:56 UTC
(In reply to comment #33)
You're damn right MediaWiki shouldn't be doing that, but I don't think it is -
I'm no expert with the innards of mySQL, but it sounds very much like something
mySQL itself is doing.

Regardless, this issue is now starting to affect a lot of users. I think I'll do
a partial rewrite of the affected portion of the installer script.
Comment 35 Brion Vibber 2006-01-05 13:07:21 UTC
Your MySQL is apparently misconfigured so that a root login with no password 
*SUCCEEDS*, but then can't do anything. You should see about fixing this -- it 
causes the installer's initial check to fail incorrectly.

If you want the installer to connect as root with a password, so it can create the 
database and set up the db user for MediaWiki, then you should give it *just* the 
root password in the root password field.

It sounds like you told the installer to create a mysql user "root" for MediaWiki 
to run under as well. You probably shouldn't do that; give it the account that you 
want to run MediaWiki under instead.
Comment 36 Jason Harrison 2006-01-05 23:34:24 UTC
Is there any possible workaround just so I can get the thing up and running? or
am I still S.O.L. as I have been since November?
Comment 37 Rob Church 2006-01-05 23:58:55 UTC
Try bug 1044 comment 10.
Comment 38 Jason Harrison 2006-01-06 04:00:47 UTC
(In reply to comment #37)
> Try bug 1044 comment 10.

I only see 1 comment there, are you sure that's the right one?
Comment 39 Rob Church 2006-01-06 12:30:55 UTC
I meant bug 3914 comment 10. Sorry, I was reading the "error number" out of the
bug summary, not the bug number.
Comment 40 Rob Church 2006-01-14 01:43:51 UTC
This should now be fixed in CVS HEAD with the code I'm committing this second.
The installer now:

[a] attempts to connect first as the specified user
[b] ...and then as root
[c] ...and then cries

Basically, an ugly hack in the middle is now a bit cleaner. I'll backport it to
1.5 branch as soon as I know it isn't going to interfere there.
Comment 41 Jason Harrison 2006-01-17 02:46:48 UTC
is this CVS HEAD thing in the newest flavor of mediawiki?  I'm still not getting
it to install... it's been 20 months now

thanks (i hope)
Comment 42 Rob Church 2006-01-17 18:06:59 UTC
CVS HEAD is the latest code in CVS, which runs Wikimedia wikis. It's not used
for the releases at the moment. I've since backported similar (though slightly
different, due to the way MediaWiki 1.5 supports databases) changes to the
installer in REL_1_5. This installer will work against existing versions of
MediaWiki within the 1.5 branch, and will also be shipped with MediaWiki 1.5.6.

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