Sun, Nov 22
With docs now: https://meta.miraheze.org/wiki/Tech:Graylog
Sat, Nov 21
Sun, Nov 15
I support this request.
Sun, Nov 8
Are there any contributions to MediaWiki core or extensions that can serve as evidence they are familiar with the MediaWiki architecture?
Oct 24 2020
Hi @SamanthaNguyen, welcome! Good to see interest for this position.
I was deploying the ALTERs to the wikis while RottenLinks was disabled (the ALTERs cannot be done live using pt-osc, unfortunately), but I forgot to re-enable RottenLinks. For now, I have enabled RottenLinks. The extension only needs to be disabled again (and the update scripts killed) if you are deploying the schema changes on databases.
Oct 18 2020
Let's keep the extension disabled, following Tim's advice at https://phabricator.wikimedia.org/T257066#6364537. However, a note must be in place.
Oct 13 2020
@John it doesn't look like larger VARCHARs are possible. Even if you don't use the rl_id field, it does seem to be working fine at first glance, without fundamentally changing the schema (the current, old fields can stay). What do you think?
Oct 10 2020
02:56:34 <+SPF|Cloud> JohnLewis: db7 doesn't seem to accept a varchar(8192) for rl_externallink 02:56:38 <+SPF|Cloud> ERROR 1071 (42000): Specified key was too long; max key length is 3072 bytes 03:01:39 <+SPF|Cloud> looking at https://mariadb.com/kb/en/innodb-system-variables/#innodb_large_prefix and https://mariadb.com/kb/en/innodb-large_prefix-deprecated-resulting-key-length/, relying on such huge varchars for index keys seems deprecated 03:09:42 <+SPF|Cloud> I don't think having the varchars as primary key is a good idea, given the deprecation comments. What do you think?
@Cyberpower678 sending 45 requests per second is still a lot. Remember this is a multi-tenant environment with few spare resources. However, if you can give me a combination of source IP and User-Agent to exempt for the rate limit temporarily, I can see how much issues are actually caused in production by the bot. I'm curious.
Oct 9 2020
While the change was committed, the change has not been applied to existing tables.
Oct 8 2020
@Cyberpower678 I can confirm on cp9 (cache proxy) traffic from IABot is being rate limited. However, sending over 40 requests per second (on average) to api.php (and thus requests that bypass the cache, and have to be served by the MediaWiki cluster) is in most cases not acceptable at all. We only send about 70 requests per second to the MediaWiki cluster.
Oct 4 2020
@J-Josyu thank you for the HAR file. That was exactly what I needed.
Oct 3 2020
Sure, I'm bad, but which one isn't sincere? Of course, the bad thing is the "volunteers" who don't solve the problem.If you call yourself a volunteer, do what you do.
I see multiple volunteers were involved in fixing a part of this issue and trying to reproduce your other issues. Your attitude does not help solving this task. Please read http://meta.miraheze.org/wiki/Code_of_Conduct and stay civil. Thanks.
Permanent fixes have been implemented for this issue, closing the task. If you still have issues, please reopen this task.
Oct 1 2020
- cache proxies (varnish)
- mediawiki nginx
- ldap server
- icinga nginx
- mariadb <- careful!
- mw services
- matomo nginx
- roundcubemail nginx
- grafana nginx
- gluster clients: mediawiki
Certificate purchased. Deployment going on.
Sep 20 2020
Waiting for response from @Paladox regarding nginx changes.
Contacted Owen for a data processing agreement for the free infra offers.
Sep 16 2020
Aug 24 2020
Aug 20 2020
Rate limiting implemented on cache proxies, monitoring now.
Aug 19 2020
Good to see interest in this job! I would recommend doing an actual security review of a pending extension, using the checklist from https://www.mediawiki.org/wiki/Security_checklist_for_developers. Note the good (e.g. CSRF tokens used, code being compliant with MediaWiki's standards and thus making the review much easier) and bad points (e.g. a lot of htmlspecialchars usage within echo statements, instead of using the Html functions) of the extension's code, security risks you find (e.g. accessing external resources, thus introducing DoS possibilities, passing user input directly into shell commands). Especially for a somewhat larger extension, that gives me an idea about your review capabilities. If I think you are capable of doing security reviews for real, you may be grant permission to approve extensions without being in a SRE position or similar.
Aug 13 2020
Aug 7 2020
https://wiki.kali-team.cn/ works now.
@Exile I can't reproduce this, the wiki works fine with me with that URL. Please let us know if you still experience issues.
tl.awiki.org works now.
@Zppix and this is a security-sensitive task because...?
(and what are the concrete actions here?)
The only relevant CVE here is the SecureBoot one, which doesn't matter at Miraheze (due to our configuration). Making the task public now. I don't see other fixes important for us either, don't see the need for quickly upgrading (which requires reboots of cloud servers as well).
Not observing now, monitoring phase for now.,
Aug 6 2020
Jul 30 2020
Nimbus approved, Aether not sure about one thing (P340). Discourse is declined since it's not maintained and I have some doubts about certain strategies used for the skin templating.
Looks fine to me as well. Approved.
@Paladox, what was the reason this extension was declined as 'hard/impossible to install'?
Give me a few days to think about it.
One potential finding: https://phabricator.miraheze.org/P339
The bundled version of TinyMCE has various vulnerabilities: https://snyk.io/test/npm/tinymce/4.6.4