[01:01:05] 4Wikimedia Labs: Initial instance creation leaves a non-Puppet-controlled, dysfunctional gmond process behind - 10https://bugzilla.wikimedia.org/64216 (10Tim Landscheidt) 3NEW p:3Unprio s:3normal a:3None After the initial instance creation, a gmond process exists: | root@toolsbeta-gmond-test:~# ps $(c... [01:22:21] 4Wikimedia Labs 3wikitech-interface: Log claims shell right has been given, but form not - 10https://bugzilla.wikimedia.org/64218 (10Tim Landscheidt) 3NEW p:3Unprio s:3normal a:3None I tried to process the automatic shell request for [[wikitech:User:Gallilama]] at [[wikitech:Special:UserRights/Gallil... [01:56:21] 4Wikimedia Labs 3tools: webservice creates blocking files and jobs when called from a user account with an eponymous tool - 10https://bugzilla.wikimedia.org/64219 (10Tim Landscheidt) 3NEW p:3Unprio s:3normal a:3Tim Landscheidt When a user X is a member of the tool tools.X and he calls "webservice sta... [04:01:07] 4Wikimedia Labs 3wikitech-interface: Log claims shell right has been given, but form not - 10https://bugzilla.wikimedia.org/64218#c1 (10Andrew Bogott) I just visited that page, and it is checked. For you too? [08:12:08] 4Wikimedia Labs 3Infrastructure: Virtual image for Ubuntu Trusty (14.04) - 10https://bugzilla.wikimedia.org/60684 (10Antoine "hashar" Musso) [08:13:28] uh .oh.. new bot? wow [08:13:44] how does it get updates ? [08:14:26] mutante: through RSS I believe :-] [08:15:25] mutante: I talked about it with Merlijn van Deen (valhallasw) [08:15:42] hashar: very nice [08:15:51] mutante: and how he should not waste his time with the old perl based wikibug :D So I guess he has been bold and created a python based bot that consume the RSS feeds [08:16:13] yay!:) [08:16:29] thanks for that, all those wikibugs bugs [08:16:40] if they can be resolved soon that would be great [09:35:02] * Beetstra looks at Coren, petan .. etc. [09:35:18] My bot throws a ".. returned error: Closing Link: 208.80.155.255 (Too many user connections (global))" upon connecting to IRC [10:28:25] mutante: it might be parsing emails too. He was asking about how to do that on toollabs a while ago. should be faster than the RSS [10:30:07] yuvipanda: in that case i wonder how it gets all the mails, the old bot ran directly on mail server [10:30:14] but maybe global bcc [10:30:20] true. [10:30:26] (as long as it doesnt report security issues, heh) [10:31:13] Beetstra: ugh, sounds like we need an exempt for that IP from freenode [10:31:39] but since we also run a freenode server.. i expect they do that [10:43:55] mutante - maybe for all IPs running bots? [10:44:29] Beetstra: yea [10:54:15] mutante: it's actually still e-mail based [10:54:28] it just runs from wikibugs-l [10:54:45] https://github.com/valhallasw/pywikibugs [10:55:18] valhallasw: ..to redis.. oh nice! [10:55:29] unless redis breaks down, in which case everything breaks down :-p [10:55:41] !pywikibugs us https://github.com/valhallasw/pywikibugs [10:55:47] !pywikibugs is https://github.com/valhallasw/pywikibugs [10:55:47] Key was added [10:58:22] valhallasw: thanks for working on that, maybe you can kill some of these after testing https://bugzilla.wikimedia.org/buglist.cgi?component=wikibugs%20IRC%20bot&list_id=308502&product=Wikimedia&resolution=--- [10:58:52] valhallasw: should probably use a redis list than pub/sub. I might submit patches soon :) [11:00:29] yuvipanda: not sure -- I chose the pub/sub *because* it doesn't keep old items in queue. [11:00:36] valhallasw: why so? [11:01:14] because you don't need all messages - you just want messages that are happening *now* [11:01:33] you don't want all the messages from the last hour if the bot was down for an hour [11:16:51] valhallasw: ah, hmm. [11:16:54] valhallasw: right. [11:21:44] valhallasw: can you add me to the project? :D [11:42:39] yuvipanda: and pub/sub doesn't need polling, although just popr'ing once a second should be OK too. [11:42:56] valhallasw: rbpop isn't polling either, no? [11:43:02] valhallasw: it's just waiting, blocked for a push. [11:43:35] oh, that's true [11:43:43] so in that respect it doesn't really matter [11:43:46] indeed. [11:43:57] another advantage of pub/sub is that it allows multiple listeners [11:43:57] I guess ultimately it is down to 'are we ok with losing bug notifications or not'? [11:44:02] yeah [11:44:12] valhallasw: right, but it is trivial to publish to two queues. [11:44:39] I personally like not losing them, but that's fine I guess :D [11:44:43] yeah. toredis.py event supports that directly :-) [11:44:54] even* [11:45:07] ok, you're now both in the service group and a github maintainer [11:45:13] woot! [11:45:19] valhallasw: yeah, that's a nice bit of code! [11:48:07] valhallasw: ' for fn in sorted(glob.glob("000359.raw")): ' [11:48:46] *grin* [11:48:52] that's what we call debug code [11:49:07] (this makes it easy to switch between *.raw and .raw) [11:49:16] haha [11:49:16] right [11:49:37] the code could use some cleanup [11:49:45] yeah. [11:49:54] now if you could import the bugs from redis to phabricator ... /me hides [11:50:08] hehe [11:50:11] mm, [11:50:16] that shouldn't be too hard, actually [11:50:16] mirror the changes to phab? that would be an interesting idea :p [11:50:25] but you'd want to pushr them in that case [11:50:34] yeah. [11:50:37] just mirror new bugs [11:50:39] hmm [11:50:41] and discussions [11:52:16] mutante: we need to get https://fab.wmflabs.org/ fixed [11:52:44] I think adding a phab listener to pywikibugs is more useful tbh :p [11:52:57] but the phab api is... *puke* [11:54:08] heh [11:54:20] I should setup an auto-update job for a full mediawiki/extensions clone in tools [11:54:25] yuvipanda: what part of "fixed" do you mean [11:54:39] thinks it needs to be puppetized [11:54:43] mutante: the https. It doesn't seem to be using protocol relative URLs [11:54:46] I see no styles [11:54:56] yuvipanda: who installed it? [11:55:05] mutante: not sure. ^demon|zzz perhaps [11:55:52] maybe that was related to replacing star.wmflabs.org cert (not using procol relative urls) [11:56:21] eh.. works for me? [11:56:32] ah, hmm [11:56:38] maybe an old cached version or somesuch for me? [11:56:53] yea, maybe,it was a self-signed cert [11:56:56] then it became a rel one [11:56:59] real [11:57:30] oh, you know, because of yuviproxy [11:57:31] mutante: this one has always used star.wmflabs.org cert [11:57:37] since this was done after the proxy [11:58:20] that cert was replaced after fab was already installed [11:58:34] but maybe i missed update [11:59:13] anyways, i think all fixes to that test instance that are manual will have to be re-added anyways [11:59:58] could start by adding the main config file [12:00:09] hmm, right [12:14:07] mutante: hmm, pushing to fab.wmflabs.org won't work at all, since it doesn't have a public IP! so people can't push things throuhg ssh [12:15:27] yuvipanda: if there are good reasons labs projects can have public IPs [12:15:34] mutante: yeah, this should have one. [12:15:44] anyone around who can add me to the phabricator project? [12:17:16] yuvipanda: project name? [12:17:26] mutante: unsure. phabricator? [12:17:29] or 'fab' [12:18:05] doesnt match anything in project filter [12:18:10] can you see from the proxy config? [12:18:13] which instance is behind it [12:18:28] mutante: ah, yes of course! [12:18:29] looking [12:18:30] looks for subdomains [12:18:34] ah, cool [12:19:43] wat, I can't login to dynamicproxy-gateway?! [12:20:08] yuvipanda: eh.. further locked down because it has real ssl key now? [12:20:30] but you being the proxy should have it :p [12:20:41] mutante: nope, I'm projectadmin [12:20:53] issue with home dir? [12:21:15] mutante: nah, fixed it. was playing with my .ssh/config to check if i can get fab.wmflabs.org to work, but then realized it was behing proxy [12:21:21] ok [12:22:54] mutante: fab2.eqiad.wmflabs [12:23:06] mutante: i can find out project too [12:24:30] mutante: aha! it is in the 'gerrit' project [12:24:57] mutante: of which I'm not a member :( think you can add me? [12:25:00] yuvipanda: thanks! and .. arrr.. should we start out with a new project? [12:25:06] that too [12:25:09] mutante: to puppetize it? [12:25:09] hold on [12:25:18] mutante: I want to get it to work first and see how it is before we start on that [12:25:24] to create multiple instances all related to phab [12:25:53] ok [12:26:14] mutante: yeah, separate project makes sense. but we need to figure out who did this first [12:26:35] !log gerrit - adding dzahn [12:26:57] !log gerrit - adding yuvipanda [12:27:02] woot! [12:27:10] Logged the message, Master [12:27:11] Logged the message, Master [12:27:28] mutante: can I be projectadmin? :) [12:27:32] ack, and i wanted to see the config file that is currently used [12:28:07] !log gerrit making yuvipanda and dzahn project admins [12:28:08] Logged the message, Master [12:28:12] woot! [12:28:58] yuvipanda: [12:28:58] 05:03 ^d: upgraded libssl on phabricator [12:29:08] that is from project specific SAL [12:29:21] ah, hmm [12:30:49] ehe, there is just 1 instance in 'gerrit' [12:30:53] and that isn't gerrit:) [12:30:56] afaict [12:31:04] recycled project [12:31:25] mutante: hehe [12:31:32] mutante: btw, can you give it a public IP? [12:31:35] as in, grant quota [12:36:44] !log gerrit - raise quota for floating IPs to 1 [12:36:46] Logged the message, Master [12:36:50] yuvipanda: now i could :) [12:36:56] mutante: woo! [12:37:13] cool! [12:37:14] associating now [12:37:16] needed to figure out new syntax [12:37:18] mutante: we will lose ssh tho [12:37:22] root@virt1000:~# nova quota-show --tenant gerrit [12:37:56] yuvipanda: i'm not logged in anyways [12:37:56] 4Wikimedia Labs 3tools: commonshelper webservice not working - 10https://bugzilla.wikimedia.org/64095#c1 (10zhuyifei1999) Related to http://lists.wikimedia.org/pipermail/labs-l/2014-April/002305.html ? [12:38:26] !quota [12:41:34] ok, now to wait for my dns to expire [12:41:55] !quota is virt1000 - nova quota-show --tenant | nova help quota-update [12:41:55] Key was added [12:43:59] !gerrit public IP for attempted Bugzilla->phabricator import via redis (pywikibugs) [12:43:59] https://gerrit.wikimedia.org/ [12:44:04] !log gerrit public IP for attempted Bugzilla->phabricator import via redis (pywikibugs) [12:44:06] Logged the message, Master [12:45:22] mutante: bah, now I've to wait for my apps' caches to clear [12:45:58] no rush [13:11:40] mutante: lol. phabricator requires a newer sshd to work properly (6.2) [13:12:33] yuvipanda: uh? sigh [13:12:43] mutante: needs 6.2, 12.04 has 5.9 [13:12:56] mutante: so I'm doing the responsible thing and building it from source [13:12:57] * yuvipanda hides [13:13:21] Ryan_Lane: hey! I remember you were doing something with trusty images for labs, right? [13:13:45] yuvipanda: make a new instance with trusty? [13:13:51] do we have images yet? looks [13:13:56] mutante: don't think so [13:14:03] and what is sshd version on 14.40 LTS [13:14:08] .04 [13:14:25] I checked. quintal+ should be ok I think? [13:15:44] yuvipanda: let's make it a phab/maniphest issue [13:15:49] "need newer sshd" [13:15:51] hah! [13:16:18] mutante: I have compiled it. [13:16:45] openssh (1:6.6p1-2ubuntu1) trusty [13:16:59] calls it proof of concept then [13:24:02] I tried to access ssh -A ahokvigneshk@tools-login.wmflabs.org but showing If you are having access problems, please see: https://wikitech.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey,hostbased). [13:24:18] Can you help me how to access? [13:28:21] Akki: this is always shown, unless you use -q [13:29:03] oh, wait [13:29:15] i didn't see the permission denied part [13:30:02] How to access wikimedia labs using tool project [13:31:56] 4Wikimedia Labs 3tools: commonshelper webservice not working - 10https://bugzilla.wikimedia.org/64095 (10Steinsplitter) p:5Unprio>3High [13:33:26] 4Wikimedia Labs 3tools: commonshelper webservice not working - 10https://bugzilla.wikimedia.org/64095 (10Steinsplitter) [13:33:59] I tried to access ssh -A ahokvigneshk@tools-login.wmflabs.org but showing If you are having access problems, please see: https://wikitech.wikimedia.org/wiki/Access#Accessing_public_and_private_instances Permission denied (publickey,hostbased). [13:34:17] Can you help me how to access? [13:39:48] mutante: hmm, I am trying to create a 'git' user on that machine, and keep getting NFS errors [13:46:00] how do I make my proxy server known to bastion (as per https://wikitech.wikimedia.org/wiki/Help:Access_to_instances_with_PuTTY_and_WinSCP) ? [13:53:50] Coren: ^ should yuvipanda do something special (not create system user by hand) or does that sound like actual NFS issue ? [13:54:11] * Coren reads up. [13:54:17] it's not toollabs, sry [13:54:25] just this [13:54:27] 06:40 < yuvipanda> mutante: hmm, I am trying to create a 'git' user on that machine, and keep getting NFS errors [13:54:42] mutante: seems to work now, so intermittent NFS issue? [13:54:44] oh no [13:54:45] doesn't anymore [13:54:54] sounds intermittent :p [13:54:57] Ah; the NFS server needs to know the user. Easiest way to fix it is to create it in LDAP as I did with other system users. [13:55:05] https://dpaste.de/W0xE [13:55:05] It really shouldn't be intermittent though. [13:55:19] Coren: can you create a 'git' user? [13:55:35] aha.. see, i was thinking "there is likely something with system users and just creating them manually" [13:55:45] vaguely rememberd issues from the past [13:56:04] yuvipanda: Sure; give me a minute. [13:56:24] :) [13:56:25] ok! [13:57:57] yuvipanda: Well, hang on first. Do you actually /need/ that user to own files on NFS? [13:58:17] Coren: no, I don't. Just needs access. [13:58:20] yuvipanda: Because right now the only issue you have is that you are trying to create its home in /home/ which you really shouldn't. [13:58:25] hmm [13:58:26] that's true [13:58:36] but there's stuff in /data/project it will read, and I guess that's ok? [13:58:43] I can just specify a different /home [13:58:58] You can read, certainly, but it'd be as 'nobody'. Is that okay? [13:59:09] should be fine for now [13:59:18] Coren: I'm just playing around with the fab instance, making it actually 'work' [14:00:00] I'll only create a global user if it turns out you actually need it then; I want to keep the number to a minimum. [14:00:27] 4Wikimedia Labs 3tools: commonshelper webservice not working - 10https://bugzilla.wikimedia.org/64095#c2 (10metatron) I've seen this problem before. lighttpd webservice stops, but old php-cgi processes remain. $webservice start then starts /one/ lighhtpd process, but can't start new php-cgi's. So plain html... [14:00:48] Coren: yeah, makes sense. I'll poke again if I can't do this with a user folder elsewhere [14:01:00] Coren: should I make its home be in /var or /etc? [14:01:17] yuvipanda: System user homes traditionally go into /var/lib [14:01:21] hmm, ok [14:05:12] 4Wikimedia Labs 3wikitech-interface: Log claims shell right has been given, but form not - 10https://bugzilla.wikimedia.org/64218#c2 (10Tim Landscheidt) 5NEW>3RES/FIX Yes (now). Mysterious ... If it were a caching issue with my browser (Chrome) it should have occured with all requests. [14:07:24] valhallasw: this bugzilla-bot is just awesome :) [14:07:33] Coren: can you tell me how I get around the blank screen when I plink to stewardbots (seems to be the situation expressed in the hint at https://wikitech.wikimedia.org/wiki/Help:Access_to_instances_with_PuTTY_and_WinSCP) [14:07:59] Coren: yuvipanda: time to fix this proxy ////// issue ? [14:08:07] sDrewth: I'm not sure I understand what you mean by "blank screen"? [14:08:28] I get a screen with a cursor top left [14:08:31] and nothing else [14:09:23] I am presuming that I am needing to get to the instance "stewardbots.eqiad.wmflabs" [14:09:39] Hm. I guessing you mean your terminal window remains blank with no activity? (plink is an ssh client for macs right?) [14:09:57] putty [14:10:02] sDrewth: Likely, but you'll need to hop on a bastion first. [14:10:29] okay, please describe that process for this luser [14:10:53] hedonil: true. it shouldn't be too hard to hardcode [14:11:14] yuvipanda: sounds promising! [14:11:47] match everything that is tools.wmflabs.org/ and redirect to same + / [14:11:53] with a permanent redirect [14:12:20] hey ^d. I've been messing around with the test fab instance trying to get the code review stuff to work. [14:12:31] with hosting on the phab instance itself. just a fyi [14:12:39] <^d> k [14:13:15] sDrewth: As far as I can tell, the instructions you followed should be correct, but stewardbots.eqiad.wmflabs doesn't look like it exists. [14:13:51] yuvipanda: Nope. You can't do it without more logic -- only when matches a tool. [14:14:05] hmm, is the instance "tools" then? [14:14:08] Coren: what's the harm in not checking that? [14:14:50] yuvipanda: Anything served from the root, including /img/, /lib/, etc. [14:15:33] sDrewth: lemme try and find what your instance should be. [14:15:46] Coren: why so? I am proposing that anything that is tools.wmflabs.org/ be redirected [14:15:55] Coren: how will that ffect /img/ ? it won't match this since it has a / at end [14:16:19] of course, I could be completely fubar'd in what I am trying to do [14:16:51] Because /img/foo.png <-- no trailing slash. Or, for that matter, /robots.txt <- also no trailing slash. Or /whatever.ico and so on. [14:17:11] hmm, robots.txt makes sense [14:17:36] /img/foo.png won't be an issue since the logic will stop as soon as it finds the second slash in the entire path [14:17:37] You can't randomly redirect broken URIs to an added slash without expecting to break something. :-) [14:17:43] heh [14:17:44] either way [14:17:53] even otherwise is fairly simple if we do it in Lua [14:18:04] it's *super* simple to just have it return the same response, but that's not correct HTTP behavior [14:20:31] mutante: giving up on phabricator for now. Have a good number of things set up, but can't seem to ssh properly [14:20:35] hmm, one last thing [14:21:04] yuvipanda: the "second slash" thingy sounds good, as every tool has at least two slashes, and afaict this would suffice [14:21:26] hedonil: yeah, but it'll redirect robots.txt to robots.txt/ [14:21:28] and that's bad [14:21:47] * Coren honestly doesn't get why that's such an issue. [14:21:56] yuvipanda: yea, i might make the new project tomorrow , for today i'm also about to run [14:22:10] mutante: yeah. would be good if we can get the trusty image up before that tho [14:22:13] yuvipanda: cool though.. progress [14:22:18] agrees [14:22:19] Yeah, it's a good thing to provide a convenience redirect; but any link to / is -- by definition -- broken. [14:22:44] Coren: yeah, but it was working before so I think we should fix it [14:22:47] mutante: heh, yeah :) [14:22:48] yuvipanda: you can make a regex for this like 3 files in tools root [14:22:57] At best, the redirect makes it /look/ like it's working at the cost of an entire unnecessary http rountrip. [14:23:37] Coren: eg: every interwiki link like [[toollabs:]] is dead right now [14:24:38] hedonil: The interwiki should be fixed instead; that trailing / is really not optional. It's just that the setting atm constructs broken URIs. [14:24:58] Coren: and it's just a normal behaviour for a webserver to serve content if you enter http://foo.org [14:25:18] even if it's not 100% compliant to the standards [14:26:21] hedonil: That's actually not true. Your *client* adds the /, even if implicitly, because there is literally no way to not 'GET /' on the request. :-) [14:27:01] Coren: as yuvipanda suggested: second slash logic and regex exception for files directly in tools.wmflabs.org (all ~5 files) [14:27:39] Coren: yeah! I expect that to simply work. however it is done [14:28:14] to get a 500 now where you didn't get one some days before is no good ;) [14:28:28] Missing trailing slashes also break relative URLs. Heh. [14:28:45] But first, I shall fix the interwiki. [14:28:49] either way, I think we should fix. I am investigating solutions now. [14:29:41] sDrewth: I'm not seeing an instance named stewardbots (or variations on that); do you know which project it should be in? [14:39:11] 4Wikimedia Labs 3tools: "webservice stop" leaves blocking php-cgi processes behind - 10https://bugzilla.wikimedia.org/64095#c3 (10Tim Landscheidt) metatron is correct; I recently had to purge some old processes (cf. [[wikitech:Nova Resource:Tools/SAL#April 10]]). To fix Magnus' issue, I killed the blocking... [14:40:33] hedonil: try now. [14:40:36] should redirect properly [14:40:52] whelp [14:41:07] yuvipanda: hell yeah! works. thanks [14:41:14] coren it is clearly too much past pumpkin hour, and I shouldn't be doing this, I will leave it and regather my thoughts when I find them [14:41:21] thx for the look-see [14:41:21] hedonil: not for long tho. has issues. [14:41:37] yuvipanda: just testing my RESTful url rewrites now [14:41:42] yuvipanda: Has nginx a list of the tools with webservice? This would allow to limit the redirect to them which does not cover tools with no webservice, but that's probably not a bad idea either. [14:41:52] scfc_de: yup, it does. that's what I am doing. [14:42:16] Wonderful. [14:43:44] yuvipanda: rewrites also work :-) [14:44:02] hedonil: rewrites are baaad in this case. you'll end up with 2 HTTP 'resources' with same content [14:44:05] so has to be a redirect [14:45:08] yuvipanda: stopped working [14:45:20] hedonil: yeah, I reverted it since it broke other things. [14:45:22] slowly working on it [14:45:33] yuvipanda: 'k [14:54:55] hedonil: At the least, now, the interwikis now are fixed to point at the right place. [14:55:12] * hedonil checks [14:56:26] Coren: yeah looks good now. thx [15:00:20] hedonil: ok it was a bit more complicated than I had imagined, and I don't have a working test instance :( [15:00:25] don't think I'll be able to do that today. [15:01:03] yuvipanda: hmm. ok. thx [15:01:15] scfc_de: hedonil should be a trivial fix in urlproxy.lua if either of you are interested. I've an app releease coming up in a few days and need to spend some time with that :( [15:01:16] sorry! [15:09:42] yuvipanda: Just dump the code somewhere. [15:17:11] scfc_de: modules/dynamicproxy/files/urlproxy.lua in operations/puppet [15:22:20] Coren: I know, but yuvipanda committed only an indentation fix for that today :-). [15:26:51] scfc_de: /tmp/urlproxy and /tmp/def have appropriate changes on tools-webproxy ;) [15:26:57] scfc_de: and they kinda worked [15:27:56] 4Wikimedia Labs 3deployment-prep (beta): Use scap to deploy on apaches - 10https://bugzilla.wikimedia.org/63746#c10 (10Gerrit Notification Bot) Change 127399 had a related patch set uploaded by BryanDavis: Move beta scap source directory off of NFS https://gerrit.wikimedia.org/r/127399 [15:29:57] yuvipanda: Thanks. [15:30:36] scfc_de: :) [15:30:42] yuvipanda: (Though I don't see /tmp/urlproxy?) [15:31:02] scfc_de: tools-proxy-test also exists [15:32:16] scfc_de: hmm, seems to have been cleaned up somehow :| [15:33:05] scfc_de: boom, found it in my vimbackup. /tmp/urlproxy.lua now [15:33:05] <^d> yuvipanda: ...while you're working on the phab instance.... [15:33:11] <^d> Mind setting up something sane for SSL? [15:33:17] ^d: ah, so SSL *used* to work. [15:33:22] ^d: I just made it stop working. [15:33:28] <^d> Ah, we need SSL. [15:33:42] ^d: yeah. so if we have SSL we can't have a public IP and hence can't ssh things to it [15:33:46] ^d: and vice versa [15:33:59] ^d: with our current ssl proxy setup at least [15:34:49] ^d: I can get ssl back on now easily. I could never get ssh push to work (I feel it is close but something's missing), so I can just re-enable ssl in the meantime [15:35:00] <^d> What we need is a real home. [15:35:04] <^d> This can't live in labs forever :p [15:35:09] indeeeed [15:35:45] ^d: puppet deployed or packaged or...? [15:36:01] <^d> Well packages don't make a whole lot of sense. [15:36:08] right [15:36:19] <^d> Probably something with (git-deploy|trebuchet|tool-of-the-week) [15:36:24] right [15:36:33] tool of the week is.... scap! [15:36:34] err [15:36:35] scp [15:36:55] <^d> Well right now I just ssh to the instance, cd to /phab/ and git pull on a couple of directories. [15:36:55] <^d> :p [15:38:27] <^d> Anyway, ssl is important if we want to do auth properly. [15:40:06] ^d: heh :P but then we cant' test arc and the workflow there [15:40:11] ^d: that's what I wanted to test [15:40:16] <^d> Indeed. [15:40:37] <^d> Why can't we have SSL on the public IP? [15:41:03] ^d: so star.wmflabs.org shouldn't be on that instance - it is mostly really restricted. [15:41:15] ^d: so we could either do a self signed one or get a new cert just for this [15:41:34] <^d> Why can't we use star.wmflabs? [15:43:02] ^d: from what I remember, to prevent the private keys from being too widely available. [15:43:42] <^d> Then lock down the instance so people can't get at it? [15:44:48] we could do that. Remove people from it, etc. but still, it needs to be fairly hardened and we can't do too many things. [15:45:14] ^d: for example, phab requires sshd 6.2 at least. I just compiled it from source. I don't know if that's remotely close to secure. Don't know if ops will be comfy leaving the key there. [15:45:26] <^d> Hrm. [15:49:52] ^d: so I don't know of a solution. One thing would be to just get a new cert for fab.wmflabs.org. Not *too* expensive, I think. RobH handles those [15:50:17] doesn't we have a Labs CA? [15:50:32] <^d> If we're going to buy a real cert, we should go ahead and move it to a real home. [15:50:34] <^d> And out of labs. [15:53:10] ^d: yeah, probably [17:51:22] Krinkle: Hi. Would you mind merging my commits to Intuition ? https://github.com/Krinkle/intuition/pull/14 Would be great. [18:33:59] petan, " I am not using our gerrit only because I have to wait weeks or months for repositories to be created" - qchris typically opens new repos within one business day [18:34:28] (although a 'create your own repo' option is certainly better than this manual process) [18:34:29] valhallasw: I think repositores I requested year ago are some still not open yet [18:34:56] petan: https://www.mediawiki.org/wiki/Git/New_repositories/Requests [18:35:02] valhallasw: usually I keep waiting few days then I just give up, open a repo on github and stop tracking that page [18:35:05] oh, maybe in the archive [18:35:28] https://www.mediawiki.org/wiki/Git/New_repositories/Requests/Archive seem to all be done? [18:35:54] I don't want to wait, usually I have an idea and I need to commit really fast, you know it's like when you need to go toilet really fast [18:36:05] :P [18:36:06] :P [18:36:08] same feeling [18:39:21] !log deployment-prep Rebooting deployment-bastion in a wild attempt to get the jenkins slave there working again [18:39:45] !ping [18:39:45] !pong [18:39:51] !log deployment-prep Rebooting deployment-bastion in a wild attempt to get the jenkins slave there working again [18:42:30] Logged the message, Master [18:42:33] Logged the message, Master [19:09:56] 4Wikimedia Labs 3tools: "webservice stop" leaves blocking php-cgi processes behind - 10https://bugzilla.wikimedia.org/64095#c4 (10Magnus Manske) 5NEW>3RES/FIX Thanks Tim, metatron, it works again! [19:17:47] 4Wikimedia Labs 3tools: "webservice stop" leaves blocking php-cgi processes behind - 10https://bugzilla.wikimedia.org/64095#c5 (10Tim Landscheidt) 5RES/FIX>3REO It works for now :-), but the general problem hasn't been solved yet. [19:18:16] scfc_de: need to spend some time getting uwsgi support up there :D [19:18:25] or even node [19:20:57] YuviPanda: In webservice? [19:21:22] scfc_de: yeah. without lighty in the middle [19:23:47] YuviPanda: That would certainly be nice (or that Java thingy). I've never used anything besides traditional CGI, so I don't have a clue what structure a typical user would expect. [19:23:58] mm, right [19:24:13] I don't know anyone who wants to run tomcat tho. but I do know lots of python stuff is running [19:26:30] I'va had requests for tomcat earlier. [19:28:28] yeah, but I don't think anyone is running them atm. [19:29:15] scfc_de: I'm thinking it'll just start app.py, since that's the usual uwsgi convention. and you can have a config file just like how we have for lighty [19:29:22] legoktm: ^ (discussing uwsgi support) [19:30:00] yes please! [19:30:57] legoktm: so, default just starts app.py and rewrites things to it. so