I noticed that MediaWiki 1.33 includes a stronger hash algorithm (argon2)
yet the default password algorithm in use is still pbkdf. The manual page
is not updated for this.
Does anyone know how to safely convert?
Is it advisable to attempt changing to this new hash algorithm?
Thanks,
Kevin
Dear Yaron,
Uncharted charting territory - very exciting!
Thank you for the solution! Absolutely did the trick.
-Billy
------ Original Message ------
From: mediawiki-l-request(a)lists.wikimedia.org
To: mediawiki-l(a)lists.wikimedia.org
Sent: 11/19/2019 5:00:04 AM
Subject: MediaWiki-l Digest, Vol 194, Issue 9
>Send MediaWiki-l mailing list submissions to
>mediawiki-l(a)lists.wikimedia.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>or, via email, send a message with subject or body 'help' to
>mediawiki-l-request(a)lists.wikimedia.org
>
>You can reach the person managing the list at
>mediawiki-l-owner(a)lists.wikimedia.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of MediaWiki-l digest..."
>
>
>Today's Topics:
>
> 1. Re: Page Forms multiple-instance coordinate entry (Yaron Koren)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 18 Nov 2019 09:54:34 -0500
>From: Yaron Koren <yaron(a)wikiworks.com>
>To: MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org>
>Subject: Re: [MediaWiki-l] Page Forms multiple-instance coordinate
> entry
>Message-ID:
> <CAGmQEQH3DQ0bTNgB4XNLpO1-13hPSpWvckkJ5Qa4aVmwzjUWcQ(a)mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>Hi Billy,
>
>Sorry about that problem. You might be the first person who's tried having
>map inputs within a multiple-instance template... at least, I haven't heard
>of someone doing that before, I don't think.
>
>Anyway, you did uncover a real bug. I just checked in a fix for this, so if
>you get the latest Page Forms code, it will hopefully work better. Please
>let me know if you run into any issues after updating the code.
>
>-Yaron
>
>On Fri, Nov 15, 2019 at 4:15 PM Billy Sims <500cents700(a)gmail.com> wrote:
>
>> Hello,
>> Has anyone run into issues with using map-picker coordinate entry on a Page
>> Forms form with a multiple-instance template ? All three openlayers,
>> leaflet, and googlemaps input types work wonderfully until the "multiple"
>> parameter is added. Once added, leaflet and openlayers display an
>> unresponsive map box in which the map visuals are offset and frozen, while
>> googlemaps displays a grey, unresponsive map box.
>>
>> My best guess is that there is a conflict with the javascript loading the
>> map feature first and then handling the multiple instance button. Perhaps
>> this would also explain the offset map image (which would seem to be
>> properly placed for a single-instance item)
>>
>> Any help/guesses/solutions are much appreciated!
>>
>> *SMW 3.1.0*
>>
>>
>>
>> *MediaWiki 1.33.1PHP 7.2.24 (litespeed)MariaDB 10.1.40-MariaDB-cll-lveICU
>> 63.1*
>>
>> (and incidentally, though I don't think this is an issue, I'll mention the
>> template used generates a subobject in which the coordinates are to then be
>> stored.
>>
>> Best,
>> Billy
>> _______________________________________________
>> MediaWiki-l mailing list
>> To unsubscribe, go to:
>>https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>>
>
>
>--
>WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>MediaWiki-l mailing list
>MediaWiki-l(a)lists.wikimedia.org
>https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
>------------------------------
>
>End of MediaWiki-l Digest, Vol 194, Issue 9
>*******************************************
Hello,
Has anyone run into issues with using map-picker coordinate entry on a Page
Forms form with a multiple-instance template ? All three openlayers,
leaflet, and googlemaps input types work wonderfully until the "multiple"
parameter is added. Once added, leaflet and openlayers display an
unresponsive map box in which the map visuals are offset and frozen, while
googlemaps displays a grey, unresponsive map box.
My best guess is that there is a conflict with the javascript loading the
map feature first and then handling the multiple instance button. Perhaps
this would also explain the offset map image (which would seem to be
properly placed for a single-instance item)
Any help/guesses/solutions are much appreciated!
*SMW 3.1.0*
*MediaWiki 1.33.1PHP 7.2.24 (litespeed)MariaDB 10.1.40-MariaDB-cll-lveICU
63.1*
(and incidentally, though I don't think this is an issue, I'll mention the
template used generates a subobject in which the coordinates are to then be
stored.
Best,
Billy
Hi,
for our production system I’m using a MariaDB Galera cluster as RDMS backend. Though there is a feature to enable (experimental) replication of MyISAM tables, this doesn't play well with Cargo. Certain operations involving _pageData tables caused the cluster to reach an inconsistent data state, thus stopping replication and ultimately falling apart.
I could isolate the cause to the following transaction (which is embedded between two inserts for the same thing):
BEGIN /* Wikimedia\Rdbms\Database::begin */
SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo\_\_staff\_\_NEXT'
SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo\_\_staff\_\_\_files'
DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE `_pageID` = '273'
DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData` WHERE `_pageID` = '273'
COMMIT /* Wikimedia\Rdbms\Database::commit */
cargo__staff table being InnoDB, cargo___pageData being MyISAM. Unfortunately this leads to the delete statement on the InnoDB table not being replicated, while the delete on the MyISAM table is. Thus on the following insert the row already exists, causing a unique key violation and inconsistent cluster state.
Is it really still necessary to use MyISAM for these tables? Full text indices are available on InnoDB for quite some time now, so I’m wondering whether this still needs to be supported or if it would be possible to make both choices available.
Best: Jan.
--
idea-sketch
Jan Böhme & Uwe Schützenmeister
Lößnitzstr. 14
01097 Dresden
www.idea-sketch.com <http://www.idea-sketch.com/>
Tel.: +49 . (0)351 . 810 74 250
Mobil: +49 . (0)179 .53 41 641
Huutoanbui3(a)gmail.com
Toi chua nhan duoc mot khoan tien nao ca .neu nhu muon hop tac lau dai thi
xin mong la moi nguoi hay lam ciec theo mot cach thuc te .va dung doi hoi
nheu qua .xin cam on
Vào 19:03 Th 7, 09 thg 11 2019 <mediawiki-l-request(a)lists.wikimedia.org> đã
viết:
> Send MediaWiki-l mailing list submissions to
> mediawiki-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> or, via email, send a message with subject or body 'help' to
> mediawiki-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> mediawiki-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MediaWiki-l digest..."
>
>
> Today's Topics:
>
> 1. Re: [Cargo] table format for _pageData and _fileData (Yaron Koren)
> 2. GitHub's "Automated Security Fixes" have been disabled on the
> Wikimedia Org (Sam Reed)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 8 Nov 2019 11:00:38 -0500
> From: Yaron Koren <yaron(a)wikiworks.com>
> To: MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org>
> Subject: Re: [MediaWiki-l] [Cargo] table format for _pageData and
> _fileData
> Message-ID:
> <CAGmQEQFfb--cRyPLFZik63su2qM-Nk73+0jyT+hc=
> zOjf39C+w(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Jan,
>
> Oh, that's too bad. I didn't know that MyISAM doesn't support database
> clustering. (You might be the first person to run Cargo on a clustered
> database - it's good to know that it seems to be working, other than this
> one problem.)
>
> You're right that the MyISAM requirement is only for old database versions
> - the last version of MySQL that had this problem was 5.6, and that version
> came out in 2013, and will stop being supported in a little over a year. I
> could have added a new setting like
> $wgCargoUseMyISAMForTablesWithSearchtextFields, but that seemed like
> overkill, so I decided instead to just remove this code that forces the use
> of MyISAM. Hopefully there aren't too many people who (a) are using Cargo
> with MySQL <= 5.6 (or its MariaDB equivalent), (b) use InnoDB by default,
> (c) use the _pageData or _fileData tables, and (d) will recreate these
> tables in the future. If there are, they'll have to either manually re-add
> this code in, or update to a more recent DB version.
>
> Anyway, if you get the latest version of the Cargo code, and recreate these
> tables, the problems will hopefully be gone.
>
> -Yaron
>
> On Fri, Nov 8, 2019 at 6:52 AM Jan Böhme <jan(a)idea-sketch.com> wrote:
>
> > Hi,
> >
> > for our production system I’m using a MariaDB Galera cluster as RDMS
> > backend. Though there is a feature to enable (experimental) replication
> of
> > MyISAM tables, this doesn't play well with Cargo. Certain operations
> > involving _pageData tables caused the cluster to reach an inconsistent
> data
> > state, thus stopping replication and ultimately falling apart.
> >
> > I could isolate the cause to the following transaction (which is embedded
> > between two inserts for the same thing):
> >
> > BEGIN /* Wikimedia\Rdbms\Database::begin */
> > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE
> > 'cargo\_\_staff\_\_NEXT'
> > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE
> > 'cargo\_\_staff\_\_\_files'
> > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE
> > `_pageID` = '273'
> > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData`
> > WHERE `_pageID` = '273'
> > COMMIT /* Wikimedia\Rdbms\Database::commit */
> >
> > cargo__staff table being InnoDB, cargo___pageData being MyISAM.
> > Unfortunately this leads to the delete statement on the InnoDB table not
> > being replicated, while the delete on the MyISAM table is. Thus on the
> > following insert the row already exists, causing a unique key violation
> and
> > inconsistent cluster state.
> >
> > Is it really still necessary to use MyISAM for these tables? Full text
> > indices are available on InnoDB for quite some time now, so I’m wondering
> > whether this still needs to be supported or if it would be possible to
> make
> > both choices available.
> >
> >
> > Best: Jan.
> >
> >
> > --
> > idea-sketch
> >
> > Jan Böhme & Uwe Schützenmeister
> > Lößnitzstr. 14
> > 01097 Dresden
> >
> > www.idea-sketch.com <http://www.idea-sketch.com/>
> >
> > Tel.: +49 . (0)351 . 810 74 250
> > Mobil: +49 . (0)179 .53 41 641
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> >
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 8 Nov 2019 18:42:37 -0700
> From: Sam Reed <reedy(a)wikimedia.org>
> To: wikitech-l(a)lists.wikimedia.org, mediawiki-l(a)lists.wikimedia.org
> Subject: [MediaWiki-l] GitHub's "Automated Security Fixes" have been
> disabled on the Wikimedia Org
> Message-ID:
> <CAOCnLWYP_A9ugC+q3U=
> mF70mFOhvWygdAea3ewxHdKoMCZEemg(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Just a heads up that "Automated Security Fixes" have been disabled on the
> Wikimedia GitHub org. See [1]
>
> The reason for this is that it generates pull requests on non canonical
> repositories (ie where Gerrit is the default development location) that
> require developers to close them.
>
> If this is a feature you want on your repo generally, because you
> canonically develop on GitHub, you can re-enable these on your repo by
> clicking the "Security" tab, and then selecting "Automated Security Fixes"
> in the top right corner. See [2] for more info. If you do develop
> canonically in GitHub, please let us know at [3].
>
> Note, this doesn't affect the security alerts related to outdated packages
> etc in a repo.
>
> Thanks!
>
>
> Sam
>
> [1] https://phabricator.wikimedia.org/T237337
> [2]
>
> https://help.github.com/en/github/managing-security-vulnerabilities/configu…
> [3] https://phabricator.wikimedia.org/T237470
> [4]
>
> https://help.github.com/en/github/managing-security-vulnerabilities/viewing…
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> ------------------------------
>
> End of MediaWiki-l Digest, Vol 194, Issue 5
> *******************************************
>
Just a heads up that "Automated Security Fixes" have been disabled on the
Wikimedia GitHub org. See [1]
The reason for this is that it generates pull requests on non canonical
repositories (ie where Gerrit is the default development location) that
require developers to close them.
If this is a feature you want on your repo generally, because you
canonically develop on GitHub, you can re-enable these on your repo by
clicking the "Security" tab, and then selecting "Automated Security Fixes"
in the top right corner. See [2] for more info. If you do develop
canonically in GitHub, please let us know at [3].
Note, this doesn't affect the security alerts related to outdated packages
etc in a repo.
Thanks!
Sam
[1] https://phabricator.wikimedia.org/T237337
[2]
https://help.github.com/en/github/managing-security-vulnerabilities/configu…
[3] https://phabricator.wikimedia.org/T237470
[4]
https://help.github.com/en/github/managing-security-vulnerabilities/viewing…
Hi!
We would like to increase the stability of our MediaWiki setup by
running several (identical) instances behind a load balancer.
We are using a PostgreSQL cluster as database, so I am reluctant to set
up a multi-master solution ala $wgLBFactoryConf. Instead I would like to
use $wgSharedDB/$wgSharedTables to have all MW frontends access the same
database and eventually share necessary directories via NFS (coming from
an HA fileserver). The plan is to run the frontends active/passive, i.e.
usually only one frontend will write to the database.
Is this a supported/tested configuration? The warning not to share
certain tables is obvious for wikis with different content, but it is
not clear to me, if there are also problems to be expected if I actually
want to have identical content across all wikis.
If it is possible in principle, are there any other gotchas? E.g.
disabling $wgPHPSessionHandling or something similar?
--
Jörn Clausen
Plattformen & Serverdienste
BITS - Bielefelder IT-Servicezentrum
https://www.uni-bielefeld.de/bits
Hi,
I already asked this on the support desk, as my first try, please excuse the double, but on second thought, i could perhaps reach more people here ?
I am not an admin for any kind of server, computer stuff (starting with linux 10 y ago ) is more or less only a hobby but i might understand some basic language.
We have a tree forum with photo gallery based on a mediawiki installation and started discussing a remodelling of the whole thing. The main issue is mobile usage, since most members want to be able to use their smartphone for anything; and here, the main issue is about uploading photos.
I'm only volunteering to do preliminary research to support the club and their admins who are not so much into computer stuff.
So here is my question: Is there a way to let users upload photos from their smartphone comfortably, e.g. have mobile apps camera do 'send to' -> (mediawiki API) like it is with chat apps ?
Or is there a mobile API which can do this ? i.e. like wikimedia app but freely configurable for other servers and it only needs to do photos.
Any hint appreciated .... Micha