[00:01:24] jarry1250: I should be able to push the new version sometime tonight. [00:01:39] jorm: I go check. [00:01:41] Coren: Cool, thank you :) [00:01:57] danke shoen. [00:02:42] jorm: I see nothing broken a priori. What happens when you try? [00:03:13] ssh: connect to host unicorn.wmflabs.org port 22: Operation timed out [00:15:15] jorm: maybe it OOM'd? [00:16:22] Coren, andrewbogott_afk: virt11 is getting very, very close to running out of disk space [00:16:31] may want to move some virtual machines around [00:16:52] also, virt11 still has that 160GB base image since an instance is using it [00:17:02] i can access it via web. [00:17:04] just not ssh. [00:17:06] if you fix that problem you can free up 160GB [00:17:12] jorm: OOM killer may have killed ssh [00:17:15] try rebooting it [00:17:21] how? [00:17:31] i know not of your openstack magick. [00:20:34] via wikitech [00:20:52] go to "Manage Instances", add your project to the filter at the top [00:21:03] then click "reboot" next to the instance in the list [00:22:02] virt5 has a failed disk [00:22:08] plus getting full too [00:25:15] welp, my contract hours are up for the week [00:25:42] most of the nodes are getting pretty full [00:25:52] people need to start cleaning after themselves :) [00:26:53] Actually; jorm, I can SSH to it fine. [00:27:17] Coren: ^^ :) [00:27:18] strange how i cannot. [00:27:39] i just rebooted it, though. [00:27:43] jorm: I should think the issue is on the network; I don't even see your attempts in the logs. [00:27:58] Coren: can't tell if this is more a remote or local internet problem but i've been seeing some iowait on tools-login. (I left `vmstat 1` running for a while on both tools-login and the bastion i was using) [00:27:59] paravoid: Bleh. Much fun. So hardware. [00:28:18] i.e. it might be my connection and a bit of iowait is normal [00:28:24] jeremyb: Tools-login is desperately overloaded, poor little thing. :-) [00:28:58] jeremyb: Mostly because of people who don't listen when we tell them to not run bots on -login. :-) [00:29:15] Coren: right, i spent a couple mins looking to see if there was one and then gave up [00:29:31] jorm: Welp, the box works fine, and I can SSH to it without issue and I don't see your attempts at all; I think you're not hitting the instance at all. [00:30:17] jeremyb: I see a couple. Time to bring out the hammer again. [00:30:34] traceroute reports fuckage at 208.80.153.214 [00:39:30] jorm: Where are you trying to connect /from/? [00:40:00] jorm: Also, you've improved on my sysadmin UX design. Not sure how high a bar that was, though. :-) [00:46:50] i'm at home, so a comcast ip. [00:54:22] jorm: Wait; you're connecting directly to unicorn and not through a bastion? [00:58:03] jorm: unicorn doesn't have a public IP [01:06:50] Coren: actually... [01:06:55] unicorn used to have a public IP. [01:07:08] I recently, and stealthily, switched it over to use the dynamic proxy. [01:07:09] Well, it doesn't now so no SSH to it from outside. [01:07:15] Maybe I broke everything in so doing? [01:07:21] andrewbogott: Just SSH [01:07:45] so, yeah, that sounds like my fault, because me moving it to the proxy would break ssh but not http [01:07:50] so... [01:07:55] d'oh! [01:07:57] that would explain everything. [01:08:09] we use that as a dumping ground for projects. [01:08:16] sorry :( [01:08:36] I sent an email saying I was going to move things over, but… maybe that wasn't enough warning. [01:08:46] I guess I could notify instance creators when I migrate them [01:10:47] jorm: Is the lack of IP going to be an ongoing problem for that instance, or was it just the secret lack that was the problem? [01:11:40] the lack is possibly going to be a problem going forward. [01:13:19] jorm: at the moment that instance is firewalled from everything except for web access and ssh. [01:22:20] jorm: By which I mean… what use could the public ip have? [01:22:36] I'm happy to turn it back on, but the proxy is generally nicer (as it serves as an https terminator.) [01:25:24] anyway, I have to run, but send me an email or respond to http://lists.wikimedia.org/pipermail/labs-l/2013-November/001877.html if you need the IP reinstated. [02:36:28] Coren, when you have a moment, I'd like to get some info about my labs db user [02:36:41] basically it's opening a bunch of connections and not closing them properly [02:37:20] and I'd like to be able to figure out how many connections the max is, and how many connections it's using at a given time [02:37:30] (accross all project databases) [02:37:33] is that even possible? [02:50:02] milimetric: On any one shard it is. [02:50:13] Lemme take a look. [02:50:49] What user? [03:20:19] Anyone working on fixing enwiki on Beta Labs. [03:20:25] I think I have a good guess what it is. [03:20:29] Bad hook registration [07:18:55] $ mysql --defaults-extra-file=~/replica.my.cnf -B -h csbwiki.labsdb csbwiki_p -e 'select count(*) from revision where rev_timestamp < 20001122001122;' [07:18:59] count(*) [07:19:01] 4 [07:22:10] Kashubian "p [07:22:34] erm? :) [07:23:02] jeremyb: csb is Kashubian, the number of admins is 5 :p [07:23:12] users about 6700 [07:23:17] ok, but still, how did this happen? [07:23:38] i have no idea what you wanted to tell us besides i looked up what csb even is [07:23:54] well wikipedia started in 2001 [07:24:01] and it seemed like you said there are very few revs [07:24:02] that timestamp is 2000 [07:24:10] oooh [07:24:19] i saw 2011 ..mind tricks [07:24:33] also, those aren't revs that are too old. they are revs that are timeless [07:25:36] well, what are the timestamps [07:25:46] that you get from that without counting [07:26:00] 1970 midnight maybe?:P [07:26:31] empty string or something like that [07:27:18] well then, you have to find out why some revision on one of the most obscure language wikipedias did not write a timestamp at some point sicne 2001 in some MW version ?:) [07:27:22] good luck? [07:27:44] hmm [07:28:06] well presumably you could look at the id before and after [07:28:33] true of course [07:30:14] jeremyb: maybe good to make springle look to outrule corruption [07:30:41] not having a ts for a rev is not really good [07:31:05] even when i said the above first about finding the root cause [10:56:11] !log deployment-prep reenabling puppet on parsoid2 and deploying the new Parsoid upstart configuration {{gerrit|99656}} [10:56:13] Logged the message, Master [13:30:52] Coren: when you get back give me a poke [14:44:30] !log integration added Amire80 and Zfilipin to the project. Created integration-sikuli.pmtpa.wmflabs instace. [14:44:32] Logged the message, Master [14:46:25] !log integration granted Amire80 and Zfilipin root access on integration-sikuli [14:46:26] Logged the message, Master [14:46:36] zeljkof ^^^^ :-D [14:46:49] hashar: thanks :) [14:46:59] I have no clue what to do with it :) [14:49:24] stupid wikis [14:49:30] everyone keep copy pasting texts [14:51:48] anyone have an idea why the i18n messages are no longer on beta for gwtoolset? [14:57:55] :'( [14:59:11] hashar '( in a config file or somewhere else? [14:59:30] dan-nl: yeah in operations/mediawiki-config [14:59:38] there is a file wmf-config/extension-list [14:59:44] but that is shared with production [15:00:26] ahh [15:00:31] you did that already [15:00:40] so somehow the cache on beta is broken [15:01:07] hmm i don't see in in extension-list or extension-list-labs [15:01:17] dan-nl: gotta look on deployment-bastion.pmtpa.wmflabs [15:01:21] something must be wrong somewhere [15:01:42] if i add it to extension-list can you approve it or only the extension-list-labs file ? [15:02:04] * c1ef446 - Move GWToolset to 1.23wmf7 extension-list file (18 hours ago) [15:02:05] ... [15:02:13] I am tired [15:02:42] so you did move it from extension-list-labs to extension-list [15:02:51] no worries, i know what you mean [15:02:54] but since GWToolset is only deployed on 1.23wmf7 that must have caused some issue in production [15:03:09] so reedy moved it to extension-list-1.23wmf7 [15:03:23] and I guess beta / labs does not load that file [15:03:32] so gwtoolset messages disappeared from beta [15:03:37] k, so shall i add it back to extension-list-labs? [15:03:43] yup I guess [15:03:45] but [15:03:55] but really, we want labs to load the *wmf ones as well [15:04:11] wmf-config/CommonSettings.php:if ( file_exists( "$wmfConfigDir/extension-list-$wmfExtendedVersionNumber" ) ) { [15:04:12] :( [15:04:22] on labs, MediaWiki version is ALWAYS master [15:04:24] hehe [15:04:34] so you could add it to extension-list-labs indeed [15:04:38] that will be good enough for now [15:04:48] whenever the file ends up in extension-list, we can remove it from extension-list-labs [15:04:52] k, thanks … one moment ... [15:04:54] will be happy to +2 [15:08:42] https://gerrit.wikimedia.org/r/#/c/102444/ [15:20:12] a user know how to use this gerrit patch uploader? [15:26:41] Betacommand: What be up? [15:49:35] Coren: Ive got a bash script that works fine while run in terminal but jsub everything seems screwy [15:50:01] You'll need to define "screwy" a little more precisely. :-) [15:50:26] Betacommand: without knowing anything, that kind of problem usually has to do with paths and/or differences between exec hosts and bastion [15:53:04] Coren: http://tools.wmflabs.org/betacommand-dev/reports/protection/en/sysop_2013_12_16.txt via cron and jsub [15:53:15] http://tools.wmflabs.org/betacommand-dev/reports/protection/en/sysop_2013_12_17.txt manual urn [15:53:19] *run [15:53:57] Are you trying to use the 'sql' command? [15:54:04] yes [15:54:06] !log wikimedia-support Updated scholarship-alpha to b2712b8 [15:54:06] wikimedia-support is not a valid project. [15:54:23] sql is strictly interactive. You want to use mysql directly. [15:54:50] hashar, https://gerrit.wikimedia.org/r/#/c/102444/ is ready for you [15:55:06] Coren: why does it work when Im not using jsub [15:55:21] IE via bash script [15:55:24] dan-nl: merging in progress :) [15:55:30] thanks! [15:55:31] !log wikimedia-support Applied ata/db/migrations/20131217-01-alt-usernames.mysql to aplha db [15:55:31] wikimedia-support is not a valid project. [15:56:00] !log wikimania-support Updated scholarship-alpha to b2712b8 [15:56:01] Logged the message, Master [15:56:04] Betacommand: It's an interactive tool that depends on the environment provided by an interactive shell. The very shell you are executing your script with. [15:56:12] !log wikimania-support Applied ata/db/migrations/20131217-01-alt-usernames.mysql to aplha db [15:56:13] Logged the message, Master [15:56:42] It works in the script because you are invoking that script from said environment. [15:56:55] * Betacommand grumbles about non-uniform systems [15:57:13] Coren: why cant it be a uniform process? [15:58:14] ... for the same reason you can't use vi from a noninteractive environment without trickery. It was never intended for that purpose. [15:58:24] dan-nl: the i18n will be refreshed by a job that runs every six minutes [15:58:47] cool, i'll double-check it in about 6 then [15:59:37] You want to use mysql; and almost certainly with --batch [16:00:21] (mysql without --batch outputs stuff meant for human viewing that is needlessly harder to parse) [16:00:45] --batch separates columns and rows uniformly with well-defined separators and is easy to parse from scripts. [16:02:24] Coren: I like the way I had stuff on the toolserver, I really HATE having two different systems and different ways of invoking stuff based off the terminal or cron [16:02:59] I should be able to use a command in either process and get the same result [16:03:04] Betacommand: You're using the wrong tool for the wrong purpose. 'sql' is really just a shortcut for quick interactive queries. [16:03:10] Betacommand: Yes you should. 'mysql'. [16:04:09] Coren: sql Query > results has been a stable tool on the toolserver for years [16:05:33] That makes a good argument to rename the tool labs' 'sql' command to something else to avoid possible confusion then. [16:05:55] But does toolserver's 'sql' separate columns with single tabs? [16:06:13] Or does it present pretty tables? [16:06:27] Tab seperate values [16:06:46] So 'sql' changes behaviour depending on how it's invoked? [16:06:54] no [16:07:33] well [16:07:49] if you pass it a query vs manual interaction yes [16:07:51] https://commons.wikimedia.org/wiki/User:Dispenser/Double_extension That would use `sql commonswiki_p` but I needed to connect to another cluster [16:08:13] IE a basic sql enwiki_p [16:08:42] vs sql enwiki_p result.txt [16:09:28] Coren: still seeing iowait in `vmstat 1` @ tools-login [16:10:14] (not sure if it's a real problem, but i'd look at `atop` if i could :) ) [16:12:48] any hints about how to speed up `select count(*) from table` on public views? [16:12:49] hashar, thanks, the i18n messages are back on beta [16:13:02] congratulations dan-nl ! [16:15:31] jeremyb: It isn't. [16:16:22] Coren: can you please fix sql ? [16:17:54] Coren: and select count(*)? [16:20:26] I can alter is functionality to be closer to the toolserver's, but that's not going to happen before Jan at earliest. Open a bz for it, please. [16:21:07] can you elaborate? how does it currently differ from toolserver? [16:21:09] jeremyb: Why do you think it's unusually slow? What table are you doing it on? [16:21:28] Coren: i've been focusing on logging/revision [16:24:01] jeremyb: select(*) still does an index scan. That's always going to be slowish on very large tables. [16:27:33] Coren: see e.g. nlwiki [16:27:41] for some reason enwiki is fast [16:29:19] jeremyb: yeay caching. How fast something is depends greatly on whether the pages containing the data are already in memory or not. [16:29:33] sure, i assumed that [16:29:45] * Coren compares. [16:30:26] but i wonder if things should be a bit more balanced :) [16:30:37] ~23s on enwiki; 7.7 from nlwiki. 53 vs 21 m rows. [16:30:59] It's not completely out of whack. [16:31:35] Also, YMMV depending on what other users may be doing at the same time. [16:31:43] 673792126/40587677 [16:31:43] 16.60090391475225349802 [16:32:20] that's en/nl edits per [[special:statistics]] [16:32:21] * Coren was comparing logging tables, not revision [16:32:44] * Coren tries with revision. [16:34:48] Also revision is huge; it's entirely possible that you're hitting page cache limits in a way that plays havock with consistency. [16:35:09] Especially if other queries are running (which they almost certainly are) [16:35:26] well not any more. i gave up and commented out select count(*) [16:35:32] Coren: who do I need to bribe to get sql fixed? [16:35:40] although i don't have good stats for how long it was taking [16:36:53] Coren: can we get csvtool installed please? [16:37:05] i see packages.ubuntu.com is fixed [16:37:26] jeremyb: Sure, just open a bz for it; I'm due for a round of package installs sometime today. [16:39:24] Betacommand: https://git.wikimedia.org/blame/operations%2Fpuppet/81c838c922cabd20cf2a1a9b704265b0582b034c/modules%2Ftoollabs%2Ffiles%2Fsql [16:39:45] Like I said, I'll have time to work on tweaks like this in Jan once I'm done with the prep for the migration. [16:39:47] hrmmm, interesting. http://packages.debian.org/python-unicodecsv [16:44:46] Coren: https://bugzilla.wikimedia.org/58649 [16:45:15] jeremyb: I should be doing a puppet patch for new packages sometime (my) afternoon. ~3-4h from now. [16:45:37] Coren: are you home? :) (i.e. which afternoon is that?) [16:46:04] EST [16:46:09] (GMT-5) [16:46:14] ok, so *my* afternoon :) [16:46:43] Coren: Not sure what Im looking at [16:47:08] Betacommand: The source for that tool. :-) [16:49:53] Coren: did you steal that from the toolserver or write your own> [16:51:02] Betacommand: That's mostly Petr's work. [16:51:41] K [17:03:15] hashar, that puppet config in mediawiki/puppet/modules/mediawiki/templates/jobrunner/jobs-loop.sh.erb should create a gwtoolset runner on beta, correct? [17:03:31] dan-nl: hopefully [17:03:46] dan-nl: I think I applied puppet and restarted the service yesterday [17:04:08] k, it doesn't seem to have done so … could it have to do with the lack of $wgJobTypesExcludedFromDefaultQueue in the CommonsSettings-lab.php file? [17:04:23] possibly [17:04:29] k, i'll add it [17:04:32] I can't remember how that is setup really [17:04:43] jobrunner08 is supposed to run jobs in the default queue [17:05:01] so you probably don't have to add your gwtoolset to $wgJobTypesExcludedFromDefaultQueue [17:06:05] dan-nl: $ mwscript showJobs.php --wiki=commonswiki --group [17:06:06] gwtoolsetUploadMediafileJob: 0 queued; 54 claimed (0 active, 54 abandoned) [17:06:07] gwtoolsetUploadMetadataJob: 1 queued; 0 claimed (0 active, 0 abandoned) [17:06:07] $ [17:06:13] not sure why 54 went abandonned [17:06:19] nor why 1 is still in queue :D [17:06:26] oh boy [17:06:27] that command can be run from deployment-bastion [17:09:34] hashar, here's that commit https://gerrit.wikimedia.org/r/#/c/102464 [17:11:48] ran that command in bastion … thanks … still, i don't understand the results either, except that david did commit a test batch about 30 minutes ago [17:14:59] hashar don't see any exceptions related to the jobs so i'm puzzled as to why they wouldn't be running … hopefully that commit to CommonSettings-labs.php will help [17:24:30] :( [17:24:42] at least showJobs could help a bit [17:24:54] and beside runJobs.php I am not sure whether we have other logs [17:28:18] Coren: looking at labs vs toolserver Im not seeing where the interactive vs non-interactive check is [17:28:42] Unless its just not installed on the exec hosts [17:30:29] Hey Coren, sorry I had gone home last night. My user is u2543 [17:30:39] i'm just starting to look at it again this morning [17:32:32] Steinsplitter: what's the issue? [17:33:58] valhallasw: now resolved. i need to install git on my computer. RAW uploads dos not work :( [17:34:12] Steinsplitter: huh? you should be able to upload a simple diff [17:36:00] but how to? i have spend moor than a hour for this tool :(, [17:36:38] Betacommand: "echo 'select * from revision limit 10;' | sql nlwiki_p | tee" works for me on labs, so it's not in the sql command [17:36:51] Steinsplitter: what's the error you get? [17:37:05] valhallasw: via jsyb? [17:37:10] *jsub [17:37:12] Betacommand: no, directly [17:37:24] valhallasw: thats the issue [17:37:48] Betacommand: my point is you're looking in the wrong place -- it's probably not in sql but in the SGE config [17:38:21] * Betacommand grumbles about how fucked up SGE is [17:38:55] valhallasw: git apply < patch fatal: unrecognized input patch -p0 < patch patch: **** Only garbage was found in the patch input. [17:39:30] "diff -u InitialiseSettings-labs.php" [17:39:56] Steinsplitter: err, what does diff with? [17:39:57] I've been told that that's the standard response Linus gives when you offer a patch in C++ [17:40:20] valhallasw: i type ""diff -u InitialiseSettings-labs.php"" and upload the new version? [17:41:28] Steinsplitter: you have to diff two versions, e.g. diff -u InitialiseSettings-labs.php InitialiseSettings-labs.php.old [17:41:36] (probably the other way around, but OK) [17:45:35] Betacommand: ok, I'm not sure what you're doing, but it works for me via jsub [17:46:13] hashar: https://gerrit.wikimedia.org/r/#/c/102464/ is ready for you. hopefully this will help ... [17:46:14] valhallasw: http://tools.wmflabs.org/paste/view/417cec05 hmm :( [17:47:06] Steinsplitter: so what's in the patch now? [17:47:21] dan-nl: got to leave sorry, can you ping some folks in #wikimedia-dev about it ? [17:47:31] sure mp [17:47:34] sorry :( [17:47:44] diff -u InitialiseSettings-labs.php.old InitialiseSettings-labs.php [17:47:44] # WARNING: This file is publically viewable on the web. [17:47:44] # Do not put private data here. [17:47:44] (....) [17:48:17] Steinsplitter: wait, did you add that text to the top of the file? [17:48:31] yes [17:48:38] diff is the command you have to run [17:48:53] to get a 'diff', i.e. a file that lists the differences between two files [17:49:42] but being able to upload 'a new version of a file' would be a useful improvement [17:50:03] dos not work uploading a new version :( [17:53:12] valhallasw: http://pastebin.com/aNQBV3uL is the command that I use [17:53:27] !log wikimania-support Updated scholarship-alpha to 51a51f8 [17:53:29] Logged the message, Master [17:53:30] thats wrapped in a bash script [17:53:59] that's not the same as sql enwiki_p < sqlscript > output ! [17:54:19] http://pastebin.com/2LKG1QD1 < this should work [17:55:27] Betacommand: what the toolserver version does is run sql -h --comments -e [17:57:44] valhallasw: the issue is that it works normally [17:58:07] but when run via jsub the same .sh file gives different results [17:59:35] valhallasw: thats what is making me mad. If it was broke in both cases it wouldnt be that big of an issue [18:00:20] That's because sql was never tested nor designed to work from anything but an interactive session, and presumes a lot from the environment. [18:01:25] Coren: Im starting to think it may not be sql issue but a SGE issue [18:02:07] Betacommand: How so? [18:02:30] Coren: $(date +"%Y_%m_%d").txt part of the filename may be getting mangled [18:02:57] ... point me at your script, please. [18:03:40] $HOME/bash/sysop_protection.sh [18:04:19] Ive got several other sql commands that dont use the date but do work fine [18:05:09] Hm. [18:05:12] Interesting. [18:06:02] Coren: all of the "Interesting" things happen to me [18:06:51] I'm not seeing any reason why that'd be different in any way. [18:06:55] * Coren does some testing. [18:07:49] valhallasw: thx aniway :-) [18:08:27] !log wikimania-support Updated scholarship-alpha to ef2e3f8 [18:08:28] Logged the message, Master [18:08:29] Coren: running the command works via term but jsub gives the result that I linked above [18:08:56] Betacommand: I see no linked output [18:09:25] maybe that was before I joined? [18:14:43] Ah-ha! [18:16:22] Oh, FFS. How did nobody else hit that bug before? [18:17:07] Betacommand: To try now? [18:18:19] So, for the curious, in our production puppet we have this general policy to install package with 'ensure => present' rather than 'ensure => latest' to avoid the risk of an upgrade mysteriously breaking things. [18:19:20] This works well, /except/ when you have a bunch of ostensibly identical hosts that were created at different times. In that case, 'ensure => present' will install whatever version was newest _at the time of install_ [18:20:16] This is not often an issue, except when the older version had a bug fixed in the newer version. New instances will get the correctly fixed version, but puppet won't touch the broken ones. [18:20:48] Betacommand: In your case, the exec host(s) you were hitting had the older version. [18:21:32] (-02 was the least loaded one, and one of the old ones, which is probably the one you got pretty much every time) [18:36:16] Coren: Ill let you know after the cron runs at about 0000 UTC [18:36:30] Coren: what was causing the issue? [18:36:53] And old version of sql on the older exec nodes. [18:36:55] An* [18:37:15] * Betacommand laughs [18:37:38] Look at scrollback. Our normal policy of not using ensure=>latest in production bites hard on labs. [18:37:44] So I was right it was both an issue with sql and grid [18:37:48] Coren: I saw that [18:38:02] Ima bring the issue with the rest of opsen and change the practice for labs. [18:38:05] i was just wondering what package was casing it [18:38:15] *causing [18:39:24] valhallasw: http://tools.wmflabs.org/betacommand-dev/reports/protection/en/sysop_2013_12_17.txt vs http://tools.wmflabs.org/betacommand-dev/reports/protection/en/sysop_2013_12_16.txt [18:43:07] Ohhhhhhhh [18:43:12] Right. Had not thought of that. [19:48:36] anyone online happen to know how often the job runner on the beta cluster runs the commonswiki jobs? [20:20:23] coren: I just merged a patch that touches nearly every line of every puppet manifest in the tools module. I'm pretty sure it was a no-op, but if you see things break in the next half hour then I'm to blame. [20:23:48] * Coren blames you anyways. [20:23:55] :-) [20:25:03] Coren: i made those changes, so blame me too if you wish :) [20:25:10] Ah, prettifying [20:25:29] Nah, andrewbogott is a good enough target for misdirected ire on his own. :-) [20:26:34] matanya: there's a chain-of-blame. Coren blames me, and then I pass it on as deserved. [20:32:00] Hm, is there some clever ssh setting change I can make to help my sessions survive the hourly 2-minute outages my network seems to suffer? [20:32:45] andrewbogott: mosh is your friend [20:33:00] can I tunnel w/mosh? [20:33:13] yes andrewbogott [20:35:12] andrewbogott: http://blog.mattgauger.com/blog/2012/04/21/mosh-ssh-tunnels-tmux/ [20:37:02] * andrewbogott reads [21:16:05] Coren, given a tool/service group is there a standard place to look for the doc page? [21:17:07] andrewbogott: No; right now it's ad-hoc and people who do so link to wherever from their .description or web landing page. Having a standard place would be good, but Ryan never agreed on a specific one. [21:17:17] So we can simply declare one by fiat. [21:18:02] I presume that your average wikitech user has edit rights to most pages? [21:19:16] + is there a list of existing tools anywhere other than just the list of service groups within the 'tools' project? (I was expecting a list here, but no dice… https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools ) [21:21:01] andrewbogott: I thought http://tools.wmflabs.org was a complete listing? [21:21:36] jarry1250: perhaps! I was expecting to find that from the wikitech homepage [21:21:52] has a tool in a labs project that isnt toollabs. dont bite me [21:23:09] coren: Any luck with service user permissions? (I guess it's not too urgent, just sitting on my todo list nagging me.) [21:23:39] jarry1250: Sorry no; I'm in bug hunting mode so it's on my short-term todo list though. [21:24:22] andrewbogott: tools.wmflabs.org has the only list outside of LDAP afaik. wikitech doesn't expose it outside the list from the management interface. [21:24:51] andrewbogott: And yes, the average wikitech user has edit. [21:25:01] does tools.wmflabs.org enumerate the tools from ldap, or are they added by hand? [21:25:22] And, should there be a link to tools.wmflabs.org from the wikitech front page? [21:26:43] Coren: Okey. I suppose if groups aren't working that means that if my tool can read the file, so can everyone else... hmm... [21:27:33] andrewbogott: It enumerates from ldap [21:28:15] andrewbogott: Talk to Brandon about links and such; he's currently working on a revamp of that. [21:28:22] Coren: tools.wmflabs.org is (presumably) hosted by a labs instance, right? Would you prefer the default doc page be there or back on the wikitech wiki? [21:28:29] (including the tools.wmflabs.org landing page) [21:28:29] Oh, great! [21:28:51] yeah. [21:29:01] But tools.wmflabs.org isn't a wiki, and we probably want to have any documentation wikied. [21:29:03] oh, yeah: i need that ip [21:45:02] jorm: 208.80.153.170 [21:45:24] Do you want me to de-proxy that instance and point unicorn.wmflabs.org at the public IP, or create a different DNS entry for the IP and keep the proxy? [21:46:42] i'm not sure what you're asking. [21:48:07] Right now http://unicorn.wmflabs.org points to a proxy box which relays page loads. It supports https and spdy so is vaguely better than just directing unicorn.wmflabs.org directly to the instance. [21:49:20] So, either you need the public ip for a) something other than web access, or b) web access of a sort that isn't supported by the proxy. [21:49:37]