[07:41:13] legoktm: when you have some time, can you let me know? I need you for the deployment of cron -> systemd for wikidata dispatcher [08:35:15] Novel amplification technique for DDoS, might be of interest to some people: https://geneva.cs.umd.edu/posts/usenix21-weaponizing-censors/ [08:35:44] Tricks middleboxes configured for web censorship to create the amplified traffic :( [08:37:24] We Have Always Been At War With Middleboxes [08:38:33] "technically infinite amplification" [08:38:44] that sounds like a lot [08:56:03] great paper, thanks! [08:58:58] very clear article, too [09:21:05] thanks! nice read :) [15:56:15] do you guys know how to do an ldapsearch? The way that used to work now turned into: [15:56:20] SASL/DIGEST-MD5 authentication started [15:56:20] Please enter your password: [15:58:05] hm, working normally for me [15:58:10] rzl@mwmaint2002:~$ ldapsearch -x cn=wmf | grep dzahn [15:58:10] member: uid=dzahn,ou=people,dc=wikimedia,dc=org [15:58:13] oh, interesting [15:58:16] why just me :) [15:58:28] rzl: could you search for "tandic" please? [15:58:41] in cn=wmf? not present [15:58:48] just if it exists [15:58:53] I want to add it to nda [15:59:22] exists, uidNumber: 33473 [15:59:24] tandic-ctr [15:59:27] cool, thanks [15:59:35] (uid is just tandic, not tandic-ctr) [15:59:45] ack, but ideally with that email address [15:59:50] yep [15:59:55] :) great, tx [18:39:31] hey bblack [18:39:58] product wants your time and attn on https://phabricator.wikimedia.org/T288938#7284392 [18:40:07] pretty please [20:00:03] if someone is around, looking for a quick review of https://gerrit.wikimedia.org/r/c/operations/puppet/+/713315/ [20:00:19] (varnish patch but pretty simple) [20:04:58] sukhe: ^ reviewed [20:05:42] bblack: thanks! [20:07:54] https://grafana.wikimedia.org/d/000000106/parser-cache?viewPanel=27&orgId=1&from=now-30d&to=now [20:08:01] There's something quite satisfying about that graph :) [20:08:34] the catching up that is [20:08:44] although the fact that it the higher base line has jumped up again is not great [20:09:18] Seems to have been a clear increase from Aug 13-14 aligned with the new branch rolling out [20:10:49] Amir1: ^ there there two changes before Aug 13 midnight when it started: 1) wmf branch to all wikis, and 30min later 2) SpamBlacklist parseroutput change. [20:11:09] I'm thinking if that could lead to a significnat increase in parser cache keys being stored. [20:11:33] the gen_html=false variant perhaps being under a different key? [20:13:33] although it seems Content/getParserOUtput doesn't do any kind of caching not even lazily [20:13:58] but the train did include the earlier change that moved from the core method to the separate parse, but that shouldn't increase cache keys indeed. [20:14:00] weird [20:23:36] Gen html shouldn't cause an increase [20:33:45] Task T288998 [20:33:46] T288998: Significant ParserCache space increase after 2021-08-21 (1.37.0-wmf.18 regression) - https://phabricator.wikimedia.org/T288998 [20:34:17] kormat: marostegui: fyi, and in case any pooling change might have had this as expected effect [20:38:43] https://sal.toolforge.org/production?p=0&q=&d=2021-08-12 [20:38:50] https://www.mediawiki.org/wiki/MediaWiki_1.37/wmf.18