terminal prompt won't show

[zwindler]

Hi,

I'm having an issue with my installation of GateOne. I'm using CentOS 6.2, as I could get all the dependencies on my previous CentOS 5.6

Installation went well, I used python 2.6 from the CentOS distrib, tornado from the python-pip and pyOpenSSL from repositories because I came into some compilation problems with pip.

From what I could see, GateOne seem to be working fine, except from the fact that I don't see the prompt. I can see the icons, the menus, I can set the preferences, but I don't see the "HOST/IP or SSH url" prompt (and so on).

At first, I thought that the terminal wasn't working at all, but it seems that caracters I type are in fact taken into account as I can see a trace of my attempts to blindly login the log viewer plugin in the web page.

Last addition : I'm using a french distro, and a colegue of mine is experiencing the same issue on a debian 6 install is also french. Not sure if this is relevant, but I wanted to add it, just in case it is :-p

[liftoff]

This sounds like the issue I just fixed (worked around anyway) in the
latest commit. Are you running the latest?

Also, the problem was actually a bug in Tornado that I reported and has
since been fixed in the dev version. If you grab that from Github it should
work.

Daniel McDougall - Liftoff Software
On Jan 16, 2012 4:03 PM, "zwindler" <
reply@reply.github.com>
wrote:

Hi,

I'm having an issue with my installation of GateOne. I'm using CentOS 6.2,
as I could get all the dependencies on my previous CentOS 5.6

Installation went well, I used python 2.6 from the CentOS distrib, tornado
from the python-pip and pyOpenSSL from repositories because I came into
some compilation problems with pip.

From what I could see, GateOne seem to be working fine, except from the
fact that I don't see the prompt. I can see the icons, the menus, I can set
the preferences, but I don't see the "HOST/IP or SSH url" prompt (and so
on).

At first, I thought that the terminal wasn't working at all, but it seems
that caracters I type are in fact taken into account as I can see a trace
of my attempts to blindly login the log viewer plugin in the web page.

Last addition : I'm using a french distro, and a colegue of mine is
experiencing the same issue on a debian 6 install is also french. Not sure
if this is relevant, but I wanted to add it, just in case it is :-p

---

Reply to this email directly or view it on GitHub:
#82

[zwindler]

Thanks from the quick answer!

I used the tarball downloadable from this web site, which is tagged 546d5a1 (that seem to be the latest)

This morning I downloaded the tarball on the master branch of tornado like you pointed out, and I (sadly) see no improvement.

Feel free to ask any information you might need if you want to look into this

[teixeiras]

same here

[liftoff]

I'll be pushing a new commit soon that will probably fix this. If not I'll get my VM up and running again to see if I can't figure it out. I think it might have to do with some recent changes to Tornado's websockets.py in the dev branch. Either way I'll get to the bottom of it.

[liftoff]

Are you still having this issue with the latest Tornado (2.2) and the latest Gate One code? I just tested it in my CentOS 6.2 VM and it seems to be working.

[zwindler]

Well there must be something missing as a dependancy on my side because I'm still having trouble. At first I thought this could be related to the fact that my CentOS is in french and that GateOne might be tested on en_US, so I installed a new english one with the last code fron the git and Tornado 2.2 but i'm still having the same problem.
python -V
Python 2.6.6
python -c "import tornado; print(tornado.version)"
2.2

I mostly followed the documentation even though I had to adapt it slightly in order to fit CentOS 6.2. Here is my installation procedure :

#last time I tried to install modules with pip, I couldn't install some of them because of the lack of gcc. Pip gave little indication on the root cause so I lost a great deal of time on this. Not sure this is still needed though but it can't hurt
yum install gcc

#I couldn't find pip in the standard CentOS repository
wget http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm
rpm -Uvh epel-release*rpm
yum install python-pip
pip-python install tornado kerberos

#getting the last version directly from github
wget https://github.com/liftoff/GateOne/tarball/master
mv master gateone.tar.gz
tar zxvf gateone.tar.gz; cd liftoff-*; sudo python setup.py install

cd /opt/gateone/
./gateone.py

Last thing, I'm getting this warning on all my test plateforms. Don't know if this is relevant to the issue or not
[W 120208 06:32:19 iostream:627] SSL Error on 10: [Errno 1] _ssl.c:490: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

[liftoff]

I just blew away my CentOS 6.2 VM and re-installed it. Then I installed pip and tornado from scratch. Then I installed Gate One from the github repo... It works fine. Here's the commands I used:

# Install pip
yum install curl # I actually forget if I had to do this
curl http://python-distribute.org/distribute_setup.py | python
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python

