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.
What's the status on meetings in the MediaWiki team?
(no time currently)
Do you know what the bottleneck is? Is it MediaWiki -> syslog-ng or syslog-ng -> graylog?
Wikimedia has been contacted. Waiting on more information from the researcher.
southparkfan@test3:~$ python3 cve.py --url 'https://grafana.miraheze.org' [-] Testing https://grafana.miraheze.org... [-] Status: 200 [-] Checking for version... [-] Grafana version appears to be: 7.4.1 [!] Version seems to indicate it's probably not vulnerable. [-] Checking if snapshot api requires authentiation... [+] Snapshot endpoint doesn't seem to require authentication! Host may be vulnerable.
cc @John as Engineering Manager
We have more storage now, could this be imported over the coming weeks?
Done.
db13
| User | Source of connections | Current TLS specs | Supports TLS 1.3 w/ AES-{128,256}-GCM? |
|---|---|---|---|
| grafana@% | Grafana app (monX) | ? | ? |
| icinga@% | Icinga monitoring agents/scripts (monX) | ? | ? |
| icinga2@% | Icinga master config (monX) | ? | ? |
| icingaweb2@% | Icinga web interface? (monX) | Does not use TLS: puppet says yes, but the config is incorrect (and tcpdump verifies plaintext data) | ? |
| mediawiki@% | MediaWiki app (mwX/testX) | (hack in DatabaseMysqli.php on test2): TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256 | No, TLS 1.3 is PHP 7.4+? |
| phabricator@% | Phabricator app (phabX) | ? | No, TLS 1.3 is PHP 7.4+? |
| piwik@% | Matomo app (monX) | ? | No, TLS 1.3 is PHP 7.4+? |
| replica@% | Database replication (dbbackupX) | ? | MariaDB master: (openssl s_client -starttls mysql) TLS_AES_128_GCM_SHA256 supported, TLS_AES_256_GCM_SHA384 supported. Replica connections unknwon. |
| root@localhost | Root access (mysql client on server) | No TLS (but that's expected) | Is supported (via local mysql client) |
| wikiadmin@% | MediaWiki maintenance & jobrunner (jobrunnerX) | sql.php (jobrunner1): TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 | No, TLS 1.3 is PHP 7.4+? |
| roundcubemail@{2001:41d0:800:1056::9,51.89.160.134} | Roundcube webmail (mailX) | No TLS, has TLS support | No, TLS 1.3 is PHP 7.4+? |
New server is in production, but cp9 needs to be decom'd.
Pending a new database backup server..
With the OK from John, Paladox & Reception: ordering immediately instead of waiting till Feb 1.
Per-server caveats noted at https://etherpad.wikimedia.org/p/Migration_to_new_infrastructure. Copy-pasted here since etherpad's data may be truncated at any time by Wikimedia.
https://stackoverflow.com/a/56457665: "Access-Control-Allow-Origin: * is totally safe to add to any resource, unless that resource contains private data protected by something other than standard credentials. Standard credentials are cookies, HTTP basic auth, and TLS client certificates."
For the record: cloud4/5 will be OVH Advance-2 64GB 2x4TB servers with 12-month commitment.
Approvals Policy: "30.00% or greater: sign-off from budget holder, one Senior Site Reliability Engineer (if applicable), and: at least two, or 50%3of Site Reliability Engineers (rounded up to above), whichever is higher"
As discussed with John & Paladox: https://etherpad.wikimedia.org/p/MH-BudgetingSRE-Jan2021
Users with the userrights-interwiki right can overrule this behavior, though. Unfortunately, rights are not variables that are immutable to people without shell access.
@RhinosF1 do you feel comfortable implementing this?
Per https://www.mediawiki.org/wiki/Manual:Hooks/UserGetRights#Usage, the https://www.mediawiki.org/wiki/Manual:Hooks/UserGetRightsRemove hook is the better choice. We are interested in a MirahezeMagic hook that: