Last modified: 2010-05-15 16:03:53 UTC
During wiki installation, the user has to specify an administrative database account for initializing the database. We also ask people to use the latest stable MediaWiki version for new wikis, and to keep up with security updates for current wikis. It would probably also be nice if people could upgrade to the latest major release with the absolute minimum of hassle. One way of making upgrades a bit easier is by saving the administrative database details into config/AdminSettings.php during installation, in the same way that we create config/LocalSettings.php during installation. This is because AdminSettings.php is required for running the maintenance/update.php and maintenance/refreshLinks.php scripts on a version upgrade. However, most people don't find this out at the time of creating their wiki - rather they find it out 3 or 6 months later when they want to upgrade, and by then they can't easily remember the administrative database details, or they can't find them because the dog ate the bit of paper with that information on it. If we saved the details in config/AdminSettings.php during setup, then people could delete that directory and this file if they did not want it, or they could move it into the parent directory along with LocalSettings.php. Alternatively, if there are security concerns about saving the details in AdminSettings.php without the user's explicit say-so, then make it a checkbox during the setup process, so that the user has to opt-in. But anything we can do to make it a little bit easier to set up and upgrade MediaWiki has got to be a good thing, surely?
It may not be a very good idea to just create this on our own. Not every admin will understand that the file was created, and it could perhaps lead to them accidentally leaving a file with their database administration info out in the open. Personally, I don't even have the same user in AdminSettings.php as the user I setup with. I use my own user to setup (creates the databases, and creates users and such), and then create a wikiadmin user who only has access to the wiki database and doesn't have the various grant and create user permissions I have. A better option may be to put a big message on the installation page "Hey, if you want to make updates easier, you should copy AdminSettings.sample into AdminSettings.php and configure it with an administrative user for the database." Or, perhaps a compromise. Instead of doing this by default where it could be a harmfull unexpected action, we could make it a checkbox option. Next to "Use a superuser account" have a checkbox for "Create an AdminSettings.php file with these credentials". That way it's not done unless the user asks for it, but it does make things simpler.
> A better option may be to put a big message on the installation page "Hey, > if you want to make updates easier, you should copy AdminSettings.sample > into AdminSettings.php and configure it with an administrative user for > the database." That would be a slight improvement, but if we can do it for the user, I think we should. However this: > Next to "Use a superuser account" have a checkbox for "Create an > AdminSettings.php file with these credentials". That way it's not done > unless the user asks for it, but it does make things simpler. ... this would be ideal, and should keep everyone happy.
I'm working on this right now. I went the route of making it optional, based on if A) The superuser account is specified and used, and B) You've also elected to created AdminSettings.php. Additionally, I didn't output it directly to the wiki root, but rather to /config, alongside LocalSettings.php.
Bah! I would just do as: http://www.mediawiki.org/wiki/Manual:AdminSettings.php#Merging_with_LocalSettings for them. That way they could use maintenance scripts just fine and need not maintain two files. They could always them separate the two back out later if they are such power users.
Fixed in r52336.
Actually done in r53664.
Reverted in r55612
AdminSettings.php is gone, and $wgDBadminuser and $wgDBadminpassword will just be filled in by $wgDBuser and $wgDBadminpassword, so I'm marking this as fixed. The only remaining problem cases are those where the regular database user doesn't have a necessary privilege, and r56323 should eliminate that problem eventually.
