User talk:Liangent
Completing project documentation
This is regarding the announcement (http://lists.wikimedia.org/pipermail/labs-l/2014-July/002762.html) if you have missed it.
We have added some fields in addition to description field which is already there on your projects. Please click "Edit Documentation" in your project page/projects pages and fill the blanks. It will only take few minutes from your valuable time.
If you have any comments or suggestion on the form please let me know.Thanks in advance!--Sandaru (talk) 16:59, 24 July 2014 (UTC)
MediaWiki hosting on tools
I am trying to figure out how to get MediaWiki to work on tools and I heard you had an instance running successfully. Could you give a little info on how you did it? Reply here when you get the chance. Thanks, -24Talk 20:29, 4 August 2014 (UTC)
- -24: Installing a standalone MediaWiki would be straightforward. I assume you want your MediaWiki installation connected to the replicated database. In my installation, https://github.com/liangent/mediawiki-extensions-Labs (and some patches against MediaWiki, primarily to add hooks and to disable unusable stuff) is the core. If you want to take it as a reference and build your own, go for it; if you just want to use it, maybe I can post some more detailed instructions later. liangent (talk) 17:21, 10 August 2014 (UTC)
- Liangent: Actually we're getting hung up on a php error. It seems that whenever a LocalSettings.php gets uploaded, the index.php page only shows a blank screen. Refer to this bug. -24Talk 21:31, 10 August 2014 (UTC)
- -24: It appears http://tools.wmflabs.org/custom-utils/mediawiki/index.php?title=Main_Page is working except for one issue that the port is not detected correctly (try setting $wgServer to fix). liangent (talk) 03:38, 11 August 2014 (UTC)
- Liangent: I was just using the auto config settings that were set in the MW install. What port should I set it to. The regular http port? -24Talk 14:37, 11 August 2014 (UTC)
- Liangent: It seems that setting $wgServer without a port fixed it. Now I have to figure out what in MW set it to 4066. -24Talk 14:41, 11 August 2014 (UTC)
- -24: Because your webservice IS running on a webserver using that port (and on a webgrid node every user is using a unique port). From the internal side, your webservice is at http://tools-webgrid-02:4066/ and the proxy at http://tools.wmflabs.org/ forwards requests there if /custom-utils is requested. liangent (talk) 15:03, 11 August 2014 (UTC)
- Liangent Good to know. Thanks for the help. I'll write some documentation on this. -24Talk 15:11, 11 August 2014 (UTC)
- -24: Because your webservice IS running on a webserver using that port (and on a webgrid node every user is using a unique port). From the internal side, your webservice is at http://tools-webgrid-02:4066/ and the proxy at http://tools.wmflabs.org/ forwards requests there if /custom-utils is requested. liangent (talk) 15:03, 11 August 2014 (UTC)
- Liangent: It seems that setting $wgServer without a port fixed it. Now I have to figure out what in MW set it to 4066. -24Talk 14:41, 11 August 2014 (UTC)
- Liangent: I was just using the auto config settings that were set in the MW install. What port should I set it to. The regular http port? -24Talk 14:37, 11 August 2014 (UTC)
- -24: It appears http://tools.wmflabs.org/custom-utils/mediawiki/index.php?title=Main_Page is working except for one issue that the port is not detected correctly (try setting $wgServer to fix). liangent (talk) 03:38, 11 August 2014 (UTC)
- Liangent: Actually we're getting hung up on a php error. It seems that whenever a LocalSettings.php gets uploaded, the index.php page only shows a blank screen. Refer to this bug. -24Talk 21:31, 10 August 2014 (UTC)
Wiki Replica c1.labsdb to be rebooted Monday 2017-10-30 14:30 UTC
A tool you maintain is hosting data on labsdb1001.eqiad.wmnet (aka c1.labsdb). This server will be rebooted Monday 2017-10-30 at 14:30 UTC.
Normal usage of the *.labsdb databases should experience only limited interruption as DNS is changed to point to the labsdb1003.eqiad.wmnet (aka c3.labsdb). The c1.labsdb service name will not be updated however, so tools hardcoded to that service name will be interrupted until the reboot is complete.
There is a possibility of catastrophic hardware failure in this reboot. There will be no way to recover the server or the data it currently hosts if that happens. Tools that are hosting self-created data on c1.labsdb will lose that data if there is hardware failure. If you are unsure why your tool is hosting data on c1.labsdb, you can check the database and table names at https://tools.wmflabs.org/tool-db-usage/.
This reboot is an intermediate step before the complete shutdown of the server on Wednesday 2017-12-13. See Wiki Replica c1 and c3 shutdown for more information. --BryanDavis 00:22, 28 October 2017 (UTC)