[00:25:48] argh [00:32:27] tgrh [00:33:03] (that's what I saw, too) [00:41:45] bd808: I added a ProxyPass rule for thumb_handler.php; 5xxs dropped and everything looks happy. Seems a little too easy. [00:58:51] MaxSem: "On Unix with shell=True, the shell defaults to /bin/sh. If args is a string, the string specifies the command to execute through the shell. This means that the string must be formatted exactly as it would be when typed at the shell prompt. This includes, for example, quoting or backslash escaping filenames with spaces in them. If args is a sequence, the first item specifies the command string, and any additional items will be [00:58:51] treated as additional arguments to the shell itself." [00:58:53] https://docs.python.org/2/library/subprocess.html [00:59:04] in other words, '--family' and the other param were being passed to /bin/sh [09:58:14] subprocess is a bit picky [17:14:01] anomie: any chance you could look into https://phabricator.wikimedia.org/T106850 ? [17:14:15] * anomie looks [17:15:07] I'm pinging jynus on _sec as well [19:57:18] bd808: how to proceed on https://gerrit.wikimedia.org/r/#/c/226666/ ? Just unWIP it and add it to WMF config? or WikimediaEvents? [20:00:33] sounds good to me. config goes in mediawiki-config I think. [20:01:01] hooking to all log topics as a handler might be a bit tricky [20:01:15] s/topics/channels/ [20:02:02] as a processor it would be easier in our current setup, but it can be done either way [20:10:56] hey! can anybody here help me with how recentchanges stuff works? [20:11:36] ori: autoloader stuff too? [20:11:39] SMalyshev: what about it? [20:12:21] Reedy: so what I try to figure out is what happens when you do suppress-delete - where the revision data goes? and what happens when I restore the reveisions then? [20:12:45] Isn't a flag just set on the database row? [20:13:23] Reedy: what I am seeing is that the revisions for this page are not in recentchanges table anymore [20:14:06] All revisions? [20:14:13] Or just hte affected ones? [20:14:16] It'd make sense [20:14:17] instead, I have a record that says "3 revisions restored"... but where are the revisions themselves? I can see them in the UI [20:14:30] but not in recentchanges table [20:15:00] recentchanges is in most cases just transient temporary data [20:15:10] It's probably not crossed someones mind to have it re-added [20:15:36] it's essentially there for performance reasons [20:16:23] yeah but I do see them in "View history" [20:16:32] so where that history comes from? [20:17:30] the revision table directly [20:17:49] ahh. ok [20:18:29] there's a script to rebuild the recentchanges table from the logs and revisions [20:18:32] so history and recentchanges use separate data sources... that explains it [20:19:15] yeah, that'd be the TLDR version :) [20:21:01] and I see that when you do suppress delete, it deletes the page history from recent changes [20:22:02] "3 revisions restored" comes from the log, it does not have anything to do with the revision delete functionality itself [20:24:58] so does anything in the UI use recentchanges at all (except obviously for Special:RecentChanges) or all history etc. is driven by other revision tables? [20:35:18] watchlist, too. [20:38:07] aha, thanks [20:40:58] tgr: I'm trying to setup a trebuchet master in labs and following your instructions. Did you ever see "Passed invalid arguments: 'NoneType' object has no attribute '__getitem__'" from sudo salt-call deploy.deployment_server_init? [20:40:58] The /srv/deployment directories are not being created for me [20:41:18] and pretty obviously I have missed some bit of config [20:42:57] bd808: don't think so... what's the stack trace? [20:43:28] sadly there is no backtrace. just that message [20:48:38] bd808: even if you run it by hand? [20:49:34] tgr: yeah. I'm doing `sudo salt-call deploy.deployment_server_init` [20:49:51] I guess that means this is an error at the other end of the salt call? [20:50:01] strangely /srv/runners/deploy.py doesn't seem to have that method... [20:50:09] don't recall seeing something like that [20:51:25] k. I'll keep digging [20:52:59] it should be in /srv/salt/_modules/deploy.py [20:53:35] ah right. server module not runner [20:53:45] works for me on sentry-deploy [20:54:10] I'm guessing that either __grains__ or __pillar__ is None [21:03:21] tgr: I think my salt master wasn't setup right to be a minion of itself [21:49:19] tgr: I figured out how to get a backtrace at least. The error isn't where I thought it was at all -- https://phabricator.wikimedia.org/P1066 [21:53:24] bd808: maybe you are missing role::deployment::salt_masters::deployment_server ? [21:53:34] that ends up as the redis server IIRC [21:53:57] Well in theory I have it, but -- https://wikitech.wikimedia.org/wiki/Hiera:Logstash [21:54:46] doh! I never enabled role::deployment::server [21:55:26] I added it to the puppet roles list but didn't check it