Last modified: 2012-04-12 13:54:14 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 T30097, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28097 - Cannot login when database is on a different server than the webserver
Cannot login when database is on a different server than the webserver
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.16.x
PC All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-17 18:31 UTC by Etienne
Modified: 2012-04-12 13:54 UTC (History)
2 users (show)

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


Attachments

Description Etienne 2011-03-17 18:31:01 UTC
Hi all,

I've ran into a weird trouble and I need a hand.

We have two webservers that provided redundancy. 
The web sites are simply copy/pasted from the primary to the backup server.
The load balancing is all done on the network side.
Hence, we have to have the same web sites on both servers, otherwise the page won't show half the time the user browse to it.
Same with the wiki page.
So, I created the wiki page on the backup server, and linked it to the database on the primary. (i know... not totally redundant, but if we lose the master, the wikipage is the last of our trouble)
Once I granted database acces to the backup server, it worked like a charm. 
I can browse the entire wiki site without a glitch.

Then I tried to login a local user. I get this error:
"Loggin error
You have not specified a valid user name."

It does work when you browse the primary, but not on the backup.
the users are stored in the database, and since all the rest of the site is also pulled from the database I can't see why it's not working.

Here's our configuration:
Windows server 2008 R2
IIS7
PHP 5.3.5
MediaWiki 1.16.2
MySQL 5.1.53

It might have something to do with the the IIS authentication... but honestly I have no clue.
I have no windows events or php_errors relative to that issue.

Any help would be greatly appreciated.

Thank you

Etienne
Comment 1 Bryan Tong Minh 2011-03-18 12:39:12 UTC
If you use MediaWiki with multiple webservers, you need to store your session data on a shared storage. This means using memcached, or setting PHP's session store path to a shared path (but I don't know if that is supported).
Comment 2 Mark A. Hershberger 2011-03-18 21:09:45 UTC
As Bryan pointed out this is a problem with the setup, not anything that can be fixed in MediaWiki.
Comment 3 Etienne 2011-03-21 13:28:26 UTC
Great! thanx for the hint guys.
I'll look into it and report any development.

Etienne
Comment 4 Etienne 2011-03-23 15:07:51 UTC
Got it working.
Not exactly a walk in the park but...

here's a little walk-through I created for our own use, thought I would share it with you.



Install WIKI on TWO Load-Balanced Server
The server we are using to publish the Wiki site are load-balanced.
So if we install the WikiPage on only one server, if the switch directs you to the second server you won’t reach the site.
If you simply install two stand alone wiki on both servers, well they will be stand alone. Any change made on one serer won’t show on the other server.
 
The solution is to install Wiki on both servers and have the second one (back) to point to the database on the prime server. Not as easy as it sounds… I’ll walk you through it.
Note: For a real redundant installation you would perform the following steps on both server and have them point to a third database server, or have the servers act as a cluster. In our case, we just want the web-site to display properly.
 
1-Install a standalone wiki site on your “back” server as explained in this document. To make the process easier, you can copy the configuration files. For the PHP, the file is php.ini and for the wiki, LocalSettings.php.
Don’t forget to install (copy) the extensions on the ‘back” server.

2-We need to share some key folders on the “prime” server:
 a. PHP/sessiondata
 b. PHP/uploadtemp
 c. Inetpub/Wiki/images
Share the folders, and allow a domain user all access to them.

3-On the “back” server only, you need to have the application pool run as the user you picked at step 2. To do so, in IIS, go on “Application Pools” select the appropriate pool, Wiki if you followed this manual. Right click “Advanced Settings” and change the Identity to that user.

4-On the “back” server. Delete the wiki/images folder. This folder holds the uploaded images and all the other uploaded files.

5-On the “back” server, create a virtual folder pointing to //your_prime_server/inetpub/wiki/images/. Right click the wiki web app, “Add Virtual Directory”. Alias: Images. Physical path: //your_prime_server/images/. Click “Connect as…” and configure your domain user that has acces to the images folder.

6-Make the following change to the php.ini file on the “back_server”
  a. open_basedir = "c:/inetpub/wiki; //”your_prime_server”/sessiondata; //”your_prime_server”/uploadtemp; //”your_prime_server”/images"
  b. upload_tmp_dir = "//”your_prime_server”/uploademp"
  c. session.save_path = "//”your_prime_server”/sessiondata"

7-Make sure this is set as:  fastcgi.impersonate = 0



any comments or suggestions, go ahead !

Etienne



Oh just so you know memCached is now memBase available at http://techzone.couchbase.com/
still free !
Comment 5 Mark A. Hershberger 2011-03-25 01:45:29 UTC
(In reply to comment #4)
> here's a little walk-through I created for our own use, thought I would share
> it with you.

Would you mind posting this to MediaWiki.org to make it easy for others who try to imitate your setup??
Comment 6 Etienne 2011-03-25 14:35:46 UTC
Will Do !  (in the following week hopefully)

Etienne

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


Navigation
Links