[00:02:16] [1/3] Hmm. If I specify the Data namespace explicitly, it does exist and come with json by default, but it still doesn't have all the boilerplate pre-filled unlike my local testing environment, so somehow JsonConfig and Chart are not taking over this namespace. [00:02:16] [2/3] https://cdn.discordapp.com/attachments/1006789349498699827/1469483363273281659/image.png?ex=6987d287&is=69868107&hm=a70365eb4d3469bb604f2ef4a718bd85a584e559f18e96a6b39a254169b5d676& [00:02:16] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1469483363730718820/image.png?ex=6987d287&is=69868107&hm=d2c59c50ca4e7ac1ce03e10b05dce2d4a9796fe5e0983215274dadd757a18be4& [00:25:48] [1/4] ^ this is the warning I'm talking about [00:25:48] [2/4] ``` [00:25:49] [3/4] PHP Warning: JsonConfig: Invalid $wgJsonConfigs['Tabular.JsonConfig']: Namespace 486 is already set to handle model 'json' [Called from JsonConfig\JCSingleton::parseConfiguration in /srv/mediawiki/1.45/extensions/JsonConfig/includes/JCSingleton.php at line 138] in /srv/mediawiki/1.45/includes/debug/MWDebug.php on line 485 [00:25:49] [4/4] ``` [00:25:56] namespace 468 is "Data" I believe [01:01:08] [1/4] Hmm that's odd. My original hypothesis is that: [01:01:08] [2/4] Before NS 468 is added to ManageWiki: JsonConfig tries to create NS 468 from its config but the NS gets removed by ManageWiki, resulting in nothing showing up in Special:NamespaceInfo. [01:01:08] [3/4] After NS 468 is added to ManageWiki: the NS does exist but JsonConfig is for some reason failing to take over this NS. [01:01:09] [4/4] From the warning you have shown, it seems that NS 468 already exists before I added it to ManageWiki? [01:01:31] 486 [01:06:15] Oh yeah I'm blind lol [01:16:29] @posix_memalign when testing locally do you set https://github.com/miraheze/mw-config/blob/d0d89066c05f8ee9884365319d5030bb23b5683a/GlobalSettings.php#L637 ? [01:17:00] isLocal = false prevents NS creation it seems looking at code. We have the same setup as the WMF though there. [01:45:09] In my local testing environment I had `'isLocal' => true`. [01:45:27] hmm odd [01:46:11] I figured that we don't want to host charts in commons like the WMF so isLocal => true is the sane choice here. [01:48:20] Yeah. I can look more at this tomorrow if you want. [02:03:18] [1/2] If I mark isLocal as true for both JsonConfig and Chart I get this exception, which is very odd considering the point of isLocal is to disable querying json data stored on commons. [02:03:18] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1469513825693859961/message.txt?ex=6987eee6&is=69869d66&hm=6180f5a039811298f50d93e1d466819966870f16825ef2abfb323341b0a0db7d& [02:34:10] The error is due to `$wgTrackGlobalJsonLinks` which goes away after I disabled it. [02:34:47] [1/2] Yeeeessss! I think having the Data namespace managed by ManageWiki somehow prevents JsonConfig from taking it over. [02:34:47] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1469521747995787390/image.png?ex=6987f647&is=6986a4c7&hm=1e3298cb4e73cb46ac72d96c80b65c68e3db3bbdd96876de663bdbc4d13a8ad7& [02:40:50] Still wrestling with `The page title you have specified does not match any of the patterns configured for the JSONConfig extension for this wiki.` when creating `Data:Chart.chart`, but at least there's some progress. [06:18:12] [1/33] Not making any progress on this. This `Chart.JsonConfig` would not register `.chart` pages with or without the `remote` key, which is its only difference from the other configurations. I guess I'll leave it to CA or my tomorrow self. [06:18:13] [2/33] ```php [06:18:13] [3/33] > $wgJsonConfigs [06:18:13] [4/33] = [ [06:18:14] [5/33] "Tabular.JsonConfig" => [ [06:18:14] [6/33] "namespace" => 486, [06:18:14] [7/33] "nsName" => "Data", [06:18:14] [8/33] "pattern" => "/.\.tab|x$/", [06:18:15] [9/33] "license" => "CC-BY-SA 4.0", [06:18:15] [10/33] "isLocal" => true, [06:18:15] [11/33] "remote" => [ [06:18:16] [12/33] "url" => "https://commons.miraheze.org/w/api.php", [06:18:16] [13/33] ], [06:18:17] [14/33] ], [06:18:17] [15/33] "Chart.JsonConfig" => [ [06:18:18] [16/33] "namespace" => 486, [06:18:18] [17/33] "nsName" => "Data", [06:18:19] [18/33] "pattern" => "/.\.chart$/", [06:18:19] [19/33] "license" => "CC-BY-SA 4.0", [06:18:20] [20/33] "isLocal" => true, [06:18:20] [21/33] ], [06:18:21] [22/33] "Map.JsonConfig" => [ [06:18:21] [23/33] "namespace" => 486, [06:18:22] [24/33] "nsName" => "Data", [06:18:22] [25/33] "pattern" => "/.\.map$/", [06:18:23] [26/33] "license" => "CC-BY-SA 4.0", [06:18:23] [27/33] "isLocal" => true, [06:18:24] [28/33] "remote" => [ [06:18:24] [29/33] "url" => "https://commons.miraheze.org/w/api.php", [06:18:25] [30/33] ], [06:18:25] [31/33] ], [06:18:26] [32/33] ] [06:18:26] [33/33] ``` [06:18:43] Can look tomorrow [07:40:09] [1/8] Just can't step away from this lol. Somehow `$wgJsonConfigModels` doesn't have `Chart.JsonConfig` set, which is probably responsible for the anomalies. [07:40:09] [2/8] ``` [07:40:09] [3/8] > $wgJsonConfigModels [07:40:10] [4/8] = [ [07:40:10] [5/8] "Map.JsonConfig" => "JsonConfig\JCMapDataContent", [07:40:10] [6/8] "Tabular.JsonConfig" => "JsonConfig\JCTabularContent", [07:40:11] [7/8] ] [07:40:11] [8/8] ``` [07:45:13] is `$wgJsonConfigModels['Chart.JsonConfig'] = 'MediaWiki\Extension\Chart\JCChartContent';` set? [07:46:06] https://github.com/wikimedia/operations-mediawiki-config/blob/0eea5710c09e588784665ba547bac8643728799f/wmf-config/CommonSettings.php#L4081 [07:48:02] [1/2] Yeah. It's in https://github.com/miraheze/mw-config/pull/6274/changes#diff-9e954f4a6ba579fb4ddf150f2b43ae3c53679fcb9609463a1ffdd5a1b25d2247R480 [07:48:02] [2/2] I think I figured out why. `wgJsonConfigModels` also appears in LocalSettings.php so that probably overrode the value in GlobalSettings.php. [07:48:17] It does indeed. [07:48:24] If its on $wgConf especially. [07:48:52] I had some issues with SUL3 because of that lol [08:22:26] Yeah moving it out of LocalSettings into GlobalSettings resolved the issue, though it seems that there's some problem with the chart-renderer service. [08:25:19] [1/3] Btw I think this override is unnecessary because FTL Multiverse doesn't even need the JsonConfig extension. All they do is load a json page through Lua with `local jsonData = mw.loadJsonData("Data:WeaponDatabase.map")` in a [module](https://ftlmultiverse.miraheze.org/wiki/Module:WeaponData). [08:25:19] [2/3] I blame the description for the JsonConfig extension `Allows JSON configuration to be stored in a wiki`. That is terribly misleading. It allows JSON configuration _for other extensions_ to be stored in a wiki. There is no point in enabling this extension by itself. [08:25:20] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1469609963189178503/image.png?ex=6988486f&is=6986f6ef&hm=5bf59df0065718a021869d7da7d02707102cb43f0daa86b67aa4a64d0bc0c6bb& [08:30:19] My guess is that they enabled the extension, realized that it didn't allow them to store json data, and jumped through a bunch of hoops on Phorge just so that they can disable the default JsonConfig behavior to have a vanilla json page. [08:40:09] [1/8] After creating a `line-1.json` file, this curl command does result in a chart. [08:40:10] [2/8] ``` [08:40:10] [3/8] curl -H 'Content-Type: application/json' \ [08:40:10] [4/8] -d "@line-1.json" \ [08:40:11] [5/8] -X POST \ [08:40:11] [6/8] http://localhost:6284/v1/chart/render [08:40:11] [7/8] ``` [08:40:11] [8/8] I'm guess MediaWiki is unable to reach `localhost:6284` for some reason. [08:59:53] Is MW proxying it through bast [09:10:47] It is not. I guess that's the issue? Outbound requests should go through bast first even if they are on the same server? [09:12:34] Yes [09:18:35] Is there an example for this? I did a text search inside `mediawiki-staging` and didn't find any mentions of bastion.The only example I know of is `sudo -u {DEPLOYUSER} http_proxy=http://bastion.fsslc.wtnet:8080 composer ...` from mwdeploy. [09:23:46] erm that's a good question [09:25:41] Is MW actually using the proxy would be the first test [09:25:58] Are there errors in the logs @posix_memalign [09:27:52] [1/8] I don't see any in graylog or journalctl for php8.2-fpm. There is a [09:27:53] [2/8] ``` [09:27:53] [3/8] $this->logger->error( [09:27:53] [4/8] 'Chart service request returned error: {error}', [09:27:54] [5/8] [ 'error' => $message ] + $context [09:27:54] [6/8] ); [09:27:54] [7/8] ``` [09:27:55] [8/8] But I'm not sure where this logger writes to. [09:29:00] It should follow standard logging [09:29:10] But what channel is it going to [09:35:58] [1/2] I couldn't figure it out since it doesn't appear anywhere in graylog, journalctl or /var/log/mediawiki, so I just hacked the source code to let it print the error message instead. [09:35:59] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1469627743376244786/image.png?ex=698858fe&is=6987077e&hm=4c0b94a8963baeb50b019585f4411c4eb3db3b769ced90f611ef4326b0f00874& [09:36:52] 403 Forbidden [09:37:06] So chart-renderer is accepting curl connections but not the one from MW [09:37:21] That's good [09:38:01] It should not need to for our own internal servers. [09:38:22] @posix_memalign does curl --proxy http://bast.wikitide.net:8080 ... give a 403? [09:38:32] *bastion [09:38:39] also fsslc.wtnet [09:38:47] [1/11] The default yaml config has this. Not sure what the difference between * and false is. [09:38:48] [2/11] ``` [09:38:48] [3/11] services: [09:38:48] [4/11] - name: chart-service [09:38:48] [5/11] module: ./dist/index.js [09:38:49] [6/11] conf: [09:38:49] [7/11] port: 6284 [09:38:49] [8/11] cors: "*" [09:38:50] [9/11] # to disable use: [09:38:50] [10/11] # cors: false [09:38:50] [11/11] ``` [09:39:04] I refer to Joe the other day in #wikimedia-sre [09:39:53] Sukhe asked why traffic back to Wikimedia goes through url downloader and got 18:57:06 <_joe_> it's one of the most basic tenets of applayer security [09:40:03] Going through bast is a benefit [09:40:12] Going through cf + varnish as well is maybe not [09:40:54] Makes sense. My point is not that we shouldnt but that it should work even if we dont in this case. [09:41:19] I mean no it absolutely should be 403'ing that going through bast [09:41:23] [1/3] Second one results in a 403 it seems [09:41:23] [2/3] https://cdn.discordapp.com/attachments/1006789349498699827/1469629104541401099/image.png?ex=69885a42&is=698708c2&hm=ff21fe4566234bcd760a370b3a00ae8f145487852e2aaddf61c87d5234ec5288& [09:41:24] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1469629104880877618/image.png?ex=69885a42&is=698708c2&hm=b3e05bd38a9bffd2178d471105e9b99c90c6552325f86ae7dcdea45b8647a1b3& [09:41:26] It's a localhost connection [09:41:37] That would be an SSRF vuln if it worked [09:41:54] Your right. I should probably sleep. [09:41:55] If it's going through bast, it needs a proper domain [09:41:57] [1/14] ``` [09:41:57] [2/14] [09:41:58] [3/14]

[09:41:58] [4/14]

Miraheze_Meta ? [20:11:03] Yep! That works, I was just going to the root URL and it wasn't doing what it should [20:14:08] Yeah that’s a bit weed