FYI
---------- Forwarded message ----------
From: Core operations via RT <core-ops(a)rt.wikimedia.org>
Date: Tue, Oct 8, 2013 at 12:14 PM
Subject: [wikimedia #5912] Upgrade PHP throughout the cluster to
5.3.10-1ubuntu3.8+wmf1 on Thursday 2013-10-08
To: akosiaris(a)wikimedia.org
Scheduling an upgrade of PHP through the cluster to from 5.3.10-1ubuntu3.6+wmf1
to 5.3.10-1ubuntu3.8+wmf1. The changes are three CVEs
CVE-2013-4635
CVE-2013-4113
CVE-2013-4248
and bug #63055 per RT #5209 (which was not solved due to one more bug)
The packages have been built and tested on beta and test.wikipedia.org and no
problems have arisen. The upgrade is expected to not be noticeable.
--
(ticket has been created)
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
Hey all,
Last Friday, the mw.Title rewrite landed in master. Here's a brief summary of the changes.
TL:DR;
* New static constructor mw.Title.newFromText (returns mw.Title or null).
* New internal title parser (uses wgLegalTitleChars and mirrors most of Title::secureAndSplit).
* Bugs like [[.com]] throwing have been fixed.
* Big thanks to David Chan!
New: Static constructor mw.Title.newFromText
Unlike the regular constructor, this one does not throw exceptions on invalid input. Instead it returns null. This should make using mw.Title less awkward.
As a reminder, you are still required to account for invalid input. Where you previously wrapped `new mw.Title` it in a try/catch (which many users forgot), one may now use mw.Title.newFromText and check the result for truthiness.
Examples:
```php
$title = Title::newFromText( $input );
if ( $title ) { .. }
```
```js
title = mw.Title.newFromText( input );
if ( title ) { .. }
```
Regular constructor (old pattern):
```js
try {
title = new mw.Title( input );
} catch ( e ) { .. }
if ( title ) { .. }
```
New: Title parser
Previously mw.Title had a very basic processor for the text input. It was designed to be looser than its PHP counterpart so that it is fast and defaults to considering something valid. It is indeed more important to not consider something invalid when it is is in fact valid, than the other way around. Clients should never be blocking an action and it'll have to go through the server anyway at some point. Though that design is good, it is not what it really was.
In practice mw.Title's old processor considered various things invalid that were valid. And it had certain side-effects that weren't very intuitive (it removed certain invalid characters so that the title would become valid;in other cases it would throw an exception).
The new parser uses wgLegalTitleChars [2] and mirrors most of Title::secureAndSplit. For this we had to convert the character sequences in wgLegalTitleChars from bytes to Unicode. Big thanks to David Chan for making this work!
A full list of bugs fixed and patterns now properly recognised as valid and invalid can be found in the commit message[1] and by examining the added test cases.
Various bugs have been fixed (e.g. titles starting with dots, such as [[.com]], throwing an exception).
Documentation: https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Title
-- Timo
[1]
https://gerrit.wikimedia.org/r/#/c/83047/https://github.com/wikimedia/mediawiki-core/commit/4894793ab60ea0a245372cb4…
[2]
https://gerrit.wikimedia.org/r/#/c/82040/https://github.com/wikimedia/mediawiki-core/commit/dc9c9ee7fc6d96f957e15b4f…
[3] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Title
I have just posted a new draft RFC on changing the thumbnail storage
and caching pipeline for Wikimedia projects [0].
This RFC was started as part of the Multimedia tech debt project.
Aaron, Faidon and I would like to move discussion forward on the issue
of the thumbnail caching layer in general and specifically would like
to find consensus on a reasonable change to address some of the
shortfalls of the current system in place for upload.wikimedia.org and
related wikis.
The core problem has been discussed on list previously [1], namely
that scaled media files (aka thumbnails) take up a lot of space in the
storage servers. This RFC proposes following a course of action
proposed in that prior discussion [2] to customize the Varnish hashing
configuration for thumbs such that a single HTCP purge would
invalidate all size variations for a given file. It attempts to
document some of the benefits and drawbacks of that proposal as well
as present a few related variations.
Any and all feedback from this group would be greatly appreciated in
vetting the core idea and determining reasonable next steps towards a
viable long term solution.
[0]: https://www.mediawiki.org/wiki/Requests_for_comment/Simplify_Thumbnail_Cache
[1]: http://wikimedia.7.x6.nabble.com/scaled-media-thumbs-as-temporary-files-not…
[2]: http://wikimedia.7.x6.nabble.com/scaled-media-thumbs-as-temporary-files-not…
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID
irc: bd808 v:415.839.6885 x6855
Might be of interest!
---------- Forwarded message ----------
From: Jon Robson <jrobson(a)wikimedia.org>
Date: Tue, Oct 8, 2013 at 12:06 AM
Subject: [WikimediaMobile] Mobile team upcoming changes
To: Operations Engineers <ops(a)lists.wikimedia.org>, mobile-l
<mobile-l(a)lists.wikimedia.org>
The MobileFrontend extension will see 2 changes within the next 3
weeks that will result in more API requests. I wanted to bring these
to the attention of ops to give you an opportunity to raise any
concerns.
The first makes the mobile uploads page exhibit infinite scroll. You
can see what this does if you compare the existing version [1] with
the beta version [2] and scroll to the bottom of the page. You will be
able to see the additional requests such a feature makes.
The second change will make Echo notifications load in mobile via
JavaScript avoiding a request to
https://en.m.wikipedia.org/wiki/Special:Notifications (this is no
different from the desktop version of the site)
You can track these changes on Mingle [3,4]. Based on the teams
existing velocity they are likely to be made and deployed no sooner
than Thursday 23rd to test wiki in that week's deployment train,
however there is a small chance they could make it a week early.
Please let us know if this could cause any issues.
[1] https://en.m.wikipedia.org/wiki/Special:Uploads/Kaldari
[2] https://en.m.wikipedia.org/wiki/Special:Uploads/Kaldari?mobileaction=beta
[3] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1282
[4] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1283
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Yuvi Panda T
http://yuvi.in/blog
Hey,
When constructing an SQL string, how should the following things be
escaped, if at all?
* Field names
* Index names
It looks like when doing a select using the Database MW thing, the field
names provided do not get escaped at all.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
I'm trying to port a template from wikitext to lua. The template [1]
is quite simple, but it gets repeated hundreds of times in some pages.
Getting the logic to work was not complicated (the modified version is
at [2]), but I'm seeing huge performance variation in the lua version:
parsing [3] takes anywhere from 15 to 20s, while the wikitext version
is stable between 18.5 and 19s (I'm testing using the "preview in
page" option).
Is this something to be expected from the lua interpreter? How can I
minimize the problem?
Thanks,
Strainu
[1] https://ro.wikipedia.org/wiki/Format:ElementLMI
[2] https://ro.wikipedia.org/wiki/Utilizator:Strainu/testlmi
[3] https://ro.wikipedia.org/wiki/Lista_monumentelor_istorice_din_Bucure%C8%99t…
Hello,
I'm lost. L
Since 2 weeks, I experience some problems : the site runs very fast, and
suddenly runs slow for a couple of seconds (let say 15/20 seconds to load a
single page), then back to normal. When the problem occurs, I see this in
the Apache access.log (see line with error 408. Apache error for Request
time out.):
192.168.75.1 - - [02/Oct/2013:16:05:34 -0400] "GET /sites/mediawiki001/
HTTP/1.1" 301 575 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0;
rv:11.0) like Gecko"
192.168.75.1 - - [02/Oct/2013:16:05:34 -0400] "POST
/sites/mediawiki001/index.php?action=ajax HTTP/1.1" 200 430
"http://euswebsrv01/sites/mediawiki001/index.php?title=Topics:Operating_syst
ems/Microsoft_Windows_8/Start_Screen" "Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0; rv:11.0) like Gecko"
192.168.75.1 - - [02/Oct/2013:16:05:34 -0400] "GET
/sites/mediawiki001/index.php?title=Main_Page HTTP/1.1" 200 8279 "-"
"Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
192.168.75.1 - - [02/Oct/2013:16:05:50 -0400] "-" 408 0 "-" "-"
192.168.75.1 - - [02/Oct/2013:16:05:50 -0400] "-" 408 0 "-" "-"
192.168.75.1 - - [02/Oct/2013:16:05:51 -0400] "-" 408 0 "-" "-"
192.168.75.1 - - [02/Oct/2013:16:05:51 -0400] "-" 408 0 "-" "-"
127.0.0.1 - - [02/Oct/2013:16:05:54 -0400] "OPTIONS * HTTP/1.0" 200 126 "-"
"Apache/2.2.22 (Ubuntu) (internal dummy connection)"
192.168.75.1 - - [02/Oct/2013:16:07:16 -0400] "GET
/sites/mediawiki001/index.php?title=File:Topics:windows-8_1-start-screen.png
HTTP/1.1" 200 7294
"http://euswebsrv01/sites/mediawiki001/index.php?title=Topics:Operating_syst
ems/Microsoft_Windows_8/Start_Screen" "Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0; rv:11.0) like Gecko"
192.168.75.1 - - [02/Oct/2013:16:07:17 -0400] "GET
/sites/mediawiki001/img_auth.php/thumb/500/5/5b/windows-8_1-start-screen.png
/120px-windows-8_1-start-screen.png HTTP/1.1" 200 13178
"http://euswebsrv01/sites/mediawiki001/index.php?title=File:Topics:windows-8
_1-start-screen.png" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0;
rv:11.0) like Gecko"
192.168.75.1 - - [02/Oct/2013:16:07:17 -0400] "GET
/sites/mediawiki001/img_auth.php/500/5/5b/windows-8_1-start-screen.png
HTTP/1.1" 200 189786
"http://euswebsrv01/sites/mediawiki001/index.php?title=File:Topics:windows-8
_1-start-screen.png" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0;
rv:11.0) like Gecko"
192.168.75.1 - - [02/Oct/2013:16:07:17 -0400] "GET /sites/mediawiki001/
HTTP/1.1" 301 575 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0;
rv:11.0) like Gecko"
General config:
VMware Workstation 10 running on Win7 SP1 x64
Web server: Ubuntu 12.04 Server x64, installed on a VMware machine, with 2
Go of RAM.
Apache/2.2.22 (Ubuntu)
MySQL 5.5.29
PHP Version 5.3.10-1ubuntu3.7
APC 3.1.13
No, I haven't change anything in my config since many weeks. I'm the only
one who access the site.
On the server, I have the following structure:
/var/www/index.html (to choose if I want to access Mediawiki site or PHPBB
site - see below)
/var/www/sites/mediawiki001 (Mediawiki site)
/var/www/sites/phpbb001 (PHPBB site)
When I access the PHPBB site, all is very rapid. issue occurs only with
Mediawiki.
I have try to read on the web. but I'm completely lost with this one. still
a newbie J
You will probably need more info (php.ini ? LocalSettings.php ? extension
list ?...) : just tell me.
Thanks in advance !
Pierre
Hello all!
It's been an absolute pleasure working with this community for GSoC 2013.
I've had a really good experience and it was really nice to get to know you
all.
I've written a blog post to summarize my experience over this summer as
well as discuss my plans for the project in the future.
http://blog.pragunbhutani.in/articles/google-summer-of-code-2013-wrap-up/
Please check it out, and if you find the project interesting and would like
to contribute to it: Don't bother knocking, come on in! :)
Cheers,
--
Pragun Bhutani
http://pragunbhutani.in
Skype : pragun.bhutani
Hello!
You know the drill.
Full schedule:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_October_7th
== Monday ==
* VisualEditor turned on by default for the following 26 wikis for all
users:
Bulgarian (bg), Catalan (ca), Cebuano (ceb), Czech (cs), Danish (da),
Estonian (et), Basque (eu), Finnish (fi), Galician (gl), Croatian
(hr), Hungarian (hu), Indonesian (id), Latvian (lv), Malay (ms),
Norwegian - Nynorsk (nn), Norwegian - Bokmål (no), Simple English
(simple), Slovak (sk), Slovenian (sl), Turkish (tr), Ukrainian (uk),
Volapük (vo), Waray-Waray (war), Modern Greek (el), Neopolitan (nap),
Venetian (vec), Sicilian (scn)
* GettingStarted/GuidedTour bug fix
== MediaWiki Train ==
* Normal MediaWiki 'train' of upgrades. 1.22wmf20 to non-Wikipedia sites
(Commons, Wiktionaries, etc) on Monday. 1.22wmf20 to all Wikipedias on
Thursday. 1.22wmf21 branched and deployed to test wikis on Thursday.
See:
https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap#Schedule_for_the_depl…
Note: Yes, there isn't a whole lot of non-standard deploys next week,
hence only the call out of Monday's deploys.
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |