Hi,
is there a problem having two mediawikis running parallel on one mysql? Experimenting with update from 1.3.3 to 1.3.9, I have one 1.3.3 running as database "wikidb" on mysql and all the apache files in ....path..../httpd/htdocs/wiki/
Now set up a second, entirely independent apache having everything in ....differentPath..../httpd/htdocs/ and untaring the 1.3.9 archive there, after renaming ....differentPath..../httpd/htdocs/wiki/
So far working good, but filling out config/index.php (everything identical with the 1.3.3, but with "Database name" set to "wikidb2" and submitting leads to:
---8<--- Checking environment...
* PHP 4.3.9: ok * 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. * No zlib support. * Couldn't find GD library or ImageMagick; image thumbnailing disabled. * Installation directory: /home/cddoc/tools/httpd/htdocs/wiki * Script URI path: /wiki * Connected as root (automatic) * Connected to database... 4.0.17; enabling MySQL 4 enhancements * Couldn't create database wikidb2; try with root access or check your username/pass.
Something's not quite right yet; make sure everything below is filled out correctly. ---8<---
And labeled "<- Enter" is the "DB root password" field - but the DB root password given there is definitely correct - checked several times.
What's the problem here? :-?
Cheers and merry christmas Philipp
On Dec 24, 2004, at 12:51 AM, Philipp wrote:
is there a problem having two mediawikis running parallel on one mysql?
No, we have several hundred.
* Couldn't create database wikidb2; try with root access or checkyour username/pass.
Something's not quite right yet; make sure everything below is filled out correctly.
Confirm that it's actually working with the mysql command-line client. Check for bogus blank root users. Try creating the database first.
-- brion vibber (brion @ pobox.com)
Confirm that it's actually working with the mysql command-line client.
No problem there:
| ~/tools/mysql >./bin/mysql -u root -p | Enter password: | Welcome to the MySQL monitor. Commands end with ; or \g. | Your MySQL connection id is 2035 to server version: 4.0.17 | | Type 'help;' or '\h' for help. Type '\c' to clear the buffer. | | mysql> create database wikidb2; | Query OK, 1 row affected (0.01 sec) | | mysql> drop database wikidb2; | Query OK, 0 rows affected (0.50 sec)
Check for bogus blank root users.
Hm, I'm not too far into DB administration; is one of these suspicious?
mysql> select host,user from user; +---------------------------+----------+ | host | user | +---------------------------+----------+ | % | root | | % | sqluser | | % | wikiuser | | xxxxxx01.de.company.com | root | | localhost | root | | localhost | sqluser | | localhost | wikiuser | | localhost.localdomain | root | | localhost.localdomain | sqluser | | localhost.localdomain | wikiuser | +---------------------------+----------+
(Altered the "xxx"-line for privacy resons)
Try creating the database first.
You mean, manually inside mysql?
| mysql> create database wikidb2; | Query OK, 1 row affected (0.02 sec)
Same result after submitting the config-script after that.
Greetings Philipp
Philipp wrote on Fri, 24 Dec 2004 10:30:04 +0100:
??>> Confirm that it's actually working with the mysql command-line client.
P> No problem there:
??|> ~/tools/mysql >./bin/mysql -u root -p ??|> Enter password: ??|> Welcome to the MySQL monitor. Commands end with ; or \g. ??|> Your MySQL connection id is 2035 to server version: 4.0.17 ??|> ??|> Type 'help;' or '\h' for help. Type '\c' to clear the buffer. ??|> mysql>>> create database wikidb2; ??|> Query OK, 1 row affected (0.01 sec) ??|> mysql>>> drop database wikidb2; ??|> Query OK, 0 rows affected (0.50 sec)
??>> Check for bogus blank root users.
P> Hm, I'm not too far into DB administration; is one of these suspicious?
mysql>> select host,user from user; P> +---------------------------+----------+ host |>> user | P> +---------------------------+----------+ ??|> % | root | ??|> % | sqluser | ??|> % | wikiuser | ??|> xxxxxx01.de.company.com | root | localhost |>> root | localhost |>> sqluser | localhost |>> wikiuser | ??|> localhost.localdomain | root | ??|> localhost.localdomain | sqluser | ??|> localhost.localdomain | wikiuser | P> +---------------------------+----------+
Please check that ALL root users have the same rights.
Because when you connect from shell, and when you connect with PHP and Apache you probably DO NOT connect as the same user.
Run from shell (after logging to the mysql): SHOW PROCESSLIST;
You should get result in form: id, user, host:socket, db,...
and put the same comand in use from php, and if host is different, you have found the problem!
HTH
-- God speed
dear friends in spirit,
One month ago I asked already: when editing a page which becomes longer than 9973 chars, the Wiki puts NIL into MYSQL.
NoOne had a specific answer but an update from 1.37 to 1.38 PLUS putting PHP-Memory to 30MB at Providers site seemed to have done it.
Many users started eagerly adding long, well structured pages in our interesting homeopathic wiki project.
On 23. Dez. it started suddenly again:
- if Page gets larger than 9805 CHARS it is eaten up when SUBMITTING: http://www.homeopathy.at/wiki/index.php?title=Testsize - this page is just the max size it may get.
- long and very long pages that are in mysql are shown OK and presented for editing
- when submitting the edited page disappears and becomes empty, also in preview - trie above to add some letters and click preview and you see what I mean.
- curiously: if you edit a SECTION within a long page the section may again become up to 9805 chars, then it disappears.
- so by putting pages in well structured way with headers and making shure you go to edit the headers you may create very well a long page: http://www.homeopathy.at/wiki/index.php?title=Testsize2, this is a 50kb Testpage just created by repetitevly filling a long chunk of text in a section.
on 23. Dez. I had nothing changed on my setup, it was a beautiful running system so there was no need to move to 1.4 beta.
Since then I installed just a couple nights long new versions (1.37, 1.38, 1.39 now running very stable 1.4Beta3), cleard up the mysql-db from "history", all without any change of the problem.
My Provider put me up to 40MB of PHP-Memory
he says he has simply no clue where the problem can be, he also tried around a long time with all kind of PHP-Variables for my server.
From the description above there must be some BUFFER-Shortage in the
submit-edit-process, I guess some Apache variable or so.
ANYONE has ANY CLUE? Do I just have to change provider?
MediaWiki 1.4beta3 PHP : 4.3.10 (cgi) MySQL 4.0.22-standard
tx
HeliR at http://www.homeopathy.at/wiki
an addition: provider has increased max-postsize "for another 10MB" without any result.
HeliR
wikitech-l@lists.wikimedia.org