[00:31:58] [bz] (8NEW - created by: 2Antoine "hashar" Musso, priority: 4Highest - 6major) [Bug 48501] [OPS] beta: get SSL certificates - https://bugzilla.wikimedia.org/show_bug.cgi?id=48501 [00:37:32] Why isn't the prefershttps ("Always use a secure connection when logged in") preference on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences? [00:37:38] It is enabled, it's just somehow hidden. [00:37:48] But not through the mediawiki-config repo, apparently. [00:37:58] I'd like to turn it off since HTTPS on Beta is broken. [06:43:57] Coren: so still around? [08:17:38] someone install 'ack' package on tools please :) [08:21:14] llida: isn't it ack-grep ? [08:21:35] possibly that, it would make 'ack' command available though [08:21:45] that is shorter to type [08:24:42] ACK is a highly versatile Kanji code checker/converter [08:24:49] i think it's what hashar said:) [08:24:58] llida: ack is already used by another package, so on Debian ack-grep is to be used [08:25:04] hashar: i remeber you once had a patch to add that [08:25:05] llida: BUT you can use a local hack if you want [08:25:07] what happened to it [08:25:28] llida: what I did is that in my .bashrc I have added something like: PATH="~/bin:$PATH" [08:25:35] created a directory bin in my homedir [08:25:39] ooh. I understand. [08:25:46] and then created there a symbolic link named 'ack' pointing to ack-grep [08:25:47] OR [08:25:51] even simpler: use an alias [08:25:57] alias ack=ack-grep [08:26:01] (in your ~/.bashrc) [08:26:03] yeah alias [08:26:44] mutante: my patch got rejected because ack-grep was not to be installed everywhere. Eventually mark changed his mind after several devs begged for it [08:27:07] mutante: the ack symlink in /usr/local/bin hasn't been made though :) [08:27:14] i see.. but so you have the package [08:29:20] there was a page that asked to include this notice on every user-facing bit of the tools -- https://www.mediawiki.org/wiki/Wikimedia_Labs/Agreement_to_disclosure_of_personally_identifiable_information [08:29:27] what page asked that? [11:26:38] Hi, I have an account on WMF Labs but I can't login to Wikimedia Gerrit. [11:26:52] I need to do so because I'd like to submit a new version of a patch for pywikipedia. [11:35:30] Coren: I'm not able to login to gerrit.wikimedia.org using my Labs username and password. [11:40:02] pietrodn: hi [11:40:26] I'm working for wmf as well [11:40:31] :) [11:41:39] jiabao: hi! :) [11:42:02] jiabao: do you have any clues for this problem? The login should be unified via LDAP… or not? [11:42:34] I am using the same credential that I use for Labs wiki login [11:42:47] mm.. i had a lot of problems with gerrit before [11:43:01] let me check 1 second [11:45:25] did you sign up for developer access? [11:45:38] I have shell access on Tool Labs [11:45:47] I signed up via the wiki [11:46:44] pietrodn: you mean login in the browser or is the problem when you are trying to submit a patch [11:47:42] via https://www.mediawiki.org/wiki/Developer_access "sign up for developer access"? [11:48:50] jiabao: if I try I get "username already in use" [11:49:00] for me was first sign up from there, and after one day someone gave me a permission, then recently I got the lab access [11:49:18] I created my account on Labs months ago [11:51:19] https://www.mediawiki.org/wiki/Talk:Developer_access [11:51:54] the user name may be different from your shell name [11:52:08] and mediawiki name [11:52:34] Wiki user name is "Pietrodn", shell name is "pietrodn". I tried both on Gerrit. [11:53:14] mutante: I have problem logging in with the browser on Gerrit. [11:55:44] just double check, you can log in this page here, right? https://wikitech.wikimedia.org/wiki/Main_Page [11:55:56] the lab [11:58:59] pietrodn: that page has a reset password option available as well may have a try of that [12:00:38] pietrodn: need to go, sorry didn't really help much. wish you work it out soon =D [12:02:11] jiabao: ok, I'll try it. Thanks! [13:44:11] YuviPanda: hello :) [13:44:16] hey hashar [13:44:17] YuviPanda: got a grrrit change pending for you https://gerrit.wikimedia.org/r/85404 [13:44:26] oh, damn [13:44:27] let me +2 [13:44:29] hardcode some "sane" defaults for the irc connection [13:44:41] _.defaults from underscore seems to work properly according to my lame test [13:44:51] hashar: if you're interested, I can give you +2 on that erpo [13:44:52] *repo [13:45:01] (03CR) 10Yuvipanda: [C: 032 V: 032] provide sane configuration defaults [labs/tools/grrrit] - 10https://gerrit.wikimedia.org/r/85404 (owner: 10Hashar) [13:45:03] done [13:45:08] \O/ [14:05:01] hi Coren [14:05:09] Heyo. [14:05:41] Coren: re yesterday's topic of jsub on exec: [14:06:08] I made a script like http://pastebin.com/a10U8PiP and expect it to be used as if it's the php command [14:06:37] however it creates a big delay on startup: http://pastebin.com/HRiidubS [14:07:28] and the fact that I can't communicate with my subprocess stops me from reusing subprocesses (keep it running and talk to it with stdin/stdout) [14:20:55] liangent: Ah, you're right that if you need to keep stdio open to the process, that won't work. [15:37:16] [bz] (8NEW - created by: 2Antoine "hashar" Musso, priority: 4Highest - 6major) [Bug 48501] [OPS] beta: get SSL certificates - https://bugzilla.wikimedia.org/show_bug.cgi?id=48501 [15:41:35] [bz] (8RESOLVED - created by: 2Chris McMahon, priority: 4Unprioritized - 6major) [Bug 54671] VisualEditor opt-in preference disappears - https://bugzilla.wikimedia.org/show_bug.cgi?id=54671 [15:44:00] YuviPanda, can you link me to the invisible unicorn API doc? I've misplaced the page. [15:44:08] andrewbogott: moment [15:44:18] andrewbogott: https://wikitech.wikimedia.org/wiki/User:Yuvipanda/Dynamic_http_routing/API [15:44:27] thx [15:50:16] YuviPanda, does your backend support an empty list of backends for a given proxy name? [15:50:49] andrewbogott: shouldn't crash. Should be a NOP [15:51:17] Ah, but the question is -- when I list all mappings later, will I get that proxy in the list? [15:51:22] andrewbogott: you can curl things to port 5000 on proxy-dammit to check? [15:51:27] andrewbogott: you should, yeah. [15:51:34] I'm imagining a gui with two steps -- one that adds proxies, and then a per-proxy link to add a host [15:51:41] andrewbogott: yeah, sounds about right [15:51:46] In which case proxies w/out assigned hosts need to persist. [15:51:55] yeah, that should persist [15:52:02] ok. [15:52:09] test tho :D [15:52:13] I should write tests for it sometime [15:53:26] I'm also thinking about multi-datacenter issues… [15:53:34] andrewbogott: such as? [15:53:36] Presumably a given proxy name should be able to map to instances in multiple datacenters [15:54:00] But when adding backends the user will have to specify which datacenter the backend is in... [15:54:11] andrewbogott: ah, so .pmtpa.wmflabs vs .eqiad.wmflabs? [15:54:15] right [15:54:22] andrewbogott: you can add IPs instead? or something else that'll stay constant. [15:54:34] andrewbogott: I think this is going to be a general labs-wide problem eventually... [15:54:45] Presumably the user will want to pick an instance name from a list though. Rather than specify backends freeform. [15:54:50] right [15:54:57] And I think we can have the same instance name once per datacenter. [15:55:11] So… no big deal, it'll just make that picklist byzantine. [15:55:35] Ryan_Lane, is that right that our current setup allows both foo.pmtpa.wmnet and foo.eqiad.wmnet? [15:55:51] heh [15:56:48] Most of our existing web pages display datacenter front and center… but we don't want that since we don't want to specify data center for a given proxy name. [15:57:04] (Um… I'm just looking at https://wikitech.wikimedia.org/wiki/Special:NovaAddress and thinking about how that interface does and doesn't apply.) [15:57:07] we don't have anything in eqiad now do we? [15:57:10] in labs, that is [15:57:25] i'm pretty sure I can't see that :P [15:57:33] Not at the moment. Soon everything will move from pmtpa to eqiad [15:57:41] Oh, I think you can if you're project admin in any projects... [15:58:52] oh, right, I see it [15:59:15] Basically the 'allocate ip' link would instead be 'new proxy' [15:59:34] And then the per-proxy actions would be add/delete host [15:59:42] And the datacenter sections have to go. [16:00:18] andrewbogott: so, I'm thinking we should restrict it to a 1-1 mapping - one host per hostname [16:00:36] Oh? [16:00:45] andrewbogott: because I think in v2 of the proxy that's how it will be - and that we will get URL routing in return [16:00:46] In theory we can do many:many can't we? [16:00:52] andrewbogott: oh, yeah. [16:01:03] andrewbogott: right now in practice we can do many to many [16:01:13] andrewbogott: but in v2 that can only be many to one (hostname -> host) [16:01:18] I thought you had some load-balancing stuff in there that you wanted to use. [16:01:25] andrewbogott: yeah, there is loadbalancing stuff now [16:01:32] andrewbogott: but more people want url routing than load balancing [16:01:42] and i'm not sure how to have url routing *and* load balancing while also beign performant [16:01:51] * andrewbogott doesn't really know what url routing is. [16:01:55] andrewbogott: so I'm considering ripping out load balancing in v2 [16:02:05] OK, well, that certainly makes the GUI simpler! [16:02:19] andrewbogott: 'if path starts with /parsoid, route to port 8000 on host A, else route to port 80 on host A' [16:02:23] that's url routing [16:02:33] Ah, I see, like vhost config [16:02:38] pretty much. [16:02:48] since a lot of people run multiple services in one host. [16:02:51] Will users want freeform control of port #, or should it just be http vs https? [16:03:08] andrewbogott: let's provide them freeform control. [16:03:12] andrewbogott: yeah, it should allow the same name in both [16:03:21] ok [16:03:29] it should only check the FQDN [16:03:34] andrewbogott: since nginx also supports things that aren't http / https - primarily, uwsgi (which anyone doing python should use, for example) [16:03:47] Um… one backend per hostname means only one /port/ per hostname as well. That OK? [16:03:54] andrewbogott: for now, yeah. [16:03:58] 'k [16:04:59] Ryan_Lane, we're talking about if we provide a picklist of hostnames for a given project… that picklist will have to specify datacenter/hostname or display the fqdn to avoid ambiguity. [16:05:16] Unless there's some step that enforces hostname uniqueness within a project [16:07:25] ah. [16:07:33] I'd display the fqdn [16:07:38] 'k [18:33:46] hi, I'm looking for user_properties table in the replicas available in labs. I know it contains private data, so it may not contain all the columns, but in the toolserver there was user_properties_anonym. is there something similar in labs? [18:55:20] !ping [18:55:20] !pong [19:23:03] Hi! Is there a schedule when we will be able to run WSGI scripts on tools? [19:34:09] [bz] (8ASSIGNED - created by: 2Yuvi Panda, priority: 4High - 6normal) [Bug 49058] Support WSGI for Running Python Scripts - https://bugzilla.wikimedia.org/show_bug.cgi?id=49058 [19:55:43] eranroz: nope :( [19:59:44] [bz] (8NEW - created by: 2Antoine "hashar" Musso, priority: 4Highest - 6major) [Bug 48501] [OPS] beta: get SSL certificates - https://bugzilla.wikimedia.org/show_bug.cgi?id=48501 [20:03:50] Would there be any reason I don't have a "~/php_error.log" for a tool, aside from "You really broke it, sucker!" [20:04:30] Coren: ^ [20:05:28] I really do think I really broke it… problem is my code works locally. This is a dev tool, so I'm not that concerned, but still... [20:05:35] Matthew_: As a rule, it will only end up being created at the time the web server decides you're actually invoking a php; there are a few things that can prevent it from going that far -- bad permissions or funky .htaccess are the most likely culprits. [20:06:13] Matthew_: In particular check that the script is (a) owned by the tool and (b) executable. [20:06:13] Coren: OK, that makes sense. I just uploaded, using my username and Cyberduck. Would there be something else I would need to do? (never done this for PHP, only static HTML files) [20:06:51] Matthew_: Ah, then definitely you want to change the owner of the file to the tool. From the tool account, do a "take thefile.php" [20:07:13] Coren: OK, that makes sense. Can that be done recursively? [20:07:44] Matthew_: It's recursive by default; "take ~/public_html" is probably what you want. [20:08:13] Coren: OK. Standby, let me try it. [20:08:46] No output, which I assume is a good sign. [20:08:58] It's better than a 500, for sure. :-) [20:09:28] Still getting a 500, but now I have an access.log… so let me check permissions. What do you recommend? [20:09:39] Oh, you mean for 'take'. Yes; it uses the Unix small tool principle: "shut the fuck up unless something goes wrong" [20:09:52] Which is nice ^^ [20:11:09] The scripts needs to be x and r for all; 0775 is usually a good mode. [20:11:27] (Because that lets the maintainers still write to them at need) [20:13:33] OK, Coren, that appears to have worked. My tools are broken still, but it's on my end now. Thank you so much! [20:14:27] As long as it ends up in your php_error.log, debugging is generally not that painful. [20:16:13] Yeah, I just figured out I missed a file :/ [20:16:24] Oh, hey, is the 404 page supposed to generate two complete pages? [20:16:41] "Two complete pages"? [20:16:47] View source on http://tools.wmflabs.org/matthewrbowker-dev/cgi-bin/css.php?color=000000 [20:17:05] You're declaring two doctypes... [20:17:12] And two [20:17:17] And so on... [20:17:26] Unless that's just on my end. [20:17:47] No, I see it too. Chrome helpfully ignores the insanity, so I never noticed. [20:19:07] Yeah, Firefox too. I only figured it out when I was trying to figure out why my styles weren't displaying. [20:19:59] Fix't [20:22:13] Coren: Nice. It's not validating (I'm looking at a 500) because you're missing a closing But other than that, thank you :) [20:26:05] Also fix't. [20:26:19] Coren: That's wonderful, thank you! [20:27:07] Fixing small and mostly static html rates about 0.03 on the effort-o-meter. [20:27:30] Yeah, but it's one of those things that's a huge difference :) [20:29:49] Is Java servlet supported on Labs? If not, is it planned? Coren? [20:29:56] s/Is/Are/ [20:30:51] Coren: Also, what's up with cgi-bin? I keep 404-ing, is that configured special? [20:31:25] Hm. You're the first to ask for the idea; I suppose we could look into making a tomcat available, but that's not a small project to do right. [20:31:50] Matthew_: Shouldn't be; /yourtool/cgi-bin/blah [20:32:00] Should map to ~yourtool/cgi-bin [20:32:08] (And not public_html/cgi-bin mind you) [20:32:14] Coren: Huh… cuz I have all my stuff in ~/public_html/cgi-bin [20:32:23] Huh, ok. Looks like I'm fixing my requires XD [20:32:45] Coren: well, if I get the proxy done, we can run tomcat on the grid... [20:32:46] :D [20:33:25] yuvipanda: I'd rather have tomcat instances than fire up that monstrosity through the grid. :-) [20:33:43] :P [20:33:58] tomcat is... not lightweight. [20:34:18] (Better than JBOSS, but that's just because it sets the bar so low) [20:34:29] heh [20:34:34] thankfully i've not had to do any of those [20:34:45] Coren: but bewarned, I'm slowly falling in love with Scala, which is JVM based... :D [20:34:58] Coren: Well, there is one Java tool, written by [[:de:user:°]], that I am hosting on the toolserver (as he does not have a Toolserver account): https://toolserver.org/~isbn/ [20:35:17] Coren: it would be great if I could transfer it to labs [20:35:42] Coren: Huh, now throwing internal errors. I moved the entire folder, so it should have the proper permissions and stuff right? [20:35:56] (Sorry, I'm still trying to get my head wrapped around Labs. TS was so easy :/ ) [20:36:46] Matthew_: It should; but if you're doing PHP you almost certainly don't want to bother with cgi-bin at all; that's really just for random executables that aren't handled by php or python. The latter two should really just go in public_html [20:37:20] Coren: Yeah, I learned old-school… I put all my config files in there so people can't get in there… [20:37:43] I'll move them into another folder then... [20:37:43] That... is a rather odd way of doing it. :-) [20:37:58] Heh, I learned on my own and stuff, so I'm probably not going by convention XD [20:39:00] ireas: Hm. Honestly, you're the first who reports the need for a java servlet; I didn't even know the TS had support for it. [20:39:17] Coren: yes, it had, see my link above ;) [20:40:24] Heh, and it's probably too late to ask this, but I'm allowed to have a matthewrbowker-dev and a mattherbowker? The former being a testing tool the latter being my live tools? [20:40:36] Matthew_: Yes. :-) [20:40:49] Coren: Nice, thanks :) [20:41:27] ireas: Out of curiosity, how is the redirect/proxy to the servelet done? [20:41:48] ireas: Ohwait; toolserver has a funky Sun web server doesn't it? [20:43:36] Coren: they once had a Zeus web server; but I am not sure if they still have it. I do not remember how I configured the servlet; but here’s the documentation: https://wiki.toolserver.org/view/Java_hosting [20:43:59] Bleagh. Glassfish. [20:44:04] * Coren ponders. [20:44:16] Yeah, we'll have to deploy a tomcat. [20:45:37] ireas: Well, it /wasn't/ planned but now it clearly has to be. [20:46:08] As well as some mechanism to deploy WARs securely. [20:46:26] * Coren idly wonders how many tools are servelets. [20:46:37] Coren: maybe DaB. could tell us how many people actually used it on the toolserver [20:48:06] Not that it's all that important. It's clearly >0 [20:48:27] but maybe it’s < 2 ;) [20:49:21] so should I just file a bug? then you can decide whether and if yes, how and when you want to install and configure it [20:50:18] Yes, please do. I don't think whether is much of an option. [20:53:15] [bz] (8NEW - created by: 2Robin Krahl, priority: 4Unprioritized - 6normal) [Bug 54845] Add support for Java Servlets on Tool Labs - https://bugzilla.wikimedia.org/show_bug.cgi?id=54845 [20:53:21] ... why does the toolserver page have a hatnote reading "Note: This page is wrong. The Toolserver still uses Tomcat. It does not use GlassFish." instead of having the text of the page say Tomcat? :-) [20:53:51] On the plus side, it means I needn't wory about funky proprietary GlassFish incompatibilities. [20:54:12] lol… I ignored that box :D [20:57:18] Coren: ok, thanks! I’ll stay tuned. :) [20:57:22] #join xlabs [20:58:18] oops [20:58:48] irc [20:58:56] Any roots around? i found a security issue that should be addressed ASAP [20:59:08] multichill: PM [21:07:07] [bz] (8NEW - created by: 2Maarten Dammers, priority: 4Unprioritized - 6normal) [Bug 54847] Data leakage user table "new" databases like wikidatawiki_p and the wikivoyage databases - https://bugzilla.wikimedia.org/show_bug.cgi?id=54847 [21:45:32] Guh… take just broke for me… "vars.local-dev.php: You need to share a group with the file" [21:46:32] exit [21:47:21] eranroz: Was that to me? [21:47:27] ops no :) [21:47:33] it was to the shell :) [21:47:35] eranroz: OK, no worries :) [21:48:00] Hahahaha, done that. It's quite interesting to explain "ps -u mbowker" to a friend… after you iMessage it to them. [21:48:48] :) [21:51:37] Coren: Halp! (I'm sorry I'm being so demanding...) [21:58:17] Matthew_: Sorry, can't help just this minute but I'll be with you shortly. [21:58:30] Coren: That's fine, thank you :) [22:21:24] Whoops, I have to step away for a few. I'll be back later. [23:09:31] Uuuuuug, OK, still the same issue. Does anyone have any idea what "vars.local.php: You need to share a group with the file" means when I take? [23:09:46] And if so, how to fix it?