Re: [Wikitech-l] [MediaWiki-l] Autopromote problems

[Alex Monk]

(CCing wikitech-l)
On 28 February 2015 at 01:04, John Horne  wrote:
>
> $wgAutopromote['sysop'] = array(APCOND_ISIP, '141.163.4.11');
>
Wait, what? MediaWiki supports that?! You should not do that.


> However, when I log in and look at the special user rights management
> page for my own userid, I see that I am in no specific group except for
> the implied group of 'autoconfirmed users' and Administrators. There are
> checkboxes for the Administrators, Bureaucrats and 'editor' groups, but
> none of them are ticked. If I tick a checkbox, and then click save, it
> says the setting has been saved but unchecks the checkbox again.
>
It sounds like UserRights can't reasonably handle groups that are both
implied (e.g. by autopromotion) and actually grant-able to specific users
(where the target user already has implied access?). I'm not entirely
surprised - I'm not sure we officially support that configuration?


> Secondly, and more worryingly, is that if I log in using the
> 141.163.4.11 IP address, and look at the special user rights page, it
> shows everyone as being in the 'Administrators' (sysop) group! If I take
> out the autopromote from the LocalSettings file, then no-one (other than
> the original account created during installation) is shown as being in
> the Administrators group. Very strange.
>
Okay, matching APCOND_ISIP (and APCOND_IPINRANGE) is based on checking
$user->getRequest()->getIP().
But take a look at what User::getRequest does:
https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/User.php;db00239568969a41148cfdec0a77436f73fe802d$3182
So it'll determine every user's eligibility for autopromotion... Using the
current requester's IP. Depending on who requests a page (or indeed, from
which IP), the wiki will have different admins. That's ridiculous.

There probably can't be much more useful behaviour from User::getRequest -
a user doesn't have an assigned IP address, and could have made different
sorts of actions from different IPs (log in, edit, etc.) - you wouldn't
want to autopromote any user account that's ever logged in from that
Plymouth University IP, for example. All we can do is look at the current
requester's IP.
I wonder why we're not just throwing an exception when code tries to call
User::getRequest for a User other than the one making the request... Maybe
we just shouldn't even have a User::getRequest function at all.

Alex.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RfC] AuthManager

[Brad Jorsch (Anomie)]

On Fri, Feb 27, 2015 at 2:38 PM, Tyler Romeo  wrote:

> and give the users' groups from the authorization provider.
>

Note we have no mention of this in the authentication RFC, since we're
being careful to separate *authentication* (authn) from *authorization*
(authz). We have vague plans to rework authz like we're doing authn here,
but we haven't done more than consider that a possibility for a future
project.

Under the current RFC, an extension that does both authn and authz would
presumably have its AuthenticationProvider store information in the session
that would be used later when authz is done (e.g. in the UserGetRights
hook).


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RfC] AuthManager

[Daniel Kinzler]

Hi Legoktm et al!

Thanks for filing the RFC. We have started to track RFCs on Phabricator now - as
I can see, you have already created a ticket. Excellent! I have cross-linked it
from the wiki page now. Since you asked for comments and feedback, I have put
the ticket on the "to discuss" column of our workborad[1].

Please keep the phabricator up to date. I have assigned it to Bryan for now, but
feel free to change that. Actually, when the ticket is under discussion, it
doesn't really need an owner.

We are currently experimenting with the RFC workflow, trying to make it more
flexible. In particular, RFCs no longer *have* to be scheduled for an IRC
descussion to be decided, the ArchCom may just decide them based on the
discussion on Phabricator or the Talk page. If you feel an IRC session would be
useful, please say so in the ticket. Hm, maybe we want a separate column for
that - "IRC queue" or something.

Anyway, if you have comments and ideas about the RFC process (old or new),
please let us now.

Thanks!
Daniel


[1] https://phabricator.wikimedia.org/tag/mediawiki-rfcs/board/
[2] https://phabricator.wikimedia.org/T91105

