Last modified: 2010-05-15 15:37:57 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 T5914, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3914 - Install error: 1044 Access denied for user
Install error: 1044 Access denied for user
Status: RESOLVED DUPLICATE of bug 921
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.5.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-09 23:23 UTC by Jason Harrison
Modified: 2010-05-15 15:37 UTC (History)
0 users

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


Attachments

Description Jason Harrison 2005-11-09 23:23:07 UTC
Here's my error message I keep getting.  My ISP says it's an error on the
softwares' side, I called BS but who are they to listen to reason?

The username is not '@%' as shown below, BTW.



    * PHP 4.3.6: ok
    * Warning: PHP's register_globals option is enabled. MediaWiki will work
correctly, but this setting increases your exposure to potential security
vulnerabilities in PHP-based software running on your server. You should disable
it if you are able.
    * 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.
    * Neither Turck MMCache nor eAccelerator are installed, can't use object
caching functions
    * GNU diff3 not found.
    * Found ImageMagick: /usr/local/bin/convert; image thumbnailing will be
enabled if you enable uploads.
    * Found GD graphics library built-in.
    * Installation directory: /usr/local/psa/home/vhosts/sleestak.net/httpdocs/wiki
    * Script URI path: /wiki
    * PHP is linked with old MySQL client libraries. If you are using a MySQL
4.1 server and have problems connecting to the database, see
http://dev.mysql.com/doc/mysql/en/old-client.html for help.
    * Trying to connect to MySQL on localhost as root...
          o Connected as root (automatic)
    * Connected to 4.0.16-globat; enabling MySQL 4 enhancements
          o Error selecting database sleestak_wiki: 1044 Access denied for user:
'@%' to database 'sleestak_wiki'
Comment 1 Rob Church 2005-11-10 12:33:40 UTC
The error text clearly states what the issue is. You're likely using a newer
mySQL version with an older version of PHP. So it's a server-side issue. There
are workarounds, such as setting the password to be in the "old" form, but at
the end of the day, it's probably better to get the client libraries PHP is
using updated.
Comment 2 Jason Harrison 2005-11-11 01:45:24 UTC
My Host still blames the software for the problem, Rob.  I appreciate any more
help as i've been trying to get this damn thing up and running for over 3 weeks
and my users are getting restless in order unleash the power of wiki! - jason

"Dear Valued Customer,

That doesn't change what I've said. You do not have root access to the database.
If we're going to get into what the software is "clearly saying" then please see
that the software clearly says that it is trying to access the database as root.
You do not have root access to the database. If you try to access the database
as root, you will not gain entry. The software is reporting that it tried
accessing the database as root and was unsuccessful.

Please give them this information. I see from the support article that all you
told them was that your ISP says it's on the software side and that you didn't
give them any more information than that. If tell them what I'm telling you,
they'll be able to help you correctly configure this software. I'm sure that
they're assuming when they wrote that reply that you should have root access to
the database.

Also, if you come to them from the angle that "I called BS but who are they to
listen to reason?" then they're likely to just assume that your ISP is being
unreasonable and not give much merit to the problem.

Nobody on this end is trying to "BS" you, and it's pretty insulting to see that
said, especially since the information I gave you is accurate but was
disregarded. We've given you the information that you need to see this problem
resolved.

Thank you for contacting our technical support. If you have any further
questions, please reply to this email leaving all text intact, and be sure to
give us a detailed description of how we can further assist you. 
 
Best regards, 
 
Johnny
Globat Signature Support - Tier 2 
Web Hosting Made Easy® 
support@globat.com 
http://www.Globat.com/

How well did we do at responding to your request? Please let us know at this link: 
http://www.zoomerang.com/survey.zgi?RYT27QJ83RVVPB7LQ1G60P33   

On Thu, 10 Nov 2005 07:54:31 -0800, bobcat@sleestak.net wrote:

>> Here's my answer from the developers:
>> 
>> http://bugzilla.wikimedia.org/show_bug.cgi?id=3914"
Comment 3 Brion Vibber 2005-11-11 02:31:24 UTC
It looks like their server is misconfigured with a bogus 'root' user, which allows 
logins but then doesn't let you do anything. If the root login had *failed*, then the 
system would continue on to use the specific account you gave it.

