=== kadams54 is now known as kadams54-away === rbasak_ is now known as rbasak [17:11] rick_h_: thanks for adding us to the analytics [17:18] mbruzek: np === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [20:58] Hi, hatch directed me here with a problem. [20:59] Spizmar_: drop it on us [20:59] hey Spizmar_ [21:00] I delete my environment and boot strap it, and deploy juju-gui, and some other charms, relations and expose them [21:01] When I point to the juju-gui server (which is the bootstrap machine), the browser just spins, [21:01] http://askubuntu.com/questions/600872/juju-gui-web-server-hangs-what-server-does-it-use [21:02] Spizmar_: the images you're using for your environment - do they have python installed? === kadams54-away is now known as kadams54 [21:02] This would not normally shosk me, as I am new to this and have broken about everything i've touched, but I do this all through a script, which I can upload, and the scriupt has worked fine, previiously. [21:03] If they need it, they had it three days ago, as I am doing everything locally, and have not refreshed any images for weeks. [21:04] ok so you have the gui deployed now and are you getting the python.h error again? [21:05] Spizmar_: what version of juju and juju-gui are you using? [21:05] hatch: Spizmar_ don't worry about the python.h error. It's just a performance speed up that it can use if it's available, but not required [21:06] rick_h_: ohh ok - I thought gui wasn't building [21:06] hatch: Spizmar_ focus on why the gui can't talk to the server. I'm guessing there's a network issue or something there [21:06] Thank you. Let me check. I was just assosiating that with the octave-controller problem [21:06] hatch: you can find out for sure if it's running by running 'ps aux' on the box and looking for the guiserver. And checking the /var/log/upstart/guiserver.log [21:06] Spizmar_: it could be, I'm not sure what octave is [21:06] Spizmar_: if you deploy multiple services onto the same machine you have to watch out for what ports they use [21:07] ahh octave is being d eployed to the same machine... [21:07] hatch: right, all that is getting sent to machine 0 [21:07] hatch: so I'd walk with Spizmar_ through looking at the browser console for connection issues, (network tab/etc) [21:08] yeah sounds good [21:08] hatch: and then going through the guiserver.log to see if it can't start/run due to ports being conflicting or the like [21:08] hatch: in which case, set the gui to run on a different port (8080 or the like) and see if that helps at all [21:09] * rick_h_ runs away now for a while and leaves it in hatch's capable hands [21:09] hatch: Spizmar_ and if you figure it out make sure to update the AU question please [21:09] Octave-controller is being deployed on a different machine, octave, which doesn't use python, is being deployed on the bootstrap machine, but it was when it worked. I was modifying the octave-controller install script when this happened, which is deployed on a different machine. [21:10] Spizmar_: ok so lets start from the beginning [21:10] ps -aux | grep guiserver [21:11] * hatch spins up local env to work along side [21:11] juju-gui is running, because I just got a warning that this is not a trusted machine, which is expected behavior. [21:11] oh ok so when you say you get the spinner you actually get the GUI spinner? [21:11] grey background and the like? [21:12] Does it say "Loading the GUI" or "Connecting to Environment" ? [21:12] Nope. I was too hopefull. guiserver is not running. [21:12] oh ok then [21:13] :) [21:13] ok ssh into the machine and open up /var/log/upstart/guiserver.log [21:13] let me strip my script down to just destroying my env, bootstrapping and deploying juju-gui. [21:13] sure [21:13] Wait one [21:13] np [21:14] What do you want me to look for [21:14] something which indicates why it's not running :) [21:15] Because that is a lot faster than a boot strap [21:15] is this a MAAS environment? [21:18] yes. [21:20] I just tried to login from the maas server machine so I could copy and paste, and it looks like I'm here, but there is no one elase here. [21:21] you ran 'juju ssh juju-gui/0' ? [21:21] iostream:409 error on read while listening on port 443, if that helps. (/var/log/upstart/guiserver.log) [21:22] No, I tried to get into #juju-gui on freenode from my maas server. [21:23] ahh ok so something else is using 443 [21:24] netstat -tulpn | grep :443 [21:24] or you can change the port for the GUI if you need to as well [21:25] LOL Let me try that. I have expertise to do that at hand, and the guy who wrote the octave stuff hasn't returned any emails :) [21:26] you'll need to run that netstat on the machine you have the gui deployed to [21:29] It was not that. No processes came up using that search. And it is in the tornado libraries, which is where the compiler presented the error. [21:30] yeah for some reason it is not able to bind to that port [21:31] you could try setting it to another port and then tail the log [21:31] juju set juju-gui port=8888 [21:31] from the 'client' machine [21:32] My mistake, there is something listening there. I had exited and was running the netstat on my maas server. [21:35] On the client machine, it does not know about the "juju" command. [21:35] the machine which you typed 'juju deploy' on is the client machine, sorry :) [21:37] OK, did that, now I get an immediate failure to connect, and 10:0:1:21:8888spins [21:38] https://10.0.1.21:8888 [21:38] Yes [21:39] ok and does the guiserver.log have anything in it? Or is it running now [21:39] you should get an ssl error because of the self signed cert in the browser [21:40] I'm assuming of course that your machine allows connections to 8888 :) [21:41] you may want to find out what else is listening on 443 and kill it if it's not supposed to be there [21:42] It says start juju gui ver, ets, and listening on port 8888 [21:43] ok and if you run netstat on that machine it shows that it's listening on 8888? [21:48] Yes, on IP4 & ip6. I did sudo ufw disable, and retried the connection from the maas server and it still spins. I'm going to find a different unused port, try it from the maas server to see how fast ibefore it complains, then change the juju-gui port, and try it again, and see how long that takes. [21:49] After that, I'm going to run the script with the other charms removed and see how it works. [21:50] yeah you should start with a fresh image because it seems like something is preventing the server from talking out [21:50] The thing that was on port 443 is gone. I think juju-gui was the thing holding the port. [21:53] Spizmar_: ok so if 443 is open again lets change the gui back to 443, tailing the logs, see if it boots up properly [21:55] I just tested a local env and aws env and the latest gui deployed properly so I know that it's working as far as LXC and AWS are concerned :) [21:55] btw, I tried port 222, firefox immediately recognized there wasn't anything there, then I changed the juju-gui port, and it is spinning away. [21:58] so the guiserver log isn't showing anything when you try and access that port? [22:00] it's really hard to debug this over irc haha - I'd probably install lynx on the same machine the guiserver is on and see if it can access it === kadams54 is now known as kadams54-away [22:06] Sorry about that, my connection froze. What was the last thing you saw from me, hatch? [22:06] that you tried 222 [22:06] I was saying I would install lynx to the GUi machine to see if I could access it locally - rule out any firewall business [22:09] I can tell you that my corporate firewall will rule that out. Between the two machines is a blank managed switch. The two machines have both had ufw disabled. [22:10] I tried 222, and firefox immediately detected that there was nothing there, I switched juju-gui's port to 222, and firefox started spinning. [22:10] but nothing showed up in the guiserver logs? [22:11] I changed it back to 443 and rebooted it, and it came up fine, in the sense that there were no additional errors in the log, but it displays the same symptoms. [22:11] what if you try chrome/ium? [22:12] The log showed the change in the ports, though. [22:13] to rule out the browser we could also try this [22:14] wget https://10.0.1.21/juju-ui/version.js [22:14] wget --no-check-certificate https://10.0.1.21/juju-ui/version.js [22:14] sorry [22:17] wget --no-check-certificate https://10.0.1.21/juju-ui/version.js [22:17] Spizmar_: did you get that ^ [22:18] And again. Corporate has the IRC port blocked so I can't use a client and this webchat thing is not looking too stable. [22:19] might be time to set up a proxy :) [22:19] Well, juju gui server version is 0.4.2 [22:19] I was trying to see if the guiserver is working - if it is it will return the that file [22:20] 0.4.2? [22:21] 0,4,2 is from the log file, it did return the file. Not sure what to do with it. [22:22] cat version.js [22:22] ok it returned the file! [22:22] that means the server is running and that you can access it [22:22] and that something firefoxy is causing the issue [22:23] are there any errors in the browser console? [22:23] I'd be very interested to know if you can access it using chrome/chromium [22:25] I'm already pushing real hard on ITs envelope by having the maas server connected, and bringing up an HPC cluster they don't own [22:25] :) keep pushing! [22:25] Firefox debugger says "this page has no souce" [22:26] I do :) I just make sure the fights have a good purpose [22:26] ok this is very odd - because clearly the guiserver is working if you got the version.js file downloaded [22:26] but firefox will not open the page [22:27] So what file should it be down loading, or what should be constructing the text, that it isn't getting? [22:27] well did that wget download the file? [22:27] you should have seen some sort of progress bar [22:28] sorry I've just been assuming you're on Ubuntu.... [22:28] what machine are you working from :) [22:29] Spizmar_: I think that I might know what the issue is - can you follow this https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings [22:29] Yes, the system I'm doing this work on is ubuntu. The system I'm on right now is win7. My chairs runners are getting a workout. [22:29] The version was 1.3.3, BTW [22:29] haha [22:29] ok new enough :) [22:30] And in the middle, I am grazing on my lunch [22:30] lunch, must be west coast? [22:30] Do you want me top go ahead and do the rebuild? [22:31] LA, but it's 1530 here [22:31] "Running late and keeping you up to date" [22:31] well I want to get a fresh profile - see this issue https://bugs.launchpad.net/juju-gui/+bug/1397296 [22:31] Bug #1397296: GUI inaccessible in Firefox 33.0

