yes

Approved on a trial basis

Approved

In T247900#5977547, @Matthewrbowker wrote:

In T247900#5977515, @Zppix wrote:

In T247900#5977505, @Matthewrbowker wrote:

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

Why can't a trusted contributor without a wiki cloak be given the same rights as one with one?

Wiki contributors are vetted using OAth, requiring 250 edits, three months service, and no active blocks. I consider that pretty low bar, certainly not something would preclude someone who is hanging in our channels actively to achieve.

And if not, someone with a cloak can bangops. Or go to #wikimedia-ops and ask for help.

In T247900#5977543, @Peachey88 wrote:

Please list what you are proposing, instead of people randomly guessing your intentions.

In T247900#5977532, @Peachey88 wrote:

Are you proposing a username based whitelist, or additional group cloaks to be whitelisted?

In T247900#5977505, @Matthewrbowker wrote:

For the record, I'm against this change. If there's truly an issue, a trusted contributor with a WMF cloak can bangops just as easily. But by whitelisting other networks, it becomes trivial to social engineer enough to begin creating spam. And I know a couple of our bad actors would love that.

Unassigning as this is now a GCI task

I dont know and since ZppixBot doesnt record irc logs (afaik) its hard to tell

Removing GeoLite* from .sopel/ fixed the slow issue, probably should perhaps a cron delete it after x time has passed if the issue reoccurs

@Halfak do you want to us to add ores[04,05,06] to Icinga2?

In T232921#5493535, @Krenair wrote:

https://tools.wmflabs.org/openstack-browser/project/ores does not list them, but does list ores-web0[456], which suggests they were deleted.

(Unassigning as i assigned myself by mistake)

In T225126#5244925, @Aklapper wrote:

The crash is very likely due to which software crashes and should not crash, and it's not MediaWiki that is crashing here.

@Aklapper but in this situation i think the crash is due to MediaWiki.

Not enough details given, and the event is now over.

(Woops accidentally unstalled) I could work on this task though the event is soon to be over, but i will need the ips! @Drarialshogren

Not occurred since the last instance.

Looks like that fixed it :) thanks

I will schedule for deployment as soon as I have a free time during a SWAT window!

@Aklapper enwiki infact does not index user namespace amongst others, see https://en.wikipedia.org/wiki/Wikipedia:Controlling_search_engine_indexing#Namespace_control

I wonder if this task should be higher priority as this is imho a core feature of the bot..

Is there a fix foreseen in the future?

Shouldnt really require discussion on if he should be granted the rights imho

In T220201#5102061, @Bstorm wrote:

@Zppix The project should be good to go in horizon now

Okay then i wont require an floating ip if thats the case.

In T220201#5089542, @bd808 wrote:

The combo of "long term abuse" and wanting a public IP makes me think you are thinking about user tracking in some form. Please do remember to read and consider the https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use. Especially:

• Clearly communicate to End Users a) that Private Information is being collected, b) how you will use it, and c) when you will delete it;
• Get express authorization from the End Users for the collection;

Updated title to reflect that it affects iOS devices as a whole as i can confirm as mentioned before it happens on iPhone aswell