What's the status on meetings in the MediaWiki team?

(no time currently)

In T6765#134610, @John wrote:

If restarting the service is required to pick up changes, databases.json and *wiki.json can't be cached

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.

• The API endpoint is open
• Our Grafana version is on a patched version
• Only impact on A, not C/I, Grafana is not critical

cc @John as Engineering Manager

@Paladox: see P381. Ideally, you turn the vmtouch (daemon) into a systemd service (a type of unit) that will run this script on every puppet run, after which you can restart the systemd service (to pick up new files).

We have more storage now, could this be imported over the coming weeks?

Done.

db13

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"

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

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:

1. checks if the user has read rights, either by global or local rights; and
2. 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
3. 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:

1. checks if the user has read rights, either by global or local rights; and
2. 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
3. revokes the read right if the user did not pass the check from 2).