SiteConfiguration::getConfig() uses wfShellExec() to call maintenance/getConfiguration.php. wfShellExec() has a parameter that allows you to pass env vars to the executed process. One way to make this codepath possible again would be to add a guard condition like && !isset( $_ENV['VIA_WFSHELLEXEC'] ) to the cli guard and have SiteConfiguration::getConfig() set that env var.

This idea is not an endorsement of calling maintenance/getConfiguration.php from within a web request in the first place but it looks like someone thought that was a good/ok idea in 1.21 and it was subsequently broken by other attempts to protect maintenance scripts from arbitrary web execution. Maybe requiring that VIA_WFSHELLEXEC has some typically non-public & per farm value would be a good idea too?

Ideally, there would be an API that allows to load configuration of certain wiki without shell-out, but that might require more effort.

In T111441#1605427, @Smalyshev wrote:

Ideally, there would be an API that allows to load configuration of certain wiki without shell-out, but that might require more effort.

I think that might have to wait for the Configuration database 2 RfC or some other system that brings structured and standardized organization to wikifarm configuration. As things stand today, MediaWiki has the SiteConfiguration helper but there is no standard method for how this gets populated or used in the wikifarm's runtime.

I suppose there could be some api action that exported a wiki's configuration data but it would need some sort of tightly controlled authorization mechanism which would then lead to the consuming wiki needing to hold OAuth or other authentication credentials to access the config of a foreign wiki.

I don't mean API as in api.php call, I mean internal API that I could call. Basically, SiteConfiguration without the shell-out and related nastyness. Not sure it it's easy to do though given that everything relies on globals :(

In T111441#1606938, @Smalyshev wrote:

I don't mean API as in api.php call, I mean internal API that I could call. Basically, SiteConfiguration without the shell-out and related nastyness.

*nod* that's what I was thinking of with the Configuration database 2 RfC reference. Things are actually even crazier than the globals for the WMF wikifarm due to all the interesting gymnastics we do in rOMWC Wikimedia - MediaWiki Config.

I don't think shelling out like this is a good idea. $wgConf->get() should generally work on Wikimedia sites though.

Having the web service shelling out to mwscript maintenance/getConfiguration.php eventually caused account creation to stop entirely and have lead to the rollback of 1.28.0-wmf.19.

I am making this a blocker.

So, what's the status/next step here?

For our needs in the cluster, I might suggest defining an internal api endpoint (similar to how /rpc/RunJobs.php is an internal only endpoint) that can take the necessary arguments and output the requested configuration? This wouldn't be particularly hard to do if we only meet the needs of WMF production, defining something more generic might be a more involved task.

Change 396301 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/core@master] Fix maintenance script failure when run as a child of a FastCGI worker

https://gerrit.wikimedia.org/r/396301

Incredible how a single line of rubbish code I wrote in 2004 can have so many people scratching their heads for so long. I hadn't seen this task before today.

Change 396301 merged by jenkins-bot:
[mediawiki/core@master] Fix maintenance script failure when run as a child of a FastCGI worker

https://gerrit.wikimedia.org/r/396301