User Details
- User Since
- Oct 26 2015, 4:00 PM (443 w, 2 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- Urbanecm
- LDAP User
- Urbanecm
- MediaWiki User
- Martin Urbanec [ Global Accounts ]
Tue, Apr 23
Problem is now resolved.
Wed, Apr 10
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).
Tue, Apr 9
Mon, Apr 8
[urbanecm@stewards1001 ~]$ cat /etc/steward-onboarder/steward-onboarder.yaml # SPDX-License-Identifier: Apache-2.0 config_paths: roles: /srv/repos/onboarding-system/config/roles.yaml users: /srv/repos/users-db/users.yaml
Sat, Apr 6
Wed, Apr 3
Tue, Apr 2
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?
Hi @Dzahn, do you have any thoughts on this, please?
Mon, Apr 1
That sounds perfect to me @Dzahn! Thanks for the suggestion.
Tue, Mar 26
Mar 23 2024
This was actually done AFAICS. Closing.
Move is in progress.
Mar 21 2024
Mar 18 2024
Should be done now. Sorry it took so long, and thank you for your patience.
Mar 17 2024
Mar 12 2024
Mar 7 2024
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.
Mar 5 2024
Thanks @Msz2001! That was quick :).
Mar 4 2024
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.
Mar 1 2024
Feb 26 2024
Feb 22 2024
Feb 18 2024
Move started.
Feb 16 2024
Feb 14 2024
Feb 13 2024
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.
Jan 30 2024
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.
Jan 20 2024
Jan 19 2024
Jan 12 2024
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).
Jan 2 2024
Done.
Deployed.
Dec 24 2023
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) .
Dec 8 2023
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.
Dec 5 2023
Dec 4 2023
Nov 29 2023
Nov 28 2023
@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.
Nov 27 2023
Nov 14 2023
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.
Nov 13 2023
Stopped the scripts; pasting outputs:
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).
Nov 9 2023
Done.