Ask Release Engineering team to help us update our PhotoDNA keys. The configuration to update is MediaModerationPhotoDNASubscriptionKey (as seen in extension.json in MediaModeration extension).
Description
Event Timeline
fair warning and FYI, this is going to take some time, as there is some difficulty in finding step-by-step instructions...
references
https://gitlab.wikimedia.org/repos/releng/scap/-/blob/master/RELEASE.md
https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment#Change_wiki_configuration
https://wikitech.wikimedia.org/wiki/Configuration_files
https://www.mediawiki.org/w/index.php?title=Manual:Writing_maintenance_scripts&useskin=vector-2022
https://wikitech.wikimedia.org/wiki/Scap#All-script
https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment?useskin=vector-2022#Run_a_maintenance_script_on_a_wiki
So far the best documentation I can find on that subject is here: https://doc.wikimedia.org/releng/scap/scap3/quickstart/setup.html. Let me know if that does or does not get you anywhere.
It sounds like you want to edit /srv/mediawiki-staging/private/PrivateSettings.php on deployment.eqiad.wmnet ? scap would come into play to actually deploy the changed file to all mediawiki servers. (edited)
yes, we need to update an api key for PhotoDNA (checks for CSE on images), the actual script that uses the key is run in mwmaint1002 and mwmaint2002 via an extension MediaModeration
Log into deployment.eqiad.wmnet and edit PrivateSettings.php as needed. Make sure to commit the changes (/srv/mediawiki-staging/private is a separate local git repo).
After that, to deploy the change, you can run scap sync-world <some string describing why you're running the sync> For example scap sync-world Updated PhotoDNA api key (Ideally referencing a ticket) (edited)
Beginning to find things out:
Is there anyone who is able to explain what a scap file looks like, and where it should be in the local repo? Have read:
https://wikitech.wikimedia.org/wiki/Scap all the links off that page and several others including https://wikitech.wikimedia.org/wiki/Scap#All-script
https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment?useskin=vector-2022#Run_a_maintenance_script_on_a_wiki
Thanks in advance & happy Friday
Hi, you may want to reach out to release engineering for help with this cc
So far the best documentation I can find on that subject is here: https://doc.wikimedia.org/releng/scap/scap3/quickstart/setup.html. Let me know if that does or does not get you anywhere.
I'd like to take a step back: what are we deploying with scap3 nowadays? I think the tool is on the way out and new projects should be deployed to Kubernetes
There's only one service in production that still uses scap3 - restbase. It's also used for some infrastructural software distribution, but if you're creating a service that should run in production, it should be deployed to Kubernetes
While the code lives as an extension that pretty much runs as a service which probably should have been developed as a script to run on a Cron job IMHO.
So for sure in that case you don't need a scap file
Point me to some docs about this service?
Code for that extension is deployed with the rest of the MediaWiki code and you don't need a scap file
gerrit.wikimedia.orggerrit.wikimedia.org
Gerrit Code Review
The goal is to run a maintenance script periodically.
the original code base has been around for a while (before my time) and it seems the folks most aware of the code have moved on - it is a script that checks for Child Sexual Images via calling PhotoDNA API. It pulls images from the database(s) based on requirements. It has been run arbitrarily - and one day it died and hasn't been run for probably over a year.
Ok, so right now it's just mediawiki code you want to get to mwmaint to run it there by hand, I guess, given you need to give it a Kafka offset you need to find by hand (from the README)
if you want to make it a proper service that is not run by hand, we can explore options. But I'd ask you to open a phabricator task and to tag "serviceops" describing what you'd like to have
What do you want to do? run the maintenance script once or do you want it to be executed automatically and periodically?
1 - the script needs to work
2 - it would be nice if I could get it to that point of running automagically
3 - due to legal rulings we need to get this running correctly asap
4 - I hope we can make time to just change it to a stand-alone script, I don't understand the logic of using an extension for this, exp. since it cannot be released into the wild due to limits on the number of images that may be processed.
So a standalone script outside of MediaWiki, you mean?
That would require some work, I would rather focus on 1 and 2 in your list, given point 3 If you want to interact quickly, you can use the backport windows to deploy your changes to mediawiki
yep, so that is where I am, the code 'should' run with changes made but still need to get the key into the code base and that is what I am struggling with
You have a config variable for that key
You need to ask for it to be added to the private Mediawiki repository in production
IIRC anyone with deployment rights should be able to do that, but I'd check with release engineering on this
posted to slack channel #engineering-enablement
1:51 PM 5 July 2023
Ellen Rayfield Hi folks, I am unsure of the process, but y'all have been recommended as a resource. I need to update the MediaModeration PhotoDNA key, it may also be named Ocp-Apim-Subscription-Key. Believe the location is PrivateSettings.php - if this isn't clear enough please slack me and I'll try to provide answers. Thanks!
UPDATED POST:
Hi folks, I am not sure of the process, but y'all have been recommended as a resource. I need to update the MediaModerationPhotoDNASubscriptionKey The configuration to update is MediaModerationPhotoDNASubscriptionKey (as seen in extension.json in MediaModeration extension). Believe the location is PrivateSettings.php - if this isn't clear enough please slack me and I'll try to provide answers. Thanks! (edited)
that value is in PirvateSettings.php on the deployment host
and as far as I know, it's only maintained directly on the deployment box, so we'd probably make the change and deploy it directly (rather than have it in Gerrit)
IIRC anyone with deployment rights should be able to do that, but I'd check with release engineering on this
yeah, the only thing I'm unsure about is if we use DOLOGMSGNOLOG anymore.
The steps are:
- Write the patch (ensure it lints)
- Apply in beta (if applicable) + deploy
- Apply the patch directly on the deployment server
- Deploy the patch
Unsure if there's anything special other than that.
And anyone with deployment rights can indeed do that.
the credentials are indeed manually edited and there is almost no stopgap to the next step: bring down all the wikis.
Scap should run php -l for you, but maybe it does not run it against private settings :D
The way to cover is:
to code review / double-check with someone else since usually, four eyes are better.
stop and ask (aka this thread)
test locally / on the debug hosts before syncing the code everywhere
And if something goes wrong:
make noise, and ask for help very loudly.
Don't hide your traces and be very honest about anything
rollback the code or get someone to rollback
celebrate the wikis being back up
Panic
Ask for a "I broke Wikipedia" T-Shirt
Happy training!
Documentation on how to deploy
https://wikitech.wikimedia.org/w/index.php?title=How_to_deploy_code&diff=2090931&oldid=2065655 (edited)
ah ha! "Deployments via scap should use the --no-log-message option flag and include minimal, benign log messages." was the piece I was missing.
$wgMediaModerationPhotoDNASubscriptionKey has been deployed -
- $wgMediaModerationPhotoDNASubscriptionKey
- $wgMediaModerationRecipientList
- $wgMediaModerationFrom
- $wgMediaModerationHttpProxy
- $wgMediaModerationCheckOnUpload = false;
Thanks for flagging that.
We should set $wgMediaModerationCheckOnUpload in the main (public) settings file. But, no need to do that now, we can deal with that later if/when we decide to change the value.
$wgMediaModerationFrom and $wgMediaModerationHttpProxy also don't seem like they'd have sensitive values, and could be set in the public InitialiseSettings file.