Run the T142503: Create a maintenance script for populating the local_user_id and global_user_id fields in the centralauth localuser table script in production.
Make sure to list this on the deployment calendar and do a !log command in IRC when it's run.
We'll need to tell the stewards and global renamers to not rename users while this script is running. Let's take a 24 hour window for this and if it takes longer than 24 hours, we'll stop it and resume later.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T66475 Make crosswiki bits and pieces truly global (tracking) | ||
| Open | Feature | None | T5525 Cross-wiki watchlists | ||
| Open | None | T148243 Add indices for local_user_id and global_user_id in production | |||
| Resolved | Niharika | T148242 Fully populate local_user_id and global_user_id fields in production | |||
| Resolved | Niharika | T142503 Create a maintenance script for populating the local_user_id and global_user_id fields in the centralauth localuser table | |||
| Resolved | Marostegui | T141951 Add local_user_id and global_user_id fields to localuser table in centralauth database | |||
| Resolved | Johan | T150835 Notify stewards and global renamers about T148242 |
@kaldari I am fairly sure this script will run at least 3-4 days. I'm thinking of asking for a week long period for stewards and renamers to not rename to be on the safe side.
Added to deployments calendar: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_November_14th
@Johan, I'm thinking of blocking the entire next week (midnight of 20th to midnight of 27th November, UST timings) for no renaming. What do you think?
And just to be very clear: with "midnight of 20th to midnight of 27th November", do you mean 00:00 both these days (start of November 20 to start of November 27) or something else?
I am not sure. There's a config flag for turning off requests but I couldn't find anything that disables renaming itself. @Legoktm @bd808 - would you know if there's a flag for disabling account renaming?
@Johan: It seems just informing them about is good enough. Disabling the feature is not worth the hassle.
Depending on the risk of having a rename in this timespan, an easier form of disabling it is probably by removing the "centralauth-rename" right from the global-renamers and stewards user groups on meta temporarily.
Like Savh said, just revoke the centralauth-rename right from the meta group, and the stewards global group.
Also, could someone explain why we need to turn of global rename during this time period? (Or a link in case I missed it)
Couldn't we just edit https://meta.wikimedia.org/wiki/Template:Globalrenamequeue with a bright red notice to warn renamers not to rename? Someone is going to be seriously trouted if they somehow miss it.
@K6ka: That sounds like a reasonable idea. I don't think there's actually a lot of danger from people being renamed during the script run. I *think* the worst-case scenario is someone being renamed between the select query and the update query in the maintenance script, in which case they just wouldn't get the local id and global id fields populated. But we could also run the maintenance script twice to patch any holes (it only selects users that are missing the data). The hold on renames is mostly just to be extra cautious and avoid any problems.
Okay, it's running on prod now. Latest update:
Updated 100 records. Last user: 15491729; Wiki: angwiki
A few users renamed past the 00:00 November 20 cutoff date.
11:26, 20 November 2016 Steinsplitter (talk | contribs) globally renamed Enviroman~frwiki to Jonathan duchesne (per request)
09:05, 20 November 2016 Steinsplitter (talk | contribs) globally renamed 千野聖広 to Pkdhefy (per request)
06:54, 20 November 2016 Mohamed Ouda (talk | contribs) globally renamed عراف الجبل to يوسف عاشق الجبل (Per :ar:وب:تام)
06:53, 20 November 2016 Mohamed Ouda (talk | contribs) globally renamed Bnikhald to ــــا (Per :ar:وب:تام)
06:45, 20 November 2016 Mohamed Ouda (talk | contribs) globally renamed AsadGhali1110 to AsadGhali0001 (Per :ar:وب:تام)
06:42, 20 November 2016 Mohamed Ouda (talk | contribs) globally renamed Zahraa.k.hameed to AsadGhali2200 (Per :ar:وب:تام)
00:26, 20 November 2016 Jmvkrecords (talk | contribs) globally renamed Manuel Duro Lopes to Manuel Paulino Duro Lopes (per request)
Not sure if this broke any accounts, but it would probably seem that having a big red box wasn't enough to stop people from pressing the button.
There was no warning box at all at Gobal rename queue, etc.
Edit: there was no warning because it hasen't been marked for translation. Thus it was just on the main template but not on /subpages. such as /en etc.
Okay, can we mark it for translation now? I don't know how to do that. @Steinsplitter, @K6ka - anyone?
Curiously, the script flew through the first few wikis but when populating records for arwiki, it was noticeably slow (maybe because arwiki is pretty big?). The script terminated abruptly at the end of it. This was the error:
Updated 46 records. Last user: 48415876; Wiki: arwiki Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information.
I've restarted the script now and it picked from where it began.
Also, I'm surprised $wgShowExceptionDetails isn't true by default on prod.
$wgShowExceptionDetails is not a production setting; it is a local debugging setting. It adds backtrace information to the fatal error page. We should probably trace through the maintenance script and figure out what actually should be logged and how to give information about that on the console.
Change 322606 had a related patch set uploaded (by Dereckson):
Disable centralauth-rename right for maintenance
Hmm, the script is pretty straightforward. I'm guessing the error could be caused by the select or update or getConnection calls failing. Not sure we can do something about those either way.
It encountered the same error once more after completing bxrwiki. It's running fine again now.
Change 322606 merged by jenkins-bot:
Disable centralauth-rename right for maintenance
Mentioned in SAL (#wikimedia-operations) [2016-11-21T06:11:10Z] <legoktm@tin> Synchronized wmf-config/: Disable centralauth-rename right for maintenance (T148242, T151155) (duration: 00m 52s)
FWIW I don't think it's safe to continue running maint scripts in production if they are throwing exceptions and we aren't able to debug them.
@Legoktm, I'm not sure the errors were caused by the script itself. It's running fine now and I'm keeping a close watch on it in any case. If it errors out again, I'll stop it.
Any updates on this? It was mentioned at T151155 that renames will be disabled for longer than the 27th.
Hi @K6ka - the script is expected to run about 2-3 more days. It's covered a lot of the bigger wikis but still needs to populate values for the smaller ones. Sorry for the inconvenience caused.
The script ran up until labswiki and errored out. It won't restart. Here's the last few lines:
All users migrated; Wiki: kywikiquote All users migrated; Wiki: kywiktionary All users migrated; Wiki: labswiki Set $wgShowExceptionDetails = true; in LocalSettings.php to show detailed debugging information.
According to P5436 , Labswiki doesn't have any attached users, which might be a problem? That's the only anomaly with labswiki I could find.
labswiki is the horrible database name for wikitech which is not a SUL wiki. It also has its database on a server that can't be reached from terbium. It shouldn't be in your list of wikis to migrate.
https://gerrit.wikimedia.org/r/#/c/322667/ is meant to Re-enable 'centralauth-rename' rights for when maintenance is done. Has been added to European SWAT E381#3944. However it looks like the script hasn't completed, blocked on labswiki.
Any updates on this? The requests are starting to pile up, and it looks like we have quite the Christmas present this year! (Also, a number of users are querying me asking about the status of their requests)
Change 322667 merged by jenkins-bot:
Re-enable 'centralauth-rename' rights for when maintenance is done
Mentioned in SAL (#wikimedia-operations) [2016-12-06T15:06:31Z] <zfilipin@tin> Synchronized wmf-config/CommonSettings.php: SWAT: [[gerrit:322667|Re-enable centralauth-rename rights for when maintenance is done (T148242 T151155)]] (duration: 00m 43s)
Mentioned in SAL (#wikimedia-operations) [2016-12-06T15:07:25Z] <zfilipin@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:322667|Re-enable centralauth-rename rights for when maintenance is done (T148242 T151155)]] (duration: 00m 43s)
@K6ka: The rename right has been re-activated. Please let me know when the backlog is cleared as we may want to re-disable it for the 2nd script run.
@kaldari The backlog is mostly cleared now, still have some usurpation requests pending at m:SRUC that are scheduled to be processed within the next few days.
Mentioned in SAL (#wikimedia-operations) [2016-12-08T00:38:12Z] <dereckson@tin> Synchronized php-1.29.0-wmf.5/extensions/CentralAuth/maintenance/populateLocalAndGlobalIds.php: [[Gerrit:325733|Improve populateLocalAndGlobalIds maintenance script]] (T148242) (duration: 00m 46s)
We'll start running the script again at 00:00 UTC (in about six hours), and will re-disable the renaming rights.
Change 325997 had a related patch set uploaded (by Kaldari):
Temporarily disable centralauth-rename right
Mentioned in SAL (#wikimedia-operations) [2016-12-16T00:23:39Z] <dereckson@tin> Synchronized wmf-config/InitialiseSettings.php: Reenable centralauth-rename right (T148242) (duration: 00m 49s)