What's the status on meetings in the MediaWiki team?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
(no time currently)
Thu, Feb 25
In T6765#134610, @John wrote:If restarting the service is required to pick up changes, databases.json and *wiki.json can't be cached
Wed, Feb 24
Wed, Feb 17
Do you know what the bottleneck is? Is it MediaWiki -> syslog-ng or syslog-ng -> graylog?
Sun, Feb 14
Wikimedia has been contacted. Waiting on more information from the researcher.
- The API endpoint is open
- Our Grafana version is on a patched version
- Only impact on A, not C/I, Grafana is not critical
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.
Sat, Feb 13
Fri, Feb 12
Tue, Feb 9
Mon, Feb 8
cc @John as Engineering Manager
We have more storage now, could this be imported over the coming weeks?
Sun, Feb 7
Tue, Feb 2
Mon, Feb 1
Done.
Sun, Jan 31
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) | ? | ? |
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..
Sat, Jan 30
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.
Fri, Jan 29
Thu, Jan 28
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"
Current infra costs (incl VAT)
cloud1 (OVH CA): $73.74/mo = ~£53.70/mo
cloud2 (OVH CA): $73.74/mo = ~£53.70/mo
cloud3 (OVH CA): $113.99/mo = ~£83.02/mo
cp9 (OVH CA): $6.00/mo= ~£4.37/mo
bacula2 (RN): $18/mo = ~£13.11/mo
dbbackup1 (RN): $24/mo = ~£17.48/mo
ns1 (RN): $16.20/yr = $1.35/mo = ~£0.99/mo
Total: $309.47/mo = ~£225.39/mo
Jan 24 2021
In T6756#133156, @John wrote:In T6756#133140, @Southparkfan wrote: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:
- checks if the user has read rights, either by global or local rights; and
- verifies the user by looking at an immutable key (immutable unless you have shell access), so the centralauth user ID is good enough (whereas a username isn't, since a steward can rename a user); and
- revokes the read right if the user did not pass the check from 2).
A much easier step 2 would be to check for a local user group assigned to the user, if that's not met, remove 'read'.
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:
- checks if the user has read rights, either by global or local rights; and
- verifies the user by looking at an immutable key (immutable unless you have shell access), so the centralauth user ID is good enough (whereas a username isn't, since a steward can rename a user); and
- revokes the read right if the user did not pass the check from 2).