[00:00:39] wow, setting up an nginx fastcgi cache was really easy [01:02:18] uhh, why does MW not directly send a PURGE command to the server listed in $wgCdnServers, and instead uses it as an HTTP forward proxy, sending it a CONNECT command? [01:05:08] ahh, I had to set wgInternalServer [01:23:49] hmm, I worry that setting InternalServer will break things, because I'm not really behind a reverse proxy [02:04:07] https://www.mediawiki.org/wiki/Manual_talk:$wgCdnServers [02:05:09] I would be really grateful if someone with good understanding of MW internals would take a look at this. It seems like a low hanging fruit to make MW support purging the Nginx cache. [02:05:36] I mean, it can already be done, I'm just not sure about possible adverse effects because it requires a hack. [02:16:09] taylan: the tl;dr is that the entire CDN set of variables is assuming an inline caching proxy, because that's how Wikimedia uses it [04:59:47] I am getting this error when running e2e tests in the pipeline, `Error: net::ERR_ABORTED at http://aw-935131.wmcloud.org/w/index.php?title=Z802 at navigate (/src/WikiLambda/node_modules/puppeteer-core/lib/cjs/puppeteer/common/FrameManager.js:155:23)` do anyone know the reason for this error or getting same error in the core? (This got passed [04:59:48] sometime and failed otherwise) [15:58:55] I just realized that the Module namespace was open for *anyone* (even IPs) to edit by default. Isn't that, like, really bad? Why does Scribunto not offer a "Module editors" group or so that you can assign people to? [15:59:34] And what are the security implications of letting people write Lua code? [16:05:13] Scribunto is designed to be pretty much as safe as writing wikitext templates [16:07:21] safer in many respects, because poorly-written wikitext can cause a lot more server load than poorly-written lua (due to CPU/time limit constraints placed upon lua modules) [16:11:38] At least the code is validated to have valid lua syntax to be able to save the edit, in contrast to templates or normal pages [17:12:09] All right then, thanks for reassuring. I was wondering whether I should find a way to list all edits in the Module namespace and audit them to make sure there was no funny business, because I had not realized everyone can edit it. For some reason, I was sure that it must be an admin-only thing. [17:13:25] By the way, if templates / modules are locked down to trusted users only, is there a way to let non-trusted users still experiment with them, so they can have a go at it and show their proposed changes to a trusted editor, who can then decide whether they're good enough at writing template/module code? [17:16:05] I guess what I really want is to protect all *existing* templates/modules (which may be used on many pages so breaking them could wreak havoc), but let non-trusted users create their own template/module that they can play around with and test... [20:47:10] you know what would be REALLY cool? if templates used {$foo} instead of {{{foo}}} q_q [21:02:21] it would be, but alas way too late for that now [21:02:39] or anything to avoid the {{{{{{{{{{{{{{{excessive numbers of curly braces found in templates, really [21:03:45] {{#invoke:...}} for the win :) [21:12:53] bash-PHP syntax is much better than template syntax /s [21:13:32] has `$wgUseInstantCommons` stopped working randomly for anyone? Not sure what has happened, it just stopped working yesterday despite no changes to the code or anything, I've tried using the `$wgForeignFileRepos` instead but that doesn't seem to work either? It just displays as a red link. [21:23:03] `[http] * Error fetching URL: SSL: no alternative certificate subject name matches target host name 'commons.wikimedia.org' [21:23:03] * There was a problem during the HTTP request: 0 Error` hmmmm [21:29:39] sounds like something for a Phabircator task tbh [21:29:52] Phabricator, even [21:30:07] Just wanted to confirm whether this was on WMF's end or mine. I'll file a ticket! [21:42:13] I feel like #wikimedia-tech and #wikimedia-opertations would be lit up if commons was down from a TLS certificate loss at the CDN edge. originalauthorit's error could be a MITM attack of some kind I suppose... [22:41:22] not neccesarily, there are certificate errors that could bother an openssl or gnutls client but not a browser (usually), such as a missing certificate error [22:42:12] originalauthorit: what client are you using to connect? (which php version, with curl extension or not?). OS versión? [22:42:43] from which country is the system connecting? (in order to figure the datacenter it hits) [22:43:57] * Platonides sees it's https://phabricator.wikimedia.org/T342473 [22:45:21] Restarting the entire system seemed to fix the issue, but I'm conscious it could happen again. PHP 7.4.3, yes with curl; and the server is in Germany. [22:45:21] * Restarting the entire system seemed to fix the issue, but I'm conscious it could happen again. PHP 7.4.3, yes with curl; and the server is in Germany. [22:46:38] that makes little sense [22:46:57] an update to ca-certificates that had not been loaded by php, maybe? [22:47:36] from Germany it would see the Digicert certificate [22:48:57] Could you comment this fix on the task? [22:49:20] I'll update the task now, yeah. [23:07:51] originalauthorit: are you on ubuntu by any chance? [23:09:05] if so you were likely hit by https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2028170 [23:09:24] Yeah