[01:45:14] Can I get another public IP for the editor-engagement project? [01:45:26] It's for a GSOC project, PronunciationRecording. [01:48:44] superm401: You need Ryan_Lane, Coren or andrewbogott for that, IIRC. [01:49:30] scfc_de, thanks. [08:04:49] [bz] (8NEW - created by: 2Magnus Manske, priority: 4Unprioritized - 6normal) [Bug 53088] Reconstructed tool not accessible - https://bugzilla.wikimedia.org/show_bug.cgi?id=53088 [09:49:26] can't figure out why simple hallo world php script gives "Internal error" on tool labs web http://tools.wmflabs.org/etwikt/ Any ideas? [09:58:28] kentaur: permissions [09:58:40] it must be owned by your tool [10:05:59] thanks [12:39:41] YuviPanda: is there a documentation somewhere as to how to set up cgi app for a tool? [12:39:47] nerus: hello! [12:40:02] YuviPanda: hello ;) [12:40:04] nerus: well, I was going to write one up but then got lazy :P [12:40:06] but [12:40:32] nerus: https://github.com/wikimedia/labs-tools-gerrit-to-redis/blob/master/src/github-receiver.py [12:40:35] i could write one if i manage to set it up myself [12:40:39] nerus: setup a virtualenv [12:40:50] nerus: put hashbang to path (#!/data/project/gerrit-to-redis/gerrit-to-redis/bin/python ) [12:40:58] nerus: chmod +x [12:41:04] inside $TOOLHIME/cgi-bin [12:41:05] and that's it [12:41:17] i see [12:41:22] I am doing http://flask.pocoo.org/docs/deploying/cgi/ [12:42:06] nerus: oh yeah, i have another tool that does that [12:42:07] moment [12:42:16] ok [12:42:25] nerus: https://github.com/addshore/dumpscan/blob/master/dumpscan.py [12:42:40] nerus: but yeah, that link from pocoo was what I used too [12:43:29] got it [12:43:32] that should help [12:43:43] thanks! [12:44:10] * sumanah encourages nerus to paste the bullet points YuviPanda just spoke into wikitech.wikimedia.org somewhere :-) [12:44:58] sumanah: sure, will document it once i get to run it myself [12:45:09] sumanah: BTW, hi :) [12:45:37] thanks nerus [12:45:37] hi! [12:45:40] sumanah: nerus is a really really good friend of mine who I have lured into doing fun stuff on labs :) [12:45:46] oh cool! [12:45:57] you didn't lure me, i wanted to do it myself :P [12:46:06] both :P [12:46:41] Last night I was talking with a woman at an event, a freelance programmer who hasn't had much of a chance to explore MySQL because her laptop's so dinky that she's only installed SQLite. So I told her about Labs :-) [12:48:30] :) [12:48:39] I don't think labs is at that point yet, tbh. [12:48:43] but it's getting there :) [12:49:35] sumanah: You know that, strictly speaking, that falls a bit outside of the TOU? [12:50:17] I mean, I don't think anyone would throw a fit over it. [12:50:35] Coren: If "play with our infrastructure to learn" is outside the ToU then we ought to change our ToU, in my opinion. [12:50:59] playing is not good ---- [12:51:02] Coren: wait, we finally have a ToU? :P [12:51:02] imho [12:51:03] Why? [12:51:16] YuviPanda: http://www.mediawiki.org/wiki/Wikimedia_Labs/Terms_of_use [12:51:19] Playing is fine, as long as it doesn't cause stress to the system or cause work for others. [12:51:21] Coren: last we met you were still talking to lvilla about it [12:51:22] It is for making/programming tools for WP [12:51:30] but nor or only playing [12:51:37] Steinsplitter: I thinkw e just have different definitions of the word 'play' :) [12:51:40] whaaat [12:51:42] But part of how people learn that is by poking around. I would call it play, maybe you would not. [12:51:46] YuviPanda: :D [12:51:57] hmm, poor grrrit-wm [12:53:27] sumanah: Well, we're not a free hosting service. Strictly speaking, stuff run on labs need to be related to mediawiki or wikimedia projects. Exploratory learning is nice, but should be done with an eye towards joining the dev community. Like I said, I'm sure nobody will throw a fit over the ocassional "out of scope" use, but I don't think we should advertize labs as the right place for it. [12:53:57] sumanah: Perhaps you should raise the issue with Erik and/or legal. [12:54:25] * addshore goes to read ye olde talk page for ye olde message [12:54:33] * sumanah considers [12:55:45] Coren: what was your suggestion for https://wikitech.wikimedia.org/wiki/User_talk:Addshore#Need for a Village Pump again? [[The Hub]] ? [12:55:50] (Part of the issue, of course, is that our resources are finite) [12:56:30] addshore: That was off-the-cuff but servicable. I'm sure something even more brilliant could be thought of. [12:56:32] Coren: well, I think you could see it as 'recruiting tool' in a way: by allowing people to learn 'big data querying' on labs, you give them the possibility to enjoy that, and maybe stay. [12:57:05] sumanah: any suggestions from the section on my talk page? [12:57:07] Coren: but that's mainly because of the replicated DB's, which are not available elsewhere [12:58:22] valhallasw: Arguably, if you're playing with wikimedia db replicas you're doing stuff that's related to the projects. :-) It's not like I think it would be a good idea to start patrolling usage for compliance, just that we might not want to encourage out-of-scope use as something we do. [12:58:23] addshore: you know, I think we should reallllly be directing people to labs-l [12:58:35] I think using tools for non wmf projekts is out of scope, [12:58:43] sumanah: some people dont like mailing lists ;p [12:59:09] Coren: Sure. [12:59:09] sumanah: ML format is good for some things, VP format is good for others. I'd rather have both. [12:59:10] addshore: yeah. That's a separate topic, though, from "not knowing where to ask" [12:59:28] indeed! [12:59:59] I dislike fragmenting people's attention, but if it's natural to you, go for it [13:01:11] hmm by the way - the old TS was for WMF and OSM projects, WP projects now migrate to Labs, but what about OSM tools not related to WMF? [13:03:06] Silke_WMDE, ^^ [13:03:22] re [13:03:29] * Silke_WMDE is reading [13:04:18] MaxSem: we need a policy ... [13:06:38] MaxSem: Whats an example for a OSM tool not related to WMF? [13:06:46] (running on the toolserver) [13:07:59] was going to answer with http://toolserver.org/~mazder/replicate-sequences/ but it had already moved:P [13:08:33] anyway, OSM was officially supported so there have to be other tools [13:10:55] MaxSem: Now that the foundation is working on having an OSM tileserver in production (for a number of reasons) it seems clear to me that projects related to that fall within scope. [13:11:47] YuviPanda: can you point me to the htaccess for dumpscan? [13:12:13] nerus: I didn't write one for dumpscan, we just do dumpscan.py/url [13:12:18] nerus: but i wrote one for another tool! moment [13:12:48] moment, finding it [13:12:53] no problem [13:13:43] nerus: http://pastebin.com/UMNf7XrH [13:14:16] nerus: note the location, it is in public_html even though it is redirecting to cgi-bin [13:14:41] hmmm [13:15:17] /wp-signpost actual path would be /data/project/wp-signpost ? [13:16:23] YuviPanda: ^^^ ? [13:16:47] nerus: hmm? [13:16:48] in RewriteRule ^(.*) /wp-signpost/cgi-bin/api.py/$1 [13:16:49] ? [13:17:25] yeah [13:17:47] nerus: no, just /wp-signpost/cgi-bin/api.py [13:17:49] since that is the URL [13:17:52] not the file path, no? [13:17:58] htaccess deals with URLs [13:19:38] hmmm [13:19:39] ok [13:19:40] my bad [13:24:05] MaxSem: Coren Sorry, I got distracted. We should actually take this question up for those people around sumanah who are working on OSM. (sumanah: THat would be: Are projects unrelated to mediawiki/WMF/WP but related to OSM development invited to Tool Labs? [13:24:08] ) [14:04:14] [bz] (8ASSIGNED - created by: 2Tim Landscheidt, priority: 4Unprioritized - 6major) [Bug 52917] tools-exec-01 is not responding - https://bugzilla.wikimedia.org/show_bug.cgi?id=52917 [14:08:17] YuviPanda: sumanah: How does this look https://wikitech.wikimedia.org/wiki/Setting_up_Flask_cgi_app_as_a_tool ? [14:08:47] nerus: nice! [14:09:06] next is to actually work on the tool :P [14:09:11] :D [14:09:16] nerus: you should email it to labs-l [14:09:30] oh [14:09:33] this link? [14:09:38] https://lists.wikimedia.org/mailman/listinfo/labs-l [14:09:39] yeah [14:10:14] * nerus is subscribing [14:11:33] nerus: subscribe and feel free to spam too! :) [14:11:53] I am against spam in principle :P [14:13:36] nerus: :) but not in practice? [15:17:56] @seen hashar [15:17:56] Steinsplitter: Last time I saw hashar they were quitting the network with reason: Quit: I am a manual virus, please copy me to your quit message. N/A at 8/2/2013 8:24:59 PM (17d18h52m56s ago) [15:18:11] 1month vacation :-( [15:36:17] edsu: 20 15:34:53 < Stryn> http://wikistream.wmflabs.org/ does not work :/ [15:36:26] yeah [15:38:01] jeremyb, Stryn http://lists.wikimedia.org/pipermail/labs-l/2013-August/001495.html [15:39:10] can anyone help me figure out why i can't log in to wikistream-web instance? [15:40:05] Coren: ^ [15:40:53] edsu: What is your wikitech username? [15:40:58] edsu [15:42:07] Coren: when i try to log in i see this error http://lists.wikimedia.org/pipermail/labs-l/2013-August/001495.html [15:42:18] Unable to create and initialize directory '/home/edsu'. [15:43:24] Ah. Gluster is probably broken. Lemme check. [15:43:25] edsu: ahhhh, i remembers that! [15:44:35] ... actually, there isn't even a home. [15:46:36] yeah, all i know is, it was working for a bit, just noticed a few days ago that the app on there was failing, and i couldn't log in [15:46:39] Yep, the home volume is broken. Lemme see if I can fix it. [15:46:49] Coren: thnx! [15:47:07] Coren: if there's a place to file a ticket to record your work let me know and i'll add one [15:47:23] [bz] (8NEW - created by: 2Magnus Manske, priority: 4Unprioritized - 6normal) [Bug 53100] Created too but not added to group - https://bugzilla.wikimedia.org/show_bug.cgi?id=53100 [15:47:36] oh, hmm :) [15:47:42] No need. Fixing gluster brain damage is pretty much routine now. I can't wait 'till we get rid of it for good. :-) [15:48:59] what is the labs moving to? [15:49:05] [bz] (8NEW - created by: 2Tim Landscheidt, priority: 4Unprioritized - 6normal) [Bug 53101] Set up SPF/DKIM for tools.wmflabs.org - https://bugzilla.wikimedia.org/show_bug.cgi?id=53101 [15:51:23] Steinsplitter: yes, hashar is on a very long vacation [15:51:33] Steinsplitter: what do you need? we do have other people who can do what he does [15:52:51] thank you. but is confidential [15:56:58] edsu: NFS. Some projects have already noved; but past issues made us slow transition down. [15:57:26] <^d> We need to get beta off nfs. [15:59:10] off? Whyso? [15:59:31] NFS has been stable since I moved the problematic controller out of the loop. [16:00:12] edsu: Home is back alive on wikistream. [16:00:37] edsu: can you point me to the wikistream source? I'm going to try to have it run on tools :) [16:01:22] ^d: Seriously, you still have issues with the filesystem? Last I checked, there hasn't been so much as a vague blip on it since the maintenance. [16:02:48] <^d> Coren: Special:Version does git operations to give you last-updated dates and such. [16:02:51] <^d> git operations on nfs suck. [16:03:19] ^d: They suck just as much on gluster. [16:03:24] <^d> I know :) [16:03:37] <^d> This isn't nfs' fault, more a "This should be on local filesystems just like on production" [16:04:01] Ah. Well, so long as there is just the one instance that's not an issue; but aren't you sharing stuff between multiple instances? [16:04:19] <^d> Yeah [16:04:26] Coren: thanks for the help! [16:04:41] Not sure what you could do then. I'm certainly not going to start deploying AFS. :-) [16:04:46] YuviPanda: https://github.com/edsu/wikistream [16:05:00] ^d: that's more a 'why is it doing git operations?!' thing :P [16:05:15] edsu: ty! [16:05:19] <^d> People want to know when extensions were updated. [16:05:32] <^d> And for some reason we've decided having special:version shell out for shit is acceptable. [16:06:04] and hence the solution is to get rid of NFS :P [16:06:14] * Coren wouldn't actually /mind/ AFS, mind you. [16:06:18] I thought there was a patch that did something else [16:06:21] (not shelling out) [16:10:26] ... wait. Shelling out from Special:Version? [16:10:34] * Coren boggles in horror. [16:10:52] Coren: indeed! And iirc it isn't even specially cached? [16:11:00] Coren: clearly NFS's fault :P [16:12:00] YuviPanda: it's not SMB's fault [16:22:42] [bz] (8RESOLVED - created by: 2Magnus Manske, priority: 4Unprioritized - 6normal) [Bug 53100] Created tool but not added to group - https://bugzilla.wikimedia.org/show_bug.cgi?id=53100 [17:28:01] scfc_de: That was completely uncalled for. [17:30:36] Coren: YMMV. I don't think WMF's legal's up to par. [17:46:03] I think they're being overly paranoid in this case. I also know they are paid to be overly paranoid and to think of all the ways everything could go wrong in the worst possible ways. [17:51:49] And, by the way, I've worked with a /lot/ of lawyers over the years. I'd be hard-pressed to find some that are more competent and who understand tech as well as our team does. You should see the morons Ubisoft have as their legal team. [17:53:41] Laywers are expensive caring [17:54:28] This topic has been on the table for /months/ and on the horizon probably for years; others could have written dissertations about that in that time frame. If they are paid to be overly paranoid, they utterly failed at the Wikivoyage logo issue. I'm very interested in what they'll produce after this long deliberations, especially if you consider them the top league of their profession, but I don't think that it will have value for [17:54:28] money. [17:54:30] !logs [17:54:30] http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-labs/ [18:10:56] scfc_de: To be fair, they are currently knee-deep in the privacy policy; I expect this should have been resolved a month ago otherwise. And, FYI, they /did/ raise the Wikivoyage logo issue; they just underestimated the zeal of the other guy's lawyers. [18:24:45] Coren, I haven't used labs in quite a while - I originally ran my bot on bots-3 but from what I understand we're using tools now - would my files still be saved somewhere? [18:25:20] Thehelpfulone: They should still be accessible from any instance in the (now obsolete) bots project. [18:25:41] For instance: bots-login [18:26:40] so can I connect to bots-login through bastion, or directly? [18:27:00] Through bastion, normally. [18:27:42] ... except that I don't see you as being a member of the bots project. [18:28:12] really? did you re-create the project or something then? [18:28:31] I didn't; and that didn't happen since I've been here at least. [18:29:42] Thehelpfulone: I see you as member of bastion, globaleducation, mailmain, tools, and wikivoyage [18:29:49] Could you have been using another account? [18:29:50] maybe I was deleted then? I used to have sudo access to something IIRC so it could have been when permissions were being removed from people [18:30:13] petan or Ryan_Lane would probably know [18:31:03] As far as I can tell, that account has never been a member of bots; at least, it doesn't have a home [18:31:09] can you view the user directories in bots Coren - hopefully my files are still there? [18:31:10] :/ [18:31:21] I can. Where would the code have been? [18:31:49] Can you give me the name of a file that'd be part of your code and likely to be unique? [18:32:32] hmm, it was all pywikipedia code [18:34:05] I think it was /home/thehelpfulone/ [18:34:32] it was on bots-3 IIRC, but it was shared project storage [18:35:19] Yeah, that's my point: I don't see a "thehelpfulone" in /home at all, and no indication that there has ever been one. [18:35:22] ... wait, wtf? [18:35:39] bots-login actually points to an instance named kraken-namenode-standby [18:36:51] Ah, petan seems to have removed bots-login entirely. Hm. Try bots-4 instead [18:37:18] Your home exists there. :-) [18:39:05] (I added you back to the project) [18:40:58] ah thanks [18:41:19] I'm going to grab some dinner and then when I get back I'll probably need your help switching to tools labs (I'm already a member of that probject) [18:42:27] Coren: We're not talking about the legal implications of space flight here. Shared hosting, mail services and privacy policies have been around since the Early Days(TM), they have been discussed in science and fought in the courts ad nauseam. Especially if you are competent in this field, you shouldn't need that time to resolve any questions that arise. Re Wikivoyage, what's the point of "maybe" as legal advice? They were asked, [18:42:27] they said "there were significant enough differences between the designs and the markets the two organizations occupied for both logos to co-exist", but found out, ooops, "such arguments are not guaranteed to win if we were to legally oppose this request because there are also some substantial similarities". That's okay for pro bono, but if you pay for it, the answer should be more reliable than a Magic 8-Ball's. [18:47:50] !log deployment-prep rebuild search indecies after some changes to indexing code. [18:47:53] Logged the message, Master [18:47:54] [bz] (8NEW - created by: 2Tim Landscheidt, priority: 4Unprioritized - 6normal) [Bug 52976] Provide user_slot resource in grid - https://bugzilla.wikimedia.org/show_bug.cgi?id=52976 [18:59:42] scfc_de: Sorry, but you don't know how courts work if you think it's possible to make a definitive answer about /anything/. They gave the best possible opinion given the available information "different enough that we don't expect they'll object or sue" isn't inconsistent with "similar enough that it would be a toss-up now that they objected and might sue". [19:03:32] scfc_de: You can't predict what the other guy will do, and sometimes even winning in the end cost you so much that you lose. That's how patent trolls earn their living. IMO, the WTO were inane jerkasses in this case, and I wouldn't have expected them to even notice -- let alone object. [19:04:26] But they did, and so legal reevaluated the situation accordingly and came up with "not worth fighting over a brand new logo". [19:06:17] *Any* legal opinion is necessarily a probability assessment. Something that's okay 99% of the time still blows up in your face 1% of the time. [19:18:22] Coren: I didn't ask for something absolute; as you apparently say yourself, WMF legal's positions seem to have been: "We don't expect them to sue." But that's not the function of legal advice: They should advise, *if* someone sues, what are our chances? That's the legal question, and you pay lawyers for *that*. For the question of whether the WTO might sue, you ask a psychologist, a game theorist or your gut. If your legal defence [19:18:22] depends on the other party not suing, you don't have one. [19:43:02] Coren: you didn't actuall cc luis :P [19:43:58] Yes I did. Odd, my sent copy has the CC, but the list doesn't. [19:44:25] Methinks the header was stripped by mailman [19:44:28] hmm, is that normal? I usually see them [19:44:33] when someone gets cc'd [19:44:36] Yeah, hence "odd" [19:44:51] I'm quite sure Luis got it [19:44:58] hehe, okay. [19:46:31] [bz] (8NEW - created by: 2Greg Grossmeier, priority: 4Unprioritized - 6major) [Bug 53113] SSL on the Beta Cluster - https://bugzilla.wikimedia.org/show_bug.cgi?id=53113 [19:53:14] [bz] (8NEW - created by: 2Antoine "hashar" Musso, priority: 4Normal - 6major) [Bug 48501] [OPS] beta: get SSL certificates - https://bugzilla.wikimedia.org/show_bug.cgi?id=48501 [19:55:38] edsu: there? [19:55:38] i'm trying to run wikistreams [19:55:38] but getting [19:55:38] Error: Cannot find module '/data/project/wikistream/app.js' [19:55:38] any idea why? [19:55:42] it seems to be looking at the wrong path [19:55:42] hmmm [19:55:56] mayb e [19:55:56] wait [19:58:55] edsu: http://wikistream-tools.proxy.wmflabs.org/ routes to it correctly, but the app doesn't seem to be running :( [20:09:00] kma500: hi :-) [20:09:31] I'm glad https://www.mediawiki.org/wiki/User:Kmenger/ToolLabsGuide is better re git & pyb [20:11:07] hi kma500! [20:11:28] http://www.mediawiki.org/wiki/User:Kmenger/ToolLabsGuide [20:11:32] * sumanah guesses that we are replacing https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help - is that right? [20:11:41] yes [20:11:48] awesome [20:11:50] I am about to copy and paste [20:12:18] https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource%3ATools%2FHelp&diff=80837&oldid=78408 [20:14:09] yay! https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help is a lot better now! thank you all, especially kma500, Coren, valhallasw, and others [20:15:29] "Plan for improving Tool Labs docs next week" email I sent.... [20:16:49] kma500: https://wikitech.wikimedia.org/wiki/Help:Terminology -- it would be good to add more terms there, yes [20:17:33] let's clean up https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools [20:19:23] kma500: so, https://www.mediawiki.org/wiki/Wikimedia_Labs/Tool_Labs/Migration_of_Toolserver_tools is the one you expanded, right? [20:19:43] and https://wikitech.wikimedia.org/wiki/User:Magnus_Manske/Migrating_from_toolserver is the only page we have that has step-by-step directions on migrating from Toolserver, right? [20:19:56] yes, as far as I know [20:21:48] kma500: https://wikitech.wikimedia.org/w/index.php?title=Help:Move_your_bot_to_Labs&action=history was the old general help page for moving your bot to labs [20:22:22] kma500: useful Q&A: https://wikitech.wikimedia.org/w/index.php?title=Help:Move_your_bot_to_Labs&oldid=11520 [20:23:34] e.g. "What software is installed? See dpkg -l " [20:23:42] kma500: ^ [20:23:50] kma500: https://wikitech.wikimedia.org/w/index.php?title=Help:Move_your_bot_to_Labs&oldid=11520#Set_up_your_bot [20:26:18] kma500: https://wikitech.wikimedia.org/wiki/User_talk:Magnus_Manske/Migrating_from_toolserver [20:27:49] kma500: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools#Useful_links could use some cleanup [20:32:58] I assume people know beta is serving https only but without style? [20:36:27] [bz] (8UNCONFIRMED - created by: 2Pleclown, priority: 4Unprioritized - 6enhancement) [Bug 53117] Switch to using the mysqlnd driver in PHP - https://bugzilla.wikimedia.org/show_bug.cgi?id=53117 [20:37:28] manybubbles: so have you heard about the bits.wikimedia.org styling/SSL issue? [20:38:02] sumanah: I regret to say I'm not following the ssl emails very closely. [20:38:22] manybubbles: oh no worries, I understand. This wasn't in email; it was something ^demon mentioned in IRC earlier today I think [20:38:54] I could be wrong, but it's something like: since bits.wikimedia.org isn't serving over SSL, SSL pages on beta are unstyled? [20:42:11] sumanah: that'd be all of the pages if you are logged in. lame. [20:42:25] manybubbles: I am not sure whether a bug is filed or who is working on it. [20:43:14] ^demon, sumanah mentioned you, do you know more about unstyled pages in beta? i'm sure it makes everyone in qa sad [20:43:33] <^demon> I sorta figured a workaround, will explain in a bit. [20:43:34] <^demon> Meeting. [20:43:50] thank you Chad [20:45:28] have good meeting [21:03:09] <^demon> manybubbles, sumanah: So basically, you're getting the same "Cert can't be trusted" warnings for bits/upload (they *do* have SSL, just like the rest of beta). [21:03:44] <^demon> Once you accept the non-trust for those hosts, it'll work like normal [21:05:00] <^demon> Open https://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php and https://upload.beta.wmflabs.org/wikipedia/en/b/bc/Wiki.png (and accept the cert issues) [21:33:31] scfc_de: can you open up port 8000 on tools-exec-03 for a moment? [21:33:41] scfc_de: not to the internet, but just to rest of labs? [21:33:58] specifically to instance project proxy on project proxy project? [21:48:52] YuviPanda: Do we have a security policy that's blocking that?! [21:49:01] scfc_de: looks like. [21:49:18] scfc_de: curl tools-exec-03:8000 [21:49:21] from inside tools project [21:49:22] and it works [21:49:25] from outside, and nope [21:49:32] (outside tools project, but inside labs) [21:49:39] scfc_de: I verified it with nmap [21:50:08] scfc_de: I think this is in the 'Manage Security Groups' thing on the sidebar [21:50:54] YuviPanda: So you propose I should allow *all* traffic from *everywhere* to port 8000? :-) [21:51:06] scfc_de: so... I don't know :P [21:51:29] Oh, I can limit it to Labs. [21:51:30] scfc_de: I just want to test this for a moment, so it's okay to allow that for a minute or two manually, and then close it back down while we figure out a longer term solution [21:52:07] (Labs being 10.4.0.0/21.) [21:52:16] TCP? [21:52:17] right [21:52:19] yeah [21:52:44] Changed it, don't know how long it takes to enable itself. [21:52:55] * YuviPanda nmaps [21:53:12] yup open [21:53:22] scfc_de: aaand http://testing.proxy.wmflabs.org/ ;) [21:53:45] scfc_de: can you also open port 3000? [21:53:57] So now webservers for everyone? :-) Re 3000, moment. [21:54:25] scfc_de: almost! This isn't a 'production' service yet, since it is waiting for a new nginx proxy. but otherwise... yeah ;) [21:54:34] 3000 should be open. [21:55:13] scfc_de: wooo http://wikistream-tools.proxy.wmflabs.org/ [21:55:16] wikistreams on tools! [21:55:25] edsu: ^ [21:55:28] Coren: Ryan_Lane ^ [21:55:40] websockets and stuff ;) [21:55:47] ty, scfc_de [21:56:48] YuviPanda: Cool! [21:59:13] (Still prefer standard CGIs, though :-).) [22:00:10] scfc_de: without the .proxy - http://wikistream-tools.wmflabs.org/ [22:00:11] :) [22:00:32] scfc_de: well, CGI model doesn't work for a lot of things anymore. plus CGI is one new process per request! [22:02:36] scfc_de: hmm, does http://wikistream-tools.wmflabs.org/ work for you? [22:05:25] YuviPanda: Yes. [22:05:36] scfc_de: ah, yeah, works for me too (crashed my browser tab tho :P) [22:05:55] scfc_de: so, this currently is very, *very* manually setup :P [22:05:56] YuviPanda: My Chrome was stuck for a minute or so as well. [22:06:41] YuviPanda: That's called "proof of concept" :-). [22:06:41] scfc_de: yeah, possibly caching / buffering in nginx [22:06:47] scfc_de: of course! [22:06:48] :) [22:07:20] scfc_de: https://gerrit.wikimedia.org/r/78025 [22:07:23] is all the current work [22:08:01] That looks nice and clean, and I have absolutely no idea what it does. [22:10:09] scfc_de: hehe, nice and clean is good enough, I think :) [22:10:53] scfc_de: thoughts on opening up everything in the Linux ephemeral port range to inside labs? :) [22:13:18] YuviPanda: Ports > 1024? I think that's probably okay (I can't think of an attack from another Labs instance that couldn't occur from inside Tools as well), but that's Coren's call. [22:13:35] scfc_de: not 1024, let me check. even higher, IIRC [22:14:01] scfc_de: https://en.wikipedia.org/wiki/Ephemeral_port [22:14:09] scfc_de: 32768 to 61000 [22:14:47] scfc_de: although the citation for that seems a little dubious [22:15:11] scfc_de: but checks out on my labs instance [22:16:43] scfc_de: so, for tools, I'll have to write wrappers similar to jsub [22:17:00] that start the server as continuous jobs, figure out the hostname and port, and communicate that to the proxy [22:17:02] YuviPanda: Ah, https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers has < 1024 as "Well-known ports", and < 49152 as "Registered ports [but not to be taken too seriously, ed.]". [22:17:16] yeah but [22:17:16] yuvipanda@proxy-project:/usr/local/nginx/lua$ cat /proc/sys/net/ipv4/ip_local_port_range [22:17:19] 32768 61000 [22:17:23] i've no idea what those numbers mean [22:17:27] but I guess they are okay to use? [22:17:38] scfc_de: these will all be randomly generated by wrapper scripts, none should be hardcoded [22:17:54] hardcoding (+ the fact that ports are first come first served) can lead to impersonation attacks easily :D [22:18:02] (for some definition of 'easily') [22:18:53] scfc_de: there also needs to be a deamon running on tools, that checks somewhere for these new servers and registers them with the proxy [22:18:56] YuviPanda: Yep, if randomness is possible, that's definitely +1. [22:19:04] scfc_de: I'll enforce randomness :) [22:19:19] so, for example, if I wanted to run a node thing [22:19:28] 1. nodesub -N [22:19:49] 2. that will submit a wrapper to the job queue. the wrapper knows which file to run, and picks a random port to run it on [22:19:55] YuviPanda: Wouldn't you want to do that the other way around? I. e., the job starts up, listens on a port, and then conveys hostname and port to your proxy? [22:20:11] 3. wrapper writes to a well known filesystem location the hostname and port [22:20:39] 4. deamon notices filesystem change, reads that, verifies that the user perms of the file there are okay, and then communicates with proxy [22:20:40] done [22:21:08] scfc_de: that is what is happening. The wrapper just waits for the connection to be established (all of the new servers (nodejs, go, etc) have inbuilt ability to just pick an unused ephemeral port) [22:21:21] scfc_de: thing is, proxy API shouldn't be available to everyoen, since we can't do auth [22:21:30] so we don't want random tools overwriting things for every other tool [22:22:26] hi there folks. I have a question about setting up my bots on labs. I've just created a bot account (grantsbot), and want to access the replica dbs. If I'm reading the documentation right, I should have a replica.my.cnf file in my bot's home directory, but I'm not seeing it. Any idea where I can find these MYSQL credentials? Relevant documentation is: https://wikitech.wikimedia.org/wiki/Help:Move_your_bot_to_Labs#Connecting_to_the_database_replicas [22:22:51] scfc_de: with 'write to filesystem' we can verify that the user is the same (via file perms) [22:22:52] so [22:22:55] scfc_de: how does that sound? [22:23:03] YuviPanda: But couldn't you save a password on proxy port creation? I. e., I register a tool "scfc-test" on the proxy with the password "joshua". I save "joshua" in a local file, and on each job restart, the tool contacts the proxy, provides "joshua" (MD5 or whatever) and then its hostname/port? [22:23:47] YuviPanda: BTW, there's still identd. [22:24:10] scfc_de: hmm, i've no idea what identd does :P [22:24:11] let me look [22:24:50] J-Mo: What's the tool's name? I don't see a "grantsbot". [22:25:13] scfc_de: hmm, fascinating. can I use ident to look for user of a service that is just listening? [22:25:43] btw J-Mo you are enjoying the new Tool Labs Guide https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help that kma500 was lead writer on [22:26:10] hmm. I just created it an hour ago. It's on the http://tools.wmflabs.org/ page as "grantsbot" [22:26:22] YuviPanda: I'm not sure, but I think you're missing my point :-): The tool has to contact the proxy to notify it about the new hostname and port, and that's when you can auth it. [22:26:34] sumanah: the guide has been a lifesaver :) [22:26:42] J-Mo: it's pretty great! [22:26:56] scfc_de: no, I think I got your point and then just took a detour to identd :) [22:27:12] scfc_de: I'm trying to think of possible holes in your point, because if I can't find any that sounds like a simpler, better one [22:27:13] than a deamon [22:27:43] J-Mo: Don't know why I didn't saw that. Yes, you should have a replica.my.cnf in that directory and it's not there. [22:28:19] YuviPanda: But you still would have to provide a way to "call dibs" on a URL in the first place. What's your idea for that? [22:28:31] scfc_de: toolname/ [22:28:35] same as now, no? [22:28:41] scfc_de, I can't find it: local-grantsbot@tools-login:~$ ls -a [22:28:41] . .. .bash_history cgi-bin .description public_html .viminfo [22:29:03] scfc_de: so only thing we need is to auth the user talking to the proxy the first time as someone who is actually [22:29:09] J-Mo: Yep, as I said, it's not there though it should be :-). Looking at the why ... [22:29:17] ahh thanks ;) [22:29:26] "toolwatcher is running" ... hmmm [22:30:55] J-Mo: I *think* that replica.my.cnf is created by the replica DB servers; that's Coren's domain. [22:30:57] Coren: ^ [22:32:12] scfc_de: and since the initial connection to the proxy server will be over the network, I don't know how to have it auth the user [22:32:25] identd sounds like something that *might* work there, but I dunno how much I should rely on it [22:35:26] YuviPanda: Oh, that's a brilliantly simple solution with "toolname/" :-). Re identd, a quick googling suggest only security issues regarding user existence, and that wouldn't be a problem on Labs. You would have to cater for requests from non-Tools hosts, though. [22:35:44] scfc_de: 'non-tools hosts'? [22:37:00] YuviPanda: Suppose I install an instance in another Labs project with my own fake identd, contact your proxy and redirect all traffic to "yuvipanda/tool" to my Labs instance. [22:37:11] aah, right [22:37:13] indeed [22:37:32] Or direct to a tools-exec node, but to a port I control. [22:38:05] scfc_de: well, only *new* registrations. Older ones will need to provide the token to do any changes, which they won't have :) [22:38:16] YuviPanda: I think Coren offered his security experience to you, and you should probably take it :-). [22:38:30]