wiki01/02 and wiki01.stg is fedora 36 which is going eol soon.
Upgrade to fedora 38, the latest mediawiki and upgrade the wiki db.
I'm doing this in staging now.
Metadata Update from @kevin: - Issue assigned to kevin - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, ops
So, I got all the packages we need built into f38-infra:
mediawiki-OpenIDConnectAPI mediawiki-PluggableAuth mediawiki-FedoraBadges mediawiki-RSS mediawiki-Lockdown mediawiki-fedoradocsredirect mediawiki-skin-fedora mediawiki-backtick-code mediawiki-OpenIDConnect php-jumbojett-OpenID-Connect-PHP
And there was a new one (that was retired in fedora: php-rmccue-requests
I reinstalled stg with f38 and got things installed.
The upgrade wouldn't run until I tweaked the config some and disabled the rss extension. ;(
I then ran the upgrade and it finished ok.
But the main page was giving a 500. ;( So, looking at it, it was the Lockdown extension. Upgraded that to the latest version.
Now it's still giving a 500, but it's not clear why.
So, we need to:
Fix whatever is causing the 500 in staging. Figure out how to fix the RSS extension.
ok. The 500 was caused by the Fedora theme. ;(
Commenting out that gets it loaded.
Auth then doesn't work because it doesn't like our scopes...
'scope' => [ 'openid', 'profile', 'email'] # 'https://id.fedoraproject.org/scope/groups', # 'https://id.fedoraproject.org/scope/agreements' ]
gets it working again.
Then we can go on to prod.
Update today:
@ryanlerch I hate to ask, but could you look into the theme? :)
@abompard can you see why those scopes aren't working?
the error is:
[PluggableAuth] ERROR: Jumbojett\OpenIDConnectClientException: Error: invalid_scope Description: unknown scope https://id.fedoraproject.org/scope/groups requested in /usr/share/php/jumbojett/OpenID-Connect-PHP/src/OpenIDConnectClient.php:276
@kevin didnt get a chance today to look at it -- will dive into it tomorrow.
Fixed and pushed a new version of the theme (0.12) and built in f38-infra and installed on staging now.
https://koji.fedoraproject.org/koji/buildinfo?buildID=2201798
I've got a problem: the openQA dispatcher bits can't log into the wiki any more, because it's polluting responses that should be pure JSON with HTML deprecation notices. When I try to log in to the wiki, an API call using this dict as its data:
OrderedDict([('meta', 'userinfo|userinfo'), ('uiprop', 'groups|rights|blockinfo|hasmsg'), ('continue', ''), ('action', 'query'), ('format', 'json')])
returns this response:
<br /> <b>Deprecated</b>: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Cookie/Jar.php</b> on line <b>63</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Cookie_Jar::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Cookie/Jar.php</b> on line <b>73</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Cookie_Jar::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Cookie/Jar.php</b> on line <b>89</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Cookie_Jar::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Cookie/Jar.php</b> on line <b>102</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Cookie/Jar.php</b> on line <b>111</b><br /> <br /> <b>Deprecated</b>: http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated in <b>/usr/share/php/rmccue/Requests/Requests/Transport/cURL.php</b> on line <b>345</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Utility/CaseInsensitiveDictionary.php</b> on line <b>40</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Utility/CaseInsensitiveDictionary.php</b> on line <b>51</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Utility/CaseInsensitiveDictionary.php</b> on line <b>68</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Utility/CaseInsensitiveDictionary.php</b> on line <b>82</b><br /> <br /> <b>Deprecated</b>: Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in <b>/usr/share/php/rmccue/Requests/Requests/Utility/CaseInsensitiveDictionary.php</b> on line <b>91</b><br /> {"batchcomplete":"","query":{"userinfo":{"id":15360,"name":"Coconut","groups":["*","user","autoconfirmed"],"rights":["read","edit","createpage","createtalk","writeapi","viewmywatchlist","editmywatchlist","viewmyprivateinfo","editmyprivateinfo","editmyoptions","autocreateaccount","move","move-subpages","move-rootuserpages","move-categorypages","movefile","upload","reupload","reupload-shared","minoredit","editmyusercss","editmyuserjson","editmyuserjs","editmyuserjsredirect","purge","sendemail","applychangetags","changetags","editcontentmodel","skipcaptcha","autoconfirmed","editsemiprotected"]}}}
Note the actual JSON response that we want is down there at the bottom, but it's preceded by a giant blurb of HTML deprecation warnings. The client library (python-mwclient) is, reasonably, expecting only JSON, so it chokes on JSON wrapped in a giant blob of HTML.
progress on the above: i think we ought to update Requests to 2.0.6, but that in itself is a major change which has consequences. I'm porting mediawiki-OpenIDConnectAPI to the 2.0 interface now and hoping that's all we need. I also filed https://phabricator.wikimedia.org/T336892 because the mediawiki behaviour of including HTML deprecation warnings in a JSON api response seems wrong.
OK, so updating requests to 2.0.6 and porting mediawiki-OpenIDConnectAPI to the new requests API seems to do the trick. Here's the upstream mw-oidcapi PR, my scratch build of requests 2.0.6, and my scratch build of mw-oidcapi. @kevin has deployed these on stg for now, feel free to do whatever cleanup needs to be done (rebuilding them on the infra tag or whatever).
Howver, I've noticed that table formatting has gotten messed up (again, this happened with another mediawiki upgrade in the past and we had to add some styling cue to the table syntax or something). Compare https://stg.fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230517.n.0_Installation and https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230517.n.0_Installation to see what I mean.
OK, I don't think the table issue is just about adding a CSS class like it was before, because it affects even https://stg.fedoraproject.org/wiki/Special:Version - but Wikipedia's https://en.wikipedia.org/wiki/Special:Version looks fine. So I suspect this is somehow caused by Fedora theming, thus it's for @ryanlerch I guess. If we can test disabling the Fedora theme and seeing if that fixes the appearance of tables, it'd confirm.
OK, we tested disabling the Fedora theme and it does fix the tables. So, ball's in @ryanlerch 's court.
The tables issue was due to mediawiki removing the table styles from the core skinning resource pack. It was however easy to add it back with a mediawiki skin feature flag. Updated the theme to version 0.13 that fixes the table styling.
I noticed too that the FPCA checking on stage wasnt working any more.
We are holding the patch to mediawiki-OpenIDConnect in the infra yum repo, and the most recent 6.2-1 build didnt include the patch. so i have updated it to include the patch (https://koji.fedoraproject.org/koji/buildinfo?buildID=2204015) 6.2-2 and now it works.
Yes, I just did scratch builds and nirik deployed them directly. I was leaving it up to him whether to rebuild or tag them into the infra tag.
This is scheduled for tomorrow.
I am just rebuilding those in f38-infra tag. :)
This is completed now with the outage day before yesterday.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.