[14:50:23] https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/ [15:37:14] MW's BcryptPassword class is almost as old as the Wordpress trac ticket heh (2013 vs 2012) [16:04:53] MatmaRex: tgr|away: meh, the file ends up served at https://auth.wikimedia.org/enwiki/.well-known/assetlinks.json instead of https://auth.wikimedia.org/.well-known/assetlinks.json [16:05:11] needs a rewrite condition to exclude this I guess. either that, or some generic "does static file exist" clause [16:05:21] I'll toy a bit on beta [16:05:35] https://en.wiktionary.org/.well-known/assetlinks.json is working at least but not enough on its own [16:07:35] hmm [16:07:57] https://gerrit.wikimedia.org/g/operations/puppet/+/dee235efbbafff1070f9f36ac2b7fa9bed16f7af/hieradata/common/mediawiki.yaml#542 [16:08:04] wait, how come robots.txt works as static file in root [16:08:30] either it should work, or there's a simple fix, let me remind myself [16:10:03] `public_rewrites: false` disables some rewrite rules: https://gerrit.wikimedia.org/g/operations/puppet/+/dee235efbbafff1070f9f36ac2b7fa9bed16f7af/modules/mediawiki/templates/apache/mediawiki-vhost.conf.erb#52 [16:11:19] Krinkle: oh, i think i get it. but it's not that simple D: [16:11:34] MatmaRex: right, so robots.txt works because there is nothing breaking it. it doesn't match the rewrite rule since there's only 1 slash in robots.txt [16:11:38] Krinkle: it's because there's a slash in ".well-known/assetlinks.json", so it matches the rewrite rule that is supposed to match wiki dbnames [16:11:44] yeah :) [16:12:07] so i think there are two ways to fix it [16:12:17] one is to adjust this regex to not match it: https://gerrit.wikimedia.org/g/operations/puppet/+/dee235efbbafff1070f9f36ac2b7fa9bed16f7af/hieradata/common/mediawiki.yaml#554 [16:13:03] another is to list it explicitly in another rewrite rule that goes before that one, something like `RewriteRule ^/\.well-known/assetlinks\.json - [L]` [16:13:22] whats makingn this work then? https://auth.wikimedia.beta.wmflabs.org/static/images/footer/wikimedia-button.svg [16:13:23] (where "-" means "do nothing", and "[L]" means "stop after matching this rule") [16:13:39] there's another rewrite rule for /static/* somewhere [16:13:55] …isn't there? [16:15:35] not that I can see [16:16:52] There is an (unneeded) rule for w/resources/ which makes https://auth.wikimedia.org/enwiki/w/resources/assets/poweredby_mediawiki.svg also work at https://auth.wikimedia.org/w/resources/assets/poweredby_mediawiki.svg although we don't need that per-se, it's fine. [16:17:02] https://gerrit.wikimedia.org/g/operations/puppet/+/6d1a0c77c756a0986e13b0bc040828f7313db646/modules/mediawiki/templates/apache/mediawiki-vhost.conf.erb#64 [16:17:21] I don't see anything for /static since that normally works as-is from the docroot symlink [16:17:31] it'd have to be specific to auth [16:17:44] i'm confused why it works [16:18:51] MatmaRex: https://en.wikipedia.org/w/static/images/footer/wikimedia-button.svg [16:19:13] for some reason there's an old symlink from /w/static -> /static [16:19:31] so it works because it ends up eating it and rewriting to /w/ [16:21:02] anyway, I propose we exclude ^/static/ and /^\.well-known/ with [L] like you say [16:22:37] i'm still confused why the symlink makes thatURL work. but +1 to the idea [16:23:09] the only thing worse than apache config is our way of generating it [16:25:37] and did you know that the template files were reimplemented for kubernetes? i only found that when one of my config changes revealed some bugs in the new version. *shakes fist* [16:25:39] https://gerrit.wikimedia.org/g/operations/puppet/+/6d1a0c77c756a0986e13b0bc040828f7313db646/modules/mediawiki/templates/apache/mediawiki-vhost.conf.erb#52 [16:25:44] https://gerrit.wikimedia.org/g/operations/deployment-charts/+/bfa516e12f24d209c38b9180a31ac41d936ce391/charts/mediawiki/templates/lamp/_site_helpers.tpl#59 [16:25:56] the only thing worse than our way of managing the apache config, is doing it twice [16:28:03] i like the thing you've done with assetlinks, i hope it works [17:23:16] Once mwdebug has a viable k8s version, and beta uses containers, then I imagine the old stuff will be removed, and with it any way to easily contribute/test it in beta. [17:24:23] Well not just beta, but anywhere really. [20:51:39] AaronSchulz: curious what you think about https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1115504. [20:52:43] replacing a `method === 'POST' ? do write : insert job` branch with a check for what the transaction profiler expectation is globally at this moment and deciding based on that. [20:53:22] the task is about trx profiler warnings on API POST-nonwrite requests. [21:23:11] MatmaRex: have you done puppet cherry picks in beta recently? It seems either I've done something silly, or the process to date no longer works. [21:23:14] Left a question in https://wm-bot.wmcloud.org/browser/index.php?start=02%2F17%2F2025&end=02%2F17%2F2025&display=%23wikimedia-sre [21:23:43] Ive got the cherry pick on `root@deployment-puppetserver-1:/srv/git/operations/puppet` but deployment-mediawiki14 keeps running the previous commit there [21:24:29] no error in syslog, it feels like a split brain scenario to me, like maybe there's another puppet server or another directory it is using. [21:24:53] Krinkle: i last tried about a month ago, seemed to work then [21:25:02] Krinkle: there's a deployment-mediawiki13 too [21:25:26] all servers are provisioing themselves with the previous commit [21:34:30] Krinkle: i tried as well. i did `matmarex@deployment-mediawiki13:~$ sudo run-puppet-agent` and it indeed deployed the previous commit. but, then i did `gitpuppet@deployment-puppetserver-1:/srv/git/operations/puppet$ git commit --amend` and that apparenly fixed it. the next run-puppet-agent deployed the new version. [21:34:53] can't explain why, but i guess turning it off and on again worked 🤷‍♂️ [21:35:23] I did a `sudo gitpuppet git rebase` earlier as well in case it had to do with commit hooks triggering or something [21:35:29] but it made no difference [21:35:43] I guess there's other hooks that run on commit --amend that are needed somehow [21:35:50] I created hte cherry pick as root, not gitpuppet [21:36:03] as per https://wikitech.wikimedia.org/wiki/Release_Engineering/Runbook/Puppet_patches#Beta_Cluster_testing [21:36:07] I'll update it to say gitpuppet [21:36:15] there are definitely some hooks, i haven't tried to read them [21:36:21] i followed https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/How_code_is_updated#Cherry-picking_a_patch_from_gerrit when i last did a cherry-pick [21:36:26] I guess that's required to work nowadays, something in the hooks is doing something that previously didn't matter but now matters [21:37:52] https://wikitech.wikimedia.org/w/index.php?diff=2187492&oldid=2187488&title=Nova_Resource:Deployment-prep/How_code_is_updated [21:38:15] i guess tgr knows why that works :) [21:39:54] Thanks! [21:55:01] I added that after running into an issue once where puppet updates failed with some sort of git permission error [21:55:13] I don't remember the symptoms, maybe it was the same thing [21:55:51] Ah that'll have been about git "safe.directory" [21:56:49] It seems there are now some git hooks on that host that must run for puppet to even bother using the commit. Some external state or sync or notifying mechanism, i.e. puppet no longer just uses the check out as-is I guess.