[00:33:07] do we really need wmf-auto-restart these days? [00:43:57] if wmf took being a wiki seriously we'd be able to edit the php of any page live just like any other article [00:44:22] deployments are just copy-pasting the new code into each one [15:37:23] !log wikifunctions Shut down all the instances, not used since we moved to Catalyst. [15:37:25] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikifunctions/SAL [17:08:21] !log integration Created integration-cumin-01 for T433592 [17:08:25] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Integration/SAL [17:08:25] T433592: Re-build integration-cumin.integration.eqiad1.wikimedia.cloud on something newer than bullseye - https://phabricator.wikimedia.org/T433592 [19:28:39] Hello! Is the WMCS admin team aware that one of the Kubernetes worker IP addresses is blocked on frwiki? This prevented my bot from making edits. https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Journal/block&page=Utilisateur%3A172.16.6.4&uselang=en [19:28:57] that's... funny [19:30:11] do we go out with 172.16.0.0 to the public wikis? [19:30:46] not *supposed* to last I heard [19:32:21] I guess anonymous edits are blocked, but it's the IP used from authenticated bots? [19:32:53] The block is labelled ‘open proxy’ and, according to the reply I received from the frwiki administrator on their talk page, this is not an error and some malicious requests may be coming from this IP address. Should I open a task, or is there already a private ticket in place to find out which tool is malicious or vulnerable and is causing the issue? thanks [19:33:12] if there are malicious requests then yes please open a security task [19:35:20] I mean if needed you can just point to the wikipedia page for reserved IP addresses. (172.16.blah isn't assignable) [19:54:52] yeah, 172.16.x.x addresses being visible to the wikis is intentional, https://wikitech.wikimedia.org/wiki/Help:Cloud_VPS_IP_space is a doc page if you need one [19:55:39] there's also a bit of mediawiki configuration that adds a software soft block to those addresses to prevent logged-out editing. I would be very curious to hear why frwiki has decided to block that specifically [19:55:42] ah that's where it was (I was looking for that page but then got bored/distracted) [19:58:50] Huh, the blocking admin sited CU confidentiality as a reason for not being able to give more deets. [19:59:18] (Assuming machine translation isn't misleading me) [22:11:57] !log jeanfred@tools-bastion-15 tools.integraality Deploy a7ad288 (Update all SPARQL unit tests targeting Q41960 to use P10241 instead of P31) [22:11:59] !log jeanfred@tools-bastion-15 tools.integraality Deploy 1cd9f21 (Switch test fixtures from red pandas to lighthouses) [22:11:59] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [22:12:00] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [22:12:01] !log jeanfred@tools-bastion-15 tools.integraality Deploy 59ccbe6 (Refactor: extract _build_drilldown_query helper) [22:12:02] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [22:12:03] !log jeanfred@tools-bastion-15 tools.integraality Deploy ef9b3fc (Wrap drilldown queries in subquery for label resolution) [22:12:04] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.integraality/SAL [22:13:41] perryprog, yes, they wouldn't be able to really say more publicly, even though internal IP addresses aren't exactly what the CU policy is supposed to protect. but they can and should be encouraged to file a security task with more details [22:14:27] ah yeah fair enough; I think my head was still in pre-temp accounts era thinking