Am 27.02.2015 um 17:57 schrieb Legoktm:
> Hi!
> 
> Anomie, bd808, CSteipp, and myself have been working on updating Tyler's
> previous AuthStack RfC:
> .
> 
> Our goal is to build an authentication system that is flexible enough to
> support the variety of usecases that MW currently supports and those it
> should support in the future, without requiring tons of hooks or ugly hacks.
> 
> Please leave comments and feedback on the talk page :)
> 
> Thanks!
> -- Legoktm
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RfC] AuthManager

[Bryan Davis]

On Fri, Feb 27, 2015 at 12:38 PM, Tyler Romeo  wrote:
> The primary vision I had with this RFC was to separate the idea of a
> MediaWiki user and an external authentication provider.
>
> In other words, an individual is logging in as a local user, and that
> user may be associated with one or more external "users". Each external
> user is linked via a provider that can authenticate the external user's
> credentials and give the users' groups from the authorization provider.
>
> The reason behind this separation is to allow a bit more abstraction
> between the local authentication layer and the actual verification of
> credentials.

Hopefully we haven't lost that distinction in our revisions. We have
dropped the notion of an ExternalUser class but only as a distinct and
required component. Now each AuthenticationProvider would be
responsible for managing the association of a set of credentials (e.g.
username and password) to a local username. The means by which this
state is managed is left unspecified by the RfC which to us seems
reasonable as it is really an implementation detail of the
AuthenticationProvider. All MediaWiki cares about is that an
AuthenticationRequest can be converted into an AuthenticationResponse
that affirms the provided credentials are valid and indicates the
local User who should be considered the authenticated owner of the
current request.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Moses decoder

[C. Scott Ananian]

I don't know anyting about moses, but I'm always interested in natural
language processing.  Let me know how it goes!
 --scott
​
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Welcome Eric Evans to the WMF Services team

[Rob Lanphier]

Hi everyone,

I'm pleased to welcome Eric Evans as a new engineer in our Services team.
Eric lives and works in San Antonio, TX

Eric's formative years in his current career were at Rackspace, which at
the time he joined (February 2000) was a small 30 person hosting company in
southern Texas. At the beginning of his tenure, he was responsible for
customer-facing sysadmin work. As he progressed with increasing
responsibilities, he eventually led a small team in the architecture and
implementation of a multi-petabyte storage system that would become
Rackspace's Cloud Files offering. By the time he left Rackspace, he was a
core contributor on the Cassandra storage software project, contributing
CQL (Cassandra Query Language) among other things. He also is given
credit/blame for having coined the term "NoSQL".

Eric left Rackspace in 2011, and has since worked in a couple of
Cassandra-related roles, first at a London-based startup (Acunu) where he
honed his remote collaboration skills, and later at The OpenNMS Group,
where he developed Newts, a Cassandra-backed time series data store used as
part of the larger network management stack.

Eric has deep roots in the free software world, and contributes even when
not strictly necessary for his job. He is a longtime contributor to the
Debian Project, where he met our very own Faidon Liambotis, and hence, a
big reason why he's here. He also created Lumens, which is software for
controlling Chrismas light displays.

Eric's first job here is to help get RESTbase ready for production use.
RESTbase is a Cassandra-backed (see a theme yet?) revision caching/storage
architecture which we're initially using to accelerate VisualEditor load
times. Everyone involved is really excited to get someone with Eric's depth
of experience in this area, and looking forward to seeing big things here.

Eric starts working remotely today, and can be found on the
#wikimedia-services IRC channel, using the nick "urandom". He'll also be
visiting our SF office the week of March 9-13.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RfC] AuthManager

[Tyler Romeo]

The primary vision I had with this RFC was to separate the idea of a
MediaWiki user and an external authentication provider.

In other words, an individual is logging in as a local user, and that
user may be associated with one or more external "users". Each external
user is linked via a provider that can authenticate the external user's
credentials and give the users' groups from the authorization provider.

The reason behind this separation is to allow a bit more abstraction
between the local authentication layer and the actual verification of
credentials.

Regards,
-- 
Tyler Romeo

