[02:57:17] (03PS1) 10Jackmcbarn: Increase length of status abbreviation to 4 [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/135989 [03:22:48] (03CR) 10PiRSquared17: "Bug: 64632" [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/135989 (owner: 10Jackmcbarn) [10:16:08] My problem with dumps-stats2 is probably due to full / [10:16:48] I'll just delete the instance now, if I manage. [11:05:27] is there any api to control jobs on grid engine using python, or will i have to use just the shell commands directly(jsub etc.) [11:06:55] rohit-dua: https://code.google.com/p/pythongrid/ [11:07:09] but I think that will just submit sge commands in the end [11:07:36] there's also https://pypi.python.org/pypi/gridtk [11:08:38] valhallasw: ok are they installed on tools-lab? [11:09:28] no idea, but they are probably easy enough to install in a virtualenv [11:12:55] valhallasw: ok. thank you. [11:30:25] Warning: Unknown: open(/var/lib/php5/sess_v1kjj6uv527knad66tqpri99l4, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in Unknown on line 0 [11:30:27] https://tools.wmflabs.org/usage/?debug=true [11:30:29] Coren: andrewbogott_afk: Maintenance going on? [11:43:34] Restarting webservice fixed it [11:43:36] strange [11:43:54] Krinkle: Not by me. Perhaps your webs - ah, there you go. [11:44:15] That should not have been needed though [11:44:20] other tools were unaffected. [11:44:31] Krinkle: But I'm pretty sure I have a good idea what happened. [11:44:31] (at least one other php tool was fine) [11:44:48] Oh? That sounds good :) [11:45:16] Ah, no; my initial idea was wrong. Durn. [11:46:39] So, since it wasn't out of space, the *only* reason I can think of for an EPERM on opening a new session file is if you had a hash collision(!) [11:46:56] I got it on every request [11:47:18] You'd have gotten the same session cookie, so that'd be expected. [11:47:38] ... holy shit. What tool was that? [11:48:11] usage [11:48:12] https://tools.wmflabs.org/usage/?debug=true [11:48:19] -rw------- 1 tools.orphantalk tools.orphantalk 10 May 29 11:42 /var/lib/php5/sess_v1kjj6uv527knad66tqpri99l4 [11:48:21] The warning is gone now that I restarted hte webservice [11:48:42] ... actual hash collision. [11:48:51] Coren: Hm.. that might make sense actually [11:48:55] session cookies are domain wide, right? [11:49:22] ... ooooh. [11:49:26] They may be. [11:49:48] No, I'm telling you they are. The question is whether on the backend the local tool permissions are split. [11:49:56] If so, the session store can't be shared. [11:50:12] at least not without fragmentation [11:50:34] At least not between tools that have session data. Right. That's a biggie, but it should be fairly simple to fix in practice. [11:50:58] yeah, a user who uses two php tools that call session_start() will get the warning [11:51:10] * Coren nods. [11:51:15] I hadn't anticipated that. [11:51:26] It means I can get rid of a hack that I created for Toolserver [11:51:33] which is that SESSION is not shared between tools [11:51:51] I like that :) [11:52:09] $_SESSION['user'] was problematic on Toolserver, clashing all the time [11:52:48] Yeah, I think I have to split the session stores otherwise we'll always run into odd bugs. [11:53:01] * Coren ponders. [11:53:12] Or have per-tool session cookies by default at best. [11:53:14] I mean, that depends on how you intend to fix it (by sharing permissions or prefixing the webserver mount path to the hash in the backend) [11:53:25] Ideally the latter [11:53:37] sharing permissions opens all sorts of nasty problems I'd rather not. [11:53:42] Yeah, totally. [11:53:55] I like having separate webservices in the backend. quite nice [11:55:02] Coren: Well, that would work if you can somehow set session.cookie_path in php.ini to the individual root of the mounted/proxied web service [11:55:08] e.g. session.cookie_path='/usage/'; [11:55:15] and orphantalk etc. [11:56:02] but that's suboptimal as it creates multiple cookies client-side. [11:56:52] actually, Toolserver fixed this at some point [11:57:03] I remember seing a .phpsessions directory in the HOMEDIR of every tool there [11:57:06] Just having a per-tool session.save_path would do it while still allowing a share session. [11:57:11] Yep [11:57:21] shared session *cookie. [11:57:36] php runs via the webservice from the local tool, so this can work. [11:57:49] I guess it alreayd does that for access logs [11:58:26] Note, it creates more than just warning, after visiting 1 tool, any subsequent tool I visit will not have the ability to store/read from sessions. [11:58:56] 3Wikimedia Labs / 3tools: Session cookies (and data) being shared between web services cause issues - 10https://bugzilla.wikimedia.org/65891 (10Marc A. Pelletier) p:5Unprio>3High [11:58:58] 3Wikimedia Labs / 3tools: Session cookies (and data) being shared between web services cause issues - 10https://bugzilla.wikimedia.org/65891 (10Marc A. Pelletier) 3NEW p:3Unprio s:3major a:3Marc A. Pelletier As the session id cookie is identical between tools, the first one to save a session prevents... [11:59:11] 3Wikimedia Labs / 3tools: Session cookies (and data) being shared between web services cause issues - 10https://bugzilla.wikimedia.org/65891 (10Marc A. Pelletier) 5NEW>3ASS [11:59:56] Krinkle: Yes, because session data is (correctly) not readable from other tools. [12:00:28] This helped me identify an inefficiency though. I don't need sessions in most tools. I'm fixing my framework to lazy-init the session based on actual read/write. [12:13:26] 3Wikimedia Labs / 3tools: Session cookies (and data) being shared between web services cause issues - 10https://bugzilla.wikimedia.org/65891#c1 (10Marc A. Pelletier) Note: one possibility is to simply *document* that caveat and let tools that care about/intend to use session data to set their save_path or co... [12:22:22] hi. which is better MySQL event scheduler OR cron for periodic sql queries.... [12:23:26] 3Wikimedia Labs / 3tools: Session cookies (and data) being shared between web services cause issues - 10https://bugzilla.wikimedia.org/65891#c2 (10Krinkle) (In reply to Marc A. Pelletier from comment #0) > As the session id cookie is identical between tools, the first one to save a > session (..) Note that... [12:24:17] rohit-dua: Personally, I'd manage scheduling yourself because implementation details on the database are subject to change. [12:25:08] Coren: ok so i'll go with cron. but performance wise what do you think is better? [12:26:41] rohit-dua: I don't think the difference is significant; the even scheduler is potentially very slightly faster (because there is one fewer level of indirection), but unless you actually need subsecond lag (and you really shouldn't) then it's not meaningful. [12:27:35] Coren: oh. ok thank you. [12:33:41] 3Wikimedia Labs / 3tools: Session cookies (and data) being shared between web services cause issues - 10https://bugzilla.wikimedia.org/65891#c3 (10Marc A. Pelletier) On the other hand, any change to the PHP config should be changing the /defaults/ only, allowing tools designed to do so to share session data... [12:47:17] (03CR) 10Merlijn van Deen: [C: 032] Increase length of status abbreviation to 4 [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/135989 (owner: 10Jackmcbarn) [12:47:41] (03CR) 10Merlijn van Deen: [V: 032] Increase length of status abbreviation to 4 [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/135989 (owner: 10Jackmcbarn) [12:48:56] 3Tool Labs tools / 3wikibugs IRC bot: pywikibugs should not abbreviate "Assigned" to three characters. - 10https://bugzilla.wikimedia.org/64632 (10Merlijn van Deen) 5NEW>3RESO/FIX [12:53:49] Coren: Hm.. There's a weird redirect bug. When for some reason a trailing slash is added by nginx, it goes from https to http. [12:54:00] e.g. https://toolserver.org/~krinkle/OrphanTalk2.php?wikidb=nlwiki_p&namespace=1&limit=10 [12:54:09] Redirects to https://tools.wmflabs.org/orphantalk/ [12:54:12] but ends up on http://tools.wmflabs.org/orphantalk/?wikidb=nlwiki_p&namespace=1&limit=101 [12:55:03] 301 redirect even [12:56:00] https://tools.wmflabs.org/orphantalk?example [12:56:19] (I've fixed the toolserver redirect to include the slash so that'll no longer fall to http now) [13:00:16] !log integration Creating integration-slave1003 instance with an Ubuntu '''Trusty''' image. [13:00:18] Logged the message, Master [13:03:40] Coren: what about doing something with that access.log we have for tool "admin" it's getting large very quickly [13:03:49] I removed it yesterday but... [13:10:01] hashar: petan: wikibugs: Wikimedia / Extension setup: Modern and Cologne Blue should remain in Preferences/Appearance after removal from core - https://bugzilla.wikimedia.org/65868#c5 (Krinkle) They'll also have to be added to beta labs somehow. [13:10:25] hi [13:10:32] I would do that, but you know [13:10:37] it's hashar's baby [13:10:41] I don't want to break it :P [13:11:29] Oh, I thought you messed with beta as well [13:12:50] petan: which file? [13:13:14] ah the skins [13:23:13] Krinkle: yes, I literally "messed" with it :P in fact I am the guy who launched it, originally with Mark Hershberger [13:23:25] Exactly [13:23:41] * Krinkle knew that [13:23:45] but then, john du hart and hashar came and I decided to stop "messing it up" and left them do the real work :D [13:24:01] Ah, I missed that [13:24:29] one day I understand how it all works and hopefully start working on it again :P [13:24:30] Don't let things go boring though. Feel free to mess with it ocasionaly to keep it interesting. [13:24:33] and I try to follow up [13:24:44] but should really have created a whole new cluster from scratch :) [13:25:05] nowadays it self maintains though since there is a lot of folks involved in the beta cluster [13:25:07] this way it was more fun :P [13:25:11] and it s fully puppetized [13:25:25] I'm still waiting for Special:NovaCreateWmflikeProject [13:25:32] hehe [13:25:33] which is a beta-like boiler plate [13:25:41] That's what Ryan Lane sold us originally [13:25:47] yes I know :P [13:25:50] properly puppetized [13:25:57] I think that vagrant is for that now [13:26:16] for easily experimentation, trying new extensions, or mw patches, or server/apache config changes in a wmflike environment [13:26:25] Not even close, that's for local mw dev [13:26:57] It's closer than plain local dev (it can have the one apache configured a lot like wmf apaches) [13:27:11] but not for proper integration testing and experimentation [13:27:45] right now that basically requires getting access to beta and breaking it temporarily for every one (and being overridden by autodeploy) [13:29:44] I am pretty sure OpenStack supports projects templating [13:32:36] The "mediawiki-in-a-box" concept is still on the table and a favorite of mine. [13:33:01] It would have to set up a dozen or so instances, apply certain puppet rules, set up a few web proxies (one for each central domain and maybe two for wikis, like {bits,upload,login,www,en-wikipedia,he-wikipedia,ru-wiktionary,nl-wikisource}-{projectname}.wmflabs.org) [13:35:13] would need certain variables in wmf-config to be factored out in a separate file generated by an erb file by puppet (e.g. bitsHostname) [13:35:20] anyway, seems doable eventually. [13:55:41] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c4 (10Andre Klapper) Coren: Not sure if I understand the question correctly :-/ > Received: from jenkins-bot by fab2.eqiad.wmflabs with local (Exim 4.76) Or does this r... [14:07:41] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c5 (10Marc A. Pelletier) Ideally, I need to be able to follow the mail flow from where it first enters the system - unless there is a relay /within/ the phabricator proje... [14:12:18] Krinkle|detached: It seems to me that a reasonable first step would be "document how to build one by hand" [14:31:16] Damianz: Got someone asking to be approved for the CBNG review interface. [14:38:16] Coren: Or before that, have a at least one manually build already [14:38:20] because beta isn't quite there yet [14:40:27] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c6 (10Marc A. Pelletier) The issue, for that instance at least, is that the MTA is running out of space for spooling mail (forcing them to be deferred) because /var is fu... [14:41:20] Krinkle: Indeed. :-) [14:41:50] andre__: I found the immediate cause of mail woes for phabricator, but it'll require some action from project admins to fix. [14:45:27] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c7 (10Daniel Zahn) the instance is a completely manual setup and as has been pointed out before it really needs to be setup for real (via puppet, incl. log rotate etc., n... [14:47:26] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c8 (10Marc A. Pelletier) At any rate, a simple stopgap would be to delete or move aside /var/log2 and /var/log3. This will free ~700M of space which will unclog email -... [14:49:41] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c9 (10Daniel Zahn) afaik Chad has set it up but i doubt he will care about keeping those logs, so the suggestion sounds good [14:51:53] mutante: Want be to explodate them? [14:51:58] me* [14:52:30] Ah, nevermind, I see you just did. [14:52:37] no i did not [14:53:05] i said i doubt anyone wants them..but i didnt even connect [14:53:44] Oh, nevermind, I didn't look at the right place. :-) [14:54:09] best would be to ask the one who set it up [14:54:29] Coren: Uh yay. I must say that I like you a lot. :) [14:54:32] awesome! [14:54:48] Indeed. I don't randomly delete stuff to make room on other's instances -- even though that's an old BOFH tradition. :-) [14:55:24] but on the other hand i want to point out this instance should not even be considered more than the most basic test setup [14:55:43] we need at least 2 ...one for testing.. one for using [14:56:12] I hope so. :-) But being a test instance means the probability that the logs were set aside for a good reason /increase/ :-) [14:56:43] hmmm.. fair.. yea [14:56:51] so, let's just compress them? [14:56:54] and ping ^d ? [14:57:23] mutante: I'll make tarballs and stuff them in /mnt [14:57:35] sounds perfect, nod [14:57:46] <^d> Sup? [14:58:31] ^d: phab instance ran out of space, coren found logs /var/log2 /var/log3 [14:58:43] Now tarballed to /mnt/log[23].tgz [14:58:49] <^d> Trash em. [14:59:03] <^d> I have nfc why we have so many logs. [14:59:41] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c10 (10Marc A. Pelletier) 5NEW>3RESO/FIX I've made tarballs of both directories to /mnt/log[23].tgz, freeing >600M of space. [15:00:17] Trash 'em? Mkay. [15:01:14] And suddenly a mail clog gets unstuck. [15:01:30] * Coren sees dozen of email being sent. [15:01:36] <^d> So yeah, fact that mail works there is mostly a happy accident? [15:01:40] <^d> I did nothing to set it up. [15:01:52] <^d> I just kind of installed phab and it sent e-mail. [15:02:01] ^d: The default instance setup provides reasonable defaults [15:02:15] (for sending mail) [15:02:29] <^d> Hence the happy :) [15:02:52] Although the From: address will be garbage that can't receive email unless you adjusted it accordingly. [15:03:12] <^d> Unless someone changed it the default was like phabricator@example.com [15:03:16] <^d> :p [15:03:44] There's jenkins-bot@fab2.eqiad.wmflabs, which is just as meaningless. [15:03:57] <^d> hehe [15:05:02] ^d: Also, maybe happy but not accident. :-) [18:01:10] (03CR) 10Alexandros Kosiaris: [C: 032 V: 032] osm: add ganglia postgres credentials [labs/private] - 10https://gerrit.wikimedia.org/r/134839 (owner: 10Alexandros Kosiaris) [19:20:30] 3Wikimedia Labs: Mail notifications from fab.wmflabs.org delivered only days later (or not at all?) - 10https://bugzilla.wikimedia.org/65861#c11 (10Andre Klapper) Thanks so much, Coren (and Daniel)! [19:52:40] Coren: Could you ave a look at this guy, and put him on hold for some time https://tools.wmflabs.org/paste/view/f25eb973 [19:52:59] Coren: sent this day ~40 k requests [19:53:41] hedonil: That does seem abusive. Sure, give me a minute to track him down. [19:58:21] hedonil: blackholed. [19:58:31] Coren: ;-) [19:59:16] Thankfully, that wasn't distributed but a single IP; I'm thinking a broken bot of some sort. [20:01:18] Coren: good thing. Webservice kept alive, handeled things like a real prod. service ;-) [20:04:50] I only restarted it, to activate a block for this UA in local .lighttpd [20:06:02] Tool labs /is/ getting more robust as time progresses and we work over the weaker points. [20:06:37] yeah. so it shall be written, and so it shall be done [20:06:41] Coren: can you block the TweetmemeBot UA? [20:07:23] Betacommand: It's easy enough to do at the .lighttpd.conf level, at the proxy level I can mostly place IP blocks only. [20:08:04] Well, I /can/ place UA block but the overhead per request is rather high. [20:09:29] Coren: due to the screwed up permissions I cant just upload a file to labs, I have to either have it in an SVN repo, or jump through a dozen hoops to fix ownership and permissions [20:10:11] ... wait what? Most people have no issues with it; what client are you using? [20:10:29] Coren: anyone with windows has that issue [20:11:05] I can upload to my local account, but not to the tools correctly [20:11:19] I know Winscp has, by default, an option set which may cause issues, though I'm probably not the best one to ask about it. IIRC, it's something along the lines of "check permissions locally" vs "allow the server to check permissions". [20:12:15] Coren: its more than "may" and last I heard there isnt a solution [20:12:32] (Maybe something like "trust remote permissions"). The point is, the client attempts to guess at whether you can write at a specific place and fails because it doesn't understand group ownership properly. [20:13:00] hedonil: proxy didn't die! yay :) [20:13:04] I'm pretty sure I've been told there is an option to turn off that fixes it. [20:13:17] YuviPanda: \o/ [20:13:27] hedonil: \o/ indeed [20:13:27] * Coren should probably install a Windows WM with the usual suspects to test things like this. [20:14:02] "When explicitly changing permissions of existing remote files, the checkboxes can be set to undefined state1)." [20:14:03] I wonder how the WMF will react to a procurement request for a Windows license. :-) [20:14:05] thing improve - step by step [20:14:05] re: WinSCP [20:14:15] "It means that the particular permissions should be left to its current state. This is useful when you want to change one particular permission for set of files/directories that have different permissions. " [20:14:28] but " Note that this will not work fully for SCP protocol for files in subdirectories. " [20:14:34] i think it's that? gotta run though [20:14:55] mutante: Not sure that's the same issue, and I'd expect most people actually use SFTP under the hood nowadays. [20:15:10] foo & blunt critics it is [20:15:54] mongodb next! [20:23:30] Coren: I just did some testing and it seems to have been fixed, without any notices [20:24:39] Betacommand: hmm, what else is shitty about tool labs? [20:24:48] Betacommand: I'm pretty sure I didn't fix anything there. I usually *break* things, remember? :-) Seriously though, it's not clear what could have changed on that aspect; I haven't changed file management since last Sept at the earliest. [20:25:26] (There were some changes related to groups being members of groups, but that's not something that'd concern your use case) [20:30:02] hi. does tools.toolname@tools.wmflabs.org MAIL work? I sent a mail to tools.bub@tools.wmflabs.org but did not receive any reply on my gmail (linked) account. [20:31:31] rohit-dua: I've had no reports of issues. Lemme go see if I can track your mail down. [20:31:45] Coren: thank you [20:32:42] rohit-dua: Looks like any delay you have is on Google's end; I see it sent to them at 2014-05-29 20:26:01 UTC [20:33:16] 2014-05-29 20:26:01 1Wq6tk-0006cz-PU => *redacted*@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [173.194.75.26] X=TLS1.0:RSA_ARCFOUR_SHA1:16 [20:35:26] Coren: if i send several emails from tool-labs to say gmail.. will it land up in the spam folders [20:36:28] rohit-dua: It might; gmail's automatic filtering is sometimes arcane. But I know that if you set your tool's email as a contact it never will. [20:37:00] Coren: you mean tools.toolname@tools.wmflabs.org [20:38:11] I mean whoever/whatever sends you email. Obviously, if it's endusers then you can't guess ahead of time (but that shouldn't hit your spamtrap) but if the tool /itself/ sends mail then yes, that's the address to add. [20:38:26] don't panic if your bots die, wikipedia is 404 for now [20:39:02] Coren: I spoke too soon. Still messed up. I can upload new files, but not re-upload existing files [20:39:30] Betacommand: You may have uploaded them originally with permissions that were too restrictive; that's a simple one-command fix. [20:40:05] Betacommand: Want me to do that for you? (add group access recursively) [20:40:17] yeah [20:40:27] betacommand-dev right? [20:40:42] yep [20:40:55] I make it real hard to guess :P [20:42:50] Betacommand: Both you and your tool now share full rw on the files in its home. [20:43:08] Coren: htanks [20:43:13] bd808, I am apparently completely sporked in betalabs with `git deploy` [20:43:20] every time I try and fix it; things seem to get worse [20:43:44] and I can't even recover and do what I want to do on my test host; because apparently git deploy rewrites the git remotes [20:43:57] haaaaaalp [20:44:34] I am actually considering doing a sudo rm -rf /srv/deployment/ocg/ocg [20:46:46] Betacommand: Have you seen the counter in the topic? [20:48:51] a930913: Whats the point? it wont get past 5 [20:49:05] Betacommand: It got to 6! [20:49:23] a930913: what was the incident now? [20:49:54] YuviPanda: To be fair, it's a more general incident. [20:50:08] indeed, shouldn't be updated here. [20:50:25] a930913: put it back! this isn't -operations [20:50:31] YuviPanda: :p [20:50:38] a930913: :) [20:51:38] mwalker: I'll look [20:53:47] bd808, thanks :) /me backs off from running random salt commands [20:54:25] Coren: looks like its a settings issue in WinSCP's transfer settings about ignoring permission errors. [20:55:42] !log deployment-prep Restarted salt minion on deployment-pdf01 with `sudo salt 'i-00000396.eqiad.wmflabs' service.restart salt-minion` [20:55:45] Logged the message, Master [20:57:54] mwalker: It looks to me like the `git deploy sync` is actually running on deployment-pdf01 but the redis server on deployment-salt isn't being told about it. [20:58:14] maybe [20:59:37] !log deployment-prep /var full on deployment-pdf01 [20:59:39] Logged the message, Master [20:59:55] mwalker: "IOError: [Errno 28] No space left on device" there's the problem [21:00:09] bd808, hah; /me goes to delete some logs [21:01:50] mwalker: Is it expected to have a lot of /var/log output here? You may want to apply the role::labs::lvm::biglogs puppet class to get a large /var partition mounted [21:02:25] I think that before you do that you'd want to save the current /var somehow [21:02:57] maybe copy it to /var-old or something [21:03:33] /var is only 2G by default in eqiad labs and can fill up fast depending on what's going on [21:03:39] well; it's 1.4G with just normal system operation (like not with the logs generated by the ocg role) [21:04:25] .5G in /var/log/upstart [21:04:46] yep; ocg not starting itself and spamming the heck out of things; so just deleted that [21:06:31] mwalker: Looks much happier now. sudo salt-call deploy.fetch 'ocg/ocg'; sudo salt-call deploy.checkout 'ocg/ocg' ran with no errors [21:07:49] !log deployment-prep mwalker cleaned up log spam from upstart on deployment-pdf01 [21:07:51] Logged the message, Master [21:08:51] what is the smtp server address I can connect, to send emails from my tool(via a bot..) [21:13:58] got it. did'nt see /usr/bin/mail before.. [21:32:24] What's the best/easy/simplest way to make certain files in a tool publicly available? I.e. sauce. [21:35:38] a930913: /shared ? [21:35:59] a930913: Anything in public_html is publicly available by default. Or do you mean from within tools? [21:37:25] a930913: ...or to make looking up thing more convenient: http://tools.wmflabs.org/tools-info/explorer/?dir=shared [21:38:32] a930913: just look, no touch (from here) :P [21:43:51] hedonil: Yeah, but that doesn't show files, does it? [21:43:59] As in, the contents. [21:44:36] a930913: it shows files as long as as they aren't locked down by their owners [21:44:56] bad habit ihmo [21:45:14] hedonil: How? Clicking files doesn't open them. [21:45:52] a930913: no. opening files not going to work [21:46:16] restricted that thing [21:46:24] I just want to make the BracketBot code publicly visible. [21:46:35] Ugly as it is. :p [21:47:12] a930913: either put it in your public_html (as Coren suggested) [21:47:47] hedonil: Doesn't reflect updates. [21:47:49] or put it in /shared and make a symlink from your public_html [21:48:23] a930913: ...or make a 301 redirect from yout public_html [21:48:51] ... as index.py or index.php [21:49:08] hedonil: To where? It's not in public_html. [21:49:28] ... or make a http rewrite rule in .lighttpd.conf [21:49:46] bd808, gwicke: do you know why trebuchet would replace the original submodule fetch location with something like: http://deployment-bastion.eqiad.wmflabs/ocg/ocg/.git/modules/mw-ocg-texter? Or possibly a better question; how to update that new location with what's in the canonical repo? [21:50:01] because right now it's a couple patches behind for all my submodules [21:50:05] hedonil: Mmm, think I'll do that. Ta. [21:51:08] mwalker: That's how trebuchet does what it does. Whatever is on deployment-bastion becomes what is clones on the minions. [21:51:32] bd808, ok; so how do I update the submodules then? [21:51:53] a930913: easiest way is to create index.php with collowing content [21:52:02] wait; I might have had old content [21:52:04] 1. header("Status: 301 Moved Permanently"); [21:52:04] header("Location: //tools.wmflabs.org/$path/sc/index.php"); [21:52:15] mwalker: You need to do that on deployment-bastion. `git deploy start`, `git do-stuff`, `git deploy sync` [21:52:30] modify ;-) [21:53:08] mwalker: Whatever state in on deployment-bastion's clone at the time you run `git deploy sync` will be tagged and the minions will be told to checkout that tag [21:53:54] hedonil: I can't redirect the browser, because the files are not public. [21:54:00] makes sense; I just don't know why its not reflecting whats in gerrit when I tell it to do git submodule update --init --recursive; but... maybe what's in gerrit is just wrong [21:54:03] * mwalker looks harder [21:55:07] a930913: download & sync-job ? [21:56:20] a930913: are you talking about providing Edward Snowdens' files? [21:56:32] :P [22:00:03] mwalker, we had issues where trebuchet didn't update the submodules [22:00:19] did you add the special entry in .git/config ? [22:00:40] gwicke, in this case it was me and gerrit fighting [22:00:45] there was a rebase that went bad [22:00:52] and my submodule updates got lost [22:00:57] and then I thought I fixed it [22:01:00] but apparently not [22:01:02] k [22:01:16] which means I owe bd808 cookies or something for wasting a lot of time [22:01:49] hedonil: I get a 404 on the rewrite :/ [22:02:29] a930913: show code, or didn't happen [22:04:09] hedonil: url.rewrite-once += ("/bracketbot/code1" => "/data/project/bracketbot/pywikipedia/wikidiffnotedit.py") [22:05:52] a930913: What language is that? [22:06:13] a930913: what's your tool ? [22:06:41] Because if I were a computer I would parse that as "subtract the variable once from the variable url.rewrite" in most languages [22:06:57] Then lose my shit because I was trying to assign another value to the result of that operation [22:07:09] a930913: url.rewrite-once += ( "^.*/wikiviewstats.*/(res/.*\.)(css|js|png|jpg|gif)" => "/wikiviewstats/$1$2" ) [22:07:26] marktraceur: lighttpd config language [22:07:30] Oh, kay then [22:07:36] * marktraceur goes away :) [22:07:59] is there a way to get delivery reports of the emails sent using /usr/sbin/exim or /usr/bin/mail in the tools-lab [22:08:00] a930913: (expample) -> must match your root of course [22:08:03] which has no '-' symbol, and uses += to merge hash tables :-) [22:08:09] hedonil: I... I did them the wrong way round, didn't I? [22:08:24] a930913: probably ... [22:09:46] hedonil: Wait, I'm not mad, I didn't. [22:09:55] a930913: plain regex thingy [22:10:04] a930913: try harder ;-) [22:10:49] a930913: two things [22:11:08] a930913: 1. check your regex http://regex101.com/ [22:11:46] a930913: 2. debug.log-request-handling = "enable" [22:12:20] & check error.log what lighty did with your regex [22:12:25] hedonil: There's hardly any regex, just a single file for now. [22:13:08] a930913: what's your tool's name ? [22:13:43] hedonil: bracketbot [22:16:02] a930913: hmm python thing in cgi subdir.... maybe valhallasw can help ;-) [22:16:05] hedonil: Looks like the absolute file is relative. [22:17:21] a930913: ah. this won't work [22:17:44] you have to make a symlink with $ ln [22:18:13] from your public_html (or subfolder) to /data/project/bracketbot/pywikipedia/wikidiffnotedit.py [22:19:34] hedonil: Symlinks do a whole directory, not a file? [22:19:42] both [22:20:26] hedonil: How? [22:23:03] a930913: what's your goal? display the code or execute something as cgi? [22:24:34] * mwalker pounds head on desk -- without role::beta::natfix, I cant talk out; with it though; other things cant talk to me... [22:24:54] andrewbogott_afk, any interesting in trying to figure out why the sysctl puppet thingy doesn't work on ubuntu 14.04? [22:26:39] for just displaying the code you have to assign "text/plain" to the file extension [22:26:43] eg: mimetype.assign += ( ".sh" => "text/plain" ) [22:26:52] hedonil: Well it 404s. [22:27:39] (which doesn't work for ".py", as it's already definded in default server config) [22:27:40] hedonil: Goal is to display source code from tool folder to the web. [22:27:54] unless you start your custom webservice [22:28:42] a930913: this is an example http://tools.wmflabs.org/tools-info/misc/webwatcher.sh [22:29:47] code is in /shared/sample_scripts/webwatcher.sh [22:30:42] and there's a symlink from /data/project/tools-info/public-html/misc/ to that file [22:30:50] hedonil: So how can I symlink a single file? [22:31:45] $ln -s /foo/bar/baz.sh [22:32:18] hedonil: From -> to? [22:32:48] $ln -s [22:38:36] hedonil: So I have the link at /shared/bracketbot/code1, what link do I use? [22:38:51] * hedonil looks [22:39:41] a930913: 1. cd to your publich_html/ dir [22:40:26] a930913: 2. $ln -s /shared/bracketbot/code1 code1.txt [22:40:47] hedonil: Oh! You confused me above. [22:40:52] :p Hold on. [22:41:03] right there [22:45:27] hedonil: Got it! [22:45:32] Coren, are you aware of a conflict between the beta::natfix puppet thing and security groups? it seems like after I applied the natfix I lost security group firewall rules [22:45:55] a930913: fine [22:46:15] hedonil: Thanks :) [22:46:28] a930913: yw ;-) [22:46:38] a930913: working link? [22:46:41] mwalker: First I hear of it, and it'd surprise me a little since anything puppet applies necessarily lives within the VM whereas the security groups live outside. [22:47:40] Coren, hmm... so I'm guessing then the natfix applied a default rule to deny everything (that wasn't there before) [22:48:03] That may be. What's in your iptables now? [22:49:16] whole bunch of stuff: http://pastebin.com/d7Kh7y5W [22:49:30] the last rule is the one I just added to make my stuff work again [22:53:56] hedonil: https://tools.wmflabs.org/bracketbot/code{1,2}