[00:02:12] <ori-l>	 jeremyb: like, the natural number? what else would come between 3758 and 3760?
[00:02:34] <ori-l>	 jeremyb: if you're referring to a ticketing or patch management system, you'll have to specify which :P
[00:08:18] <jeremyb>	 ori-l: rt
[00:08:23] <jeremyb>	 no battery remaining
[00:08:26] * jeremyb  runs away

[00:24:11] <ori-l>	 jeremyb: I marked it resolved; thanks.
[00:33:56] <kaldari>	 Anybody on here know about RevisionDeletion? Specifically how do you use Special:RevisionDelete? I have my local permissions set so that I should be able to use it, but when I go to the special page, it just says "Invalid target revision". The docs on MediaWiki.org are no help whatsoever :(
[00:37:55] <legoktm>	 kaldari: go to a page history
[00:37:59] <legoktm>	 check some checkboxes
[00:38:07] <legoktm>	 and then hit hide/show revisions (or something like that)
[00:38:55] <kaldari>	 I don't see any 'hide/show' :(
[00:39:06] <legoktm>	 oh it sas
[00:39:17] <legoktm>	 del/undel selected revisions
[00:39:19] <legoktm>	 says*
[00:39:24] <kaldari>	 I don't see those either :(
[00:39:37] <kaldari>	 I set the following in my LocalSettings.php:
[00:39:38] <kaldari>	 $wgGroupPermissions['sysop']['deleterevision'] = true;
[00:39:38] <kaldari>	 $wgGroupPermissions['sysop']['deletelogentry'] = true;
[00:39:44] <kaldari>	 and am logged in as a sysop
[00:39:52] <kaldari>	 do I need to do anything else?
[00:39:55] <legoktm>	 https://en.wikipedia.org/wiki/Wikipedia:REVDEL#Technical_details
[00:40:00] <legoktm>	 i wonder if enwiki changed the messages.
[00:41:07] <legoktm>	 "Change visibility of selected revisions" <-- kaldari thats the default message
[00:41:43] <kaldari>	 ah, I see it!
[00:42:23] <kaldari>	 The screenshots at https://www.mediawiki.org/wiki/Help:RevisionDelete and https://www.mediawiki.org/wiki/Manual:RevisionDelete must be outdated
[00:42:37] <kaldari>	 I was looking for links in the log entries themselves
[00:42:56] <legoktm>	 log entries have links i think.
[00:43:28] <legoktm>	 no, checkboxes.
[00:43:46] <legoktm>	 yeah, those look pretty outdated.
[00:43:55] <kaldari>	 legoktm: Anyway, thanks!
[00:44:02] <legoktm>	 np :)
[02:00:45] <kaldari>	 legoktm: I rewrote much of the documentation and replaced the ancient screenshot with a new one: https://www.mediawiki.org/wiki/Manual:RevisionDelete
[02:01:40] <kaldari>	 someone should give me a barnstar :)
[02:02:02] <p858snake|l>	 mediawiki wiki doesn't have barnstars >.>
[02:02:20] <kaldari>	 The 'I can't believe you actually wrote documentation' Barnstar
[02:02:24] <legoktm>	 oh that is awesome :D
[02:02:27] <p858snake|l>	 i'm sure someone in the office can give you a gold sticker or something
[02:02:30] * legoktm  throws wikilove at kaldari 

[02:02:42] <kaldari>	 yay, I love gold stickers
[02:14:18] <jeremyb>	 hrmmmmmm, gold barnstar?
[02:14:24] <jeremyb>	 i wonder how much that would cost
[02:14:30] <jeremyb>	 we could do 14kt
[06:11:40] <Nemo_bis>	 jeremyb: well, gold has fallen so much :P (500 G€ losses for central banks I'm told)
[07:56:28] <matanya_>	 paravoid: i'm getting 502 Bad Gateway nginx/1.1.19 when trying to load wikipedia
[08:26:03] <Nemo_bis>	 matanya_: are you having huge packet loss to bits too? 50 % for me on gw-wikimedia.init7.net
[08:26:17] <matanya_>	 yes, seems so
[08:26:58] <Nemo_bis>	 mark_____ changed some routing the other day, dunno if related
[08:27:24] <matanya_>	 ping some ops from -operations :)
[08:29:08] <matanya_>	 e.g. mutante ...
[08:30:40] <mutante>	 matanya_: sorry, i don't know about routing changes, if you think it's serious and networking we should probably call mark
[08:30:55] * mark_____  has a look

