[00:01:30] New patchset: Hashar; "rm files/php/wmerrors.ini (moved to appserver module)" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/68829 [00:01:30] New patchset: Hashar; "PHP fatal destination is now a class parameter" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/68830 [00:01:30] New patchset: Hashar; "vary wmerrors.ini 'fatal_log_file' per realm" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/68831 [00:04:26] !log reloading squid config on cp1001-cp1020 (text eqiad) for RT-5296 [00:04:34] Logged the message, Master [00:08:07] Change merged: jenkins-bot; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68825 [00:25:13] New patchset: Hashar; "beta: wikidata@master now requires WikibaseDataModel" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68833 [00:32:09] New review: Dzahn; "(1 comment)" [operations/apache-config] (master) - https://gerrit.wikimedia.org/r/65443 [00:32:41] Change abandoned: Hashar; "apparently unneeded now.. not sure what happened." [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68833 [00:35:03] New patchset: Dzahn; "add a script and cron to mail out bugzilla audit log and move bugzilla scripts to files/bugzilla instead of misc" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/56562 [00:35:47] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [00:36:37] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.125 second response time [00:57:39] !log reedy synchronized php-1.22wmf6/extensions/SecurePoll/ [00:57:47] Logged the message, Master [01:32:39] RECOVERY - NTP on ssl3003 is OK: NTP OK: Offset -0.002747893333 secs [01:33:29] RECOVERY - NTP on ssl3002 is OK: NTP OK: Offset -0.0009081363678 secs [01:39:30] New patchset: Yurik; "Synced up varnish VCL file with configuration on meta" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/68840 [01:59:37] New patchset: Yurik; "Removed X-Carrier header" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/68841 [02:03:16] Change abandoned: Yurik; "Moved to https://gerrit.wikimedia.org/r/#/c/68841/" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/62867 [02:05:21] !log reedy synchronized php-1.22wmf6/extensions/SecurePoll/ [02:05:30] Logged the message, Master [02:08:17] !log LocalisationUpdate completed (1.22wmf6) at Sat Jun 15 02:08:17 UTC 2013 [02:08:25] Logged the message, Master [02:12:49] New patchset: Jforrester; "Run VisualEditor default-on A/B split test for new accounts on enwiki" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68846 [02:13:57] !log LocalisationUpdate completed (1.22wmf7) at Sat Jun 15 02:13:57 UTC 2013 [02:14:05] Logged the message, Master [02:19:50] !log LocalisationUpdate ResourceLoader cache refresh completed at Sat Jun 15 02:19:50 UTC 2013 [02:19:59] Logged the message, Master [02:36:44] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [02:37:35] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.128 second response time [02:50:43] New patchset: Reedy; "Update old links to gitweb" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68848 [02:51:04] Change merged: Reedy; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68848 [04:13:57] PROBLEM - Puppet freshness on manutius is CRITICAL: No successful Puppet run in the last 10 hours [05:01:56] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [05:02:46] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.129 second response time [05:33:49] PROBLEM - NTP on ssl3002 is CRITICAL: NTP CRITICAL: No response from NTP server [05:36:52] PROBLEM - NTP on ssl3003 is CRITICAL: NTP CRITICAL: No response from NTP server [06:13:32] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [06:14:22] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.127 second response time [06:22:32] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [06:23:22] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.126 second response time [06:40:34] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [06:41:24] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.124 second response time [06:56:34] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [06:57:24] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.128 second response time [07:00:34] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [07:03:24] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.129 second response time [07:30:44] New patchset: MaxSem; "Enable mobile host for Commons" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68851 [07:58:35] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [07:59:25] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.123 second response time [08:31:29] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [08:32:19] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.129 second response time [08:32:39] RECOVERY - NTP on ssl3002 is OK: NTP OK: Offset -0.0007095336914 secs [08:33:53] Change merged: jenkins-bot; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68851 [08:37:05] !log maxsem synchronized wmf-config/InitialiseSettings.php 'Mobile host for Commons' [08:37:14] Logged the message, Master [08:52:33] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [08:53:21] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.136 second response time [09:02:30] RECOVERY - NTP on ssl3003 is OK: NTP OK: Offset 0.001187324524 secs [09:30:40] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [09:32:30] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.129 second response time [09:44:06] PROBLEM - Puppet freshness on labstore4 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:06] PROBLEM - Puppet freshness on erzurumi is CRITICAL: No successful Puppet run in the last 10 hours [09:44:06] PROBLEM - Puppet freshness on lvs1004 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:06] PROBLEM - Puppet freshness on lvs1005 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:06] PROBLEM - Puppet freshness on lvs1006 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:07] PROBLEM - Puppet freshness on mc15 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:07] PROBLEM - Puppet freshness on mw1020 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:08] PROBLEM - Puppet freshness on ms-fe3001 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:08] PROBLEM - Puppet freshness on sockpuppet is CRITICAL: No successful Puppet run in the last 10 hours [09:44:09] PROBLEM - Puppet freshness on spence is CRITICAL: No successful Puppet run in the last 10 hours [09:44:09] PROBLEM - Puppet freshness on virt1 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:10] PROBLEM - Puppet freshness on virt3 is CRITICAL: No successful Puppet run in the last 10 hours [09:44:10] PROBLEM - Puppet freshness on virt4 is CRITICAL: No successful Puppet run in the last 10 hours [11:38:00] New review: Jeroen De Dauw; "Wikibase will automatically include this thing if its found at ../WikibaseDataModel/WikibaseDataMode..." [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68833 [11:46:37] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [11:47:27] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.122 second response time [12:15:03] RECOVERY - Puppet freshness on sockpuppet is OK: puppet ran at Sat Jun 15 12:14:52 UTC 2013 [12:20:33] RECOVERY - Puppet freshness on mw1020 is OK: puppet ran at Sat Jun 15 12:20:22 UTC 2013 [12:21:33] PROBLEM - Host wtp1008 is DOWN: PING CRITICAL - Packet loss = 100% [12:23:05] RECOVERY - Host wtp1008 is UP: PING OK - Packet loss = 0%, RTA = 0.25 ms [12:35:48] New review: Diederik; "Ok" [operations/puppet] (production) C: 1; - https://gerrit.wikimedia.org/r/68841 [13:30:49] PROBLEM - Parsoid on wtp1007 is CRITICAL: Connection refused [13:30:49] PROBLEM - Parsoid on wtp1023 is CRITICAL: Connection refused [13:30:58] PROBLEM - Parsoid on wtp1004 is CRITICAL: Connection refused [13:31:48] RECOVERY - Parsoid on wtp1023 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.013 second response time [13:40:03] RECOVERY - Parsoid on wtp1004 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.016 second response time [13:45:00] RECOVERY - Parsoid on wtp1007 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.011 second response time [14:04:35] New patchset: Odder; "(bug 49612) Localise $wgSitename for fr.wikibooks" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/68858 [14:14:10] PROBLEM - Puppet freshness on manutius is CRITICAL: No successful Puppet run in the last 10 hours [14:25:40] PROBLEM - Parsoid on wtp1003 is CRITICAL: Connection refused [14:39:35] RECOVERY - Parsoid on wtp1003 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.006 second response time [14:42:54] PROBLEM - Parsoid on wtp1010 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [15:22:51] RECOVERY - Parsoid on wtp1010 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.007 second response time [15:35:31] PROBLEM - DPKG on mc15 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [15:38:28] RECOVERY - DPKG on mc15 is OK: All packages OK [15:45:47] PROBLEM - Parsoid on wtp1020 is CRITICAL: Connection refused [15:53:47] RECOVERY - Parsoid on wtp1020 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.003 second response time [15:55:57] PROBLEM - RAID on mc15 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [15:56:47] RECOVERY - RAID on mc15 is OK: OK: Active: 2, Working: 2, Failed: 0, Spare: 0 [16:14:48] PROBLEM - Disk space on mc15 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [16:15:37] RECOVERY - Disk space on mc15 is OK: DISK OK [17:15:43] PROBLEM - Parsoid on wtp1005 is CRITICAL: Connection refused [17:25:21] PROBLEM - Parsoid on wtp1021 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [17:27:41] RECOVERY - Parsoid on wtp1005 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.012 second response time [17:32:12] RECOVERY - Parsoid on wtp1021 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.015 second response time [17:39:13] PROBLEM - Parsoid on wtp1022 is CRITICAL: Connection refused [17:40:03] PROBLEM - Parsoid on wtp1015 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [17:45:54] RECOVERY - Parsoid on wtp1015 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.014 second response time [17:59:25] PROBLEM - SSH on lvs6 is CRITICAL: Server answer: [17:59:41] greg-g: [18:00:13] RECOVERY - Parsoid on wtp1022 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.004 second response time [18:00:23] RECOVERY - SSH on lvs6 is OK: SSH OK - OpenSSH_5.9p1 Debian-5ubuntu1.1 (protocol 2.0) [18:12:21] PROBLEM - SSH on cp1043 is CRITICAL: Server answer: [18:13:21] RECOVERY - SSH on cp1043 is OK: SSH OK - OpenSSH_5.9p1 Debian-5ubuntu1.1 (protocol 2.0) [18:31:21] PROBLEM - Host wtp1008 is DOWN: PING CRITICAL - Packet loss = 100% [18:32:01] RECOVERY - Host wtp1008 is UP: PING OK - Packet loss = 0%, RTA = 0.27 ms [18:33:11] PROBLEM - Parsoid on wtp1014 is CRITICAL: Connection refused [18:36:44] PROBLEM - Parsoid on wtp1021 is CRITICAL: Connection refused [18:50:44] RECOVERY - Parsoid on wtp1021 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.003 second response time [18:57:05] RECOVERY - Parsoid on wtp1014 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.007 second response time [19:44:36] PROBLEM - Puppet freshness on erzurumi is CRITICAL: No successful Puppet run in the last 10 hours [19:44:36] PROBLEM - Puppet freshness on labstore4 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:36] PROBLEM - Puppet freshness on lvs1004 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:36] PROBLEM - Puppet freshness on lvs1005 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:36] PROBLEM - Puppet freshness on lvs1006 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:37] PROBLEM - Puppet freshness on mc15 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:37] PROBLEM - Puppet freshness on ms-fe3001 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:38] PROBLEM - Puppet freshness on spence is CRITICAL: No successful Puppet run in the last 10 hours [19:44:38] PROBLEM - Puppet freshness on virt1 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:39] PROBLEM - Puppet freshness on virt3 is CRITICAL: No successful Puppet run in the last 10 hours [19:44:39] PROBLEM - Puppet freshness on virt4 is CRITICAL: No successful Puppet run in the last 10 hours [20:34:33] PROBLEM - Parsoid on wtp1006 is CRITICAL: Connection refused [20:49:25] If i want to submit a patch for Apache redirect rules (httpd.conf-style), what repo/file should I be looking at? [20:49:35] Presumably something in operations (if I can at all) [20:50:27] operations/apache-config [20:51:08] MaxSem: Aha! Thanks [20:54:00] RECOVERY - Parsoid on wtp1006 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.002 second response time [20:55:23] MaxSem et al.: Hmm, I'm looking for redirects to thumb.php, can't seem to find them in that repo (but maybe I'm being blind), any ideas? [20:56:52] PROBLEM - Parsoid on wtp1018 is CRITICAL: Connection refused [21:06:00] PROBLEM - Parsoid on wtp1012 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [21:08:40] PROBLEM - Parsoid on wtp1016 is CRITICAL: Connection refused [21:08:50] RECOVERY - Parsoid on wtp1018 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.007 second response time [21:16:16] * Elsie bites basile. [21:17:51] PROBLEM - Parsoid on wtp1015 is CRITICAL: Connection refused [21:24:40] RECOVERY - Parsoid on wtp1016 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.004 second response time [21:40:32] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [21:40:52] RECOVERY - Parsoid on wtp1015 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.004 second response time [21:43:22] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.130 second response time [21:57:33] PROBLEM - Puppetmaster HTTPS on stafford is CRITICAL: CRITICAL - Socket timeout after 10 seconds [21:58:22] RECOVERY - Puppetmaster HTTPS on stafford is OK: HTTP OK: Status line output matched 400 - 336 bytes in 0.128 second response time [22:20:49] PROBLEM - Parsoid on wtp1001 is CRITICAL: Connection refused [22:29:49] PROBLEM - Parsoid on wtp1009 is CRITICAL: Connection refused [22:31:49] PROBLEM - Parsoid on wtp1017 is CRITICAL: Connection refused [22:32:49] RECOVERY - Parsoid on wtp1017 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.006 second response time [22:32:49] RECOVERY - Parsoid on wtp1009 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.006 second response time [22:44:08] odder: mis-ping? it was contentless, so i assume so [22:44:48] RECOVERY - Parsoid on wtp1001 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.011 second response time [22:51:48] PROBLEM - DPKG on mc15 is CRITICAL: Timeout while attempting connection [22:53:48] RECOVERY - DPKG on mc15 is OK: All packages OK [22:57:29] RECOVERY - Parsoid on wtp1012 is OK: HTTP OK: HTTP/1.1 200 OK - 1373 bytes in 0.003 second response time [22:59:29] Ryan_Lane: poke [23:06:10] PROBLEM - NTP on ssl3003 is CRITICAL: NTP CRITICAL: No response from NTP server [23:06:30] PROBLEM - NTP on ssl3002 is CRITICAL: NTP CRITICAL: No response from NTP server [23:11:50] * AzaToth pokes Ryan_Lane  [23:16:11] New patchset: AzaToth; "Updating debian package files" [operations/debs/adminbot] (master) - https://gerrit.wikimedia.org/r/68935 [23:16:41] Ryan_Lane: I notice that morebots is "unlicensed" [23:16:56] I would assume it means you cannot run it at all right? [23:34:25] AzaToth: link? [23:34:55] there is a http://unlicense.org/, which, while a "crayon license" is probably good enough for our uses. [23:35:56] ("crayon license" meaning not written by lawyers and just copy/pasting things together and hoping they work and accomplish the desired goal) [23:39:03] greg-g: https://gerrit.wikimedia.org/r/68935 [23:39:37] greg-g: the original coptright file stated "Unlicensed for adminlogbot.py and adminlog.py (for now)" [23:39:53] I updated the file to dep5 [23:40:37] greg-g: I would assume they actually meat that there is no license, not that they use "unlicensed" [23:40:49] yeah, I see now, agree [23:41:01] yeah, that should be fixed, trivially, given the list of authors is a known list of people :) [23:41:09] as it is Ryan_Lane who wrote it [23:41:22] sadly the files in question doesn't specify any license [23:41:47] and while statusnet.py states "GPL3", it's not enough [23:42:14] but yea, it should be easy to fix [23:42:40] do you have any general license enacting policy? [23:42:54] i.e. everything you do is licensed under a said license? [23:43:52] ori-l: you are part of the problem :-P [23:44:57] what did I do? [23:45:28] ori-l: make a commit to adminlog.py [23:46:11] AzaToth: if you're sorting that out, my contributions may be licensed under any free software license, so feel free to pick one that works [23:46:19] hehe [23:46:54] ori-l: problem was that the copyright file explicitly stated "Unlicensed for adminlogbot.py and adminlog.py (for now)" [23:47:53] that's not a great copyright header, as far as those things go [23:48:48] yea [23:48:57] I blame Ryan_Lane many times for that [23:49:06] I would hazard a guess that the packager simply meant that no license information was available [23:49:18] so by "unlicensed" he probably meant "no license information available at this time" [23:50:00] I don't know where Ryan_Lane took it from or if he wrote it himself [23:50:15] no informantion regarding that is available in the repo [23:50:24] did you check SVN? [23:50:28] someone else wrote it [23:50:31] I modified it [23:50:36] it was on wikitech [23:50:54] on wiki? [23:51:00] no. on the server [23:51:03] ok [23:51:18] maybe it was written by domas? or river? or andrew garret? [23:51:31] I think domas [23:51:55] I would assume legally it could be a problem? [23:52:20] or do you have a general license for things you do? [23:53:11] especially because it's more than a hack script [23:59:29] PROBLEM - Parsoid on wtp1011 is CRITICAL: Connection refused