Last modified: 2011-03-01 18:46:40 UTC
After Installtaion of mediawiki-1.11.0.tar.gz on my PC (XAMP) had no access to MySQL was possible. I have deleted Wiki and XAMP reinstalled.
There is no way that MediaWiki could break your MySQL, due to the nature of installing MediaWiki on your home computer (which I am presuming you did) it is quite possible that in the process of preparing your environment to install MediaWiki you broke something, or tinckering afterwards caused something bad to ocurr. Regardless, it is not MediaWiki.
MediaWiki can create a MySQL user with a different hostname to a pre-existing user, and thereby potentially override the pre-existing user's grants, if the new user is earlier in the hostname search order. The new user may then have a different set of privileges and a different password. I saw a report of this on #mediawiki two days ago -- someone claimed that all the databases except MediaWiki's were dropped by the MediaWiki installer, and that existing web applications stopped working. The problem was the lack of global usage rights for the new user. It would be nice to have some feedback from the reporter as to whether this was possibly the case here, since it is a real problem with the MediaWiki installer and needs to be fixed.
Not a blocker, does not block development. Assuming some easy workaround exists, so this isn't critical, no worse than major.
After installation Wiki has creade a password for my MySQL on my PC. I can't log in and must look in the config to finde this password. I look in my config.inc.php at phpMyAdmin and found the password :-)) But why Wiki don't tell me this during the installation?
I've discovered that the MediaWiki installer is capable of silently changing the password of an existing user account. This will be fixed in the new installer, targeted for 1.15.
Pinging this. New installer is now targeted for 1.17.
This bug is still present in new installer marking as a blocker for 1.17. Reproduction: * Create user foo with some password * Run the installer * On page=DBSettings, uncheck "Use the same account as for installation" * Enter foo as username * Enter a DIFFERENT password for this user * Check "Create the account if it does not already exist" * Finish installation foo's password will be changed.
User creation is done inside maintenance/users.sql using GRANT ALL PRIVILEGES ON $db TO $wgDBuser IDENTIFIED BY $pass; http://dev.mysql.com/doc/refman/5.1/en/grant.html > When the IDENTIFIED BY clause is present and you have global grant privileges, > the password becomes the new password for the account, even if the account > exists and already has a password. With no IDENTIFIED BY clause, the account > password remains unchanged. It should instead use CREATE USER where "An error occurs if the account already exists". http://dev.mysql.com/doc/refman/5.1/en/create-user.html If the CREATE USER for any of the three accounts already exist, it should abort. It could still mask a user with the same name but different host, but manually performing queries to mysql.user doesn't look nice (we should at least skip any error on doing so).
Created attachment 8209 [details] Fix for password overwrite in GRANT Separates the CREATE and GRANT stages so we can handle them separately (and not overwrite the password silently). Attempts to check mysql.user if we can, but creates anyway if we can't verify.
I would perform the grant directly from there, too. users.sql duplicates information that is now copied into MysqlInstaller.php so I would get rid of the sql file. If the mysql.user found it existed or the create user failed with whatever error code there is for already exist, it should show "User $1 already exists" (informative), not 'Creating user "$1" failed: $2'. Wrap everything in a transaction.
Created attachment 8223 [details] Try #2 Applies changes from previous comment.
Looks good. What should we do when there is just one of the accounts? Should we proceed to create the other two?
I figured just to continue and try to make all 3, but it can go either way.
Fixed in r83029.
