Last modified: 2010-05-15 15:56:50 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 6063 - Install conks out possibly due to dash in superuser's username
Install conks out possibly due to dash in superuser's username
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.6.x
PC FreeBSD
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-24 00:16 UTC by Nomad of Norad (David C Hall)
Modified: 2010-05-15 15:56 UTC (History)
0 users

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


Attachments

Description Nomad of Norad (David C Hall) 2006-05-24 00:16:12 UTC
(Moving and condensing this from a thread on the MediaWiki-l mailing list...)

I have been attempting to install MediaWiki onto a settup with the following specs:

FreeBSD 4.11-STABLE

mysql Ver 12.22 Ditrib 4.0.16

perl, v5.8.3

php 4.4.1

...and have most recently gotten the following output in my browser upon
attempted install:

# PHP 4.4.1 installed
#
Warning: PHP's register_globals option is enabled. Disable it if you can.
MediaWiki will work, but your server is more exposed to PHP-based 
security vulnerabilities.
# 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
# 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: /home/joshua-w/public_html/wiki
# Script URI path: /wiki
# Environment checked. You can install MediaWiki.

Generating configuration file...
# Database type: mysql
# 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.
# Attempting to connect to database server as joshua-w...success.
# Connected to 4.0.16
# Database joshua-w_wiki exists
# There are already MediaWiki tables in this database. Checking if 
updates are needed...
# Granting user permissions...
Query "GRANT DELETE,INSERT,SELECT,UPDATE ON `joshua-w_wiki`.* TO 
'wikiuser'@'%' IDENTIFIED BY 'password-munged' " failed with error code "Access 
denied for user: 'joshua-w@localhost' to database 'joshua-w_wiki' 
(localhost)".

With a bit of googling, I discovered BugZilla bug #1734 (marked as Fixed) here
which suggests a problem with usernames having a dash (-) in them.

In my case, using a username here without a dash in it is not an option, because
my webspace provider appends the selected name (fragment) onto an
already-existing name (fragment) that has a dash in it.  I.e., I can select
spoon as a new username, and will get joshua-w_spoon when finished.  There is no
way to bypass having the joshua-w_ part of the name.

I'm hoping there's a way around this problem, either via an update to the
MediaWiki software or via a mod to the existing version.

BTW, I have also verified, via vDeck (the webinterface at my provider), that the
user joshua-w_wiki has got all the permissions set for the database
joshua-w_wiki (note that it is the same name as the user).

If I have oerlooked or left out anything, somebody please tell me.
Comment 1 Nomad of Norad (David C Hall) 2006-06-01 22:06:18 UTC
Well, the problem turned out to be that the password on the user linked to the
database wasn't long enough, or something of the sort.  When I created the
username and password, vDeck didn't complain about that, but apparently it was
an internal error when it came time to run the process described above.

It finally worked when I inserted joshua-w_wiki as the DC username (with new,
longer password), and inserted root as the superuser account, with - (a dash) as
the password.

I am setting this to WORKSFORME.  If that's the wrong setting, the techs here
are free to change it again.  :-)

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


Navigation
Links