[00:14:11] !log tools.meetbot https://meetbot.toolforge.org/ says 503, No webservice. `webservice status` says "Your webservice of type php7.3 is running on backend kubernetes". Do a restart. [00:14:13] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.meetbot/SAL [00:15:23] > /data/project/meetbot/bin/meetbot: line 4: [[stretch: command not found [00:15:23] > IOError: [Errno 13] Permission denied: '/data/project/meetbot/wm-labs-meetbot.conf' [00:15:23] > ERROR 2020-10-14T16:57:16 Exception id: 0xda836 [00:17:15] * Krinkle adds quotes [00:20:02] actualy, I dont' think that's related to the webservice [00:20:17] why won't the simple static+php server serve the directory? [00:20:54] 2020-10-16 00:18:13: (server.c.1464) server started (lighttpd/1.4.53) [00:20:56] seems fine [00:23:41] https://gerrit.wikimedia.org/r/c/operations/puppet/+/606824 ? [01:59:40] hello! is it possible to force connection to specific replica host (not shard), e.g. labsdb1009? this is for https://sql-optimizer.toolforge.org/ which needs to have two connections to the same exact machine in order to work [02:00:42] I think Bryan was looking at that this week. I don't think there was any specific answer though [02:01:54] hmm okay. It used to work reliably connecting to s1.web.db.svc.eqiad.wmflabs, but sometime recently that rotates between labsdb1009 and labsdb1010 a lot [02:01:59] https://phabricator.wikimedia.org/T265430 [02:02:28] I thought there was a ticket :) [02:02:33] ah beautiful, thank you. Subscribed [09:01:16] !log admin [codfw1dev] basic network connectivity seems stable after cleaning up everything related to address scopes (T261724) [09:01:19] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [09:01:19] T261724: cloudgw: evaluate / validate setup in codfw1dev - https://phabricator.wikimedia.org/T261724 [09:18:19] !log admin [codfw1dev] live-hacked cloudservices2002-dev /etc/powerdns/recursor.conf file to include cloud-codfw1dev-floating CIDR (185.15.57.0/29) while https://gerrit.wikimedia.org/r/c/operations/puppet/+/634050 is in review, so VMs with a floating IP can query the DNS recursor (T261724) [09:18:23] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [09:18:23] T261724: cloudgw: evaluate / validate setup in codfw1dev - https://phabricator.wikimedia.org/T261724 [09:25:21] !log admin [codfw1dev] hard-rebooting bastion-codfw1dev-02, seems in bad shape, doesn't even wake up in the virsh console [09:25:23] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [09:29:58] !log admin [codfw1dev] still some DNS weirdness, investigating [09:30:00] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL [18:54:15] !log tools.sge-status restarting webservice to try and clear a mysterious 404 [18:54:17] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.sge-status/SAL [19:15:13] !log tools.sge-status Fixed rewrite path in $HOME/.lighttpd.conf to work with sge-status.toolforge.org [19:15:15] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.sge-status/SAL [19:36:35] wonder if anyone’s online who could give me some tool security advice? (or walk me through some anxiety / paranoia lol) [19:36:44] currently, most of my tools reset the CSRF token each time they get a POST [19:37:09] this should limit the impact even if an attacker manages to steal a CSRF token, which I quite like [19:37:36] on the other hand, it means people can’t open multiple instances of the tool in separate tabs, and submit them all, because the first tab to submit will invalidate the CSRF token of the other tabs [19:37:58] so I’m not sure if I should be more lenient and leave the CSRF tokens valid for longer, or what the impact of this on security would be [19:38:28] (in some tools, notably Wikidata Lexeme Forms, I try to handle the CSRF error gracefully and send back the form with the data pre-filled so the user can immediately resubmit, but it’s still annoying) [19:46:50] lucaswerkmeister: MediaWiki lets CSRF tokens be valid for the length of your session, so I think that's fine [19:48:10] I don't know how much it matters to guard against CSRF tokens being stolen [19:48:32] yeah, MediaWiki’s long-lived tokens are the main counterargument I can think of [19:49:14] I guess you could argue that, if the attacker can steal one CSRF token, chances are they can steal as many as they need? but that doesn’t feel comforting :D [19:49:19] heh [19:49:41] also, MediaWiki's JS layer automatically retries when tokens are invalid, which helps the UX [19:49:57] which could happen if you leave a browser tab open for days or something [19:51:43] if you're relying on normal
posting, you could have JS check the token's validity, refreshing it if necessary, and then submitting the form with the new token. But that all seems overkill compared to just making tokens live longer [19:53:24] yeah, fair enough [19:54:08] then I think I’ll make the tokens live longer, and if anyone finds an issue and isn’t malicious, they can let me know :) [19:54:12] thanks! [19:55:43] :)