Next install Tornado, pyOpenSSL, kerberos, and PIL (while we're at it =)

pip install tornado pyOpenSSL kerberos PIL

Then download and install Gate One just like you did above (grabbing the tarball and running the setup.py).

For reference, that "unknown ca" error will happen if your install of OpenSSL is missing the default certificates. Not sure how that would happen but it can be remedied by installing some CA package or by copying them from another server (I forget the instructions/path but just google it).

[zwindler]

First, I confirm that having a "french CentOS" generates errors (python traceback for bad encoding the french caracters) but the easy workaround is changind the server lang environment

Then, for the real issue here, we both lost time for something really silly (sorry) : the problem seems to be coming from the Web Browser/javascript.

My collegue told me that he had the same issue on Chrome so I didn't bother to try it. My day to day browser being Firefox 8, I thought there wouldn't be any problems (it's not like i'm using IE6). I confirm you that the procedure I used is sufficient to have a working GateOne for Chrome, but in Firefox (8 and also 10) the issue comes up.

I'm receiving javascript error in the console
Erreur : Could not get domain!
Fichier Source : https://[MY_IP]/static/gateone.js
Ligne : 3137
Erreur : t.termUpdatesWorker is undefined
Fichier Source : https://[MY_IP]/static/gateone.js
Ligne : 3173

Changing browser isn't impossible for me at home, but people don't always have the choice of their browser, especially where I work where lots of ports are also blocked => thus bringing up the "need" of a web terminal being available anywhere.

[liftoff]

Hmm... It appears that my workaround for Firefox 8's broken Web Worker behavior (with Blobs) isn't working. If you take a look at the source code in question (gateone/static/gateone.js) right around that line (3137) you'll see the following:

var blobURL = URL.createObjectURL(bb.getBlob());
// NOTE: Using Blob URLs for WebWorkers doesn't work in Firefox 8 due to a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=699633)
if (navigator.userAgent.indexOf('Firefox/8') == -1) {
    t.termUpdatesWorker = new Worker(blobURL);
} else {
    // Fall back to the old way
    t.termUpdatesWorker = new Worker(go.prefs.url+'static/go_process.js');
    // Why bother with Blobs?  Because you can't load Web Workers from a different origin *type*.  What?!?
    // The origin type would be, say, HTTPS on port 443.  So if I wanted to load a Web Worker from such a page where the Worker's URL is from an HTTPS server on port 10443 it would throw errors.  Even if it is from the same domain.  The same holds true for loading a Worker from an HTTP URL.  What's odd is that you can load a Worker from HTTPS on a completely *different* domain as long as it's the same origin *type*!  Who comes up with this stuff?!?
    // So by loading the Web Worker code via the WebSocket we can get around all that nonsense since WebSockets can be anywhere and on any port without silly restrictions.
    // In other words, the old way should still work as long as Gate One is listening on the same protocol (HTTPS) and port (443) as the app that's embedding it.
}

What it boils down to is this: It is a bug in Firefox 8 that I thought I successfully worked around for most situations (it worked great in my own testing when I myself was using Firefox 8) but apparently there's something different about your environment preventing the workaround from actually working around the bug.

Having said that, it was fixed in Firefox 9 and the latest is Firefox 10 (which is the best Firefox ever! =). I don't suppose you can upgrade? Essentially, I don't want to spend much time on this if I don't have to since Firefox 8 will soon be just another notch in the archives of history. Perhaps understanding why you can't upgrade to a new version of Firefox would help motivate me (I do want to help you but when the Firefox devs themselves refused to backport the fix, well, what can I say? :).

Now, as to the French language problem: I consider stuff like that to be #1 priority bugs. That is unnacceptable. I'm going to install a French language CentOS and fix it. Can you paste the output of "env" so I can replicate it in my testing?

Gate One is supposed to work very well with internationalization. If that isn't working it is a major problem.

Je parle un peu français. Je peux le réparer!

[zwindler]

You're right, it works perfectly on Firefox 10. Thanks for the help on my
issue :-)

For the requested information, I'm trying to push attachments, hope this
will be readable via github, otherwise I'll copy them again. I've been
confused because when I tried to reproduce the traceback I failed at first
(nothing happened). But then after some time the traceback came in loops
(see one of those in the attachment)

Feel free to ask any additional information. I hope you can work around
this without too much effort because I've had another experience with those
kind of problems with python on another project. Fixing it has been a
tedious task for the developer

2012/2/9 Dan McDougall <
reply@reply.github.com

Hmm... It appears that my workaround for Firefox 8's broken Web Worker
behavior (with Blobs) isn't working. If you take a look at the source code
in question (gateone/static/gateone.js) right around that line (3137)
you'll see the following:

var blobURL = URL.createObjectURL(bb.getBlob());
// NOTE: Using Blob URLs for WebWorkers doesn't work in Firefox 8 due
to a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=699633)
if (navigator.userAgent.indexOf('Firefox/8') == -1) {
t.termUpdatesWorker = new Worker(blobURL);
} else {
// Fall back to the old way
t.termUpdatesWorker = new
Worker(go.prefs.url+'static/go_process.js');
// Why bother with Blobs? Because you can't load Web Workers from
a different origin type. What?!?
// The origin type would be, say, HTTPS on port 443. So if I
wanted to load a Web Worker from such a page where the Worker's URL is from
an HTTPS server on port 10443 it would throw errors. Even if it is from
the same domain. The same holds true for loading a Worker from an HTTP
URL. What's odd is that you can load a Worker from HTTPS on a completely
different domain as long as it's the same origin type! Who comes up
with this stuff?!?
// So by loading the Web Worker code via the WebSocket we can get
around all that nonsense since WebSockets can be anywhere and on any port
without silly restrictions.
// In other words, the old way should still work as long as Gate
One is listening on the same protocol (HTTPS) and port (443) as the app
that's embedding it.
}

What it boils down to is this: It is a bug in Firefox 8 that I thought
I successfully worked around for most situations (it worked great in my
own testing when I myself was using Firefox 8) but apparently there's
something different about your environment preventing the workaround from
actually working around the bug.

Having said that, it was fixed in Firefox 9 and the latest is Firefox 10
(which is the best Firefox ever! =). I don't suppose you can upgrade?
Essentially, I don't want to spend much time on this if I don't have to
since Firefox 8 will soon be just another notch in the archives of history.
Perhaps understanding why you can't upgrade to a new version of Firefox
would help motivate me (I do want to help you but when the Firefox devs
themselves refused to backport the fix, well, what can I say? :).

Now, as to the French language problem: I consider stuff like that to be
#1 priority bugs. That is unnacceptable. I'm going to install a French
language CentOS and fix it. Can you paste the output of "env" so I can
replicate it in my testing?

Gate One is supposed to work very well with internationalization. If
that isn't working it is a major problem.

Je parle un peu franais. Je peux le rparer!

---

Reply to this email directly or view it on GitHub:
#82 (comment)

[E 120209 20:15:25 ioloop:413] Exception in callback <tornado.stack_context._StackContextWrapper object at 0x919f25c>
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/tornado/ioloop.py", line 399, in _run_callback
callback()
File "./gateone.py", line 1401, in _send_refresh
self.write_message(json_encode(output_dict))
File "/usr/lib/python2.6/site-packages/tornado/websocket.py", line 141, in write_message
self.ws_connection.write_message(message, binary=binary)
AttributeError: 'NoneType' object has no attribute 'write_message'
[I 120209 20:15:30 gateone:867] WebSocket opened (%anonymous).
[E 120209 20:15:31 websocket:257] Uncaught exception in /ws
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/tornado/websocket.py", line 254, in wrapper
return callback(_args, *_kwargs)
File "./gateone.py", line 895, in on_message
PLUGIN_WS_CMDS[key](value, tws=self)# tws==TerminalWebSocket
File "/opt/gateone/plugins/ssh/ssh.py", line 356, in get_connect_string
'sshjs_reconnect': json_encode({term: connect_string})
File "/opt/gateone/utils.py", line 170, in json_encode
return unicode(_json_encode(obj))
File "/usr/lib/python2.6/site-packages/tornado/escape.py", line 84, in json_encode
return _json_encode(recursive_unicode(value)).replace("</", "</")
File "/usr/lib/python2.6/site-packages/tornado/escape.py", line 208, in recursive_unicode
return dict((recursive_unicode(k), recursive_unicode(v)) for (k,v) in obj.iteritems())
File "/usr/lib/python2.6/site-packages/tornado/escape.py", line 208, in
return dict((recursive_unicode(k), recursive_unicode(v)) for (k,v) in obj.iteritems())
File "/usr/lib/python2.6/site-packages/tornado/escape.py", line 214, in recursive_unicode
return to_unicode(obj)
File "/usr/lib/python2.6/site-packages/tornado/escape.py", line 174, in to_unicode
return value.decode("utf-8")
File "/usr/lib/python2.6/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xd8 in position 4: invalid continuation byte

env

TERM=xterm
SHELL=/bin/bash
USER=root
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
PWD=/root
LANG=fr_FR.UTF-8
G_BROKEN_FILENAMES=1
_=/bin/env

locale

LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

[liftoff]

Can you run Gate One with "--logging='debug'" and send me that traceback again with some of the lines leading up to it? Also, the hostname you're connecting to... Does it have any non-ASCII characters? Something like "français-consoler.méga-entreprise.com"?

Also, what locale are you running your browser from? Is your browser configured to use fr_FR.UTF-8 or perhaps something like fr_FR.1252?

When I installed French locale support and set my LANG to fr_FR.UTF-8 everything seemed to work fine so I'm not sure what's going on here.

[liftoff]

Any update on the French language issue? Is it still happening?

[zwindler]

I know I told you I'd keep you posted on this but I've been really busy lately and it's not going to change soon. Sorry for that

I guess that the easiest thing would be to close the issue for now (the initial problem being resolved). When I've got more time I can look if I still have the same problem or not and inform you if there still is a problem.

Does this seem ok to you?

Denis

[liftoff]

Absolutely. Just open a new ticket when you're ready.