[08:31:00] <mutante>	 WP works for me though
[08:31:03] <mutante>	 ah, thanks
[08:31:22] <Kelson>	 jeremyb: no yet :)
[08:31:28] <matanya_>	 it does, but not a reliable manner. thanks mark_____ 
[08:33:31] <mark>	 so whoever sees problems, can you please post traceroute output? :)
[08:37:36] <mark>	 i'm not seeing any issues at the moment
[08:43:49] <Nemo_bis>	 mark: http://p.defau.lt/?1_2YRrCApGKVhW_KuoLEVQ
[08:43:55] <Nemo_bis>	 seems better now?
[08:44:12] <mark>	 ok, that's not packet loss to bits
[08:44:20] <mark>	 0.0% to bits-lb
[08:47:46] <Kelson>	 jeremyb: https://bugzilla.wikimedia.org/show_bug.cgi?id=55503
[08:48:55] <Nemo_bis>	 1 % maybe... http://p.defau.lt/?m6L4vR_x2nW5Jo06BpO9ag dunno, it's matanya_ complaining, he should provide more info ;)
[08:51:06] <matanya_>	 mark: in a pm it is good?
[08:51:27] <mark>	 yes
[14:30:58] <Steinsplitter>	 Request: GET http://outreach.wikimedia.org/wiki/Wikipedia_Education_Program, from ... via sq72.wikimedia.org (squid/2.7.STABLE9) to ()
[14:30:58] <Steinsplitter>	 Error: ERR_CANNOT_FORWARD, errno (11) Resource temporarily unavailable at Wed, 09 Oct 2013 14:26:30 GMT 
[18:29:04] <valhallasw>	 Debugging Flask apps without proper error reporting is really a huge PITA...
[18:29:33] <valhallasw>	 not being able to turn http/500's into error messages does not help -_-'
[18:33:34] <Ryan_Lane>	 valhallasw: this is related to labs?
[18:33:53] <valhallasw>	 yes, because normally one would use apache's error logs...
[18:34:05] <valhallasw>	 so, tool labs relates.
[18:44:44] <Ryan_Lane>	 valhallasw: heh. should likely mention it in the labs channel, then ;)
[18:44:53] <valhallasw>	 Ryan_Lane: >_< thanks.
[18:45:02] <valhallasw>	 err
[18:45:03] <Ryan_Lane>	 I think there was some issue with giving access to the error logs?
[18:45:16] <valhallasw>	 ok, my brain is fried. I thought I posted the 'it's working' in the wrong channel.
[18:45:26] <valhallasw>	 Yeah, privacy issue due to IP's
[18:46:02] <valhallasw>	 it will be fixed in the future when Coren implements his plans for tool labs webservers 2.0 :-)
[18:47:10] <Coren>	 Which I am working on now.
[18:47:34] <Coren>	 The solution was too evident for me to consider it back when I was doing basic design; in retrospect it's effin simple.
[18:48:39] <Ryan_Lane>	 heh
[19:25:09] <mwalker>	 csteipp: you around?
[19:56:50] <csteipp>	 mwalker: I'm back
[20:05:52] <mwalker>	 csteipp: Jeff_Green and I were wondering what your thoughts were on allowing a ganglia user to sensitive log data
[20:07:15] <csteipp>	 I would be very cautious about using ganglia as an identity source.. I would say they are trying on the security front, but they have a long way to go on their process.
[20:10:11] <mwalker>	 *nods* that's pretty much the conclusion we came to
[20:10:30] <mwalker>	 or at least; I think so
[20:10:37] <mwalker>	 what do you mean by identity source
[20:10:39] <mwalker>	 ?
[20:12:00] <Jeff_Green>	 csteipp: specifically we're talking about a log parser that feeds data into ganglia. mwalker initially built it as a module to make use of ganglia's metric grouping. but since it will run under the ganglia user it can't access the logs presently
[20:12:00] <mwalker>	 the context I'm coming from is I have a python script running under the ganglia user; and we were debating on if it could be trusted to have direct access to log data; or if we needed to aggregate things for it in a different process
[20:12:08] <mwalker>	 jinx!
[20:12:10] <Jeff_Green>	 ha what he said
[20:12:24] <csteipp>	 Ah, sorry, thought you meant an end user
[20:12:48] <Jeff_Green>	 so we already disable gexec which is good-ish
[20:13:20] <Jeff_Green>	 so we're talking about the sanity of allowing a local ganglia daemon access to sensitive data
[20:14:15] <csteipp>	 Yeah, overall I would be very cautious about it. Are you actually putting that sensitive data into ganglia?
[20:14:33] <csteipp>	 Or is it just in the same dataset as something ganglia is accessing?
[20:14:33] <Jeff_Green>	 no
[20:14:55] <Jeff_Green>	 it's raw banner logs and we're talking about aggregating a few simple counters off of them
[20:15:28] <Jeff_Green>	 i.e. impressions in the last 15 minutes, and similar
[20:17:18] <csteipp>	 gatcha. So I personally wouldn't do it, but I have no idea how much other similar data that user has access to, so it could be somewhat irrelevant.
[20:17:38] <Jeff_Green>	 at present, little or none
[20:17:55] <csteipp>	 I would probably setup something to replicate a sanitized version of the logfile that ganglia then read
[20:18:55] <Jeff_Green>	 right. we were talking about having the ganglia module shell out to a script that would run under sudo
[20:19:57] <Jeff_Green>	 and that script would run as a user that generates the sane report to stdout
[20:20:05] <Jeff_Green>	 sound reasonable?
[20:20:59] <csteipp>	 So the script actually reads the log file and then reports back the aggregates?
[20:21:06] <Jeff_Green>	 yep
[20:21:10] <csteipp>	 Yeah, that would probably work
[20:21:34] <Jeff_Green>	 alright, we'll do it!
[21:00:09] <mwalker>	 ori-l: I was wondering -- do you have any insight into why we use ganglia for some things and graphite for others? e.g. is the plan to move to graphite so any new reporting metrics should be written to go there?
[21:01:16] <ori-l>	 there isn't a simple answer to that; graphite is very flexible but its flexibility also makes it hard to expose publicly, so access to it is somewhat gated
[21:01:55] <ori-l>	 there's a strong existing commitment to keeping ganglia public and open and people have historically relied on it to diagnose a range of issues
[21:02:33] <ori-l>	 if you write metrics by sending them to statsd you can have them routed to both so you can enjoy the best of both worlds
[21:02:53] <mwalker>	 oh? tell me more!
[21:03:01] <ori-l>	 in general, I think that our graphite setup needs a lot of work so if you're developing something that you want to rely on then ganglia might be the thing to do
[21:03:38] <ori-l>	 statsd is a simple daemon that listens to metrics via UDP. metrics look like 'myapp.somemetric.dbcalltime:143|ms'
[21:03:41] <mwalker>	 I'd like to rely on it :) but I'll be writing more things that follow the same pattern I'm developing in the frack for banner impressions
[21:03:59] <ori-l>	 it computes summary statistics and flushes them to a backend every N seconds / minutes
[21:04:13] <ori-l>	 where 'backend' is currently (and for the forseeable future) either ganglia or graphite or both
[21:04:48] <ori-l>	 '|ms' measures latency, but there are other data formats; you can 'foo|incr' to increment a counter
[21:04:59] <ori-l>	 it's nice in that statsd keeps state, so your application doesn't have to
[21:05:54] <mwalker>	 can it accept timestamped calls?
[21:06:00] <ori-l>	 I took a quick look at your gmond module last night and it looks good; I would say get that in place before considering other options, because none are currently as reliable / familiar / maintainable as gmond metric modules. We use those all over the place.
[21:06:05] <mwalker>	 ok
[21:06:24] <ori-l>	 er, not sure, but I think not; it assumes the time it receives the metric is the time it applies to
[21:06:56] <mwalker>	 makes sense; that's how ganglia works -- it's just frustrating for me because we have a lot of batched operations
[21:07:17] <mwalker>	 and it turns out that graphite is friendly towards that sort of data
[21:07:35] <ori-l>	 so, a discovery i made recently is that the ganglia wire protocol is pretty simple and sometimes it's much simpler to just write to ganglia yourself rather than contort yourself to fit gmond's framework
[21:07:46] <ori-l>	 ah, yes, graphite is probably more flexible
[21:08:29] <ori-l>	 if you want to set aside half an hour later to walk me through your requirements i can try and help you figure out what would be a good fit
[21:08:36] <ori-l>	 i'd be happy to , i mean
[21:09:17] <mwalker>	 sure; that'd be cool