(MediaWiki is designed primarily for systems operated by the wiki operator, and will 
try to log in as root and *create* the user you specify. If the root login fails, it 
assumes you're on some limited account and hopes the account already exists.)

If they can't fix their broken root login, you'll need to poke around in config/
index.php and disable that bit.
Comment 4 Rob Church 2005-11-11 07:49:00 UTC
If you've been leaving the root password box blank, as expected, it might be
worth a try just to shove some utter crap in there and hope it's rejected by the
mySQL server. MediaWiki's installer is, as Brion said, designed to be run by the
operator themself in about nine tenths of cases. However, it will attempt to use
the other user account information provided if root access is denied.

Your web host is misinterpreting how the software works, although to be fair, if
their server is allowing MediaWiki to think it can connect as root, it won't
display a problem until it finds root can't *do* anything; but it won't then
attempt to use the limited account credentials you supplied previously. Perhaps
it's worth us tweaking this bit in the installer...?
Comment 5 Jason Harrison 2005-11-11 08:59:41 UTC
Thanks Rob and Brion for the advice, I went into config/index.php and tried to
enter some utter crap to no avail.  Also cut out the database check routine...
no dice.

I might be so bold to say that maybe this does happen more often with users
attempting to install on an ISP's server rather than their own.  It just happens
that I see to always find a way to break things (damn testing background) and
I'm pretty vocal about even the most minor details.

If there's any other workarounds, I'm all ears.  Textpad is open willing and
ready.  -Jason   
Comment 6 Jason Harrison 2005-11-17 19:22:30 UTC
I reopened this bug as I don't believe it is 'invalid' and it is definately not
'fixed' either.  The program still will not install and I am sure there has got
to be an easy workaround.

It's a week later and i'm still hoping to get this launched on the 1st for my
users like I promised.  I have been hyping up wiki for a while and it would
really really stink to have it all backfire on me.  

Like I said, i'm not too good with SQL / PHP, I can edit stuff and replace so
any help would be really really helpful so I don't have to eat crow!

-jason
bobcat@sleestak.net
Comment 7 Rob Church 2005-11-20 00:43:42 UTC
As a bug, which affects all our users, it's invalid, because it only basically
affects you. Brion also told you what you need to do - modify the bit of
config/index.php which uses root if it can. I might post details on how to do
this shortly.
Comment 8 Brion Vibber 2005-11-20 00:47:22 UTC
Rob, it is a general problem in that a number of people have encountered this. 
I believe there's another bug report open for making the attempted 'root' 
username selectable in the installer interface (possibly with a patch, but if 
so it might be out of date).
Comment 9 Rob Church 2005-11-20 00:49:03 UTC
I'll poke about and see if I can come up with a patch for it.
Comment 10 Rob Church 2005-11-20 01:16:04 UTC
Workaround:

1. Edit config/index.php
2. Comment out lines 502-509 and lines 511-523 inclusive.
3. Save, upload
4. Re-run the installer

Note: Haven't tested these modifications, but those appear to be the lines which
do the root stuff. With luck, this should sort you.
Comment 11 Rob Church 2005-12-15 17:58:19 UTC

*** This bug has been marked as a duplicate of 921 ***
Comment 12 Jason Harrison 2005-12-15 18:28:35 UTC
Rob that workaround never did anything.  I have been waiting for an update
patiently of sorts over the last month, but nothing has surfaced.. please help!
Comment 13 Rob Church 2005-12-15 18:34:24 UTC
Sooner or later, and probably sooner, I'm going to give in to the burning
temptation to re-do the installer completely. Brion's just waiting for it, I
know. ;-)

When that happens, this is one of the things I hope to address.
Comment 14 wyzemoro 2006-02-15 17:26:44 UTC
i also have this problem. using MediaWiki 1.5.6.

from my local slackware 10.2 linux box.

MediaWiki 1.5.6 installation

Please include all of the lines below when reporting installation problems.
Checking environment...

    * PHP 4.4.0: ok
    * PHP server API is apache; ok, using pretty URLs (index.php/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.
    * Neither Turck MMCache nor eAccelerator are installed, can't use object
caching functions
    * Found GNU diff3: /usr/bin/diff3.
    * Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if
you enable uploads.
    * Found GD graphics library built-in.
    * Installation directory: /var/www/htdocs/wiki
    * Script URI path: /wiki
    * Connecting to wiki on localhost as ...success.
    * Connected to 4.1.14; using enhancements for mySQL 4.
          o Error selecting database wiki: 1044 Access denied for user
''@'localhost' to database 'wiki'

and my webhost somewhere:

Checking environment...

    * PHP 4.3.10: ok
    * Warning: PHP's register_globals option is enabled. MediaWiki will work
correctly, but this setting increases your exposure to potential security
vulnerabilities in PHP-based software running on your server. You should disable
it if you are able.
    * PHP server API is apache; ok, using pretty URLs (index.php/Page_Title)
    * Have XML / Latin1-UTF-8 conversion support.
    * PHP is configured with no memory_limit.
    * Have zlib support; enabling output compression.
    * Neither Turck MMCache nor eAccelerator are installed, can't use object
caching functions
    * Found GNU diff3: /usr/bin/diff3.
    * Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if
you enable uploads.
    * Found GD graphics library built-in.
    * Installation directory: /home/morofoci/public_html/wiki
    * Script URI path:
    * PHP is linked with old MySQL client libraries. If you are using a MySQL
4.1 server and have problems connecting to the database, see
http://dev.mysql.com/doc/mysql/en/old-client.html for help.
    * Connecting to morofoci_wiki on localhost as ...success.
    * Connected to 4.0.25-standard; using enhancements for mySQL 4.
          o Error selecting database morofoci_wiki: 1044 Access denied for user:
'@localhost' to database 'morofoci_wiki'
Comment 15 wyzemoro 2006-02-15 17:51:06 UTC
if i use the root access on MySQL on my Slackware 10.2 Linux box. Its OK!

Checking environment...

    * PHP 4.4.0: ok
    * PHP server API is apache; ok, using pretty URLs (index.php/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.
    * Neither Turck MMCache nor eAccelerator are installed, can't use object
caching functions
    * Found GNU diff3: /usr/bin/diff3.
    * Found ImageMagick: /usr/bin/convert; image thumbnailing will be enabled if
you enable uploads.
    * Found GD graphics library built-in.
    * Installation directory: /var/www/htdocs/wiki
    * Script URI path: /wiki
    * Connecting to wiki on localhost as root...success.
    * Connected to 4.1.14; using enhancements for mySQL 4.
    * Database wiki exists
    * Creating tables... using MySQL 3/4 table defs... done.
    * Initializing data...
    * Created sysop account wyzemoro.
    *

      Initialising "MediaWiki" namespace...
      Clearing message cache...Done.

      Creating LocalSettings.php...

the problem is how can it be fix like in my shared hosting were i dont have root
access?

Comment 16 Rob Church 2006-02-16 11:31:24 UTC
The output from comment #14 looks to me like no username was entered in the
regular database username field, and that the superuser account details were
left to the defaults (i.e. "don't use") meaning that the installer tried to
connect with a blank username.

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


Navigation
Links