Hello,
The committee has finished selecting new members of the Code of Conduct
Committee <https://www.mediawiki.org/wiki/Code_of_Conduct/Committee>. The
new committee candidates are (in alphabetical order):
- Amir Sarabadani
- Eugene233
- Martin Urbanec
- MusikAnimal
- Nuria Ruiz
Auxiliary members will be (also in alphabetical order):
- Effie Mouzeli
- Huji
- Jayprakash12345
- Luke081515
- Tony Thomas
More details about the member candidates can be found in this MediaWiki.org
page
<https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members/Candidates>
.
Changes compared to last term:
- Legoktm leaves the main committee
- Eugene233 joins the main CoC committee
- Nuria moves from auxiliary to the main committee
- Luke081515 joins the auxiliary committee
- Ariel leaves the auxiliary committee
- Tony Thomas moves from main to the auxiliary committee
This is not the final structure. According to the Code of Conduct
<https://www.mediawiki.org/wiki/Code_of_Conduct/Committee#Selection_of_new_m…>,
the current committee publishes the new members and calls for public
feedback. Please let the committee know via techconduct(a)wikimedia.org if
you have any concern regarding the candidate slate by end of day *May 31,
2022*.
After that, the committee will either finalize the candidate slate or
update it in response to concerns raised. If the candidate slate changes,
there will be another two week feedback period covering the newly proposed
members. After the selections are finalized, there will be a training
period, after which the new Committee will be appointed and serve for a
year.
Best,
Martin Urbanec, on behalf of the Code of Conduct committee
This release promotes Node.js 14 to be the default for the fresh-node command.
Get started by installing, updating, or learning more, at:
https://gerrit.wikimedia.org/g/fresh#fresh-environment
Changelog:
https://gerrit.wikimedia.org/g/fresh/+/22.05.1/CHANGELOG.md
Node.js 14 is now the default environment for the fresh-node command, this follows WMF CI (Thanks James Forrester!). [1] Node.js 12 remains available via fresh-node12. Node.js 10 has been removed after being deprecated since September of last year.
This release also adds support for detecting and installing to your home directory instead of system-wide, which is often preferred on Linux. The installer automatically selects one of $HOME/bin or $HOME/.local/bin if it exists and is in your "PATH". (Thanks Antoine Musso!)
If you encounter problems with Node.js 14 or experience other issues, let us know on Phabricator at https://phabricator.wikimedia.org/tag/fresh/. This is also where you can previous tasks.
Fresh is a fast way to create isolated environments from your terminal. These can be used to work more responsibly with 'npm' developer tools such as ESLint, QUnit, Grunt, Selenium, and more. Example guide: https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing
--
Timo Tijhof
[1] https://phabricator.wikimedia.org/T267890
Hey all,
A note that WMF Release Engineering are spending a sprint focusing as a
team on GitLab migration efforts. *As a consequence, we're pausing the
deployment train for the week of **M**ay 9th*so we can work on the
problem as a group without losing 1-2 people to train duties for most of
the week.
Unlike our recent experiment at running multiple trains in a week, this
/shouldn't/have much immediate impact on your work, but if you're
interested in GitLab adoption, you might want to follow along on the
sprint workboard:
https://phabricator.wikimedia.org/project/board/5873/
Goal for this sprint:***Migration of blubber / blubberoid to GitLab*
* https://phabricator.wikimedia.org/T301168
* What that means;
* Project exists on GitLab
* CI runs on commits
* We can publish an image from GitLab
<3
-- Brennen Bearnes, forRelease Engineering
Since the beginning of the year, the Wikimedia Language team has enabled
translation backports for MediaWiki core, extensions and skins hosted on
Gerrit. On a weekly schedule compatible translations from master branch are
backpored to all the supported release branches. Currently supported
branches are 1.35–1.38.
Translation backports partially replace the purpose of the
LocalisationUpdate extension. Wikimedia sites no longer use the extension,
and to our knowledge only a few other users of the extension exist, because
it needs manual setup to use.
We, the Language team, think that maintaining the LocalisationUpdate
extension is no longer a good use of our time. We are asking for your
feedback about the future of this extension.
We are planning to:
* Remove LocalisationUpdate from the MediaWiki Language Extension Bundle
starting from version 2022.07
* Remove us as maintainers of the extension
Additionally, based on the feedback, we are planning to either mark the
extension as unmaintained, transfer maintenance to a new maintainer, or
request the extension to be archived and removed from the list of
extensions bundled with MediaWiki core if there is no indication that
anyone uses this extension.
We request your feedback and welcome discussion on
https://phabricator.wikimedia.org/T300498. Please let us know if you are
using this extension and whether you would be interested in maintaining it.
*Anticipated questions*
Q: What about Wikimedia sites: does this mean they will not get frequent
translation updates as they used to have?
A: We still think this is important, but we do not think the previous
solution can be restored. We would like to collaborate on new solutions.
One solution could be more frequent deployments.
-Niklas
Hi everyone,
I just realized I probably sent my original message (see below) to the
wrong list. So here goes again, this time with a deeper understanding
what is going on, but also still much doubt and confusion.
tl;dr on the original post: Users are being randomly disconnected from
our mediawiki instances.
I would like to check with you if what I found is a bug or not and if
it's not, then I'm looking to understand why it behaves this way. I am
also looking for information on what triggers garbage collection of PHP
sessions.
Since I originally posted, I have found out what is deleting sessions
from the objectcache table in the database. I have been able to
reproduce this both on a remote server and locally. Both times, my
set-up is running in a docker environment.
The call-stack that does this is the following:
#0 SqlBagOStuff->deleteServerObjectsExpiringBefore() called at
[/var/www/html/includes/objectcache/SqlBagOStuff.php:668]
#1 SqlBagOStuff->deleteObjectsExpiringBefore() called at
[/var/www/html/includes/libs/objectcache/CachedBagOStuff.php:148]
#2 CachedBagOStuff->deleteObjectsExpiringBefore() called at
[/var/www/html/includes/session/PHPSessionHandler.php:376]
#3 MediaWiki\Session\PHPSessionHandler->gc()
#4 session_start() called at [/var/www/html/includes/Setup.php:757]
#5 require_once(/var/www/html/includes/Setup.php) called at
[/var/www/html/includes/WebStart.php:89]
#6 require(/var/www/html/includes/WebStart.php) called at
[/var/www/html/index.php:44]
Usually, SqlBagOStuff::deleteServerObjectsExpiringBefore is called
fromMWCallableUpdate->doUpdate() and passed a Unix timestamp. This
timestamp is a UTC value and handled as such.
However, sometimes, as can be seen from the backtrace above, it is
called from the Garbage Collector in PHPSessionHandler:
public function gc( $maxlifetime ) {
if ( self::$instance !== $this ) {
throw new \UnexpectedValueException( __METHOD__ . ': Wrong
instance called!' );
}
$before = date( 'YmdHis', time() );
$this->store->deleteObjectsExpiringBefore( $before );
return true;
}
The problem here is that – probably for historical reasons - the
function is passed a date string here instead of a Unix timestamp. And
*the actual problem with that* is that the date() function applies
timezone information (if $wgLocaltimezone is set). The resulting
timestamp will thus be in the future (or be local time, interpreted as
UTC). With a value of something equivalent to GMT+2, gc() will cause all
current sessions to be deleted since they have a standard expiry time of
1h, stored as UTC value in the database.
If this happens, and the session is not declared persistent
($session->isPersistent(), "Keep me logged in"), then all users are
immediately logged out of mediawiki.
Thus, my first question: Is this a bug? Since the $timestamp parameter
is passed to ConvertibleTimestamp::convert( TS_UNIX, $timestamp ) in
SqlBagOStuff::deleteServerObjectsExpiringBefore anyway, I do not see any
reason to pass a date string. My suggestion for a fix would be to change
the gc method as follows:
public function gc( $maxlifetime ) {
if ( self::$instance !== $this ) {
throw new \UnexpectedValueException( __METHOD__ . ': Wrong
instance called!' );
}
$this->store->deleteObjectsExpiringBefore( microtime(true) ); //
time() would be sufficient
return true;
}
My second question would be: What controls when PHPSessionHandler::gc is
called? Is it indeed the session configuration for the PHP process (i.e.
session.gc_probability, session.gc_divisor and session.gc_maxlifetime) ?
Thanks,
David
> Hi all,
>
>
> I'm writing to the list in the hope of receiving some feedback,
> questions, maybe answers to help us solve a conundrum with sessions we
> have on our Wikibase/Mediawiki installation.
>
>
> We're running two different docker-based wikibase installations (one
> staging, one production) on two separate virtual machines. Both use
> the SimpleSaml extension to connect to a SAML implementation, but we
> have found that the random session deletion happens both with and
> without the SAML extension used.
>
>
> The symptoms that we've seen are that out of the blue, users are
> disconnected from mediawiki. Since we use SAML, it's enough to click
> the Login link to again be connected.
>
>
> The duration or number of requests until a session is deleted seems
> random. It does appear though, that the more (or more frequent)
> requests are made (and thus background jobs run) the quicker a session
> is deleted.
>
>
> We have even tried setting $wgObjectCacheSessionExpiry = 7200; in
> order to exclude any TimeZone related issues which was our first
> suspicion. However, changing this from the default 1h session expiry
> does not change the behavior we're seeing.
>
>
> Sessions are deleted regardless of their nature. E.g. sessions
> established for oauth connections are deleted in the same way and at
> the same time as other sessions. E.g. using wikidataintegrator we're
> able to run a number of requests until the CSRF token expires (with
> the number of requests that succeed before this happens being random):
>
> […]
> Created Item Q379 from Classhttp://www.cidoc-crm.org/cidoc-crm/E34_Inscription.
> Created Item Q380 from Classhttp://www.cidoc-crm.org/cidoc-crm/E53_Place.
> Errorwhile writing to Wikidata
> ERROR creating class referencefor http://www.cidoc-crm.org/cidoc-crm/E35_Title: {'error': {'code':'badtoken','info':'Invalid CSRF token.','*':'See https://saf-dev.bnl.lu/w/api.php for API usage. Subscribe to the
> mediawiki-api-announce mailing list at
> <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce>
> for notice of API deprecations and breaking changes.'}}
> Errorwhile writing to Wikidata
> ERROR creating object property referencefor http://www.cidoc-crm.org/cidoc-crm/P16_used_specific_object: {'error': {'code':'badtoken','info':'Invalid CSRF token.','*':'See https://saf-dev.bnl.lu/w/api.php for API usage. Subscribe to the
> mediawiki-api-announce mailing list at
> <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce>
> for notice of API deprecations and breaking changes.'}}
>
>
>
> If sessions are not randomly deleted, then session renewal seems to
> work as planned with them being renewed after half their expiry time:
>
> |[DBQuery] SqlBagOStuff::fetchBlobMulti [0s] db.svc:3306: SELECT
> keyname,value,exptime FROM `objectcache` WHE RE keyname =
> 'mediawiki:MWSession:n9krnsfa303qk9c2osp6c81tp1k2bp5b' [session]
> SessionBackend
> "require/require_once/MediaWiki\Session\Session->renew/MediaWiki\Session\SessionBackend-
> >renew" metadata dirty for renew():
> require/require_once/MediaWiki\Session\Session->renew/MediaWiki\Session\Sessi
> onBackend->renew [session] SessionBackend
> "n9krnsfa303qk9c2osp6c81tp1k2bp5b" force-persist for renew():
> require/require_once/Media
> Wiki\Session\Session->renew/MediaWiki\Session\SessionBackend->renew
> [session] SessionBackend "n9krnsfa303qk9c2osp6c81tp1k2bp5b" save:
> dataDirty=0 metaDirty=1 forcePersist=1 [cookie] setcookie:
> "mediawiki_session", "n9krnsfa303qk9c2osp6c81tp1k2bp5b", "0", "/", "",
> "1", "1", "" [cookie] setcookie: "mediawikiUserID", "13",
> "1648233666", "/", "", "1", "1", "" [cookie] setcookie:
> "mediawikiUserName", "Ibl676", "1648233666", "/", "", "1", "1", ""
> [cookie] already deleted setcookie: "mediawikiToken", "",
> "1614105666", "/", "", "1", "1", "" [cookie] already deleted
> setcookie: "forceHTTPS", "", "1614105666", "/", "", "", "1", ""
> [session] SessionBackend "n9krnsfa303qk9c2osp6c81tp1k2bp5b" Taking
> over PHP session [session] SessionBackend
> "n9krnsfa303qk9c2osp6c81tp1k2bp5b" save: dataDirty=0 metaDirty=1
> forcePersist=1 [cookie] already set setcookie: "mediawiki_session",
> "n9krnsfa303qk9c2osp6c81tp1k2bp5b", "0", "/", "", "1", "1", ""
> [cookie] already set setcookie: "mediawikiUserID", "13", "1648233666",
> "/", "", "1", "1", "" [cookie] already set setcookie:
> "mediawikiUserName", "Ibl676", "1648233666", "/", "", "1", "1", ""
> [cookie] already deleted setcookie: "mediawikiToken", "",
> "1614105666", "/", "", "1", "1", "" [cookie] already deleted
> setcookie: "forceHTTPS", "", "1614105666", "/", "", "", "1", ""
> [DBQuery] SqlBagOStuff::updateTable [0.002s] db.svc:3306: REPLACE INTO
> `objectcache` (keyname,value,exptime) VALU ES
> ('mediawiki:MWSession:n9krnsfa303qk9c2osp6c81tp1k2bp5b','...\0','20220223194106')|
>
> Here is one example where the session got deleted by whatever feels
> responsible to do so:
>
> MariaDB [mediawiki]> select keyname, exptimefrom objectcachewhere keynamelike 'mediawiki:MWSession%';
> +------------------------------------------------------+---------------------+
> | keyname | exptime |
> +------------------------------------------------------+---------------------+
> | mediawiki:MWSession:t7d5lms2nrma6k627c6usrgc6289en3a |2022-03-24 17:34:34 |
> +------------------------------------------------------+---------------------+
> 1 rowin set (0.001 sec)
>
> MariaDB [mediawiki]> select keyname, exptimefrom objectcachewhere keynamelike 'mediawiki:MWSession%';
> Emptyset (0.001 sec)
>
> MariaDB [mediawiki]> select now();
> +---------------------+
> | now() |
> +---------------------+
> |2022-03-24 17:37:15 |
> +---------------------+
> 1 rowin set (0.024 sec)
>
>
> The only instance of me finding something remotely related to randomly
> deleting a session would be these log entries:
>
>
> |2022-03-24 17:03:29 51290acae35a mediawiki: SessionManager using
> store SqlBagOStuff 2022-03-24 17:03:29 51290acae35a mediawiki: Saving
> all sessions on shutdown 2022-03-24 17:03:29 51290acae35a mediawiki:
> SessionManager using store SqlBagOStuff 2022-03-24 17:03:29
> 51290acae35a mediawiki: Session
> "[30]MediaWiki\Session\CookieSessionProvider<-:13:Ibl676>8favvi92d08njut82j66un60r601titn":
> Unverified user provided and no metadata to auth it 2022-03-24
> 17:03:29 51290acae35a mediawiki: setcookie: "mediawiki_session", "",
> "1616605409", "/", "", "1", "1", "" 2022-03-24 17:03:29 51290acae35a
> mediawiki: setcookie: "mediawikiUserID", "", "1616605409", "/", "",
> "1", "1", "" 2022-03-24 17:03:29 51290acae35a mediawiki: already
> deleted setcookie: "mediawikiToken", "", "1616605409", "/", "", "1",
> "1", "" 2022-03-24 17:03:29 51290acae35a mediawiki: already deleted
> setcookie: "forceHTTPS", "", "1616605409", "/", "", "", "1", ""
> 2022-03-24 17:03:29 51290acae35a mediawiki: SessionBackend
> "ujf6rcheseb51lpaojrqggb4c23s1flr" is unsaved, marking dirty in
> constructor 2022-03-24 17:03:29 51290acae35a mediawiki: SessionBackend
> "ujf6rcheseb51lpaojrqggb4c23s1flr" save: dataDirty=1 metaDirty=1
> forcePersist=0 2022-03-24 17:03:29 51290acae35a mediawiki: already
> deleted setcookie: "mediawiki_session", "", "1616605409", "/", "",
> "1", "1", "" 2022-03-24 17:03:29 51290acae35a mediawiki: already
> deleted setcookie: "mediawikiUserID", "", "1616605409", "/", "", "1",
> "1", "" 2022-03-24 17:03:29 51290acae35a mediawiki: already deleted
> setcookie: "mediawikiToken", "", "1616605409", "/", "", "1", "1", ""
> 2022-03-24 17:03:29 51290acae35a mediawiki: already deleted setcookie:
> "forceHTTPS", "", "1616605409", "/", "", "", "1", "" 2022-03-24
> 17:03:29 51290acae35a mediawiki: Saving all sessions on shutdown |
>
> IBL676 is my SAML ID. I'm not sure why the user is unverified and what
> metadata would be used/required to verify it?
>
>
>
> Looking forward to any advice on how to further investigate what is
> going on here.
>
--
*TenTwentyFour S.à r.l.*
www.tentwentyfour.lu <https://www.tentwentyfour.lu>
*T*: +352 20 211 1024
*F*: +352 20 211 1023
1 place de l'Hôtel de Ville
4138 Esch-sur-Alzette