Hi! I am Southparkfan; co-founder and system administrator for Miraheze. I am responsible for the smooth operation of Miraheze's servers, which includes applying configuration changes, conducting maintenance and incident investigations, performance tuning, monitoring the servers and other miscellaneous tasks.
You can usually find me on IRC in the #miraheze channel on chat.freenode.net.
I find no abnormal metrics regarding cp9, nor do I have any other evidence saying cp9 is constrained by the available resources. Running mtr towards @Dmehus' IP shows some terrible latencies at multiple hops. Since @John has lots of expertise with networking, I'm interested if he could narrow this down to OVH network issues.
With docs now: https://meta.miraheze.org/wiki/Tech:Graylog
I support this request.
Are there any contributions to MediaWiki core or extensions that can serve as evidence they are familiar with the MediaWiki architecture?
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.
Let's keep the extension disabled, following Tim's advice at https://phabricator.wikimedia.org/T257066#6364537. However, a note must be in place.
@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?
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.
While the change was committed, the change has not been applied to existing tables.
@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.
@J-Josyu thank you for the HAR file. That was exactly what I needed.
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.
Certificate purchased. Deployment going on.
Waiting for response from @Paladox regarding nginx changes.
Seems resolved.
Contacted Owen for a data processing agreement for the free infra offers.
@Universal_Omega seems fine to me. Welcome. Do you have MFA enabled on your Phabricator? If so, we'll add you to acl*security_reviewers.
Rate limiting implemented on cache proxies, monitoring now.
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.
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.,
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.
Approved.
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