[22:35] I can see the +bug, the second says I don't need to know. I'm reading. [22:38] I had to do a reboot of the maas server yesterday, and I don't remember what the updates were, if firefox had an update. [22:40] yeah I'd be interested to know if you try a new profile as noted in that bug if you can access it [22:43] trying to bring it up on my maas server [22:51] Did the refresh, It has no effect on the symptoms. I'm going to do the rebuild. [22:51] *hmph* I'm running out of ideas [22:52] :) [22:52] Unless you want any of the logs or the bootstrap debug output? [22:53] nah - see the server is working because you were able to download that js file [22:53] Hey, I ran out ideas yesterday :) [22:53] and your network is allowing the connection (because you were able to download the file) [22:53] so that leaves us at the browser?!? [22:54] OK, I will download chrome. [22:54] shhh don't tell IT [22:55] I'm not even sure they've heard Microsoft has killed IR [22:55] IE [22:55] haha [22:56] that will be awesome when IE goes evergreen [22:56] It is all they support, with a list of our own sites you have to use other browsers to use. [23:01] went right to it. Expect a wave of these, as the new update of whatever was updated trickles down to peoples juju-gui machines. [23:01] so you did a fresh firefox install? [23:01] Do you know how I can list what was updated yesterday, so we can weed through them to find out which one it was, if you want? [23:01] sorry I have no idea... [23:02] or you tried with chrome you mean [23:02] I didn't update firefox. [23:02] I tried with chrome and it works great. [23:03] That means something in yesterdays install broke something. [23:03] damn... [23:04] I don't know if it directly broke firefox, or if it broke something one that is used by juju-gui, and that breaks fire fox. [23:04] Would you be able to comment on that launchpad bug saying that you are having the same issue and the reset settings fix did not work [23:04] Sure will. [23:05] thanks! [23:05] of course this doesn't fix your issue - but at least if you comment on the bug you'll be notified when we figure out what's going on... [23:05] That you! I get very bull dog when I'm tired, and I'm tired, and I'd never have thought of using a different browser. [23:06] the issue with this bug is that noone on the GUI team can reproduce it [23:06] but obviously it's an issue heh [23:06] LOL! It fixes MY problem I could care less if it's firefox or chrome! [23:07] haha yay! Well now you can go update the AU question :) [23:07] I think this update probably makes it a lot easier to reproduce. I never had the problem before yesterday. [23:08] hmm nope, even after the update still works fine here... [23:08] *close* WFM! lol jk [23:08] After a boostrap? [23:09] yep [23:09] Well, it may not make it easier for you, but it may make it easier for us out her :) [23:10] well I'm glad I got you going again at least :) [23:11] Me too. Is there a channel for charms in general, or for apache, or a place to see what channels there are? [23:12] #juju and #juju-dev [23:12] #juju-dev is mostly for actual juju development [23:12] so you're probably looking for #juju [23:12] Great, thanks! [23:13] there is also the juju mailing list - juju at lists dot ubuntu dot com [23:13] I'm heading off to put the anser in the question have a good one! [23:13] you too, cya