[00:00:03] I could do it with 2.4 [00:00:50] I guess it's complaining about unicode() now? [00:01:22] unicode() doesn't exist. [00:01:23] fwilson: No, more u'foo' strings at line 23 [00:01:32] legoktm: exactly :) [00:01:33] fwilson: Run 2to3 on your script first. [00:02:21] u'compare' on line 38 [00:02:35] fwilson: Listen to legoktm. He speaks sooth. :-) [00:02:38] :) [00:02:58] Ryan_Lane: Do we have 2.4 deployed anywhere? [00:03:00] 2to3 works now, so I did do that [00:03:07] no clue [00:03:20] does it come with precise? [00:03:20] ImportError: No module named urllib2 [00:03:26] Wait what? [00:03:28] No urllib2? [00:03:43] oh [00:03:44] fwilson: I may need to add python3 libs. :-) [00:03:45] urllib.request [00:03:49] no, you shouldn't need to [00:04:21] Can't use string pattern on a byte-like object? [00:04:50] Ryan_Lane: Nope; even raring seems to be on 2.2.22 [00:04:55] then nope [00:05:03] * Coren curses. [00:05:26] *sigh* [00:05:35] Coren: python3 libs should be default with the package. [00:05:47] fwilson: Just do import urllib.request as urllib2 [00:05:54] That should fix most things [00:06:03] legoktm: i'm from urllib.request import * [00:06:10] Ahhhhhhhhhhhhhhhhhhh [00:06:13] Never do that [00:06:14] Okay, okay [00:06:18] Ssshhh [00:06:20] * legoktm trouts fwilson [00:06:20] Don't tell Vacation9 [00:06:40] !trout fwilson [00:06:43] :/ [00:06:50] Nope, no helpmebot :) [00:06:55] Bwahahahahaha! *ahem* [00:07:26] !trout is *catches a fresh trout from the river, then slaps $1 with it a few times [00:07:27] Key was added [00:07:32] !trout fwilson [00:07:32] *catches a fresh trout from the river, then slaps fwilson with it a few times [00:07:37] ... [00:07:37] close enough. [00:07:46] Be back in a bit [00:07:50] [Thu Mar 14 00:07:16 2013] [error] [client 10.4.1.89] import urllib2.request as urllib2 [00:07:51] [Thu Mar 14 00:07:16 2013] [error] [client 10.4.1.89] ImportError: No module named urllib2.request [00:08:06] >.< [00:10:51] I note that, in python3, the lib seems to be named just 'urllib' [00:11:09] viz. /usr/lib/python3.2/urllib [00:11:45] cf. /usr/lib/python2.7/urllib2.pyc [00:17:56] Yeah. [00:18:10] Well python2 has a plain "urllib" too. [00:18:11] python3 merged the two [00:22:01] Okay, that's fixed [00:22:29] but what in the world does "attempted to use string pattern on a bytes-like object" mean? [00:22:54] google it [00:23:37] I did, it doesn't help very much, all I can tell is that it is in some way related to json [00:23:44] Which I have a feeling tha it isn't [00:24:10] Oh, wait a second [00:25:51] I'd love to be more helpful, but I have level zero in Python-fu [00:26:44] Coren: $ python -c "import this" [00:27:03] Oh yes, you should do that [00:27:57] Just out of curiousity, why didn't we start with unicode in the first place [00:31:18] Change on 12mediawiki a page Wikimedia Labs/Tool Labs/Notepad was modified, changed by MPelletier (WMF) link https://www.mediawiki.org/w/index.php?diff=659541 edit summary: [+8] +python3 [00:34:54] !logs [00:34:54] logs http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-labs [00:35:27] is it possible to have own domain pointing to labs? [00:37:06] Why? [00:37:35] Just out of curiousity, is it possible to get data from bots project in tools project? [00:39:06] fwilson: rsync them from an instance to another? [00:39:21] Danny_B: though yes, I'd also like to know why [00:39:22] hashar: but it's cross-project, i'm not sure how i would do that [00:39:42] labs isn't meant for production use [00:40:51] for instance when somebody runs some wiki-related tools on own server with own domain but would like to migrate to labs [00:41:38] why not redirect their domain to labs? [00:42:03] short answer: eys [00:42:07] keep urls? [00:42:07] *yes [00:42:19] i'm just checking possibilities [00:44:02] Ryan_Lane: "ls: cannot access /data/project: Transport endpoint is not connected " [00:44:11] which instance/project? [00:44:13] cvn-app1 [00:44:16] one sec [00:44:26] Also, cvn-apache2 appears to be critical in ganglia, ssl handshake? [00:44:43] cvn-app1 doesn't have that problem. I set up both the same way afaik [00:45:38] well, these are gluster errors I haven't seen before [00:45:56] either way [00:45:58] fixed [00:46:06] /etc/init.d/autofs restart [00:46:13] ok [00:46:21] looking at apache2 [00:46:27] I just rebooted apache2 [00:46:38] (right after you said gluster was fixed on app1) [00:46:50] I'm on apache2 [00:47:06] !resource i-00000339 [00:47:06] https://labsconsole.wikimedia.org/wiki/Nova_Resource:i-00000339 [00:47:21] nagios shows no issue for it [00:47:24] err [00:47:25] icinga [00:47:28] i-00000339 [00:47:29] err [00:47:32] http://icinga.wmflabs.org/cgi-bin/icinga/extinfo.cgi?type=1&host=cvn-apache2.pmtpa.wmflabs [00:48:13] Ryan_Lane: http://nagios.wmflabs.org/cgi-bin/icinga/status.cgi?hostgroup=cvn&style=detail [00:48:24] "cvn-apache2.pmtpa.wmflabs " has critical errors [00:48:38] "CHECK_NRPE: Error - Could not complete SSL handshake. " for load, disk, ram and processes [00:48:45] ah [00:49:11] I recall seeing those last year one a fresh instance, one had to run puppet manually once to fix it [00:49:19] I know there was some issue with nrpe.... [00:49:27] however this instance isn't fresh anymore, it's been on for a while and only now does it start showing the errors since a few days [00:49:31] but killing it and restarting it should have worked [00:49:38] Damianz: ^^ ? [00:49:42] mutante: ^^ ? [00:49:55] Ryan_Lane: after the restart just now it resolved it for some of them [00:49:59] yep, i killed and restarted nagios-nrpe-server on all instances the other day [00:50:03] they're slowly disappearing [00:50:11] but this is just on one instance and i think it wasnt the same error [00:50:34] btw, why didn't these get reported in #wikimedia-labs-nagios? I have a stalkword in that channel for projects I'm in. [00:50:42] duration 6d ... so that isnt that new either..hmm [00:50:49] they only get reported when it initially goes critical [00:50:57] ok [00:50:59] mutante: well, it didn't hit all instances [00:51:04] oh wait, it just fixed itself [00:51:07] mutante: only ones that had salt responding [00:51:12] I killed nrpe and restarted it [00:51:16] must've been the reboot then [00:51:17] at least disk space is OK now [00:51:23] gotcha Ryan [00:52:11] we had similar issues in the past in prod. with nagios-nrpe-server not restarting properly [00:52:30] and once attempted to fix it, i think successfully, by adding a "sleep" in the init script [00:52:42] and then we cleaned up/removed that old init script when we switched to icinga .. [00:53:30] but it also didn't happen anymore, last time i made a change to NRPE checkcommands, which triggers a restart, it did not break like it used to back in the days.. [00:57:37] mutante: could it be the puppet subscribe[] not working properly ? [00:58:49] well, i don't know if this is the exact same issue, but the old issue wasn't that, it was puppet doing a service restart and then it would stop but not come back [00:59:50] I tried out on a frozen instance [01:00:31] puppet never stopped the nrpe process despite claiming it did [01:01:04] notice: /Stage[main]/Nrpe::Service/Service[nagios-nrpe-server]/ensure: ensure changed 'stopped' to 'running' [01:01:13] keep doing it despite me having /usr/sbin/nrpe -c /etc/icinga/nrpe.cfg -d running [01:03:45] confirmed ..ugh [01:04:07] just using the init script , not puppet related, does not properly stop it [01:04:11] and if you try to use /etc/init.d/nagios-nrpe-server stop [01:04:19] it says OK despite the process still running [01:04:25] suspecting the pid file is incorrect [01:05:43] running as user pid 4294967295 ? [01:05:55] uid [01:06:25] if [ ! -d "$PIDDIR" ]; then mkdir "$PIDDIR" chown nagios "$PIDDIR" [01:07:02] PIDDIR owned by nagios .. but process not running as nagios [01:07:11] good catch [01:08:18] Welp, 13 hour days is 'nuf for me. [01:08:19] * Coren waves. [01:08:43] mutante: /etc/icinga/nrpe.cfg has user icinga [01:08:47] # id icinga [01:08:47] id: icinga: No such user [01:08:49] so hmm [01:09:03] include user::icinga; require => User['icinga'] [01:11:40] systemuser { icinga: name => "icinga", home => "/home/icinga", groups => [ "icinga", "dialout", "nagios" ] } [01:13:03] but does whatever class install nrpe on labs include that icinga::monitor class? [01:13:08] Ryan_Lane: service is setup in manifests/nrpe.pp [01:13:16] class nrpe::service { [01:18:17] fixing [02:00:18] Is ganglia down? [02:01:19] hm [02:01:25] looks like it kind of is [02:02:06] hm [02:02:10] looks like it's out of memory [02:02:14] ssh: Could not resolve hostname bastion3.wmflabs.org: nodename nor servname provided, or not known [02:02:15] :( [02:02:58] hashar: fixed [02:03:01] \O/ [02:03:11] stupid pdns ldap backend [02:03:19] cant we get a bastion.wmflabs.org entry pointing to all bastions? :] [02:03:29] heh [02:03:36] that won't make things better ;) [02:03:37] or even a failover between both datacenters [02:03:52] expecting ssh to try all the IN A records it is given [02:04:00] yeah, it doesn't do that [02:04:08] and it would give back different keys for each [02:04:16] ah true [02:04:16] unless we sync'd all the host keys [02:04:20] ;-] [02:04:21] but that has another set of problems [02:04:43] FastLizard4: fixed [02:04:46] restarted gmond [02:04:56] seems we need a larger instance for ganglia [02:04:59] Ryan_Lane: Aha, danke :) [02:05:02] * Ryan_Lane goes to create one [02:12:00] bah. both aggregator1 and aggregator2 need to be recreated [02:12:21] or resized.... [02:12:27] hm. maybe I'll get resize working [02:13:09] !log deployment-prep Trying out geoip module from {{gerrit|53714}} on deployment-integration [02:13:12] Logged the message, Master [02:21:42] booo [02:21:49] geoip does not play well in labs [02:22:00] !log account-creation-assistance apt-get update/upgrade on all instances [02:22:01] Logged the message, Master [02:22:45] hashar: in what way? [02:23:03] attempt to access the private volatile storage to get the GeoIP datafiles [02:23:04] :-D [02:23:09] oh [02:23:09] right [02:23:11] of course [02:23:11] I thought it worked [02:23:17] different puppet master [02:23:20] using a different set of files [02:23:22] we don't have that enabled on virt0 [02:23:39] hashar: can you add a bug? [02:23:44] wikimedia labs, infrastructure [02:23:49] sure [02:24:25] hmm geoip-database package has been installed [02:28:56] https://bugzilla.wikimedia.org/show_bug.cgi?id=46093 [02:28:58] [bz] (NEW - created by: Antoine "hashar" Musso, priority: Unprioritized - normal) [Bug 46093] virt0 puppet master lacks GeoIP files - https://bugzilla.wikimedia.org/show_bug.cgi?id=46093 [04:20:32] !log deployment-prep Upgrading apache32, apache33, video05 and jobrunner08 [04:20:35] Logged the message, Master [04:22:05] !log deployment-prep Restarted apache on apache32,33 [04:22:07] Logged the message, Master [04:22:17] !log deployment-prep killed job runners on jobrunner08 and restarted service [04:22:19] Logged the message, Master [08:05:12] is there a general problem ? git fetch origin does not work [08:06:46] hmm, was slow but is working now [08:52:47] addshore, legoktm were there any stability issues over past days? [08:53:03] compared to the TS? lol nope [08:53:08] great [08:53:36] I mean since we launched scheduler [08:54:03] nah its great [08:59:59] Damianz is CB working now? [09:00:03] I see little activity on sql [09:07:21] [bz] (NEW - created by: Antoine "hashar" Musso, priority: Low - enhancement) [Bug 46104] reduce the number of wiki on beta - https://bugzilla.wikimedia.org/show_bug.cgi?id=46104 [10:22:46] [bz] (NEW - created by: Tim Landscheidt, priority: Unprioritized - normal) [Bug 46105] Install libmediawiki-api-perl - https://bugzilla.wikimedia.org/show_bug.cgi?id=46105 [10:24:10] !log wikidata-dev wikidata-testrepo: disabled AbuseFilter extension in the local puppet files, because it led to error messages when editing lang links. Also: Installed php5-xdebug for a better apache error log. [10:24:13] Logged the message, Master [11:14:33] !log webtools rebooted webtools-login & webtools-apache-1 [11:14:34] Logged the message, Master [11:20:43] petan: :D [11:21:40] one thing I was going to say is we should always try and keep usage at 100^% of all resources - 1 instance, that way if one goes down / we need to do something to it all is fine :) [12:02:27] !log wikidata-dev puppety-pupp: Deleted obsolete puppet test instance [12:02:29] Logged the message, Master [13:10:43] addshore what [13:11:49] addshore I don't care about wiki bots being on loaded instance - but I DO CARE about interactive bots being on these [13:12:08] it's like mixing elephant and glasses in one room - glasses will crash [13:12:37] interactive bots should live on instance with load near to 0 to work properly [13:12:53] that's it [13:18:39] @notify addshore [13:18:39] This user is now online in #huggle so I will let you know when they show some activity (talk etc) [13:44:50] petan: im here for a bit [13:45:07] ok what did you talk about [13:45:23] well firstly looking at ganglia we should probably have another instance for OGE [13:45:33] ok - I will make it then [13:46:18] secondly with interactive bots we should have yet another instance which OGE uses, but have a seperate queue for that instance [13:46:23] * addshore now has to go ;p [13:46:30] ill be back latrter! [13:47:40] addshore yes I agree with that [13:50:08] !gridbots is http://helms-deep.cable.nu/~rwh/blog/?p=159 [13:50:08] Key was added [14:48:14] Coren, when reading the conversation between Petr and you, I got the question, if volunteers can really help in tools already or is Petr right that you want to do the first steps alone? [14:48:51] Jan_Luca no volunteers in tools so far [14:48:56] btw I am Petr Bena [14:49:36] Jan_Luca: I'm not /opposed/ to having help but, at this point, it's more likely than not that the actual time spent would increase as additional sysadmins are involved. At least some minimal documentation would be needed, and that needs the base groundwork to have been settled. [14:49:55] Jan_Luca: tl;dr in a couple weeks, most likely. [14:50:37] Coren: You think that volunteers would cause problems [14:50:40] And yes, petan will be welcome to step forward personally if he wants to. :-) [14:50:42] I? [14:50:45] ? [14:51:10] Because I think there are many persons that could help you with some things [14:51:17] Jan_Luca: No, just that right now the time needed for coordination would be bigger than the time saved with the extra hands. Most of the documentation exists in my head only. :-) [14:51:25] well, that's what I think as well, hence all my emails [14:51:50] but I can of course wait working within bots project only of course [14:52:14] In a couple of weeks, once the greater part of the design has gelled and is at least minimally documented, extra help will become useful. [14:52:49] Coren: I think the idea of open source/open knowledge is that everybody can access it and help to extend it [14:53:40] And I understand labs as a platform for working together! to help the Wikimedia projects [14:55:59] At moment I can understand DaB. why he has his problems with the migration to Tool Labs when the first steps are happen without the community [14:57:18] Jan_Luca: I think that the dichotomy is imaginary. I am no less "the community" than everyone else, except that I have the opportunity to devote my full attention to this; I'm not sure where that meme originates that I am somehow and adversary, but that canard needs to stop. [14:59:08] <^demon> Coren's old school :) [14:59:46] ^demon: Oy. *Elder* school. :-) [14:59:57] (Ancient?) [14:59:58] :-) [15:00:33] <^demon> Well, I meant it as "Been on-wiki since at least '06 or earlier" :) [15:00:59] Jan_Luca: If people needed to be root to "work together", Toolserver would have two users. [15:02:50] Jan_Luca: And, again, nobody every said there wouldn't be volunteer roots; just that right now it's not as useful as it would be in a couple weeks. [15:03:12] <^demon> "Repository corruption is not good. Sounds like there are still some bugs in JGit's GC class that need to be investigated and fixed before this is unleashed on the masses." [15:03:13] <^demon> Aww :( [15:03:37] ^demon: I would tend to agree. Repo corruption is "not good". [15:04:29] <^demon> Not good at all. [15:05:35] <^demon> Yeah, I think it collects some stuff that's not garbage. That's kinda really bad. [15:05:54] Coren: My problem is that persons who like to help to make the Tool Labs a good alternative to Toolserver get the answer that they are at moment not useful [15:06:26] with this answer there would be nobody in a couple weeks to help then [15:08:31] Jan_Luca: Read and comment on Coren's proposals on-wiki, become a member of the project and beta-test its current implementation, etc., etc., etc. [15:08:33] Jan_Luca: That... I have no answer to that. That assertion is neither realistic nor rational, and I do not see what I could possibly say that is relevant. People also will not get root access to the Openstack underlying the VM infrastructure, nor enable access on the routers. How is that relevant? [15:09:15] scfc_de: That too, yes. [15:10:00] Jan_Luca: The difference is that I am saying "not yet, I'm still preparing things" as opposed to "no, you don't get to touch that" [15:10:40] Coren: I don't know if you know about DaB. and his position about Tool Labs [15:11:01] Jan_Luca: I do, and I'm disapointed that he chose to not get involved; his help would have been invaluable. [15:11:59] Jan_Luca: But then again, he is free to occupy his time in the manner he choses. We can't very well coerce him into participating! [15:12:06] <^demon> "Build path is incomplete...cannot find java.lang.Object" [15:12:10] <^demon> wtf eclipse? [15:14:52] So my question is "Why?" Why do DaB. choose this position? I think he shares among other things the doubts that petan and I have and the less participation that the comunity has at moment because you decide the way to go [15:18:51] Jan_Luca: I think DaBPunkt is alive and well and can answer your question much better. [15:19:08] Jan_Luca: I very much doubt that Daniel based his decision on how I approach the job months before I even applied for it. If you want his reasons, then you should ask him. [15:23:41] Coren: I don't think that there is any dichotomy but I (and petan seems to do this, too) think that the way of the first steps of Tool Labs could be better [15:23:48] well, I have doubts, indeed, but I am not really opposed to the idea of tools labs should the philosophy of its maintenance change in future - and you said it will. The reason why I am standing out of tools is unlikely same as DaB's - he's not the part of project because he doesn't want to, I am not part of it because I am not allowed to :P [15:26:20] Coren: I don't say that your work is bad, I only want that Tool Labs is more open for the volunteers [15:26:27] petan: You are welcome as a part of the project, just not *yet* as root :-). [15:27:16] scfc_de, which kind of block me from doing anything useful there - I am working as sysadmin on bots, not as bot operator - I can't help very much with testing... [15:27:27] I have some bots, but... [15:27:53] they aren't designed to run in grid, so even if some would run there, they wouldn't help to test anything [15:28:07] Jan_Luca: What do you want to do that you can't do? [15:28:28] scfc_de: What should I test? How the webserver for my tools works? [15:29:01] Jan_Luca: No, I asked what you *want* to do. [15:29:55] Jan_Luca: Yes, they are different approaches. Perhaps ^demon is right in calling me "Old school", and I do my original work with a "too many cooks spoils the sauce" approach. I believe that the initial design and setup phase needs to be done with a consistent and unified approach that is not amenable to multiple simultaneous designers. This doesn't mean that I won't appreciate input and [15:30:24] Jan_Luca: advice (and, indeed, I've already made several changes to the design according to feedback like Tim's here) [15:31:03] scfc_de: My problem is not that I have less permissions but that the project is too closed at moment [15:31:09] Jan_Luca: And, every bit of testing helps. Bring tools over, and note what breaks, or what needs to be documented. [15:31:29] scfc_de: When I need root I could get my own project ;-) [15:31:31] Jan_Luca: ... what? How is it closed? [15:32:17] <^demon> That's not what I meant by old school, but meh :) [15:32:35] ^demon: Hey, quoting out of context FTW! :-P [15:32:40] Coren: Too closed for the offered help [15:33:04] Jan_Luca: ... you haven't offered help for me to deny. [15:33:57] (I thought my initial question was some kind of offering help...) [15:34:27] Coren, when reading the conversation between Petr and you, I got the question, if volunteers can really help in tools already or is Petr right that you want to do the first steps alone? [15:35:44] My intention of the question was to help Tool Labs [15:36:29] so I asked if volunteers (like me) can help set up the envirment [15:36:48] Jan_Luca: I did not understand the implicit question. [15:37:44] Jan_Luca: The answer, then, is yes you can; the best help possible atm is to try to run code and see what is missing (dependencies, environmental contraints, etc). Same for the webserver; are there missing settings to have thing work right, are there difficulties with the rewrite rules, etc. [15:39:20] Jan_Luca: Trying the grid scheduler to see if things run as expected is also useful, though that one is not entirely configured yet so problems are probable. [15:40:23] Coren: The problem is that I have only one tools that I think about to migrate [15:40:46] Jan_Luca: Other invaluable help includes documentation of things you found unclear; there is a lot I assume given my experience and the fact that I am setting the environment up that may be obscure or incomprehensible to others; finding those so I can document them is something I cannot do myself. [15:42:57] (For instance, it never occured to me that saying 'sudo to the tool user' wouldn't automatically mean 'sudo -iu' to most) [15:43:58] Jan_Luca: You can also help by assisting Silke in completing her inventory of actual tools and their dependencies. Last I checked, she was overwhelmed with the amount of work. [15:45:12] If you want, I can probably find even more things that could use help. :-) [15:45:52] Coren: To get a good end of the discussion, I ask you to add me to project so I can look into it [15:46:00] my user is jan [15:46:13] Jan_Luca: Sure. Do you want a tool user set up too? [15:46:21] yes [15:46:54] Jan_Luca: What's the name for it? (That's going to be part of the webserver URI, amongst other things) [15:47:32] is there some convention? [15:47:54] Not really; users right now take the name their tool is usually known as, like "voxelbot") [15:48:14] then use "commonshelper2" [15:48:15] The actual username will be 'local-xxx' so no conflicts there. [15:48:43] that is the tool I think about to migrate [15:48:45] {{doing}} [15:49:44] Coren: Creating a tool is the first thing I would add to the documentation ;-) [15:50:21] There's going to be a self-serve interface on wikitech for that; manual creation is a temporary hack. [15:51:25] Jan_Luca: {{done}} [15:51:32] You can hop onto tools-login now [15:52:03] Switching to your tool uses "sudo -iu local-commonshelper2" [15:54:17] Your tool has a default mysql database available, the credential are in its ~/.my.cnf [15:54:47] Also, the tool's public_html and cgi-bin are served by http://tools.wmflabs.org/commonshelper2/ [15:55:44] .. and since I've repeated that schpeil at least five times in the past two days, I go document it now. :-) [15:56:47] bbiab [15:57:43] One thing I would do is to setup a direct login to get it simlar to Toolserver [16:03:40] Jan_Luca: You can't log into MMPs on Toolserver. The setup is the same. [16:04:26] scfc_de: No, I mean a login adresss like tools-login.wmflabs.org [16:04:42] because not every toolserver user will understand bastion [16:06:58] Jan_Luca: https://wikitech.wikimedia.org/wiki/Help:Access#Using_ProxyCommand_ssh_option [16:07:42] scfc_de: I can use bastion but I think not every toolserver user can use it without problems [16:08:40] Jan_Luca: What problems? [16:09:48] for example use ProxyCommand [16:10:11] What do you mean by that? [16:13:47] I think that there will be some users that have problems with bastion and to avoid problems I suggest to set up a direct login server for Tool Labs [16:14:39] That would just be a new bastion [16:14:47] It wouldn't solve any issues [16:15:12] well it would solve some issues as you wouldn't need to mess with forwarding etc. I think he has a point [16:15:16] What problems? [16:15:25] not all people are unix guru's [16:15:33] Wouldn't need to mess with forwarding? [16:15:44] Krenair: yes [16:15:46] Krenair [16:15:55] A direct login server sounds like something you'd have to proxy through to get to the tool labs instance you want [16:16:12] Just a new bastion [16:16:17] Krenair you don't need to get to instance you want - you submit jobs from login instance ;) [16:16:20] that's how it works [16:16:28] There's one central instance..? [16:16:28] login instance is master server of grid [16:16:30] yes [16:17:47] I'm not sure what blocks being able to SSH directly to instances at the moment... [16:17:57] Krenair: Ryan :-). [16:18:13] Oh, ops is against it? [16:18:19] what's the point of bastion if you allow direct access to tool ? I agree some people will have trouble with forwarding and they'll need to login in two steps [16:18:20] nothing really - I had one instace with direct ssh long time ago [16:18:30] Krenair: (Just an assumption.) [16:18:50] but that was just because firewall wasn't operational back then, later I disabled it [16:19:02] Ryan_Lane: Want to chime in? [16:19:28] The problem is that direct ssh to instances would need a public IP for every instance [16:19:37] Not for every instance [16:19:39] and the number of this IPs are not very big [16:19:44] Just for one central tool labs instance [16:19:55] (I think) [16:20:07] Krenair: This is my idea [16:20:11] ;-) [16:20:28] .... [16:20:34] You said all instances... [16:21:00] Maybe my intention was not clear ... [16:21:04] The problem is that direct ssh to instances would need a public IP for every instance [16:21:09] every instance -> multiple [16:21:19] one central instance -> single [16:21:34] I mean: I think that there will be some users that have problems with bastion and to avoid problems I suggest to set up a direct login server for Tool Labs [16:23:02] the other was the answer to: I'm not sure what blocks being able to SSH directly to instances at the moment... [16:26:37] * Coren burps. [16:27:24] I'm not opposed to making tools-login accessible directly from the outside. I'll have to ask internally in Ops, but I think that's entirely feasible. [16:28:04] And no, the primary reason why we can't ssh directly to the instances is "not enough public IPs" [16:28:10] tools already has a public IP [16:29:21] Strictly speaking, though, the tools project never needs users logging in directly to instances other than -login [16:36:20] Coren: I mean that the public IP problem is one reason for creating bastion [16:36:51] and not access every instance (in all projects) with public IPS [16:37:03] Jan_Luca: Yes, but since the tools project already has a public IP, it should be okay to use it for SSH also to log in directly to tool-login [16:37:48] Coren: you cannot access two instances (-login and -webproxy) with one public IP [16:39:41] Jan_Luca: Sure you can, on different ports. But I'm probably simply going to use a second public IP if I can convince Ryan_Lane to assign it; I agree with you that given the variable level of unix expertise in tools maintainer, it's a good idea to reduce the complexity. [16:41:12] Coren: Yes, with a complex way you need only one IP but I think for Tool Labs you get a second (bastion has three) [17:00:26] petan: You should read https://wiki.toolserver.org/view/Job_scheduling [17:00:38] there is the docu about qcronsub [17:04:26]