[05:13:13] Is there any way to run betalabs code (particular extension)at given tag ? [05:14:06] or this should go to -ops channel? :) [05:18:06] kart_: You want one of the beta wikis to pin an extension at a particular version? [05:18:47] Right now there is no way to do that. Beta runs the HEAD of master for everything. [05:31:30] bd808: Thanks [05:31:53] bd808: yes. for Content Translation [05:34:52] Beta runs the tip of master because that is what will be released "next". You could test something else using MediaWiki-Vagrant or another manually configured wiki. [05:35:04] If you needed to share it you could do that in a Labs project. [05:36:28] bd808: that's fine. Just wanted to know :) [07:34:32] 3Tool Labs tools / 3X!'s tools: LanguageTool removes article from watchlist - 10https://bugzilla.wikimedia.org/67991#c2 (10Daniel Naber) Hi, thanks for the report. I'm the author of LanguageTool, I'll try to fix this. The problem is that in the moment we send you to Wikipedia, the checkbox that decides wheth... [07:51:34] 3Tool Labs tools / 3X!'s tools: LanguageTool removes article from watchlist - 10https://bugzilla.wikimedia.org/67991#c3 (10Daniel Naber) The problem is that we send the user directly to the diff view. There, we could use the 'wpWatchthis' parameter to set the value of the "watch" checkbox, but we cannot set... [10:49:16] I'm trying to import sample article on es.betawiki but, getting [10:49:20] Import failed: Loss of session data. Please try again. [10:49:34] (I'v import right, yes) [11:28:40] scfc_de: can you please restart the webservice of sul : http://tools.wmflabs.org/sulinfo/sulinfo.php [11:31:41] !log tools Started webservice for sulinfo; stopped at 2014-06-29 18:31:04 [11:31:44] Logged the message, Master [11:31:47] matanya: Done. [11:31:56] thanks a lot [11:32:28] Or can anyone imported article to en/de betawikis are here? [11:32:37] (Need help for es/ca wikis) [11:32:41] scfc_de: this service became very important with new Global renaming, please make sure it is up :) [11:32:42] *beta [11:32:48] kart_: you need hashar [11:32:55] who is not here :) [11:32:56] but he is on vacation [11:33:01] afaik [11:33:04] yep [11:34:42] I'm getting, Import failed: Loss of session data. Please try again. - so it must be in config for beta. [11:35:23] seems so, would you want me to peek at it ? [11:38:07] matanya: if you can help, that will be great. [11:38:52] matanya: you can try importing any article from es wikipedia. [11:39:03] ok [11:39:21] to http://es.wikipedia.beta.wmflabs.org/ [12:02:24] anybody knows who to ping to get login problem at http://en.wikipedia.beta.wmflabs.org/ fixed? [12:02:32] Login error: Wikipedia uses cookies to log in users. You have cookies disabled. Please enable them and try again. [12:15:35] zeljkof: I think Chris McMahon would know who to ping, but he doesn't seem to be online as well (yet; east coast = 8:15 now). I believe I saw bd808 working on it recently as well. [12:16:22] scfc_de: thanks [12:17:02] yes, Chris is still sleeping now, I remember seeing mail from hashar on who to ping if things go wrong, looking for it [12:19:57] Hm, the crontab thingy didn't auto-change my command to use jsub [12:21:31] 3Wikimedia Labs / 3tools: Clean up list of projects on Tool Labs home page - 10https://bugzilla.wikimedia.org/49937#c9 (10This, that and the other) Just giving this bug a poke. This has become a lot more of an issue now, with over 820 tools listed on the Tools home page, and the majority lacking any ancillar... [12:23:50] wikibugs seems to be lagging quite a bit. [13:09:47] 3Wikimedia Labs / 3Infrastructure: Transition service groups to new globally unique names and UIDs - 10https://bugzilla.wikimedia.org/58997#c15 (10Tim Landscheidt) 5PATC>3RESO/FIX I think this bug can be closed. [14:10:41] Coren: Am I correct in thinking that http://lists.wikimedia.org/pipermail/labs-l/2014-July/002747.html is not something that people should do? [14:11:02] Coren: chrismcmahon told me to ping you about https://bugzilla.wikimedia.org/show_bug.cgi?id=63981 [14:11:15] could you please take a look? [14:11:52] hi Coren it may be more something for Ori or Chris Steipp, I didn't realize he'd already reported the issue [14:12:47] chrismcmahon, Coren: Ori reported it a month ago, looks like back then it was a minor thing, but now it breaks all browser tests that need to log in [14:12:49] 3Wikimedia Labs / 3deployment-prep (beta): cannot create account on beta wikidata - 10https://bugzilla.wikimedia.org/68031 (10Aude) 3NEW p:3Unprio s:3normal a:3None I am trying to create a new account on beta and am getting a captcha. The captcha image is broken and not displaying, so it is not possi... [14:15:20] anomie: In essence, you could achieve the same thing with "while true; do webservice start; sleep 1m; done" [14:17:35] scfc_de: "sleep 20s", according to the email. Either way, I thought running stuff like that on -dev or -login isn't allowed. [14:18:06] anomie: Oh, well, that would be another aspect. [14:21:31] anomie: It's not allowed, but I'll tolerate it briefly while I'm working on the "real" solution that will live on -submit. [14:21:58] anomie: Which will also be a single daemon for everyone and not one for every tool. :-) [14:27:17] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981#c1 (10Željko Filipin) This is now also reproducible for all beta.wmflabs.org sites that I have tried: http://en.wikipedia.beta.wmflabs.org/ http://de.wikipedia.beta.wm... [14:28:01] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981 (10Chris McMahon) s:5normal>3critic [14:33:17] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981#c2 (10Andre Klapper) p:5Unprio>3Highes Bug 68031 might be a dup? [14:33:17] 3Wikimedia Labs / 3deployment-prep (beta): cannot create account on beta wikidata - 10https://bugzilla.wikimedia.org/68031#c1 (10Andre Klapper) p:5Unprio>3High Potential dup of bug 63981? [14:52:16] petan: are you available to fill some older (public) logs into wmbot's archive? or who can I ask? [14:52:54] anyone know who Filtro antiabusos on betalabs? [14:52:58] is [14:53:02] * [14:53:59] kart_: AbuseFilter extension, from the name :) [14:54:15] There are global abuse filter rules on labs and Wikimedia projects, you may need to ask a labs steward [14:55:00] But beta is down now http://meta.beta.wmflabs.org/wiki/ [14:55:14] Wrong url [14:55:50] Slow as hell but should be http://deployment.wikimedia.beta.wmflabs.org/wiki/Special:ListGroupRights [14:58:43] Sigh [15:01:46] aude: are you able to gibe Henning shell access on labs? [15:01:51] *give [15:02:40] Tobi_WMDE: What's Henning's wikitech username? [15:03:54] scfc_de: Henning_Snater [15:05:12] Tobi_WMDE: He already has shell access? [15:05:27] scfc_de: oh, ok. [15:05:39] than he should be fine.. [15:05:42] thx! [15:11:45] (03PS1) 10Andrew Bogott: Fill in some more dummy etherpad settings. [labs/private] - 10https://gerrit.wikimedia.org/r/146473 [15:12:06] (03CR) 10Andrew Bogott: [C: 032] Fill in some more dummy etherpad settings. [labs/private] - 10https://gerrit.wikimedia.org/r/146473 (owner: 10Andrew Bogott) [15:15:29] Nemo_bis: I see only MarkAHershberger in import rights [15:16:33] kart_: a steward can give you importer flag, but you can manage to upload only few MB of XML via Special:Import [15:17:08] (03CR) 10Andrew Bogott: [V: 032] Fill in some more dummy etherpad settings. [labs/private] - 10https://gerrit.wikimedia.org/r/146473 (owner: 10Andrew Bogott) [15:18:26] Nemo_bis: across all wikis (beta*)? [15:18:47] indeed, imports should be done on the shell [15:19:15] kart_: do you have shell access to betalaabs? [15:24:11] YuviPanda: yes [15:27:41] kart_: ah, you should be able to import [15:28:39] YuviPanda: I'll do some testing, but do you like https://gerrit.wikimedia.org/r/#/c/145974/ in principle? [15:29:33] andrewbogott: seems sane [15:29:57] ok [15:30:36] oh, actually, brian tested already. So I'm going to go ahead and merge [15:42:54] andrewbogott: 'at some point in the future' I want to abstract out labs-vagrant into a puppet-in-puppet module instead, that lets instances run puppet from an external repository in addition to ops/puppet. Exactly same as labs-vagrant, but with arbit git repositories [15:43:00] would be super useful for people running their own projects [15:43:03] YuviPanda: if I want to import articles on es betawiki, where should I do that ? ie which machine [15:43:21] kart_: deployment-salt.eqiad.wmflabs [15:43:29] YuviPanda: yeah, that sounds doable. [15:44:10] YuviPanda: thanks [15:48:01] YuviPanda: you should mention that about labs-vagrant to Dan Duvall, he is making lots of improvements to vagrant right now. he is "marxarelli" on IRC [15:48:22] chrismcmahon: aaah, cool! [15:48:33] chrismcmahon: don't have time atm, though, but it shouldn't be 'too hard' [15:49:46] YuviPanda: Dan is our new "Automation Engineer" and we are pointing him to anything that looks remotely like Ruby, including vagrant and puppet to start [15:50:26] aaah cool [16:01:16] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981#c3 (10Chris Steipp) Wow, that's bad. Is hhvm able to talk to both memcached and redis? Does it respect our setting up redis/memcache as the session storage instead of... [16:01:39] !log integration Killed stuck beta-update-databases-eqiad job [16:01:41] Logged the message, Master [16:05:01] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981#c4 (10Chris McMahon) As of about an hour ago: 07:55 ori: chrismcmahonbrb: i'll fix it [16:10:03] !log integration beta-update-databases-eqiad job was stuck for ~24 hours :( [16:10:05] Logged the message, Master [16:37:05] !log deployment-prep scap failing to deploymnet-videoscaler01 and deploymnet-jobrunner01 due to ssh auth failures; likely a puppet config problem [16:37:07] Logged the message, Master [16:59:43] !log deployment-prep scap failing to deploymnet-videoscaler01 and deploymnet-jobrunner01 due to other random failures now. Lots of strange permissions errors during rsync [16:59:47] Logged the message, Master [17:10:20] !log rebooting deployment-videoscaler01 to see if that fixes things [17:10:20] rebooting is not a valid project. [17:13:52] Coren, et al: Hi! I'm trying to make something on tool labs with Python. I got a basic script working, but I'd like to do it with Python 3 instead of 2. [17:13:55] Is that possible? [17:14:55] I can get to a Python3 command line on the tool account, but when I try to change the .lighttpd.conf to make it use python3, it breaks. [17:15:12] (That is, I think it crashes the web server instance) [17:22:13] ragesoss: There's no immediate reason why that would be the case that I can think of; lighttpd shouldn't care either way. [17:22:28] ragesoss: Do you have any diagnostic messages to help track it down? [17:22:54] Coren: no. Any idea how to generate some? [17:23:30] when I add the python3 entry to .lighttpd.conf and restart, after that I can't access the tool at all. [17:23:36] (including just the html page) [17:23:46] What's the tool's name? [17:23:50] I get the default tool offline thing. [17:23:55] scfc_de: coursestats [17:24:01] Huh. That points at an error in config; isn't there anything in the error.log? [17:25:19] Coren: ah, yes. [17:25:20] 2014-07-15 02:15:37: (server.c.1502) unlink failed for: /var/run/lighttpd/coursestats.pid 2 No such file or directory [17:25:26] !log rebooting deployment-jobrunner01 [17:25:26] rebooting is not a valid project. [17:25:52] ragesoss: That's 15 hours ago :-). [17:26:03] yes, I was working on it last night and got stuck. [17:27:09] ragesoss: Anything before that? [17:27:18] ragesoss: I think the more important lines are: "source: /var/run/lighttpd/coursestats.conf line: 563 pos: 1 parser failed somehow near here: (EOL)", "Duplicate config variable in conditional 0 global: cgi.assign" [17:27:50] ragesoss: And that tool doesn't have any .lighttpd.conf. What did the one look like that you used? [17:27:59] scfc_de: yeah, perhaps. I think it was different things I tried adding to the conf for different times. [17:29:10] cgi.assign = ( [17:29:11] ".py" => "/usr/bin/python3", [17:29:11] ) [17:29:16] or something like that, scfc_de. [17:30:11] what would be the right way to enable python3 scripts? [17:30:46] I'll try that as coursestats' .lighttpd.conf and we'll see :-). [17:32:31] Wait, there already is a cgi.assign for php, so you'd need to use "cgi.assign += [...]" to add one. [17:32:32] 3Wikimedia Labs / 3deployment-prep (beta): New users not created on loginwiki in Labs - 10https://bugzilla.wikimedia.org/62244#c24 (10Gilles Dubuc) 5RESO/FIX>3REOP The same symptoms have reappeared for the UploadWizard API test: https://integration.wikimedia.org/ci/job/UploadWizard-api-commons.wikimedia... [17:33:47] Oh, there's even a little information point about that on the help page, I just missed it. [17:34:03] Thanks Coren and scfc_de. I'll see if that works. [17:34:51] ragesoss: Coren's right; += works. Please see if it now calls Python 3 for .py. [17:34:54] * Coren returns to work on bigbrother. [17:48:01] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981 (10Chris McMahon) 5NEW>3RESO/FIX [18:09:09] !log tools.heritage Logging was fixed (?) [18:09:12] Logged the message, Master [18:09:34] 3Tool Labs tools / 3[other]: wiki viewstats incorrectly links .mw aggregate lines - 10https://bugzilla.wikimedia.org/68047 (10Jörn Hees) 3NEW p:3Unprio s:3normal a:3None Aggregate lines from the pageview files for the mobile wikipedia (as described in #68046) are incorrectly linked... [18:09:38] hmm [18:10:00] !log local-heritage Logging was fixed (?) [18:10:00] local-heritage is not a valid project. [18:10:34] 3Tool Labs tools / 3[other]: wiki viewstats incorrectly links .mw aggregate lines - 10https://bugzilla.wikimedia.org/68047 (10Jörn Hees) [18:15:12] andrewbogott / Coren : I'm cleaning up a bit on wikitech. Can you delete some pages for me or assign me admin so I can clean up myself? [18:15:37] multichill: I can delete, just pm me a list of links [18:15:56] multichill: {{Delete}} + time should also work :-). [18:16:06] 18:15, 15 July 2014 Coren (Talk | contribs | block) changed group membership for User:Multichill from shell to shell and contentadmin (No big deal) [18:16:18] or that :) [18:16:32] andrewbogott: Contentadmin is, really, no big deal. :_) [18:19:57] Ah, thank you. Moved all the local-.../SAL to tools..../SAL [18:21:58] andrewbogott: Thanks for fixing the bot! [18:22:42] multichill: sure thing. Glad it's working. [18:23:03] https://wikitech.wikimedia.org/wiki/Special:Contributions/127.0.0.1 <- I wonder why this is coming from localhost and not some account [18:23:07] btw, the !log feature was totally accidental. A rare case where a bug turned out to be a useful feature [18:23:17] rather than the more traditional opposite [18:24:01] 3Wikimedia Labs: Cannot log into nor reboot social-tools1 instance "The requested host does not exist. " - 10https://bugzilla.wikimedia.org/67545#c1 (10Andrew Bogott) 5NEW>3RESO/FIX It looks like this instance was mothballed after the eqiad migration, hence not really ready for login. As a rule, instances... [18:24:09] I alwasy used local-toolname, I didn't know the just toolname worked :P [18:24:25] well, that too [18:25:07] I'm not sure why the edits come in as 127.0.0.1. I've seen it doing that for a while but haven't investigated. [18:25:17] It's nice for projects where multiple people are changing things. And I'm used to keeping a log anyway :P [18:25:51] I believe that those 127.0.0.1 edits are from an openstack callback, e.g. on instance creation or reboot [18:26:13] !log deployment-prep Removed local mwdeploy user from /etc/passwd on deployment-videoscaler01 and deployment-jobrunner01 [18:26:15] Logged the message, Master [18:26:46] 3Tool Labs tools / 3[other]: wiki viewstats incorrectly links .mw aggregate lines - 10https://bugzilla.wikimedia.org/68047#c1 (10Jörn Hees) 5NEW>3RESO/INV oups, just found https://de.wikipedia.org/wiki/Wikipedia:Wiki_ViewStats will close this then... [18:26:50] hm… maybe not? [18:27:43] http://tools.wmflabs.org/wikidata-todo/autolist2.php is not available ... waiting it says [18:30:11] it ends with a 504 Gateway Time-out [18:31:13] multichill: ok, turns out those edits are done by mediawiki itself, via the jobqueue. [18:31:32] So, it sort of makes sense that it has lost track of who did it... [18:31:46] Lol, maybe assign a (dummy) username? [18:31:49] But maybe there's a way to attribute a job in the jobqueue to a particular editor? I don't know. [18:32:02] That's possible, several tools do that [18:32:17] For example importimages.php [18:44:37] multichill: something like this? https://gerrit.wikimedia.org/r/#/c/146512/ [18:44:47] can someone please start autolist2 again ? [18:45:26] GerardM-: It is running. [18:47:10] when I run the URL, it shows me a 504 .. [18:47:11] andrewbogott: Looks sensible [18:47:30] 'k, I'll finish up after lunch [18:47:32] 504 Gateway Time-out [18:53:56] Coren? [18:54:41] I have seen a couple of times that the erwin85 tools were not responding on the web [18:55:02] when looking at the error log I saw: [18:55:02] 2014-07-13 14:16:28: (server.c.1398) [note] sockets disabled, connection limit r [18:55:06] eached [18:55:14] GerardM-: I suppose it is timing out because it is taking to long. Magnus can diagnose that further. [18:55:33] akoopal: Ah. Does it look like that's normal (large) use, or is the tool being hammered by a bot/spider? [18:55:39] restarting the webservice helps, but is there a way to prevent it? [18:56:00] some of erwins tools are rather populair I think [18:56:27] so I think it is large use [18:57:48] hmm, don't see real ip's in the access.log, so can't see if there is one obvious IP doing requests [19:00:47] Coren: most usage seems to be randomarticle.php [19:00:48] it does not even start scfc_de [19:01:48] akoopal: Then I can increase its connection limit. Give me a minute. [19:02:40] akoopal: What's the tool name? [19:02:44] erwin85 [19:03:04] is it normal it needs to be restarted when it hits it? [19:03:57] akoopal: It doesn't have to, it'll just randomly not answer until the number of connections goes back down. Restarting it just hides the problem by dropping every connection so it'll look okay until it fills up again. [19:04:18] akoopal: I've just doubled the number of workers for next time it starts. If the issue was only high useage, that should help a lot. [19:04:28] ok, thanks [19:04:35] will give it a restart then [19:05:45] thanks for the help [19:08:46] 3Tool Labs tools / 3X!'s tools: LanguageTool removes article from watchlist - 10https://bugzilla.wikimedia.org/67991#c4 (10Daniel Naber) My conclusion is that there is no real fix. A fix would require people to log in for the tool, and/or it would slow down the checking. As a work-around I have added a warni... [19:10:09] akoopal: Another possible issue is workers that run for too long. If they stay around minutes, then it's not long before they're all in use. [19:10:50] Coren: ok, so if it comes back time for some performance analysis then [19:33:57] multichill: there's already a prod database that has the mariadb setup, so I ran the query you posted on labs-l [19:33:58] 1 row in set (0.02 sec) [19:34:00] :) [19:34:29] Hello, I'm maintainer of this service group and I have no idea why this happened [19:34:31] http://tools.wmflabs.org/wikitest-rtl/w/index.php?title=Main_Page [19:34:53] php update.php returns this: DB connection error: Access denied for user 'p50380g50529'@'10.68.16.8' (using password: YES) (tools-db) [19:35:06] YuviPanda: It's just a local copy of the database, right? [19:35:21] multichill: pretty much. [19:35:37] mysql:research@analytics-store.eqiad.wmnet [(none)]> SELECT * FROM wikidatawiki.wb_entity_per_page LIMIT 1; [19:35:41] multichill: ^ [19:36:06] 3Wikimedia Labs / 3deployment-prep (beta): New users not created on loginwiki in Labs - 10https://bugzilla.wikimedia.org/62244#c25 (10Andre Klapper) Gilles: Isn't that bug 63981? [19:36:30] Amir1: Are you talking about the webservice not being up or the denied access? [19:36:53] That was one of the big things that went MIA in the whole toolserver/toollabs migration YuviPanda. Nice to see it coming back [19:36:53] scfc_de: both [19:37:06] multichill: :) [19:37:41] I'm restarting the webservice to see what happens [19:37:42] Cross database joins are painfull right now. I forgot one and left it running. 10 row took 11 hours :P [19:37:50] :) [19:37:53] btw: hi, multichill and YuviPanda [19:37:59] hi Amir1 [19:38:11] hi Amir1 :) [19:38:15] Back from your trip? [19:38:27] multichill: still here [19:38:33] I hate this city [19:38:42] Which one are you? [19:39:05] Dubai [19:39:21] hot and humid [19:39:35] illegal to eat or drink in public during the day [19:40:04] Ah, feels like home? :P [19:40:43] in home they don't enforce the law specially where I live [19:40:54] in this here is worse than home [19:40:59] *in this case [19:41:35] 3Wikimedia Labs / 3deployment-prep (beta): Login error when attempting to log in on beta-hhvm wikis - 10https://bugzilla.wikimedia.org/63981 (10Andre Klapper) [19:41:35] Ramadan is easier in the Middle East I guess, here the days are very long right now. Only 21:53 - 05:38 with darkness [19:42:04] Amir1: The webserver is started, but has an internal error; unfortunately error.log doesn't reveal anything *now*, but I would look for the cause of "2014-07-15 18:22:47: (mod_fastcgi.c.2701) FastCGI-stderr: PHP Fatal error: Call to a member function disable() on a non-object in /data/project/wikitest-rtl/public_html/w/includes/GlobalFunctions.php on line 2191" [19:42:44] scfc_de: thank you, I haven't changed anything [19:42:47] multichill: but it's not hot there [19:43:02] 3Wikimedia Labs / 3deployment-prep (beta): New users not created on loginwiki in Labs - 10https://bugzilla.wikimedia.org/62244#c26 (10Gilles Dubuc) 5REOP>3RESO/FIX Probably, since it just came back to normal. [19:43:17] Amir1: My brother used to live in Dubai. He didn't like it that much I think. Now he lives in New Delhi and he hates it :P [19:43:31] This weekend it's going to be hot (30+) and humid [19:45:02] multichill: I don't know how bad New Delhi would be but this place is worst place I've been in my entire life. [19:45:16] multichill: do you know lots of cities in Iran are cold [19:45:20] Dubai + a lot of pollution [19:45:42] e.g. Zanjan and Tabriz are freezing cold [19:45:48] High up right? [19:45:48] Tehran is mild [19:45:55] multichill: yes [19:46:19] Like Mexico City :-) [19:46:25] hmm [19:46:48] One of wikipedia came in Iran to do some stuff, the first thing he said "I thought Tehran would be hotter" [19:47:05] *wikipedians [19:47:29] Ha, assumptions, assumptions...... [19:49:22] scfc_de: I'm updating so it may work [19:50:25] didn't work [19:50:35] and I still can't connect to db [19:52:06] multichill: by the way, I'm importing lots of coordinates to Wikidata [19:52:10] about 200K [19:52:20] Oh? From where? Italian wp? [19:52:35] All of big wikis [19:52:43] Amir1: If I do "sql enwiki" as tools.wikitest-rtl, it works, so the password is correct; are you sure you're using the correct one in (I suppose) MediaWiki? [19:52:44] Klosses has a database [19:53:16] Ah, you're using Tim's big db. That's nice! [19:53:33] scfc_de: maybe the localsettings is wrong [19:53:56] Amir1: It is. Also, please make LocalSettings.php not world-readable :-). [19:54:19] (I. e. "chmod o-r LocalSettings.php".) [19:54:49] I usually use chmod 770 for my codes [19:54:52] If MediaWiki can't connect to the database, that would probably also explain why its web platform doesn't start. [19:55:16] yes, I thought these issues are connected [19:55:26] Amir1: That would work as well. Just important that the last digit is 0 or -. [19:55:40] *or the last three characters are ---. [19:56:22] but the issue is I don't know why the mediawiki can't connect to the database [19:56:43] maybe some databases have changed [19:57:40] Amir1: You use a password in LocalSettings.php that is not the one in replica.my.cnf. [19:58:22] Oh! You're using tools-db. If I could remember how that worked ... [19:59:04] Coren: For tools-db, the old accounts à la p50380g50529 were grandfathered in, weren't they? [20:00:24] scfc_de: is it possible to change the database to something new or more easier to use? [20:00:38] instead of tools-db [20:02:23] Amir1: https://wikitech.wikimedia.org/wiki/Tool_Labs/Migration_to_eqiad#My_database_is_missing_from_tools-db [20:04:08] I don't see a database of user tools.wikitest-rtl on tools-db (would be (re-)named s51149__*), so either Coren has it saved somewhere or you'll need to resetup. [20:06:37] multichill: fyi, that patch is merged and will be deployed on Monday. [20:06:43] scfc_de: I just changed it as what it's written there and this is the new error: DB connection error: Unknown database 's51149__wikitest-rtl' (tools-db) [20:06:58] Good job! [20:07:50] qchris: Do you know of any Gerrit client libraries for Perl or Python that provide nice wrappers "commit ('Iabc...')->status (); ...->files ();", etc.? Googling and asking valhallasw was unsuccessful :-), and the ones I found were /too/ thin. [20:09:45] scfc_de: No, I don't. YuviPanda did some Python glue around gerrit ... not sure if it has an API wrapper. [20:10:05] hmm, I was writing my own, I think? [20:10:10] oh dear, I forgot :| [20:10:17] scfc_de: I just commanded "finish-migration wikitest-rtl" [20:10:25] but no change, maybe I should wait [20:10:48] Amir: I don't see a database of user tools.wikitest-rtl on tools-db (would be (re-)named s51149__*), so either Coren has it saved somewhere or you'll need to resetup. [20:11:02] qchris, YuviPanda: Thanks! [20:11:11] ah, no, I was going to write my own and then got distracted [20:11:15] so no beuon [20:11:18] beuno [20:11:39] scfc_de: okay [20:11:44] scfc_de: Sorry :-/ [20:14:35] hey, our labs-vagrant server ee-flow-extra lost /mediawiki/vagrant , so nothing works! [20:15:04] spagewmf: Blerg. No /vagrant directory at all [20:15:07] ? [20:15:39] I had a patch merged today to mount /srv and migrate the files from /mnt/vagrant to /srv/vagrant [20:15:42] bd808: is it related to https://gerrit.wikimedia.org/r/#/c/145974/ ? /vagrant symlink to /srv/vagrant, has only LocalSettings.php in it, no more /srv/vagrant/mediawiki [20:17:03] well, /srv/vagrant has various bits and pieces in it, but not mediawiki [20:17:06] thanks [20:17:24] spagewmf: Do you still have a /mnt/vagrant directory? [20:17:48] bd808: /mnt is empty [20:18:37] scfc_de: thank you for your help :) I'm here until Coren comes [20:18:39] there's a /data/scratch/mediawiki ... [20:19:12] spagewmf: Hmmm... the script that moved things should only have deleted /mnt/vagrant if the copy had worked [20:19:32] but /data/scratch/mediawiki is by Nemo_bis from July 13, probably not relevant [20:19:55] let me check an instance in another project and see what happened to it [20:20:58] bd808: thanks. There's nothing in /srv/vagrant/logs but an empty puppet subdir. [20:24:02] please don't delete that directory, it's being used by a script [20:24:45] spagewmf: my instance at wikimania-scholarships seems to have suffered a similar fate. It looks like I ended up with a new checkout of vagrant in the /srv/vagrant directory instead of the existing code being copied over :/ [20:25:01] I tested this too :/ [20:25:15] Nemo_bis: I won't, we have an unrelated problem with /vagrant/mediawiki [20:26:18] bd808: no worries, it happens. We did have a DB backup in ee-flow-extra:/srv/vagrant/mediawiki/extensions/Flow from a few days ago but it's far from critical [20:26:56] spagewmf: thanks for being nice about it. I still feel crappy [20:28:23] If you ended up with a new clone of vagrant like I did and you are on a Ubuntu 12.04 host like I am, you will need to do 'git checkout precise-compat' in /vagrant to get a version that will run properly on your host. [20:28:39] The head of vagrant only works on 14.04 boxes now. [20:28:47] I'll rm -rf somewhere on production in solidarity :) [20:29:29] Amir1: there is one database backup at /data/backups/tools-db/ http://tools.wmflabs.org/tools-info/explorer/?dir=public/backups/tools-db [20:29:38] This might be a good time to replace your labs instance with a 14.04 host too. :/ [20:30:42] Coren: fyi, there's a link on boingboing right now to unicorn.wmflabs.org. Probably fine, but… just a warning that we might see some extra traffic. [20:31:40] andrewbogott: It looks like my patch (https://gerrit.wikimedia.org/r/#/c/145974/) may have not worked as I'd planned (and tested). [20:31:53] bd808: We'll see. I did the git checkout, enabled a role, now `sudo labs-vagrant provision` [20:32:12] bd808: what are you seeing? [20:32:23] andrewbogott: spagewmf and I both have instances where the copy the old to new step didn't work [20:32:26] I tried it on my existing vagrant box and it seems fine; haven't tried on a fresh one. [20:32:34] Oh? I got a copy and a symlink [20:32:51] andrewbogott: That's good. maybe failure is hit and miss [20:33:22] Well, 'good' -- it would be better if it always failed the same way :) [20:33:25] wikimania-scholarships definitely ended up with a new clone of mw-vagrant [20:34:14] bd808: so, you have an old install in /vagrant and a new one in /srv/vagrant? [20:34:50] No. old /mnt/vagrant is gone; symlink points to new checkout in /srv/vagrant [20:35:03] Like maybe the "before" constraint didn't work? [20:36:43] oh, wait -- I never had anything in /mnt/vagrant, only /vagrant [20:36:48] I think... [20:36:55] maybe not, I guess I never looked to see if it was a symlink :) [20:38:08] andrewbogott: Here's the puppet log from the run that did the change -- http://paste.debian.net/109989/ [20:41:14] bd808: it looks like that could potentially move vagrant to /srv and /then/ create the partition and mount (thus concealing the vagrant that was moved) and then determind that vagrant is not yet installed [20:41:21] although that doesn't sound like what you're seeing [20:42:30] Oh man it could. [20:43:25] I was counting on the require for the lvm role, but that maybe doesn't mean it will be done before the other include? [20:45:19] andrewbogott: That's what happened. I see the copy happen before the mount. [20:45:20] bd808: You need to require a specific resource; in this case Mount['/srv'] [20:45:43] yep, just order the dependency and it should work [20:45:49] Coren: Yup. So randomly hosts will be ok and borked :/ [20:46:19] It's done now across all of labs I'd imagine [20:46:56] bd808: ee-flow-extra is back in business after error-free provision, complete with spam posts [20:47:45] spagewmf: Great. I'm guessing that your prior version is sitting on the primary disk, right underneath the mount point for the new one. I made a dumb puppet error [20:48:22] I can see in /var/log/puppet.log that that's what happened on wikimania-scholarships [20:48:52] You should be able to access the shadowed copy with "mount --bind", if necessary. [20:50:02] hedonil: I just saw your message [20:50:08] let me check [20:50:59] scfc_de: can you copy this back up to some place else so I can connect to it [20:51:00] http://tools.wmflabs.org/tools-info/explorer/?dir=public/backups/tools-db [20:51:05] (wikitest-rtl) [20:52:03] scfc_de: Thanks! That actually works. [20:52:15] * bd808 will write an email to labs-l [20:53:32] bd808: Trick that Coren once taught :-). [20:55:46] Amir1: Your tool account tools.wikitest-rtl can read /public/backups/tools-db/p50380g50529__wikitest-rtl.sql.gz directly. [20:57:39] bd808: on ee-flow-extra I uncovered /srv and am moving stuff from it. Is there a file that records what labs-vagrant roles were enabled? [20:58:36] spagewmf: vagrant/puppet/manifests/manifests.d/vagrant-managed.pp [21:11:27] Hoi ... there is trouble in paradise ... not only Autolist2 and related tools fail the same is true for https://tools.wmflabs.org/wikidata-todo/stats.php [21:13:14] Coren: poke on the graphite box? [21:21:03] scfc_de: it returns me this error: [21:21:06] tools.wikitest-rtl@tools-dev:~$ mysql s51149__wikitest-rtl < p50380g50529__wikitest-rtl.sql [21:21:07] ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) [21:21:27] maybe I'm doing something wrong or it needs a admin to do it [21:21:33] *an admin [21:24:08] Amir1: you need to tell mysql the hostname [21:24:22] Amir1: or use wrapper script *sql* [21:24:30] Amir1: sql local < bla [21:25:05] hedonil: I tried the sql tools.wikitest-rtl@tools-dev:~$ sql s51149__wikitest-rtl < p50380g50529__wikitest-rtl.sql [21:25:07] This is unknown db to me, if you don't like that, blame petan on freenode [21:25:08] Make sure to ask for a db in format of _p [21:25:32] Amir1: sql *local* < bla [21:25:41] local = tools-db [21:27:23] hedonil: ERROR 1044 (42000) at line 22: Access denied for user 's51149'@'%' to database 'p50380g50529__wikitest-rtl' [21:27:39] sounds better ;) [21:27:45] :)) [21:28:39] Coren had a níce onliner for restoring old databases with new name [21:28:49] I think I can fix it, [21:28:53] just a min. [21:36:22] i think my solution is working [21:36:28] Amir1: great [21:37:14] hedonil: scfc_de It worked [21:37:16] :) [21:37:45] I renamed the database name in the back up file via python [21:39:11] wheeee labs-vagrant breakage [21:39:31] brion: I sent an email to labs-l :( [21:39:40] bd808: reading it now :D [21:39:47] still error [21:39:55] http://tools.wmflabs.org/wikitest-rtl/w/index.php?title=Main_Page [21:40:13] I was able to run update.php without any issues [21:42:57] bd808: woot, that worked :D http://ogvjs-testing.wmflabs.org/wiki/Main_Page is live again [21:42:59] thanks! [21:43:29] 2014-07-15 21:40:47: (request.c.1141) POST-request, but content-length missing -> 411 [21:43:34] brion: Glad I could fix what I broke. [21:44:00] Amir1: That can't be related to a simple GET of the main page. [21:44:12] whoops gotta copy my /srv/images too [21:44:22] aaand it’s fixed [21:44:24] you're right [21:44:42] scfc_de: let me dig deeper [21:47:07] Amir1: If I directly "curl -H 'Host: tools.wmflabs.org' -I http://tools-webgrid-04:4032/wikitest-rtl/w/index.php?title=Main_Page", no error message at all is delivered. Maybe enable the standard MediaWiki debug options to get some errors? [21:47:49] sure [21:53:56] scfc_de: what do you think about this: http://paste.ubuntu.com/7800548/ [21:56:29] Amir1: That looks more like the errors you would expect when you run MediaWiki from the command line? I don't know if they're related. [22:00:01] scfc_de: yeah I thought that too but it worked for once [22:00:16] installing mediawiki is a pain in the ass [22:00:25] always and never gets easy [22:00:30] Amir1: http://tools.wmflabs.org/wikitest-rtl/w/README works [22:01:19] (So it's not a server problem, but PHP/MediaWiki.) [22:01:38] maybe the permission is not okay -rw-r--r-- 1 tools.wikitest-rtl tools.wikitest-rtl 4386 Jul 15 19:49 api.php [22:01:39] Amir1: http://tools.wmflabs.org/wikitest-rtl/w/scfc-test.php works, so it's a MediaWiki problem. [22:01:49] No, the permissions look fine. [22:03:38] But the POST mystery has been solved: That's MediaWiki calling MediaWiki to run the job queue. [22:04:04] And index.php gets redirected to index.php?title=Main_Page, so not all is broken. [22:04:25] I'm updating everything [22:13:59] scfc_de: now it's working [22:14:13] I'm going to drink a bottle of vodka [22:14:15] :D [22:29:14] In Dubai? Be careful :-). [22:48:41] bd808: FYI the confirmedit role doesn't work in labs-vagrant on 12.04, can't locate package dejavu-fonts. But now I'm getting all kinds of provision errors, it's trying to manipulate files in a non-existent /etc/php5/conf.d [22:49:49] spagewmf: Just confirmedit or other roles too? (/etc/php5/conf.d) [22:51:00] bd808: I'm not sure. enable-role confirmedit had all kinds of errors starting withthe missing dejavu-fonts package, so I disabled it, now provision fails [22:52:09] I'd like to say that we will fix 12.04 bugs but I know that in reality we've jumped forward to 14.04 and will probably not have much bandwidth for backports. [22:52:34] Patches welcome though. There is a branch for 12.04 compatibility. [22:54:10] bd808: sounds reasonable. If I create a new labs instance can I rename this one so the new one reuses ee-flow-extra [22:55:00] spagewmf: I don't know if there is an way to rename an existing instance. Maybe Coren or andrewbogott can say? [22:55:29] bd808: Not really. [22:55:34] I have jsut copied things to /data/project, deleted and recreated previously [22:55:39] If there were, it would almost certainly be more trouble than just making a new one [22:56:34] spagewmf: I would guess a db dump plus your /vagrant dir and maybe some image caches would be most of what you'd want to preserve [22:57:30] bd808: yeah, sounds familiar from the eqiad migration. [22:58:35] in https://wikitech.wikimedia.org/wiki/Special:NovaInstance , some of our instances' "Image ID" say "ubuntu-12.04-precise (deprecated 2014-04-17)" , but others just say "ubuntu-12.04-precise" [23:04:00] spagewmf: That's nothing to worry about. I periodically update the base image, so an VM that's not based on the very latest image will have a note like that. [23:12:23] I updated https://wikitech.wikimedia.org/wiki/Labs-vagrant to recommend Image type "ubuntu-14.04-trusty". [23:14:31] Labs-vagrant page says "ssh to your instance, and wait" ... for what? A puppet run? [23:15:09] https://wikitech.wikimedia.org/wiki/Help:Instances page says "you can run puppet by running `sudo puppetd -tv` but I get command not found [23:16:07] spagewmf: use sudo puppet agent -tv now [23:16:12] * YuviPanda updates doc [23:16:34] bah, no phone, so can't use 2factor auth :( [23:17:08] YuviPanda: you answered faster than Google. I'll update the page, thanks. [23:20:17] spagewmf: :) [23:25:29] spagewmf: thanks for https://wikitech.wikimedia.org/w/index.php?title=Help:Instances&diff=next&oldid=117411 , I got caught by this error :) [23:26:09] yw [23:31:20] coren are you around ?