An idea that originates from a recent-ish meeting with @Tchanders is introducing a temporary "IP addresses visible" mode, which would ensure all temporary accounts are resolved to an IP, which can be enabled from time to time (for a specific reason). Conceptually, this would be similar to Phabricator's high-security mode, which removes the need to enter a MFA token every time a sensitive action is taken. If this mode exists, it could help with the logging. It would be more similar to T346809 (except it would still be multipage, just not unlimited over time).

In T358852#9690255, @Tchanders wrote:

Do we need this for Special:DeletedContributions too?

In T351202#9682286, @Dzahn wrote:

In T351202#9678542, @Urbanecm wrote:

@Dzahn: Can you please make a dry-run of syncmembers and share it as a private past on this task, so that I can take a look at the changes it would make?

Done. Please see P59236

We also need to move the list of users from ~urbanecm/config/users.yaml to a better location. Filled T361547 to track that. Also, we should create a more reasonable export path than somewhere in my home. Maybe /srv/exports?

In T351202#9639225, @Dzahn wrote:

Following up on the last comment by Legoktm. I am also in favor of this option and would be happy to make the relevant puppet change to add a systemd timer for this on the lists server.

Could you export the list of stewards/email addresses on the stewards* machines locally and let me know where they are and then I take a look at the rest?

Hi @Dzahn, do you have any thoughts on this, please?

That sounds perfect to me @Dzahn! Thanks for the suggestion.

This was actually done AFAICS. Closing.

Move is in progress.

In T359553#9612508, @Superpes15 wrote:

In T359553#9612388, @sbassett wrote:

Accounts without Phab MFA enabled:

1. @Ajraddatz

Many thanks! I added the 6 members who have 2FA enabled to acl*security_steward and notified Ajraddatz about this :) We let you know when you should check again :D

Should be done now. Sorry it took so long, and thank you for your patience.

Done.

I've performed the removals. According to the last years decision of security team, we just now need to confirm 2FA is enabled as it should be before performing the additions (no extra approval is necessary anymore). Filled T359557 to be able to fully handle the ACL on our end.

Thanks @Msz2001! That was quick :).

Thanks for filling the request. Would it be possible to provide SVG versions for the logos you desire to use? With a SVG file version, we would be able to handle your request in a much easier way.

Move started.

In T320108#9542469, @dcaro wrote:

In T320108#9539081, @Urbanecm wrote:

Thanks @dcaro! I was figuring out how to make this work in k8s instead, and it was just a typo.

The question still stands though: assuming the grid engine is going to go away, how would I keep the tool working there? Or does this qualify for some sort of extension, as you mentioned in your prior message?

We can extend it for up to a month yes, you are clearly working on moving to k8s :), it's a hard limit though.

In T338032#9530131, @Dzahn wrote:

In T338032#9530072, @RoySmith wrote:

Is there some way I can track those zendesk tickets?

I am waiting for a response to the general question whether people outside @wikimedia.org can open ITS tickets. Will let you know soon.

Hi @Trizek @NemoLePoisson, I have good news! It took way longer than originally anticipated, but thanks to the conditional user options project I worked on recently with my WMF staff hat on, this change can now be fulfilled w/o issues, assuming French Wikipedia still wants to go ahead. Please let me know.

Thanks @dcaro! I was figuring out how to make this work in k8s instead, and it was just a typo.

Hi @dcaro, thanks for asking. I'm having troubles with migrating the webservice. I have a mix of Python CGI scripts and generic files to host under the urbanecmbot URL, and for certain reasons (such as, dependency of the Android app on the exact URI), I can't really move the Python part to a different tool and host it via the k8s webservice. I've been using the lighttpd grid service, which allowed the use of Python CGI scripts as well as other scripts, but I can't reach the same effect at k8s.

Thank you for creating this task. My name is Martin Urbanec and I am one of the system administrators responsible for performing site configuration changes. As of now, MediaWiki does not support restricting only the INDEX magic word – such a configuration setting simply does not exist, and as such, it cannot be changed. This means it is only possible to disable both the INDEX and NOINDEX magic words. However, this setting is a per-namespace one, which means we can disallow those magic words in one namespace, but leave them working in another. For more details, please see the docs at MediaWiki.org and documentation for the $wgExemptFromUserRobotsControl configuration setting.

FTR, I'm filling this ticket as a response to a question I received from WMCZ staff. I answered (using my understanding of how Wikistats, AQS and Hadoop work with each other), but I'm filling a ticket anyway, considering I indeed find the selected data visualisation to be very confusing and hard to understand (without reviewing the individual HQL queries).

Done.

Deployed.

As of now, this is not really actionable. From the description and the voting, there is clear consensus on introducing autopatrolled and patroller user groups at skwiki, which can be done. However, it is NOT clear who is supposed to be granting and revoking those groups (by default, it is stewards only, which is likely not intended) .

I (temporarily) "fixed" the issue by disabling the faulty test, but I'd appreciate help with identifying where the actual issue lies and how to fix it.

In T350568#9383011, @Xqt wrote:

@Urbanecm: I wasn't able to exclude Pywikibot-test from User Agent regex Pywikibot/8\.[56].+Python/3\.6 e.g. with (?!test) but get a 504 error. Any idea?

In T350568#9381768, @Xqt wrote:

@Urbanecm: Thank you. Currently I have no glue how can I get access to stat1005 and how to call the python statements you did last year in T312794. Can you lead me for the first steps?

In T350568#9377934, @Xqt wrote:

@Legoktm, @Urbanecm: Could one of you take over this task. Looks like it is too complicated to make it by my own.

In T352224#9365719, @JJMC89 wrote:

Feature summary Allow userrights to be modified by using the API.

There is a disconnect between the task title and the task description feature summary, which is already possible.

@JJMC89 Not really though – userrights right is not available as part of any of the existing grants, so all API clients that authenticate by OAuth or bot passwords cannot call action=userrights and expect the result to be something else than "Permission denied". It is only possible to call the API if you're authenticated using your main password, which is supposed to only happen in your browser (or mobile apps) and as such, it does not support a cron-executed script running somewhere and changing user rights via the API.

FTR, I'm currently working on automating the various MediaWiki accesses (group membership, accounts on private wikis, etc.), but I plan on proceeding with Mailman lists reasonably soon, so I'm filling this task to get the discussion on this started.

In T350834#9327613, @Dzahn wrote:

@Urbanecm As the new group approver for this new group would you approve that guy @Urbanecm?

Stopped the scripts; pasting outputs:

In T315510#9326854, @Urbanecm wrote:

I started the scripts again. After a short while, frwiki was at 8 GiB again, growing fairly quickly. The other two instances are behaving more reasonably so far (884 MiB for enwiki, 218 MiB for rowiki).

I started the scripts again. After a short while, frwiki was at 8 GiB again, growing fairly quickly. The other two instances are behaving more reasonably so far (884 MiB for enwiki, 218 MiB for rowiki).

Done.

In T350834#9319322, @Aklapper wrote:

I'm confused if this is a staff request (@wikimedia.org email address) or a volunteer request (@Urbanecm volunteer Phabricator account requesting this)

In T344164#9317522, @Dzahn wrote:

In T344164#9317520, @Urbanecm wrote:

Will do. Is there some sort of standard/preferred location?

Not really, deploy1002 will do!