On 2/27/15 08:57, Legoktm wrote:
> Hi!
>
> Anomie, bd808, CSteipp, and myself have been working on updating Tyler's
> previous AuthStack RfC:
> .
>
> Our goal is to build an authentication system that is flexible enough to
> support the variety of usecases that MW currently supports and those it
> should support in the future, without requiring tons of hooks or ugly hacks.
>
> Please leave comments and feedback on the talk page :)
>
> Thanks!
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Moses decoder

[Bahodir Mansurov]

Hello,

I’ve been learning how to use Moses decoder [1] for creating machine 
translation models for the Uzbek language and was wondering if anyone else has 
any experience with. After talking to Amir, we decided to set Moses up in a 
Labs instance. Is anyone else interested in this? How was your experience with 
the decoder?

Thanks,
Baha

[1] https://github.com/moses-smt/mosesdecoder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Language Extension Bundle 2015.02 release

[Kartik Mistry]

Hello all,

I would like to announce the release of MediaWiki Language Extension
Bundle 2015.02. This bundle is compatible with MediaWiki 1.23.8 and
MediaWiki 1.24.1 releases.

* Download: 
https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.02.tar.bz2
* sha256sum: 536cf86e7080d8293a02cb59f99d96328c7009c8239e818556b28b77b02ff88d

Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode

Release notes for each extension are below.

-- Kartik Mistry

== Babel, CLDR, CleanChanges and LocalisationUpdate ==
* Only localisation updates.

== Translate ==
* Improvements in Special:PagePreparation:
** T69591: Added 'Cancel' button.
** T68880: Categories kept as a part of page template.
* T87503: Validate and normalize input file encoding in FFS.
* T54728: Split language details to subpage on Special:SupportedLanguages.
* Performance improvements by removing unneeded queries.
* T53410: Performance improvements in Special:MessageGroupStats and
Special:LanguageStats

== UniversalLanguageSelector ==
* Restore compatibility with IE8. If you still have any issue, please report it!
* Magnifying glass icon is now clickable!
* Localisation updates.

-- 
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [RfC] AuthManager

[Legoktm]

Hi!

Anomie, bd808, CSteipp, and myself have been working on updating Tyler's
previous AuthStack RfC:
.

Our goal is to build an authentication system that is flexible enough to
support the variety of usecases that MW currently supports and those it
should support in the future, without requiring tons of hooks or ugly hacks.

Please leave comments and feedback on the talk page :)

Thanks!
-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: Another labs outage - curse of the accursed hardware failure continues

[Yuvi Panda]

FYI


-- Forwarded message --
From: Yuvi Panda 
Date: Fri, Feb 27, 2015 at 11:42 AM
Subject: Another labs outage - curse of the accursed hardware failure continues
To: Wikimedia Labs 


Hello!

A repeat of the failure that happened a few days ago. Underlying flaky
hardware, andrewbogott is looking into it atm.

== Why is everything so terrible? ==

Labs instances are Virtual Machines that run on physical hardware.
When the underlying hardware dies, the virtual machines on them also
die. This is similar to AWS or other cloud providers. We had one spare
machine (virt1012) in case any of the currently in use machines died
and needed a lifeboat.

A week or so ago one of the machines (virt1005) died, and we migrated
things to virt1012. This week, the new machine, virt1012, has been
having issues, and that's why the outages are all so similar. So the
current instability is basically caused by *two* different
hardware-related issues happening to two different machines with
different configuration.

IT IS A CURSE!

== Making things better? ==

We're adding more hardware. https://phabricator.wikimedia.org/T90783
is the ticket for that.

And specifically for toollabs, it would be awesome for it to be able
to survive one virt* node being down. This is not an easy problem to
solve, but here's the tracking ticket for it:
https://phabricator.wikimedia.org/T90542

Andrew is working through his night (again) to diagnose / fix this
issue (thanks!) and we'll keep you updated as things progress. Thank
you for your patience.

--
Yuvi Panda T
http://yuvi.in/blog


-- 
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l